Re: [PATCH v12 08/29] HMM: add device page fault support v6.

[Aneesh Kumar K.V]

Jérôme Glisse  writes:

> [ text/plain ]
> This patch add helper for device page fault. Thus helpers will fill
> the mirror page table using the CPU page table and synchronizing
> with any update to CPU page table.
>
> Changed since v1:
>   - Add comment about directory lock.
>
> Changed since v2:
>   - Check for mirror->hmm in hmm_mirror_fault()
>
> Changed since v3:
>   - Adapt to HMM page table changes.
>
> Changed since v4:
>   - Fix PROT_NONE, ie do not populate from protnone pte.
>   - Fix huge pmd handling (start address may != pmd start address)
>   - Fix missing entry case.
>
> Signed-off-by: Jérôme Glisse 
> Signed-off-by: Sherry Cheung 
> Signed-off-by: Subhash Gutti 
> Signed-off-by: Mark Hairgrove 
> Signed-off-by: John Hubbard 
> Signed-off-by: Jatin Kumar 
> ---





 +static int hmm_mirror_fault_hpmd(struct hmm_mirror *mirror,
> +  struct hmm_event *event,
> +  struct vm_area_struct *vma,
> +  struct hmm_pt_iter *iter,
> +  pmd_t *pmdp,
> +  struct hmm_mirror_fault *mirror_fault,
> +  unsigned long start,
> +  unsigned long end)
> +{
> + struct page *page;
> + unsigned long addr, pfn;
> + unsigned flags = FOLL_TOUCH;
> + spinlock_t *ptl;
> + int ret;
> +
> + ptl = pmd_lock(mirror->hmm->mm, pmdp);
> + if (unlikely(!pmd_trans_huge(*pmdp))) {
> + spin_unlock(ptl);
> + return -EAGAIN;
> + }
> + flags |= event->etype == HMM_DEVICE_WFAULT ? FOLL_WRITE : 0;
> + page = follow_trans_huge_pmd(vma, start, pmdp, flags);
> + pfn = page_to_pfn(page);
> + spin_unlock(ptl);
> +
> + /* Just fault in the whole PMD. */
> + start &= PMD_MASK;
> + end = start + PMD_SIZE - 1;
> +
> + if (!pmd_write(*pmdp) && event->etype == HMM_DEVICE_WFAULT)
> + return -ENOENT;
> +
> + for (ret = 0, addr = start; !ret && addr < end;) {
> + unsigned long i, next = end;
> + dma_addr_t *hmm_pte;
> +
> + hmm_pte = hmm_pt_iter_populate(iter, addr, &next);
> + if (!hmm_pte)
> + return -ENOMEM;
> +
> + i = hmm_pt_index(&mirror->pt, addr, mirror->pt.llevel);
> +
> + /*
> +  * The directory lock protect against concurrent clearing of
> +  * page table bit flags. Exceptions being the dirty bit and
> +  * the device driver private flags.
> +  */
> + hmm_pt_iter_directory_lock(iter);
> + do {
> + if (!hmm_pte_test_valid_pfn(&hmm_pte[i])) {
> + hmm_pte[i] = hmm_pte_from_pfn(pfn);
> + hmm_pt_iter_directory_ref(iter);

I looked at that and it is actually 
static inline void hmm_pt_iter_directory_ref(struct hmm_pt_iter *iter)
{
BUG_ON(!iter->ptd[iter->pt->llevel - 1]);
hmm_pt_directory_ref(iter->pt, iter->ptd[iter->pt->llevel - 1]);
}

static inline void hmm_pt_directory_ref(struct hmm_pt *pt,
struct page *ptd)
{
if (!atomic_inc_not_zero(&ptd->_mapcount))
/* Illegal this should not happen. */
BUG();
}

what is the mapcount update about ?

> + }
> + BUG_ON(hmm_pte_pfn(hmm_pte[i]) != pfn);
> + if (pmd_write(*pmdp))
> + hmm_pte_set_write(&hmm_pte[i]);
> + } while (addr += PAGE_SIZE, pfn++, i++, addr != next);
> + hmm_pt_iter_directory_unlock(iter);
> + mirror_fault->addr = addr;
> + }
> +

So we don't have huge page mapping in hmm page table ? 


> + return 0;
> +}
> +
> +static int hmm_pte_hole(unsigned long addr,
> + unsigned long next,
> + struct mm_walk *walk)
> +{
> + return -ENOENT;
> +}
> +


-aneesh

Re: [PATCH trace-cmd 1/2] trace-cmd-listen: remove useless printf

[Peter Xu]

On Tue, Mar 22, 2016 at 09:18:11AM -0400, Steven Rostedt wrote:
> > diff --git a/trace-listen.c b/trace-listen.c
> > index 1e38eda..12cc9c5 100644
> > --- a/trace-listen.c
> > +++ b/trace-listen.c
> > @@ -721,7 +721,6 @@ static void do_accept_loop(int sfd)
> > do {
> > cfd = accept(sfd, (struct sockaddr *)&peer_addr,
> >  &peer_addr_len);
> > -   printf("connected!\n");
> 
> I probably kept this in for debugging. But I still think there should
> be some kind of logging here. If anything, change this to a debug
> print. I'm working on passing in --debug into the command line here, so
> I'm not going to take this patch. It should be converted to the debug
> coed.

Sure. This is trivial. Please just drop it.

-- peterx

Re: [PATCH] spi: fsl-dspi: Set max_speed_hz for master

[Stefan Agner]

On 2016-03-21 13:11, Bhuvanchandra DV wrote:
> Calculate and update max speed from bus clock for SoC's
> using DSPI IP.
> 
> The bus clock factor's are taken from the data sheet's
> of respective SoC's.

Plurals are without apostrophe...

I wonder if GCC optimizes this to a bit shift...

Acked-by: Stefan Agner 

> 
> Signed-off-by: Bhuvanchandra DV 
> ---
>  drivers/spi/spi-fsl-dspi.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 59a1143..8753276 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -121,18 +121,22 @@ enum dspi_trans_mode {
>  
>  struct fsl_dspi_devtype_data {
>   enum dspi_trans_mode trans_mode;
> + u8 max_clock_factor;
>  };
>  
>  static const struct fsl_dspi_devtype_data vf610_data = {
>   .trans_mode = DSPI_EOQ_MODE,
> + .max_clock_factor = 2,
>  };
>  
>  static const struct fsl_dspi_devtype_data ls1021a_v1_data = {
>   .trans_mode = DSPI_TCFQ_MODE,
> + .max_clock_factor = 8,
>  };
>  
>  static const struct fsl_dspi_devtype_data ls2085a_data = {
>   .trans_mode = DSPI_TCFQ_MODE,
> + .max_clock_factor = 8,
>  };
>  
>  struct fsl_dspi {
> @@ -726,6 +730,9 @@ static int dspi_probe(struct platform_device *pdev)
>   }
>   clk_prepare_enable(dspi->clk);
>  
> + master->max_speed_hz =
> + clk_get_rate(dspi->clk) / dspi->devtype_data->max_clock_factor;
> +
>   init_waitqueue_head(&dspi->waitq);
>   platform_set_drvdata(pdev, master);

Re: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

[Oucharek, Doug S]

Yes, those are “per-CPT allocations”.  So the allocator ends up allocating an 
array of pointers to the given data type.

Doug

On Mar 22, 2016, at 10:39 PM, Dilger, Andreas 
mailto:andreas.dil...@intel.com>> wrote:

On 2016/03/22, 19:49, "lustre-devel on behalf of Greg Kroah-Hartman"
mailto:lustre-devel-boun...@lists.lustre.org>
 on behalf of
gre...@linuxfoundation.org> wrote:

On Tue, Mar 22, 2016 at 06:21:04PM -0400, James Simmons wrote:
Latest testing fails when using ko2iblnd. It was tracked down
to commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.

This reverts commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.
---
.../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index 89f9390..0d32e65 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1968,7 +1968,7 @@ static int kiblnd_net_init_pools(kib_net_t *net,
__u32 *cpts, int ncpts)
 */

net->ibn_fmr_ps = cfs_percpt_alloc(lnet_cpt_table(),
-sizeof(*net->ibn_fmr_ps));
+sizeof(kib_fmr_poolset_t));

Ok, why is this revert needed?  Please give me a big huge comment about
why this is not the same size of the variable being assigned to it,
otherwise someone else is going to come along and make the exact same
change again.

if (!net->ibn_fmr_ps) {
CERROR("Failed to allocate FMR pool array\n");
rc = -ENOMEM;
@@ -1992,7 +1992,7 @@ static int kiblnd_net_init_pools(kib_net_t *net,
__u32 *cpts, int ncpts)

 create_tx_pool:
net->ibn_tx_ps = cfs_percpt_alloc(lnet_cpt_table(),
-   sizeof(*net->ibn_tx_ps));
+   sizeof(kib_tx_poolset_t));

Same here, why is this code wrong?

Looks like the declarations are:

   kib_tx_poolset_t **ibn_tx_ps; /* tx pool-set */
kib_fmr_poolset_t **ibn_fmr_ps; /* fmr pool-set */



so the right code should be:

   sizeof(**net->ibn_tx_ps);


and the same for sizeof(**net->ibn_fmr_ps)

Cheers, Andreas
--
Andreas Dilger

Lustre Principal Architect
Intel High Performance Data Division


___
lustre-devel mailing list
lustre-de...@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org

[PATCH] tpm: drop the field 'time_expired' from struct tpm_chip

[Jarkko Sakkinen]

Removed the field because it is not used for anything.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 09302ab..3c4e5eb 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -175,7 +175,6 @@ struct tpm_chip {
 
int dev_num;/* /dev/tpm# */
unsigned long is_open;  /* only one allowed */
-   int time_expired;
 
struct mutex tpm_mutex; /* tpm is processing */
 
-- 
2.7.3

Re: [PATCH] tpm: drop 'base' from struct tpm_vendor_specific

[Jarkko Sakkinen]

On Wed, Mar 23, 2016 at 08:16:09AM +0200, Jarkko Sakkinen wrote:
> Dropped the field 'base' from struct tpm_vendor_specific and migrated
> it to the private structures of tpm_atmel and tpm_nsc.
> 
> Signed-off-by: Jarkko Sakkinen 

Ugh, forgot the final step: removing the field from the struct.
Otherwise, this should be good (at least from my point of view).

/Jarkko

> ---
>  drivers/char/tpm/tpm_atmel.c |  6 ++---
>  drivers/char/tpm/tpm_atmel.h |  7 --
>  drivers/char/tpm/tpm_nsc.c   | 57 
> +---
>  3 files changed, 46 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
> index affc04b..c6daf6c 100644
> --- a/drivers/char/tpm/tpm_atmel.c
> +++ b/drivers/char/tpm/tpm_atmel.c
> @@ -36,6 +36,7 @@ enum tpm_atmel_read_status {
>  };
>  
>  struct tpm_atmel_priv {
> + unsigned long base;
>   int region_size;
>   int have_region;
>  };
> @@ -146,8 +147,7 @@ static void atml_plat_remove(void)
>   if (chip) {
>   tpm_chip_unregister(chip);
>   if (priv->have_region)
> - atmel_release_region(chip->vendor.base,
> -  priv->region_size);
> + atmel_release_region(priv->base, priv->region_size);
>   atmel_put_base_addr(chip->vendor.iobase);
>   platform_device_unregister(pdev);
>   }
> @@ -196,6 +196,7 @@ static int __init init_atmel(void)
>   goto err_unreg_dev;
>   }
>  
> + priv->base = base;
>   priv->have_region = have_region;
>   priv->region_size = region_size;
>  
> @@ -206,7 +207,6 @@ static int __init init_atmel(void)
>   }
>  
>   chip->vendor.iobase = iobase;
> - chip->vendor.base = base;
>   chip->vendor.priv = priv;
>  
>   rc = tpm_chip_register(chip);
> diff --git a/drivers/char/tpm/tpm_atmel.h b/drivers/char/tpm/tpm_atmel.h
> index 6c831f9..08607a6 100644
> --- a/drivers/char/tpm/tpm_atmel.h
> +++ b/drivers/char/tpm/tpm_atmel.h
> @@ -22,6 +22,8 @@
>   *
>   */
>  
> +#define atmel_get_priv(chip) ((struct tpm_atmel_priv *) chip->vendor.priv)
> +
>  #ifdef CONFIG_PPC64
>  
>  #include 
> @@ -78,8 +80,9 @@ static void __iomem * atmel_get_base_addr(unsigned long 
> *base, int *region_size)
>   return ioremap(*base, *region_size);
>  }
>  #else
> -#define atmel_getb(chip, offset) inb(chip->vendor->base + offset)
> -#define atmel_putb(val, chip, offset) outb(val, chip->vendor->base + offset)
> +#define atmel_getb(chip, offset) inb(atmel_get_priv(chip)->base + offset)
> +#define atmel_putb(val, chip, offset) \
> + outb(val, atmel_get_priv(chip)->base + offset)
>  #define atmel_request_region request_region
>  #define atmel_release_region release_region
>  /* Atmel definitions */
> diff --git a/drivers/char/tpm/tpm_nsc.c b/drivers/char/tpm/tpm_nsc.c
> index 766370b..8ccb1d5 100644
> --- a/drivers/char/tpm/tpm_nsc.c
> +++ b/drivers/char/tpm/tpm_nsc.c
> @@ -64,6 +64,13 @@ enum tpm_nsc_cmd_mode {
>   NSC_COMMAND_EOC = 0x03,
>   NSC_COMMAND_CANCEL = 0x22
>  };
> +
> +struct tpm_nsc_priv {
> + unsigned long base;
> +};
> +
> +#define tpm_nsc_get_priv(chip) ((struct tpm_nsc_priv *) chip->vendor.priv)
> +
>  /*
>   * Wait for a certain status to appear
>   */
> @@ -72,7 +79,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, u8 
> val, u8 * data)
>   unsigned long stop;
>  
>   /* status immediately available check */
> - *data = inb(chip->vendor.base + NSC_STATUS);
> + *data = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
>   if ((*data & mask) == val)
>   return 0;
>  
> @@ -80,7 +87,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, u8 
> val, u8 * data)
>   stop = jiffies + 10 * HZ;
>   do {
>   msleep(TPM_TIMEOUT);
> - *data = inb(chip->vendor.base + 1);
> + *data = inb(tpm_nsc_get_priv(chip)->base + 1);
>   if ((*data & mask) == val)
>   return 0;
>   }
> @@ -95,9 +102,9 @@ static int nsc_wait_for_ready(struct tpm_chip *chip)
>   unsigned long stop;
>  
>   /* status immediately available check */
> - status = inb(chip->vendor.base + NSC_STATUS);
> + status = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
>   if (status & NSC_STATUS_OBF)
> - status = inb(chip->vendor.base + NSC_DATA);
> + status = inb(tpm_nsc_get_priv(chip)->base + NSC_DATA);
>   if (status & NSC_STATUS_RDY)
>   return 0;
>  
> @@ -105,9 +112,9 @@ static int nsc_wait_for_ready(struct tpm_chip *chip)
>   stop = jiffies + 100;
>   do {
>   msleep(TPM_TIMEOUT);
> - status = inb(chip->vendor.base + NSC_STATUS);
> + status = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
>   if (status & NSC_STATUS_OBF)
> - status = inb(chip->vendor.base + NSC_DATA);
> +

[PATCH] tpm: drop 'base' from struct tpm_vendor_specific

[Jarkko Sakkinen]

Dropped the field 'base' from struct tpm_vendor_specific and migrated
it to the private structures of tpm_atmel and tpm_nsc.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm_atmel.c |  6 ++---
 drivers/char/tpm/tpm_atmel.h |  7 --
 drivers/char/tpm/tpm_nsc.c   | 57 +---
 3 files changed, 46 insertions(+), 24 deletions(-)

diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index affc04b..c6daf6c 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -36,6 +36,7 @@ enum tpm_atmel_read_status {
 };
 
 struct tpm_atmel_priv {
+   unsigned long base;
int region_size;
int have_region;
 };
@@ -146,8 +147,7 @@ static void atml_plat_remove(void)
if (chip) {
tpm_chip_unregister(chip);
if (priv->have_region)
-   atmel_release_region(chip->vendor.base,
-priv->region_size);
+   atmel_release_region(priv->base, priv->region_size);
atmel_put_base_addr(chip->vendor.iobase);
platform_device_unregister(pdev);
}
@@ -196,6 +196,7 @@ static int __init init_atmel(void)
goto err_unreg_dev;
}
 
+   priv->base = base;
priv->have_region = have_region;
priv->region_size = region_size;
 
@@ -206,7 +207,6 @@ static int __init init_atmel(void)
}
 
chip->vendor.iobase = iobase;
-   chip->vendor.base = base;
chip->vendor.priv = priv;
 
rc = tpm_chip_register(chip);
diff --git a/drivers/char/tpm/tpm_atmel.h b/drivers/char/tpm/tpm_atmel.h
index 6c831f9..08607a6 100644
--- a/drivers/char/tpm/tpm_atmel.h
+++ b/drivers/char/tpm/tpm_atmel.h
@@ -22,6 +22,8 @@
  *
  */
 
+#define atmel_get_priv(chip) ((struct tpm_atmel_priv *) chip->vendor.priv)
+
 #ifdef CONFIG_PPC64
 
 #include 
@@ -78,8 +80,9 @@ static void __iomem * atmel_get_base_addr(unsigned long 
*base, int *region_size)
return ioremap(*base, *region_size);
 }
 #else
-#define atmel_getb(chip, offset) inb(chip->vendor->base + offset)
-#define atmel_putb(val, chip, offset) outb(val, chip->vendor->base + offset)
+#define atmel_getb(chip, offset) inb(atmel_get_priv(chip)->base + offset)
+#define atmel_putb(val, chip, offset) \
+   outb(val, atmel_get_priv(chip)->base + offset)
 #define atmel_request_region request_region
 #define atmel_release_region release_region
 /* Atmel definitions */
diff --git a/drivers/char/tpm/tpm_nsc.c b/drivers/char/tpm/tpm_nsc.c
index 766370b..8ccb1d5 100644
--- a/drivers/char/tpm/tpm_nsc.c
+++ b/drivers/char/tpm/tpm_nsc.c
@@ -64,6 +64,13 @@ enum tpm_nsc_cmd_mode {
NSC_COMMAND_EOC = 0x03,
NSC_COMMAND_CANCEL = 0x22
 };
+
+struct tpm_nsc_priv {
+   unsigned long base;
+};
+
+#define tpm_nsc_get_priv(chip) ((struct tpm_nsc_priv *) chip->vendor.priv)
+
 /*
  * Wait for a certain status to appear
  */
@@ -72,7 +79,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, u8 
val, u8 * data)
unsigned long stop;
 
/* status immediately available check */
-   *data = inb(chip->vendor.base + NSC_STATUS);
+   *data = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
if ((*data & mask) == val)
return 0;
 
@@ -80,7 +87,7 @@ static int wait_for_stat(struct tpm_chip *chip, u8 mask, u8 
val, u8 * data)
stop = jiffies + 10 * HZ;
do {
msleep(TPM_TIMEOUT);
-   *data = inb(chip->vendor.base + 1);
+   *data = inb(tpm_nsc_get_priv(chip)->base + 1);
if ((*data & mask) == val)
return 0;
}
@@ -95,9 +102,9 @@ static int nsc_wait_for_ready(struct tpm_chip *chip)
unsigned long stop;
 
/* status immediately available check */
-   status = inb(chip->vendor.base + NSC_STATUS);
+   status = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
if (status & NSC_STATUS_OBF)
-   status = inb(chip->vendor.base + NSC_DATA);
+   status = inb(tpm_nsc_get_priv(chip)->base + NSC_DATA);
if (status & NSC_STATUS_RDY)
return 0;
 
@@ -105,9 +112,9 @@ static int nsc_wait_for_ready(struct tpm_chip *chip)
stop = jiffies + 100;
do {
msleep(TPM_TIMEOUT);
-   status = inb(chip->vendor.base + NSC_STATUS);
+   status = inb(tpm_nsc_get_priv(chip)->base + NSC_STATUS);
if (status & NSC_STATUS_OBF)
-   status = inb(chip->vendor.base + NSC_DATA);
+   status = inb(tpm_nsc_get_priv(chip)->base + NSC_DATA);
if (status & NSC_STATUS_RDY)
return 0;
}
@@ -132,8 +139,9 @@ static int tpm_nsc_recv(struct tpm_chip *chip, u8 * buf, 
size_t count)
dev_err(&chip->dev, "F0 timeout\n");
return -EIO;
}
-   if ((data =
-

[PATCH] ARM: dts: exynos: Enable SSS on Odroid X/X2/U3 family

[Krzysztof Kozlowski]

Enable the Security SubSystem (SSS) on Exynos4412-based Odroid boards
to provide hardware acceleration for AES operations.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Tobias Jakobi 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 5e5d3fecb04c..470e592e9232 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -492,6 +492,10 @@
status = "okay";
 };
 
+&sss {
+   status = "okay";
+};
+
 &tmu {
vtmu-supply = <&ldo10_reg>;
status = "okay";
-- 
2.5.0

Re: [PATCH v2 5/6] x86/xen,pat: Remove PAT table init code from Xen

[Juergen Gross]

On 22/03/16 18:02, Borislav Petkov wrote:
> On Wed, Mar 16, 2016 at 06:46:58PM -0600, Toshi Kani wrote:
>> Xen supports PAT without MTRR for its guests.  In order to
>> enable WC attribute, it was necessary for xen_start_kernel()
>> to call pat_init_cache_modes() to update PAT table before
>> starting guest kernel.
>>
>> Now that the kernel initializes PAT table to the BIOS handoff
>> state when MTRR is disabled, this Xen-specific PAT init code
>> is no longer necessary.  Delete it from xen_start_kernel().
>>
>> Also change pat_init_cache_modes() to a static function since
>> PAT table should not be tweaked by other modules.
>>
>> Signed-off-by: Toshi Kani 
>> Cc: Konrad Rzeszutek Wilk 
>> Cc: Borislav Petkov 
>> Cc: Luis R. Rodriguez 
>> Cc: Juergen Gross 
>> Cc: Ingo Molnar 
>> Cc: H. Peter Anvin 
>> Cc: Thomas Gleixner 
>> ---
>>  arch/x86/include/asm/pat.h |1 -
>>  arch/x86/mm/pat.c  |2 +-
>>  arch/x86/xen/enlighten.c   |9 -
>>  3 files changed, 1 insertion(+), 11 deletions(-)
> 
> Jürgen, ack?

Yes, seems to be okay.

Acked-by: Juergen Gross 


Juergen

[PATCH] Input: Change BTN_TOOL_FINGER falg when HOVER event trigger

[duson]

Only ABS_DISTANCE is not enough for upper OS  to distiguish hover event
be triggered from object form faraway to and close touchpad surface or from
object prepare to leave the touchpad surface. We add BNT_TOOL_FINGER to help
it.

 Object_at_faraway   
object_at_hover_area  object_touch_touchpad
 BTN_TOUCH  00  
   1
BTN_TOOL_FINGER  0   1  
1
ABS_DISTANCE  0   1 
 0

Signed-off by: Duson Lin 
---
 drivers/input/mouse/elan_i2c_core.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/input/mouse/elan_i2c_core.c 
b/drivers/input/mouse/elan_i2c_core.c
index 2f58985..9392a8c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -4,7 +4,7 @@
  * Copyright (c) 2013 ELAN Microelectronics Corp.
  *
  * Author: 林政維 (Duson Lin) 
- * Version: 1.6.0
+ * Version: 1.6.1
  *
  * Based on cyapa driver:
  * copyright (c) 2011-2012 Cypress Semiconductor, Inc.
@@ -845,23 +845,27 @@ static void elan_report_absolute(struct elan_tp_data 
*data, u8 *packet)
 {
struct input_dev *input = data->input;
u8 *finger_data = &packet[ETP_FINGER_DATA_OFFSET];
-   int i;
+   int i, valid_count = 0;
u8 tp_info = packet[ETP_TOUCH_INFO_OFFSET];
u8 hover_info = packet[ETP_HOVER_INFO_OFFSET];
bool contact_valid, hover_event;
 
-   hover_event = hover_info & 0x40;
+   hover_event = (hover_info & 0x40);
for (i = 0; i < ETP_MAX_FINGERS; i++) {
contact_valid = tp_info & (1U << (3 + i));
elan_report_contact(data, i, contact_valid, finger_data);
 
-   if (contact_valid)
+   if (contact_valid) {
finger_data += ETP_FINGER_DATA_LEN;
+   valid_count++;
+   }
}
 
input_report_key(input, BTN_LEFT, tp_info & 0x01);
+   input_report_key(input, BTN_TOOL_FINGER,
+   ((hover_event != 0) | (valid_count > 0)));
input_report_abs(input, ABS_DISTANCE, hover_event != 0);
-   input_mt_report_pointer_emulation(input, true);
+   input_mt_report_pointer_emulation(input, false);
input_sync(input);
 }
 
-- 
1.7.9.5

Re: [lustre-devel] [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

[Dilger, Andreas]

On 2016/03/22, 19:49, "lustre-devel on behalf of Greg Kroah-Hartman"
 wrote:

>On Tue, Mar 22, 2016 at 06:21:04PM -0400, James Simmons wrote:
>> Latest testing fails when using ko2iblnd. It was tracked down
>> to commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.
>> 
>> This reverts commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.
>> ---
>>  .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>>b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> index 89f9390..0d32e65 100644
>> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
>> @@ -1968,7 +1968,7 @@ static int kiblnd_net_init_pools(kib_net_t *net,
>>__u32 *cpts, int ncpts)
>>   */
>>  
>>  net->ibn_fmr_ps = cfs_percpt_alloc(lnet_cpt_table(),
>> -   sizeof(*net->ibn_fmr_ps));
>> +   sizeof(kib_fmr_poolset_t));
>
>Ok, why is this revert needed?  Please give me a big huge comment about
>why this is not the same size of the variable being assigned to it,
>otherwise someone else is going to come along and make the exact same
>change again.
>
>>  if (!net->ibn_fmr_ps) {
>>  CERROR("Failed to allocate FMR pool array\n");
>>  rc = -ENOMEM;
>> @@ -1992,7 +1992,7 @@ static int kiblnd_net_init_pools(kib_net_t *net,
>>__u32 *cpts, int ncpts)
>>  
>>   create_tx_pool:
>>  net->ibn_tx_ps = cfs_percpt_alloc(lnet_cpt_table(),
>> -  sizeof(*net->ibn_tx_ps));
>> +  sizeof(kib_tx_poolset_t));
>
>Same here, why is this code wrong?

Looks like the declarations are:

kib_tx_poolset_t**ibn_tx_ps;/* tx pool-set */
kib_fmr_poolset_t   **ibn_fmr_ps;   /* fmr pool-set */



so the right code should be:

sizeof(**net->ibn_tx_ps);


and the same for sizeof(**net->ibn_fmr_ps)

Cheers, Andreas
-- 
Andreas Dilger

Lustre Principal Architect
Intel High Performance Data Division

[PATCH] tpm_tis: drop manufacturer_id from struct tpm_vendor_specific

[Jarkko Sakkinen]

Dropped manufacturer_id from struct tpm_vendor_specific and redeclared
it in the private struct priv_data that tpm_tis uses because the field
is only used tpm_tis.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h | 2 --
 drivers/char/tpm/tpm_tis.c | 7 +--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index cbab4e9..fcd7f1e 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -145,8 +145,6 @@ struct tpm_vendor_specific {
void *priv;
 
wait_queue_head_t read_queue;
-
-   u16 manufacturer_id;
 };
 
 #define TPM_VPRIV(c) ((c)->vendor.priv)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 7d7a776..068f021 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -94,6 +94,7 @@ struct tpm_info {
 #defineTPM_RID(l)  (0x0F04 | ((l) << 12))
 
 struct priv_data {
+   u16 manufacturer_id;
bool irq_tested;
wait_queue_head_t int_queue;
 };
@@ -516,7 +517,9 @@ out:
 
 static bool tpm_tis_req_canceled(struct tpm_chip *chip, u8 status)
 {
-   switch (chip->vendor.manufacturer_id) {
+   struct priv_data *priv = chip->vendor.priv;
+
+   switch (priv->manufacturer_id) {
case TPM_VID_WINBOND:
return ((status == TPM_STS_VALID) ||
(status == (TPM_STS_VALID | TPM_STS_COMMAND_READY)));
@@ -722,7 +725,7 @@ static int tpm_tis_init(struct device *dev, struct tpm_info 
*tpm_info,
goto out_err;
 
vendor = ioread32(chip->vendor.iobase + TPM_DID_VID(0));
-   chip->vendor.manufacturer_id = vendor;
+   priv->manufacturer_id = vendor;
 
dev_info(dev, "%s TPM (device-id 0x%X, rev-id %d)\n",
 (chip->flags & TPM_CHIP_FLAG_TPM2) ? "2.0" : "1.2",
-- 
2.7.3

Re: [PATCH] tty/hvc: Use IRQF_SHARED for hvc consoles

[Stewart Smith]

Samuel Mendoza-Jonas  writes:
> Commit 2def86a7200c
> ("hvc: Convert to using interrupts instead of opal events")
> enabled the use of interrupts in the hvc_driver for OPAL platforms.
> However on machines with more than one hvc console, any console after
> the first will fail to register an interrupt handler in
> notifier_add_irq() since all consoles share the same IRQ number but do
> not set the IRQF_SHARED flag:
>
> [   51.179907] genirq: Flags mismatch irq 31.  (hvc_console) vs.
>  (hvc_console)
> [   51.180010] hvc_open: request_irq failed with rc -16.
>
> This error propagates up to hvc_open() and the console is closed, but
> OPAL will still generate interrupts that are not handled, leading to
> rcu_sched stall warnings.
>
> Set IRQF_SHARED when calling request_irq, allowing additional consoles
> to start properly.
>
> Signed-off-by: Samuel Mendoza-Jonas 
> Cc:  # 4.1.x-

Tested on 4.4.6 - seemed to stop (some of) the problems I was having
when using it as a kernel for the bootloader on a FSP based POWER8
system.

Tested-by: Stewart Smith 

-- 
Stewart Smith
OPAL Architect, IBM.

[PATCH] staging: dgnc: fix CamelCase in dgnc_driver.c

[Daeseok Youn]

fix checkpatch.pl warning about CamelCase.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_driver.c | 52 +++---
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.c 
b/drivers/staging/dgnc/dgnc_driver.c
index 4eb410e..af2e835 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -48,7 +48,7 @@ static void   dgnc_do_remap(struct dgnc_board *brd);
 /*
  * File operations permitted on Control/Management major.
  */
-static const struct file_operations dgnc_BoardFops = {
+static const struct file_operations dgnc_board_fops = {
.owner  =   THIS_MODULE,
.unlocked_ioctl =   dgnc_mgmt_ioctl,
.open   =   dgnc_mgmt_open,
@@ -58,11 +58,11 @@ static const struct file_operations dgnc_BoardFops = {
 /*
  * Globals
  */
-uint   dgnc_NumBoards;
-struct dgnc_board  *dgnc_Board[MAXBOARDS];
+uint   dgnc_num_boards;
+struct dgnc_board  *dgnc_board[MAXBOARDS];
 DEFINE_SPINLOCK(dgnc_global_lock);
 DEFINE_SPINLOCK(dgnc_poll_lock); /* Poll scheduling lock */
-uint   dgnc_Major;
+uint   dgnc_major;
 intdgnc_poll_tick = 20;/* Poll interval - 20 ms */
 
 /*
@@ -92,7 +92,7 @@ struct board_id {
unsigned int is_pci_express;
 };
 
-static struct board_id dgnc_Ids[] = {
+static struct board_id dgnc_ids[] = {
{   PCI_DEVICE_CLASSIC_4_PCI_NAME,  4,  0   },
{   PCI_DEVICE_CLASSIC_4_422_PCI_NAME,  4,  0   },
{   PCI_DEVICE_CLASSIC_8_PCI_NAME,  8,  0   },
@@ -140,14 +140,14 @@ static void cleanup(bool sysfiles)
if (sysfiles)
dgnc_remove_driver_sysfiles(&dgnc_driver);
 
-   device_destroy(dgnc_class, MKDEV(dgnc_Major, 0));
+   device_destroy(dgnc_class, MKDEV(dgnc_major, 0));
class_destroy(dgnc_class);
-   unregister_chrdev(dgnc_Major, "dgnc");
+   unregister_chrdev(dgnc_major, "dgnc");
 
-   for (i = 0; i < dgnc_NumBoards; ++i) {
-   dgnc_remove_ports_sysfiles(dgnc_Board[i]);
-   dgnc_tty_uninit(dgnc_Board[i]);
-   dgnc_cleanup_board(dgnc_Board[i]);
+   for (i = 0; i < dgnc_num_boards; ++i) {
+   dgnc_remove_ports_sysfiles(dgnc_board[i]);
+   dgnc_tty_uninit(dgnc_board[i]);
+   dgnc_cleanup_board(dgnc_board[i]);
}
 
dgnc_tty_post_uninit();
@@ -217,12 +217,12 @@ static int dgnc_start(void)
 *
 * Register management/dpa devices
 */
-   rc = register_chrdev(0, "dgnc", &dgnc_BoardFops);
+   rc = register_chrdev(0, "dgnc", &dgnc_board_fops);
if (rc < 0) {
pr_err(DRVSTR ": Can't register dgnc driver device (%d)\n", rc);
return rc;
}
-   dgnc_Major = rc;
+   dgnc_major = rc;
 
dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt");
if (IS_ERR(dgnc_class)) {
@@ -232,7 +232,7 @@ static int dgnc_start(void)
}
 
dev = device_create(dgnc_class, NULL,
-   MKDEV(dgnc_Major, 0),
+   MKDEV(dgnc_major, 0),
NULL, "dgnc_mgmt");
if (IS_ERR(dev)) {
rc = PTR_ERR(dev);
@@ -262,11 +262,11 @@ static int dgnc_start(void)
return 0;
 
 failed_tty:
-   device_destroy(dgnc_class, MKDEV(dgnc_Major, 0));
+   device_destroy(dgnc_class, MKDEV(dgnc_major, 0));
 failed_device:
class_destroy(dgnc_class);
 failed_class:
-   unregister_chrdev(dgnc_Major, "dgnc");
+   unregister_chrdev(dgnc_major, "dgnc");
return rc;
 }
 
@@ -283,7 +283,7 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
rc = dgnc_found_board(pdev, ent->driver_data);
if (rc == 0)
-   dgnc_NumBoards++;
+   dgnc_num_boards++;
 
return rc;
 }
@@ -346,7 +346,7 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
}
}
 
-   dgnc_Board[brd->boardnum] = NULL;
+   dgnc_board[brd->boardnum] = NULL;
 
kfree(brd);
 }
@@ -365,8 +365,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
unsigned long flags;
 
/* get the board structure and prep it */
-   dgnc_Board[dgnc_NumBoards] = kzalloc(sizeof(*brd), GFP_KERNEL);
-   brd = dgnc_Board[dgnc_NumBoards];
+   dgnc_board[dgnc_num_boards] = kzalloc(sizeof(*brd), GFP_KERNEL);
+   brd = dgnc_board[dgnc_num_boards];
 
if (!brd)
return -ENOMEM;
@@ -382,15 +382,15 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
 
/* store the info for the board we've found */
brd->magic = DGNC_BOARD_MAGIC;
-   brd->boardnum = dgnc_NumBoards;
+   brd->boardnum = dgnc_num_boards;
brd->vendor = dgnc_

Re: [PATCH 0/3] Remaining fixes for v4.5 (post tpmdd-next-20160120)

[Jarkko Sakkinen]

On Wed, Mar 23, 2016 at 07:09:24AM +0200, Jarkko Sakkinen wrote:
> Fixes remaining after tpmdd-next-20160120 has been pulled and API change
> so that session object stays intact after a successful unseal operation.

Oops. Please ignore this, did a mistake with git send-email. Sorry about
this.

/Jarkko

> Harald Hoyer (1):
>   tpm_eventlog.c: fix binary_bios_measurements
> 
> Jarkko Sakkinen (2):
>   tpm: fix: keep auth session intact after unseal operation
>   tpm: fix: return rc when devm_add_action() fails
> 
>  drivers/char/tpm/tpm-chip.c |  7 ++-
>  drivers/char/tpm/tpm2-cmd.c | 10 +++---
>  drivers/char/tpm/tpm_eventlog.c | 10 --
>  3 files changed, 21 insertions(+), 6 deletions(-)
> 
> -- 
> 2.7.0
> 

[PATCH] tpm_atmel: drop tpm_atmel specific fields from tpm_vendor_specific

[Jarkko Sakkinen]

Introduced a private struct tpm_atmel_priv that contains the variables
have_region and region_size that were previously located in struct
tpm_vendor_specific. These fields were only used by tpm_atmel.

Signed-off-by: Jarkko Sakkinen 
---
 drivers/char/tpm/tpm.h   |  3 ---
 drivers/char/tpm/tpm_atmel.c | 23 +++
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 4764545..cbab4e9 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -136,9 +136,6 @@ struct tpm_vendor_specific {
 
int irq;
 
-   int region_size;
-   int have_region;
-
struct list_head list;
int locality;
unsigned long timeout_a, timeout_b, timeout_c, timeout_d; /* jiffies */
diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index a48a878..affc04b 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -35,6 +35,11 @@ enum tpm_atmel_read_status {
ATML_STATUS_READY = 0x08
 };
 
+struct tpm_atmel_priv {
+   int region_size;
+   int have_region;
+};
+
 static int tpm_atml_recv(struct tpm_chip *chip, u8 *buf, size_t count)
 {
u8 status, *hdr = buf;
@@ -136,12 +141,13 @@ static struct platform_device *pdev;
 static void atml_plat_remove(void)
 {
struct tpm_chip *chip = dev_get_drvdata(&pdev->dev);
+   struct tpm_atmel_priv *priv = chip->vendor.priv;
 
if (chip) {
tpm_chip_unregister(chip);
-   if (chip->vendor.have_region)
+   if (priv->have_region)
atmel_release_region(chip->vendor.base,
-chip->vendor.region_size);
+priv->region_size);
atmel_put_base_addr(chip->vendor.iobase);
platform_device_unregister(pdev);
}
@@ -163,6 +169,7 @@ static int __init init_atmel(void)
int have_region, region_size;
unsigned long base;
struct  tpm_chip *chip;
+   struct tpm_atmel_priv *priv;
 
rc = platform_driver_register(&atml_drv);
if (rc)
@@ -183,6 +190,15 @@ static int __init init_atmel(void)
goto err_rel_reg;
}
 
+   priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv) {
+   rc = -ENOMEM;
+   goto err_unreg_dev;
+   }
+
+   priv->have_region = have_region;
+   priv->region_size = region_size;
+
chip = tpmm_chip_alloc(&pdev->dev, &tpm_atmel);
if (IS_ERR(chip)) {
rc = PTR_ERR(chip);
@@ -191,8 +207,7 @@ static int __init init_atmel(void)
 
chip->vendor.iobase = iobase;
chip->vendor.base = base;
-   chip->vendor.have_region = have_region;
-   chip->vendor.region_size = region_size;
+   chip->vendor.priv = priv;
 
rc = tpm_chip_register(chip);
if (rc)
-- 
2.7.3

[PATCH 0/3] Remaining fixes for v4.5 (post tpmdd-next-20160120)

[Jarkko Sakkinen]

Fixes remaining after tpmdd-next-20160120 has been pulled and API change
so that session object stays intact after a successful unseal operation.

Harald Hoyer (1):
  tpm_eventlog.c: fix binary_bios_measurements

Jarkko Sakkinen (2):
  tpm: fix: keep auth session intact after unseal operation
  tpm: fix: return rc when devm_add_action() fails

 drivers/char/tpm/tpm-chip.c |  7 ++-
 drivers/char/tpm/tpm2-cmd.c | 10 +++---
 drivers/char/tpm/tpm_eventlog.c | 10 --
 3 files changed, 21 insertions(+), 6 deletions(-)

-- 
2.7.0

Re: [PATCH v2 13/18] mm/compaction: support non-lru movable page migration

[Joonsoo Kim]

On Tue, Mar 22, 2016 at 11:55:45PM +0900, Minchan Kim wrote:
> On Tue, Mar 22, 2016 at 02:50:37PM +0900, Joonsoo Kim wrote:
> > On Mon, Mar 21, 2016 at 03:31:02PM +0900, Minchan Kim wrote:
> > > We have allowed migration for only LRU pages until now and it was
> > > enough to make high-order pages. But recently, embedded system(e.g.,
> > > webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
> > > so we have seen several reports about troubles of small high-order
> > > allocation. For fixing the problem, there were several efforts
> > > (e,g,. enhance compaction algorithm, SLUB fallback to 0-order page,
> > > reserved memory, vmalloc and so on) but if there are lots of
> > > non-movable pages in system, their solutions are void in the long run.
> > > 
> > > So, this patch is to support facility to change non-movable pages
> > > with movable. For the feature, this patch introduces functions related
> > > to migration to address_space_operations as well as some page flags.
> > > 
> > > Basically, this patch supports two page-flags and two functions related
> > > to page migration. The flag and page->mapping stability are protected
> > > by PG_lock.
> > > 
> > >   PG_movable
> > >   PG_isolated
> > > 
> > >   bool (*isolate_page) (struct page *, isolate_mode_t);
> > >   void (*putback_page) (struct page *);
> > > 
> > > Duty of subsystem want to make their pages as migratable are
> > > as follows:
> > > 
> > > 1. It should register address_space to page->mapping then mark
> > > the page as PG_movable via __SetPageMovable.
> > > 
> > > 2. It should mark the page as PG_isolated via SetPageIsolated
> > > if isolation is sucessful and return true.
> > > 
> > > 3. If migration is successful, it should clear PG_isolated and
> > > PG_movable of the page for free preparation then release the
> > > reference of the page to free.
> > > 
> > > 4. If migration fails, putback function of subsystem should
> > > clear PG_isolated via ClearPageIsolated.
> > 
> > I think that this feature needs a separate document to describe
> > requirement of each step in more detail. For example, #1 can be
> > possible without holding a lock? I'm not sure because you lock
> > the page when implementing zsmalloc page migration in 15th patch.
> 
> Yes, we needs PG_lock because install page->mapping and PG_movable
> should be atomic and PG_lock protects it.
> 
> Better interface might be
> 
> void __SetPageMovable(struct page *page, sruct address_space *mapping);
> 
> > 
> > #3 also need more explanation. Before release, we need to
> > unregister address_space. I guess that it needs to be done
> > in migratepage() but there is no explanation.
> 
> Okay, we can unregister address_space in __ClearPageMovable.
> I will change it.
> 
> > 
> > > 
> > > Cc: Vlastimil Babka 
> > > Cc: Mel Gorman 
> > > Cc: Hugh Dickins 
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: virtualizat...@lists.linux-foundation.org
> > > Signed-off-by: Gioh Kim 
> > > Signed-off-by: Minchan Kim 
> > > ---
> > >  Documentation/filesystems/Locking  |   4 +
> > >  Documentation/filesystems/vfs.txt  |   5 ++
> > >  fs/proc/page.c |   3 +
> > >  include/linux/fs.h |   2 +
> > >  include/linux/migrate.h|   2 +
> > >  include/linux/page-flags.h |  29 
> > >  include/uapi/linux/kernel-page-flags.h |   1 +
> > >  mm/compaction.c|  14 +++-
> > >  mm/migrate.c   | 132 
> > > +
> > >  9 files changed, 177 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/Documentation/filesystems/Locking 
> > > b/Documentation/filesystems/Locking
> > > index 619af9bfdcb3..0bb79560abb3 100644
> > > --- a/Documentation/filesystems/Locking
> > > +++ b/Documentation/filesystems/Locking
> > > @@ -195,7 +195,9 @@ unlocks and drops the reference.
> > >   int (*releasepage) (struct page *, int);
> > >   void (*freepage)(struct page *);
> > >   int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
> > > + bool (*isolate_page) (struct page *, isolate_mode_t);
> > >   int (*migratepage)(struct address_space *, struct page *, struct page 
> > > *);
> > > + void (*putback_page) (struct page *);
> > >   int (*launder_page)(struct page *);
> > >   int (*is_partially_uptodate)(struct page *, unsigned long, unsigned 
> > > long);
> > >   int (*error_remove_page)(struct address_space *, struct page *);
> > > @@ -219,7 +221,9 @@ invalidatepage:   yes
> > >  releasepage: yes
> > >  freepage:yes
> > >  direct_IO:
> > > +isolate_page:yes
> > >  migratepage: yes (both)
> > > +putback_page:yes
> > >  launder_page:yes
> > >  is_partially_uptodate:   yes
> > >  error_remove_page:   yes
> > > diff --git a/Documentation/filesystems/vfs.txt 
> > > b/Documentation/filesystems/vfs.txt
> > > index b02a7d598258..4c1b6c3b4bc8 100644

Re: [RFC 2/2] staging: android: ion: Add of_ion_device_get function

[Dan Carpenter]

On Tue, Mar 22, 2016 at 03:33:51PM -0700, Moritz Fischer wrote:
> +struct ion_device *of_ion_device_get(struct device_node *node)
> +{
> + struct miscdevice *mdev = of_misc_get(node);
> +
> + if (IS_ERR(mdev))
> + return ERR_PTR(PTR_ERR(mdev));

Use ERR_CAST() for this.

regarda,
dan carpenter

Re: rcu stalls and soft lockups with recent kernels

[Mike Galbraith]

(cc)

On Tue, 2016-03-22 at 16:22 -0400, Ion Badulescu wrote:
> On 03/17/2016 10:28 PM, Mike Galbraith wrote:
> > On Wed, 2016-03-16 at 12:15 -0400, Ion Badulescu wrote:
> > > Just following up to my own email:
> > > 
> > > It turns out that we can eliminate the RCU stalls by changing from
> > > CONFIG_RCU_NOCB_CPU_ALL to CONFIG_RCU_NOCB_CPU_NONE. Letting each cpu
> > > handle its own RCU callbacks completely fixes the problems for us.
> > > 
> > > Now, CONFIG_NO_HZ_FULL and CONFIG_RCU_NOCB_CPU_ALL is the default config
> > > for fedora and rhel7. Ho-humm...
> > 
> > All RCU offloaded to CPU0 of a big box seems like a very bad idea.
> 
> 
> It's not offloaded to CPU0, is it? Those rcuo* threads are not cpu-bound 
> and can run on any cpu the scheduler will put them on. In any case, 
> there was no indication that the rcuo* threads wanted to run but 
> couldn't get cpu time.

Right, my thinker was screwed on cross-threaded.

> Anyway, looks like I spoke too soon. It's less often with 
> RCU_NOCB_CPU_NONE than with RCU_NOCB_CPU_ALL, but the soft lockups and 
> rcu stalls are still happening.
> 
> [44206.316711] clocksource: timekeeping watchdog: Marking clocksource 
> 'tsc' as unstable because the skew is too large:
> [44206.328463] clocksource:   'hpet' wd_now: 
>  wd_last: 5f03cdca mask: 
> [44206.339037] clocksource:   'tsc' cs_now: 
> 64788b443c3a cs_last: 647840eea919 mask: 
> [44206.351253] clocksource: Switched to clocksource hpet
> [44922.301452] INFO: rcu_sched detected stalls on CPUs/tasks:
> [44922.307644]  0-...: (1 GPs behind) idle=53d/141/0 
> softirq=8515474/8515477 fqs=6994
> [44922.317435]  (detected by 1, t=21019 jiffies, g=2011397, c=2011396, 
> q=3263)
> [44922.325274] Task dump for CPU 0:
> [44922.325276] python  R  running task0 257113 257112 
> 0x00080088   0 FAIR10   15229448373
> [44922.325283]  8152ca8e 881b7687 880e83669000 
> 7d54
> [44922.333671]  881b1cdc7a48 880a58a57e58 0086 
> 
> [44922.342060]   3fa1 880a58a54000 
> 880a58a57e88
> [44922.350446] Call Trace:
> [44922.353215]  [] ? __schedule+0x38e/0xa90
> [44922.359388]  [] ? rcu_eqs_enter_common+0x66/0x130
> [44922.366437]  [] ? acct_account_cputime+0x1c/0x20
> [44922.373388]  [] ? account_user_time+0x78/0x80
> [44922.380045]  [] ? vtime_account_user+0x43/0x60
> [44922.386801]  [] ? __context_tracking_exit+0x70/0xc0
> [44922.394044]  [] ? enter_from_user_mode+0x1f/0x50
> [44922.400994]  [] ? apic_timer_interrupt+0x69/0x90
> [44923.210453] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s! 
> [python:257113]
> [44923.218890] Modules linked in: nfsv3 nfs_acl nfs msr autofs4 lockd 
> grace sunrpc cachefiles fscache binfmt_misc nls_iso8859_1 nls_cp437 vfat 
> fat vhost_net vhost tun kvm irqbypass input_leds hid_generic iTCO_wdt 
> iTCO_vendor_support pcspkr sfc mtd i2c_algo_bit sb_edac sg l
> pc_ich mfd_core ehci_pci ehci_hcd xhci_pci xhci_hcd i2c_i801 i2c_core 
> ixgbe ptp pps_core mdio ipmi_devintf ipmi_si ipmi_msghandler tpm_tis tpm 
> acpi_power_meter hwmon ext4 jbd2 mbcache crc16 raid1 dm_mirror 
> dm_region_hash dm_log dm_mod
> [44923.269289] CPU: 0 PID: 257113 Comm: python Tainted: G  I 
> 4.4.5-el6.ia32e.lime.0 #1
> [44923.279089] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS 
> SE5C610.86B.01.01.0011.081020151200 08/10/2015
> [44923.290824] task: 880e83669000 ti: 880a58a54000 task.ti: 
> 880a58a54000
> [44923.299253] RIP: 0033:[<2b5ee4e0502d>]  [<2b5ee4e0502d>] 
> 0x2b5ee4e0502d
> [44923.307508] RSP: 002b:7ffe4120b170  EFLAGS: 0212
> [44923.313494] RAX: 0008 RBX: 03fe1480 RCX: 
> 03fc9b00
> [44923.321513] RDX: 2b5ee34b4260 RSI: 2248 RDI: 
> 00d4
> [44923.329530] RBP: 03fe1800 R08: 0078 R09: 
> 0800
> [44923.337548] R10: 7ffe4120b550 R11: 00011240 R12: 
> 2b5ee34ba938
> [44923.345566] R13: 2b5ee34c1010 R14: 7ffe4120b428 R15: 
> 0400
> [44923.353580] FS:  2b5ec7fe98c0() GS:88103fc0() 
> knlGS:
> [44923.362689] CS:  0010 DS:  ES:  CR0: 80050033
> [44923.369147] CR2: 2b5ee419 CR3: 0005ac81b000 CR4: 
> 001406f0
> 
> That rcu_eqs_enter_common function seems to be a fairly common 
> occurrence in these stack traces. Not sure if it means anything, though.
> 
> Also, this seems to be a sock lockup with RIP in userspace. Does it mean 
> timer interrupts are disabled? Somehow it fails to reschedule the NMI timer.
> 
> We're at our wits' end here...
> 
> This, btw, is a 2x12 core Haswell box.
> 
> Thanks,
> -Ion

Re: [PATCH] zram: revive swap_slot_free_notify

[Joonsoo Kim]

On Tue, Mar 22, 2016 at 11:06:29PM +0900, Minchan Kim wrote:
> On Tue, Mar 22, 2016 at 05:20:08PM +0900, Joonsoo Kim wrote:
> > 2016-03-22 17:00 GMT+09:00 Minchan Kim :
> > > On Tue, Mar 22, 2016 at 02:08:59PM +0900, Joonsoo Kim wrote:
> > >> On Fri, Mar 18, 2016 at 04:58:31PM +0900, Minchan Kim wrote:
> > >> >  "remove compressed copy from zram in-memory"
> > >> > applied swap_slot_free_notify call in *end_swap_bio_read* to
> > >> > remove duplicated memory between zram and memory.
> > >> >
> > >> > However, with introducing rw_page in zram <8c7f01025f7b>
> > >> > "zram: implement rw_page operation of zram", it became void
> > >> > because rw_page doesn't need bio.
> > >> >
> > >> > This patch restores the function for rw_page.
> > >> >
> > >> > Signed-off-by: Minchan Kim 
> > >> > ---
> > >> >  mm/page_io.c | 93 
> > >> > 
> > >> >  1 file changed, 50 insertions(+), 43 deletions(-)
> > >> >
> > >> > diff --git a/mm/page_io.c b/mm/page_io.c
> > >> > index ff74e512f029..18aac7819cc9 100644
> > >> > --- a/mm/page_io.c
> > >> > +++ b/mm/page_io.c
> > >> > @@ -66,6 +66,54 @@ void end_swap_bio_write(struct bio *bio)
> > >> > bio_put(bio);
> > >> >  }
> > >> >
> > >> > +static void swap_slot_free_notify(struct page *page)
> > >> > +{
> > >> > +   struct swap_info_struct *sis;
> > >> > +   struct gendisk *disk;
> > >> > +
> > >> > +   /*
> > >> > +* There is no guarantee that the page is in swap cache - the 
> > >> > software
> > >> > +* suspend code (at least) uses end_swap_bio_read() against a non-
> > >> > +* swapcache page.  So we must check PG_swapcache before 
> > >> > proceeding with
> > >> > +* this optimization.
> > >> > +*/
> > >> > +   if (unlikely(!PageSwapCache(page)))
> > >> > +   return;
> > >> > +
> > >> > +   sis = page_swap_info(page);
> > >> > +   if (!(sis->flags & SWP_BLKDEV))
> > >> > +   return;
> > >> > +
> > >> > +   /*
> > >> > +* The swap subsystem performs lazy swap slot freeing,
> > >> > +* expecting that the page will be swapped out again.
> > >> > +* So we can avoid an unnecessary write if the page
> > >> > +* isn't redirtied.
> > >> > +* This is good for real swap storage because we can
> > >> > +* reduce unnecessary I/O and enhance wear-leveling
> > >> > +* if an SSD is used as the as swap device.
> > >> > +* But if in-memory swap device (eg zram) is used,
> > >> > +* this causes a duplicated copy between uncompressed
> > >> > +* data in VM-owned memory and compressed data in
> > >> > +* zram-owned memory.  So let's free zram-owned memory
> > >> > +* and make the VM-owned decompressed page *dirty*,
> > >> > +* so the page should be swapped out somewhere again if
> > >> > +* we again wish to reclaim it.
> > >> > +*/
> > >> > +   disk = sis->bdev->bd_disk;
> > >> > +   if (disk->fops->swap_slot_free_notify) {
> > >> > +   swp_entry_t entry;
> > >> > +   unsigned long offset;
> > >> > +
> > >> > +   entry.val = page_private(page);
> > >> > +   offset = swp_offset(entry);
> > >> > +
> > >> > +   SetPageDirty(page);
> > >> > +   disk->fops->swap_slot_free_notify(sis->bdev,
> > >> > +   offset);
> > >> > +   }
> > >> > +}
> > >> > +
> > >> >  static void end_swap_bio_read(struct bio *bio)
> > >> >  {
> > >> > struct page *page = bio->bi_io_vec[0].bv_page;
> > >> > @@ -81,49 +129,7 @@ static void end_swap_bio_read(struct bio *bio)
> > >> > }
> > >> >
> > >> > SetPageUptodate(page);
> > >> > -
> > >> > -   /*
> > >> > -* There is no guarantee that the page is in swap cache - the 
> > >> > software
> > >> > -* suspend code (at least) uses end_swap_bio_read() against a non-
> > >> > -* swapcache page.  So we must check PG_swapcache before 
> > >> > proceeding with
> > >> > -* this optimization.
> > >> > -*/
> > >> > -   if (likely(PageSwapCache(page))) {
> > >> > -   struct swap_info_struct *sis;
> > >> > -
> > >> > -   sis = page_swap_info(page);
> > >> > -   if (sis->flags & SWP_BLKDEV) {
> > >> > -   /*
> > >> > -* The swap subsystem performs lazy swap slot 
> > >> > freeing,
> > >> > -* expecting that the page will be swapped out 
> > >> > again.
> > >> > -* So we can avoid an unnecessary write if the page
> > >> > -* isn't redirtied.
> > >> > -* This is good for real swap storage because we 
> > >> > can
> > >> > -* reduce unnecessary I/O and enhance wear-leveling
> > >> > -* if an SSD is used as the as swap device.
> > >> > -* But if in-memory swap device (eg zram) is used,
> > >> > -* this causes a duplicated copy between 
> > >> > uncompressed
> > >> > -* data in VM-owned memory and comp

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

On Fri, Mar 18, 2016 at 03:10:09PM +0100, Vlastimil Babka wrote:
> On 03/17/2016 04:52 PM, Joonsoo Kim wrote:
> > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka :
> >>
> >> Okay. I used following slightly optimized version and I need to
> >> add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1)'
> >> to yours. Please consider it, too.
> >
> > Hmm, this one is not work, I still can see the bug is there after
> > applying
> > this patch, did I miss something?
> 
>  I may find that there is a bug which was introduced by me some time
>  ago. Could you test following change in __free_one_page() on top of
>  Vlastimil's patch?
> 
>  -page_idx = pfn & ((1 << max_order) - 1);
>  +page_idx = pfn & ((1 << MAX_ORDER) - 1);
> >>>
> >>>
> >>> I tested Vlastimil's patch + your change with stress for more than half
> >>> hour, the bug
> >>> I reported is gone :)
> >>
> >>
> >> Oh, ok, will try to send proper patch, once I figure out what to write in
> >> the changelog :)
> > 
> > Thanks in advance!
> > 
> 
> OK, here it is. Hanjun can you please retest this, as I'm not sure if you had
> the same code due to the followup one-liner patches in the thread. Lucas, see 
> if
> it helps with your issue as well. Laura and Joonsoo, please also test and 
> review
> and check changelog if my perception of the problem is accurate :)
> 
> Thanks
> 
> 8<
> From: Vlastimil Babka 
> Date: Fri, 18 Mar 2016 14:22:31 +0100
> Subject: [PATCH] mm/page_alloc: prevent merging between isolated and other
>  pageblocks
> 
> Hanjun Guo has reported that a CMA stress test causes broken accounting of
> CMA and free pages:
> 
> > Before the test, I got:
> > -bash-4.3# cat /proc/meminfo | grep Cma
> > CmaTotal: 204800 kB
> > CmaFree:  195044 kB
> >
> >
> > After running the test:
> > -bash-4.3# cat /proc/meminfo | grep Cma
> > CmaTotal: 204800 kB
> > CmaFree: 6602584 kB
> >
> > So the freed CMA memory is more than total..
> >
> > Also the the MemFree is more than mem total:
> >
> > -bash-4.3# cat /proc/meminfo
> > MemTotal:   16342016 kB
> > MemFree:22367268 kB
> > MemAvailable:   22370528 kB
> 
> Laura Abbott has confirmed the issue and suspected the freepage accounting
> rewrite around 3.18/4.0 by Joonsoo Kim. Joonsoo had a theory that this is
> caused by unexpected merging between MIGRATE_ISOLATE and MIGRATE_CMA
> pageblocks:
> 
> > CMA isolates MAX_ORDER aligned blocks, but, during the process,
> > partialy isolated block exists. If MAX_ORDER is 11 and
> > pageblock_order is 9, two pageblocks make up MAX_ORDER
> > aligned block and I can think following scenario because pageblock
> > (un)isolation would be done one by one.
> >
> > (each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
> > MIGRATE_ISOLATE, respectively.
> >
> > CC -> IC -> II (Isolation)
> > II -> CI -> CC (Un-isolation)
> >
> > If some pages are freed at this intermediate state such as IC or CI,
> > that page could be merged to the other page that is resident on
> > different type of pageblock and it will cause wrong freepage count.
> 
> This was supposed to be prevented by CMA operating on MAX_ORDER blocks, but
> since it doesn't hold the zone->lock between pageblocks, a race window does
> exist.
> 
> It's also likely that unexpected merging can occur between MIGRATE_ISOLATE
> and non-CMA pageblocks. This should be prevented in __free_one_page() since
> commit 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated
> pageblock"). However, we only check the migratetype of the pageblock where
> buddy merging has been initiated, not the migratetype of the buddy pageblock
> (or group of pageblocks) which can be MIGRATE_ISOLATE.
> 
> Joonsoo has suggested checking for buddy migratetype as part of
> page_is_buddy(), but that would add extra checks in allocator hotpath and
> bloat-o-meter has shown significant code bloat (the function is inline).
> 
> This patch reduces the bloat at some expense of more complicated code. The
> buddy-merging while-loop in __free_one_page() is initially bounded to
> pageblock_border and without any migratetype checks. The checks are placed
> outside, bumping the max_order if merging is allowed, and returning to the
> while-loop with a statement which can't be possibly considered harmful.
> 
> This fixes the accounting bug and also removes the arguably weird state in the
> original commit 3c605096d315 where buddies could be left unmerged.
> 
> Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on 
> isolated pageblock")
> Link: https://lkml.org/lkml/2016/3/2/280
> Reported-by: Hanjun Guo 
> Debugged-by: Laura Abbott 
> Debugged-by: Joonsoo Kim 
> Signed-off-by: Vlastimil Babka 
> Cc:  # 3.18+
> ---
>  mm/page_alloc.c | 46 +-
>  1 file changed, 33 insertions(+), 13 deletions(-)

Acked-by: Joonsoo Kim 

Thanks for taking care of this issue!.

Thanks.

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

On Tue, Mar 22, 2016 at 03:56:46PM +0100, Lucas Stach wrote:
> Am Montag, den 21.03.2016, 13:42 +0900 schrieb Joonsoo Kim:
> > On Fri, Mar 18, 2016 at 02:32:35PM +0100, Lucas Stach wrote:
> > > Hi Vlastimil, Joonsoo,
> > > 
> > > Am Freitag, den 18.03.2016, 00:52 +0900 schrieb Joonsoo Kim:
> > > > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka :
> > > > > On 03/17/2016 10:24 AM, Hanjun Guo wrote:
> > > > >>
> > > > >> On 2016/3/17 14:54, Joonsoo Kim wrote:
> > > > >>>
> > > > >>> On Wed, Mar 16, 2016 at 05:44:28PM +0800, Hanjun Guo wrote:
> > > > 
> > > >  On 2016/3/14 15:18, Joonsoo Kim wrote:
> > > > >
> > > > > On Mon, Mar 14, 2016 at 08:06:16AM +0100, Vlastimil Babka wrote:
> > > > >>
> > > > >> On 03/14/2016 07:49 AM, Joonsoo Kim wrote:
> > > > >>>
> > > > >>> On Fri, Mar 11, 2016 at 06:07:40PM +0100, Vlastimil Babka wrote:
> > > > 
> > > >  On 03/11/2016 04:00 PM, Joonsoo Kim wrote:
> > > > 
> > > >  How about something like this? Just and idea, probably buggy
> > > >  (off-by-one etc.).
> > > >  Should keep away cost from  > > >  expense of the
> > > >  relatively fewer >pageblock_order iterations.
> > > > >>>
> > > > >>> Hmm... I tested this and found that it's code size is a little 
> > > > >>> bit
> > > > >>> larger than mine. I'm not sure why this happens exactly but I 
> > > > >>> guess
> > > > >>> it would be
> > > > >>> related to compiler optimization. In this case, I'm in favor of 
> > > > >>> my
> > > > >>> implementation because it looks like well abstraction. It adds 
> > > > >>> one
> > > > >>> unlikely branch to the merge loop but compiler would optimize 
> > > > >>> it to
> > > > >>> check it once.
> > > > >>
> > > > >> I would be surprised if compiler optimized that to check it 
> > > > >> once, as
> > > > >> order increases with each loop iteration. But maybe it's smart
> > > > >> enough to do something like I did by hand? Guess I'll check the
> > > > >> disassembly.
> > > > >
> > > > > Okay. I used following slightly optimized version and I need to
> > > > > add 'max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 
> > > > > 1)'
> > > > > to yours. Please consider it, too.
> > > > 
> > > >  Hmm, this one is not work, I still can see the bug is there after
> > > >  applying
> > > >  this patch, did I miss something?
> > > > >>>
> > > > >>> I may find that there is a bug which was introduced by me some time
> > > > >>> ago. Could you test following change in __free_one_page() on top of
> > > > >>> Vlastimil's patch?
> > > > >>>
> > > > >>> -page_idx = pfn & ((1 << max_order) - 1);
> > > > >>> +page_idx = pfn & ((1 << MAX_ORDER) - 1);
> > > > >>
> > > > >>
> > > > >> I tested Vlastimil's patch + your change with stress for more than 
> > > > >> half
> > > > >> hour, the bug
> > > > >> I reported is gone :)
> > > > >
> > > > >
> > > > > Oh, ok, will try to send proper patch, once I figure out what to 
> > > > > write in
> > > > > the changelog :)
> > > > 
> > > > Thanks in advance!
> > > 
> > > After digging into the "PFN busy" race in CMA (see [1]), I believe we
> > > should just prevent any buddy merging in isolated ranges. This fixes the
> > > race I'm seeing without the need to hold the zone lock for extend
> > > periods of time.
> > 
> > "PFNs busy" can be caused by other type of race, too. I guess that
> > other cases happens more than buddy merging. Do you have any test case for
> > your problem?
> > 
> I don't have any specific test case, but the etnaviv driver manages to
> hit this race quite often. That's because we allocate/free a large
> number of relatively small buffer from CMA, where allocation and free
> regularly happen on different CPUs.
> 
> So while we also have cases where the "PFN busy" is triggered by other
> factors, like pages locked for get_user_pages(), this race is the number
> one source of CMA retries in my workload.
> 
> > If it is indeed a problem, you can avoid it with simple retry
> > MAX_ORDER times on alloc_contig_range(). This is a rather dirty but
> > the reason I suggest it is that there are other type of race in
> > __alloc_contig_range() and retry could help them, too. For example,
> > if some of pages in the requested range isn't attached to the LRU yet
> > or detached from the LRU but not freed to buddy,
> > test_pages_isolated() can be failed.
> 
> While a retry makes sense (if at all just to avoid a CMA allocation
> failure under CMA pressure), I would like to avoid the associated
> overhead for the common path where CMA is just racing with itself. The
> retry should only be needed in situations where we don't have any means
> to control the race, like a concurrent GUP.

Make sense. When I tried to fix merging issue previously, I worried
about side-effect of unmerged buddy so I tried to reduce unmerged
buddy as much as possible. But,

Re: [PATCH v2] cpufreq: rockchip: add driver

[Viresh Kumar]

On 23-03-16, 10:18, Feng Xiao wrote:
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 14b1f93..1786315 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ
>   depends on ARCH_OMAP2PLUS
>   default ARCH_OMAP2PLUS
>  
> +config ARM_ROCKCHIP_CPUFREQ
> + tristate "Rockchip CPUfreq driver"

Since you are allowing it to be built as a module ...

> + depends on ARCH_ROCKCHIP && CPUFREQ_DT
> + select PM_OPP
> + help
> +   This adds the CPUFreq driver support for Rockchip SoCs.
> +   The driver will directly use cpufreq-dt driver as backend.
> +
> +   If in doubt, say N.

> +++ b/drivers/cpufreq/rockchip-cpufreq.c
> +static int __init rockchip_cpufreq_driver_init(void)
> +{
> + struct platform_device *pdev;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rockchip_compat); i++) {
> + if (of_machine_is_compatible(rockchip_compat[i])) {
> + pdev = platform_device_register_simple("cpufreq-dt",
> +-1, NULL, 0);
> + return PTR_ERR_OR_ZERO(pdev);
> + }
> + }
> +
> + return -ENODEV;
> +}
> +module_init(rockchip_cpufreq_driver_init);

You need a module exit as well to remove the device. Otherwise following
sequence will give you errors:

insmod rockchip-cpufreq.ko
rmmod rockchip-cpufreq.ko
insmod rockchip-cpufreq.ko //Errors on this..

So, either don't allow it to be built as a module or fix the module-exit path.

-- 
viresh

Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

[SeongJae Park]

On Wed, 23 Mar 2016, Vaishali Thakkar wrote:




On Wednesday 23 March 2016 04:57 AM, SeongJae Park wrote:

Hello Vaishali,


The patch looks good to me.  However, I have few trivial questions.

On Tue, 22 Mar 2016, Vaishali Thakkar wrote:


When any unsupported hugepage size is specified, 'hugepagesz=' and
'hugepages=' should be ignored during command line parsing until any
supported hugepage size is found. But currently incorrect number of
hugepages are allocated when unsupported size is specified as it fails
to ignore the 'hugepages=' command.

Test case:

Note that this is specific to x86 architecture.

Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
After boot, dmesg output shows that X number of hugepages of the size 2M
is pre-allocated instead of 0.

So, to handle such command line options, introduce new routine
hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
state when unsupported hugepagesize is found so that we can ignore the
'hugepages=' parameters after that and then reset the variable when
supported hugepage size is found.

The routine hugetlb_bad_size can be called while setting 'hugepagesz='
parameter in an architecture specific code.

Signed-off-by: Vaishali Thakkar 
Cc: Mike Kravetz 
Cc: Naoya Horiguchi 
Cc: Hillf Danton 
Cc: Michal Hocko 
Cc: Yaowei Bai 
Cc: Dominik Dingel 
Cc: Kirill A. Shutemov 
Cc: Paul Gortmaker 
Cc: Dave Hansen 
---
The patch is having 2 checkpatch.pl warnings. I have just followed
the current code to maintain consistency. If we decide to silent
these warnings then may be we should silent those warnings as well.
I am fine with any option whichever works best for everyone else.
---
include/linux/hugetlb.h |  1 +
mm/hugetlb.c| 14 +-
2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 7d953c2..e44c578 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct 
address_space *mapping,
/* arch callback */
int __init alloc_bootmem_huge_page(struct hstate *h);

+void __init hugetlb_bad_size(void);
void __init hugetlb_add_hstate(unsigned order);
struct hstate *size_to_hstate(unsigned long size);

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 06058ea..44fae6a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
static struct hstate * __initdata parsed_hstate;
static unsigned long __initdata default_hstate_max_huge_pages;
static unsigned long __initdata default_hstate_size;
+static bool __initdata parsed_valid_hugepagesz = true;

/*
 * Protects updates to hugepage_freelists, hugepage_activelist, nr_huge_pages,
@@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
subsys_initcall(hugetlb_init);

/* Should be called on processing a hugepagesz=... option */
+void __init hugetlb_bad_size(void)
+{
+parsed_valid_hugepagesz = false;
+}
+
void __init hugetlb_add_hstate(unsigned int order)
{
struct hstate *h;
@@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
unsigned long *mhp;
static unsigned long *last_mhp;

+if (!parsed_valid_hugepagesz) {
+pr_warn("hugepages = %s preceded by "
+"an unsupported hugepagesz, ignoring\n", s);


How about concatenating the format string?  `CodingStyle` now suggests to
_never_ break every user-visible strings.



As I said above, I just followed the pattern of the current code to maintain the
consistency. Probably a separate change would be good for solving all those
warnings. :)


Understood and agreed. :)





+parsed_valid_hugepagesz = true;
+return 1;
+}
/*
 * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter yet,
 * so this hugepages= parameter goes to the "default hstate".
 */
-if (!hugetlb_max_hstate)
+else if (!hugetlb_max_hstate)


Because the upper `if` statement will do `return`, above change looks not
significantly necessary.  Is this intended?



I think above change is necessary for the cases like "hugepages=X" because in 
that
case the X hugepages of the default size [like 2M for x86] should be allocated.


Looks like my poor English made some confusion, sorry.  I was just saying
about the addition of `else` in the line, not whole change.

Because the upper `if` statement that catching wrong `hugepagesz=` case
does `return`, below statements will not be executed at all in the case.
So, the result will not be changed even if the `else` is not added though
the addition of `else` may help readability for someone.
That's why I said the change (addition of `else`) looks not significantly
necessary.

If I am missing something wrong, please let me know.  Or, if this question
bothers you, just ignore it because I also know that this is just a
trivial question. ;)


Thanks,
Seong

Re: [PATCH 2/2] arch:mm: Use hugetlb_bad_size

[Hillf Danton]

> 
> Do you want me to send new version of the patchset breaking this patch in
> to separate patches?
> 
Yes.

thanks
Hillf

[PATCH v6] acpi: Issue _OSC call for native thermal interrupt handling

[Srinivas Pandruvada]

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake based systems by Intel P states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.
HWP interrupts uses thermal LVT.
Linux natively handles thermal interrupts, but in Skylake based systems
SMM will take control of thermal interrupts. This is a problem for several
reasons:
- It is freezing in BIOS when tries to handle thermal interrupt, which
will require BIOS upgrade
- With SMM handling thermal we loose all the reporting features of
Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
- Some thermal drivers like x86-package-temp driver depends on the thermal
threshold interrupts
- The HWP interrupts are useful for debugging and tuning performance

So we need native handling of thermal interrupts. This requires some
way to inform SMM that OS can handle thermal interrupts. This can be
done by using _OSC/_PDC under processor scope very early in ACPI
initialization flow.
The bit 12 of _OSC/_PDC in processor scope defines whether OS supports
handling of native interrupts for Collaborative Processor Performance
Control (CPPC) notifications. Since HWP is a implementation of CPPC,
setting this bit is equivalent to inform SMM that OS is capable of
handling thermal interrupts.
Refer to this document for details on _OSC/_PDC
http://www.intel.com/content/www/us/en/standards/processor-vendor-
specific-acpi-specification.html

This change introduces a new function acpi_early_processor_set_osc(),
which walks acpi name space and finds acpi processor object and
set capability via _OSC method.

Also this change writes HWP status bits to 0 to clear any HWP status
bits in intel_thermal_interrupt().

Signed-off-by: Srinivas Pandruvada 
---
v6:
Added __init for two functions and moved dummy function to internal.h
Shortened the name of the function.

v5:
No code change. Changed commit message to explain HWP is a implementation
of CPPC.

v4:
Suggestion by Boris for removing use of intermediate variable for
clearing HWP status and using boot_cpu_has instead of static_cpu_has

v3:
- Added CONFIG_X86 around static_cpu_has() to fix compile error on
ARCH=ia64, reported by kbuild test robot
- return AE_CTRL_TERMINATE to terminate acpi name walk space, when _OSC
is set already once.
v2:
Unnecessary newline was introduced, removed that in acpi_processor.c

 arch/x86/kernel/cpu/mcheck/therm_throt.c |  3 +++
 drivers/acpi/acpi_processor.c| 44 
 drivers/acpi/bus.c   |  3 +++
 drivers/acpi/internal.h  |  6 +
 4 files changed, 56 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c 
b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 2c5aaf8..0553858 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -385,6 +385,9 @@ static void intel_thermal_interrupt(void)
 {
__u64 msr_val;
 
+   if (static_cpu_has(X86_FEATURE_HWP))
+   wrmsrl_safe(MSR_HWP_STATUS, 0);
+
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
 
/* Check for violation of core thermal thresholds*/
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6979186..ba50f46 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -491,6 +491,50 @@ static void acpi_processor_remove(struct acpi_device 
*device)
 }
 #endif /* CONFIG_ACPI_HOTPLUG_CPU */
 
+#ifdef CONFIG_X86
+static bool acpi_hwp_native_thermal_lvt_set;
+static acpi_status __init acpi_hwp_native_thermal_lvt_osc(acpi_handle handle,
+ u32 lvl,
+ void *context,
+ void **rv)
+{
+   u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
+   u32 capbuf[2];
+   struct acpi_osc_context osc_context = {
+   .uuid_str = sb_uuid_str,
+   .rev = 1,
+   .cap.length = 8,
+   .cap.pointer = capbuf,
+   };
+
+   if (acpi_hwp_native_thermal_lvt_set)
+   return AE_CTRL_TERMINATE;
+
+   capbuf[0] = 0x;
+   capbuf[1] = 0x1000; /* set bit 12 */
+
+   if (ACPI_SUCCESS(acpi_run_osc(handle, &osc_context))) {
+   acpi_hwp_native_thermal_lvt_set = true;
+   kfree(osc_context.ret.pointer);
+   }
+
+   return AE_OK;
+}
+
+void __init acpi_early_processor_set_osc(void)
+{
+   if (boot_cpu_has(X86_FEATURE_HWP)) {
+   acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX,
+   acpi_hwp_native_thermal_lvt_osc,
+   NULL, NULL, NULL);
+   acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
+acpi_hwp_native_thermal_lvt_osc,
+ 

Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

[Vaishali Thakkar]

On Wednesday 23 March 2016 04:57 AM, SeongJae Park wrote:
> Hello Vaishali,
>
>
> The patch looks good to me.  However, I have few trivial questions.
>
> On Tue, 22 Mar 2016, Vaishali Thakkar wrote:
>
>> When any unsupported hugepage size is specified, 'hugepagesz=' and
>> 'hugepages=' should be ignored during command line parsing until any
>> supported hugepage size is found. But currently incorrect number of
>> hugepages are allocated when unsupported size is specified as it fails
>> to ignore the 'hugepages=' command.
>>
>> Test case:
>>
>> Note that this is specific to x86 architecture.
>>
>> Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
>> After boot, dmesg output shows that X number of hugepages of the size 2M
>> is pre-allocated instead of 0.
>>
>> So, to handle such command line options, introduce new routine
>> hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
>> parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
>> state when unsupported hugepagesize is found so that we can ignore the
>> 'hugepages=' parameters after that and then reset the variable when
>> supported hugepage size is found.
>>
>> The routine hugetlb_bad_size can be called while setting 'hugepagesz='
>> parameter in an architecture specific code.
>>
>> Signed-off-by: Vaishali Thakkar 
>> Cc: Mike Kravetz 
>> Cc: Naoya Horiguchi 
>> Cc: Hillf Danton 
>> Cc: Michal Hocko 
>> Cc: Yaowei Bai 
>> Cc: Dominik Dingel 
>> Cc: Kirill A. Shutemov 
>> Cc: Paul Gortmaker 
>> Cc: Dave Hansen 
>> ---
>> The patch is having 2 checkpatch.pl warnings. I have just followed
>> the current code to maintain consistency. If we decide to silent
>> these warnings then may be we should silent those warnings as well.
>> I am fine with any option whichever works best for everyone else.
>> ---
>> include/linux/hugetlb.h |  1 +
>> mm/hugetlb.c| 14 +-
>> 2 files changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 7d953c2..e44c578 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct 
>> address_space *mapping,
>> /* arch callback */
>> int __init alloc_bootmem_huge_page(struct hstate *h);
>>
>> +void __init hugetlb_bad_size(void);
>> void __init hugetlb_add_hstate(unsigned order);
>> struct hstate *size_to_hstate(unsigned long size);
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 06058ea..44fae6a 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
>> static struct hstate * __initdata parsed_hstate;
>> static unsigned long __initdata default_hstate_max_huge_pages;
>> static unsigned long __initdata default_hstate_size;
>> +static bool __initdata parsed_valid_hugepagesz = true;
>>
>> /*
>>  * Protects updates to hugepage_freelists, hugepage_activelist, 
>> nr_huge_pages,
>> @@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
>> subsys_initcall(hugetlb_init);
>>
>> /* Should be called on processing a hugepagesz=... option */
>> +void __init hugetlb_bad_size(void)
>> +{
>> +parsed_valid_hugepagesz = false;
>> +}
>> +
>> void __init hugetlb_add_hstate(unsigned int order)
>> {
>> struct hstate *h;
>> @@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
>> unsigned long *mhp;
>> static unsigned long *last_mhp;
>>
>> +if (!parsed_valid_hugepagesz) {
>> +pr_warn("hugepages = %s preceded by "
>> +"an unsupported hugepagesz, ignoring\n", s);
>
> How about concatenating the format string?  `CodingStyle` now suggests to
> _never_ break every user-visible strings.
>

As I said above, I just followed the pattern of the current code to maintain the
consistency. Probably a separate change would be good for solving all those
warnings. :)

>> +parsed_valid_hugepagesz = true;
>> +return 1;
>> +}
>> /*
>>  * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter 
>> yet,
>>  * so this hugepages= parameter goes to the "default hstate".
>>  */
>> -if (!hugetlb_max_hstate)
>> +else if (!hugetlb_max_hstate)
>
> Because the upper `if` statement will do `return`, above change looks not
> significantly necessary.  Is this intended?
>

I think above change is necessary for the cases like "hugepages=X" because in 
that
case the X hugepages of the default size [like 2M for x86] should be allocated.

>> mhp = &default_hstate_max_huge_pages;
>> else
>> mhp = &parsed_hstate->max_huge_pages;
>> -- 
>> 2.1.4
>>
>> -- 
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
>>

-- 
Vaishali

Re: [PATCH 2/2] arch:mm: Use hugetlb_bad_size

[Vaishali Thakkar]

On Wednesday 23 March 2016 08:45 AM, Hillf Danton wrote:
>> Update the setup_hugepagesz function to call the routine
>> hugetlb_bad_size when unsupported hugepage size is found.
>>
>> Misc:
>>   - Silent 80 characters warning
>>
>> Signed-off-by: Vaishali Thakkar 
>> Cc: Mike Kravetz 
>> Cc: Naoya Horiguchi 
>> Cc: Hillf Danton 
>> Cc: Michal Hocko 
>> Cc: Yaowei Bai 
>> Cc: Dominik Dingel 
>> Cc: Kirill A. Shutemov 
>> Cc: Paul Gortmaker 
>> Cc: Dave Hansen 
>> ---
>> - Please note that the patch is tested for x86 only. But as this
>>   is one line change I just changed them. So, it would be good if
>>   the patch can be tested for other architectures before adding
>>   this in to mainline.
>> - Not sure if printk related checkpatch.pl warning should be resolved
>>   with this patch as code is not consistent in architectures. May be
>>   one separate patch for changing all printk's to pr_ kind of
>>   debugging functions would be good.
>> ---
>>  arch/arm64/mm/hugetlbpage.c   | 1 +
>>  arch/metag/mm/hugetlbpage.c   | 1 +
>>  arch/powerpc/mm/hugetlbpage.c | 7 +--
>>  arch/tile/mm/hugetlbpage.c| 7 ++-
> Looks Chris Metcalf  not cced;-(
>
>>  arch/x86/mm/hugetlbpage.c | 1 +
>>  5 files changed, 14 insertions(+), 3 deletions(-)
>>
> Help more if separate patches rather than a monolithic one are 
> delivered to the arch maintainers. 

Do you want me to send new version of the patchset breaking this patch in
to separate patches?

>> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
>> index 589fd28..aa8aee7 100644
>> --- a/arch/arm64/mm/hugetlbpage.c
>> +++ b/arch/arm64/mm/hugetlbpage.c
>> @@ -307,6 +307,7 @@ static __init int setup_hugepagesz(char *opt)
>>  } else if (ps == PUD_SIZE) {
>>  hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>>  } else {
>> +hugetlb_bad_size();
>>  pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
>>  return 0;
>>  }
>> diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
>> index b38700a..db1b7da 100644
>> --- a/arch/metag/mm/hugetlbpage.c
>> +++ b/arch/metag/mm/hugetlbpage.c
>> @@ -239,6 +239,7 @@ static __init int setup_hugepagesz(char *opt)
>>  if (ps == (1 << HPAGE_SHIFT)) {
>>  hugetlb_add_hstate(HPAGE_SHIFT - PAGE_SHIFT);
>>  } else {
>> +hugetlb_bad_size();
>>  pr_err("hugepagesz: Unsupported page size %lu M\n",
>> ps >> 20);
>>  return 0;
>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
>> index 6dd272b..a437ff7 100644
>> --- a/arch/powerpc/mm/hugetlbpage.c
>> +++ b/arch/powerpc/mm/hugetlbpage.c
>> @@ -772,8 +772,11 @@ static int __init hugepage_setup_sz(char *str)
>>
>>  size = memparse(str, &str);
>>
>> -if (add_huge_page_size(size) != 0)
>> -printk(KERN_WARNING "Invalid huge page size specified(%llu)\n", 
>> size);
>> +if (add_huge_page_size(size) != 0) {
>> +hugetlb_bad_size();
>> +printk(KERN_WARNING "Invalid huge page size specified(%llu)\n",
>> +   size);
>> +}
>>
>>  return 1;
>>  }
>> diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
>> index e212c64..77ceaa3 100644
>> --- a/arch/tile/mm/hugetlbpage.c
>> +++ b/arch/tile/mm/hugetlbpage.c
>> @@ -308,11 +308,16 @@ static bool saw_hugepagesz;
>>
>>  static __init int setup_hugepagesz(char *opt)
>>  {
>> +int rc;
>> +
>>  if (!saw_hugepagesz) {
>>  saw_hugepagesz = true;
>>  memset(huge_shift, 0, sizeof(huge_shift));
>>  }
>> -return __setup_hugepagesz(memparse(opt, NULL));
>> +rc = __setup_hugepagesz(memparse(opt, NULL));
>> +if (rc)
>> +hugetlb_bad_size();
>> +return rc;
>>  }
>>  __setup("hugepagesz=", setup_hugepagesz);
>>
>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>> index 740d7ac..3ec44f8 100644
>> --- a/arch/x86/mm/hugetlbpage.c
>> +++ b/arch/x86/mm/hugetlbpage.c
>> @@ -165,6 +165,7 @@ static __init int setup_hugepagesz(char *opt)
>>  } else if (ps == PUD_SIZE && cpu_has_gbpages) {
>>  hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>>  } else {
>> +hugetlb_bad_size();
>>  printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
>>  ps >> 20);
>>  return 0;
>> --
>> 2.1.4

-- 
Vaishali

RE: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

[Rajesh Bhagat]

> -Original Message-
> From: Mathias Nyman [mailto:mathias.ny...@linux.intel.com]
> Sent: Tuesday, March 22, 2016 5:36 PM
> To: Rajesh Bhagat 
> Cc: gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Sriram Dash 
> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI
> commmand timeout
> 
> On 22.03.2016 07:19, Rajesh Bhagat wrote:
> >
> >
> >> -Original Message-
> >> From: Mathias Nyman [mailto:mathias.ny...@intel.com]
> >> Sent: Monday, March 21, 2016 2:46 PM
> >> To: Rajesh Bhagat ; Mathias Nyman
> >> ; linux-...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org
> >> Cc: gre...@linuxfoundation.org; Sriram Dash 
> >> Subject: Re: [PATCH] usb: xhci: Fix incomplete PM resume operation
> >> due to XHCI commmand timeout
> >>
> >> On 21.03.2016 06:18, Rajesh Bhagat wrote:
> >>>
> >>>
> 
>  Hi
> 
>  I think clearing the whole command ring is a bit too much in this case.
>  It may cause issues for all attached devices when one command times out.
> 
> >>>
> >>> Hi Mathias,
> >>>
> >>> I understand your point, But I want to understand how would
> >>> completion handler be called if a command is timed out and
> >>> xhci_abort_cmd_ring is successful. In this case all the code would be 
> >>> waiting on
> completion handler forever.
> >>>
> >>>
> >>> 2. xhci_handle_command_timeout -> xhci_abort_cmd_ring(failure) ->
> >>> xhci_cleanup_command_queue -> xhci_complete_del_and_free_cmd
> >>>
> >>> In our case command is timed out, Hence we hit the case #2 but
> >>> xhci_abort_cmd_ring is success which does not calls complete.
> >>
> >> xhci_abort_cmd_ring() will write CA bit (CMD_RING_ABORT) to CRCR register.
> >> This will generate a command completion event with status "command
> >> aborted" for the pending command.
> >> This event is then followed by a "command ring stopped" command completion
> event.
> >>
> >> See xHCI specs 5.4.5 and 4.6.1.2
> >>
> >> handle_cmd_completion() will check if cmd_comp_code ==
> >> COMP_CMD_ABORT, goto event_handled, and call
> >> xhci_complete_del_and_free_cmd(cmd, cmd_comp_code) for the aborted
> command.
> >>
> >> If xHCI already processed the aborted command, we might only get a
> >> command ring stopped event, in this case handle_cmd_completion() will
> >> call xhci_handle_stopped_cmd_ring(xhci, cmd), which will turn the
> >> commands that were tagged for "abort" that still remain on the command 
> >> ring to
> NO-OP commands.
> >>
> >> The completion callback will be called for these NO-OP command later
> >> when we get a command completion event for them.
> >>
> >
> > Thanks Mathias for detailed explanation. Now I understand how
> > completion handler is supposed to be called in this scenario.
> >
> > But in our case, somehow we are not getting any event and
> > handle_cmd_completion function is not getting called even after successful
> xhci_abort_cmd_ring when command timed out.
> >
> > Now, my point here is code prior to this patch xhci: rework command
> > timeout and cancellation, Code would have returned in case command timed 
> > out in
> xhci_alloc_dev itself.
> >
> > -   /* XXX: how much time for xHC slot assignment? */
> > -   timeleft = wait_for_completion_interruptible_timeout(
> > -   command->completion,
> > -   XHCI_CMD_DEFAULT_TIMEOUT);
> > -   if (timeleft <= 0) {
> > -   xhci_warn(xhci, "%s while waiting for a slot\n",
> > -   timeleft == 0 ? "Timeout" : "Signal");
> > -   /* cancel the enable slot request */
> > -   ret = xhci_cancel_cmd(xhci, NULL, command->command_trb);
> > -   return ret;
> > -   }
> > +   wait_for_completion(command->completion);
> >
> > But after this patch, we are waiting for hardware event, which is
> > somehow not generated and causing a hang scenario.
> >
> > IMO, The assumption that "xhci_abort_cmd_ring would always generate an
> > event and handle_cmd_completion would be called" will not be always be true 
> > if HW
> is in bad state.
> >
> > Please share your opinion.
> >
> 
> writing the CA (command abort) bit in CRCR (command ring control register)  
> will stop
> the command ring, and CRR (command ring running) will be set to 0 by xHC.
> xhci_abort_cmd_ring() polls this bit up to 5 seconds.
> If it's not 0 then the driver considers the command abort as failed.
> 
> The scenario you're thinking of is that xHC would still react to CA bit set, 
> it would stop
> the command ring and set CRR 0, but not send a command completion event.
> 
> Have you tried adding some debug to handle_cmd_completion() and see if you 
> receive
> any event after command abortion?
> 

Yes. We have added debug prints at first line of handle_cmd_completion, and we 
are not getting 
those prints. The last print messages that we get are as below from 
xhci_alloc_dev while resume 
operation: 

xhci-hcd xhci-hcd.0.auto: Com

Re: [PATCH V2 0/2] kexec: Make a pair of map/unmap reserved pages in error path

[Xunlei Pang]

On 2016/03/23 at 10:48, Baoquan He wrote:
> On 03/01/16 at 05:53pm, Xunlei Pang wrote:
>> This is a bug fix.
>>
>> After this, I will try to do a cleanup for crash_unmap/map_reserved_pages()
>> (only used by S390) to consolidate it with 
>> arch_kexec_unprotect/protect_crashkres().
> Hi Xunlei, Minfei,
>
> I think you need discuss together about how to do clean up codes in this
> place. From my point of view, arch_map/unmap_reserved_pages and
> arch_kexec_protect/unprotect_crashkres() are for the same goal but by
> different ways on different arch. So for Xunlei's patchset, you might
> need to rethink your implementation, the name of function. I personally
> think you just implement a x86 specific arch_map/unmap_reserved_pages.
> It may need a more generic name, and then add your x86 arch specific
> implementation. Sorry I can't see your patches on my mail client,

Like what you said, I think arch_kexec_unprotect/protect_crashkres() are
generic enough, but any other better name is welcome :-)

It also covered the newly-added kexec file path, and we can easily transfer
arch_map/unmap_reserved_pages into this new interface.

I was planning doing that, but sick recently, I will try to send a patch
doing that later.

Regards,
Xunlei

> Xunlei. Since Andrew asked, I just checked these.
>
> I am fine with Minfei's patch 1/2. But for patch 2/2, it's a little
> comfortable to me. Is it really necessary to abstract code block from
> kexec_load, then wrap them into a newly added function do_kexec_load()?
> Without this wrapping is there a way to do your bug fix? Is there
> possibility that do_kexec_load will be called in other places? What's
> the benefit to wrap it into do_kexec_load against not wrapping?
>
> Thanks
> Baoquan
>
>> Regards,
>> Xunlei
>>
>> On 03/01/2016 at 04:02 PM, Minfei Huang wrote:
>>> v1:
>>> - Bisect the patch according to Andrew Morton's suggestion
>>>
>>> Minfei Huang (2):
>>>   kexec: Make a pair of map/unmap reserved pages in error path
>>>   kexec: Do a cleanup for function kexec_load
>>>
>>>  kernel/kexec.c | 112 
>>> -
>>>  1 file changed, 63 insertions(+), 49 deletions(-)
>>>
>>
>> ___
>> kexec mailing list
>> ke...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 4/5] mm/lru: is_file/active_lru can be boolean

[Joe Perches]

On Wed, 2016-03-23 at 10:26 +0800, Yaowei Bai wrote:
> This patch makes is_file/active_lru return bool to improve
> readability due to these particular functions only using either
> one or zero as their return value.
> 
> No functional change.

These assignments to int should likely be modified too

$ git grep -w -n is_file_lru
include/linux/mmzone.h:191:static inline int is_file_lru(enum lru_list lru)
mm/vmscan.c:1404:   nr_taken, mode, 
is_file_lru(lru));
mm/vmscan.c:1525:   int file = is_file_lru(lru);
mm/vmscan.c:1581:   int file = is_file_lru(lru);
mm/vmscan.c:1783:   int file = is_file_lru(lru);
mm/vmscan.c:1934:   if (is_file_lru(lru))
mm/vmscan.c:2129:   int file = is_file_lru(lru);

Re: [PATCH 2/2] arch:mm: Use hugetlb_bad_size

[Hillf Danton]

> 
> Update the setup_hugepagesz function to call the routine
> hugetlb_bad_size when unsupported hugepage size is found.
> 
> Misc:
>   - Silent 80 characters warning
> 
> Signed-off-by: Vaishali Thakkar 
> Cc: Mike Kravetz 
> Cc: Naoya Horiguchi 
> Cc: Hillf Danton 
> Cc: Michal Hocko 
> Cc: Yaowei Bai 
> Cc: Dominik Dingel 
> Cc: Kirill A. Shutemov 
> Cc: Paul Gortmaker 
> Cc: Dave Hansen 
> ---
> - Please note that the patch is tested for x86 only. But as this
>   is one line change I just changed them. So, it would be good if
>   the patch can be tested for other architectures before adding
>   this in to mainline.
> - Not sure if printk related checkpatch.pl warning should be resolved
>   with this patch as code is not consistent in architectures. May be
>   one separate patch for changing all printk's to pr_ kind of
>   debugging functions would be good.
> ---
>  arch/arm64/mm/hugetlbpage.c   | 1 +
>  arch/metag/mm/hugetlbpage.c   | 1 +
>  arch/powerpc/mm/hugetlbpage.c | 7 +--
>  arch/tile/mm/hugetlbpage.c| 7 ++-

Looks Chris Metcalf  not cced;-(

>  arch/x86/mm/hugetlbpage.c | 1 +
>  5 files changed, 14 insertions(+), 3 deletions(-)
> 

Help more if separate patches rather than a monolithic one are 
delivered to the arch maintainers. 

> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 589fd28..aa8aee7 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -307,6 +307,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
>   return 0;
>   }
> diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
> index b38700a..db1b7da 100644
> --- a/arch/metag/mm/hugetlbpage.c
> +++ b/arch/metag/mm/hugetlbpage.c
> @@ -239,6 +239,7 @@ static __init int setup_hugepagesz(char *opt)
>   if (ps == (1 << HPAGE_SHIFT)) {
>   hugetlb_add_hstate(HPAGE_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu M\n",
>  ps >> 20);
>   return 0;
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 6dd272b..a437ff7 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -772,8 +772,11 @@ static int __init hugepage_setup_sz(char *str)
> 
>   size = memparse(str, &str);
> 
> - if (add_huge_page_size(size) != 0)
> - printk(KERN_WARNING "Invalid huge page size specified(%llu)\n", 
> size);
> + if (add_huge_page_size(size) != 0) {
> + hugetlb_bad_size();
> + printk(KERN_WARNING "Invalid huge page size specified(%llu)\n",
> +size);
> + }
> 
>   return 1;
>  }
> diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
> index e212c64..77ceaa3 100644
> --- a/arch/tile/mm/hugetlbpage.c
> +++ b/arch/tile/mm/hugetlbpage.c
> @@ -308,11 +308,16 @@ static bool saw_hugepagesz;
> 
>  static __init int setup_hugepagesz(char *opt)
>  {
> + int rc;
> +
>   if (!saw_hugepagesz) {
>   saw_hugepagesz = true;
>   memset(huge_shift, 0, sizeof(huge_shift));
>   }
> - return __setup_hugepagesz(memparse(opt, NULL));
> + rc = __setup_hugepagesz(memparse(opt, NULL));
> + if (rc)
> + hugetlb_bad_size();
> + return rc;
>  }
>  __setup("hugepagesz=", setup_hugepagesz);
> 
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 740d7ac..3ec44f8 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -165,6 +165,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE && cpu_has_gbpages) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
>   ps >> 20);
>   return 0;
> --
> 2.1.4

Question about PCI I/O space in ARM64

[Kefeng Wang]

Hi all，

If no pci, the PCI I/O space(16M) is mapped into an irrelevant mem space(right 
?), not a right IO space,
that is, no one call pci_remap_iospace() to remap the memory mapped I/O space, 
once driver
like f71805f loaded, write value to IO space(see 
f71805f_init->f71805f_find->superio_enter->outb),
we met following oops,

Unable to handle kernel paging request at virtual address ffbffee0002e
pgd = ffc1d68d4000
[ffbffee0002e] *pgd=, *pud=
Internal error: Oops: 9446 [#1] PREEMPT SMP
Modules linked in: f71805f(+) hwmon
CPU: 3 PID: 1659 Comm: insmod Not tainted 4.5.0+ #88
Hardware name: linux,dummy-virt (DT)
task: ffc1f6665400 ti: ffc1d6418000 task.ti: ffc1d6418000
PC is at f71805f_find+0x6c/0x358 [f71805f]


I am not clear about PCI I/O, but if this is indeed a bug, how to solve this 
issue,
any advice will be appreciated.

Thanks
Kefeng

Re: [PATCH V2 0/2] kexec: Make a pair of map/unmap reserved pages in error path

[Baoquan He]

On 03/01/16 at 05:53pm, Xunlei Pang wrote:
> This is a bug fix.
> 
> After this, I will try to do a cleanup for crash_unmap/map_reserved_pages()
> (only used by S390) to consolidate it with 
> arch_kexec_unprotect/protect_crashkres().

Hi Xunlei, Minfei,

I think you need discuss together about how to do clean up codes in this
place. From my point of view, arch_map/unmap_reserved_pages and
arch_kexec_protect/unprotect_crashkres() are for the same goal but by
different ways on different arch. So for Xunlei's patchset, you might
need to rethink your implementation, the name of function. I personally
think you just implement a x86 specific arch_map/unmap_reserved_pages.
It may need a more generic name, and then add your x86 arch specific
implementation. Sorry I can't see your patches on my mail client,
Xunlei. Since Andrew asked, I just checked these.

I am fine with Minfei's patch 1/2. But for patch 2/2, it's a little
comfortable to me. Is it really necessary to abstract code block from
kexec_load, then wrap them into a newly added function do_kexec_load()?
Without this wrapping is there a way to do your bug fix? Is there
possibility that do_kexec_load will be called in other places? What's
the benefit to wrap it into do_kexec_load against not wrapping?

Thanks
Baoquan

> 
> Regards,
> Xunlei
> 
> On 03/01/2016 at 04:02 PM, Minfei Huang wrote:
> > v1:
> > - Bisect the patch according to Andrew Morton's suggestion
> >
> > Minfei Huang (2):
> >   kexec: Make a pair of map/unmap reserved pages in error path
> >   kexec: Do a cleanup for function kexec_load
> >
> >  kernel/kexec.c | 112 
> > -
> >  1 file changed, 63 insertions(+), 49 deletions(-)
> >
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

[PATCH v2] misc: sram: fix check of devm_ioremap*() return value

[Vladimir Zapolskiy]

Both devm_ioremap() and devm_ioremap_wc() functions return either
a pointer to valid iomem region or NULL, check for IS_ERR() is improper
and may result in oops on error path. Now on error -ENOMEM is returned.

Fixes: 0ab163ad1ea0 ("misc: sram: switch to ioremap_wc from ioremap")
Signed-off-by: Vladimir Zapolskiy 
---
I add Fixes: tag for reference, but unfortunately the change can not
be cleanly applied to kernel versions liable to the problem.

Changes from v1 to v2:
- had to rebase on top of eb43e023130b ("misc: sram: add optional ioremap 
without write combining")
- slightly reworded the commit message and subject

v1 of the change: https://lkml.org/lkml/2016/3/6/202

 drivers/misc/sram.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 69cdabe..f84b53d 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -364,8 +364,8 @@ static int sram_probe(struct platform_device *pdev)
sram->virt_base = devm_ioremap(sram->dev, res->start, size);
else
sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
-   if (IS_ERR(sram->virt_base))
-   return PTR_ERR(sram->virt_base);
+   if (!sram->virt_base)
+   return -ENOMEM;
 
sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
  NUMA_NO_NODE, NULL);
-- 
2.1.4

Re: [RFC] high preempt off latency in vfree path

[Andi Kleen]

> (1)
> One is we reduce the number of lazy_max_pages (right now its around 32MB per 
> core worth of pages).
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index aa3891e..2720f4f 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -564,7 +564,7 @@ static unsigned long lazy_max_pages(void)
> 
> log = fls(num_online_cpus());
> 
> -   return log * (32UL * 1024 * 1024 / PAGE_SIZE);
> +   return log * (8UL * 1024 * 1024 / PAGE_SIZE);
>  }

This seems like the right fix to me.  Perhaps even make it somewhat smaller.

Even on larger systems it's probably fine because they have a lot more
cores/threads these days, so it will be still sufficiently large.

-Andi

Re: [PATCH 2/2] arch:mm: Use hugetlb_bad_size

[Mike Kravetz]

On 03/22/2016 03:05 AM, Vaishali Thakkar wrote:
> Update the setup_hugepagesz function to call the routine
> hugetlb_bad_size when unsupported hugepage size is found.
> 
> Misc:
>   - Silent 80 characters warning
> 
> Signed-off-by: Vaishali Thakkar 
> Cc: Mike Kravetz 
> Cc: Naoya Horiguchi 
> Cc: Hillf Danton 
> Cc: Michal Hocko 
> Cc: Yaowei Bai 
> Cc: Dominik Dingel 
> Cc: Kirill A. Shutemov 
> Cc: Paul Gortmaker 
> Cc: Dave Hansen 
> ---

Looks fine to me,

Reviewed-by: Mike Kravetz 

> - Please note that the patch is tested for x86 only. But as this
>   is one line change I just changed them. So, it would be good if
>   the patch can be tested for other architectures before adding
>   this in to mainline.
> - Not sure if printk related checkpatch.pl warning should be resolved
>   with this patch as code is not consistent in architectures. May be
>   one separate patch for changing all printk's to pr_ kind of
>   debugging functions would be good.
> ---
>  arch/arm64/mm/hugetlbpage.c   | 1 +
>  arch/metag/mm/hugetlbpage.c   | 1 +
>  arch/powerpc/mm/hugetlbpage.c | 7 +--
>  arch/tile/mm/hugetlbpage.c| 7 ++-
>  arch/x86/mm/hugetlbpage.c | 1 +
>  5 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 589fd28..aa8aee7 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -307,6 +307,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
>   return 0;
>   }
> diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
> index b38700a..db1b7da 100644
> --- a/arch/metag/mm/hugetlbpage.c
> +++ b/arch/metag/mm/hugetlbpage.c
> @@ -239,6 +239,7 @@ static __init int setup_hugepagesz(char *opt)
>   if (ps == (1 << HPAGE_SHIFT)) {
>   hugetlb_add_hstate(HPAGE_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu M\n",
>  ps >> 20);
>   return 0;
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 6dd272b..a437ff7 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -772,8 +772,11 @@ static int __init hugepage_setup_sz(char *str)
>  
>   size = memparse(str, &str);
>  
> - if (add_huge_page_size(size) != 0)
> - printk(KERN_WARNING "Invalid huge page size specified(%llu)\n", 
> size);
> + if (add_huge_page_size(size) != 0) {
> + hugetlb_bad_size();
> + printk(KERN_WARNING "Invalid huge page size specified(%llu)\n",
> +size);
> + }
>  
>   return 1;
>  }
> diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
> index e212c64..77ceaa3 100644
> --- a/arch/tile/mm/hugetlbpage.c
> +++ b/arch/tile/mm/hugetlbpage.c
> @@ -308,11 +308,16 @@ static bool saw_hugepagesz;
>  
>  static __init int setup_hugepagesz(char *opt)
>  {
> + int rc;
> +
>   if (!saw_hugepagesz) {
>   saw_hugepagesz = true;
>   memset(huge_shift, 0, sizeof(huge_shift));
>   }
> - return __setup_hugepagesz(memparse(opt, NULL));
> + rc = __setup_hugepagesz(memparse(opt, NULL));
> + if (rc)
> + hugetlb_bad_size();
> + return rc;
>  }
>  __setup("hugepagesz=", setup_hugepagesz);
>  
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 740d7ac..3ec44f8 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -165,6 +165,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE && cpu_has_gbpages) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
>   ps >> 20);
>   return 0;
> 


-- 
Mike Kravetz

Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

[Mike Kravetz]

On 03/22/2016 03:00 AM, Vaishali Thakkar wrote:
> When any unsupported hugepage size is specified, 'hugepagesz=' and
> 'hugepages=' should be ignored during command line parsing until any
> supported hugepage size is found. But currently incorrect number of
> hugepages are allocated when unsupported size is specified as it fails
> to ignore the 'hugepages=' command.
> 
> Test case:
> 
> Note that this is specific to x86 architecture.
> 
> Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
> After boot, dmesg output shows that X number of hugepages of the size 2M
> is pre-allocated instead of 0.
> 
> So, to handle such command line options, introduce new routine
> hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
> parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
> state when unsupported hugepagesize is found so that we can ignore the
> 'hugepages=' parameters after that and then reset the variable when
> supported hugepage size is found.
> 
> The routine hugetlb_bad_size can be called while setting 'hugepagesz='
> parameter in an architecture specific code.
> 
> Signed-off-by: Vaishali Thakkar 
> Cc: Mike Kravetz 
> Cc: Naoya Horiguchi 
> Cc: Hillf Danton 
> Cc: Michal Hocko 
> Cc: Yaowei Bai 
> Cc: Dominik Dingel 
> Cc: Kirill A. Shutemov 
> Cc: Paul Gortmaker 
> Cc: Dave Hansen 
> ---

Looks fine to me,

Reviewed-by: Mike Kravetz 

> The patch is having 2 checkpatch.pl warnings. I have just followed
> the current code to maintain consistency. If we decide to silent
> these warnings then may be we should silent those warnings as well.
> I am fine with any option whichever works best for everyone else. 
> ---
>  include/linux/hugetlb.h |  1 +
>  mm/hugetlb.c| 14 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 7d953c2..e44c578 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct 
> address_space *mapping,
>  /* arch callback */
>  int __init alloc_bootmem_huge_page(struct hstate *h);
>  
> +void __init hugetlb_bad_size(void);
>  void __init hugetlb_add_hstate(unsigned order);
>  struct hstate *size_to_hstate(unsigned long size);
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 06058ea..44fae6a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
>  static struct hstate * __initdata parsed_hstate;
>  static unsigned long __initdata default_hstate_max_huge_pages;
>  static unsigned long __initdata default_hstate_size;
> +static bool __initdata parsed_valid_hugepagesz = true;
>  
>  /*
>   * Protects updates to hugepage_freelists, hugepage_activelist, 
> nr_huge_pages,
> @@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
>  subsys_initcall(hugetlb_init);
>  
>  /* Should be called on processing a hugepagesz=... option */
> +void __init hugetlb_bad_size(void)
> +{
> + parsed_valid_hugepagesz = false;
> +}
> +
>  void __init hugetlb_add_hstate(unsigned int order)
>  {
>   struct hstate *h;
> @@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
>   unsigned long *mhp;
>   static unsigned long *last_mhp;
>  
> + if (!parsed_valid_hugepagesz) {
> + pr_warn("hugepages = %s preceded by "
> + "an unsupported hugepagesz, ignoring\n", s);
> + parsed_valid_hugepagesz = true;
> + return 1;
> + }
>   /*
>* !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter 
> yet,
>* so this hugepages= parameter goes to the "default hstate".
>*/
> - if (!hugetlb_max_hstate)
> + else if (!hugetlb_max_hstate)
>   mhp = &default_hstate_max_huge_pages;
>   else
>   mhp = &parsed_hstate->max_huge_pages;
> 


-- 
Mike Kravetz

[PATCH] lib: scatterlist: fix ifnullfree.cocci warnings

[kbuild test robot]

lib/sg_pool.c:152:3-18: WARNING: NULL check before freeing functions like 
kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. 
Maybe consider reorganizing relevant code to avoid passing NULL values.
lib/sg_pool.c:154:3-21: WARNING: NULL check before freeing functions like 
kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. 
Maybe consider reorganizing relevant code to avoid passing NULL values.

 NULL check before some freeing functions is not needed.

 Based on checkpatch warning
 "kfree(NULL) is safe this check is probably not required"
 and kfreeaddr.cocci by Julia Lawall.

Generated by: scripts/coccinelle/free/ifnullfree.cocci

CC: Ming Lin 
Signed-off-by: Fengguang Wu 
---

 sg_pool.c |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/lib/sg_pool.c
+++ b/lib/sg_pool.c
@@ -148,10 +148,8 @@ static __init int sg_pool_init(void)
 cleanup_sdb:
for (i = 0; i < SG_MEMPOOL_NR; i++) {
struct sg_pool *sgp = sg_pools + i;
-   if (sgp->pool)
-   mempool_destroy(sgp->pool);
-   if (sgp->slab)
-   kmem_cache_destroy(sgp->slab);
+   mempool_destroy(sgp->pool);
+   kmem_cache_destroy(sgp->slab);
}
 
return -ENOMEM;

Re: [PATCH v2 5/5] lib: scatterlist: move SG pool code from SCSI driver to lib/sg_pool.c

[kbuild test robot]

Hi Ming,

[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.5 next-20160322]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Ming-Lin/mempool-based-chained-scatterlist-alloc-free-api/20160323-060710
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next


coccinelle warnings: (new ones prefixed by >>)

>> lib/sg_pool.c:152:3-18: WARNING: NULL check before freeing functions like 
>> kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not 
>> needed. Maybe consider reorganizing relevant code to avoid passing NULL 
>> values.
   lib/sg_pool.c:154:3-21: WARNING: NULL check before freeing functions like 
kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. 
Maybe consider reorganizing relevant code to avoid passing NULL values.

Please review and possibly fold the followup patch.

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

Re: [PATCH] Add fwupdate and Mok GUID's to the EFI variable immutable whitelist

[Mario Limonciello]

On 03/22/2016 04:37 PM, Limonciello, Mario wrote:
> ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 caused all variables to be
> immutable by default.  This causes problems with userspace applications
> mokutil and fwupdate.
> ---
>  drivers/firmware/efi/vars.c | 2 ++
>  include/linux/efi.h | 8 
>  2 files changed, 10 insertions(+)
>
> diff --git a/drivers/firmware/efi/vars.c b/drivers/firmware/efi/vars.c
> index 0ac594c..16bd2a9 100644
> --- a/drivers/firmware/efi/vars.c
> +++ b/drivers/firmware/efi/vars.c
> @@ -199,6 +199,8 @@ static const struct variable_validate variable_validate[] 
> = {
>   { EFI_GLOBAL_VARIABLE_GUID, "PlatformLang", validate_ascii_string },
>   { EFI_GLOBAL_VARIABLE_GUID, "Timeout", validate_uint16 },
>   { LINUX_EFI_CRASH_GUID, "*", NULL },
> + { FWUPDATE_GUID, "fwupdate*", NULL },
> + { MOK_GUID, "Mok*", NULL },
>   { NULL_GUID, "", NULL },
>  };
>  
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 1626474..c882cb0 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -575,6 +575,14 @@ void efi_native_runtime_setup(void);
>   EFI_GUID(0x8be4df61, 0x93ca, 0x11d2, \
>0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c)
>  
> +#define FWUPDATE_GUID \
> + EFI_GUID(0x0abba7dc, 0xe516, 0x4167, \
> +  0xbb, 0xf5, 0x4d, 0x9d, 0x1c, 0x73, 0x94, 0x16)
> +
> +#define MOK_GUID \
> + EFI_GUID(0x605dab50, 0xe046, 0x4300, \
> +  0xab, 0xb6, 0x3d, 0xd8, 0x10, 0xdd, 0x8b, 0x23)
> +
>  #define UV_SYSTEM_TABLE_GUID \
>   EFI_GUID(0x3b13a7d4, 0x633e, 0x11dd, \
>0x93, 0xec, 0xda, 0x25, 0x56, 0xd8, 0x95, 0x93)
Actually, I think this patch should be discarded unless there is a
desire to make the kernel work with older userspace tools. 

I later realized that efivar 0.22 will actually handle working with
immutable variables properly.  This means that mokutil 0.2 won't work
with this kernel commit, but mokutil 0.3 which uses efivar
(https://github.com/lcp/mokutil/commit/7b49e834284659527c9f7cf554f223748c00564b)
should work properly.

fwupdate works properly in most instances except for an install time
cleanup script that removes stale variables.  This is fixed with a
trivial change:
https://github.com/rhinstaller/fwupdate/pull/50/commits/535d3a0f9c096d452cc7e2b5be79cf964e2d6d5b

Re: [PATCH] vlan: propagate gso_min_segs

[Eric Dumazet]

On Wed, 2016-03-23 at 09:35 +0800, Haishuang Yan wrote:
> vlan drivers lack proper propagation of gso_min_segs from lower device.
> 
> Signed-off-by: Haishuang Yan 
> ---

The plan was to get rid of gso_min_segs, as nothing uses it.

Otherwise I would have included this in my recent patches...

For such a rare 'issue' , we believe ndo_features_check() is better,
because it does not slow down the fast path.

Thanks.

Re: RCU stall

[Paul E. McKenney]

On Tue, Mar 22, 2016 at 06:59:32PM -0700, Paul E. McKenney wrote:
> On Tue, Mar 22, 2016 at 04:53:26PM -0700, Bart Van Assche wrote:
> > On 03/22/2016 01:45 PM, Paul E. McKenney wrote:
> > >You are getting a soft lockup as well as an RCU CPU stall warning, so
> > >it looks like something is taking a very long time in blk_done_softirq().
> > >
> > >You have multiple occurrences at different times, so it looks to be
> > >a long time as opposed to an infinite time.  Are you perhaps doing
> > >something that would make a huge amount of work for blk_done_softirq()?
> > >
> > >See Documentation/RCU/stallwarn.txt in the kernel source tree for more
> > >info on how to debug this sort of thing.
> > 
> > Hello Paul,
> > 
> > None of the drivers involved in the test I ran contain RCU code that
> > has been changed recently. The block and SCSI subsystems processes
> > I/O completions in softirq context but until last week I hadn't seen
> > any RCU lockup complaints when I ran an SRP test against a kernel
> > with lockdep and several other kernel debugging options enabled.
> > This is why I sent an e-mail to you. I have read
> > Documentation/RCU/stallwarn.txt after I received your reply but this
> > didn't provide me any clue about where to look for the root cause.
> > Any further help would be appreciated.
> 
> My suggestion would be to check the block/SCSI softirq handler for
> event traces.  If there are some, enable them and see what the loop
> is doing.  Documentation/trace/ftrace.txt describes how to enable
> existing event tracing.
> 
> If there is no event tracing, consider adding some in your local
> view.  Failing that, there is always printk().  ;-)
> 
> Or perhaps you have some sort of debug setup.
> 
> Either way, the next step is to work out why that CPU is spending
> so much time in that loop.

And the dmesg leading up to the stall might have some clues.

Note that a soft lockup triggered at 10509.568010, well before the RCU
CPU stall warning..  And you have a second soft lockup at 10537.567212,
with the same funtion scsi_request_fn() at the top of the stack in both
stack traces.  That function has a nice big "for (;;)" loop that does
not appear to have any iteration-limiting mechanism.  (Though perhaps
there is such a mechanism implemented in one of the called functions,
but that would be something for you to look into.)  As you saw when
reading stallwarn.txt, having a too-long loop in the kernel is a good
way to get RCU CPU stall warnings.

Also, before the soft lockups, you have a bunch of FAIL indications
and other nasty-looking error messages.  Might you have some sort of
configuration or hardware problem?

Thanx, Paul

[PATCH 2/5] mm/memory_hotplug: is_mem_section_removable can be boolean

[Yaowei Bai]

This patch makes is_mem_section_removable return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/memory_hotplug.h | 6 +++---
 mm/memory_hotplug.c| 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index adbef58..20d8a5d 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -247,16 +247,16 @@ static inline void mem_hotplug_done(void) {}
 
 #ifdef CONFIG_MEMORY_HOTREMOVE
 
-extern int is_mem_section_removable(unsigned long pfn, unsigned long nr_pages);
+extern bool is_mem_section_removable(unsigned long pfn, unsigned long 
nr_pages);
 extern void try_offline_node(int nid);
 extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
 extern void remove_memory(int nid, u64 start, u64 size);
 
 #else
-static inline int is_mem_section_removable(unsigned long pfn,
+static inline bool is_mem_section_removable(unsigned long pfn,
unsigned long nr_pages)
 {
-   return 0;
+   return false;
 }
 
 static inline void try_offline_node(int nid) {}
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 24ea063..87be160 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1406,7 +1406,7 @@ static struct page *next_active_pageblock(struct page 
*page)
 }
 
 /* Checks if this range of memory is likely to be hot-removable. */
-int is_mem_section_removable(unsigned long start_pfn, unsigned long nr_pages)
+bool is_mem_section_removable(unsigned long start_pfn, unsigned long nr_pages)
 {
struct page *page = pfn_to_page(start_pfn);
struct page *end_page = page + nr_pages;
@@ -1414,12 +1414,12 @@ int is_mem_section_removable(unsigned long start_pfn, 
unsigned long nr_pages)
/* Check the starting page of each pageblock within the range */
for (; page < end_page; page = next_active_pageblock(page)) {
if (!is_pageblock_removable_nolock(page))
-   return 0;
+   return false;
cond_resched();
}
 
/* All pageblocks in the memory block are likely to be hot-removable */
-   return 1;
+   return true;
 }
 
 /*
-- 
1.9.1

Re: [PATCH] staging: delete STE RMI4 hackish driver

[Greg KH]

On Fri, Mar 18, 2016 at 10:12:15AM +0100, Linus Walleij wrote:
> As of commit 62d5bdf972ebcfc99f72f734ae979713e4ca6450
> "Merge branch 'synaptics-rmi4' into next" the input subsystem
> has a proper RMI4 infrastructure and touchscreen driver.
> The ST Ux500 platform has been converted to use the new driver
> and its devicetree bindings. Delete this ancient hack.
> 
> Cc: Andrew Duggan 
> Cc: Christopher Heiny 
> Signed-off-by: Linus Walleij 
> Acked-by: Dmitry Torokhov 
> ---
>  drivers/staging/ste_rmi4/Kconfig  |9 -
>  drivers/staging/ste_rmi4/Makefile |4 -
>  drivers/staging/ste_rmi4/TODO |7 -
>  drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c | 1137 
> -
>  drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h |   46 -
>  5 files changed, 1203 deletions(-)
>  delete mode 100644 drivers/staging/ste_rmi4/Kconfig
>  delete mode 100644 drivers/staging/ste_rmi4/Makefile
>  delete mode 100644 drivers/staging/ste_rmi4/TODO
>  delete mode 100644 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.c
>  delete mode 100644 drivers/staging/ste_rmi4/synaptics_i2c_rmi4.h

You forgot to fix up the drivers/staging/Makefile and
drivers/staging/Kconfig files as well :(

I'll go add that here...

[PATCH 0/5] mm: make several functions return bool

[Yaowei Bai]

This series only makes several functions return bool to
improve readability, no other functional changes.

Yaowei Bai (5):
  mm/hugetlb: is_vm_hugetlb_page can be boolean
  mm/memory_hotplug: is_mem_section_removable can be boolean
  mm/vmalloc: is_vmalloc_addr can be boolean
  mm/lru: is_file/active_lru can be boolean
  mm/mempolicy: vma_migratable can be boolean

 include/linux/hugetlb_inline.h |  6 +++---
 include/linux/memory_hotplug.h |  6 +++---
 include/linux/mempolicy.h  | 10 +-
 include/linux/mm.h |  4 ++--
 include/linux/mmzone.h |  4 ++--
 mm/memory_hotplug.c|  6 +++---
 6 files changed, 18 insertions(+), 18 deletions(-)

-- 
1.9.1

[PATCH 3/5] mm/vmalloc: is_vmalloc_addr can be boolean

[Yaowei Bai]

This patch makes is_vmalloc_addr return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index dbf1edd..826d2fb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -400,14 +400,14 @@ unsigned long vmalloc_to_pfn(const void *addr);
  * On nommu, vmalloc/vfree wrap through kmalloc/kfree directly, so there
  * is no special casing required.
  */
-static inline int is_vmalloc_addr(const void *x)
+static inline bool is_vmalloc_addr(const void *x)
 {
 #ifdef CONFIG_MMU
unsigned long addr = (unsigned long)x;
 
return addr >= VMALLOC_START && addr < VMALLOC_END;
 #else
-   return 0;
+   return false;
 #endif
 }
 #ifdef CONFIG_MMU
-- 
1.9.1

[PATCH 5/5] mm/mempolicy: vma_migratable can be boolean

[Yaowei Bai]

This patch makes vma_migratable return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mempolicy.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
index 2696c1f..6978a99 100644
--- a/include/linux/mempolicy.h
+++ b/include/linux/mempolicy.h
@@ -172,14 +172,14 @@ extern int mpol_parse_str(char *str, struct mempolicy 
**mpol);
 extern void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol);
 
 /* Check if a vma is migratable */
-static inline int vma_migratable(struct vm_area_struct *vma)
+static inline bool vma_migratable(struct vm_area_struct *vma)
 {
if (vma->vm_flags & (VM_IO | VM_PFNMAP))
-   return 0;
+   return false;
 
 #ifndef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
if (vma->vm_flags & VM_HUGETLB)
-   return 0;
+   return false;
 #endif
 
/*
@@ -190,8 +190,8 @@ static inline int vma_migratable(struct vm_area_struct *vma)
if (vma->vm_file &&
gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
< policy_zone)
-   return 0;
-   return 1;
+   return false;
+   return true;
 }
 
 extern int mpol_misplaced(struct page *, struct vm_area_struct *, unsigned 
long);
-- 
1.9.1

[PATCH 4/5] mm/lru: is_file/active_lru can be boolean

[Yaowei Bai]

This patch makes is_file/active_lru return bool to improve
readability due to these particular functions only using either
one or zero as their return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mmzone.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 6de02ac3..652d60e 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -188,12 +188,12 @@ enum lru_list {
 
 #define for_each_evictable_lru(lru) for (lru = 0; lru <= LRU_ACTIVE_FILE; 
lru++)
 
-static inline int is_file_lru(enum lru_list lru)
+static inline bool is_file_lru(enum lru_list lru)
 {
return (lru == LRU_INACTIVE_FILE || lru == LRU_ACTIVE_FILE);
 }
 
-static inline int is_active_lru(enum lru_list lru)
+static inline bool is_active_lru(enum lru_list lru)
 {
return (lru == LRU_ACTIVE_ANON || lru == LRU_ACTIVE_FILE);
 }
-- 
1.9.1

[PATCH 1/5] mm/hugetlb: is_vm_hugetlb_page can be boolean

[Yaowei Bai]

This patch makes is_vm_hugetlb_page return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/hugetlb_inline.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/hugetlb_inline.h b/include/linux/hugetlb_inline.h
index 2bb681f..a4e7ca0 100644
--- a/include/linux/hugetlb_inline.h
+++ b/include/linux/hugetlb_inline.h
@@ -5,16 +5,16 @@
 
 #include 
 
-static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
+static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
 {
return !!(vma->vm_flags & VM_HUGETLB);
 }
 
 #else
 
-static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
+static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
 {
-   return 0;
+   return false;
 }
 
 #endif
-- 
1.9.1

Re: [PATCH] Staging: fsl-mc: Fix up bad parameters to dev_err and dev_dbg

[Greg Kroah-Hartman]

On Fri, Mar 18, 2016 at 06:29:01PM -0700, Guenter Roeck wrote:
> The first parameter to dev_dbg() and dev_err() is struct device *,
> not struct device **.
> 
> Fixes: de71daf5c839 ("Staging: fsl-mc: Replace pr_debug with dev_dbg")
> Fixes: 454b0ec8bf99 ("Staging: fsl-mc: Replace pr_err with dev_err")
> Cc: Bhumika Goyal 
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/staging/fsl-mc/bus/mc-bus.c | 4 ++--
>  drivers/staging/fsl-mc/bus/mc-sys.c | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)

Someone else sent a patch for this before you did, I'll add you to that
one...

thanks,

greg k-h

Re: [PATCH] KVM: page_track: fix access to NULL slot

[Xiao Guangrong]

On 03/23/2016 12:40 AM, Paolo Bonzini wrote:

This happens when doing the reboot test from virt-tests:

[  131.833653] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[  131.842461] IP: [] kvm_page_track_is_active+0x17/0x60 [kvm]
[  131.850500] PGD 0
[  131.852763] Oops:  [#1] SMP
[  132.007188] task: 880075fbc500 ti: 880850a3c000 task.ti: 
880850a3c000
[  132.138891] Call Trace:
[  132.141639]  [] page_fault_handle_page_track+0x31/0x40 
[kvm]
[  132.149732]  [] paging64_page_fault+0xff/0x910 [kvm]
[  132.172159]  [] kvm_mmu_page_fault+0x64/0x110 [kvm]
[  132.179372]  [] handle_exception+0x1b2/0x430 [kvm_intel]
[  132.187072]  [] vmx_handle_exit+0x1e1/0xc50 [kvm_intel]
...


Thank you for fixing it, Paolo!

Reviewed-by: Xiao Guangrong 

linux-next: Tree for Mar 23

[Stephen Rothwell]

Hi all,

Please do not add any v4.7 related material to your linux-next included
trees until after v4.6-rc1 is released.

Changes since 20160322:

Non-merge commits (relative to Linus' tree): 1734
 1504 files changed, 102964 insertions(+), 28484 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 231 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (01cde1538e1d Merge tag 'nfs-for-4.6-1' of 
git://git.linux-nfs.org/projects/trondmy/linux-nfs)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (deaf7565eb61 ARCv2: ioremap: Support dynamic 
peripheral address space)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b562e44f507e Linux 4.5)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (9ef595d83aea sparc: Convert naked unsigned uses to 
unsigned int)
Merging net/master (9a3492194eca Merge branch 'AF_VSOCK-missed-wakeups')
Merging ipsec/master (215276c0147e xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (ad8ec957f693 wext: unregister_pernet_subsys() on 
notifier registration failure)
Merging sound-current/for-linus (c64c1437afb1 ALSA: hda - Fix missing ELD 
update at unplugging)
Merging pci-current/for-linus (9188269a2e8e Revert "PCI: dra7xx: Mark driver as 
broken")
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (6b5f04b6cf8e Merge branch 'for-4.6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (01cde1538e1d Merge tag 'nfs-for-4.6-1' 
of git://git.linux-nfs.org/projects/trondmy/linux-nfs)
Merging char-misc.current/char-misc-linus (5cd0911a9e0e Merge tag 
'please-pull-pstore' of 
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux)
Merging input-current/for-linus (4d2508a55990 ARM: pxa/raumfeld: use 
PROPERTY_ENTRY_INTEGER to define props)
Merging crypto-current/master (dfe97ad30e8c crypto: marvell/cesa - forward 
devm_ioremap_resource() error code)
Merging ide/master (0d7ef45cdeeb ide: palm_bk3710: test clock rate to avoid 
division by 0)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl er

[PATCH v2] cpufreq: rockchip: add driver

[Feng Xiao]

This driver will directly use cpufreq-dt driver as backend.

As there is not a generic devicetree board file(rockchip.c)
on ARM64 architecture, so remove platform_device_register_simple
in rockchip.c and add a new cpufreq driver to support Rockchip
SoCs.

Signed-off-by: Feng Xiao 
Reviewed-by: Heiko Stuebner 
---
change in v2:
- add rockchip,rk3036 and rockchip,rk3228 to compatibility list

change in v1:
- add compatible check

 arch/arm/mach-rockchip/rockchip.c  |  1 -
 drivers/cpufreq/Kconfig.arm| 10 +++
 drivers/cpufreq/Makefile   |  1 +
 drivers/cpufreq/rockchip-cpufreq.c | 57 ++
 4 files changed, 68 insertions(+), 1 deletion(-)
 create mode 100644 drivers/cpufreq/rockchip-cpufreq.c

diff --git a/arch/arm/mach-rockchip/rockchip.c 
b/arch/arm/mach-rockchip/rockchip.c
index 3f07cc5..beb71da 100644
--- a/arch/arm/mach-rockchip/rockchip.c
+++ b/arch/arm/mach-rockchip/rockchip.c
@@ -74,7 +74,6 @@ static void __init rockchip_dt_init(void)
 {
rockchip_suspend_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
-   platform_device_register_simple("cpufreq-dt", 0, NULL, 0);
 }
 
 static const char * const rockchip_board_dt_compat[] = {
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 14b1f93..1786315 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -97,6 +97,16 @@ config ARM_OMAP2PLUS_CPUFREQ
depends on ARCH_OMAP2PLUS
default ARCH_OMAP2PLUS
 
+config ARM_ROCKCHIP_CPUFREQ
+   tristate "Rockchip CPUfreq driver"
+   depends on ARCH_ROCKCHIP && CPUFREQ_DT
+   select PM_OPP
+   help
+ This adds the CPUFreq driver support for Rockchip SoCs.
+ The driver will directly use cpufreq-dt driver as backend.
+
+ If in doubt, say N.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 9e63fb1..91d8bb7 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_ARM_MT8173_CPUFREQ)  += mt8173-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
+obj-$(CONFIG_ARM_ROCKCHIP_CPUFREQ) += rockchip-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ)  += s3c24xx-cpufreq.o
 obj-$(CONFIG_ARM_S3C24XX_CPUFREQ_DEBUGFS) += s3c24xx-cpufreq-debugfs.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
diff --git a/drivers/cpufreq/rockchip-cpufreq.c 
b/drivers/cpufreq/rockchip-cpufreq.c
new file mode 100644
index 000..9266614
--- /dev/null
+++ b/drivers/cpufreq/rockchip-cpufreq.c
@@ -0,0 +1,57 @@
+/*
+ * Rockchip Platforms CPUFreq Support
+ *
+ * Copyright (C) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Feng Xiao 
+ *
+ * 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 "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; 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 
+
+static const char * const rockchip_compat[] = {
+   "rockchip,rk2928",
+   "rockchip,rk3036",
+   "rockchip,rk3066a",
+   "rockchip,rk3066b",
+   "rockchip,rk3188",
+   "rockchip,rk3228",
+   "rockchip,rk3288",
+   "rockchip,rk3366",
+   "rockchip,rk3368",
+   "rockchip,rk3399",
+};
+
+static int __init rockchip_cpufreq_driver_init(void)
+{
+   struct platform_device *pdev;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(rockchip_compat); i++) {
+   if (of_machine_is_compatible(rockchip_compat[i])) {
+   pdev = platform_device_register_simple("cpufreq-dt",
+  -1, NULL, 0);
+   return PTR_ERR_OR_ZERO(pdev);
+   }
+   }
+
+   return -ENODEV;
+}
+module_init(rockchip_cpufreq_driver_init);
+
+MODULE_AUTHOR("Feng Xiao ");
+MODULE_DESCRIPTION("Rockchip cpufreq driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Re: [RFC 1/4] perf kvm: Enable 'record' on powerpc

[Arnaldo Carvalho de Melo]

Em Tue, Mar 22, 2016 at 04:12:11PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Feb 24, 2016 at 02:37:42PM +0530, Ravi Bangoria escreveu:
> > 'perf kvm record' is not available on powerpc because 'perf' relies on
> > the 'cycles' event (a PMU event) to profile the guest. However, for
> > powerpc, this can't be used from the host because the PMUs are controlled
> > by the guest rather than the host.
> > 
> > There exists a tracepoint 'kvm_hv:kvm_guest_exit' in powerpc which is
> > hit whenever any of the threads exit the guest context. The guest
> > instruction pointer dumped along with this tracepoint data in the field
> > 'pc', can be used as guest instruction pointer.
> > 
> > This patch changes default event as kvm_hv:kvm_guest_exit for recording
> > guest data in host on powerpc. As we are using host event to record guest
> > data, this approach will enable only --guest option of 'perf kvm'. Still
> > --host --guest together won't work.
> 
> It should, i.e. --host --guest should translate to:
> 
>-e cycles:H,kvm_hv:kvm_guest_exit
> 
> I.e. both collect cycles only in the host, and also the tracepoint that
> will allow us to get the guest approximation for the unavailable cycles
> event, no?
> 
> I'm putting the infrastructure work needed for this the perf/cpumode
> branch. More work will be put there soon.

So I took a different path and made perf_evsel__parse_sample set a new
perf_sample.cpumode field, this way we'll end up having just to set a
per-evsel ->post_parse_sample() callback for the event that replaces
"cycles" for PPC guests where we'll just set data->ip and data->cpumode,
the rest of the code remains unchanged.

The changes I made looks useful in itself, as, IIRC more code was
removed than added.

I'll continue tomorrow and will test with the kvm:kvm_exit on x86_64 for
testing, that has:

[root@jouet ~]# perf kvm --guest record -a -e cycles:H,kvm:kvm_exit
sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 2.410 MB perf.data.guest (16076
samples) ]
[root@jouet ~]# perf evlist -i perf.data.guest --trace-fields
cycles:H: (not a tracepoint)
kvm:kvm_exit: trace_fields: exit_reason,guest_rip,isa,info1,info2
[root@jouet ~]#

Enough for me to test this code without requiring access to a PPC64
machine with a guest.

The first approach, more in line with your latest patchkit is at
perf/cpumode.v1, the one I'm working now is at the perf/cpumode branch
in my git tree at:

https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=perf/cpumode

- Arnaldo

> I didn't like the fact that this was touching the common code too much,
> so I'm providing infrastructure for the evsel to be used to obtain the
> cpumode, but trying to constrain the kvm specific bits.
> 
> I.e. we should not touch perf_evlist__add_default, but instead replace
> "cycles" with what is appropriate for 'perf kvm record' when that event
> is specified, be it explicitely or not.
> 
> Doing it this way I _think_ we'll be able to remove the limitation
> stated on your last paragraph above ("Still --host --guest together
> won't work").
> 
> I.e. this, but automatically:
> 
> [root@jouet ~]# perf kvm record -a -e cycles:H,kvm:kvm_exit
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 1.428 MB perf.data.guest (1644
> samples) ]
> 
> [root@jouet ~]# 
> [root@jouet ~]# perf evlist -i perf.data.guest
> cycles:H
> kvm:kvm_exit
> # Tip: use 'perf evlist --trace-fields' to show fields for tracepoint
> # events
> [root@jouet ~]#
> 
> If we look at the verbose output:
> 
> [root@jouet ~]# perf evlist -v -i perf.data.guest
> cycles:H: size: 112, { sample_period, sample_freq }: 4000, sample_type:
> IP|TID|TIME|CPU|PERIOD|IDENTIFIER, read_format: ID, disabled: 1,
> inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, sample_id_all: 1,
> exclude_guest: 1, mmap2: 1, comm_exec: 1
> kvm:kvm_exit: type: 2, size: 112, config: 0x596, { sample_period,
> sample_freq }: 1, sample_type: IP|TID|TIME|CPU|PERIOD|RAW|IDENTIFIER,
> read_format: ID, disabled: 1, inherit: 1, sample_id_all: 1,
> exclude_host: 1
> # Tip: use 'perf evlist --trace-fields' to show fields for tracepoint
> # events
> [root@jouet ~]#
> 
> 
> 
> Which works as well with:
> 
> [root@jouet ~]# perf kvm --guest --host record -a -e cycles:H,kvm:kvm_exit
> ^C[ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 1.387 MB perf.data.kvm (1090 samples)
> ]
> 
> [root@jouet ~]# perf evlist -v -i perf.data.kvm
> cycles:H: size: 112, { sample_period, sample_freq }: 4000, sample_type:
> IP|TID|TIME|CPU|PERIOD|IDENTIFIER, read_format: ID, disabled: 1,
> inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, sample_id_all: 1,
> exclude_guest: 1, mmap2: 1, comm_exec: 1
> kvm:kvm_exit: type: 2, size: 112, config: 0x596, { sample_period,
> sample_freq }: 1, sample_type: IP|TID|TIME|CPU|PERIOD|RAW|IDENTIFIER,
> read_format: ID

Re: RCU stall

[Paul E. McKenney]

On Tue, Mar 22, 2016 at 04:53:26PM -0700, Bart Van Assche wrote:
> On 03/22/2016 01:45 PM, Paul E. McKenney wrote:
> >You are getting a soft lockup as well as an RCU CPU stall warning, so
> >it looks like something is taking a very long time in blk_done_softirq().
> >
> >You have multiple occurrences at different times, so it looks to be
> >a long time as opposed to an infinite time.  Are you perhaps doing
> >something that would make a huge amount of work for blk_done_softirq()?
> >
> >See Documentation/RCU/stallwarn.txt in the kernel source tree for more
> >info on how to debug this sort of thing.
> 
> Hello Paul,
> 
> None of the drivers involved in the test I ran contain RCU code that
> has been changed recently. The block and SCSI subsystems processes
> I/O completions in softirq context but until last week I hadn't seen
> any RCU lockup complaints when I ran an SRP test against a kernel
> with lockdep and several other kernel debugging options enabled.
> This is why I sent an e-mail to you. I have read
> Documentation/RCU/stallwarn.txt after I received your reply but this
> didn't provide me any clue about where to look for the root cause.
> Any further help would be appreciated.

My suggestion would be to check the block/SCSI softirq handler for
event traces.  If there are some, enable them and see what the loop
is doing.  Documentation/trace/ftrace.txt describes how to enable
existing event tracing.

If there is no event tracing, consider adding some in your local
view.  Failing that, there is always printk().  ;-)

Or perhaps you have some sort of debug setup.

Either way, the next step is to work out why that CPU is spending
so much time in that loop.

Thanx, Paul

[lkp] [chrdev] af427b8e3a: kmsg.ide-tape:Failed_to_register_chrdev_interface

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
chrdev-warn
commit af427b8e3a4e1fc4f7e893a617acf9520cdd616c ("chrdev: allocate dynamic 
chardevs in all unused holes")

As below, the log "ide-tape: Failed to register chrdev interface" showed with 
your commit.

[5.180939] hdc: QEMU DVD-ROM, ATAPI CD/DVD-ROM drive
[5.853022] hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO0
[5.854273] hdc: MWDMA2 mode selected
[5.855154] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[5.856004] ide1 at 0x170-0x177,0x376 on irq 15
[5.862154] ide-gd driver 1.18
[5.862765] ide-tape: Failed to register chrdev interface
[5.863789] Loading iSCSI transport class v2.0-870.
[5.881544] fnic: Cisco FCoE HBA Driver, ver 1.6.0.17a
[5.882531] fnic: Successfully Initialized Trace Buffer
[5.884415] fnic: Successfully Initialized FC_CTLR Trace Buffer
[5.894058] Loading Adaptec I2O RAID: Version 2.4 Build 5go
[5.895042] Detecting Adaptec I2O RAID controllers...
[5.895900] Adaptec aacraid driver 1.2-1[41010]-ms
[5.897116] qla2xxx [:00:00.0]-0005: : QLogic Fibre Channel HBA Driver: 
8.07.00.26-k.
[5.898534] csiostor: Chelsio FCoE driver 1.0.0
[5.899479] megasas: 06.808.16.00-rc1
[5.900172] mpt3sas version 09.102.00.00 loaded
[5.901225] 3ware 9000 Storage Controller device driver for Linux 
v2.26.02.014.
[5.902498] ipr: IBM Power RAID SCSI Device Driver version: 2.6.3 (October 
17, 2015)
[5.903896] libcxgbi:libcxgbi_init_module: Chelsio iSCSI driver library 
libcxgbi v0.9.1-ko (Apr. 2015)
[5.905462] libcxgbi:libcxgbi_init_module: tag itt 0x1fff, 13 bits, age 0xf, 
4 bits.
[5.919807] libcxgbi:ddp_setup_host_page_size: system PAGE 4096, ddp idx 0.
[5.920991] Chelsio T3 iSCSI Driver cxgb3i v2.0.1-ko (Apr. 2015)





FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-acpi-redef/gcc-5/af427b8e3a4e1fc4f7e893a617acf9520cdd616c/vmlinuz-4.5.0-rc2-00207-gaf427b8
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-28/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-acpi-redef-af427b8e3a4e1fc4f7e893a617acf9520cdd616c-20160319-21157-140zqnh-0.yaml
 ARCH=x86_64 kconfig=x86_64-acpi-redef 
branch=linux-devel/devel-catchup-201603190348 
commit=af427b8e3a4e1fc4f7e893a617acf9520cdd616c 
BOOT_IMAGE=/pkg/linux/x86_64-acpi-redef/gcc-5/af427b8e3a4e1fc4f7e893a617acf9520cdd616c/vmlinuz-4.5.0-rc2-00207-gaf427b8
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-acpi-redef/gcc-5/af427b8e3a4e1fc4f7e893a617acf9520cdd616c/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-28::dhcp drbd.minor_count=8'  -initrd 
/fs/sdc1/initrd-vm-kbuild-yocto-x86_64-28 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sdc1/disk0-vm-kbuild-yocto-x86_64-28,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-28 -serial 
file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-28 -daemonize -display none 
-monitor null 




Thanks,
Xiaolong Ye
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General se

[PATCH 1/2] x86/apic: remove declaration of unused hw_nmi_is_cpu_stuck

[Yaowei Bai]

Commit 10f9014912 ("x86: Cleanup hw_nmi.c cruft") removed unused
code in the hw_nmi.c file because of the redesign of the hardlockup
watchdog but left declaration of hw_nmi_is_cpu_stuck in linux/nmi.h,
so remvoe it.

Signed-off-by: Yaowei Bai 
---
 include/linux/nmi.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/linux/nmi.h b/include/linux/nmi.h
index 7ec5b86..4630eea 100644
--- a/include/linux/nmi.h
+++ b/include/linux/nmi.h
@@ -65,7 +65,6 @@ static inline bool trigger_allbutself_cpu_backtrace(void)
 #endif
 
 #ifdef CONFIG_LOCKUP_DETECTOR
-int hw_nmi_is_cpu_stuck(struct pt_regs *);
 u64 hw_nmi_get_sample_period(int watchdog_thresh);
 extern int nmi_watchdog_enabled;
 extern int soft_watchdog_enabled;
-- 
1.9.1

[GIT PULL] clk changes for v4.6

[Stephen Boyd]

The following changes since commit a0d54c3899aaeb047969d9479263c6bcf385c331:

  clk: ti: omap3+: dpll: use non-locking version of clk_get_rate (2016-02-22 
14:03:02 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus

for you to fetch changes up to 4d3ac6662452060721599a3392bc2f524af984cb:

  clk: bcm2835: fix check of error code returned by devm_ioremap_resource() 
(2016-03-15 18:14:11 -0700)


The clk changes for this release cycle are mostly dominated by
new device support in terms of LoC, but there has been some cleanup
in the core as well as the usual minor clk additions to various
drivers.

Core:

 - parent tracking has been simplified

 - CLK_IS_ROOT is now a no-op flag, cleaning up drivers has started

 - of_clk_init() doesn't consider disabled DT nodes anymore

 - clk_unregister() had an error path bug squashed

 - of_clk_get_parent_count() has been fixed to only return unsigned ints

 - HAVE_MACH_CLKDEV is removed now that the last arch user (ARM) is gone

New Drivers:

 - NXP LPC18xx creg

 - QCOM IPQ4019 GCC

 - TI dm814x ADPLL

 - i.MX6QP

Updates:

 - Cyngus audio clks found on Broadcom iProc devices

 - Non-critical fixes for BCM2385 PLLs

 - Samsung exynos5433 updates for clk id errors, HDMI support,
   suspend/resume simplifications

 - USB, CAN, LVDS, and FCP clks on shmobile devices

 - sunxi got support for more clks on new SoCs and went through a minor
   refactoring/rewrite to use a simpler factor clk construct

 - rockchip added some more clk ids and added suport for fraction dividers

 - QCOM GDSCs in msm8996

 - A new devm helper to make adding custom actions simpler (acked by Greg)


Alexander Kochetkov (2):
  clk: rockchip: add hclk_cpubus to the list of rk3188 critical clocks
  clk: rockchip: Allow sclk_i2s0 and i2s0_frac to change their parents rate 
on rk3188

Anatolij Gustschin (1):
  clk: imx: correct pwm7 clock name in driver for i.MX6UL

Andre Przywara (4):
  clk: sunxi: improve error reporting for the mux clock
  clk: sunxi: improve mux_clk error handling and reporting
  clk: sunxi: improve divider_clk error handling and reporting
  clk: sunxi: Improve divs_clk error handling and reporting

Andreas Färber (1):
  clk: meson: Fix meson_clk_register_clks() signature type mismatch

Andrew F. Davis (1):
  clk: Make of_clk_get_from_provider() available to modules

Andrzej Hajda (3):
  clk: vt8500: fix sign of possible PLL values
  clk/samsung: exynos5433: add definitions of HDMI-PHY output clocks
  clk/samsung: exynos5433: add pclk_decon clock

Archit Taneja (1):
  clk: qcom: Fix pre-divider usage for pixel RCG

Arnd Bergmann (4):
  clk: st: avoid uninitialized variable use
  clk: sunxi: don't mark sun6i_ar100_data __initconst
  clk: vt8500: don't return possibly uninitialized data
  clk: socfpga: fix __init annotation

Bai Ping (1):
  clk: imx: Add clock support for imx6qp

Caesar Wang (2):
  clk: rockchip: add id of the tsadc clock found on rk3228 SoCs
  clk: rockchip: add the tsadc clocks found on rk3228 SoCs

Chen-Yu Tsai (11):
  clk: sunxi: usb: Sort clk providers by chip family and name
  clk: sunxi: factors: Make struct clk_factors_config table const
  clk: sunxi: factors: Add clk cleanup in sunxi_factors_register() error 
path
  clk: sunxi: factors: Add unregister function
  clk: sunxi: factors: Consolidate get_factors parameters into a struct
  clk: sunxi: factors: Support custom formulas
  clk: sunxi: factors: Drop round_rate from clk ops
  clk: sunxi: rewrite sun6i-a31-ahb1-clk using factors clk with custom 
recalc
  clk: sunxi: rewrite sun6i-ar100 using factors clk
  clk: sunxi: rewrite sun8i-a23-mbus-clk using the simpler composite clk
  clk: sunxi: Fix sun8i-a23-apb0-clk divider flags

Dinh Nguyen (1):
  clk: socfpga: allow for multiple parents on Arria10 periph clocks

Dirk Behme (1):
  clk: shmobile: r8a7795: Add SD divider support

Elaine Zhang (1):
  clk: rockchip: include downstream muxes into fractional dividers on rk3368

Eric Anholt (2):
  clk: bcm2835: Fix setting of PLL divider clock rates
  clk: bcm2835: Reuse CLK_DIVIDER_MAX_AT_ZERO for recalc_rate()

Geert Uytterhoeven (3):
  clk: shmobile: cpg-mssr: Update serial port clock in example
  clk: shmobile: div6: Fix .recalc_rate() using a stale divisor
  clk: Ignore disabled DT clock providers

Heiko Stuebner (10):
  clk: rockchip: rk3368: fix cpuclk mux bit of big cpu-cluster
  clk: rockchip: rk3368: fix cpuclk core dividers
  clk: rockchip: rk3368: fix parents of video encoder/decoder
  clk: rockchip: rk3368: fix hdmi_cec gate-register
  clk: rockchip: fix usbphy-related clocks
  Merge branch 'v4.6-shared/clkids' into v4.6-c

Re: [PATCH] Revert "Staging: lustre: o2iblnd: Use sizeof type *pointer instead of sizeof type."

[Greg Kroah-Hartman]

On Tue, Mar 22, 2016 at 06:21:04PM -0400, James Simmons wrote:
> Latest testing fails when using ko2iblnd. It was tracked down
> to commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.
> 
> This reverts commit 4671a026616df26000f7d8ad2f2ea4b6de79263c.
> ---
>  .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
> b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index 89f9390..0d32e65 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@ -1968,7 +1968,7 @@ static int kiblnd_net_init_pools(kib_net_t *net, __u32 
> *cpts, int ncpts)
>*/
>  
>   net->ibn_fmr_ps = cfs_percpt_alloc(lnet_cpt_table(),
> -sizeof(*net->ibn_fmr_ps));
> +sizeof(kib_fmr_poolset_t));

Ok, why is this revert needed?  Please give me a big huge comment about
why this is not the same size of the variable being assigned to it,
otherwise someone else is going to come along and make the exact same
change again.

>   if (!net->ibn_fmr_ps) {
>   CERROR("Failed to allocate FMR pool array\n");
>   rc = -ENOMEM;
> @@ -1992,7 +1992,7 @@ static int kiblnd_net_init_pools(kib_net_t *net, __u32 
> *cpts, int ncpts)
>  
>   create_tx_pool:
>   net->ibn_tx_ps = cfs_percpt_alloc(lnet_cpt_table(),
> -   sizeof(*net->ibn_tx_ps));
> +   sizeof(kib_tx_poolset_t));

Same here, why is this code wrong?

thanks,

greg k-h

[lkp] [x86/mm] e5809dfe26: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:617

[kernel test robot]

]  #0:  (&cgroup_threadgroup_rwsem){.+.+.+}, at: 
[] copy_process+0x546/0x18b8
[   20.105297]  #1:  (&mm->mmap_sem){++}, at: [] 
copy_process+0xd41/0x18b8
[   20.108847] CPU: 0 PID: 2071 Comm: udevd Not tainted 
4.5.0-rc2-00216-ge5809df #85
[   20.111694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   20.114691]   88000c3dbc80 81520f7f 
88000c39aa40
[   20.118032]  88000c3dbca8 810be484 820d3bcf 
0269
[   20.121303]   88000c3dbcd0 810be500 
88000c30dfa0
[   20.124604] Call Trace:
[   20.125970]  [] dump_stack+0x4b/0x63
[   20.127606]  [] ___might_sleep+0x1f9/0x200
[   20.129410]  [] __might_sleep+0x75/0x7c
[   20.131124]  [] mutex_lock_nested+0x3e/0x35f
[   20.132948]  [] ? kvm_clock_read+0x25/0x2e
[   20.134798]  [] ? kvm_sched_clock_read+0x9/0x12
[   20.136590]  [] ? sched_clock+0x9/0xd
[   20.138323]  [] propagate_tlb_flush+0x27/0xa6
[   20.140291]  [] ? propagate_tlb_flush+0x27/0xa6
[   20.142244]  [] flush_tlb_mm_range+0x1aa/0x213
[   20.144105]  [] copy_process+0x1008/0x18b8
[   20.145945]  [] _do_fork+0xbd/0x5d4
[   20.147686]  [] ? retint_user+0x18/0x20
[   20.149402]  [] ? trace_hardirqs_on_caller+0x17d/0x199
[   20.151373]  [] ? trace_hardirqs_on_thunk+0x17/0x19
[   20.153309]  [] SyS_clone+0x19/0x1b
[   20.155064]  [] entry_SYSCALL_64_fastpath+0x12/0x72
[   21.094778] BUG: sleeping function called from invalid context at 
kernel/locking/mutex.c:617
[   21.100371] in_atomic(): 1, irqs_disabled(): 0, pid: 2292, name: mount.sh
[   21.103857] 2 locks held by mount.sh/2292:
[   21.106265]  #0:  (&cgroup_threadgroup_rwsem){.+.+.+}, at: 
[] copy_process+0x546/0x18b8
[   21.112531]  #1:  (&mm->mmap_sem){++}, at: [] 
copy_process+0xd41/0x18b8
[   21.118074] CPU: 0 PID: 2292 Comm: mount.sh Not tainted 
4.5.0-rc2-00216-ge5809df #85
[   21.122721] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   21.127422]   88000b07fc80 81520f7f 
88000b7f
[   21.132282]  88000b07fca8 810be484 820d3bcf 
0269
[   21.137007]   88000b07fcd0 810be500 
889634a0
[   21.141808] Call Trace:
[   21.143582]  [] dump_stack+0x4b/0x63
[   21.146393]  [] ___might_sleep+0x1f9/0x200
[   21.149581]  [] __might_sleep+0x75/0x7c
[   21.152686]  [] mutex_lock_nested+0x3e/0x35f
[   21.155795]  [] ? kvm_clock_read+0x25/0x2e
[   21.158841]  [] ? kvm_sched_clock_read+0x9/0x12
[   21.162026]  [] ? sched_clock+0x9/0xd
[   21.164890]  [] propagate_tlb_flush+0x27/0xa6
[   21.168325]  [] ? propagate_tlb_flush+0x27/0xa6
[   21.172010]  [] flush_tlb_mm_range+0x1aa/0x213
[   21.175213]  [] copy_process+0x1008/0x18b8
[   21.178618]  [] _do_fork+0xbd/0x5d4
[   21.181445]  [] ? __might_fault+0x40/0x8d
[   21.184399]  [] ? lockdep_sys_exit_thunk+0x12/0x14
[   21.187857]  [] SyS_clone+0x19/0x1b
[   21.190601]  [] entry_SYSCALL_64_fastpath+0x12/0x72
[   21.214523] blk_update_request: I/O error, dev fd0, sector 0


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu SandyBridge -kernel 
/pkg/linux/x86_64-nfsroot/gcc-5/e5809dfe266f4ab66b20db540663298d909c7b8c/vmlinuz-4.5.0-rc2-00216-ge5809df
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-x86_64-34/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-nfsroot-e5809dfe266f4ab66b20db540663298d909c7b8c-20160322-8447-s50ff4-5.yaml
 ARCH=x86_64 kconfig=x86_64-nfsroot 
branch=linux-devel/devel-catchup-201603221233 
commit=e5809dfe266f4ab66b20db540663298d909c7b8c 
BOOT_IMAGE=/pkg/linux/x86_64-nfsroot/gcc-5/e5809dfe266f4ab66b20db540663298d909c7b8c/vmlinuz-4.5.0-rc2-00216-ge5809df
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-nfsroot/gcc-5/e5809dfe266f4ab66b20db540663298d909c7b8c/5
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-kbuild-yocto-x86_64-34::dhcp drbd.minor_count=8'  -initrd 
/fs/sda1/initrd-vm-kbuild-yocto-x86_64-34 -m 320 -smp 1 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/sda1/disk0-vm-kbuild-yocto-x86_64-34,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-kbuild-yocto-x86_64-34 -serial 
file:/dev/shm/kboot/serial-vm-kbuild-yocto-x86_64-34 -daemonize -display none 
-monitor null 


Thanks,
Xiaolong Ye
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x

[RFC] high preempt off latency in vfree path

[Joel Fernandes]

Hi,

I'm seeing on my system with some real time audio requirements, I'm seeing the preemptirqsoff 
tracer complaining that preempt was off for 17ms in the vfree path. Since we have requirements 
of 8ms scheduling this seems awfully bad.


The tracer output showed __free_vmap_area was about 7300 times. Can we do better here? I have 
proposed 2 potential fixes here, any thoughts on which one's better?


Here's the path that blocks preempt (full latency ftrace output uploaded to 
http://raw.codepile.net/pile/OWNpvKkB.js)


 => preempt_count_sub
 => _raw_spin_unlock
 => __purge_vmap_area_lazy
 => free_vmap_area_noflush
 => remove_vm_area
 => __vunmap
 => vfree
 => n_tty_close
 => tty_ldisc_close.isra.1
 => tty_ldisc_kill
 => tty_ldisc_release
 => tty_release

Here are the approaches:
(1)
One is we reduce the number of lazy_max_pages (right now its around 32MB per 
core worth of pages).

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index aa3891e..2720f4f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -564,7 +564,7 @@ static unsigned long lazy_max_pages(void)

log = fls(num_online_cpus());

-   return log * (32UL * 1024 * 1024 / PAGE_SIZE);
+   return log * (8UL * 1024 * 1024 / PAGE_SIZE);
 }


(2) Second alternative approach I am thinking is to change purge_lock into a mutex and then 
move the vmap_area spinlock around the free_vmap_area call. Thus giving the scheduler a chance 
to put something else on the CPU in between free_vmap_area calls. That would look like:


diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index aa3891e..9565d72 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -594,7 +594,7 @@ void set_iounmap_nonlazy(void)
 static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
int sync, int force_flush)
 {
-   static DEFINE_SPINLOCK(purge_lock);
+   static DEFINE_MUTEX(purge_lock);
LIST_HEAD(valist);
struct vmap_area *va;
struct vmap_area *n_va;
@@ -606,10 +606,10 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
unsigned long *end,
 * the case that isn't actually used at the moment anyway.
 */
if (!sync && !force_flush) {
-   if (!spin_trylock(&purge_lock))
+   if (!mutex_trylock(&purge_lock))
return;
} else
-   spin_lock(&purge_lock);
+   mutex_lock(&purge_lock);

if (sync)
purge_fragmented_blocks_allcpus();
@@ -636,12 +636,13 @@ static void __purge_vmap_area_lazy(unsigned long *start, 
unsigned long *end,
flush_tlb_kernel_range(*start, *end);

if (nr) {
-   spin_lock(&vmap_area_lock);
-   list_for_each_entry_safe(va, n_va, &valist, purge_list)
+   list_for_each_entry_safe(va, n_va, &valist, purge_list) {
+   spin_lock(&vmap_area_lock);
__free_vmap_area(va);
+   spin_unlock(&vmap_area_lock);
+   }
-   spin_unlock(&vmap_area_lock);

}
-   spin_unlock(&purge_lock);
+   mutex_unlock(&purge_lock);
 }

 /*

Thanks!
Joel

[PATCH 2/2] x86/dma: is_device_dma_capable can be boolean

[Yaowei Bai]

This patch makes is_device_dma_capable return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/dma-mapping.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 5e45cf9..175c20f 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -81,7 +81,7 @@ static inline int valid_dma_direction(int dma_direction)
(dma_direction == DMA_FROM_DEVICE));
 }
 
-static inline int is_device_dma_capable(struct device *dev)
+static inline bool is_device_dma_capable(struct device *dev)
 {
return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
 }
-- 
1.9.1

Re: [PATCH v4 19/20] x86, kaslr: Allow random address to be below loaded address

[Baoquan He]

On 03/22/16 at 12:54pm, Kees Cook wrote:
> On Tue, Mar 22, 2016 at 12:32 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> >
> > Now new randomized output can only be chosen from regions above loaded
> > address. In this case, for bootloaders like kexec which always loads
> > kernel near the end of ram, it doesn't do randomization at all. Or kernel
> > is loaded in a very big starting address, we should not give up that area
> > is loaded in a very large address, then the area below the large loaded
> > address will be given up. This is not reasonable.
> >
> > With correct tracking in mem_avoid  we can allow random output below
> > loaded address. With this change, though kexec can get random ouput
> > below its loaded address of kernel.
> >
> > Now we just pick 512M as min_addr. If kernel loaded address is bigger than
> > 512M, E.g 8G. Then [512M, 8G) can be added into random output candidate 
> > area.
> >
> > Signed-off-by: Yinghai Lu 
> > ---
> >  arch/x86/boot/compressed/aslr.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/aslr.c 
> > b/arch/x86/boot/compressed/aslr.c
> > index ddfc3d0..d072ca7 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -446,7 +446,8 @@ void choose_kernel_location(unsigned char *input,
> > unsigned long output_size,
> > unsigned char **virt_offset)
> >  {
> > -   unsigned long random;
> > +   unsigned long random, min_addr;
> > +
> > *virt_offset = (unsigned char *)LOAD_PHYSICAL_ADDR;
> >
> >  #ifdef CONFIG_HIBERNATION
> > @@ -467,8 +468,13 @@ void choose_kernel_location(unsigned char *input,
> > mem_avoid_init((unsigned long)input, input_size,
> >(unsigned long)*output);
> >
> > +   /* start from 512M */
> > +   min_addr = (unsigned long)*output;
> > +   if (min_addr > (512UL<<20))
> > +   min_addr = 512UL<<20;
> 
> The goal is to find a minimum address? I'm not sure this comment makes
> sense. Shouldn't this be:
> 
> /* Lower minimum to 512M. */
>min_addr = min_t(unsigned long, *output, 512UL << 20);
> 
> Or something like that?

Yes, the goal is to lower minimum to 512M. It's better to change it to
"Lower minimum to 512M" as you suggested. I will resend a new one with
this update into this thread.

Thanks a lot for your great suggestion for patch log, code change and
patch rearranging, and also appreciate your encouragement and patience.

Thanks
Baoquan

> 
> > +
> > /* Walk e820 and find a random address. */
> > -   random = find_random_phy_addr((unsigned long)*output, output_size);
> > +   random = find_random_phy_addr(min_addr, output_size);
> > if (!random)
> > debug_putstr("KASLR could not find suitable E820 
> > region...\n");
> > else {
> > --
> > 2.5.0
> >
> 
> -Kees
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH 3/3] staging: dgnc: use tty_alloc_driver instead of kcalloc

[DaeSeok Youn]

2016-03-22 22:02 GMT+09:00 Greg KH :
> On Tue, Mar 22, 2016 at 04:40:24PM +0900, DaeSeok Youn wrote:
>> 2016-03-22 6:05 GMT+09:00 Greg KH :
>> > On Mon, Mar 14, 2016 at 01:29:00PM +0900, Daeseok Youn wrote:
>> >> the tty_alloc_driver() can allocate memory for ttys and termios.
>> >> And also it can release allocated memory easly with using
>> >> put_tty_driver().
>> >>
>> >> Signed-off-by: Daeseok Youn 
>> >
>> > But you broke the driver in the previous patch, you can't do that, each
>> > patch has to be 'stand-alone'.
>> I am not sure about 'stand-alone'. this patch has to have dependency on
>> previous patch..
>
> Yes, that is ok, but your first patch said it was just function
> renaming, and then the second patch broke functionality, and the third
> fixed it up.  You should have a working kernel at each step in your
> patch series, which you did not.
I got it. So I start over from fixing coding style of dgnc module like
I was doing
dgap module.

>
>> And I have a question not related this thread,
>> I had been waiting my patches merged and also have other patches on
>> same file(in case of dgnc).
>> I couldn't send next patches until previous patches are taken.
>> How can I manage my patches for this case?
>
> Just send your new patches and say they depend on the previous ones.  My
> staging patch queue is almost empty at the moment so odds are I have
> already applied, or rejected them.
thanks for your explanation. :-)

I will try to make patches more carefully.

regards,
Daeseok.
>
> thanks,
>
> greg k-h

Re: [PATCH v5] acpi: Issue _OSC call for native thermal interrupt handling

[Rafael J. Wysocki]

On Wed, Mar 23, 2016 at 2:05 AM, Srinivas Pandruvada
 wrote:
> There are several reports of freeze on enabling HWP (Hardware PStates)
> feature on Skylake based systems by Intel P states driver. The root
> cause is identified as the HWP interrupts causing BIOS code to freeze.
> HWP interrupts uses thermal LVT.
> Linux natively handles thermal interrupts, but in Skylake based systems
> SMM will take control of thermal interrupts. This is a problem for several
> reasons:
> - It is freezing in BIOS when tries to handle thermal interrupt, which
> will require BIOS upgrade
> - With SMM handling thermal we loose all the reporting features of
> Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
> - Some thermal drivers like x86-package-temp driver depends on the thermal
> threshold interrupts
> - The HWP interrupts are useful for debugging and tuning performance
>
> So we need native handling of thermal interrupts. This requires some
> way to inform SMM that OS can handle thermal interrupts. This can be
> done by using _OSC/_PDC under processor scope very early in ACPI
> initialization flow.
> The bit 12 of _OSC/_PDC in processor scope defines whether OS supports
> handling of native interrupts for Collaborative Processor Performance
> Control (CPPC) notifications. Since HWP is a implementation of CPPC,
> setting this bit is equivalent to inform SMM that OS is capable of
> handling thermal interrupts.
> Refer to this document for details on _OSC/_PDC
> http://www.intel.com/content/www/us/en/standards/processor-vendor-
> specific-acpi-specification.html
>
> This change introduces a new function acpi_early_processor_set_osc(),
> which walks acpi name space and finds acpi processor object and
> set capability via _OSC method.
>
> Also this change writes HWP status bits to 0 to clear any HWP status
> bits in intel_thermal_interrupt().
>
> Signed-off-by: Srinivas Pandruvada 
> ---
> v5:
> No code change. Changed commit message to explain HWP is a implementation
> of CPPC.
>
> v4:
> Suggestion by Boris for removing use of intermediate variable for
> clearing HWP status and using boot_cpu_has instead of static_cpu_has
>
> v3:
> - Added CONFIG_X86 around static_cpu_has() to fix compile error on
> ARCH=ia64, reported by kbuild test robot
> - return AE_CTRL_TERMINATE to terminate acpi name walk space, when _OSC
> is set already once.
> v2:
> Unnecessary newline was introduced, removed that in acpi_processor.c
>
>  arch/x86/kernel/cpu/mcheck/therm_throt.c |  3 ++
>  drivers/acpi/acpi_processor.c| 47 
> 
>  drivers/acpi/bus.c   |  3 ++
>  drivers/acpi/internal.h  |  2 ++
>  4 files changed, 55 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c 
> b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> index 0b445c2..ac780ca 100644
> --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
> @@ -384,6 +384,9 @@ static void intel_thermal_interrupt(void)
>  {
> __u64 msr_val;
>
> +   if (static_cpu_has(X86_FEATURE_HWP))
> +   wrmsrl_safe(MSR_HWP_STATUS, 0);
> +
> rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
>
> /* Check for violation of core thermal thresholds*/
> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> index b5e54f2..52934d9 100644
> --- a/drivers/acpi/acpi_processor.c
> +++ b/drivers/acpi/acpi_processor.c
> @@ -491,6 +491,53 @@ static void acpi_processor_remove(struct acpi_device 
> *device)
>  }
>  #endif /* CONFIG_ACPI_HOTPLUG_CPU */
>
> +#ifdef CONFIG_X86
> +static bool acpi_hwp_native_thermal_lvt_set;
> +static acpi_status acpi_set_hwp_native_thermal_lvt_osc(acpi_handle handle,

That can be __init, can't it?

> +  u32 lvl, void *context,
> +  void **rv)
> +{
> +   u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
> +   u32 capbuf[2];
> +   struct acpi_osc_context osc_context = {
> +   .uuid_str = sb_uuid_str,
> +   .rev = 1,
> +   .cap.length = 8,
> +   .cap.pointer = capbuf,
> +   };
> +
> +   if (acpi_hwp_native_thermal_lvt_set)
> +   return AE_CTRL_TERMINATE;
> +
> +   capbuf[0] = 0x;
> +   capbuf[1] = 0x1000; /* set bit 12 */
> +
> +   if (ACPI_SUCCESS(acpi_run_osc(handle, &osc_context))) {
> +   acpi_hwp_native_thermal_lvt_set = true;
> +   kfree(osc_context.ret.pointer);
> +   }
> +
> +   return AE_OK;
> +}
> +
> +void acpi_early_processor_set_osc(void)

And that can be __init too?

> +{
> +   if (boot_cpu_has(X86_FEATURE_HWP)) {
> +   acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
> +   ACPI_UINT32_MAX,
> +   acpi_set_hwp_native_thermal_lvt_osc,
> +   NULL, N

Re: [PATCH v3 00/23] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

[Finn Thain]

On Tue, 22 Mar 2016, Ondrej Zary wrote:

> Tested on HP C2502 (53C400A chip), Canon FG2-5202 (53C400 chip) and 
> DTC-3181L (DTCT-436P chip) ISA cards - everything works fine!
> 
> Thanks.

Thanks for testing, Ondrej.

> 
> Tested-by: Ondrej Zary 

Hannes, would you please take a look at patches 04/23, 14/23, 20/23 and 
23/23 when convenient? These four patches need a "reviewed-by" tag.

-- 

[PATCH] vlan: propagate gso_min_segs

[Haishuang Yan]

vlan drivers lack proper propagation of gso_min_segs from lower device.

Signed-off-by: Haishuang Yan 
---
 drivers/net/ipvlan/ipvlan_main.c | 2 ++
 drivers/net/macvlan.c| 1 +
 net/8021q/vlan.c | 1 +
 net/8021q/vlan_dev.c | 1 +
 4 files changed, 5 insertions(+)

diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index 57941d3..72a2517 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -120,6 +120,7 @@ static int ipvlan_init(struct net_device *dev)
dev->features |= NETIF_F_LLTX;
dev->gso_max_size = phy_dev->gso_max_size;
dev->gso_max_segs = phy_dev->gso_max_segs;
+   dev->gso_min_segs = phy_dev->gso_min_segs;
dev->hard_header_len = phy_dev->hard_header_len;
 
ipvlan_set_lockdep_class(dev);
@@ -594,6 +595,7 @@ static int ipvlan_device_event(struct notifier_block 
*unused,
ipvlan->dev->features = dev->features & IPVLAN_FEATURES;
ipvlan->dev->gso_max_size = dev->gso_max_size;
ipvlan->dev->gso_max_segs = dev->gso_max_segs;
+   ipvlan->dev->gso_min_segs = dev->gso_min_segs;
netdev_features_change(ipvlan->dev);
}
break;
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..72991e9 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -1534,6 +1534,7 @@ static int macvlan_device_event(struct notifier_block 
*unused,
list_for_each_entry(vlan, &port->vlans, list) {
vlan->dev->gso_max_size = dev->gso_max_size;
vlan->dev->gso_max_segs = dev->gso_max_segs;
+   vlan->dev->gso_min_segs = dev->gso_min_segs;
netdev_update_features(vlan->dev);
}
break;
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index a1e273a..01a4de1 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -312,6 +312,7 @@ static void vlan_transfer_features(struct net_device *dev,
 
vlandev->gso_max_size = dev->gso_max_size;
vlandev->gso_max_segs = dev->gso_max_segs;
+   vlandev->gso_min_segs = dev->gso_min_segs;
 
if (vlan_hw_offload_capable(dev->features, vlan->vlan_proto))
vlandev->hard_header_len = dev->hard_header_len;
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index e7e6257..752263d 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -552,6 +552,7 @@ static int vlan_dev_init(struct net_device *dev)
 NETIF_F_GSO_SOFTWARE;
dev->gso_max_size = real_dev->gso_max_size;
dev->gso_max_segs = real_dev->gso_max_segs;
+   dev->gso_min_segs = real_dev->gso_min_segs;
if (dev->features & NETIF_F_VLAN_FEATURES)
netdev_warn(real_dev, "VLAN features are set incorrectly.  
Q-in-Q configurations may not work correctly.\n");
 
-- 
1.8.3.1

[PATCH] gre: fix return value of gre_rcv

[Haishuang Yan]

Dropped skb's should be documented by an appropriate return value.
Use the correct NET_RX_DROP and NET_RX_SUCCESS values for that reason.

Signed-off-by: Haishuang Yan 
---
 net/ipv4/ip_gre.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 31936d3..1dc0cdb 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -432,12 +432,12 @@ static int gre_rcv(struct sk_buff *skb)
goto drop;
 
if (ipgre_rcv(skb, &tpi) == PACKET_RCVD)
-   return 0;
+   return NET_RX_SUCCESS;
 
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
 drop:
kfree_skb(skb);
-   return 0;
+   return NET_RX_DROP;
 }
 
 static __sum16 gre_checksum(struct sk_buff *skb)
-- 
1.8.3.1

Re: [NEW DRIVER V6 0/7] DA9058 PMIC - please comment on this new driver

[Alexandre Belloni]

Hi Anthony, Steve,

This driver has been submitted a while ago and reached v6 but still had
a few comments. Do you still have some interest in seeing it being
accepted?

On 19/04/2013 at 17:56:29 +0100, Anthony Olech wrote :
> This is submission attempt number 6 to have this driver included in
> the linux kernel source tree. This is the driver for the Dialog DA9058.
> 
> The DA9058 is a low power Power Management Integrated Circuit with extra
> functionality. It is a Multi Function Device controlled only from an I2C
> bus whose components can raise an interrupt request on a single IRQ line.
> 
> The driver for the DA9058 consists of a core (i2c) device driver that
> instantiates the individual component device drivers for:
> 
> adc - 5 ADC channels
> gpio - 2 available pins
> onkey - 1 device
> regulator - 4 BUCKS, 19 LDO and 3 fixed
> rtc - low power clock
> hwmon - 5 monitored voltages/temperatures
> 
> All the above six component device drivers depend on the 'core'
> component driver, which is number one in the patch series.
> 
> Each component driver for the Dialog DA9058 will follow as an e-mail
> patch relative to 
> 
> This driver has been tested on a Samsung SMDK6410 connected to a Dialog
> DA9058 Evaluation Board via one GPIO and a 3-wire I2C connection.
> 
> All the components can be builtin to the kernel or compiled as modules.
> As far as I can tell, all the latest APIs both for the core driver and
> all the component drivers have been adhered to, but if I have missed
> something please let me know.
> 
> In a clean check out of next-20130419 in linux-next, each patch has been
> applied individually and the final result has been built successfully.
> 
> Many thanks,
> Anthony Olech, Dialog Semiconductor Ltd.
> 
> Tony Olech (at Home) (7):
>   drivers/mfd: DA9058 MFD core driver
>   drivers/iio/adc: DA9058 ADC driver
>   drivers/input/misc: DA9058 ONKEY driver
>   drivers/rtc: DA9058 RTC driver
>   drivers/gpio: DA9058 GPIO driver
>   drivers/hwmon: DA9058 HWMON driver
>   drivers/regulator: DA9058 REGULATOR driver
> 
>  Documentation/hwmon/da9058   |   38 ++
>  drivers/gpio/Kconfig |   12 +
>  drivers/gpio/Makefile|1 +
>  drivers/gpio/gpio-da9058.c   |  376 ++
>  drivers/hwmon/Kconfig|   10 +
>  drivers/hwmon/Makefile   |3 +-
>  drivers/hwmon/da9058-hwmon.c |  330 
>  drivers/iio/adc/Kconfig  |   12 +
>  drivers/iio/adc/Makefile |1 +
>  drivers/iio/adc/da9058-adc.c |  396 ++
>  drivers/input/misc/Kconfig   |   10 +
>  drivers/input/misc/Makefile  |1 +
>  drivers/input/misc/da9058_onkey.c|  173 +++
>  drivers/mfd/Kconfig  |   17 +
>  drivers/mfd/Makefile |3 +
>  drivers/mfd/da9058-core.c|   73 +++
>  drivers/mfd/da9058-i2c.c |   96 
>  drivers/mfd/da9058-info.c|  939 
> ++
>  drivers/mfd/da9058-irq.c |   56 ++
>  drivers/regulator/Kconfig|   11 +
>  drivers/regulator/Makefile   |1 +
>  drivers/regulator/da9058-regulator.c |  199 +++
>  drivers/rtc/Kconfig  |   10 +
>  drivers/rtc/Makefile |1 +
>  drivers/rtc/rtc-da9058.c |  448 
>  include/linux/mfd/da9058/adc.h   |   18 +
>  include/linux/mfd/da9058/bat.h   |   33 ++
>  include/linux/mfd/da9058/codec.h |   22 +
>  include/linux/mfd/da9058/conf.h  |   22 +
>  include/linux/mfd/da9058/core.h  |   66 +++
>  include/linux/mfd/da9058/gpio.h  |   19 +
>  include/linux/mfd/da9058/hwmon.h |   32 ++
>  include/linux/mfd/da9058/i2c.h   |   22 +
>  include/linux/mfd/da9058/irq.h   |   50 ++
>  include/linux/mfd/da9058/onkey.h |   17 +
>  include/linux/mfd/da9058/pdata.h |   30 ++
>  include/linux/mfd/da9058/registers.h |  480 +
>  include/linux/mfd/da9058/regulator.h |   26 +
>  include/linux/mfd/da9058/rtc.h   |   17 +
>  39 files changed, 4070 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/hwmon/da9058
>  create mode 100644 drivers/gpio/gpio-da9058.c
>  create mode 100644 drivers/hwmon/da9058-hwmon.c
>  create mode 100644 drivers/iio/adc/da9058-adc.c
>  create mode 100644 drivers/input/misc/da9058_onkey.c
>  create mode 100644 drivers/mfd/da9058-core.c
>  create mode 100644 drivers/mfd/da9058-i2c.c
>  create mode 100644 drivers/mfd/da9058-info.c
>  create mode 100644 drivers/mfd/da9058-irq.c
>  create mode 100644 drivers/regulator/da9058-regulator.c
>  create mode 100644 drivers/rtc/rtc-da9058.c
>  create mode 100644 include/linux/mfd/da9058/adc.h
>  create mode 100644 include/linux/mfd/da9058/bat.h
>  create mode 100644 include/linux/mfd/da9058/codec.h
>  create mode 100644 include/linux/mfd/da9058/conf.h
>  create mode 100644 include/linux/mfd/da9058/core.h
>  create mode 100

Re: [PATCH] gma500: fix missing comma in dsi_errors array initializer

[One Thousand Gnomes]

On Tue, 22 Mar 2016 16:40:18 -0700
Joe Perches  wrote:

> On Tue, 2016-03-22 at 22:49 +, Colin King wrote:
> > From: Colin Ian King 
> > 
> > There is a missing comma between two strings in the dsi_errors[]
> > array initializer, causing two strings to be concatenated and the
> > array being incorrectly initialized.  Add in the missing comma.

I sent that a while ago, and there's also a patch to remove bogus code
from mdfld_dsi_dpi.c outstanding somewhere


Alan
 

Re: [PATCH] staging: dgnc: fix camelcase of SerialDriver and PrintDriver

[DaeSeok Youn]

2016-03-22 21:21 GMT+09:00 walter harms :
>
> You have send this patch before, right ?
> then it is a good custom to have something like: [Patch V2] in the
> subject line. In the comment you should write somethink like
>
> v2:  fix withspace damage
> v1:  fix issue
>
> Otherwise none of the reviewer maintainer will see what was changes.
> Sometimes patch run a few rounds before applied.
Yes, you're right.

I should leave a message.. sorry.

I had been making many patches, I think, until last year.
But I didn't contribute to linux kernel for long time(maybe one year.. :-( )
And I made mistakes while sending patches.. I was breaking the working
code because of this.

So I want to start over from making minor patches like fixing coding style.

Now, this patch was taken by Greg.
And also I will try to fix other coding style first of this module.
(I had been fixing issues dgap module that was removed in linux-next
branch. dgnc has same issues what dgap has.
I can also fix issues in dgnc module.)

Thanks for comment.

regards,
Daeseok.
>
> just my two cents
>
> re,
>  wh
>
> Am 22.03.2016 10:20, schrieb Daeseok Youn:
>> fix the checkpatch.pl warning about CamelCase.
>>
>> Signed-off-by: Daeseok Youn 
>> ---
>>  drivers/staging/dgnc/dgnc_driver.h |   4 +-
>>  drivers/staging/dgnc/dgnc_tty.c| 118 
>> ++---
>>  2 files changed, 61 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/staging/dgnc/dgnc_driver.h 
>> b/drivers/staging/dgnc/dgnc_driver.h
>> index e4be81b..953c891 100644
>> --- a/drivers/staging/dgnc/dgnc_driver.h
>> +++ b/drivers/staging/dgnc/dgnc_driver.h
>> @@ -202,9 +202,9 @@ struct dgnc_board {
>>* to our channels.
>>*/
>>
>> - struct tty_driver   SerialDriver;
>> + struct tty_driver serial_driver;
>>   charSerialName[200];
>> - struct tty_driver   PrintDriver;
>> + struct tty_driver print_driver;
>>   charPrintName[200];
>>
>>   booldgnc_Major_Serial_Registered;
>> diff --git a/drivers/staging/dgnc/dgnc_tty.c 
>> b/drivers/staging/dgnc/dgnc_tty.c
>> index bcd2bdf..081ac75 100644
>> --- a/drivers/staging/dgnc/dgnc_tty.c
>> +++ b/drivers/staging/dgnc/dgnc_tty.c
>> @@ -178,20 +178,20 @@ int dgnc_tty_register(struct dgnc_board *brd)
>>  {
>>   int rc = 0;
>>
>> - brd->SerialDriver.magic = TTY_DRIVER_MAGIC;
>> + brd->serial_driver.magic = TTY_DRIVER_MAGIC;
>>
>>   snprintf(brd->SerialName, MAXTTYNAMELEN, "tty_dgnc_%d_", 
>> brd->boardnum);
>>
>> - brd->SerialDriver.name = brd->SerialName;
>> - brd->SerialDriver.name_base = 0;
>> - brd->SerialDriver.major = 0;
>> - brd->SerialDriver.minor_start = 0;
>> - brd->SerialDriver.num = brd->maxports;
>> - brd->SerialDriver.type = TTY_DRIVER_TYPE_SERIAL;
>> - brd->SerialDriver.subtype = SERIAL_TYPE_NORMAL;
>> - brd->SerialDriver.init_termios = DgncDefaultTermios;
>> - brd->SerialDriver.driver_name = DRVSTR;
>> - brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW |
>> + brd->serial_driver.name = brd->SerialName;
>> + brd->serial_driver.name_base = 0;
>> + brd->serial_driver.major = 0;
>> + brd->serial_driver.minor_start = 0;
>> + brd->serial_driver.num = brd->maxports;
>> + brd->serial_driver.type = TTY_DRIVER_TYPE_SERIAL;
>> + brd->serial_driver.subtype = SERIAL_TYPE_NORMAL;
>> + brd->serial_driver.init_termios = DgncDefaultTermios;
>> + brd->serial_driver.driver_name = DRVSTR;
>> + brd->serial_driver.flags = (TTY_DRIVER_REAL_RAW |
>>  TTY_DRIVER_DYNAMIC_DEV |
>>  TTY_DRIVER_HARDWARE_BREAK);
>>
>> @@ -199,28 +199,28 @@ int dgnc_tty_register(struct dgnc_board *brd)
>>* The kernel wants space to store pointers to
>>* tty_struct's and termios's.
>>*/
>> - brd->SerialDriver.ttys = kcalloc(brd->maxports,
>> -  sizeof(*brd->SerialDriver.ttys),
>> + brd->serial_driver.ttys = kcalloc(brd->maxports,
>> +  sizeof(*brd->serial_driver.ttys),
>>GFP_KERNEL);
>> - if (!brd->SerialDriver.ttys)
>> + if (!brd->serial_driver.ttys)
>>   return -ENOMEM;
>>
>> - kref_init(&brd->SerialDriver.kref);
>> - brd->SerialDriver.termios = kcalloc(brd->maxports,
>> - sizeof(*brd->SerialDriver.termios),
>> + kref_init(&brd->serial_driver.kref);
>> + brd->serial_driver.termios = kcalloc(brd->maxports,
>> + 
>> sizeof(*brd->serial_driver.termios),
>>   GFP_KERNEL);
>> - if (!brd->SerialDriver.termios)
>> + if (!brd->serial_driver.termios)
>>   return -ENOMEM;
>>
>>   /*
>>* Entry points for driver.  Called by the 

Re: [RFC][PATCH v6 1/2] printk: Make printk() completely async

[Sergey Senozhatsky]

On (03/22/16 17:36), Petr Mladek wrote:
> > -   /* cpu currently holding logbuf_lock in this function */
> > -   static unsigned int logbuf_cpu = UINT_MAX;
> > +   bool in_panic = console_loglevel == CONSOLE_LOGLEVEL_MOTORMOUTH;
> 
> I am just looking at the printk in NMI patchset and I will need to
> deal with the panic state as well. I am not sure if this detection
> is secure.
> 
> This console level is set also by kdb_show_stack()
> and kdb_dumpregs(). I am not sure how this kdb stuff works
> and if it affects normal kernel but...
> 
> Anyway, it seems that many locations detects the panic situation
> via the variable oops_in_progress. It has another advantage
> that it can be easily checked and we would not need any extra
> variable here.

oops_in_progress is not my favorite global. and we can't rely on it
in async printk.

in panic() we have

 console_verbose();
 bust_spinlocks(1); << sets to one

pr_emerg("Kernel panic - not syncing: %s\n", buf);
smp_send_stop();

 bust_spinlocks(0); << sets it back to zero

console_flush_on_panic();

there are several issues here.
- first, panic_cpu does not see oops_in_progress right after bust_spinlocks(0).
thus all printk issued from panic_cpu can go via async printk.

- second, smp_send_stop() does not guarantee that all of the CPUs received
STOP IPI by the time it returns. on some platforms (ARM, for instance)
smp_send_stop()

:if (!cpumask_empty(&mask))
:smp_cross_call(&mask, IPI_CPU_STOP);
:
:/* Wait up to one second for other CPUs to stop */
:timeout = USEC_PER_SEC;
:while (num_online_cpus() > 1 && timeout--)
: udelay(1);
:
:if (num_online_cpus() > 1)
:   pr_warn("SMP: failed to stop secondary CPUs\n");
:
:return;

 waits for one second and returns back to panic_cpu, and panic_cpu sets
oops_in_progress back to zero. simulataneously SOPT_IPIs can start arriving
to remaining CPUs. on some platforms (ARM, for instance) STOP_IPI is

: raw_spin_lock(&stop_lock);
: pr_crit("CPU%u: stopping\n", cpu);
: dump_stack();
: raw_spin_unlock(&stop_lock);
: }
:
: set_cpu_online(cpu, false);
:
: local_fiq_disable();
: local_irq_disable();
:
: while (1)
: cpu_relax();


so CPUs dump_stack()s can in theory happen when oops_in_progress is zero
and, thus, printk will try to print it by printk_kthread, which is not
something we really want to do in panic().

so I wanted to have in printk some panic indication that once set never
gets cleared. my proposal was

void console_panic(void)
{
printk_sync = false;
}

or similar.

-ss

[PATCH v5] acpi: Issue _OSC call for native thermal interrupt handling

[Srinivas Pandruvada]

There are several reports of freeze on enabling HWP (Hardware PStates)
feature on Skylake based systems by Intel P states driver. The root
cause is identified as the HWP interrupts causing BIOS code to freeze.
HWP interrupts uses thermal LVT.
Linux natively handles thermal interrupts, but in Skylake based systems
SMM will take control of thermal interrupts. This is a problem for several
reasons:
- It is freezing in BIOS when tries to handle thermal interrupt, which
will require BIOS upgrade
- With SMM handling thermal we loose all the reporting features of
Linux arch/x86/kernel/cpu/mcheck/therm_throt driver
- Some thermal drivers like x86-package-temp driver depends on the thermal
threshold interrupts
- The HWP interrupts are useful for debugging and tuning performance

So we need native handling of thermal interrupts. This requires some
way to inform SMM that OS can handle thermal interrupts. This can be
done by using _OSC/_PDC under processor scope very early in ACPI
initialization flow.
The bit 12 of _OSC/_PDC in processor scope defines whether OS supports
handling of native interrupts for Collaborative Processor Performance
Control (CPPC) notifications. Since HWP is a implementation of CPPC,
setting this bit is equivalent to inform SMM that OS is capable of
handling thermal interrupts.
Refer to this document for details on _OSC/_PDC
http://www.intel.com/content/www/us/en/standards/processor-vendor-
specific-acpi-specification.html

This change introduces a new function acpi_early_processor_set_osc(),
which walks acpi name space and finds acpi processor object and
set capability via _OSC method.

Also this change writes HWP status bits to 0 to clear any HWP status
bits in intel_thermal_interrupt().

Signed-off-by: Srinivas Pandruvada 
---
v5:
No code change. Changed commit message to explain HWP is a implementation
of CPPC.

v4:
Suggestion by Boris for removing use of intermediate variable for
clearing HWP status and using boot_cpu_has instead of static_cpu_has

v3:
- Added CONFIG_X86 around static_cpu_has() to fix compile error on
ARCH=ia64, reported by kbuild test robot
- return AE_CTRL_TERMINATE to terminate acpi name walk space, when _OSC
is set already once.
v2:
Unnecessary newline was introduced, removed that in acpi_processor.c

 arch/x86/kernel/cpu/mcheck/therm_throt.c |  3 ++
 drivers/acpi/acpi_processor.c| 47 
 drivers/acpi/bus.c   |  3 ++
 drivers/acpi/internal.h  |  2 ++
 4 files changed, 55 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c 
b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 0b445c2..ac780ca 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -384,6 +384,9 @@ static void intel_thermal_interrupt(void)
 {
__u64 msr_val;
 
+   if (static_cpu_has(X86_FEATURE_HWP))
+   wrmsrl_safe(MSR_HWP_STATUS, 0);
+
rdmsrl(MSR_IA32_THERM_STATUS, msr_val);
 
/* Check for violation of core thermal thresholds*/
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index b5e54f2..52934d9 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -491,6 +491,53 @@ static void acpi_processor_remove(struct acpi_device 
*device)
 }
 #endif /* CONFIG_ACPI_HOTPLUG_CPU */
 
+#ifdef CONFIG_X86
+static bool acpi_hwp_native_thermal_lvt_set;
+static acpi_status acpi_set_hwp_native_thermal_lvt_osc(acpi_handle handle,
+  u32 lvl, void *context,
+  void **rv)
+{
+   u8 sb_uuid_str[] = "4077A616-290C-47BE-9EBD-D87058713953";
+   u32 capbuf[2];
+   struct acpi_osc_context osc_context = {
+   .uuid_str = sb_uuid_str,
+   .rev = 1,
+   .cap.length = 8,
+   .cap.pointer = capbuf,
+   };
+
+   if (acpi_hwp_native_thermal_lvt_set)
+   return AE_CTRL_TERMINATE;
+
+   capbuf[0] = 0x;
+   capbuf[1] = 0x1000; /* set bit 12 */
+
+   if (ACPI_SUCCESS(acpi_run_osc(handle, &osc_context))) {
+   acpi_hwp_native_thermal_lvt_set = true;
+   kfree(osc_context.ret.pointer);
+   }
+
+   return AE_OK;
+}
+
+void acpi_early_processor_set_osc(void)
+{
+   if (boot_cpu_has(X86_FEATURE_HWP)) {
+   acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+   ACPI_UINT32_MAX,
+   acpi_set_hwp_native_thermal_lvt_osc,
+   NULL, NULL, NULL);
+   acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
+acpi_set_hwp_native_thermal_lvt_osc,
+NULL, NULL);
+   }
+}
+#else
+
+void acpi_early_processor_set_osc(void) {}
+
+#endif
+
 /*
  * The following ACPI IDs are known to be suitable for representing as
  * proc

Re: [PATCH v14 09/17] drm: rockchip: dp: add rockchip platform dp driver

[Mark yao]

On 2016年02月15日 19:10, Yakir Yang wrote:

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas


It looks good for me, I like it, So

Acked-by: Mark Yao 

--
Ｍark Yao

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Mark yao]

On 2016年03月23日 08:41, Dave Airlie wrote:

So although it's small framework or just subdirectory, we would need
someone who can manage the framework to avoid further confusion if
necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.





Sure, these patches looks cool, I think it's ready to be merged, I'd 
like to give a Acked-by on rockchip side.


--
Ｍark Yao

Re: [PATCH v3 4/4] nmi_backtrace: generate one-line reports for idle cpus

[Rafael J. Wysocki]

On Tuesday, March 22, 2016 11:45:57 PM Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 11:31:11PM +0100, Rafael J. Wysocki wrote:
> 
> > > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> > > index cd4510a63375..924554f920fb 100644
> > > --- a/drivers/idle/intel_idle.c
> > > +++ b/drivers/idle/intel_idle.c
> > > @@ -725,8 +725,8 @@ static struct cpuidle_state avn_cstates[] = {
> > >   *
> > >   * Must be called under local_irq_disable().
> > >   */
> > > -static int intel_idle(struct cpuidle_device *dev,
> > > - struct cpuidle_driver *drv, int index)
> > > +static __cpuidle int intel_idle(struct cpuidle_device *dev,
> > > + struct cpuidle_driver *drv, int index)
> > >  {
> > >   unsigned long ecx = 1; /* break on interrupt flag */
> > >   struct cpuidle_state *state = &drv->states[index];
> > 
> > Well, what about intel_idle_freeze()?  Or do we not care?
> 
> I argued against it; when you're suspended the NMI watchdog is stopped
> too.

Is it also stopped for suspend-to-idle?  I'm not sure about that.

Where do I need to look to find out?

> Then again, you've more experience debugging that thing, so if
> you think its useful its not much effort adding it.
> 
> > And analogous stuff in processor_idle.c for that matter?
> > 
> > acpi_idle_enter()/acpi_idle_enter_freeze() plus stuff called by those?
> 
> Ah, I only tagged acpi_processor_ffh_cstate_enter() because I went from
> mwait_idle_with_hints(), I suppose acpi_safe_halt() and
> acpi_idle_do_entry() itself for the INB method should cover it?

Yes, these two should be sufficient.

> (This being one of the reasons I asked Chris to Cc you; you know this
> stuff far better than I do)
> 
> ---
>  drivers/acpi/processor_idle.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 175c86bee3a9..d5b11fff9e88 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -111,7 +111,7 @@ static const struct dmi_system_id 
> processor_power_dmi_table[] = {
>   * Callers should disable interrupts before the call and enable
>   * interrupts after return.
>   */
> -static void acpi_safe_halt(void)
> +__cpuidle static void acpi_safe_halt(void)
>  {
>   if (!tif_need_resched()) {
>   safe_halt();
> @@ -680,7 +680,7 @@ static int acpi_idle_bm_check(void)
>   *
>   * Caller disables interrupt before call and enables interrupt after return.
>   */
> -static void acpi_idle_do_entry(struct acpi_processor_cx *cx)
> +__cpuidle static void acpi_idle_do_entry(struct acpi_processor_cx *cx)
>  {
>   if (cx->entry_method == ACPI_CSTATE_FFH) {
>   /* Call into architectural FFH based C-state */

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Dave Airlie]

>
>> So although it's small framework or just subdirectory, we would need
>> someone who can manage the framework to avoid further confusion if
>> necessary.
>
> So maybe it just doesn't need a maintainer, and maybe those the owner
> of the bridge driver should be responsible for choosing the tree which
> it's merged through along with updates.  That's how dw-hdmi has been
> managed on the whole.
>
> It also means that the bridge driver maintainer is able to test changes
> to the bridge driver, rather than having some over-arching bridge
> subdirectory maintainer who doesn't have a clue whether the changes
> work on the hardware.
>
> IMHO, having bridge driver authors/maintainers look after their own
> code has many advantages.

The author just send me a pull request with acks from a git tree
that hopefully both people agreed and tested from. No need to
send this via another maintainer layer.

Dave.

[lkp] [tty/serial/8250] 9e2a7d9c24: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
yegorslists-googlemail-com/tty-serial-8250-add-MCTRL_GPIO-support/20160322-211617
commit 9e2a7d9c247ff3c90ff8a4086a165a6d141de16f ("tty/serial/8250: use 
mctrl_gpio helpers")


[0.00] Hierarchical RCU implementation.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS:4352 nr_irqs:440 16
[0.00] BUG: unable to handle kernel NULL pointer dereference at 
0008
[0.00] IP: [] mctrl_gpio_set+0x15/0x60
[0.00] PGD 0 
[0.00] Oops:  [#1] SMP 
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
4.5.0-next-20160322-5-g9e2a7d9 #236
[0.00] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.00] task: 8301b540 ti: 8300 task.ti: 
8300
[0.00] RIP: 0010:[]  [] 
mctrl_gpio_set+0x15/0x60
[0.00] RSP: :83003d48  EFLAGS: 00010086
[0.00] RAX: 826f8a48 RBX:  RCX: 
[0.00] RDX: 0008 RSI: 0002 RDI: 
[0.00] RBP: 83003da8 R08: 0001c200 R09: 002a
[0.00] R10:  R11: 0053 R12: 8503e2e0
[0.00] R13: 0001c200 R14: 0013 R15: 0001
[0.00] FS:  () GS:880014c0() 
knlGS:
[0.00] CS:  0010 DS:  ES:  CR0: 80050033
[0.00] CR2: 0008 CR3: 03014000 CR4: 06b0
[0.00] Stack:
[0.00]  0086 83003db0 810d9e16 

[0.00]  816f6e06   
0001
[0.00]   83003db0 816f3627 
8503e2e0
[0.00] Call Trace:
[0.00]  [] ? lock_acquire+0xa6/0xe0
[0.00]  [] ? serial8250_do_set_termios+0xf6/0x3f0
[0.00]  [] ? default_serial_dl_write+0x27/0x30
[0.00]  [] serial8250_do_set_mctrl+0xa3/0xb0
[0.00]  [] serial8250_set_mctrl+0x16/0x20
[0.00]  [] serial8250_do_set_termios+0x2dc/0x3f0
[0.00]  [] serial8250_set_termios+0x16/0x20
[0.00]  [] uart_set_options+0xf4/0x150
[0.00]  [] serial8250_console_setup+0x7f/0x130
[0.00]  [] univ8250_console_setup+0x39/0x50
[0.00]  [] register_console+0x295/0x370
[0.00]  [] univ8250_console_init+0x1e/0x28
[0.00]  [] console_init+0x1c/0x25
[0.00]  [] start_kernel+0x2cc/0x44c
[0.00]  [] ? early_idt_handler_array+0x120/0x120
[0.00]  [] x86_64_start_reservations+0x38/0x3a
[0.00]  [] x86_64_start_kernel+0xeb/0xf8
[0.00] Code: ef e8 80 b5 d4 00 5b 41 5c 41 5d 5d c3 66 0f 1f 84 00 00 
00 00 00 55 48 8d 57 08 48 c7 c0 48 8a 6f 82 31 ff 48 89 e5 48 83 ec 60 <48> 8b 
0a 48 85 c9 74 1d 80 78 04 00 74 17 41 89 f8 4a 89 4c c5 
[0.00] RIP  [] mctrl_gpio_set+0x15/0x60
[0.00]  RSP 
[0.00] CR2: 0008
[0.00] ---[ end trace 6df90b3c20cfd0c4 ]---
[0.00] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/x86_64-randconfig-i0-201612/gcc-5/9e2a7d9c247ff3c90ff8a4086a165a6d141de16f/vmlinuz-4.5.0-next-20160322-5-g9e2a7d9
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-lkp-wsx03-quantal-x86_64-2/bisect_boot-1-quantal-core-x86_64.cgz-x86_64-randconfig-i0-201612-9e2a7d9c247ff3c90ff8a4086a165a6d141de16f-20160322-6028-xx10d2-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-i0-201612 
branch=linux-devel/devel-catchup-201603222125 
commit=9e2a7d9c247ff3c90ff8a4086a165a6d141de16f 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-i0-201612/gcc-5/9e2a7d9c247ff3c90ff8a4086a165a6d141de16f/vmlinuz-4.5.0-next-20160322-5-g9e2a7d9
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-lkp-wsx03-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-i0-201612/gcc-5/9e2a7d9c247ff3c90ff8a4086a165a6d141de16f/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-lkp-wsx03-quantal-x86_64-2::dhcp drbd.minor_count=8'  -initrd 
/fs/sdc1/initrd-vm-lkp-wsx03-quantal-x86_64-2 -m 360 -smp 2 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -pidfile 
/dev/shm/kboot/pid-vm-lkp-wsx03-quantal-x86_64-2 -serial 
file:/dev/shm/kboot/serial-vm-lkp-wsx03-quantal-x86_64-2 -daemonize -display 
none -monitor null 




Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 

Re: [RFC][PATCH v6 1/2] printk: Make printk() completely async

[Sergey Senozhatsky]

Hello Petr,

On (03/22/16 14:11), Petr Mladek wrote:
[..]
> > -   /* cpu currently holding logbuf_lock in this function */
> > -   static unsigned int logbuf_cpu = UINT_MAX;
> > +   bool in_panic = console_loglevel == CONSOLE_LOGLEVEL_MOTORMOUTH;
> > +   bool sync_print = printk_sync;
> 
> I still think that this local variable adds more mess than good.
> Please, rename it to do_printk_sync at least. It will a poor human
> to distinguish it from the global one ;-)

ok, I'll take a look :)

> > +* Set printing_func() sleep condition early, under the @logbuf_lock.
> > +* So printing kthread (if RUNNING) will go to console_lock() and spin
> > +* on @logbuf_lock.
> > +*/
> > +   if (!printk_sync)
> > +   need_flush_console = true;
> 
> We set this variable for each call and also when printk_kthread is
> NULL or when sync_printk is false.

hm, yes. (printk_kthread && !need_flush_console) makes more sense.
so we it doesn't get re-dirty if already set.

> We migth want to clear it also from console_unlock(). I think that
> a good place would be in the check:
> 
>   raw_spin_lock(&logbuf_lock);
>   retry = console_seq != log_next_seq;
>   raw_spin_unlock_irqrestore(&logbuf_lock, flags);

hm, what's wrong with clearing it in printk_kthread  printing function?

> > +   if (!sync_print) {
> > +   if (in_sched) {
> > +   /*
> > +* @in_sched messages may come too early, when we don't
> > +* yet have @printk_kthread. We can't print deferred
> > +* messages directly, because this may deadlock, route
> > +* them via IRQ context.
> > +*/
> > +   __this_cpu_or(printk_pending,
> > +   PRINTK_PENDING_OUTPUT);
> > +   irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
> > +   } else if (printk_kthread && !in_panic) {
> > +   /* Offload printing to a schedulable context. */
> > +   wake_up_process(printk_kthread);
> > +   } else {
> > +   sync_print = true;
> > +   }
> > +   }
> > local_irq_restore(flags);
> 
> Please, what is the exact reason to call the above stuff before
> we release IRQs here? I guess that it is related to the discussions
> about possible lock debugging, infinite loops, ...
> 
> I wonder how the disabled IRQs help here. It is very likely that I
> miss something.

with IRQs enabled we have preemption enabled, so this thing

__this_cpu_or(printk_pending,
PRINTK_PENDING_OUTPUT);
irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));

can set pending and queue irq_work on different CPUs.

using "this_cpu = smp_processor_id()" which is taken right after
local_irq_save(flags) at the beginning of vprintk_emit() is not an
option - once we enable preemption CPUs are free to go offline. so
this thing wants to be under preemption disable(), and local_irq_save()
gives us it.

well, I can do

+ preempt_disable()
+ local_irq_restore()

if (!sync_print) {
...
__this_cpu_or()
irq_work_queue()
...
}
- local_irq_restore()
+ preempt_enable()

but

> In each case, irq_work_queue() is lock-less and was used with IRQs
> enabled before.
> 
> So, it might be related to wake_up_process(). It takes a lock but
> using
> 
>raw_spin_lock_irqsave(&p->pi_lock, flags);

wake_up_process disables IRQs in the beginning anyway.
so we have

local_irq_restore()
local_irq_save()

which is sort of nasty. disabling IRQs can be a bit expensive, not
that printk is that hot path, but I wanted to avoid additional latencies
that can happen due to IRQ enable-disable ping-pong.

> , so it disables IRQs in the critical section. Do we need to guard
> it in between?
> 
> I think that you actually wanted to disable lockdep or any other lock
> debugging, instead.

preemption.

well, disabling lockdep is may be a good thing to do as well...

>   if (in_sched) {
>   /*
>* @in_sched messages may come too early, when we don't
>* yet have @printk_kthread. We can't print deferred
>* messages directly, because this may deadlock, route
>* them via IRQ context.
>*/
>   __this_cpu_or(printk_pending,
> PRINTK_PENDING_OUTPUT);
>   irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
>   goto out;
>   }
> 
>   /* Avoid printk recursion */
>   lockdep_off();
> 
>   if  (printk_kthread && !in_panic) {
>   /* Offload printing to a schedulable context. */
>   wake_up_process(printk_kthread);
>   goto out_lockdep;
>   } else {
>   /*
>* Try to acquire and then immediately release the console

Re: [PATCH 2/2] ARM: dts: exynos: Enable SSS on Trats2

[Krzysztof Kozlowski]

On 23.03.2016 04:25, Tobias Jakobi wrote:
> Hello Krzysztof,
> 
> you can also add the node to the exynos4412-odroid-common dtsi. I have
> checked that it works properly on an X2.
> 
> Thanks for patches and fixing that alignment issue!

Thanks for testing it. I'll send a follow up with you as Tested-by.

I didn't add it because my Odroid U3 is in unusable state... I need to
fix it.

Best regards,
Krzysztof

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Russell King - ARM Linux]

On Wed, Mar 23, 2016 at 08:54:15AM +0900, Inki Dae wrote:
> 

Please wrap your long lines.

> 
> 2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> > On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> >> In this case, someone else may send an email again like you "who is going 
> >> to merge?"
> >> That would be why we need a maintainer.
> >>
> >> drm panel is already managed well by Thierry Reding without such 
> >> confusion. 
> > 
> > You don't need a maintainer for every subdirectory just because it's
> > a subdirectory...
> > 
> > Sometimes, having too many maintainers adds beaurocracy which becomes
> 
> Yes, but... if there is no someone who is responsible for maintainership,
> then we would receive such emails like Heiko sent "who is going to merge" 
> I don't also want adding many maintainers unnecessary but drm bridge -
> although the framework is a thin and small - is used *over the ARM SoC*
> so that many confusions may happen for upstream.

Just because someone asks doesn't mean someone needs to be appointed.
Maybe the question that should be asked instead is whether the original
author is willing to maintain their driver.

> So although it's small framework or just subdirectory, we would need
> someone who can manage the framework to avoid further confusion if
> necessary.

So maybe it just doesn't need a maintainer, and maybe those the owner
of the bridge driver should be responsible for choosing the tree which
it's merged through along with updates.  That's how dw-hdmi has been
managed on the whole.

It also means that the bridge driver maintainer is able to test changes
to the bridge driver, rather than having some over-arching bridge
subdirectory maintainer who doesn't have a clue whether the changes
work on the hardware.

IMHO, having bridge driver authors/maintainers look after their own
code has many advantages.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: RCU stall

[Bart Van Assche]

On 03/22/2016 01:45 PM, Paul E. McKenney wrote:

You are getting a soft lockup as well as an RCU CPU stall warning, so
it looks like something is taking a very long time in blk_done_softirq().

You have multiple occurrences at different times, so it looks to be
a long time as opposed to an infinite time.  Are you perhaps doing
something that would make a huge amount of work for blk_done_softirq()?

See Documentation/RCU/stallwarn.txt in the kernel source tree for more
info on how to debug this sort of thing.


Hello Paul,

None of the drivers involved in the test I ran contain RCU code that has 
been changed recently. The block and SCSI subsystems processes I/O 
completions in softirq context but until last week I hadn't seen any RCU 
lockup complaints when I ran an SRP test against a kernel with lockdep 
and several other kernel debugging options enabled. This is why I sent 
an e-mail to you. I have read Documentation/RCU/stallwarn.txt after I 
received your reply but this didn't provide me any clue about where to 
look for the root cause. Any further help would be appreciated.


Thanks,

Bart.

[PATCH v6 4/5] livepatch: reuse module loader code to write relocations

[Jessica Yu]

Reuse module loader code to write relocations, thereby eliminating the need
for architecture specific relocation code in livepatch. Specifically, reuse
the apply_relocate_add() function in the module loader to write relocations
instead of duplicating functionality in livepatch's arch-dependent
klp_write_module_reloc() function.

In order to accomplish this, livepatch modules manage their own relocation
sections (marked with the SHF_RELA_LIVEPATCH section flag) and
livepatch-specific symbols (marked with SHN_LIVEPATCH symbol section
index). To apply livepatch relocation sections, livepatch symbols
referenced by relocs are resolved and then apply_relocate_add() is called
to apply those relocations.

In addition, remove x86 livepatch relocation code and the s390
klp_write_module_reloc() function stub. They are no longer needed since
relocation work has been offloaded to module loader.

Lastly, mark the module as a livepatch module so that the module loader
canappropriately identify and initialize it.

Signed-off-by: Jessica Yu 
Reviewed-by: Miroslav Benes 
---
 arch/s390/include/asm/livepatch.h|   7 --
 arch/x86/include/asm/livepatch.h |   2 -
 arch/x86/kernel/Makefile |   1 -
 arch/x86/kernel/livepatch.c  |  70 -
 include/linux/livepatch.h|  20 -
 kernel/livepatch/core.c  | 148 ++-
 samples/livepatch/livepatch-sample.c |   1 +
 7 files changed, 95 insertions(+), 154 deletions(-)
 delete mode 100644 arch/x86/kernel/livepatch.c

diff --git a/arch/s390/include/asm/livepatch.h 
b/arch/s390/include/asm/livepatch.h
index d5427c7..2c12137 100644
--- a/arch/s390/include/asm/livepatch.h
+++ b/arch/s390/include/asm/livepatch.h
@@ -24,13 +24,6 @@ static inline int klp_check_compiler_support(void)
return 0;
 }
 
-static inline int klp_write_module_reloc(struct module *mod, unsigned long
-   type, unsigned long loc, unsigned long value)
-{
-   /* not supported yet */
-   return -ENOSYS;
-}
-
 static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
 {
regs->psw.addr = ip;
diff --git a/arch/x86/include/asm/livepatch.h b/arch/x86/include/asm/livepatch.h
index 7e68f95..a7f9181 100644
--- a/arch/x86/include/asm/livepatch.h
+++ b/arch/x86/include/asm/livepatch.h
@@ -32,8 +32,6 @@ static inline int klp_check_compiler_support(void)
 #endif
return 0;
 }
-int klp_write_module_reloc(struct module *mod, unsigned long type,
-  unsigned long loc, unsigned long value);
 
 static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
 {
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 616ebd2..89f8ade 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -79,7 +79,6 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
 obj-y  += apic/
 obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
 obj-$(CONFIG_DYNAMIC_FTRACE)   += ftrace.o
-obj-$(CONFIG_LIVEPATCH)+= livepatch.o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_X86_TSC)  += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
deleted file mode 100644
index 92fc1a5..000
--- a/arch/x86/kernel/livepatch.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * livepatch.c - x86-specific Kernel Live Patching Core
- *
- * Copyright (C) 2014 Seth Jennings 
- * Copyright (C) 2014 SUSE
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-
-/**
- * klp_write_module_reloc() - write a relocation in a module
- * @mod:   module in which the section to be modified is found
- * @type:  ELF relocation type (see asm/elf.h)
- * @loc:   address that the relocation should be written to
- * @value: relocation value (sym address + addend)
- *
- * This function writes a relocation to the specified location for
- * a particular module.
- */
-int klp_write_module_reloc(struct module *mod, unsigned long type,
-  unsigned long loc, unsigned long value)
-{
-   size_t size = 4;
-   unsigned long val;
-   unsigned long core = (unsigned long)mod->core_layout.base;
-   unsigned long core_size = mod->core_layout.size;
-
-   switch (type) {
-   case

[PATCH v6 5/5] Documentation: livepatch: outline Elf format and requirements for patch modules

[Jessica Yu]

Document livepatch module requirements and the special Elf constants patch
modules use.

Signed-off-by: Jessica Yu 
Acked-by: Miroslav Benes 
---
 Documentation/livepatch/module-elf-format.txt | 311 ++
 1 file changed, 311 insertions(+)
 create mode 100644 Documentation/livepatch/module-elf-format.txt

diff --git a/Documentation/livepatch/module-elf-format.txt 
b/Documentation/livepatch/module-elf-format.txt
new file mode 100644
index 000..eedbdcf
--- /dev/null
+++ b/Documentation/livepatch/module-elf-format.txt
@@ -0,0 +1,311 @@
+===
+Livepatch module Elf format
+===
+
+This document outlines the Elf format requirements that livepatch modules must 
follow.
+
+-
+Table of Contents
+-
+0. Background and motivation
+1. Livepatch modinfo field
+2. Livepatch relocation sections
+   2.1 What are livepatch relocation sections?
+   2.2 Livepatch relocation section format
+   2.2.1 Required flags
+   2.2.2 Required name format
+   2.2.3 Example livepatch relocation section names
+   2.2.4 Example `readelf --sections` output
+   2.2.5 Example `readelf --relocs` output
+3. Livepatch symbols
+   3.1 What are livepatch symbols?
+   3.2 A livepatch module's symbol table
+   3.3 Livepatch symbol format
+   3.3.1 Required flags
+   3.3.2 Required name format
+   3.3.3 Example livepatch symbol names
+   3.3.4 Example `readelf --symbols` output
+4. Symbol table and Elf section access
+
+
+0. Background and motivation
+
+
+Formerly, livepatch required separate architecture-specific code to write
+relocations. However, arch-specific code to write relocations already
+exists in the module loader, so this former approach produced redundant
+code. So, instead of duplicating code and re-implementing what the module
+loader can already do, livepatch leverages existing code in the module
+loader to perform the all the arch-specific relocation work. Specifically,
+livepatch reuses the apply_relocate_add() function in the module loader to
+write relocations. The patch module Elf format described in this document
+enables livepatch to be able to do this. The hope is that this will make
+livepatch more easily portable to other architectures and reduce the amount
+of arch-specific code required to port livepatch to a particular
+architecture.
+
+Since apply_relocate_add() requires access to a module's section header
+table, symbol table, and relocation section indices, Elf information is
+preserved for livepatch modules (see section 4). Livepatch manages its own
+relocation sections and symbols, which are described in this document. The
+Elf constants used to mark livepatch symbols and relocation sections were
+selected from OS-specific ranges according to the definitions from glibc.
+
+0.1 Why does livepatch need to write its own relocations?
+-
+A typical livepatch module contains patched versions of functions that can
+reference non-exported global symbols and non-included local symbols.
+Relocations referencing these types of symbols cannot be left in as-is
+since the kernel module loader cannot resolve them and will therefore
+reject the livepatch module. Furthermore, we cannot apply relocations that
+affect modules not yet loaded at patch module load time (e.g. a patch to a
+driver that is not loaded). Formerly, livepatch solved this problem by
+embedding special "dynrela" (dynamic rela) sections in the resulting patch
+module Elf output. Using these dynrela sections, livepatch could resolve
+symbols while taking into account its scope and what module the symbol
+belongs to, and then manually apply the dynamic relocations. However this
+approach required livepatch to supply arch-specific code in order to write
+these relocations. In the new format, livepatch manages its own SHT_RELA
+relocation sections in place of dynrela sections, and the symbols that the
+relas reference are special livepatch symbols (see section 2 and 3). The
+arch-specific livepatch relocation code is replaced by a call to
+apply_relocate_add().
+
+
+PATCH MODULE FORMAT REQUIREMENTS
+
+
+--
+1. Livepatch modinfo field
+--
+
+Livepatch modules are required to have the "livepatch" modinfo attribute.
+See the sample livepatch module in samples/livepatch/ for how this is done.
+
+Livepatch modules can be identified by users by using the 'modinfo' command
+and looking for the presence of the "livepatch" field. This field is also
+used by the kernel module loader to identify livepatch modules.
+
+Example modinfo output:
+---
+% modinfo livepatch-meminfo.ko
+filename:  livepatch-meminfo.ko
+livepatch: Y
+license:   GPL
+depends:
+vermagic:  

[PATCH v6 1/5] Elf: add livepatch-specific Elf constants

[Jessica Yu]

Livepatch manages its own relocation sections and symbols in order to be
able to reuse module loader code to write relocations. This removes
livepatch's dependence on separate "dynrela" sections to write relocations
and also allows livepatch to patch modules that are not yet loaded.

The livepatch Elf relocation section flag (SHF_RELA_LIVEPATCH),
and symbol section index (SHN_LIVEPATCH) allow both livepatch and the
module loader to identity livepatch relocation sections and livepatch
symbols.

Livepatch relocation sections are marked with SHF_RELA_LIVEPATCH to
indicate to the module loader that it should not apply that relocation
section and that livepatch will handle them.

The SHN_LIVEPATCH shndx marks symbols that will be resolved by livepatch.
The module loader ignores these symbols and does not attempt to resolve
them.

The values of these Elf constants were selected from OS-specific
ranges according to the definitions from glibc.

Signed-off-by: Jessica Yu 
Reviewed-by: Miroslav Benes 
---
 include/uapi/linux/elf.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 71e1d0e..cb4a72f 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -282,16 +282,18 @@ typedef struct elf64_phdr {
 #define SHT_HIUSER 0x
 
 /* sh_flags */
-#define SHF_WRITE  0x1
-#define SHF_ALLOC  0x2
-#define SHF_EXECINSTR  0x4
-#define SHF_MASKPROC   0xf000
+#define SHF_WRITE  0x1
+#define SHF_ALLOC  0x2
+#define SHF_EXECINSTR  0x4
+#define SHF_RELA_LIVEPATCH 0x0010
+#define SHF_MASKPROC   0xf000
 
 /* special section indexes */
 #define SHN_UNDEF  0
 #define SHN_LORESERVE  0xff00
 #define SHN_LOPROC 0xff00
 #define SHN_HIPROC 0xff1f
+#define SHN_LIVEPATCH  0xff20
 #define SHN_ABS0xfff1
 #define SHN_COMMON 0xfff2
 #define SHN_HIRESERVE  0x
-- 
2.4.3

[PATCH v6 3/5] module: s390: keep mod_arch_specific for livepatch modules

[Jessica Yu]

Livepatch needs to utilize the symbol information contained in the
mod_arch_specific struct in order to be able to call the s390
apply_relocate_add() function to apply relocations. Keep a reference to
syminfo if the module is a livepatch module. Remove the redundant vfree()
in module_finalize() since module_arch_freeing_init() (which also frees
those structures) is called in do_init_module(). If the module isn't a
livepatch module, we free the structures in module_arch_freeing_init() as
usual.

Signed-off-by: Jessica Yu 
Reviewed-by: Miroslav Benes 
---
 arch/s390/kernel/module.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
index 7873e17..fbc0789 100644
--- a/arch/s390/kernel/module.c
+++ b/arch/s390/kernel/module.c
@@ -51,6 +51,10 @@ void *module_alloc(unsigned long size)
 
 void module_arch_freeing_init(struct module *mod)
 {
+   if (is_livepatch_module(mod) &&
+   mod->state == MODULE_STATE_LIVE)
+   return;
+
vfree(mod->arch.syminfo);
mod->arch.syminfo = NULL;
 }
@@ -425,7 +429,5 @@ int module_finalize(const Elf_Ehdr *hdr,
struct module *me)
 {
jump_label_apply_nops(me);
-   vfree(me->arch.syminfo);
-   me->arch.syminfo = NULL;
return 0;
 }
-- 
2.4.3

[PATCH v6 2/5] module: preserve Elf information for livepatch modules

[Jessica Yu]

For livepatch modules, copy Elf section, symbol, and string information
from the load_info struct in the module loader. Persist copies of the
original symbol table and string table.

Livepatch manages its own relocation sections in order to reuse module
loader code to write relocations. Livepatch modules must preserve Elf
information such as section indices in order to apply livepatch relocation
sections using the module loader's apply_relocate_add() function.

In order to apply livepatch relocation sections, livepatch modules must
keep a complete copy of their original symbol table in memory. Normally, a
stripped down copy of a module's symbol table (containing only "core"
symbols) is made available through module->core_symtab. But for livepatch
modules, the symbol table copied into memory on module load must be exactly
the same as the symbol table produced when the patch module was compiled.
This is because the relocations in each livepatch relocation section refer
to their respective symbols with their symbol indices, and the original
symbol indices (and thus the symtab ordering) must be preserved in order
for apply_relocate_add() to find the right symbol.

Signed-off-by: Jessica Yu 
Reviewed-by: Miroslav Benes 
---
 include/linux/module.h |  25 ++
 kernel/module.c| 125 +++--
 2 files changed, 147 insertions(+), 3 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 2bb0c30..3daf2b3 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -330,6 +330,15 @@ struct mod_kallsyms {
char *strtab;
 };
 
+#ifdef CONFIG_LIVEPATCH
+struct klp_modinfo {
+   Elf_Ehdr hdr;
+   Elf_Shdr *sechdrs;
+   char *secstrings;
+   unsigned int symndx;
+};
+#endif
+
 struct module {
enum module_state state;
 
@@ -456,7 +465,11 @@ struct module {
 #endif
 
 #ifdef CONFIG_LIVEPATCH
+   bool klp; /* Is this a livepatch module? */
bool klp_alive;
+
+   /* Elf information */
+   struct klp_modinfo *klp_info;
 #endif
 
 #ifdef CONFIG_MODULE_UNLOAD
@@ -630,6 +643,18 @@ static inline bool module_requested_async_probing(struct 
module *module)
return module && module->async_probe_requested;
 }
 
+#ifdef CONFIG_LIVEPATCH
+static inline bool is_livepatch_module(struct module *mod)
+{
+   return mod->klp;
+}
+#else /* !CONFIG_LIVEPATCH */
+static inline bool is_livepatch_module(struct module *mod)
+{
+   return false;
+}
+#endif /* CONFIG_LIVEPATCH */
+
 #else /* !CONFIG_MODULES... */
 
 /* Given an address, look for it in the exception tables. */
diff --git a/kernel/module.c b/kernel/module.c
index 041200c..5f71aa6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1973,6 +1973,83 @@ static void module_enable_nx(const struct module *mod) { 
}
 static void module_disable_nx(const struct module *mod) { }
 #endif
 
+#ifdef CONFIG_LIVEPATCH
+/*
+ * Persist Elf information about a module. Copy the Elf header,
+ * section header table, section string table, and symtab section
+ * index from info to mod->klp_info.
+ */
+static int copy_module_elf(struct module *mod, struct load_info *info)
+{
+   unsigned int size, symndx;
+   int ret;
+
+   size = sizeof(*mod->klp_info);
+   mod->klp_info = kmalloc(size, GFP_KERNEL);
+   if (mod->klp_info == NULL)
+   return -ENOMEM;
+
+   /* Elf header */
+   size = sizeof(mod->klp_info->hdr);
+   memcpy(&mod->klp_info->hdr, info->hdr, size);
+
+   /* Elf section header table */
+   size = sizeof(*info->sechdrs) * info->hdr->e_shnum;
+   mod->klp_info->sechdrs = kmalloc(size, GFP_KERNEL);
+   if (mod->klp_info->sechdrs == NULL) {
+   ret = -ENOMEM;
+   goto free_info;
+   }
+   memcpy(mod->klp_info->sechdrs, info->sechdrs, size);
+
+   /* Elf section name string table */
+   size = info->sechdrs[info->hdr->e_shstrndx].sh_size;
+   mod->klp_info->secstrings = kmalloc(size, GFP_KERNEL);
+   if (mod->klp_info->secstrings == NULL) {
+   ret = -ENOMEM;
+   goto free_sechdrs;
+   }
+   memcpy(mod->klp_info->secstrings, info->secstrings, size);
+
+   /* Elf symbol section index */
+   symndx = info->index.sym;
+   mod->klp_info->symndx = symndx;
+
+   /*
+* For livepatch modules, core_kallsyms.symtab is a complete
+* copy of the original symbol table. Adjust sh_addr to point
+* to core_kallsyms.symtab since the copy of the symtab in module
+* init memory is freed at the end of do_init_module().
+*/
+   mod->klp_info->sechdrs[symndx].sh_addr = \
+   (unsigned long) mod->core_kallsyms.symtab;
+
+   return 0;
+
+free_sechdrs:
+   kfree(mod->klp_info->sechdrs);
+free_info:
+   kfree(mod->klp_info);
+   return ret;
+}
+
+static void free_module_elf(struct module *mod)
+{
+   kfree(mod->klp_info->sechdrs);
+   kfree(mod->

[PATCH v6 0/5] (mostly) Arch-independent livepatch

[Jessica Yu]

This patchset removes livepatch's need for architecture-specific relocation
code by leveraging existing code in the module loader to perform
arch-dependent work. Specifically, instead of duplicating code and
re-implementing what the apply_relocate_add() function in the module loader
already does in livepatch's klp_write_module_reloc(), we reuse
apply_relocate_add() to write relocations. The hope is that this will make
livepatch more easily portable to other architectures and greatly reduce
the amount of arch-specific code required to port livepatch to a particular
architecture.

Background: Why does livepatch need to write its own relocations?
==
A typical livepatch module contains patched versions of functions that can
reference non-exported global symbols and non-included local symbols.
Relocations referencing these types of symbols cannot be left in as-is
since the kernel module loader cannot resolve them and will therefore
reject the livepatch module. Furthermore, we cannot apply relocations that
affect modules not loaded yet at run time (e.g. a patch to a driver). The
current kpatch build system therefore solves this problem by embedding
special "dynrela" (dynamic reloc) sections in the resulting patch module
Elf output. Using these dynrela sections, livepatch can correctly resolve
symbols while taking into account its scope and what module the symbol
belongs to, and then manually apply the dynamic relocations.

Motivation: Why is having arch-dependent relocation code a problem?
==
The original motivation for this patchset stems from the increasing
roadblocks encountered while attempting to port livepatch to s390.
Specifically, there were problems dealing with s390 PLT and GOT relocation
types (R_390_{PLT,GOT}), which are handled differently from x86's
relocation types (which are much simpler to deal with, and a single
livepatch function (klp_write_module_reloc()) has been sufficient enough).
These s390 reloc types cannot be handled by simply performing a calculation
(as in the x86 case). For s390 modules with PLT/GOT relocations, the kernel
module loader allocates and fills in PLT+GOT table entries for every symbol
referenced by a PLT/GOT reloc in module core memory. So the problem of
porting livepatch to s390 became much more complicated than simply writing
an s390-specific klp_write_module_reloc() function. How can livepatch
handle these relocation types if the s390 module loader needs to allocate
and fill PLT/GOT entries ahead of time? The potential solutions were: 1)
have livepatch possibly allocate and maintain its own PLT/GOT tables for
every patch module (requiring even more arch-specific code), 2) modify the
s390 module loader heavily to accommodate livepatch modules (i.e. allocate
all the needed PLT/GOT entries for livepatch in advance but refrain from
applying relocations for to-be-patched modules), or 3) eliminate this
potential mess by leveraging module loader code to do all the relocation
work, letting livepatch off the hook completely. Solution #3 is what this
patchset implements.

How does this patchset remedy these problems?
==
Reusing the module loader code to perform livepatch relocations means that
livepatch no longer needs arch-specific reloc code and the aforementioned
problems with s390 PLT/GOT reloc types disappear (because we let the module
loader do all the relocation work for us). It will enable livepatch to be
more easily ported to other architectures.

Summary of proposed changes
==
This patch series enables livepatch to use the module loader's
apply_relocate_add() function to apply livepatch relocations (i.e. what
used to be dynrelas). apply_relocate_add() requires access to a patch
module's section headers, symbol table, reloc section indices, etc., and all
of these are accessible through the load_info struct used in the module
loader. Therefore we persist module Elf information (copied from load_info)
for livepatch modules.

The ELF-related changes enable livepatch to patch modules that are not yet
loaded (as well as patch vmlinux when kaslr is enabled). In order to use
apply_relocate_add(), we need real SHT_RELA sections to pass in. A
complication here is that relocations for not-yet-loaded modules should not
be applied when the patch module loads; they should only be applied once
the target module is loaded. Thus kpatch build scripts were modified to
output a livepatch module that contains special .klp.rela. sections that
are managed by livepatch and are applied at the appropriate time (i.e. when
target module loads). They are marked with a special SHF_RELA_LIVEPATCH
section flag to indicate to the module loader that livepatch will handle
them. The SHN_LIVEPATCH shndx marks symbols that need to be resolved
once their respective target module loads. So, the module loader ignores
these symbols and does not attempt to resolve them. These ELF constants
were selected from OS-specific ranges according to the definitions from
glibc.

Patches based on linux-next.

Previous pa

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
> 

Re: [RFC 0/2] staging: ion: of_ion_device_get

[Moritz Fischer]

On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott  wrote:

> If allocation is coming from userspace and drivers are only importing
> you should be using the dma_buf APIs instead of Ion APIs directly.
> Ion is a dma_buf exporter and dma_buf APIs are the preferred API.

Ok, thanks. Sounds reasonable.

Thanks,

Moritz

PS: My email skills today suck ... sorry about that ... I should go home ...

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Russell King - ARM Linux]

On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> In this case, someone else may send an email again like you "who is going to 
> merge?"
> That would be why we need a maintainer.
> 
> drm panel is already managed well by Thierry Reding without such confusion. 

You don't need a maintainer for every subdirectory just because it's
a subdirectory...

Sometimes, having too many maintainers adds beaurocracy which becomes
counter-productive.  dw_hdmi seems to be adequately managed so far
without there needing to be a "DRM bridge maintainer".

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 2/2] arch:mm: Use hugetlb_bad_size

[Naoya Horiguchi]

On Tue, Mar 22, 2016 at 03:35:59PM +0530, Vaishali Thakkar wrote:
> Update the setup_hugepagesz function to call the routine
> hugetlb_bad_size when unsupported hugepage size is found.
> 
> Misc:
>   - Silent 80 characters warning
> 
> Signed-off-by: Vaishali Thakkar 
> Cc: Mike Kravetz 
> Cc: Naoya Horiguchi 
> Cc: Hillf Danton 
> Cc: Michal Hocko 
> Cc: Yaowei Bai 
> Cc: Dominik Dingel 
> Cc: Kirill A. Shutemov 
> Cc: Paul Gortmaker 
> Cc: Dave Hansen 

Reviewed-by: Naoya Horiguchi 

> ---
> - Please note that the patch is tested for x86 only. But as this
>   is one line change I just changed them. So, it would be good if
>   the patch can be tested for other architectures before adding
>   this in to mainline.
> - Not sure if printk related checkpatch.pl warning should be resolved
>   with this patch as code is not consistent in architectures. May be
>   one separate patch for changing all printk's to pr_ kind of
>   debugging functions would be good.
> ---
>  arch/arm64/mm/hugetlbpage.c   | 1 +
>  arch/metag/mm/hugetlbpage.c   | 1 +
>  arch/powerpc/mm/hugetlbpage.c | 7 +--
>  arch/tile/mm/hugetlbpage.c| 7 ++-
>  arch/x86/mm/hugetlbpage.c | 1 +
>  5 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 589fd28..aa8aee7 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -307,6 +307,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu K\n", ps >> 10);
>   return 0;
>   }
> diff --git a/arch/metag/mm/hugetlbpage.c b/arch/metag/mm/hugetlbpage.c
> index b38700a..db1b7da 100644
> --- a/arch/metag/mm/hugetlbpage.c
> +++ b/arch/metag/mm/hugetlbpage.c
> @@ -239,6 +239,7 @@ static __init int setup_hugepagesz(char *opt)
>   if (ps == (1 << HPAGE_SHIFT)) {
>   hugetlb_add_hstate(HPAGE_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   pr_err("hugepagesz: Unsupported page size %lu M\n",
>  ps >> 20);
>   return 0;
> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
> index 6dd272b..a437ff7 100644
> --- a/arch/powerpc/mm/hugetlbpage.c
> +++ b/arch/powerpc/mm/hugetlbpage.c
> @@ -772,8 +772,11 @@ static int __init hugepage_setup_sz(char *str)
>  
>   size = memparse(str, &str);
>  
> - if (add_huge_page_size(size) != 0)
> - printk(KERN_WARNING "Invalid huge page size specified(%llu)\n", 
> size);
> + if (add_huge_page_size(size) != 0) {
> + hugetlb_bad_size();
> + printk(KERN_WARNING "Invalid huge page size specified(%llu)\n",
> +size);
> + }
>  
>   return 1;
>  }
> diff --git a/arch/tile/mm/hugetlbpage.c b/arch/tile/mm/hugetlbpage.c
> index e212c64..77ceaa3 100644
> --- a/arch/tile/mm/hugetlbpage.c
> +++ b/arch/tile/mm/hugetlbpage.c
> @@ -308,11 +308,16 @@ static bool saw_hugepagesz;
>  
>  static __init int setup_hugepagesz(char *opt)
>  {
> + int rc;
> +
>   if (!saw_hugepagesz) {
>   saw_hugepagesz = true;
>   memset(huge_shift, 0, sizeof(huge_shift));
>   }
> - return __setup_hugepagesz(memparse(opt, NULL));
> + rc = __setup_hugepagesz(memparse(opt, NULL));
> + if (rc)
> + hugetlb_bad_size();
> + return rc;
>  }
>  __setup("hugepagesz=", setup_hugepagesz);
>  
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 740d7ac..3ec44f8 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -165,6 +165,7 @@ static __init int setup_hugepagesz(char *opt)
>   } else if (ps == PUD_SIZE && cpu_has_gbpages) {
>   hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT);
>   } else {
> + hugetlb_bad_size();
>   printk(KERN_ERR "hugepagesz: Unsupported page size %lu M\n",
>   ps >> 20);
>   return 0;
> -- 
> 2.1.4
> 

Re: [PATCH] gma500: fix missing comma in dsi_errors array initializer

[Joe Perches]

On Tue, 2016-03-22 at 22:49 +, Colin King wrote:
> From: Colin Ian King 
> 
> There is a missing comma between two strings in the dsi_errors[]
> array initializer, causing two strings to be concatenated and the
> array being incorrectly initialized.  Add in the missing comma.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 2 +-
>  1 file changed, 1 insertion(+), 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 6b43ae3..1616af2 100644
> --- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
> @@ -72,7 +72,7 @@ static const char *const dsi_errors[] = {
>   "RX Prot Violation",
>   "HS Generic Write FIFO Full",
>   "LP Generic Write FIFO Full",
> - "Generic Read Data Avail"
> + "Generic Read Data Avail",
>   "Special Packet Sent",
>   "Tearing Effect",
>  };

>From 2011:

https://lkml.org/lkml/2011/7/8/197

and

commit fc5ace7ed2a58e32047abf65ff8b5a6432e92fac
Author: Dan Carpenter 
Date:   Fri Jul 8 09:45:19 2011 +0100

Staging: gma500: typo in array initialization

There is a comma missing here between the strings so they were
concatenated by mistake.

Signed-off-by: Dan Carpenter 
Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 

Apparently this wasn't merged back into this version.

Are there any other changes in that old staging version that
also need to be merged back?

Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

[Naoya Horiguchi]

On Tue, Mar 22, 2016 at 03:30:43PM +0530, Vaishali Thakkar wrote:
> When any unsupported hugepage size is specified, 'hugepagesz=' and
> 'hugepages=' should be ignored during command line parsing until any
> supported hugepage size is found. But currently incorrect number of
> hugepages are allocated when unsupported size is specified as it fails
> to ignore the 'hugepages=' command.
> 
> Test case:
> 
> Note that this is specific to x86 architecture.
> 
> Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
> After boot, dmesg output shows that X number of hugepages of the size 2M
> is pre-allocated instead of 0.
> 
> So, to handle such command line options, introduce new routine
> hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
> parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
> state when unsupported hugepagesize is found so that we can ignore the
> 'hugepages=' parameters after that and then reset the variable when
> supported hugepage size is found.
> 
> The routine hugetlb_bad_size can be called while setting 'hugepagesz='
> parameter in an architecture specific code.

> Signed-off-by: Vaishali Thakkar 
> Cc: Mike Kravetz 
> Cc: Naoya Horiguchi 
> Cc: Hillf Danton 
> Cc: Michal Hocko 
> Cc: Yaowei Bai 
> Cc: Dominik Dingel 
> Cc: Kirill A. Shutemov 
> Cc: Paul Gortmaker 
> Cc: Dave Hansen 

Maybe parsed_hstate can do what parsed_valid_hugepagesz does, but both
are __initdata so it's not a big deal.

Reviewed-by: Naoya Horiguchi 

> ---
> The patch is having 2 checkpatch.pl warnings. I have just followed
> the current code to maintain consistency. If we decide to silent
> these warnings then may be we should silent those warnings as well.
> I am fine with any option whichever works best for everyone else. 
> ---
>  include/linux/hugetlb.h |  1 +
>  mm/hugetlb.c| 14 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 7d953c2..e44c578 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct 
> address_space *mapping,
>  /* arch callback */
>  int __init alloc_bootmem_huge_page(struct hstate *h);
>  
> +void __init hugetlb_bad_size(void);
>  void __init hugetlb_add_hstate(unsigned order);
>  struct hstate *size_to_hstate(unsigned long size);
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 06058ea..44fae6a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
>  static struct hstate * __initdata parsed_hstate;
>  static unsigned long __initdata default_hstate_max_huge_pages;
>  static unsigned long __initdata default_hstate_size;
> +static bool __initdata parsed_valid_hugepagesz = true;
>  
>  /*
>   * Protects updates to hugepage_freelists, hugepage_activelist, 
> nr_huge_pages,
> @@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
>  subsys_initcall(hugetlb_init);
>  
>  /* Should be called on processing a hugepagesz=... option */
> +void __init hugetlb_bad_size(void)
> +{
> + parsed_valid_hugepagesz = false;
> +}
> +
>  void __init hugetlb_add_hstate(unsigned int order)
>  {
>   struct hstate *h;
> @@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
>   unsigned long *mhp;
>   static unsigned long *last_mhp;
>  
> + if (!parsed_valid_hugepagesz) {
> + pr_warn("hugepages = %s preceded by "
> + "an unsupported hugepagesz, ignoring\n", s);
> + parsed_valid_hugepagesz = true;
> + return 1;
> + }
>   /*
>* !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter 
> yet,
>* so this hugepages= parameter goes to the "default hstate".
>*/
> - if (!hugetlb_max_hstate)
> + else if (!hugetlb_max_hstate)
>   mhp = &default_hstate_max_huge_pages;
>   else
>   mhp = &parsed_hstate->max_huge_pages;
> -- 
> 2.1.4
> 

Re: [RFC 0/2] staging: ion: of_ion_device_get

[Moritz Fischer]

On Tue, Mar 22, 2016 at 4:20 PM, Laura Abbott  wrote:
> On 03/22/2016 04:08 PM, Moritz Fischer wrote:
>>
>> Hi Laura,
>>
>> On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott  wrote:
>>
>>> In the past what drivers have done is a foo_ion_client_create which has
>>> the
>>> reference
>>> to the ion_device created from ion_device_create. Drivers then call the
>>> foo_ion_client_create function.
>>
>>
>> Oh, so you mean you add a function to create a client to the platform
>> device implementing
>> the heap and the export this function?
>>
>> heap implements:
>>
>> foo_create_client();
>>
>> driver calls:
>>
>> foo_create_client() ?
>>
>
> Yes, exactly
>
>>> Can you elaborate more on your sharing and allocation flow? This might
>>> suggest
>>> another idea.
>>
>>
>> Well I'll have a bunch of DMA streams to / from an FPGA that contains
>> DMA engines & accelerators. To that end
>> my userland software would allocate say 64 buffers, hand them over to
>> driver A to queue/deque them.
>>
>> In future I might want to share these buffers between streams and with
>> other peripherals on the same bus,
>> which is why I looked at ION.
>>
>
> If allocation is coming from userspace and drivers are only importing
> you should be using the dma_buf APIs instead of Ion APIs directly.
> Ion is a dma_buf exporter and dma_buf APIs are the preferred API.
>
>> Thanks,
>>
>> Moritz
>>
>
> Thanks,
> Laura

Re: [PATCH] arch: powerpc: mm: fixed spelling error.

[Andrew Donnellan]

Hi Alok

Thanks for wanting to contribute to the Linux kernel!

On 22/03/16 20:43, mistryalok wrote:

Fixed spelling error.
Signed-off-by: Alok Mistry 
---
/*
-* No CPU has hugepages but lacks no execute, so we
+* No CPU has huge pages but lacks no execute, so we
 * don't need to worry about that case
 */


Within the kernel, we have a lot of internal terminology. If you grep 
through the kernel source code, you'll find that in both the 
documentation and the code, we do use the term "hugepage". We also use 
"huge page", but "hugepage" is more common. Therefore I wouldn't call it 
a spelling error, just an internal term :)



Andrew

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH 1/2] mm/hugetlb: Introduce hugetlb_bad_size

[SeongJae Park]

Hello Vaishali,


The patch looks good to me.  However, I have few trivial questions.

On Tue, 22 Mar 2016, Vaishali Thakkar wrote:


When any unsupported hugepage size is specified, 'hugepagesz=' and
'hugepages=' should be ignored during command line parsing until any
supported hugepage size is found. But currently incorrect number of
hugepages are allocated when unsupported size is specified as it fails
to ignore the 'hugepages=' command.

Test case:

Note that this is specific to x86 architecture.

Boot the kernel with command line option 'hugepagesz=256M hugepages=X'.
After boot, dmesg output shows that X number of hugepages of the size 2M
is pre-allocated instead of 0.

So, to handle such command line options, introduce new routine
hugetlb_bad_size. The routine hugetlb_bad_size sets the global variable
parsed_valid_hugepagesz. We are using parsed_valid_hugepagesz to save the
state when unsupported hugepagesize is found so that we can ignore the
'hugepages=' parameters after that and then reset the variable when
supported hugepage size is found.

The routine hugetlb_bad_size can be called while setting 'hugepagesz='
parameter in an architecture specific code.

Signed-off-by: Vaishali Thakkar 
Cc: Mike Kravetz 
Cc: Naoya Horiguchi 
Cc: Hillf Danton 
Cc: Michal Hocko 
Cc: Yaowei Bai 
Cc: Dominik Dingel 
Cc: Kirill A. Shutemov 
Cc: Paul Gortmaker 
Cc: Dave Hansen 
---
The patch is having 2 checkpatch.pl warnings. I have just followed
the current code to maintain consistency. If we decide to silent
these warnings then may be we should silent those warnings as well.
I am fine with any option whichever works best for everyone else.
---
include/linux/hugetlb.h |  1 +
mm/hugetlb.c| 14 +-
2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 7d953c2..e44c578 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -338,6 +338,7 @@ int huge_add_to_page_cache(struct page *page, struct 
address_space *mapping,
/* arch callback */
int __init alloc_bootmem_huge_page(struct hstate *h);

+void __init hugetlb_bad_size(void);
void __init hugetlb_add_hstate(unsigned order);
struct hstate *size_to_hstate(unsigned long size);

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 06058ea..44fae6a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -51,6 +51,7 @@ __initdata LIST_HEAD(huge_boot_pages);
static struct hstate * __initdata parsed_hstate;
static unsigned long __initdata default_hstate_max_huge_pages;
static unsigned long __initdata default_hstate_size;
+static bool __initdata parsed_valid_hugepagesz = true;

/*
 * Protects updates to hugepage_freelists, hugepage_activelist, nr_huge_pages,
@@ -2659,6 +2660,11 @@ static int __init hugetlb_init(void)
subsys_initcall(hugetlb_init);

/* Should be called on processing a hugepagesz=... option */
+void __init hugetlb_bad_size(void)
+{
+   parsed_valid_hugepagesz = false;
+}
+
void __init hugetlb_add_hstate(unsigned int order)
{
struct hstate *h;
@@ -2691,11 +2697,17 @@ static int __init hugetlb_nrpages_setup(char *s)
unsigned long *mhp;
static unsigned long *last_mhp;

+   if (!parsed_valid_hugepagesz) {
+   pr_warn("hugepages = %s preceded by "
+   "an unsupported hugepagesz, ignoring\n", s);


How about concatenating the format string?  `CodingStyle` now suggests to
_never_ break every user-visible strings.


+   parsed_valid_hugepagesz = true;
+   return 1;
+   }
/*
 * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter 
yet,
 * so this hugepages= parameter goes to the "default hstate".
 */
-   if (!hugetlb_max_hstate)
+   else if (!hugetlb_max_hstate)


Because the upper `if` statement will do `return`, above change looks not
significantly necessary.  Is this intended?


mhp = &default_hstate_max_huge_pages;
else
mhp = &parsed_hstate->max_huge_pages;
--
2.1.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

Re: [RFC 0/2] staging: ion: of_ion_device_get

[Laura Abbott]

On 03/22/2016 04:08 PM, Moritz Fischer wrote:

Hi Laura,

On Tue, Mar 22, 2016 at 3:51 PM, Laura Abbott  wrote:


In the past what drivers have done is a foo_ion_client_create which has the
reference
to the ion_device created from ion_device_create. Drivers then call the
foo_ion_client_create function.


Oh, so you mean you add a function to create a client to the platform
device implementing
the heap and the export this function?

heap implements:

foo_create_client();

driver calls:

foo_create_client() ?



Yes, exactly


Can you elaborate more on your sharing and allocation flow? This might
suggest
another idea.


Well I'll have a bunch of DMA streams to / from an FPGA that contains
DMA engines & accelerators. To that end
my userland software would allocate say 64 buffers, hand them over to
driver A to queue/deque them.

In future I might want to share these buffers between streams and with
other peripherals on the same bus,
which is why I looked at ION.



If allocation is coming from userspace and drivers are only importing
you should be using the dma_buf APIs instead of Ion APIs directly.
Ion is a dma_buf exporter and dma_buf APIs are the preferred API.


Thanks,

Moritz



Thanks,
Laura