Re: [PATCH v2 2/4] mm/compaction: stop the isolation when we isolate enough freepage

[Zhang Yanfei]

Hello,

At 2015/1/30 20:34, Joonsoo Kim wrote:
> From: Joonsoo 
> 
> Currently, freepage isolation in one pageblock doesn't consider how many
> freepages we isolate. When I traced flow of compaction, compaction
> sometimes isolates more than 256 freepages to migrate just 32 pages.
> 
> In this patch, freepage isolation is stopped at the point that we
> have more isolated freepage than isolated page for migration. This
> results in slowing down free page scanner and make compaction success
> rate higher.
> 
> stress-highalloc test in mmtests with non movable order 7 allocation shows
> increase of compaction success rate.
> 
> Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> 27.13 : 31.82
> 
> pfn where both scanners meets on compaction complete
> (separate test due to enormous tracepoint buffer)
> (zone_start=4096, zone_end=1048576)
> 586034 : 654378
> 
> In fact, I didn't fully understand why this patch results in such good
> result. There was a guess that not used freepages are released to pcp list
> and on next compaction trial we won't isolate them again so compaction
> success rate would decrease. To prevent this effect, I tested with adding
> pcp drain code on release_freepages(), but, it has no good effect.
> 
> Anyway, this patch reduces waste time to isolate unneeded freepages so
> seems reasonable.

Reviewed-by: Zhang Yanfei 

IMHO, the patch making the free scanner move slower makes both scanners
meet further. Before this patch, if we isolate too many free pages and even 
after we release the unneeded free pages later the free scanner still already
be there and will be moved forward again next time -- the free scanner just
cannot be moved back to grab the free pages we released before no matter where
the free pages in, pcp or buddy. 

> 
> Signed-off-by: Joonsoo Kim 
> ---
>  mm/compaction.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 4954e19..782772d 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -490,6 +490,13 @@ static unsigned long isolate_freepages_block(struct 
> compact_control *cc,
>  
>   /* If a page was split, advance to the end of it */
>   if (isolated) {
> + cc->nr_freepages += isolated;
> + if (!strict &&
> + cc->nr_migratepages <= cc->nr_freepages) {
> + blockpfn += isolated;
> + break;
> + }
> +
>   blockpfn += isolated - 1;
>   cursor += isolated - 1;
>   continue;
> @@ -899,7 +906,6 @@ static void isolate_freepages(struct compact_control *cc)
>   unsigned long isolate_start_pfn; /* exact pfn we start at */
>   unsigned long block_end_pfn;/* end of current pageblock */
>   unsigned long low_pfn;   /* lowest pfn scanner is able to scan */
> - int nr_freepages = cc->nr_freepages;
>   struct list_head *freelist = >freepages;
>  
>   /*
> @@ -924,11 +930,11 @@ static void isolate_freepages(struct compact_control 
> *cc)
>* pages on cc->migratepages. We stop searching if the migrate
>* and free page scanners meet or enough free pages are isolated.
>*/
> - for (; block_start_pfn >= low_pfn && cc->nr_migratepages > nr_freepages;
> + for (; block_start_pfn >= low_pfn &&
> + cc->nr_migratepages > cc->nr_freepages;
>   block_end_pfn = block_start_pfn,
>   block_start_pfn -= pageblock_nr_pages,
>   isolate_start_pfn = block_start_pfn) {
> - unsigned long isolated;
>  
>   /*
>* This can iterate a massively long zone without finding any
> @@ -953,9 +959,8 @@ static void isolate_freepages(struct compact_control *cc)
>   continue;
>  
>   /* Found a block suitable for isolating free pages from. */
> - isolated = isolate_freepages_block(cc, _start_pfn,
> + isolate_freepages_block(cc, _start_pfn,
>   block_end_pfn, freelist, false);
> - nr_freepages += isolated;
>  
>   /*
>* Remember where the free scanner should restart next time,
> @@ -987,8 +992,6 @@ static void isolate_freepages(struct compact_control *cc)
>*/
>   if (block_start_pfn < low_pfn)
>   cc->free_pfn = cc->migrate_pfn;
> -
> - cc->nr_freepages = nr_freepages;
>  }
>  
>  /*
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] mm/compaction: fix wrong order check in compact_finished()

[Zhang Yanfei]

Hello,

At 2015/1/30 20:34, Joonsoo Kim wrote:
> What we want to check here is whether there is highorder freepage
> in buddy list of other migratetype in order to steal it without
> fragmentation. But, current code just checks cc->order which means
> allocation request order. So, this is wrong.
> 
> Without this fix, non-movable synchronous compaction below pageblock order
> would not stopped until compaction is complete, because migratetype of most
> pageblocks are movable and high order freepage made by compaction is usually
> on movable type buddy list.
> 
> There is some report related to this bug. See below link.
> 
> http://www.spinics.net/lists/linux-mm/msg81666.html
> 
> Although the issued system still has load spike comes from compaction,
> this makes that system completely stable and responsive according to
> his report.
> 
> stress-highalloc test in mmtests with non movable order 7 allocation doesn't
> show any notable difference in allocation success rate, but, it shows more
> compaction success rate.
> 
> Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> 18.47 : 28.94
> 
> Cc: 
> Acked-by: Vlastimil Babka 
> Signed-off-by: Joonsoo Kim 

Reviewed-by: Zhang Yanfei 

> ---
>  mm/compaction.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index b68736c..4954e19 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1173,7 +1173,7 @@ static int __compact_finished(struct zone *zone, struct 
> compact_control *cc,
>   return COMPACT_PARTIAL;
>  
>   /* Job done if allocation would set block type */
> - if (cc->order >= pageblock_order && area->nr_free)
> + if (order >= pageblock_order && area->nr_free)
>   return COMPACT_PARTIAL;
>   }
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: enhance check for seq_printf uses that could be seq_puts

[Joe Perches]

On Sat, 2015-01-31 at 04:04 +0200, Heba Aamer wrote:
> This patch enhances the check for seq_printf uses that could
> be seq_puts.
> 
> It was considering the escape of % is \%, but it is %%.
> This led to skipping some valid cases related to that warning.  
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -4804,11 +4804,14 @@ sub process {
>  # check for seq_printf uses that could be seq_puts
>   if ($sline =~ /\bseq_printf\s*\(.*"\s*\)\s*;\s*$/) {
>   my $fmt = get_quoted_string($line, $rawline);
> - if ($fmt ne "" && $fmt !~ /[^\\]\%/) {
> - if (WARN("PREFER_SEQ_PUTS",
> -  "Prefer seq_puts to seq_printf\n" . 
> $herecurr) &&
> - $fix) {
> - $fixed[$fixlinenr] =~ 
> s/\bseq_printf\b/seq_puts/;
> + if ($fmt ne "") {
> + $fmt =~ s/%%//g;
> + if ($fmt !~ /%/) {
> + if (WARN("PREFER_SEQ_PUTS",
> +  "Prefer seq_puts to 
> seq_printf\n" . $herecurr) &&
> + $fix) {
> + $fixed[$fixlinenr] =~ 
> s/\bseq_printf\b/seq_puts/;
> + }
>   }
>   }
>   }

Probably be simpler to use:
---
 scripts/checkpatch.pl | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 059c032..7f1804e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4854,7 +4854,8 @@ sub process {
 # check for seq_printf uses that could be seq_puts
if ($sline =~ /\bseq_printf\s*\(.*"\s*\)\s*;\s*$/) {
my $fmt = get_quoted_string($line, $rawline);
-   if ($fmt ne "" && $fmt !~ /[^\\]\%/) {
+   $fmt =~ s/%%//g;
+   if ($fmt !~ /%/) {
if (WARN("PREFER_SEQ_PUTS",
 "Prefer seq_puts to seq_printf\n" . 
$herecurr) &&
$fix) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Documentation/x86: fix path in zero-page.txt

[Alexander Kuleshov]

Signed-off-by: Alexander Kuleshov 
---
 Documentation/x86/zero-page.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index 199f453..82fbdbc 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -3,7 +3,7 @@ protocol of kernel. These should be filled by bootloader or 
16-bit
 real-mode setup code of the kernel. References/settings to it mainly
 are in:
 
-  arch/x86/include/asm/bootparam.h
+  arch/x86/include/uapi/asm/bootparam.h
 
 
 Offset Proto   NameMeaning
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP system

[Felipe Balbi]

+linux-omap

On Fri, Jan 30, 2015 at 04:43:30PM -0800, Stephen Boyd wrote:
> In a uniprocessor implementation the interrupt processor targets
> registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
> gic_get_cpumask() will print a critical message saying
> 
>  GIC CPU mask not found - kernel will fail to boot.
> 
> if these registers all read as zero, but there won't actually be
> a problem on uniprocessor systems and the kernel will boot just
> fine. Skip this check if we're running a UP kernel or if we
> detect that the hardware only supports a single processor.
> 

Nice, I'll test this on AM437x on Monday but certainly looks promising:

Acked-by: Felipe Balbi 


> Acked-by: Nicolas Pitre 
> Cc: Russell King 
> Cc: Stefan Agner 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/irqchip/irq-gic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d617ee5a3d8a..1b70e0de0f6e 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -346,7 +346,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
>   break;
>   }
>  
> - if (!mask)
> + if (!mask && num_possible_cpus() > 1)
>   pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
>  
>   return mask;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/3] An alternative to SPI NAND

[Brian Norris]

On Fri, Jan 30, 2015 at 08:47:29AM -0300, Ezequiel Garcia wrote:
> On 01/29/2015 09:57 PM, Peter Pan 潘栋 (peterpandong) wrote:
> [..]
> > 
> > Currently, we are working on sharing the bbt code. I think your and Brain's 
> > suggestion
> > will be very helpful.
> > 
> > There are two options. We can put struct nand_bbt pointer in either 
> > nand_chip
> > or mtd_info structure.
> 
> I'm sorry, you lost me here. Do you mean struct nand_bbt_descr ?

I'm assuming he's suggesting a new struct that he's calling nand_bbt.

> > If put nand_bbt in nand_chip, we need to change the
> 
> I thought the plan was NOT to base spi-nand on nand, so you can't put
> this in nand_chip, can you?

You could. It's just a matter of who does the pointer chasing. (It's
just important that nand_bbt.c doesn't *assume* that it has nand_chip as
a parent.)

If struct nand_bbt is embedded directly in struct mtd_info, then
nand_bbt.c could implement functions such that its users can just do
this:

mtd->_block_isbad = nand_bbt_blockisbad;

But if you don't (and instead embed it in a custom location like
nand_chip), we'd have to write wrappers that call the nand_bbt_*
functions (like nand_base does today). e.g.:

mtd->_block_isbad = spi_nand_blockisbad;

int spi_nand_block_isbad(struct mtd_info *mtd, loff_t offs)
{
struct spi_nand_chip *chip = mtd->priv;
struct nand_bbt *bbt = chip->bbt;

return nand_bbt_blockisbad(bbt, offs);
}

Anyway, I think it's worth laying out exactly where the pieces are going
to fit here. I reckon we need the following:

 1. a short list of parameters that nand_bbt needs from the NAND
 implementation (either nand_base or spi-nand-*)

 2. a list of parameters that need to be kept around for nand_bbt
 bookkeeping / handling

 3. an init function (nand_bbt_init()?) that takes #1 and computes #2

 3(a) a corresponding release function

 4. a set of functions that, given only a few obvious parameters (e.g.,
 block offsets) and a struct that holds #2, handle all BBT needs (e.g.,
 bad block lookup, bad block scanning, marking new bad blocks)

Since I see #1 and #2 overlapping quite a bit, we might combine them,
where several parameters are expected to be set by the nand_bbt user
(either nand_base.c or nand_bbt.c), and a few are considered private to
nand_bbt.

struct nand_bbt {
struct mtd_info *mtd;

/*
 * This is important to abstract out of nand_bbt.c and provide
 * separately in nand_base.c and spi-nand-base.c -- it's sort of
 * duplicated in nand_block_bad() (nand_base) and
 * scan_block_fast() (nand_bbt) right now
 *
 * Note that this also means nand_chip.badblock_pattern should
 * be removed from nand_bbt.c
 */
int (*is_bad_bbm)(struct mtd_info *mtd, loff_t ofs);

/* Only required if the driver wants to attempt to program new
 * bad block markers that imitate the factory-marked BBMs */
int (*mark_bad_bbm)(struct mtd_info *mtd, loff_t ofs);

unsigned int bbt_options;

/* Only required for NAND_BBT_PERCHIP */
int numchips;

/* Discourage new customer usages here; suggest usage of the
 * relevant NAND_BBT_* options instead */
struct nand_bbt_descr *bbt_td;
struct nand_bbt_descr *bbt_md;

/* The rest are filled in by nand_bbt_init() */

int bbt_erase_shift;
int page_shift;

u8 *bbt;
};

#3 might simply look like:

int nand_bbt_init(struct nand_bbt *bbt);
void nand_bbt_release(struct nand_bbt *bbt);

#4 might look like the following APIs for nand_bbt.c (not too different
than we have now):

int nand_bbt_init(struct nand_bbt *bbt); /* init + scan? */
int nand_bbt_markbad(struct nand_bbt *bbt, loff_t offs);
int nand_bbt_isreserved(struct nand_bbt *bbt, loff_t offs);
int nand_bbt_isbad(struct nand_bbt *bbt, loff_t offs);

(The above allows for nand_bbt to be embedded anywhere; we could modify
this API to be drop-in replacements for the mtd_info callbacks if we
embed struct nand_bbt in mtd_info.)

> Also: After looking at the nand_bbt.c file, I'm wondering how promising
> is to separate it from NAND. It seems the BBT code is quite attached to
> NAND!

There will be quite a bit of churn, but I don't think that it is too
strongly attached.

> Are you planning to do this in just one patch? Maybe it's better to
> start simple and prepare small patches that gradually make the
> nand_base.c and nand_bbt.c files less dependent.

Yeah, a series of patches would be best. And maybe start smaller.

If the nand_bbt stuff really slows someone down, we might want to just
agree on an API similar to the above and then work on the rest of the
SPI NAND details, assuming someone (e.g., me) writes the implementation
(and transitions other drivers to do this).

Unless someone else thinks they have an excellent handle on the above,
I'll take a stab at doing this. I actually have a few patches that have
hung 

[PATCH v2 2/2] x86/boot: use already defined KEEP_SEGMENTS macro in head_{32,64}.S

[Alexander Kuleshov]

There is already defined macro KEEP_SEGMENTS in the
bootparam.h, let's use it instead of shifting bits

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/boot/compressed/head_32.S | 5 +++--
 arch/x86/boot/compressed/head_64.S | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/head_32.S 
b/arch/x86/boot/compressed/head_32.S
index 1d7fbbc..11e549d 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -29,7 +29,8 @@
 #include 
 #include 
 #include 
-
+#include 
+   
__HEAD
 ENTRY(startup_32)
 #ifdef CONFIG_EFI_STUB
@@ -102,7 +103,7 @@ preferred_addr:
 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
 * us to not reload segments
 */
-   testb   $(1<<6), BP_loadflags(%esi)
+   testb   $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 1f
 
cli
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 6b1766c..90c1521 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
__HEAD
.code32
@@ -46,7 +47,7 @@ ENTRY(startup_32)
 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
 * us to not reload segments
 */
-   testb $(1<<6), BP_loadflags(%esi)
+   testb $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 1f
 
cli
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] x86: use already defined KEEP_SEGMENTS macro from bootparam.h

[Alexander Kuleshov]

There is already defined macro KEEP_SEGMENTS in the
bootparam.h, let's use it instead of shifting bits

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/kernel/head_32.S | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index f36bd42..fba3990 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -22,7 +22,8 @@
 #include 
 #include 
 #include 
-
+#include 
+   
 /* Physical address */
 #define pa(X) ((X) - __PAGE_OFFSET)
 
@@ -89,8 +90,8 @@ ENTRY(startup_32)
movl pa(stack_start),%ecx

/* test KEEP_SEGMENTS flag to see if the bootloader is asking
-   us to not reload segments */
-   testb $(1<<6), BP_loadflags(%esi)
+  us to not reload segments */
+   testb $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 2f
 
 /*
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] x86: loadflags cleanups

[Alexander Kuleshov]

There are a couple macros in the arch/x86/include/uapi/asm/bootparam.h
for checking loadflags bits. Let's use it instead of shifting bits

Alexander Kuleshov (2):
  x86: use already defined KEEP_SEGMENTS macro from bootparam.h
  x86/boot: use already defined KEEP_SEGMENTS macro in head_{32,64}.S

 arch/x86/boot/compressed/head_32.S | 5 +++--
 arch/x86/boot/compressed/head_64.S | 3 ++-
 arch/x86/kernel/head_32.S  | 7 ---
 3 files changed, 9 insertions(+), 6 deletions(-)

-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] x86/boot: use already defined KEEP_SEGMENTS macro in head_{32,64}.S

[Alexander Kuleshov]

Sorry for noise, misunderstood  send-email alias with maintainers.

2015-01-31 12:30 GMT+06:00 Alexander Kuleshov :
> There is already defined macro KEEP_SEGMENTS in the
> bootparam.h, let's use it instead of shifting bits
>
> Signed-off-by: Alexander Kuleshov 
> ---
>  arch/x86/boot/compressed/head_32.S | 5 +++--
>  arch/x86/boot/compressed/head_64.S | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/head_32.S 
> b/arch/x86/boot/compressed/head_32.S
> index 1d7fbbc..11e549d 100644
> --- a/arch/x86/boot/compressed/head_32.S
> +++ b/arch/x86/boot/compressed/head_32.S
> @@ -29,7 +29,8 @@
>  #include 
>  #include 
>  #include 
> -
> +#include 
> +
> __HEAD
>  ENTRY(startup_32)
>  #ifdef CONFIG_EFI_STUB
> @@ -102,7 +103,7 @@ preferred_addr:
>  * Test KEEP_SEGMENTS flag to see if the bootloader is asking
>  * us to not reload segments
>  */
> -   testb   $(1<<6), BP_loadflags(%esi)
> +   testb   $KEEP_SEGMENTS, BP_loadflags(%esi)
> jnz 1f
>
> cli
> diff --git a/arch/x86/boot/compressed/head_64.S 
> b/arch/x86/boot/compressed/head_64.S
> index 6b1766c..90c1521 100644
> --- a/arch/x86/boot/compressed/head_64.S
> +++ b/arch/x86/boot/compressed/head_64.S
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
> __HEAD
> .code32
> @@ -46,7 +47,7 @@ ENTRY(startup_32)
>  * Test KEEP_SEGMENTS flag to see if the bootloader is asking
>  * us to not reload segments
>  */
> -   testb $(1<<6), BP_loadflags(%esi)
> +   testb $KEEP_SEGMENTS, BP_loadflags(%esi)
> jnz 1f
>
> cli
> --
> 2.3.0-rc1
>



-- 
_
0xAX
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] x86/boot: use already defined KEEP_SEGMENTS macro in head_{32,64}.S

[Alexander Kuleshov]

There is already defined macro KEEP_SEGMENTS in the
bootparam.h, let's use it instead of shifting bits

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/boot/compressed/head_32.S | 5 +++--
 arch/x86/boot/compressed/head_64.S | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/head_32.S 
b/arch/x86/boot/compressed/head_32.S
index 1d7fbbc..11e549d 100644
--- a/arch/x86/boot/compressed/head_32.S
+++ b/arch/x86/boot/compressed/head_32.S
@@ -29,7 +29,8 @@
 #include 
 #include 
 #include 
-
+#include 
+   
__HEAD
 ENTRY(startup_32)
 #ifdef CONFIG_EFI_STUB
@@ -102,7 +103,7 @@ preferred_addr:
 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
 * us to not reload segments
 */
-   testb   $(1<<6), BP_loadflags(%esi)
+   testb   $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 1f
 
cli
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 6b1766c..90c1521 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
__HEAD
.code32
@@ -46,7 +47,7 @@ ENTRY(startup_32)
 * Test KEEP_SEGMENTS flag to see if the bootloader is asking
 * us to not reload segments
 */
-   testb $(1<<6), BP_loadflags(%esi)
+   testb $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 1f
 
cli
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] x86: loadflags cleanups

[Alexander Kuleshov]

There are a couple macros in the arch/x86/include/uapi/asm/bootparam.h
for checking loadflags bits. Let's use it instead of shifting bits

Alexander Kuleshov (2):
  x86: use already defined KEEP_SEGMENTS macro from bootparam.h
  x86/boot: use already defined KEEP_SEGMENTS macro in head_{32,64}.S

 arch/x86/boot/compressed/head_32.S | 5 +++--
 arch/x86/boot/compressed/head_64.S | 3 ++-
 arch/x86/kernel/head_32.S  | 7 ---
 3 files changed, 9 insertions(+), 6 deletions(-)

-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/2] x86: use already defined KEEP_SEGMENTS macro from bootparam.h

[Alexander Kuleshov]

There is already defined macro KEEP_SEGMENTS in the
bootparam.h, let's use it instead of shifting bits

Signed-off-by: Alexander Kuleshov 
---
 arch/x86/kernel/head_32.S | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index f36bd42..fba3990 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -22,7 +22,8 @@
 #include 
 #include 
 #include 
-
+#include 
+   
 /* Physical address */
 #define pa(X) ((X) - __PAGE_OFFSET)
 
@@ -89,8 +90,8 @@ ENTRY(startup_32)
movl pa(stack_start),%ecx

/* test KEEP_SEGMENTS flag to see if the bootloader is asking
-   us to not reload segments */
-   testb $(1<<6), BP_loadflags(%esi)
+  us to not reload segments */
+   testb $KEEP_SEGMENTS, BP_loadflags(%esi)
jnz 2f
 
 /*
-- 
2.3.0-rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/19] arm64: expose number of page table levels on Kconfig level

[Jungseok Lee]

On Jan 30, 2015, at 11:56 PM, Catalin Marinas wrote:
> On Fri, Jan 30, 2015 at 02:43:11PM +, Kirill A. Shutemov wrote:
>> We would want to use number of page table level to define mm_struct.
>> Let's expose it as CONFIG_PGTABLE_LEVELS.
>> 
>> ARM64_PGTABLE_LEVELS is renamed to PGTABLE_LEVELS and defined before
>> sourcing init/Kconfig: arch/Kconfig will define default value and it's
>> sourced from init/Kconfig.
>> 
>> Signed-off-by: Kirill A. Shutemov 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
> 
> It looks fine.
> 
> Acked-by: Catalin Marinas 

A system can boot up successfully on top of arm64/for-next/core branch under
4KB + {3|4}Level + CONFIG_DEBUG_RODATA, but I don't try it with 64KB pages.

Best Regards
Jungseok Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/19] expose page table levels on Kconfig leve

[Guenter Roeck]

On 01/30/2015 04:11 PM, Kirill A. Shutemov wrote:


The patch below should fix all regressions from -next.
Please test.


Here is the current status, with the tip of your config_pgtable_levels
branch plus a couple of fixes addressing most of the build failures
your branch inherited from -next.

Build results:
total: 134 pass: 133 fail: 1
Failed builds:
sparc64:allmodconfig
Qemu tests:
total: 30 pass: 30 fail: 0

The remaining build failure is not related to your patch series.
There are also some WARNING tracebacks in the arm qemu test, but
those are also not related to your series.

Feel free to add

Tested-by: Guenter Roeck 

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: pxa: Fix typo in zeus.c

[Masanari Iida]

This patch fix a typo in struct platform_device can_regulator_device.

Signed-off-by: Masanari Iida 
---
 arch/arm/mach-pxa/zeus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-pxa/zeus.c b/arch/arm/mach-pxa/zeus.c
index 205f9bf..ac2ae5c 100644
--- a/arch/arm/mach-pxa/zeus.c
+++ b/arch/arm/mach-pxa/zeus.c
@@ -412,7 +412,7 @@ static struct fixed_voltage_config can_regulator_pdata = {
 };
 
 static struct platform_device can_regulator_device = {
-   .name   = "reg-fixed-volage",
+   .name   = "reg-fixed-voltage",
.id = 0,
.dev= {
.platform_data  = _regulator_pdata,
-- 
2.3.0.rc1.30.g76afe74

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

[Ohad Ben-Cohen]

On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson  wrote:
> In a system where you have two hwlock blocks lckA and lckB, each
> consisting of 8 locks and you have dspB that can only access lckB

This is a good example - thanks. To be able to cope with such cases we
will have to pass a hwlock block reference and its relative lock id.

The DT binding should definitely be prepared for such cases (just kill
the base-id field?), but let's see what it means about the Linux
implementation.

Since the existence of several hwblocks is still fictional (Bjorn,
please confirm too?), we may prefer to introduce changes to support it
only when it shows up; it all depends on the amount of changes needed.
Suman, care to take a look please?

>> - Sometimes a remote processor, which may not be running Linux, will
>> have to dynamically allocate a hwlock, and send the ID of the
>> allocated lock to us (another processor running Linux)
>>
> I'm sorry but you cannot have a system on both sides that is allowed
> to do dynamic allocation from a limited set of resources.

Of course not. On such systems, Linux is not the one responsible for
allocating the hwlocks, at least not during part of the time or from
part of the hwlocks. There were a few different use cases, with
different semantics, that required communicating to Linux an hwlock
id, but since none of them have reached mainline, we should only
remember they may show up one day, but not put too much effort to
support them right now.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Clock Regression in next-20150130 caused by cb75a8fcd14e

[Guenter Roeck]

On Fri, Jan 30, 2015 at 05:04:44PM -0800, Tony Lindgren wrote:
> Hi all,
> 
> Looks like commit cb75a8fcd14e ("clk: Add rate constraints to clocks")
> causes a regression on at least omaps where the serial console either
> does not show anything, or just prints garbage.
> 
> Reverting cb75a8fcd14e makes things work again on next-20150130.
> 
> Any ideas?
> 
The patch seems to have some problems.
Also see http://www.spinics.net/lists/kernel/msg1916843.html.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mips: Re-introduce copy_user_page

[Guenter Roeck]

Commit bcd022801ee5 ("MIPS: Fix COW D-cache aliasing on fork") replaced
the inline function copy_user_page for mips with an external reference,
but neglected to introduce the actual non-inline function. Restore it.

Fixes: bcd022801ee5 ("MIPS: Fix COW D-cache aliasing on fork")
Fixes: 4927b7d77c00 ("dax,ext2: replace the XIP page fault handler with the DAX 
page fault handler")
Cc: Atsushi Nemoto 
Cc: Matthew Wilcox 
Signed-off-by: Guenter Roeck 
---
4927b7d77c00 is in -next.

 arch/mips/include/asm/page.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 154b70a..69c2f19 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -105,8 +105,17 @@ static inline void clear_user_page(void *addr, unsigned 
long vaddr,
flush_data_cache_page((unsigned long)addr);
 }
 
-extern void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
-   struct page *to);
+static inline void copy_user_page(void *vto, void *vfrom, unsigned long vaddr,
+ struct page *to)
+{
+   extern void (*flush_data_cache_page)(unsigned long addr);
+
+   copy_page(vto, vfrom);
+   if (!cpu_has_ic_fills_f_dc || pages_do_alias((unsigned long)vto,
+vaddr & PAGE_MASK))
+   flush_data_cache_page((unsigned long)vto);
+}
+
 struct vm_area_struct;
 extern void copy_user_highpage(struct page *to, struct page *from,
unsigned long vaddr, struct vm_area_struct *vma);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powerpc/mm: bail out early when flushing TLB page

[Arseny Solokha]

> On Fri, 2015-01-30 at 19:08 +0700, Arseny Solokha wrote:
>> MMU_NO_CONTEXT is conditionally defined as 0 or (unsigned int)-1.
>
> For nohash it is specifically -1.

>>  However, in __flush_tlb_page() a corresponding variable is only tested
>> for open coded 0, which can cause NULL pointer dereference if `mm'
>> argument was legitimately passed as such.
>>
>> Bail out early in case the first argument is NULL, thus eliminate confusion
>> between different values of MMU_NO_CONTEXT and avoid disabling and then
>> re-enabling preemption unnecessarily.
>
> How did you notice this?  Did you see an oops, or was it code
> inspection?  I'm wondering what codepath gets here with mm == NULL.

Just a code inspection. It didn't seemed right at the first glance.

Arsény


>
> -Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4] tick/hotplug: Handover time related duties before cpu offline

[Preeti U Murthy]

These duties include do_timer to update jiffies and broadcast wakeups on those
platforms which do not have an external device to handle wakeup of cpus from 
deep
idle states. The handover of these duties is not robust against a cpu offline
operation today.

The do_timer duty is handed over in the CPU_DYING phase today to one of the 
online
cpus. This relies on the fact that *all* cpus participate in stop_machine phase.
But if this design is to change in the future, i.e. if all cpus are not
required to participate in stop_machine, the freshly nominated do_timer cpu
could be idle at the time of handover. In that case, unless its interrupted,
it will not wakeup to update jiffies and timekeeping will hang.

With regard to broadcast wakeups, today if the cpu handling broadcast of wakeups
goes offline, the job of broadcasting is handed over to another cpu in the 
CPU_DEAD
phase. The CPU_DEAD notifiers are run only after the offline cpu sets its state 
as
CPU_DEAD. Meanwhile, the kthread doing the offline is scheduled out while 
waiting for
this transition by queuing a timer. This is fatal because if the cpu on which
this kthread was running has no other work queued on it, it can re-enter deep
idle state, since it sees that a broadcast cpu still exists. However the 
broadcast
wakeup will never come since the cpu which was handling it is offline, and the 
cpu
on which the kthread doing the hotplug operation was running never wakes up to 
see
this because its in deep idle state.

Fix these issues by handing over the do_timer and broadcast wakeup duties just 
before
the offline cpu kills itself, to the cpu performing the hotplug operation. 
Since the
cpu performing the hotplug operation is up and running, it becomes aware of the 
handover
of do_timer duty and queues the broadcast timer upon itself so as to seamlessly
continue both these operations.

It fixes the bug reported here:
http://linuxppc.10917.n7.nabble.com/offlining-cpus-breakage-td88619.html

Signed-off-by: Preeti U Murthy 
---
Changes from V3: https://lkml.org/lkml/2015/1/20/236
1. Move handover of broadcast duty away from CPU_DYING phase to just before
the cpu kills itself.
2. Club the handover of timekeeping duty along with broadcast duty to make
timekeeping robust against hotplug.

 include/linux/tick.h |2 ++
 kernel/cpu.c |4 
 kernel/time/clockevents.c|4 
 kernel/time/tick-broadcast.c |4 +---
 kernel/time/tick-common.c|   12 +---
 kernel/time/tick-internal.h  |3 ++-
 6 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/include/linux/tick.h b/include/linux/tick.h
index eda850c..6634be5 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -78,6 +78,7 @@ struct tick_sched {
 extern void __init tick_init(void);
 extern int tick_is_oneshot_available(void);
 extern struct tick_device *tick_get_device(int cpu);
+extern void tick_handover_tk(int hcpu);
 
 # ifdef CONFIG_HIGH_RES_TIMERS
 extern int tick_init_highres(void);
@@ -120,6 +121,7 @@ static inline int tick_oneshot_mode_active(void) { return 
0; }
 #else /* CONFIG_GENERIC_CLOCKEVENTS */
 static inline void tick_init(void) { }
 static inline void tick_cancel_sched_timer(int cpu) { }
+static inline void tick_handover_tk(int hcpu) {}
 static inline void tick_clock_notify(void) { }
 static inline int tick_check_oneshot_change(int allow_nohz) { return 0; }
 static inline void tick_irq_enter(void) { }
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 5d22023..329ec59 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "smpboot.h"
@@ -421,6 +422,9 @@ static int __ref _cpu_down(unsigned int cpu, int 
tasks_frozen)
while (!idle_cpu(cpu))
cpu_relax();
 
+   /* Handover timekeeping and broadcast duties to the current cpu */
+   tick_handover_tk(cpu);
+
/* This actually kills the CPU. */
__cpu_die(cpu);
 
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 5544990..2b10b13 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -566,10 +566,6 @@ int clockevents_notify(unsigned long reason, void *arg)
ret = tick_broadcast_oneshot_control(reason);
break;
 
-   case CLOCK_EVT_NOTIFY_CPU_DYING:
-   tick_handover_do_timer(arg);
-   break;
-
case CLOCK_EVT_NOTIFY_SUSPEND:
tick_suspend();
tick_suspend_broadcast();
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 066f0ec..4f59ede 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -669,7 +669,7 @@ static void broadcast_shutdown_local(struct 
clock_event_device *bc,
clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN);
 }
 
-static void broadcast_move_bc(int deadcpu)
+void tick_handover_broadcast(int deadcpu)
 {
struct clock_event_device *bc = 

[BUG, bisect] hang when copying large file to disc

[Jeremiah Mahler]

If a large file (> 1 GB) is transferred from a USB stick or a mmc
to an local disc (using ext4), it will proceed normally until it
has transferred approximately 600 MB.  Then the speed will drop off
to zero and the terminal performing the operation will usually
hang.  And sometimes other terminals will hang as well.  A reboot
is required to get the system working again.

  mount /dev/sdb1 /mnt
  pv /mnt/large_file > large_file_out
  (... ~600 MB ... hang)

I have performed a bisect and found that commit ef39794651347 introduced
the bug.  This commit is present in the latest -next 20150130.

  From ef397946513470381c0e9ed5b355cd1c9855a364 Mon Sep 17 00:00:00 2001
  From: Theodore Ts'o 
  Date: Sat, 24 Jan 2015 20:51:05 -0500
  Subject: [PATCH] vfs: add support for a lazytime mount option
  
  Add a new mount option which enables a new "lazytime" mode.  This mode
  causes atime, mtime, and ctime updates to only be made to the
  in-memory version of the inode.  The on-disk times will only get
  updated when (a) if the inode needs to be updated for some non-time
  related change, (b) if userspace calls fsync(), syncfs() or sync(), or
  (c) just before an undeleted inode is evicted from memory.
  
  This is OK according to POSIX because there are no guarantees after a
  crash unless userspace explicitly requests via a fsync(2) call.
  
  For workloads which feature a large number of random write to a
  preallocated file, the lazytime mount option significantly reduces
  writes to the inode table.  The repeated 4k writes to a single block
  will result in undesirable stress on flash devices and SMR disk
  drives.  Even on conventional HDD's, the repeated writes to the inode
  table block will trigger Adjacent Track Interference (ATI) remediation
  latencies, which very negatively impact long tail latencies --- which
  is a very big deal for web serving tiers (for example).
  
  Google-Bug-Id: 18297052
  
  Signed-off-by: Theodore Ts'o 
  ---
   fs/ext4/inode.c  |  6 
   fs/fs-writeback.c| 62 
+---
   fs/gfs2/file.c   |  4 +--
   fs/inode.c   | 56 +---
   fs/jfs/file.c|  2 +-
   fs/libfs.c   |  2 +-
   fs/proc_namespace.c  |  1 +
   fs/sync.c|  8 ++
   include/linux/backing-dev.h  |  1 +
   include/linux/fs.h   |  5 
   include/trace/events/writeback.h | 60 +-
   include/uapi/linux/fs.h  |  4 ++-
   mm/backing-dev.c | 10 +--
   13 files changed, 186 insertions(+), 35 deletions(-)

If I can do anything else to help, let me know.

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] IRQ: don't suspend nested_thread irqs over system suspend.

[NeilBrown]

On Sat, 31 Jan 2015 00:51:17 +0100 "Rafael J. Wysocki" 
wrote:

> On Saturday, January 31, 2015 12:06:37 AM Rafael J. Wysocki wrote:
> > On Saturday, January 31, 2015 09:25:45 AM NeilBrown wrote:
> > > 
> > > Nested IRQs can only fire when the parent irq fires.
> > > So when the parent is suspended, there is no need to suspend
> > > the child irq.
> > > 
> > > Suspending nested irqs can cause a problem is they are suspended or
> > > resumed in the wrong order.
> > > If an interrupt fires while the parent is active but the child is
> > > suspended, then the interrupt will not be acknowledged properly
> > > and so an interrupt storm can result.
> > > This is particularly likely if the parent is resumed before
> > > the child, and the interrupt was raised during suspend.
> > > 
> > > Ensuring correct ordering would be possible, but it is simpler
> > > to just never suspend nested interrupts.  This patch does that.
> > 
> > Clever. :-)
> > 
> > This is fine by me.  Thomas, what do you think?
> 
> It looks like I've overlooked a potential problem, though.
> 
> Can a nested interrupt be a wakeup one?  We won't set IRQD_WAKEUP_ARMED for it
> then and may not handle wakeup correctly.
> 

I only have a fairly narrow understanding of this stuff, but if you have
nested interrupts, you would surely need the parent to be registered as a
wakeup interrupt, else the device wouldn't wake and the nested interrupt
would be ineffective until something else woke the device.

Very few files mention both '.irq_set_wake' and  'irq_set_nested'.

twl6040-irq.c has code to set irq_wake_enable  on the parent if any nested
irqs have had irq_set_wake calls.
tps6586x.c has something similar, but much simpler.
arizona-irq.c and rc5t583-irq.c do the same as tps6586x.c

So I think that any nested interrupts which might want to be wakeup
interrupts already deal with the issue, and I don't introduce a new problem
here.

Thanks,
NeilBrown

> > > This patch allows the IRQF_EARLY_RESUME to be removed from
> > > twl4030_sih_setup().  That flag attempts to fix the same problem
> > > is a very different way, but causes
> > > 
> > > [   56.095825] WARNING: CPU: 0 PID: 3 at ../kernel/irq/manage.c:661 
> > > irq_nested_primary_handler+0x18/0x28()
> > > [   56.095825] Primary handler called for nested irq 348
> > > 
> > > warnings on resume.
> > > 
> > > Signed-off-by: NeilBrown 
> > > 
> > > diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> > > index 3ca532592704..40cbcfb7fc43 100644
> > > --- a/kernel/irq/pm.c
> > > +++ b/kernel/irq/pm.c
> > > @@ -118,6 +118,8 @@ void suspend_device_irqs(void)
> > >   unsigned long flags;
> > >   bool sync;
> > >  
> > > + if (irq_settings_is_nested_thread(desc))
> > > + continue;
> > >   raw_spin_lock_irqsave(>lock, flags);
> > >   sync = suspend_device_irq(desc, irq);
> > >   raw_spin_unlock_irqrestore(>lock, flags);
> > > @@ -158,6 +160,8 @@ static void resume_irqs(bool want_early)
> > >  
> > >   if (!is_early && want_early)
> > >   continue;
> > > + if (irq_settings_is_nested_thread(desc))
> > > + continue;
> > >  
> > >   raw_spin_lock_irqsave(>lock, flags);
> > >   resume_irq(desc, irq);
> > 
> > 
> 



pgp66nQtCl0Kc.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 2/5] x86, traps: Track entry into and exit from IST context

[Andy Lutomirski]

On Fri, Jan 30, 2015 at 5:28 PM, Sasha Levin  wrote:
> On 01/30/2015 02:57 PM, Sasha Levin wrote:
>> On 01/28/2015 04:02 PM, Andy Lutomirski wrote:
>>> On Wed, Jan 28, 2015 at 9:48 AM, Paul E. McKenney
>>>  wrote:
 On Wed, Jan 28, 2015 at 08:33:06AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 23, 2015 at 5:25 PM, Andy Lutomirski  
> wrote:
>> On Fri, Jan 23, 2015 at 12:48 PM, Sasha Levin  
>> wrote:
>>> On 01/23/2015 01:34 PM, Andy Lutomirski wrote:
 On Fri, Jan 23, 2015 at 10:04 AM, Borislav Petkov  
 wrote:
> On Fri, Jan 23, 2015 at 09:58:01AM -0800, Andy Lutomirski wrote:
>>> [  543.999079] Call Trace:
>>> [  543.999079] dump_stack (lib/dump_stack.c:52)
>>> [  543.999079] lockdep_rcu_suspicious 
>>> (kernel/locking/lockdep.c:4259)
>>> [  543.999079] atomic_notifier_call_chain 
>>> (include/linux/rcupdate.h:892 kernel/notifier.c:182 
>>> kernel/notifier.c:193)
>>> [  543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:192)
>>> [  543.999079] notify_die (kernel/notifier.c:538)
>>> [  543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:538)
>>> [  543.999079] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
>>> [  543.999079] do_debug (arch/x86/kernel/traps.c:652)
>>> [  543.999079] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609)
>>> [  543.999079] ? do_int3 (arch/x86/kernel/traps.c:610)
>>> [  543.999079] ? trace_hardirqs_on_caller 
>>> (kernel/locking/lockdep.c:2554 kernel/locking/lockdep.c:2601)
>>> [  543.999079] debug (arch/x86/kernel/entry_64.S:1310)
>>
>> I don't know how to read this stack trace.  Are we in do_int3,
>> do_debug, or both?  I didn't change do_debug at all.
>
> It looks like we're in do_debug. do_int3 is only on the stack but not
> part of the current frame if I can trust the '?' ...
>

 It's possible that an int3 happened and I did something wrong on
 return that caused a subsequent do_debug to screw up, but I don't see
 how my patch would have caused that.

 Were there any earlier log messages?
>>>
>>> Nope, nothing odd before or after.
>>
>> Trinity just survived for a decent amount of time for me with my
>> patches, other than a bunch of apparently expected OOM kills.  I have
>> no idea how to tell trinity how much memory to use.
>
> A longer trinity run on a larger VM survived (still with some OOM
> kills, but no taint) with these patches.  I suspect that it's a
> regression somewhere else in the RCU changes.  I have
> CONFIG_PROVE_RCU=y, so I should have seen the failure if it was there,
> I think.

 If by "RCU changes" you mean my changes to the RCU infrastructure, I am
 going to need more of a hint than I see in this thread thus far.  ;-)

>>>
>>> I can't help much, since I can't reproduce the problem.  Presumably if
>>> it's a bug in -tip, someone else will trigger it, too.
>>
>> I'm not sure what to tell you here, I'm not using any weird options for 
>> trinity
>> to reproduce it.
>>
>> It doesn't happen to frequently, but I still see it happening.
>>
>> Would you like me to try a debug patch or something similar?
>
> After talking with Paul we know what's going on here:
>
> do_debug() calls ist_enter() to indicate we're running on the interrupt
> stack. The first think ist_enter() does is:

I wonder whether there's an easy way to trigger this.  Probably a
watchpoint on the user stack would do the trick.

>
> preempt_count_add(HARDIRQ_OFFSET);
>
> After this, as far as the kernel is concerned, we're in interrupt mode
> so in_interrupt() will return true.
>
> Next, we'll call exception_enter() which won't do anything since:
>
> void context_tracking_user_exit(void)
> {
> unsigned long flags;
>
> if (!context_tracking_is_enabled())
> return;
>
> if (in_interrupt())  <=== This returns true, so nothing else 
> gets done
> return;
>
> At this stage we never tell RCU that we exited user mode, but then we
> try to use it calling the notifiers, which explains the warnings I'm seeing.
>

Is fixing this as simple as calling exception_enter before
incrementing the preempt count?  I'll try to have a tested patch
tomorrow.

Thanks for tracking this down!  I've been out of town since you
reported this, so I haven't had enough time to track it down myself.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ocfs2: remove goto statement in ocfs2_dx_dir_link_trailer()

[Daeseok Youn]

It is nothing to do in 'out' label, so just return 'ret'
variable.

Signed-off-by: Daeseok Youn 
---
 fs/ocfs2/dir.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index 319e786..e6e5de8 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -179,7 +179,7 @@ static int ocfs2_dx_dir_link_trailer(struct inode *dir, 
handle_t *handle,
  OCFS2_JOURNAL_ACCESS_WRITE);
if (ret) {
mlog_errno(ret);
-   goto out;
+   return ret;
}
trailer = ocfs2_trailer_from_bh(dirdata_bh, dir->i_sb);
dx_root = (struct ocfs2_dx_root_block *)dx_root_bh->b_data;
@@ -189,7 +189,6 @@ static int ocfs2_dx_dir_link_trailer(struct inode *dir, 
handle_t *handle,
 
ocfs2_journal_dirty(handle, dx_root_bh);
 
-out:
return ret;
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] staging: lustre: lustre: osc: modifying seq_printf statements

[Heba Aamer]

This patch modifies the seq_printf statements in
drivers/staging/lustre/lustre/osc/lproc_osc.c file.
It changes it to seq_puts and seq_putc wherever applicable.

Signed-off-by: Heba Aamer 
---
v2: changing %% to %

 drivers/staging/lustre/lustre/osc/lproc_osc.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/osc/lproc_osc.c 
b/drivers/staging/lustre/lustre/osc/lproc_osc.c
index 8e22e45..1795d3a 100644
--- a/drivers/staging/lustre/lustre/osc/lproc_osc.c
+++ b/drivers/staging/lustre/lustre/osc/lproc_osc.c
@@ -364,7 +364,7 @@ static int osc_checksum_type_seq_show(struct seq_file *m, 
void *v)
else
seq_printf(m, "%s ", cksum_name[i]);
}
-   seq_printf(m, "\n");
+   seq_putc(m, '\n');
return 0;
 }
 
@@ -601,9 +601,9 @@ static int osc_rpc_stats_seq_show(struct seq_file *seq, 
void *v)
seq_printf(seq, "pending read pages:   %d\n",
   atomic_read(>cl_pending_r_pages));
 
-   seq_printf(seq, "\n\t\t\tread\t\t\twrite\n");
-   seq_printf(seq, "pages per rpc   rpcs   %% cum %% |");
-   seq_printf(seq, "   rpcs   %% cum %%\n");
+   seq_puts(seq, "\n\t\t\tread\t\t\twrite\n");
+   seq_puts(seq, "pages per rpc rpcs   % cum % |");
+   seq_puts(seq, "   rpcs   % cum %\n");
 
read_tot = lprocfs_oh_sum(>cl_read_page_hist);
write_tot = lprocfs_oh_sum(>cl_write_page_hist);
@@ -624,9 +624,9 @@ static int osc_rpc_stats_seq_show(struct seq_file *seq, 
void *v)
break;
}
 
-   seq_printf(seq, "\n\t\t\tread\t\t\twrite\n");
-   seq_printf(seq, "rpcs in flight rpcs   %% cum %% |");
-   seq_printf(seq, "   rpcs   %% cum %%\n");
+   seq_puts(seq, "\n\t\t\tread\t\t\twrite\n");
+   seq_puts(seq, "rpcs in flight   rpcs   % cum % |");
+   seq_puts(seq, "   rpcs   % cum %\n");
 
read_tot = lprocfs_oh_sum(>cl_read_rpc_hist);
write_tot = lprocfs_oh_sum(>cl_write_rpc_hist);
@@ -647,9 +647,9 @@ static int osc_rpc_stats_seq_show(struct seq_file *seq, 
void *v)
break;
}
 
-   seq_printf(seq, "\n\t\t\tread\t\t\twrite\n");
-   seq_printf(seq, "offset rpcs   %% cum %% |");
-   seq_printf(seq, "   rpcs   %% cum %%\n");
+   seq_puts(seq, "\n\t\t\tread\t\t\twrite\n");
+   seq_puts(seq, "offset   rpcs   % cum % |");
+   seq_puts(seq, "   rpcs   % cum %\n");
 
read_tot = lprocfs_oh_sum(>cl_read_offset_hist);
write_tot = lprocfs_oh_sum(>cl_write_offset_hist);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners

[Davidlohr Bueso]

On Fri, 2015-01-30 at 17:51 -0800, Tim Chen wrote:
> On Fri, 2015-01-30 at 01:14 -0800, Davidlohr Bueso wrote:
> > When readers hold the semaphore, the ->owner is nil. As such,
> > and unlike mutexes, '!owner' does not necessarily imply that
> > the lock is free. This will cause writers to potentially spin
> > excessively as they've been mislead to thinking they have a
> > chance of acquiring the lock, instead of blocking.
> > 
> > This patch therefore enhances the counter check when the owner
> > is not set by the time we've broken out of the loop. Otherwise
> > we can return true as a new owner has the lock and thus we want
> > to continue spinning. While at it, we can make rwsem_spin_on_owner()
> > less ambiguos and return right away under need_resched conditions.
> > 
> > Signed-off-by: Davidlohr Bueso 
> > ---
> >  kernel/locking/rwsem-xadd.c | 21 +++--
> >  1 file changed, 15 insertions(+), 6 deletions(-)
> > 
> > diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> > index 07713e5..1c0d11e 100644
> > --- a/kernel/locking/rwsem-xadd.c
> > +++ b/kernel/locking/rwsem-xadd.c
> > @@ -337,21 +337,30 @@ static inline bool owner_running(struct rw_semaphore 
> > *sem,
> >  static noinline
> >  bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct 
> > *owner)
> >  {
> > +   long count;
> > +
> > rcu_read_lock();
> > while (owner_running(sem, owner)) {
> > -   if (need_resched())
> > -   break;
> > +   /* abort spinning when need_resched */
> > +   if (need_resched()) {
> > +   rcu_read_unlock();
> > +   return false;
> > +   }
> >  
> > cpu_relax_lowlatency();
> > }
> > rcu_read_unlock();
> >  
> > +   if (READ_ONCE(sem->owner))
> > +   return true; /* new owner, continue spinning */
> > +
> 
> Do you have some comparison data of whether it is more advantageous
> to continue spinning when owner changes?  After the above change, 
> rwsem will behave more like a spin lock for write lock and 
> will keep spinning when the lock changes ownership.

But recall we still abort when need_resched, so the spinning isn't
infinite. Never has been.

>  Now during heavy
> lock contention, if we don't continue spinning and sleep, we may use the
> clock cycles for actually running other threads. 

Under heavy contention, time spinning will force us to ultimately block
anyway.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drivers: net: xgene: fix: Out of order descriptor bytes read

[David Miller]

From: Iyappan Subramanian 
Date: Thu, 29 Jan 2015 14:38:23 -0800

> This patch fixes the following kernel crash,
 ...
> Software writes poison data into the descriptor bytes[15:8] and upon
> receiving the interrupt, if those bytes are overwritten by the hardware with
> the valid data, software also reads bytes[7:0] and executes receive/tx
> completion logic.
> 
> If the CPU executes the above two reads in out of order fashion, then the
> bytes[7:0] will have older data and causing the kernel panic.  We have to
> force the order of the reads and thus this patch introduces read memory
> barrier between these reads.
> 
> Signed-off-by: Iyappan Subramanian 
> Signed-off-by: Keyur Chudgar 

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] irda: use msecs_to_jiffies for conversions

[David Miller]

From: Nicholas Mc Guire 
Date: Thu, 29 Jan 2015 18:22:51 +0100

> This is only an API consolidation and should make things more readable
> it replaces  var * HZ / 1000  constructs by  msecs_to_jiffies(var).
> 
> Signed-off-by: Nicholas Mc Guire 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sparc: io_64.h: Replace io function-link macros

[David Miller]

From: Ricardo Ribalda Delgado 
Date: Thu, 29 Jan 2015 15:52:02 +0100

> Function like macros cannot be assigned to function pointers. This patch
> convert the function-like macros into object-macros, that the
> precompiler will replace with the name of the final function.
> 
> With this patch this kind of code will work:
> 
> if (priv->mode_big_endian)
>   priv.read = ioread32be;
> else
>   priv.read = ioread32;
> 
> Same approach has been taken on asm-generic/io.h
> 
> Reported-by: kbuild test robot 
> Fixes: 99082eab63449f9d spi/xilinx: Remove iowrite/ioread wrappers
> Signed-off-by: Ricardo Ribalda Delgado 

Acked-by: David S. Miller 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rhashtable: Make selftest modular

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 29 Jan 2015 15:40:25 +0100

> Allow the selftest on the resizable hash table to be built modular, just
> like all other tests that do not depend on DEBUG_KERNEL.
> 
> Signed-off-by: Geert Uytterhoeven 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] checkpatch: enhance check for seq_printf uses that could be seq_puts

[Heba Aamer]

This patch enhances the check for seq_printf uses that could
be seq_puts.

It was considering the escape of % is \%, but it is %%.
This led to skipping some valid cases related to that warning.  

Signed-off-by: Heba Aamer 
---
 scripts/checkpatch.pl |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f0bb6d6..0b125ca 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4804,11 +4804,14 @@ sub process {
 # check for seq_printf uses that could be seq_puts
if ($sline =~ /\bseq_printf\s*\(.*"\s*\)\s*;\s*$/) {
my $fmt = get_quoted_string($line, $rawline);
-   if ($fmt ne "" && $fmt !~ /[^\\]\%/) {
-   if (WARN("PREFER_SEQ_PUTS",
-"Prefer seq_puts to seq_printf\n" . 
$herecurr) &&
-   $fix) {
-   $fixed[$fixlinenr] =~ 
s/\bseq_printf\b/seq_puts/;
+   if ($fmt ne "") {
+   $fmt =~ s/%%//g;
+   if ($fmt !~ /%/) {
+   if (WARN("PREFER_SEQ_PUTS",
+"Prefer seq_puts to 
seq_printf\n" . $herecurr) &&
+   $fix) {
+   $fixed[$fixlinenr] =~ 
s/\bseq_printf\b/seq_puts/;
+   }
}
}
}
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH v2] procfs: Always expose /proc//map_files/ and make it readable

[Calvin Owens]

On Thursday 01/29 at 17:30 -0800, Kees Cook wrote:
> On Tue, Jan 27, 2015 at 8:38 PM, Calvin Owens  wrote:
> > On Monday 01/26 at 15:43 -0800, Andrew Morton wrote:
> >> On Tue, 27 Jan 2015 00:00:54 +0300 Cyrill Gorcunov  
> >> wrote:
> >>
> >> > On Mon, Jan 26, 2015 at 02:47:31PM +0200, Kirill A. Shutemov wrote:
> >> > > On Fri, Jan 23, 2015 at 07:15:44PM -0800, Calvin Owens wrote:
> >> > > > Currently, /proc//map_files/ is restricted to CAP_SYS_ADMIN, and
> >> > > > is only exposed if CONFIG_CHECKPOINT_RESTORE is set. This interface
> >> > > > is very useful for enumerating the files mapped into a process when
> >> > > > the more verbose information in /proc//maps is not needed.
> >>
> >> This is the main (actually only) justification for the patch, and it it
> >> far too thin.  What does "not needed" mean.  Why can't people just use
> >> /proc/pid/maps?
> >
> > The biggest difference is that if you do something like this:
> >
> > fd = open("/stuff", O_BLAH);
> > map = mmap(NULL, 4096, PROT_BLAH, MAP_SHARED, fd, 0);
> > close(fd);
> > unlink("/stuff");
> >
> > ...then map_files/ gives you a way to get a file descriptor for
> > "/stuff", which you couldn't do with /proc/pid/maps.
> >
> > It's also something of a win if you just want to see what is mapped at a
> > specific address, since you can just readlink() the symlink for the
> > address range you care about and it will go grab the appropriate VMA and
> > give you the answer. /proc/pid/maps requires walking the VMA tree, which
> > is quite expensive for processes with many thousands of threads, even
> > without the O(N^2) issue.
> >
> > (You have to know what address range you want though, since readdir() on
> > map_files/ obviously has to walk the VMA tree just like /proc/N/maps.)
> >
> >> > > > This patch moves the folder out from behind CHECKPOINT_RESTORE, and
> >> > > > removes the CAP_SYS_ADMIN restrictions. Following the links requires
> >> > > > the ability to ptrace the process in question, so this doesn't allow
> >> > > > an attacker to do anything they couldn't already do before.
> >> > > >
> >> > > > Signed-off-by: Calvin Owens 
> >> > >
> >> > > Cc +linux-api@
> >> >
> >> > Looks good to me, thanks! Though I would really appreciate if someone
> >> > from security camp take a look as well.
> >>
> >> hm, who's that.  Kees comes to mind.
> >>
> >> And reviewers' task would be a heck of a lot easier if they knew what
> >> /proc/pid/map_files actually does.  This:
> >>
> >> akpm3:/usr/src/25> grep -r map_files Documentation
> >> akpm3:/usr/src/25>
> >>
> >> does not help.
> >>
> >> The 640708a2cff7f81 changelog says:
> >>
> >> : This one behaves similarly to the /proc//fd/ one - it contains
> >> : symlinks one for each mapping with file, the name of a symlink is
> >> : "vma->vm_start-vma->vm_end", the target is the file.  Opening a 
> >> symlink
> >> : results in a file that point exactly to the same inode as them vma's 
> >> one.
> >> :
> >> : For example the ls -l of some arbitrary /proc//map_files/
> >> :
> >> :  | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80403000-7f8f80404000 
> >> -> /lib64/libc-2.5.so
> >> :  | lr-x-- 1 root root 64 Aug 26 06:40 7f8f8061e000-7f8f8062 
> >> -> /lib64/libselinux.so.1
> >> :  | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80826000-7f8f80827000 
> >> -> /lib64/libacl.so.1.1.0
> >> :  | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a2f000-7f8f80a3 
> >> -> /lib64/librt-2.5.so
> >> :  | lr-x-- 1 root root 64 Aug 26 06:40 7f8f80a3-7f8f80a4c000 
> >> -> /lib64/ld-2.5.so
> >>
> >> afacit this info is also available in /proc/pid/maps, so things
> >> shouldn't get worse if the /proc/pid/map_files permissions are at least
> >> as restrictive as the /proc/pid/maps permissions.  Is that the case?
> >> (Please add to changelog).
> >
> > Yes, the only difference is that you can follow the link as per above.
> > I'll resend with a new message explaining that and the deletion thing.
> >
> >> There's one other problem here: we're assuming that the map_files
> >> implementation doesn't have bugs.  If it does have bugs then relaxing
> >> permissions like this will create new vulnerabilities.  And the
> >> map_files implementation is surprisingly complex.  Is it bug-free?
> >
> > While I was messing with it I used it a good bit and didn't see any
> > issues, although I didn't actively try to fuzz it or anything. I'd be
> > happy to write something to test hammering it in weird ways if you like.
> > I'm also happy to write testcases for namespaces.
> >
> > So far as security issues, as others have pointed out you can't follow
> > the links unless you can ptrace the process in question, which seems
> > like a pretty solid guarantee. As Cyrill pointed out in the discussion
> > about the documentation, that's the same protection as /proc/N/fd/*, and
> > those links function in the same way.
> 
> My concern here is that fd/* are connected as 

Re: [PATCH 1/5] irqchip: gicv3-its: allocate proper size for DT

[Yun Wu (Abel)]

On 2015/1/31 3:10, Marc Zyngier wrote:

> On 30/01/15 07:46, Yun Wu wrote:
>> A hardware implementation may be designed to search the device
>> table (DT) using a direct mapping between device ID and memory
>> address, and in this scenario a single page, currently allocated
>> for DT in ITS driver, will be probably not enough.
>>
>> This patch will try best to get this addressed by enlarging DT
>> size with a limitation of MAX_ORDER pages.
>>
>> Signed-off-by: Yun Wu 
> 
> A similar patch has been posted already (and is already in my queue):
> 
> https://git.kernel.org/cgit/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gic-fixes=4be3de2af2a58476f84d678f3e8a3596f23f80d5
> 

Oh, now I see it. How about allocating a order of MAX_ORDER pages and
throwing out a warning if the number of device id bits exceeds maximum
order kernel supports, instead of letting the ITS fail in probing.

Thanks,
Abel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] locking/rwsem: Avoid deceiving lock spinners

[Tim Chen]

On Fri, 2015-01-30 at 01:14 -0800, Davidlohr Bueso wrote:
> When readers hold the semaphore, the ->owner is nil. As such,
> and unlike mutexes, '!owner' does not necessarily imply that
> the lock is free. This will cause writers to potentially spin
> excessively as they've been mislead to thinking they have a
> chance of acquiring the lock, instead of blocking.
> 
> This patch therefore enhances the counter check when the owner
> is not set by the time we've broken out of the loop. Otherwise
> we can return true as a new owner has the lock and thus we want
> to continue spinning. While at it, we can make rwsem_spin_on_owner()
> less ambiguos and return right away under need_resched conditions.
> 
> Signed-off-by: Davidlohr Bueso 
> ---
>  kernel/locking/rwsem-xadd.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 07713e5..1c0d11e 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -337,21 +337,30 @@ static inline bool owner_running(struct rw_semaphore 
> *sem,
>  static noinline
>  bool rwsem_spin_on_owner(struct rw_semaphore *sem, struct task_struct *owner)
>  {
> + long count;
> +
>   rcu_read_lock();
>   while (owner_running(sem, owner)) {
> - if (need_resched())
> - break;
> + /* abort spinning when need_resched */
> + if (need_resched()) {
> + rcu_read_unlock();
> + return false;
> + }
>  
>   cpu_relax_lowlatency();
>   }
>   rcu_read_unlock();
>  
> + if (READ_ONCE(sem->owner))
> + return true; /* new owner, continue spinning */
> +

Do you have some comparison data of whether it is more advantageous
to continue spinning when owner changes?  After the above change, 
rwsem will behave more like a spin lock for write lock and 
will keep spinning when the lock changes ownership. Now during heavy
lock contention, if we don't continue spinning and sleep, we may use the
clock cycles for actually running other threads.  This was the
assumption in the older code.  The trade
off may or may not be worth it depending on how big the thread
switching overhead is and how long the lock is held.  

It will be good to have a few data points to make sure
that this change is beneficial.

>   /*
> -  * We break out the loop above on need_resched() or when the
> -  * owner changed, which is a sign for heavy contention. Return
> -  * success only when sem->owner is NULL.
> +  * When the owner is not set, the lock could be free or
> +  * held by readers. Check the counter to verify the
> +  * state.
>*/
> - return sem->owner == NULL;
> + count = READ_ONCE(sem->count);
> + return (count == 0 || count == RWSEM_WAITING_BIAS);
>  }
>  
>  static bool rwsem_optimistic_spin(struct rw_semaphore *sem)

Thanks.

Tim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] localedef.1: tfix

[Masanari Iida]

Signed-off-by: Masanari Iida 
---
 man1/localedef.1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man1/localedef.1 b/man1/localedef.1
index a7549d1..bb1e158 100644
--- a/man1/localedef.1
+++ b/man1/localedef.1
@@ -80,7 +80,7 @@ argument is interpreted as follows:
 If
 .I outputpath
 contains a slash character ('/'), it is interpreted as the name of the
-directory where the output defintions are to be stored.
+directory where the output definitions are to be stored.
 In this case, there is a separate output file for each locale category
 .RI ( LC_CTIME ,
 .IR LC_NUMERIC ,
-- 
2.3.0.rc1.30.g76afe74

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] irqchip: gicv3-its: add support for power down

[Yun Wu (Abel)]

On 2015/1/31 3:23, Marc Zyngier wrote:

> On 30/01/15 07:46, Yun Wu wrote:
>> Configurations of an ITS cannot be changed if the ITS is in an
>> active status, so it might not be safe to perform a soft reboot
>> with all the active ITSes un-disabled, etc. kexec.
>>
>> This patch will make sure all the active ITSes disabled before
>> enabling them again without resetting ITS hardware.
> 
> And what happens if the kernel crashes or gets rebooted from a watchdog?
> Or if the bootloader messes things up? The ITS is in an unknown state
> when we start again.
> 
> Wouldn't it be better to address this instead? Enforcing an safe initial
> state seems a better solution that relying on mechanisms that may not be
> relevant for all cases.
> 

Sure, checking the ITS state before initializing it is really a better
solution, I will rewrite this patch and test again.

Thanks,
Abel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] irqchip: gicv3-its: use 64KB page as default granule

[Yun Wu (Abel)]

On 2015/1/31 3:18, Marc Zyngier wrote:

> On 30/01/15 07:46, Yun Wu wrote:
>> The field of page size in register GITS_BASERn might be read-only
>> if an implementation only supports a single, fixed page size. But
>> currently the ITS driver will throw out an error when PAGE_SIZE
>> is less than the minimum size supported by an ITS. So addressing
>> this problem by using 64KB pages as default granule for all the
>> ITS base tables.
> 
> Do you actually know of an implementation with such a behaviour?

Yes, Hisilicon implemented a fixed page size of 16KB.

> 
>> Signed-off-by: Yun Wu 
>> ---
>>  drivers/irqchip/irq-gic-v3-its.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c 
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 2a08d85..430bc92 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -801,7 +801,7 @@ static int its_alloc_tables(struct its_node *its)
>>  int err;
>>  int i;
>>  int size;
>> -int psz = PAGE_SIZE;
>> +int psz = SZ_64K;
>>  u64 shr = GITS_BASER_InnerShareable;
>>
>>  for (i = 0; i < GITS_BASER_NR_REGS; i++) {
> 
> Assuming such an implementation exists, you'll have to rebase this on
> top of the patch I mentioned in my reply to patch #1.
> 

OK, I will.

Thanks,
Abel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] char/misc driver fixes for 3.19-rc7

[Greg KH]

The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:

  Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-3.19-rc7

for you to fetch changes up to 26713c81231363c07cbd0f7392a8c94d7ba8e61c:

  drivers/Kconfig: remove duplicate entry for soc (2015-01-25 20:26:42 +0800)


Char/misc driver fixes for 3.19-rc7

Here are two tiny patches, one fixing up the drivers/Kconfig file, and
one adding a MAINTAINERS entry for the UIO git tree.

Signed-off-by: Greg Kroah-Hartman 


Lars Poeschel (1):
  drivers/Kconfig: remove duplicate entry for soc

Mandeep Sandhu (1):
  MAINTAINERS: add git url entry for UIO

 MAINTAINERS | 1 +
 drivers/Kconfig | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v13 4/6] clk: Add rate constraints to clocks

[Stephen Boyd]

On 01/29, Stephen Boyd wrote:
> On 01/29/15 05:31, Geert Uytterhoeven wrote:
> > Hi Tomeu, Mike,
> >
> > On Fri, Jan 23, 2015 at 12:03 PM, Tomeu Vizoso
> >  wrote:
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -2391,25 +2543,24 @@ int __clk_get(struct clk *clk)
> >> return 1;
> >>  }
> >>
> >> -static void clk_core_put(struct clk_core *core)
> >> +void __clk_put(struct clk *clk)
> >>  {
> >> struct module *owner;
> >>
> >> -   owner = core->owner;
> >> +   if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
> >> +   return;
> >>
> >> clk_prepare_lock();
> >> -   kref_put(>ref, __clk_release);
> >> +
> >> +   hlist_del(>child_node);
> >> +   clk_core_set_rate_nolock(clk->core, clk->core->req_rate);
> > At this point, clk->core->req_rate is still zero, causing
> > cpg_div6_clock_round_rate() to be called with a zero "rate" parameter,
> > e.g. on r8a7791:
> 
> Hmm.. I wonder if we should assign core->req_rate to be the same as
> core->rate during __clk_init()? That would make this call to
> clk_core_set_rate_nolock() a nop in this case.
> 

Here's a patch to do this

---8<
From: Stephen Boyd 
Subject: [PATCH] clk: Assign a requested rate by default

We need to assign a requested rate here so that we avoid
requesting a rate of 0 on clocks when we remove clock consumers.

Signed-off-by: Stephen Boyd 
---
 drivers/clk/clk.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a29daf9edea4..8416ed1c40be 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2142,6 +2142,7 @@ int __clk_init(struct device *dev, struct clk *clk_user)
struct clk_core *orphan;
struct hlist_node *tmp2;
struct clk_core *clk;
+   unsigned long rate;
 
if (!clk_user)
return -EINVAL;
@@ -2266,12 +2267,13 @@ int __clk_init(struct device *dev, struct clk *clk_user)
 * then rate is set to zero.
 */
if (clk->ops->recalc_rate)
-   clk->rate = clk->ops->recalc_rate(clk->hw,
+   rate = clk->ops->recalc_rate(clk->hw,
clk_core_get_rate_nolock(clk->parent));
else if (clk->parent)
-   clk->rate = clk->parent->rate;
+   rate = clk->parent->rate;
else
-   clk->rate = 0;
+   rate = 0;
+   clk->rate = clk->req_rate = rate;
 
/*
 * walk the list of orphan clocks and reparent any that are children of
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] USB driver fixes for 3.19-rc7

[Greg KH]

The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:

  Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.19-rc7

for you to fetch changes up to 54eb4cd465423280c0e8a7150176667c92939ec4:

  Merge tag 'fixes-for-v3.19-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus 
(2015-01-26 19:13:41 -0800)


USB fixes for 3.19-rc7

Here are some small USB fixes and quirk additions for 3.19-rc7.

All have been in linux-next for a while with no reported problems.

Signed-off-by: Greg Kroah-Hartman 


Dmitry Nezhevenko (1):
  usb-storage/SCSI: blacklist FUA on JMicron 152d:2566 USB-SATA controller

Greg Kroah-Hartman (1):
  Merge tag 'fixes-for-v3.19-rc6' of git://git.kernel.org/.../balbi/usb 
into usb-linus

Hans de Goede (1):
  uas: Add no-report-opcodes quirk for Simpletech devices with id 4971:8017

Heikki Krogerus (1):
  usb: phy: never defer probe in non-OF case

Macpaul Lin (1):
  USB: Add OTG PET device to TPL

Mark Knibbs (1):
  storage: Revise/fix quirk for 04E6:000F SCM USB-SCSI converter

Robert Baldyga (1):
  usb: dwc2: call dwc2_is_controller_alive() under spinlock

 drivers/usb/core/otg_whitelist.h   | 5 +
 drivers/usb/core/quirks.c  | 4 
 drivers/usb/dwc2/core_intr.c   | 6 +++---
 drivers/usb/phy/phy.c  | 2 +-
 drivers/usb/storage/unusual_devs.h | 9 -
 drivers/usb/storage/unusual_uas.h  | 7 +++
 6 files changed, 28 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Staging driver fixes for 3.19-rc7

[Greg KH]

The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc:

  Linux 3.19-rc5 (2015-01-18 18:02:20 +1200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.19-rc7

for you to fetch changes up to 41c9e95d641acc096975e70239742929b5971afa:

  MAINTAINERS: add Android driver entries (2015-01-25 20:21:54 +0800)


Staging tree fixes for 3.19-rc7

Here are two tiny staging tree fixes.  One for the nvec driver to
resolve a reported problem, and one to add a MAINTAINERS entry for the
Android drivers.

Signed-off-by: Greg Kroah-Hartman 


Greg KH (1):
  MAINTAINERS: add Android driver entries

Marc Dietrich (1):
  staging: nvec: specify a platform-device base id

 MAINTAINERS | 10 ++
 drivers/staging/nvec/nvec.c |  9 +++--
 2 files changed, 13 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/5] x86, traps: Track entry into and exit from IST context

[Sasha Levin]

On 01/30/2015 02:57 PM, Sasha Levin wrote:
> On 01/28/2015 04:02 PM, Andy Lutomirski wrote:
>> On Wed, Jan 28, 2015 at 9:48 AM, Paul E. McKenney
>>  wrote:
>>> On Wed, Jan 28, 2015 at 08:33:06AM -0800, Andy Lutomirski wrote:
 On Fri, Jan 23, 2015 at 5:25 PM, Andy Lutomirski  
 wrote:
> On Fri, Jan 23, 2015 at 12:48 PM, Sasha Levin  
> wrote:
>> On 01/23/2015 01:34 PM, Andy Lutomirski wrote:
>>> On Fri, Jan 23, 2015 at 10:04 AM, Borislav Petkov  
>>> wrote:
 On Fri, Jan 23, 2015 at 09:58:01AM -0800, Andy Lutomirski wrote:
>> [  543.999079] Call Trace:
>> [  543.999079] dump_stack (lib/dump_stack.c:52)
>> [  543.999079] lockdep_rcu_suspicious (kernel/locking/lockdep.c:4259)
>> [  543.999079] atomic_notifier_call_chain 
>> (include/linux/rcupdate.h:892 kernel/notifier.c:182 
>> kernel/notifier.c:193)
>> [  543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:192)
>> [  543.999079] notify_die (kernel/notifier.c:538)
>> [  543.999079] ? atomic_notifier_call_chain (kernel/notifier.c:538)
>> [  543.999079] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
>> [  543.999079] do_debug (arch/x86/kernel/traps.c:652)
>> [  543.999079] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609)
>> [  543.999079] ? do_int3 (arch/x86/kernel/traps.c:610)
>> [  543.999079] ? trace_hardirqs_on_caller 
>> (kernel/locking/lockdep.c:2554 kernel/locking/lockdep.c:2601)
>> [  543.999079] debug (arch/x86/kernel/entry_64.S:1310)
>
> I don't know how to read this stack trace.  Are we in do_int3,
> do_debug, or both?  I didn't change do_debug at all.

 It looks like we're in do_debug. do_int3 is only on the stack but not
 part of the current frame if I can trust the '?' ...

>>>
>>> It's possible that an int3 happened and I did something wrong on
>>> return that caused a subsequent do_debug to screw up, but I don't see
>>> how my patch would have caused that.
>>>
>>> Were there any earlier log messages?
>>
>> Nope, nothing odd before or after.
>
> Trinity just survived for a decent amount of time for me with my
> patches, other than a bunch of apparently expected OOM kills.  I have
> no idea how to tell trinity how much memory to use.

 A longer trinity run on a larger VM survived (still with some OOM
 kills, but no taint) with these patches.  I suspect that it's a
 regression somewhere else in the RCU changes.  I have
 CONFIG_PROVE_RCU=y, so I should have seen the failure if it was there,
 I think.
>>>
>>> If by "RCU changes" you mean my changes to the RCU infrastructure, I am
>>> going to need more of a hint than I see in this thread thus far.  ;-)
>>>
>>
>> I can't help much, since I can't reproduce the problem.  Presumably if
>> it's a bug in -tip, someone else will trigger it, too.
> 
> I'm not sure what to tell you here, I'm not using any weird options for 
> trinity
> to reproduce it.
> 
> It doesn't happen to frequently, but I still see it happening.
> 
> Would you like me to try a debug patch or something similar?

After talking with Paul we know what's going on here:

do_debug() calls ist_enter() to indicate we're running on the interrupt
stack. The first think ist_enter() does is:

preempt_count_add(HARDIRQ_OFFSET);

After this, as far as the kernel is concerned, we're in interrupt mode
so in_interrupt() will return true.

Next, we'll call exception_enter() which won't do anything since:

void context_tracking_user_exit(void)
{
unsigned long flags;

if (!context_tracking_is_enabled())
return;

if (in_interrupt())  <=== This returns true, so nothing else 
gets done
return;

At this stage we never tell RCU that we exited user mode, but then we
try to use it calling the notifiers, which explains the warnings I'm seeing.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clk: remove clk-private.h

[Mike Turquette]

Quoting Stephen Boyd (2015-01-30 15:48:46)
> On 01/30/15 13:25, Michael Turquette wrote:
> > Private clock framework data structures should be private, surprisingly.
> >
> > Now that all platforms and drivers have been updated to remove static
> > initializations of struct clk and struct clk_core objects and all
> > references to clk-private.h have been removed we can move the
> > definitions of these structures into drivers/clk/clk.c and delete the
> > header.
> >
> > Additionally the ugly DEFINE_CLK macros have been removed. Those were
> > used for static definitions of struct clk objects. That practice is no
> > longer allowed.
> >
> > Signed-off-by: Michael Turquette 
> 
> This is great!
> 
> Reviewed-by: Stephen Boyd 
> 
> given the minor comment below.
> 
> > - * Returns 0 on success, otherwise an error code.
> > - */
> > -int __clk_init(struct device *dev, struct clk *clk);
> 
> Shouldn't __clk_init become static now in clk.c?

Good catch!

Regards,
Mike

> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[Stephen Boyd]

Kept meaning to get back to this thread. Have you resolved it?

On 10/29/14 03:38, Marcin Jabrzyk wrote:
> So I've tried this patch, it resolves one problem but introduces also
> new ones. As expected the BUG warning is not showing after applying
> this patch but there are some interesting side effects.

Well that's half good news.

> I was looking on /proc/interrupts output. IRQ for CPU0 have "MCT" name
> and IRQ for CPU1 has unexpectedly no name at all.

This is pretty confusing. I don't see how the patch could cause this to
happen.

> After making hotplug cycle of CPU1 I've observed that IRQs attached
> originally for that CPU are generating on really low count and not in
> order with IRQ for CPU0.
> What's more the interrupt for CPU1 is showing to me as being counted
> for both CPUs, so it's probably not being attached to CPU1.
>

yeah. Can you give the output of /proc/timer_list in addition to
/proc/interrupts? It may give some hints on what's going on. It may also
be interesting to see if irq_force_affinity() is failing. Please check
the return value and print an error


diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 1800053b4644..3c4538e26731 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 {
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+   int ret;
 
mevt = container_of(evt, struct mct_clock_event_device, evt);
 
@@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
enable_irq(evt->irq);
-   irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+   ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], 
cpumask_of(cpu));
+   if (ret)
+   pr_err("force failed %d\n", ret);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Clock Regression in next-20150130 caused by cb75a8fcd14e

[Tony Lindgren]

Hi all,

Looks like commit cb75a8fcd14e ("clk: Add rate constraints to clocks")
causes a regression on at least omaps where the serial console either
does not show anything, or just prints garbage.

Reverting cb75a8fcd14e makes things work again on next-20150130.

Any ideas?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 00/30] Refine PCI scan interfaces and make generic pci host bridge

[Yijing Wang]

On 2015/1/30 23:45, Bjorn Helgaas wrote:
> On Fri, Jan 30, 2015 at 3:10 AM, Yijing Wang  wrote:
>> Hi Bjorn,
>>Any comments for this series ?  I'm so sorry to bother you.  :)
> 
> It's next in my queue after Wei Yang's powerpc sriov series.  Here's
> the queue I work from:
> https://patchwork.ozlabs.org/project/linux-pci/list/?order=date

OK, thanks.

> 
> Bjorn
> 
>> On 2015/1/21 8:29, Yijing Wang wrote:
>>> v1->v2:
>>>   Split pci_host_bridge_list into a new patch, remove .phb_probe_mode
>>>   and rework powerpc .phb_of_scan_bus() for simpilicty suggested by
>>>   Arnd. Refresh some patch description log, and add a new patch to fix
>>>   build warning in ia64.
>>>
>>> This series is based on Bjorn's pci-next branch.
>>>
>>> Patch 1-4 ripped out pci_bus_add_devices() from pci scan interfaces
>>> for better pci scan flow.
>>>
>>> Patch 5-11 make a generic pci_host_bridge to hold pci_host_bridge
>>> related informations, and introduce a pci_host_bridge_ops to
>>> support platform host drivers provide its own pci_host_bridge
>>> related operations to setup pci_host_bridge during pci enumeration.
>>>
>>> Patch 12-28 apply the new pci scan interfaces to platform pci host
>>> bridge drivers.
>>>
>>> Now in kernel, we scan pci bus use the following ways:
>>> 1. pci_scan_bus.
>>>   parent = NULL, default io/mem/bus resources
>>>   call pci_bus_add_devices()
>>>
>>> 2. pci_scan_bus_parented() + pci_bus_add_devices()
>>>   default io/mem/bus resources, only used by xen
>>>
>>> 3. pci_scan_root_bus() + pci_bus_add_devices()
>>>
>>> 4. pci_create_root_bus() + pci_scan_child_bus() + pci_bus_add_devices()
>>>
>>> 5. pci_create_root_bus() + xx_of_scan_bus()  +  pci_bus_add_devices()
>>>
>>> And we have a lot of arch specific pci_domain_nr() and other platform
>>> specific weak function like pcibios_root_bridge_prepare().
>>>
>>> After applied this series, we have following scan interfaces:
>>>
>>> 1. pci_scan_bus_legacy()
>>>   parent = NULL, default io/mem/bus resources.
>>>   for legacy pci scan
>>>
>>> 2. pci_scan_root_bus()
>>>   for callers provide its own parent and io/mem/bus resources
>>>   but no platform specific pci_host_bridge operations
>>>
>>> 3. pci_scan_root_bridge()
>>>   for callers provide its own parent and io/mem/bus resources
>>>   and pci_host_bridge_ops.
>>>
>>> Besides, above pci scan interfaces all need addtionally call 
>>> pci_bus_add_devices()
>>> to set match_driver true and try to attach drivers.
>>>
>>> Also we could eliminate all arch specific pci_domain_nr() after applied 
>>> this series.
>>>
>>> I tested this series on x86 (with or without ACPI).
>>> Comments and tests are warmly welcome!
>>>
>>> Arnd Bergmann (1):
>>>   xen/PCI: Don't use deprecated function pci_scan_bus_parented()
>>>
>>> Yijing Wang (29):
>>>   PCI: Rip out pci_bus_add_devices() from pci_scan_bus()
>>>   PCI: Rip out pci_bus_add_devices() from pci_scan_root_bus()
>>>   PCI: Remove deprecated pci_scan_bus_parented()
>>>   PCI: Rename pci_scan_bus() to pci_scan_bus_legacy()
>>>   PCI: Combine PCI domain and bus number in u32 arg
>>>   PCI: Pass PCI domain number combined with root bus number
>>>   PCI: Introduce pci_host_assign_domain_nr() to assign domain
>>>   PCI: Separate pci_host_bridge creation out of pci_create_root_bus()
>>>   PCI: Introduce pci_host_bridge_list to manage host bridges
>>>   PCI: Save sysdata in pci_host_bridge drvdata
>>>   PCI: Introduce pci_host_bridge_ops to support host specific
>>> operations
>>>   PCI: Introduce new scan function pci_scan_root_bridge()
>>>   PCI/x86: Refine pci_acpi_scan_root() with generic pci_host_bridge
>>>   PCI/IA64: Refine pci_acpi_scan_root() with generic pci_host_bridge
>>>   PCI/IA64: Fix the build warning about pci_domain_nr()
>>>   PCI/powerpc: Rename pcibios_root_bridge_prepare()
>>>   PCI/powerpc: Use pci_scan_root_bridge() for simplicity
>>>   PCI: Remove weak pcibios_root_bridge_prepare()
>>>   PCI/sparc: Use pci_scan_root_bridge() for simplicity
>>>   PCI: Introduce pci_bus_child_max_busnr()
>>>   PCI/Parisc: Use pci_scan_root_bus() for simplicity
>>>   PCI/mvebu: Use pci_common_init_dev() to simplify code
>>>   PCI/tegra: Remove redundant tegra_pcie_scan_bus()
>>>   PCI/designware: Use pci_scan_root_bus() for simplicity
>>>   PCI/xgene: Use pci_scan_root_bus() instead of pci_create_root_bus()
>>>   PCI: Rename __pci_create_root_bus() to pci_create_root_bus()
>>>   PCI: Export find_pci_host_bridge()
>>>   PCI: Remove platform specific pci_domain_nr()
>>>   PCI: Remove pci_bus_assign_domain_nr()
>>>
>>>  arch/alpha/include/asm/pci.h |2 -
>>>  arch/alpha/kernel/pci.c  |7 +-
>>>  arch/alpha/kernel/sys_nautilus.c |4 +-
>>>  arch/frv/mb93090-mb00/pci-vdk.c  |6 +-
>>>  arch/ia64/include/asm/pci.h  |1 -
>>>  arch/ia64/pci/pci.c  |   34 +++---
>>>  arch/ia64/sn/kernel/io_acpi_init.c   |6 +-
>>>  

[PATCH] staging/lustre: remove unused lustre_update.h header

[green]

From: Oleg Drokin 

lustre_update.h containts various server-side structures that are
not really relevant for the client.
Also remove the only user of this file that does not actually need it.

Signed-off-by: Oleg Drokin 
---
 .../staging/lustre/lustre/include/lustre_update.h  | 189 -
 drivers/staging/lustre/lustre/ptlrpc/layout.c  |   1 -
 2 files changed, 190 deletions(-)
 delete mode 100644 drivers/staging/lustre/lustre/include/lustre_update.h

diff --git a/drivers/staging/lustre/lustre/include/lustre_update.h 
b/drivers/staging/lustre/lustre/include/lustre_update.h
deleted file mode 100644
index 84defce..000
--- a/drivers/staging/lustre/lustre/include/lustre_update.h
+++ /dev/null
@@ -1,189 +0,0 @@
-/*
- * GPL HEADER START
- *
- * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 only,
- * as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License version 2 for more details (a copy is included
- * in the LICENSE file that accompanied this code).
- *
- * You should have received a copy of the GNU General Public License
- * version 2 along with this program; If not, see
- * http://www.gnu.org/licenses/gpl-2.0.htm
- *
- * GPL HEADER END
- */
-/*
- * Copyright (c) 2013, Intel Corporation.
- */
-/*
- * lustre/include/lustre_update.h
- *
- * Author: Di Wang 
- */
-
-#ifndef _LUSTRE_UPDATE_H
-#define _LUSTRE_UPDATE_H
-
-#define UPDATE_BUFFER_SIZE 8192
-struct update_request {
-   struct dt_device*ur_dt;
-   struct list_headur_list;/* attached itself to 
thandle */
-   int ur_flags;
-   int ur_rc;  /* request result */
-   int ur_batchid; /* Current batch(trans) id */
-   struct update_buf   *ur_buf;   /* Holding the update req */
-};
-
-static inline unsigned long update_size(struct update *update)
-{
-   unsigned long size;
-   inti;
-
-   size = cfs_size_round(offsetof(struct update, u_bufs[0]));
-   for (i = 0; i < UPDATE_BUF_COUNT; i++)
-   size += cfs_size_round(update->u_lens[i]);
-
-   return size;
-}
-
-static inline void *update_param_buf(struct update *update, int index,
-int *size)
-{
-   int i;
-   void*ptr;
-
-   if (index >= UPDATE_BUF_COUNT)
-   return NULL;
-
-   ptr = (char *)update + cfs_size_round(offsetof(struct update,
-  u_bufs[0]));
-   for (i = 0; i < index; i++) {
-   LASSERT(update->u_lens[i] > 0);
-   ptr += cfs_size_round(update->u_lens[i]);
-   }
-
-   if (size != NULL)
-   *size = update->u_lens[index];
-
-   return ptr;
-}
-
-static inline unsigned long update_buf_size(struct update_buf *buf)
-{
-   unsigned long size;
-   inti = 0;
-
-   size = cfs_size_round(offsetof(struct update_buf, ub_bufs[0]));
-   for (i = 0; i < buf->ub_count; i++) {
-   struct update *update;
-
-   update = (struct update *)((char *)buf + size);
-   size += update_size(update);
-   }
-   LASSERT(size <= UPDATE_BUFFER_SIZE);
-   return size;
-}
-
-static inline void *update_buf_get(struct update_buf *buf, int index, int 
*size)
-{
-   int count = buf->ub_count;
-   void*ptr;
-   int i = 0;
-
-   if (index >= count)
-   return NULL;
-
-   ptr = (char *)buf + cfs_size_round(offsetof(struct update_buf,
-   ub_bufs[0]));
-   for (i = 0; i < index; i++)
-   ptr += update_size((struct update *)ptr);
-
-   if (size != NULL)
-   *size = update_size((struct update *)ptr);
-
-   return ptr;
-}
-
-static inline void update_init_reply_buf(struct update_reply *reply, int count)
-{
-   reply->ur_version = UPDATE_REPLY_V1;
-   reply->ur_count = count;
-}
-
-static inline void *update_get_buf_internal(struct update_reply *reply,
-   int index, int *size)
-{
-   char *ptr;
-   int count = reply->ur_count;
-   int i;
-
-   if (index >= count)
-   return NULL;
-
-   ptr = (char *)reply + cfs_size_round(offsetof(struct update_reply,
-ur_lens[count]));
-   for (i = 0; i < index; i++) {
-   LASSERT(reply->ur_lens[i] > 0);
-   ptr += cfs_size_round(reply->ur_lens[i]);
-   }
-
-   if (size != NULL)
-   *size = 

[PATCH V2 1/2] spmi: remove wakeup command before slave probe

[Gilad Avidov]

According to spmi spec a slave powers up into startup state and then
transitions into active state. Thus, the wakeup command is not required
before calling the slave's probe. The wakeup command is only needed for
slaves that are in sleep state after receiving the sleep command.

This is a bug since spmi master controllers, such as spmi-pmic-arb,
which have no support for wakeup command return an error on that
command and thus fail before reaching a slave driver probe.

Cc: ga...@codeaurora.org
Acked-by: Sagar Dharia 
Signed-off-by: Gilad Avidov 
---
 drivers/spmi/spmi.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
index 1d92f51..9ff7454 100644
--- a/drivers/spmi/spmi.c
+++ b/drivers/spmi/spmi.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -316,11 +316,6 @@ static int spmi_drv_probe(struct device *dev)
struct spmi_device *sdev = to_spmi_device(dev);
int err;
 
-   /* Ensure the slave is in ACTIVE state */
-   err = spmi_command_wakeup(sdev);
-   if (err)
-   goto fail_wakeup;
-
pm_runtime_get_noresume(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
@@ -335,7 +330,6 @@ fail_probe:
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
pm_runtime_put_noidle(dev);
-fail_wakeup:
return err;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 2/2] spmi: pmic_arb: add support for hw version 2

[Gilad Avidov]

Qualcomm PMIC Arbiter version-2 changes from version-1 are:

- Some different register offsets.
- New channel register space, one per PMIC peripheral (ppid).
  All tx traffic uses these channels.
- New observer register space. All rx trafic uses this space.
- Different command format for spmi command registers.

Signed-off-by: Gilad Avidov 
Acked-by: Sagar Dharia 
---
 .../bindings/spmi/qcom,spmi-pmic-arb.txt   |   6 +-
 drivers/spmi/spmi-pmic-arb.c   | 310 +
 2 files changed, 260 insertions(+), 56 deletions(-)

diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt 
b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
index 715d099..e16b9b5 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -1,6 +1,6 @@
 Qualcomm SPMI Controller (PMIC Arbiter)
 
-The SPMI PMIC Arbiter is found on the Snapdragon 800 Series.  It is an SPMI
+The SPMI PMIC Arbiter is found on Snapdragon chipsets.  It is an SPMI
 controller with wrapping arbitration logic to allow for multiple on-chip
 devices to control a single SPMI master.
 
@@ -19,6 +19,10 @@ Required properties:
  "core" - core registers
  "intr" - interrupt controller registers
  "cnfg" - configuration registers
+   Registers used only for V2 PMIC Arbiter:
+ "chnls"  - tx-channel per virtual slave registers.
+ "obsrvr" - rx-channel (called observer) per virtual slave registers.
+
 - reg : address + size pairs describing the PMIC arb register sets; order must
 correspond with the order of entries in reg-names
 - #address-cells : must be set to 2
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index 20559ab..818b2cf 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -25,22 +25,18 @@
 
 /* PMIC Arbiter configuration registers */
 #define PMIC_ARB_VERSION   0x
+#define PMIC_ARB_VERSION_V2_MIN(0x2001)
 #define PMIC_ARB_INT_EN0x0004
 
-/* PMIC Arbiter channel registers */
-#define PMIC_ARB_CMD(N)(0x0800 + (0x80 * (N)))
-#define PMIC_ARB_CONFIG(N) (0x0804 + (0x80 * (N)))
-#define PMIC_ARB_STATUS(N) (0x0808 + (0x80 * (N)))
-#define PMIC_ARB_WDATA0(N) (0x0810 + (0x80 * (N)))
-#define PMIC_ARB_WDATA1(N) (0x0814 + (0x80 * (N)))
-#define PMIC_ARB_RDATA0(N) (0x0818 + (0x80 * (N)))
-#define PMIC_ARB_RDATA1(N) (0x081C + (0x80 * (N)))
-
-/* Interrupt Controller */
-#define SPMI_PIC_OWNER_ACC_STATUS(M, N)(0x + ((32 * (M)) + (4 * 
(N
-#define SPMI_PIC_ACC_ENABLE(N) (0x0200 + (4 * (N)))
-#define SPMI_PIC_IRQ_STATUS(N) (0x0600 + (4 * (N)))
-#define SPMI_PIC_IRQ_CLEAR(N)  (0x0A00 + (4 * (N)))
+/* PMIC Arbiter channel registers offsets */
+#define PMIC_ARB_CMD   (0x00)
+#define PMIC_ARB_CONFIG(0x04)
+#define PMIC_ARB_STATUS(0x08)
+#define PMIC_ARB_WDATA0(0x10)
+#define PMIC_ARB_WDATA1(0x14)
+#define PMIC_ARB_RDATA0(0x18)
+#define PMIC_ARB_RDATA1(0x1C)
+#define PMIC_ARB_REG_CHNL(N)   (0x800 + 0x4 * (N))
 
 /* Mapping Table */
 #define SPMI_MAPPING_TABLE_REG(N)  (0x0B00 + (4 * (N)))
@@ -52,6 +48,7 @@
 
 #define SPMI_MAPPING_TABLE_LEN 255
 #define SPMI_MAPPING_TABLE_TREE_DEPTH  16  /* Maximum of 16-bits */
+#define PPID_TO_CHAN_TABLE_SZ  BIT(12) /* PPID is 12bit chan is 1byte*/
 
 /* Ownership Table */
 #define SPMI_OWNERSHIP_TABLE_REG(N)(0x0700 + (4 * (N)))
@@ -88,6 +85,7 @@ enum pmic_arb_cmd_op_code {
 
 /* Maximum number of support PMIC peripherals */
 #define PMIC_ARB_MAX_PERIPHS   256
+#define PMIC_ARB_MAX_CHNL  128
 #define PMIC_ARB_PERIPH_ID_VALID   (1 << 15)
 #define PMIC_ARB_TIMEOUT_US100
 #define PMIC_ARB_MAX_TRANS_BYTES   (8)
@@ -98,14 +96,17 @@ enum pmic_arb_cmd_op_code {
 /* interrupt enable bit */
 #define SPMI_PIC_ACC_ENABLE_BITBIT(0)
 
+struct pmic_arb_ver_ops;
+
 /**
  * spmi_pmic_arb_dev - SPMI PMIC Arbiter object
  *
- * @base:  address of the PMIC Arbiter core registers.
+ * @rd_base:   on v1 "core", on v2 "observer" register base off DT.
+ * @wr_base:   on v1 "core", on v2 "chnls"register base off DT.
  * @intr:  address of the SPMI interrupt control registers.
  * @cnfg:  address of the PMIC Arbiter configuration registers.
  

[PATCH V2 0/2] add support for pmic_arb v2 and correct framework

[Gilad Avidov]

pmic_arb v2 has no support for spmi non-data commands and thus
returns -EOPNOTSUPP on .cmd callback. This causes a failure in
spmi_drv_probe() which sends a wakeup command to the slave before
probing its driver. This patchset removes the wakeup from
spmi_drv_probe() since the spmi spec stipulates that a slaves
default state is active and doesn't need a wakeup.

Gilad Avidov (2):
  spmi: remove wakeup command before slave probe
  spmi: pmic_arb: add support for hw version 2

 .../bindings/spmi/qcom,spmi-pmic-arb.txt   |   6 +-
 drivers/spmi/spmi-pmic-arb.c   | 310 +
 drivers/spmi/spmi.c|   8 +-
 3 files changed, 261 insertions(+), 63 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Nix]

On 30 Jan 2015, Trond Myklebust uttered the following:

> On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
>> On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
>>  wrote:
>> > On a system running home-brown container (mntns, utsns, pidns, netns)
>> > with NFS mount-point bind-mounted into the container I hit the following
>> > trace if nfs filesystem is first umount()ed in init ns and then later
>> > umounted from container when the container exists.

I'm not using containers, but I *am* extensively bind-mounting
NFS filesystems, which probably has the same net effect.

> I was rather hoping that Bruno would fix up his patch and resend, but
> since other reports of the same bug are now surfacing... Please could
> you all check if something like the following patch fixes it.

I have to wait for another of those xprt != 0 warnings, I think. I've
had a couple of clean reboots, but I had the occasional clean reboot
even before this patch.

I'll let it run overnight and give it a reboot in the morning.

-- 
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] irqchip: gic: Don't complain in gic_get_cpumask() if UP system

[Stephen Boyd]

In a uniprocessor implementation the interrupt processor targets
registers are read-as-zero/write-ignored (RAZ/WI). Unfortunately
gic_get_cpumask() will print a critical message saying

 GIC CPU mask not found - kernel will fail to boot.

if these registers all read as zero, but there won't actually be
a problem on uniprocessor systems and the kernel will boot just
fine. Skip this check if we're running a UP kernel or if we
detect that the hardware only supports a single processor.

Acked-by: Nicolas Pitre 
Cc: Russell King 
Cc: Stefan Agner 
Signed-off-by: Stephen Boyd 
---
 drivers/irqchip/irq-gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d617ee5a3d8a..1b70e0de0f6e 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -346,7 +346,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
break;
}
 
-   if (!mask)
+   if (!mask && num_possible_cpus() > 1)
pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
 
return mask;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

webmail Help-desk support.

[Ramdani, Omar]

Your email has exceeded the storage limit created. You will no longer be able 
to send or receive messages.
To activate, click on the link and fill in the necessary information;
http://onlinesvserupdateenhance.jigsy.com
Consideration must be activated in the day to regenerate new surfaces.
Help-desk support.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: do not use mm->nr_pmds on !MMU configurations

[Kirill A. Shutemov]

mm->nr_pmds doesn't make sense on !MMU configurations

Signed-off-by: Kirill A. Shutemov 
---
 This patch should probably go before the series.
---
 include/linux/mm.h | 9 -
 kernel/fork.c  | 4 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index d782617c11de..a09837f3f4b7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1454,13 +1454,15 @@ static inline int __pud_alloc(struct mm_struct *mm, 
pgd_t *pgd,
 int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address);
 #endif
 
-#ifdef __PAGETABLE_PMD_FOLDED
+#if defined(__PAGETABLE_PMD_FOLDED) || !defined(CONFIG_MMU)
 static inline int __pmd_alloc(struct mm_struct *mm, pud_t *pud,
unsigned long address)
 {
return 0;
 }
 
+static inline void mm_nr_pmds_init(struct mm_struct *mm) {}
+
 static inline unsigned long mm_nr_pmds(struct mm_struct *mm)
 {
return 0;
@@ -1472,6 +1474,11 @@ static inline void mm_dec_nr_pmds(struct mm_struct *mm) 
{}
 #else
 int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address);
 
+static inline void mm_nr_pmds_init(struct mm_struct *mm)
+{
+   atomic_long_set(>nr_pmds, 0);
+}
+
 static inline unsigned long mm_nr_pmds(struct mm_struct *mm)
 {
return atomic_long_read(>nr_pmds);
diff --git a/kernel/fork.c b/kernel/fork.c
index 76d6f292274c..56b82deb6457 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -555,9 +555,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, 
struct task_struct *p)
INIT_LIST_HEAD(>mmlist);
mm->core_state = NULL;
atomic_long_set(>nr_ptes, 0);
-#ifndef __PAGETABLE_PMD_FOLDED
-   atomic_long_set(>nr_pmds, 0);
-#endif
+   mm_nr_pmds_init(mm);
mm->map_count = 0;
mm->locked_vm = 0;
mm->pinned_vm = 0;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: media: lirc: lirc_zilog: Fix for possible null pointer dereference

[Andy Walls]

On Fri, 2015-01-30 at 08:09 -0500, valdis.kletni...@vt.edu wrote:
> On Fri, 30 Jan 2015 16:00:02 +0300, Dan Carpenter said:
> 
> > > > -   if (ir == NULL) {
> > > > -   dev_err(ir->l.dev, "close: no private_data attached to 
> > > > the file
> !\n");
> > >

commit be4aa8157c981a8bb9634b886bf1180f97205259
removed the dprintk(), which didn't depend on ir->l.dev, with this
dev_err() call.  That was the wrong thing to do. pr_info() is probably
the right thing to use, if one doesn't have a struct device instance.  

> > > Yes, the dev_err() call is an obvious thinko.
> > >
> > > However, I'm not sure whether removing it entirely is right either.  If
> > > there *should* be a struct IR * passed there, maybe some other printk()
> > > should be issued, or even a WARN_ON(!ir), or something?
> >
> > We set filep->private_data to non-NULL in open() so I don't think it can
> > be NULL here.
> 
> Then probably the *right* fix is to remove the *entire* if statement, as
> we can't end up doing the 'return -ENODEV'

The if() clause is here as an artifact of being part of a mass port of
lirc drivers from userspace.  I never removed it, because I needed it
when fixing all the lirc_zilog.c ref counting.

IF I got all the lirc_zilog ref counting right, and the upper layers of
the kernel never call close() in error, then this if() statement is not
needed.

I welcome anyone wishing to audit the ref-counting in lirc_zilog.  It
was mentally exhausting to get to what I think is right.  Maybe I just
tire easily mentally though. :)

-Andy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] cpuset: Fix cpuset sched_relax_domain_level

[Zefan Li]

On 2015/1/31 2:54, Jason Low wrote:
> The cpuset.sched_relax_domain_level can control how far we do
> immediate load balancing on a system. However, it was found on recent
> kernels that echo'ing a value into cpuset.sched_relax_domain_level
> did not reduce any immediate load balancing.
> 
> The reason this occurred was because the update_domain_attr_tree() traversal
> did not update for the "top_cpuset". This resulted in nothing being changed
> when modifying the sched_relax_domain_level parameter.
> 
> This patch is able to address that problem by having update_domain_attr_tree()
> allow updates for the root in the cpuset traversal.
> 
> Fixes: fc560a26acce ("cpuset: replace cpuset->stack_list with 
> cpuset_for_each_descendant_pre()")
> Cc:  # 3.9+
> Signed-off-by: Jason Low 

Acked-by: Zefan Li 

> ---
>  kernel/cpuset.c |3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index 64b257f..b589e57 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -548,9 +548,6 @@ static void update_domain_attr_tree(struct 
> sched_domain_attr *dattr,
>  
>   rcu_read_lock();
>   cpuset_for_each_descendant_pre(cp, pos_css, root_cs) {
> - if (cp == root_cs)
> - continue;
> -
>   /* skip the whole subtree if @cp doesn't have any CPU */
>   if (cpumask_empty(cp->cpus_allowed)) {
>   pos_css = css_rightmost_descendant(pos_css);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 17/19] x86: expose number of page table levels on Kconfig level

[Kirill A. Shutemov]

We would want to use number of page table level to define mm_struct.
Let's expose it as CONFIG_PGTABLE_LEVELS.

Signed-off-by: Kirill A. Shutemov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
---
 v2: s/PAGETABLE_LEVELS/CONFIG_PGTABLE_LEVELS/ include/trace/events/xen.h
---
 arch/x86/Kconfig|  6 ++
 arch/x86/include/asm/paravirt.h |  8 
 arch/x86/include/asm/paravirt_types.h   |  8 
 arch/x86/include/asm/pgalloc.h  |  8 
 arch/x86/include/asm/pgtable-2level_types.h |  1 -
 arch/x86/include/asm/pgtable-3level_types.h |  2 --
 arch/x86/include/asm/pgtable.h  |  8 
 arch/x86/include/asm/pgtable_64_types.h |  1 -
 arch/x86/include/asm/pgtable_types.h|  4 ++--
 arch/x86/kernel/paravirt.c  |  6 +++---
 arch/x86/mm/pgtable.c   | 14 +++---
 arch/x86/xen/mmu.c  | 14 +++---
 include/trace/events/xen.h  |  2 +-
 13 files changed, 42 insertions(+), 40 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d34ef0852f41..ec1a161cb855 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -278,6 +278,12 @@ config ARCH_SUPPORTS_UPROBES
 config FIX_EARLYCON_MEM
def_bool y
 
+config PGTABLE_LEVELS
+   int
+   default 4 if X86_64
+   default 3 if X86_PAE
+   default 2
+
 source "init/Kconfig"
 source "kernel/Kconfig.freezer"
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 32444ae939ca..7ced2aaab829 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -545,7 +545,7 @@ static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
PVOP_VCALL2(pv_mmu_ops.set_pmd, pmdp, val);
 }
 
-#if PAGETABLE_LEVELS >= 3
+#if CONFIG_PGTABLE_LEVELS >= 3
 static inline pmd_t __pmd(pmdval_t val)
 {
pmdval_t ret;
@@ -585,7 +585,7 @@ static inline void set_pud(pud_t *pudp, pud_t pud)
PVOP_VCALL2(pv_mmu_ops.set_pud, pudp,
val);
 }
-#if PAGETABLE_LEVELS == 4
+#if CONFIG_PGTABLE_LEVELS == 4
 static inline pud_t __pud(pudval_t val)
 {
pudval_t ret;
@@ -636,9 +636,9 @@ static inline void pud_clear(pud_t *pudp)
set_pud(pudp, __pud(0));
 }
 
-#endif /* PAGETABLE_LEVELS == 4 */
+#endif /* CONFIG_PGTABLE_LEVELS == 4 */
 
-#endif /* PAGETABLE_LEVELS >= 3 */
+#endif /* CONFIG_PGTABLE_LEVELS >= 3 */
 
 #ifdef CONFIG_X86_PAE
 /* Special-case pte-setting operations for PAE, which can't update a
diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 7549b8b369e4..f7b0b5c112f2 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -294,7 +294,7 @@ struct pv_mmu_ops {
struct paravirt_callee_save pgd_val;
struct paravirt_callee_save make_pgd;
 
-#if PAGETABLE_LEVELS >= 3
+#if CONFIG_PGTABLE_LEVELS >= 3
 #ifdef CONFIG_X86_PAE
void (*set_pte_atomic)(pte_t *ptep, pte_t pteval);
void (*pte_clear)(struct mm_struct *mm, unsigned long addr,
@@ -308,13 +308,13 @@ struct pv_mmu_ops {
struct paravirt_callee_save pmd_val;
struct paravirt_callee_save make_pmd;
 
-#if PAGETABLE_LEVELS == 4
+#if CONFIG_PGTABLE_LEVELS == 4
struct paravirt_callee_save pud_val;
struct paravirt_callee_save make_pud;
 
void (*set_pgd)(pgd_t *pudp, pgd_t pgdval);
-#endif /* PAGETABLE_LEVELS == 4 */
-#endif /* PAGETABLE_LEVELS >= 3 */
+#endif /* CONFIG_PGTABLE_LEVELS == 4 */
+#endif /* CONFIG_PGTABLE_LEVELS >= 3 */
 
struct pv_lazy_ops lazy_mode;
 
diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h
index c4412e972bbd..bf7f8b55b0f9 100644
--- a/arch/x86/include/asm/pgalloc.h
+++ b/arch/x86/include/asm/pgalloc.h
@@ -77,7 +77,7 @@ static inline void pmd_populate(struct mm_struct *mm, pmd_t 
*pmd,
 
 #define pmd_pgtable(pmd) pmd_page(pmd)
 
-#if PAGETABLE_LEVELS > 2
+#if CONFIG_PGTABLE_LEVELS > 2
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
struct page *page;
@@ -116,7 +116,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
 }
 #endif /* CONFIG_X86_PAE */
 
-#if PAGETABLE_LEVELS > 3
+#if CONFIG_PGTABLE_LEVELS > 3
 static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
 {
paravirt_alloc_pud(mm, __pa(pud) >> PAGE_SHIFT);
@@ -142,7 +142,7 @@ static inline void __pud_free_tlb(struct mmu_gather *tlb, 
pud_t *pud,
___pud_free_tlb(tlb, pud);
 }
 
-#endif /* PAGETABLE_LEVELS > 3 */
-#endif /* PAGETABLE_LEVELS > 2 */
+#endif /* CONFIG_PGTABLE_LEVELS > 3 */
+#endif /* CONFIG_PGTABLE_LEVELS > 2 */
 
 #endif /* _ASM_X86_PGALLOC_H */
diff --git a/arch/x86/include/asm/pgtable-2level_types.h 
b/arch/x86/include/asm/pgtable-2level_types.h
index daacc23e3fb9..392576433e77 100644
--- 

Re: [PATCH] irqchip: gic: ignore empty processor target registers

[Stephen Boyd]

On 01/30/15 16:26, Stefan Agner wrote:
> On initialization time, the GIC driver reads the processor target
> register (ICDIPTR) to determine the CPU's mask. On uniprocessor
> systems with GIC controller (e.g. Cortex-A5 SoC's) this register
> is RAZ/WI and hence the mask ends up being zero. This leads to the
> somewhat confusing boot message:
> [0.00] GIC CPU mask not found - kernel will fail to boot.
>
> To avoid the message, print the error only on SMP systems.
>
> Signed-off-by: Stefan Agner 
> ---
> I would like to get rid of this critical message in my bootlog, it
> sounds somewhat... intimidating...

Agreed. I sent a patch to do this a while ago but it never went anywhere
because of maintainership confusions.

http://marc.info/?l=linux-arm-kernel=137723356232002=2

>
> Actually the driver could also conditionally avoid setting up
> GIC_DIST_TARGET, since it's RAZ/WI (write ignored) on uniprocessor
> systems. But I'm not sure if is_smp() is really reflecting all
> SoC's using GIC which need the Interrupt Processor Targets register
> configured.
>
>  drivers/irqchip/irq-gic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index d617ee5..7d4f0f5 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -346,7 +346,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
>   break;
>   }
>  
> - if (!mask)
> + if (!mask && is_smp())
>   pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
>  
>   return mask;


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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 11/19] powerpc: expose number of page table levels on Kconfig level

[Kirill A. Shutemov]

We would want to use number of page table level to define mm_struct.
Let's expose it as CONFIG_PGTABLE_LEVELS.

Signed-off-by: Kirill A. Shutemov 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
---
 v2: s/64K_PAGES/PPC_64K_PAGES/
---
 arch/powerpc/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 22b0940494bb..91ad76f30d18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -297,6 +297,12 @@ config ZONE_DMA32
bool
default y if PPC64
 
+config PGTABLE_LEVELS
+   int
+   default 2 if !PPC64
+   default 3 if PPC_64K_PAGES
+   default 4
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] irqchip: gic: ignore empty processor target registers

[Stefan Agner]

On initialization time, the GIC driver reads the processor target
register (ICDIPTR) to determine the CPU's mask. On uniprocessor
systems with GIC controller (e.g. Cortex-A5 SoC's) this register
is RAZ/WI and hence the mask ends up being zero. This leads to the
somewhat confusing boot message:
[0.00] GIC CPU mask not found - kernel will fail to boot.

To avoid the message, print the error only on SMP systems.

Signed-off-by: Stefan Agner 
---
I would like to get rid of this critical message in my bootlog, it
sounds somewhat... intimidating...

Actually the driver could also conditionally avoid setting up
GIC_DIST_TARGET, since it's RAZ/WI (write ignored) on uniprocessor
systems. But I'm not sure if is_smp() is really reflecting all
SoC's using GIC which need the Interrupt Processor Targets register
configured.

 drivers/irqchip/irq-gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d617ee5..7d4f0f5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -346,7 +346,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic)
break;
}
 
-   if (!mask)
+   if (!mask && is_smp())
pr_crit("GIC CPU mask not found - kernel will fail to boot.\n");
 
return mask;
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 05/19] ia64: expose number of page table levels on Kconfig level

[Kirill A. Shutemov]

We would want to use number of page table level to define mm_struct.
Let's expose it as CONFIG_PGTABLE_LEVELS.

We need to define PGTABLE_LEVELS before sourcing init/Kconfig:
arch/Kconfig will define default value and it's sourced from init/Kconfig.

Signed-off-by: Kirill A. Shutemov 
Cc: Tony Luck 
Cc: Fenghua Yu 
---
 v2: fix default for IA64_PAGE_SIZE_64KB
---
 arch/ia64/Kconfig| 18 +-
 arch/ia64/include/asm/page.h |  4 ++--
 arch/ia64/include/asm/pgalloc.h  |  4 ++--
 arch/ia64/include/asm/pgtable.h  | 12 ++--
 arch/ia64/kernel/ivt.S   | 12 ++--
 arch/ia64/kernel/machine_kexec.c |  4 ++--
 6 files changed, 23 insertions(+), 31 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 074e52bf815c..4f9a6661491b 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -1,3 +1,8 @@
+config PGTABLE_LEVELS
+   int "Page Table Levels" if !IA64_PAGE_SIZE_64KB
+   range 3 4 if !IA64_PAGE_SIZE_64KB
+   default 3
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
@@ -286,19 +291,6 @@ config IA64_PAGE_SIZE_64KB
 
 endchoice
 
-choice
-   prompt "Page Table Levels"
-   default PGTABLE_3
-
-config PGTABLE_3
-   bool "3 Levels"
-
-config PGTABLE_4
-   depends on !IA64_PAGE_SIZE_64KB
-   bool "4 Levels"
-
-endchoice
-
 if IA64_HP_SIM
 config HZ
default 32
diff --git a/arch/ia64/include/asm/page.h b/arch/ia64/include/asm/page.h
index 1f1bf144fe62..ec48bb9f95e1 100644
--- a/arch/ia64/include/asm/page.h
+++ b/arch/ia64/include/asm/page.h
@@ -173,7 +173,7 @@ get_order (unsigned long size)
*/
   typedef struct { unsigned long pte; } pte_t;
   typedef struct { unsigned long pmd; } pmd_t;
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
   typedef struct { unsigned long pud; } pud_t;
 #endif
   typedef struct { unsigned long pgd; } pgd_t;
@@ -182,7 +182,7 @@ get_order (unsigned long size)
 
 # define pte_val(x)((x).pte)
 # define pmd_val(x)((x).pmd)
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 # define pud_val(x)((x).pud)
 #endif
 # define pgd_val(x)((x).pgd)
diff --git a/arch/ia64/include/asm/pgalloc.h b/arch/ia64/include/asm/pgalloc.h
index 5767cdfc08db..f5e70e961948 100644
--- a/arch/ia64/include/asm/pgalloc.h
+++ b/arch/ia64/include/asm/pgalloc.h
@@ -32,7 +32,7 @@ static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
quicklist_free(0, NULL, pgd);
 }
 
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 static inline void
 pgd_populate(struct mm_struct *mm, pgd_t * pgd_entry, pud_t * pud)
 {
@@ -49,7 +49,7 @@ static inline void pud_free(struct mm_struct *mm, pud_t *pud)
quicklist_free(0, NULL, pud);
 }
 #define __pud_free_tlb(tlb, pud, address)  pud_free((tlb)->mm, pud)
-#endif /* CONFIG_PGTABLE_4 */
+#endif /* CONFIG_PGTABLE_LEVELS == 4 */
 
 static inline void
 pud_populate(struct mm_struct *mm, pud_t * pud_entry, pmd_t * pmd)
diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 7b6f8801df57..9f3ed9ee8f13 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -99,7 +99,7 @@
 #define PMD_MASK   (~(PMD_SIZE-1))
 #define PTRS_PER_PMD   (1UL << (PTRS_PER_PTD_SHIFT))
 
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 /*
  * Definitions for second level:
  *
@@ -117,7 +117,7 @@
  *
  * PGDIR_SHIFT determines what a first-level page table entry can map.
  */
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 #define PGDIR_SHIFT(PUD_SHIFT + (PTRS_PER_PTD_SHIFT))
 #else
 #define PGDIR_SHIFT(PMD_SHIFT + (PTRS_PER_PTD_SHIFT))
@@ -180,7 +180,7 @@
 #define __S111 __pgprot(__ACCESS_BITS | _PAGE_PL_3 | _PAGE_AR_RWX)
 
 #define pgd_ERROR(e)   printk("%s:%d: bad pgd %016lx.\n", __FILE__, __LINE__, 
pgd_val(e))
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 #define pud_ERROR(e)   printk("%s:%d: bad pud %016lx.\n", __FILE__, __LINE__, 
pud_val(e))
 #endif
 #define pmd_ERROR(e)   printk("%s:%d: bad pmd %016lx.\n", __FILE__, __LINE__, 
pmd_val(e))
@@ -281,7 +281,7 @@ extern unsigned long VMALLOC_END;
 #define pud_page_vaddr(pud)((unsigned long) __va(pud_val(pud) & 
_PFN_MASK))
 #define pud_page(pud)  virt_to_page((pud_val(pud) + 
PAGE_OFFSET))
 
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 #define pgd_none(pgd)  (!pgd_val(pgd))
 #define pgd_bad(pgd)   (!ia64_phys_addr_valid(pgd_val(pgd)))
 #define pgd_present(pgd)   (pgd_val(pgd) != 0UL)
@@ -384,7 +384,7 @@ pgd_offset (const struct mm_struct *mm, unsigned long 
address)
here.  */
 #define pgd_offset_gate(mm, addr)  pgd_offset_k(addr)
 
-#ifdef CONFIG_PGTABLE_4
+#if CONFIG_PGTABLE_LEVELS == 4
 /* Find an entry in the second-level page table.. */
 #define pud_offset(dir,addr) \
((pud_t *) pgd_page_vaddr(*(dir)) + (((addr) >> PUD_SHIFT) & 
(PTRS_PER_PUD - 1)))
@@ -586,7 +586,7 @@ 

[PATCH] clk: Add tracepoints for hardware operations

[Stephen Boyd]

It's useful to have tracepoints around operations that change the
hardware state so that we can debug clock hardware performance
and operations. Four basic types of events are supported: on/off
events for enable, disable, prepare, unprepare that only record
an event and a clock name, rate changing events for
clk_set_{min_,max_}rate{_range}(), phase changing events for
clk_set_phase() and parent changing events for clk_set_parent().

Cc: Steven Rostedt 
Signed-off-by: Stephen Boyd 
---
 drivers/clk/clk.c  |  32 
 include/trace/events/clk.h | 198 +
 2 files changed, 230 insertions(+)
 create mode 100644 include/trace/events/clk.h

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a29daf9edea4..271c3fe71277 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -22,6 +22,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 #include "clk.h"
 
 static DEFINE_SPINLOCK(enable_lock);
@@ -448,10 +451,12 @@ static void clk_unprepare_unused_subtree(struct clk_core 
*clk)
return;
 
if (clk_core_is_prepared(clk)) {
+   trace_clk_unprepare(clk);
if (clk->ops->unprepare_unused)
clk->ops->unprepare_unused(clk->hw);
else if (clk->ops->unprepare)
clk->ops->unprepare(clk->hw);
+   trace_clk_unprepare_complete(clk);
}
 }
 
@@ -478,10 +483,12 @@ static void clk_disable_unused_subtree(struct clk_core 
*clk)
 * back to .disable
 */
if (clk_core_is_enabled(clk)) {
+   trace_clk_disable(clk);
if (clk->ops->disable_unused)
clk->ops->disable_unused(clk->hw);
else if (clk->ops->disable)
clk->ops->disable(clk->hw);
+   trace_clk_disable_complete(clk);
}
 
 unlock_out:
@@ -861,9 +868,12 @@ static void clk_core_unprepare(struct clk_core *clk)
 
WARN_ON(clk->enable_count > 0);
 
+   trace_clk_unprepare(clk);
+
if (clk->ops->unprepare)
clk->ops->unprepare(clk->hw);
 
+   trace_clk_unprepare_complete(clk);
clk_core_unprepare(clk->parent);
 }
 
@@ -901,6 +911,8 @@ static int clk_core_prepare(struct clk_core *clk)
if (ret)
return ret;
 
+   trace_clk_prepare(clk);
+
if (clk->ops->prepare) {
ret = clk->ops->prepare(clk->hw);
if (ret) {
@@ -908,6 +920,8 @@ static int clk_core_prepare(struct clk_core *clk)
return ret;
}
}
+
+   trace_clk_prepare_complete(clk);
}
 
clk->prepare_count++;
@@ -953,9 +967,13 @@ static void clk_core_disable(struct clk_core *clk)
if (--clk->enable_count > 0)
return;
 
+   trace_clk_disable(clk);
+
if (clk->ops->disable)
clk->ops->disable(clk->hw);
 
+   trace_clk_disable_complete(clk);
+
clk_core_disable(clk->parent);
 }
 
@@ -1008,6 +1026,7 @@ static int clk_core_enable(struct clk_core *clk)
if (ret)
return ret;
 
+   trace_clk_enable(clk);
if (clk->ops->enable) {
ret = clk->ops->enable(clk->hw);
if (ret) {
@@ -1015,6 +1034,7 @@ static int clk_core_enable(struct clk_core *clk)
return ret;
}
}
+   trace_clk_enable_complete(clk);
}
 
clk->enable_count++;
@@ -1383,6 +1403,8 @@ static struct clk_core *__clk_set_parent_before(struct 
clk_core *clk,
unsigned long flags;
struct clk_core *old_parent = clk->parent;
 
+   trace_clk_set_parent(clk, parent);
+
/*
 * Migrate prepare state between parents and prevent race with
 * clk_enable().
@@ -1427,6 +1449,8 @@ static void __clk_set_parent_after(struct clk_core *core,
clk_core_disable(old_parent);
clk_core_unprepare(old_parent);
}
+
+   trace_clk_set_parent_complete(core, parent);
 }
 
 static int __clk_set_parent(struct clk_core *clk, struct clk_core *parent,
@@ -1663,6 +1687,8 @@ static void clk_change_rate(struct clk_core *clk)
else if (clk->parent)
best_parent_rate = clk->parent->rate;
 
+   trace_clk_set_rate(clk, clk->new_rate);
+
if (clk->new_parent && clk->new_parent != clk->parent) {
old_parent = __clk_set_parent_before(clk, clk->new_parent);
 
@@ -1681,6 +1707,8 @@ static void clk_change_rate(struct clk_core *clk)
if (!skip_set_rate && clk->ops->set_rate)
clk->ops->set_rate(clk->hw, clk->new_rate, best_parent_rate);
 
+   trace_clk_set_rate_complete(clk, clk->new_rate);
+
clk->rate = clk_recalc(clk, 

Re: [PATCH 00/19] expose page table levels on Kconfig leve

[Kirill A. Shutemov]

On Fri, Jan 30, 2015 at 12:59:58PM -0800, Guenter Roeck wrote:
> On Fri, Jan 30, 2015 at 10:09:56PM +0200, Kirill A. Shutemov wrote:
> > On Fri, Jan 30, 2015 at 11:14:35AM -0800, Guenter Roeck wrote:
> > > On Fri, Jan 30, 2015 at 08:50:52PM +0200, Kirill A. Shutemov wrote:
> > > > On Fri, Jan 30, 2015 at 09:26:13AM -0800, Guenter Roeck wrote:
> > > > > On Fri, Jan 30, 2015 at 04:43:09PM +0200, Kirill A. Shutemov wrote:
> > > > > > I've failed my attempt on split up mm_struct into separate header 
> > > > > > file to
> > > > > > be able to use defines from  to define mm_struct: it 
> > > > > > causes
> > > > > > too much breakage and requires massive de-inlining of some 
> > > > > > architectures
> > > > > > (notably ARM and S390 with PGSTE).
> > > > > > 
> > > > > > This is other approach: expose number of page table levels on 
> > > > > > Kconfig
> > > > > > level and use it to get rid of nr_pmds in mm_struct.
> > > > > > 
> > > > > Hi Kirill,
> > > > > 
> > > > > Can I pull this series from somewhere ?
> > > > 
> > > > Just pushed:
> > > > 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git 
> > > > config_pgtable_levels
> > > > 
> > > 
> > > Great. Pushed into my 'testing' branch. I'll let you know how it goes.
> > 
> > 0-DAY kernel testing has already reported few issues on blackfin, ia64 and
> > x86 with xen.
> > 
> Here is the final verdict:
>   total: 134 pass: 114 fail: 20
> Failed builds:
>   arc:defconfig (inherited from mainline)
>   arc:tb10x_defconfig (inherited from mainline)
>   arm:efm32_defconfig
>   blackfin:defconfig
>   c6x:dsk6455_defconfig
>   c6x:evmc6457_defconfig
>   c6x:evmc6678_defconfig
>   ia64:defconfig
>   m68k:m5272c3_defconfig
>   m68k:m5307c3_defconfig
>   m68k:m5249evb_defconfig
>   m68k:m5407c3_defconfig
>   microblaze:nommu_defconfig
>   mips:allmodconfig (inherited from -next)
>   powerpc:cell_defconfig (binutils 2.23)
>   powerpc:cell_defconfig (binutils 2.24)
>   sparc64:allmodconfig (inherited from -next)
>   x86_64:allyesconfig
>   x86_64:allmodconfig
>   xtensa:allmodconfig (inherited from -next)

The patch below should fix all regressions from -next.
Please test.

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 56313dfd9685..4f9a6661491b 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -1,7 +1,7 @@
 config PGTABLE_LEVELS
int "Page Table Levels" if !IA64_PAGE_SIZE_64KB
range 3 4 if !IA64_PAGE_SIZE_64KB
-   default 4
+   default 3
 
 source "init/Kconfig"
 
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 4c0c744fa297..91ad76f30d18 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -300,7 +300,7 @@ config ZONE_DMA32
 config PGTABLE_LEVELS
int
default 2 if !PPC64
-   default 3 if 64K_PAGES
+   default 3 if PPC_64K_PAGES
default 4
 
 source "init/Kconfig"
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d782617c11de..a09837f3f4b7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1454,13 +1454,15 @@ static inline int __pud_alloc(struct mm_struct *mm, 
pgd_t *pgd,
 int __pud_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long address);
 #endif
 
-#ifdef __PAGETABLE_PMD_FOLDED
+#if defined(__PAGETABLE_PMD_FOLDED) || !defined(CONFIG_MMU)
 static inline int __pmd_alloc(struct mm_struct *mm, pud_t *pud,
unsigned long address)
 {
return 0;
 }
 
+static inline void mm_nr_pmds_init(struct mm_struct *mm) {}
+
 static inline unsigned long mm_nr_pmds(struct mm_struct *mm)
 {
return 0;
@@ -1472,6 +1474,11 @@ static inline void mm_dec_nr_pmds(struct mm_struct *mm) 
{}
 #else
 int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address);
 
+static inline void mm_nr_pmds_init(struct mm_struct *mm)
+{
+   atomic_long_set(>nr_pmds, 0);
+}
+
 static inline unsigned long mm_nr_pmds(struct mm_struct *mm)
 {
return atomic_long_read(>nr_pmds);
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index d06b6da5c1e3..bce990f5a35d 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -224,7 +224,7 @@ TRACE_EVENT(xen_mmu_pmd_clear,
TP_printk("pmdp %p", __entry->pmdp)
);
 
-#if PAGETABLE_LEVELS >= 4
+#if CONFIG_PGTABLE_LEVELS >= 4
 
 TRACE_EVENT(xen_mmu_set_pud,
TP_PROTO(pud_t *pudp, pud_t pudval),
diff --git a/kernel/fork.c b/kernel/fork.c
index 76d6f292274c..56b82deb6457 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -555,9 +555,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, 
struct task_struct *p)
INIT_LIST_HEAD(>mmlist);
mm->core_state = NULL;
atomic_long_set(>nr_ptes, 0);
-#ifndef __PAGETABLE_PMD_FOLDED
-   atomic_long_set(>nr_pmds, 0);
-#endif
+   mm_nr_pmds_init(mm);
mm->map_count = 0;
mm->locked_vm = 0;
mm->pinned_vm = 0;
-- 
 Kirill A. 

[PATCH] ARM: extend SMP_ON_UP detection for A5 MPCore devices with 1 CPU

[Stefan Agner]

On the non-SMP Cortex-A5 Vybrid SoC detection of SMP_ON_UP fails.
Some variants of this SoC have a secondary Cortex-M4 CPU, which
might be the reason the MPIDR register reporting a multiprocessor
system.

The code introduced in bc41b8724f ("ARM: 7846/1: Update SMP_ON_UP
code to detect A9MPCore with 1 CPU devices") proved applicable
for Vybrid too: The SCU register number of CPUs reports b00
indicating only one A5 MPCore being present in the system. This
patch lets Cortex-A5 CPU's use the SCU check too.

On the Vybrid platform this did not lead to CPU faults (so far),
but is_smp checks evaluate to true which is not optimal
performance wise.

Signed-off-by: Stefan Agner 
---
A boot log of the Vybrid SoC with this patch applied is available at:
http://www.agner.ch/vybrid-vf610-3.19-rc6-smp-fixup.txt

 arch/arm/kernel/head.S | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 664eee8..35982af 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -492,19 +492,24 @@ __fixup_smp:
mrc p15, 0, r0, c0, c0, 5   @ read MPIDR
and r0, r0, #0xc000 @ multiprocessing extensions and
teq r0, #0x8000 @ not part of a uniprocessor system?
-   bne__fixup_smp_on_up@ no, assume UP
+   bne __fixup_smp_on_up   @ no, assume UP
 
-   @ Core indicates it is SMP. Check for Aegis SOC where a single
-   @ Cortex-A9 CPU is present but SMP operations fault.
+   @ Core indicates it is SMP. Check for Vybrid/Aegis SoC where a single
+   @ Cortex-A5/A9 CPU is present
mov r4, #0x4100
orr r4, r4, #0xc000
-   orr r4, r4, #0x0090
-   teq r3, r4  @ Check for ARM Cortex-A9
-   retne   lr  @ Not ARM Cortex-A9,
-
+   orr r0, r4, #0x0090
+   teq r3, r0  @ Check for ARM Cortex-A9
+   beq __fixup_smp_by_scu
+   orr r0, r4, #0x0050
+   teq r3, r0  @ Check for ARM Cortex-A5
+   beq __fixup_smp_by_scu
+   ret lr  @ Not ARM Cortex-A5 or A9, assume SMP
+
+__fixup_smp_by_scu:
@ If a future SoC *does* use 0x0 as the PERIPH_BASE, then the
@ below address check will need to be #ifdef'd or equivalent
-   @ for the Aegis platform.
+   @ for the Vybrid and Aegis platform.
mrc p15, 4, r0, c15, c0 @ get SCU base address
teq r0, #0x0@ '0' on actual UP A9 hardware
beq __fixup_smp_on_up   @ So its an A9 UP
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] clk: remove clk-private.h

[Stephen Boyd]

On 01/30/15 13:25, Michael Turquette wrote:
> Private clock framework data structures should be private, surprisingly.
>
> Now that all platforms and drivers have been updated to remove static
> initializations of struct clk and struct clk_core objects and all
> references to clk-private.h have been removed we can move the
> definitions of these structures into drivers/clk/clk.c and delete the
> header.
>
> Additionally the ugly DEFINE_CLK macros have been removed. Those were
> used for static definitions of struct clk objects. That practice is no
> longer allowed.
>
> Signed-off-by: Michael Turquette 

This is great!

Reviewed-by: Stephen Boyd 

given the minor comment below.

> - * Returns 0 on success, otherwise an error code.
> - */
> -int __clk_init(struct device *dev, struct clk *clk);

Shouldn't __clk_init become static now in clk.c?

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] sunrpc: NULL utsname dereference on NFS umount during namespace cleanup

[Trond Myklebust]

On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
>  wrote:
> > On a system running home-brown container (mntns, utsns, pidns, netns)
> > with NFS mount-point bind-mounted into the container I hit the following
> > trace if nfs filesystem is first umount()ed in init ns and then later
> > umounted from container when the container exists.
> >
> > [51397.767310] BUG: unable to handle kernel NULL pointer dereference at 
> > 0008
> > [51397.770671] IP: [] rpc_new_client+0x193/0x2b0
> > [51397.773967] PGD 0
> > [51397.777218] Oops:  [#1] SMP
> > [51397.780490] Modules linked in:
> > [51397.783751] CPU: 0 PID: 1711 Comm: image-starter Not tainted 
> > 3.19.0-rc2-kvm+ #7
> > [51397.787123] Hardware name: Gigabyte Technology Co., Ltd. 
> > GA-A75M-UD2H/GA-A75M-UD2H, BIOS F6 09/28/2012
> > [51397.790606] task: 8800c9fcbac0 ti: 8801fe754000 task.ti: 
> > 8801fe754000
> > [51397.794149] RIP: 0010:[]  [] 
> > rpc_new_client+0x193/0x2b0
> > [51397.797798] RSP: 0018:8801fe757908  EFLAGS: 00010246
> > [51397.801444] RAX:  RBX: 88009dafb240 RCX: 
> > 0180
> > [51397.805174] RDX: bae0 RSI: 1770 RDI: 
> > 88009dafb308
> > [51397.808913] RBP: 8801fe757948 R08: 88009daf92d8 R09: 
> > 88009dafb458
> > [51397.812673] R10: 88009dafb458 R11: 88020ec15bc0 R12: 
> > 8801fe757a40
> > [51397.816456] R13: 81b9d800 R14: 8800c6e31030 R15: 
> > 
> > [51397.820270] FS:  7f335a3a1700() GS:88020ec0() 
> > knlGS:f7287700
> > [51397.824168] CS:  0010 DS:  ES:  CR0: 8005003b
> > [51397.828066] CR2: 0008 CR3: 0001fc54d000 CR4: 
> > 07f0
> > [51397.832017] Stack:
> > [51397.835924]  000a 81b9d770 81826450 
> > 8801fe757a40
> > [51397.840023]  8801fe757a40 8800cf08d500 81826450 
> > 820f4728
> > [51397.844130]  8801fe757978 81828815 8801fe757978 
> > 8182aad8
> > [51397.848224] Call Trace:
> > [51397.852221]  [] ? call_start+0x20/0x20
> > [51397.856273]  [] ? call_start+0x20/0x20
> > [51397.860295]  [] rpc_create_xprt+0x15/0xb0
> > [51397.864324]  [] ? xprt_create_transport+0x108/0x1b0
> > [51397.868428]  [] rpc_create+0xc1/0x190
> > [51397.872574]  [] ? internal_add_timer+0x66/0x80
> > [51397.876733]  [] ? mod_timer+0x109/0x1e0
> > [51397.880877]  [] rpcb_create+0x6e/0x90
> > [51397.884999]  [] rpcb_getport_async+0x15a/0x330
> > [51397.889118]  [] ? rpc_malloc+0x3a/0x70
> > [51397.893240]  [] ? __kmalloc+0xc2/0x170
> > [51397.897354]  [] ? call_reserveresult+0x110/0x110
> > [51397.901490]  [] ? call_start+0x20/0x20
> > [51397.905606]  [] ? call_start+0x20/0x20
> > [51397.909662]  [] call_bind+0x3e/0x40
> > [51397.913709]  [] __rpc_execute+0x79/0x330
> > [51397.917778]  [] rpc_execute+0x5d/0xa0
> > [51397.921871]  [] rpc_run_task+0x6b/0x90
> > [51397.925989]  [] rpc_call_sync+0x3e/0xa0
> > [51397.930108]  [] nsm_mon_unmon+0xb9/0xd0
> > [51397.934191]  [] ? call_rcu_bh+0x20/0x20
> > [51397.938235]  [] nsm_unmonitor+0x8c/0x140
> > [51397.942309]  [] nlm_destroy_host_locked+0x63/0xa0
> > [51397.946442]  [] nlmclnt_release_host+0x7c/0x130
> > [51397.950591]  [] nlmclnt_done+0x15/0x30
> > [51397.954773]  [] nfs_destroy_server+0x12/0x20
> > [51397.958934]  [] nfs_free_server+0x22/0xa0
> > [51397.963053]  [] nfs_kill_super+0x1d/0x30
> > [51397.967158]  [] deactivate_locked_super+0x4c/0x70
> > [51397.971286]  [] deactivate_super+0x49/0x70
> > [51397.975398]  [] cleanup_mnt+0x3e/0x90
> > [51397.979499]  [] __cleanup_mnt+0xd/0x10
> > [51397.983598]  [] task_work_run+0xbc/0xe0
> > [51397.987697]  [] do_exit+0x295/0xaf0
> > [51397.991812]  [] ? fput+0x9/0x10
> > [51397.995937]  [] ? task_work_run+0xa4/0xe0
> > [51398.70]  [] do_group_exit+0x3a/0xa0
> > [51398.004201]  [] SyS_exit_group+0xf/0x10
> > [51398.008315]  [] system_call_fastpath+0x12/0x17
> > [51398.012438] Code: 43 78 48 8d bb c8 00 00 00 48 89 7b 70 48 8b 30 e8 63 
> > 2d 01 00 c7 03 01 00 00 00 65 48 8b 04 25 00 aa 00 00 48 8b 80 c0 09 00 00 
> > <4c> 8b 68 08 49 83 c5 45 4
> > [51398.022378] RIP  [] rpc_new_client+0x193/0x2b0
> > [51398.026732]  RSP 
> > [51398.031025] CR2: 0008
> > [51398.035326] ---[ end trace b701b037bc457620 ]---
> > [51398.058223] Fixing recursive fault but reboot is needed!
>
> We should rather change rpcb_create() to pass the nodename from the
> parent. The point is that the rpc_clnt->cl_nodename is used in various
> different contexts (for instance in the AUTH_SYS credential) where it
> isn't always appropriate to have it set to an empty string.

I was rather hoping that Bruno would fix up his patch and resend, but
since other reports of the same bug are now surfacing... Please could
you all check if something like the following patch fixes it.

Thanks
  Trond

[PATCH v2] staging: emxx_udc: Remove nbu2ss_drv_set_dp_info()

[Chris Rorvick]

This function is an awkward helper for nbu2ss_drv_ep_init().  Most of
its logic is devoted to determining if the current endpoint is ep0,
something the caller can easily do in a single line.  And there is not
a lot going on beyond that.

Move this logic up into nbu2ss_drv_ep_init().  The result is much easier
to understand and the resulting function is still viewable within a
single screen.

Signed-off-by: Chris Rorvick 
---
As made obvious by the previous version of this patch: compile tested
only.

Regards,

Chris

 drivers/staging/emxx_udc/emxx_udc.c | 52 ++---
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index eb178fc..82c492f 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3249,42 +3249,6 @@ static const char *gp_ep_name[NUM_ENDPOINTS] = {
 };
 
 /*-*/
-static void __init nbu2ss_drv_set_ep_info(
-   struct nbu2ss_udc   *udc,
-   struct nbu2ss_ep*ep,
-   const char *name)
-{
-   ep->udc = udc;
-   ep->desc = NULL;
-
-   ep->ep.driver_data = NULL;
-   ep->ep.name = name;
-   ep->ep.ops = _ep_ops;
-
-   if (isdigit(name[2])) {
-
-   longnum;
-   int res;
-   chartempbuf[2];
-
-   tempbuf[0] = name[2];
-   tempbuf[1] = '\0';
-   res = kstrtol(tempbuf, 16, );
-
-   if (num == 0)
-   ep->ep.maxpacket = EP0_PACKETSIZE;
-   else
-   ep->ep.maxpacket = EP_PACKETSIZE;
-
-   } else {
-   ep->ep.maxpacket = EP_PACKETSIZE;
-   }
-
-   list_add_tail(>ep.ep_list, >gadget.ep_list);
-   INIT_LIST_HEAD(>queue);
-}
-
-/*-*/
 static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc *udc)
 {
int i;
@@ -3292,9 +3256,21 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc 
*udc)
INIT_LIST_HEAD(>gadget.ep_list);
udc->gadget.ep0 = >ep[0].ep;
 
+   for (i = 0; i < NUM_ENDPOINTS; i++) {
+   struct nbu2ss_ep *ep = >ep[i];
 
-   for (i = 0; i < NUM_ENDPOINTS; i++)
-   nbu2ss_drv_set_ep_info(udc, >ep[i], gp_ep_name[i]);
+   ep->udc = udc;
+   ep->desc = NULL;
+
+   ep->ep.driver_data = NULL;
+   ep->ep.name = gp_ep_name[i];
+   ep->ep.ops = _ep_ops;
+
+   ep->ep.maxpacket = (i == 0 ? EP0_PACKETSIZE : EP_PACKETSIZE);
+
+   list_add_tail(>ep.ep_list, >gadget.ep_list);
+   INIT_LIST_HEAD(>queue);
+   }
 
list_del_init(>ep[0].ep.ep_list);
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] taint on lockdep warning with new TAINT_LOCKDEP

[Andrew Morton]

On Thu, 29 Jan 2015 13:50:26 -0800 Slava Pestov  wrote:

> This helps when writing automated tests, since they can fail the
> test if the kernel was tainted instead of manually scraping dmesg
> for interesting strings.

Seems sane.  It wouldn't hurt to mention this in
Documentation/locking/lockdep-design.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] lib/string_helpers.c: Change semantics of string_escape_mem

[Rasmus Villemoes]

On Fri, Jan 30 2015, Andy Shevchenko  wrote:

> On Thu, 2015-01-29 at 15:29 +0100, Rasmus Villemoes wrote:
>> On Thu, Jan 29 2015, Andy Shevchenko  
>> wrote:
>> 
>> >>   *
>> >>   * Return:
>> >> - * The amount of the characters processed to the destination buffer, or
>> >> - * %-ENOMEM if the size of buffer is not enough to put an escaped 
>> >> character is
>> >> - * returned.
>> >> - *
>> >> - * Even in the case of error @dst pointer will be updated to point to 
>> >> the byte
>> >> - * after the last processed character.
>> >> + * The total size of the escaped output that would be generated for
>> >> + * the given input and flags. To check whether the output was
>> >> + * truncated, compare the return value to osz. There is room left in
>> >> + * dst for a '\0' terminator if and only if ret < osz.
>> >>   */
>> >> -int string_escape_mem(const char *src, size_t isz, char **dst, size_t 
>> >> osz,
>> >> -   unsigned int flags, const char *esc)
>> >> +size_t string_escape_mem(const char *src, size_t isz, char *dst, size_t 
>> >> osz,
>> >> +  unsigned int flags, const char *esc)
>> >
>> > I prefer to leave the prototype the same. int for return is okay. dst
>> > should be updated accordingly.
>> 
>> Please explain exactly what you think the return value should be, and
>> what *dst should be set to.
>
> Return value like you proposed, *dst is incremented by it.

The more I think about it, the less I like having dst being char**.

(1) It is unlike most other functions taking buffer+size arguments.
(2) It is inconvenient. Callers doing

  char escaped[SOME_SIZE];

or

  char *escaped = kmalloc(likely_big_enough);

can't just pass  they would need to use an extra dummy variable.

(3) With the return value telling the size of the would-be generated
output, it is redundant.

In fact, I dislike it so much that I'm not going to sign off on a patch
where dst is still char**.

>> > Could it be a part of nomem test still?
>> 
>> What nomem test? string_escape_mem with snprintf-like semantics cannot
>> return an error; that has to be checked by the caller. 
>
> Make this code a separate test, which actually still nomem, since you
> have not enough memory in the destination buffer. What the problem to
> check for proper return value and the last couple of characters written
> to the destination buffer?

Sure, it could go into a separate helper. Anyway, the semantics of
string_escape_mem needs to be decided before it makes sense to update
the tests.

> When your series will be ready (and actually I recommend to push first
> patch apart from the rest since it's not related) 

I agree on that part. Andrew, could you take 1/3
(http://thread.gmane.org/gmane.linux.kernel/1876841/focus=348404), and
then we'll see when the %pE case gets sorted out.

Rasmus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: emxx_udc: Remove nbu2ss_drv_set_dp_info()

[Chris Rorvick]

On Fri, Jan 30, 2015 at 5:30 PM, Chris Rorvick  wrote:
> +
> +   ep->ep.maxpacket = (i == 0 ? EP0_PACKETSIZE : EP0_PACKETSIZE);
> +

Damn.  I looked this over twice before sending this and still only
noticed this stupid typo after sending it.  Will send a v2 shortly.

Sorry for the noise,

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86/smpboot: check if CLFLUSH is actually necessary

[Borislav Petkov]

On Fri, Jan 30, 2015 at 02:26:17PM -0700, Scotty Bauer wrote:
> mwait_play_dead previously issued a CLFLUSH to work around a bug on some xeon 
> processors. We can now determine if the CPU is a buggy CPU. This patch checks 
> if if we're on a buggy CPU which allows non-buggy cpu's to eliminate the 
> CLFLUSH.
> 
> 
> 
> 
> 

> From 3da1be5c998a8d51f98fdba09b3cb477526c5ff3 Mon Sep 17 00:00:00 2001
> From: Scott Bauer 
> Date: Fri, 30 Jan 2015 14:10:37 -0700
> Subject: [PATCH] Add check to determine if CLFLUSH is actually necessary
>  before monitor/wait
> 
> Signed-off-by: Scott Bauer 
> ---
>  arch/x86/kernel/smpboot.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 6d7022c..552ff48 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1384,6 +1384,7 @@ static inline void mwait_play_dead(void)
>   unsigned int highest_subcstate = 0;
>   void *mwait_ptr;
>   int i;
> + int cpu;
>  
>   if (!this_cpu_has(X86_FEATURE_MWAIT))
>   return;
> @@ -1420,6 +1421,7 @@ static inline void mwait_play_dead(void)
>* content is immaterial as it is not actually modified in any way.
>*/
>   mwait_ptr = _thread_info()->flags;
> + cpu = smp_processor_id();
>  
>   wbinvd();
>  
> @@ -1430,10 +1432,15 @@ static inline void mwait_play_dead(void)
>* needed, but it should be harmless in either case.
>* The WBINVD is insufficient due to the spurious-wakeup
>* case where we return around the loop.
> +  *
> +  * Check if the CLFLUSH is actually necessary before calling
>*/
> - mb();
> - clflush(mwait_ptr);
> - mb();
> + if (cpu_has_bug(_data(cpu), X86_BUG_CLFLUSH_MONITOR)) {
> + mb();
> + clflush(mwait_ptr);
> + mb();

Or you can so something even better:

alternative(ASM_NOP3, "clflush", X86_BUG_CLFLUSH_MONITOR);

Well, almost, you'd also need to pass in mwait_ptr, i.e. something like that:

https://lkml.kernel.org/r/1422377631-8986-3-git-send-email-ross.zwis...@linux.intel.com

but simpler. Maybe this:

asm volatile(ALTERNATIVE(ASM_NOP3, "clflush %[p]", 
X86_BUG_CLFLUSH_MONITOR)
  : [p] "+m" (*mwait_ptr));

Totally untested though - it is supposed to show the idea only.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: emxx_udc: Remove nbu2ss_drv_set_dp_info()

[Chris Rorvick]

This function is an awkward helper for nbu2ss_drv_ep_init().  Most of
its logic is devoted to determining if the current endpoint is ep0,
something the caller can easily do in a single line.  And there is not
a lot going on beyond that.

Move this logic up into nbu2ss_drv_ep_init().  The result is much easier
to understand and the resulting function is still viewable within a
single screen.

Signed-off-by: Chris Rorvick 
---
 drivers/staging/emxx_udc/emxx_udc.c | 52 ++---
 1 file changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index eb178fc..46864b0 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -3249,42 +3249,6 @@ static const char *gp_ep_name[NUM_ENDPOINTS] = {
 };
 
 /*-*/
-static void __init nbu2ss_drv_set_ep_info(
-   struct nbu2ss_udc   *udc,
-   struct nbu2ss_ep*ep,
-   const char *name)
-{
-   ep->udc = udc;
-   ep->desc = NULL;
-
-   ep->ep.driver_data = NULL;
-   ep->ep.name = name;
-   ep->ep.ops = _ep_ops;
-
-   if (isdigit(name[2])) {
-
-   longnum;
-   int res;
-   chartempbuf[2];
-
-   tempbuf[0] = name[2];
-   tempbuf[1] = '\0';
-   res = kstrtol(tempbuf, 16, );
-
-   if (num == 0)
-   ep->ep.maxpacket = EP0_PACKETSIZE;
-   else
-   ep->ep.maxpacket = EP_PACKETSIZE;
-
-   } else {
-   ep->ep.maxpacket = EP_PACKETSIZE;
-   }
-
-   list_add_tail(>ep.ep_list, >gadget.ep_list);
-   INIT_LIST_HEAD(>queue);
-}
-
-/*-*/
 static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc *udc)
 {
int i;
@@ -3292,9 +3256,21 @@ static void __init nbu2ss_drv_ep_init(struct nbu2ss_udc 
*udc)
INIT_LIST_HEAD(>gadget.ep_list);
udc->gadget.ep0 = >ep[0].ep;
 
+   for (i = 0; i < NUM_ENDPOINTS; i++) {
+   struct nbu2ss_ep *ep = >ep[i];
 
-   for (i = 0; i < NUM_ENDPOINTS; i++)
-   nbu2ss_drv_set_ep_info(udc, >ep[i], gp_ep_name[i]);
+   ep->udc = udc;
+   ep->desc = NULL;
+
+   ep->ep.driver_data = NULL;
+   ep->ep.name = gp_ep_name[i];
+   ep->ep.ops = _ep_ops;
+
+   ep->ep.maxpacket = (i == 0 ? EP0_PACKETSIZE : EP0_PACKETSIZE);
+
+   list_add_tail(>ep.ep_list, >gadget.ep_list);
+   INIT_LIST_HEAD(>queue);
+   }
 
list_del_init(>ep[0].ep.ep_list);
 }
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

[Bjorn Andersson]

On Fri, Jan 16, 2015 at 4:46 PM, Ohad Ben-Cohen  wrote:
> Mark,
>
> On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland  wrote:
>>> The hwlock is a basic hardware primitive that allow synchronization
>>> between different processors in the system, which may be running Linux
>>> as well as other operating systems, and may have no other means of
>>> communication.
>>>
>>> The hwlock id numbers are predefined, global and static across the
>>> entire system: Linux may boot well after other operating systems are
>>> already running and using these hwlocks to communicate, and therefore,
>>> in order to use these hardware devices, it must not enumerate them
>>> differently than the rest of the system.
>>
>> That's not true.
>>
>> In order to communicate it must agree with the other users as to the
>> meaning of each instance, and the protocol for use. That doesn't
>> necessarily mean that Linux needs to know the numerical ID from a
>> datasheet, and regardless that ID is separate from the logical ID Linux
>> uses internally.
>
> Let me describe hwspinlocks a bit more so we all get to know it better
> and can then agree on a proper solution.
>
> - What makes handling of hwspinlock ID numbers convenient is the fact
> that it's not based on random datasheet numbers. In fact, hwspinlocks
> is just special memory: usually datasheets just define the base
> address and the size of the hwspinlock area. So any numerical ID we
> use to call the locks themselves are already logical and sane, similar
> to the way we handle memory (i.e. if we have 32 locks we'll always use
> 0..31). So hwlocks ids are very much like memory addressing, and not
> irq numbers.
>

But that's exactly how irqs or gpios work as well. If you have 32
gpios in a system they used to be numbered 0-31 and people would
reference them directly by that number. Every one of the systems that
was designed in this way is moving away from it.

> - Sometimes Linux will have to dynamically allocate a hwlock, and send
> the ID of the allocated lock to a remote processor (which may not be
> running Linux).

In a system where you have two hwlock blocks lckA and lckB, each
consisting of 8 locks and you have dspB that can only access lckB;
will you tell the firmware engineers to always subtract 8 from the
numbers you pass them?

Wouldn't it make much more sense to have local indexes here and pass
them e.g lckB:2?

> - Sometimes a remote processor, which may not be running Linux, will
> have to dynamically allocate a hwlock, and send the ID of the
> allocated lock to us (another processor running Linux)
>

I'm sorry but you cannot have a system on both sides that is allowed
to do dynamic allocation from a limited set of resources.

Further more this dynamic allocation leads to interesting race
conditions as what happens if you dynamically allocate a hwlock that
is statically allocated by another part of the system?
The only solution I can think of is to have a static allocation of ids
that the dynamic allocator might use, and then we're just carrying
extra code when the system is already statically configured...

> We cannot tell in advance what kind of IPC is going to be used for
> sending and receiving this hwlock ID. Some are handled by Linux
> (kernel) and some by the user space. So we must be able to expose an
> ID the system will understand as well as receive one.
>

Designing this interface to take into consideration that someone might
send us something completely crazy isn't productive.


The only reason for having num-locks and base-id in device tree is
because of the current Linux implementation. base-id is not a property
of the hardware and num-locks is not needed for anything but book
keeping of base-id's in the hwlock framework.

This is why I preferred Sumans earlier suggestion of having the
binding consist of #hwlock-cells =  and the necessary accessor
functions for resolving a hwlock based on a dt reference.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] IRQ: don't suspend nested_thread irqs over system suspend.

[Rafael J. Wysocki]

On Saturday, January 31, 2015 12:06:37 AM Rafael J. Wysocki wrote:
> On Saturday, January 31, 2015 09:25:45 AM NeilBrown wrote:
> > 
> > Nested IRQs can only fire when the parent irq fires.
> > So when the parent is suspended, there is no need to suspend
> > the child irq.
> > 
> > Suspending nested irqs can cause a problem is they are suspended or
> > resumed in the wrong order.
> > If an interrupt fires while the parent is active but the child is
> > suspended, then the interrupt will not be acknowledged properly
> > and so an interrupt storm can result.
> > This is particularly likely if the parent is resumed before
> > the child, and the interrupt was raised during suspend.
> > 
> > Ensuring correct ordering would be possible, but it is simpler
> > to just never suspend nested interrupts.  This patch does that.
> 
> Clever. :-)
> 
> This is fine by me.  Thomas, what do you think?

It looks like I've overlooked a potential problem, though.

Can a nested interrupt be a wakeup one?  We won't set IRQD_WAKEUP_ARMED for it
then and may not handle wakeup correctly.

> > This patch allows the IRQF_EARLY_RESUME to be removed from
> > twl4030_sih_setup().  That flag attempts to fix the same problem
> > is a very different way, but causes
> > 
> > [   56.095825] WARNING: CPU: 0 PID: 3 at ../kernel/irq/manage.c:661 
> > irq_nested_primary_handler+0x18/0x28()
> > [   56.095825] Primary handler called for nested irq 348
> > 
> > warnings on resume.
> > 
> > Signed-off-by: NeilBrown 
> > 
> > diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> > index 3ca532592704..40cbcfb7fc43 100644
> > --- a/kernel/irq/pm.c
> > +++ b/kernel/irq/pm.c
> > @@ -118,6 +118,8 @@ void suspend_device_irqs(void)
> > unsigned long flags;
> > bool sync;
> >  
> > +   if (irq_settings_is_nested_thread(desc))
> > +   continue;
> > raw_spin_lock_irqsave(>lock, flags);
> > sync = suspend_device_irq(desc, irq);
> > raw_spin_unlock_irqrestore(>lock, flags);
> > @@ -158,6 +160,8 @@ static void resume_irqs(bool want_early)
> >  
> > if (!is_early && want_early)
> > continue;
> > +   if (irq_settings_is_nested_thread(desc))
> > +   continue;
> >  
> > raw_spin_lock_irqsave(>lock, flags);
> > resume_irq(desc, irq);
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v10 02/17] x86_64: add KASan support

[Andrey Ryabinin]

2015-01-31 0:37 GMT+03:00 Andrew Morton :
> On Fri, 30 Jan 2015 19:15:42 +0300 Andrey Ryabinin  
> wrote:
>
>> >> --- a/lib/Kconfig.kasan
>> >> +++ b/lib/Kconfig.kasan
>> >> @@ -5,6 +5,7 @@ if HAVE_ARCH_KASAN
>> >>
>> >>  config KASAN
>> >>bool "AddressSanitizer: runtime memory debugger"
>> >> +  depends on !MEMORY_HOTPLUG
>> >>help
>> >>  Enables address sanitizer - runtime memory debugger,
>> >>  designed to find out-of-bounds accesses and use-after-free bugs.
>> >
>> > That's a significant restriction.  It has obvious runtime implications.
>> > It also means that `make allmodconfig' and `make allyesconfig' don't
>> > enable kasan, so compile coverage will be impacted.
>> >
>> > This wasn't changelogged.  What's the reasoning and what has to be done
>> > to fix it?
>> >
>>
>> Yes, this is runtime dependency. Hot adding memory won't work.
>> Since we don't have shadow for hotplugged memory, kernel will crash on the 
>> first access to it.
>> To fix this we need to allocate shadow for new memory.
>>
>> Perhaps it would be better to have a runtime warning instead of Kconfig 
>> dependecy?
>
> Is there a plan to get mem-hotplug working with kasan, btw?  It doesn't
> strike me as very important/urgent.  Please add a sentence about this
> to the changelog as well.
>

I don't have a strict plan for this. I could work on this, but not now
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 3.19-rc4: Fix race condition in i.MX serial port driver

[Greg KH]

On Tue, Jan 13, 2015 at 05:07:08PM +0100, Michael Doswald wrote:
> Under pressure, the imx.c device driver may transfer the same data multiple
> times. 
> 
> Reason: 
> Function imx_dma_tx checks for an active DMA transfer by calling
> dmaengine_tx_status. The return value may indicate that no transfer is 
> running while the dma_tx_callback function is still being executed. In 
> this case the xmit->tail pointer may not be updated to the correct value 
> when imx_dma_tx initiates a new DMA transfer, which will result in a DMA
> transfer with the same base address as the previous one.
> 
> Patch:
> Use existing dma_is_txing variable to guard DMA transfer initiation instead
> of dmaengine_tx_status. Clear dma_is_txing at the end of the DMA callback
> function therefore extending the critical section where the port lock is
> held. Critical section extension is in line with the callback function 
> of other drivers, e.g. serial-tegra.c (tegra_uart_tx_dma_complete).
>  
>  
> Signed-off-by: Michael Doswald 
> ---
>  drivers/tty/serial/imx.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)

Fails to apply to my tree :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] tty: serial: 8250_core: Check that port->line is >=0

[Greg Kroah-Hartman]

On Thu, Jan 15, 2015 at 03:55:08PM +0100, Michal Simek wrote:
> This patch should be the part of:
> "tty: serial: 8250_core: use the ->line argument as a hint in
> serial8250_find_match_or_unused()"
> (sha1: 59b3e898ddfc81a65975043b5eb44103cc29ff6e)
> 

How can I go back in time and add a patch to another one?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] tty: serial: 8250_core: Remove trailing whitespaces

[Greg Kroah-Hartman]

On Thu, Jan 15, 2015 at 03:55:07PM +0100, Michal Simek wrote:
> No functional changes.
> 
> Signed-off-by: Michal Simek 
> ---

I can't take gpg-signed patches, git chokes on them :(

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: emxx_udc: emxx_udc: Removed variables that is never used

[Chris Rorvick]

On Fri, Jan 30, 2015 at 11:35 AM, Rickard Strandqvist
 wrote:
> 2015-01-30 15:20 GMT+01:00 Dan Carpenter :
>> Yes.  Please send that as a patch which can be applied.
>>
>> regards,
>> dan carpenter
>>
>
>
> Hi
>
> Okay, I'll do it this weekend.
> Or do you do it Chris?

I'll send out a patch removing nbu2ss_drv_set_dp_info() in a minute.
This only inflates the init function to a few more than 20 lines while
making the code far easier to understand.

Regards,

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 06/17] mm: slub: introduce metadata_access_enable()/metadata_access_disable()

[Andrey Ryabinin]

2015-01-31 2:16 GMT+03:00 Andrew Morton :
> On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin  
> wrote:
>
>> >> > kasan_disable_local/kasan_enable_local are also undocumented doesn't
>> >> > help.
>> >> >
>> >>
>> >> Ok, How about this?
>> >>
>> >> /*
>> >>  * This hooks separate payload access from metadata access.
>> >>  * Useful for memory checkers that have to know when slub
>> >>  * accesses metadata.
>> >>  */
>> >
>> > "These hooks".
>> >
>> > I still don't understand :( Maybe I'm having a more-stupid-than-usual
>> > day.
>>
>> I think it's me being stupid today ;) I'll try to explain better.
>>
>> > How can a function "separate access"?  What does this mean?  More
>> > details, please.  I think I've only once seen a comment which had too
>> > much info!
>> >
>>
>> slub could access memory marked by kasan as inaccessible (object's metadata).
>> Kasan shouldn't print report in that case because this access is valid.
>> Disabling instrumentation of slub.c code is not enough to achieve this
>> because slub passes pointer to object's metadata into memchr_inv().
>>
>> We can't disable instrumentation for memchr_inv() because this is quite
>> generic function.
>>
>> So metadata_access_enable/metadata_access_disable wrap some
>> places in slub.c where access to object's metadata starts/end.
>> And kasan_disable_local/kasan_enable_local just disable/enable
>> error reporting in this places.
>
> ooh, I see.  Something like this?
>

Yes! Thank you, this looks much better.

> /*
>  * slub is about to manipulate internal object metadata.  This memory lies
>  * outside the range of the allocated object, so accessing it would normally
>  * be reported by kasan as a bounds error.  metadata_access_enable() is used
>  * to tell kasan that these accesses are OK.
>  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 17/17] kasan: enable instrumentation of global variables

[Andrey Ryabinin]

2015-01-31 0:45 GMT+03:00 Andrew Morton :
> On Fri, 30 Jan 2015 20:47:13 +0300 Andrey Ryabinin  
> wrote:
>
>> >> +struct kasan_global {
>> >> +  const void *beg;/* Address of the beginning of the 
>> >> global variable. */
>> >> +  size_t size;/* Size of the global variable. */
>> >> +  size_t size_with_redzone;   /* Size of the variable + size of the 
>> >> red zone. 32 bytes aligned */
>> >> +  const void *name;
>> >> +  const void *module_name;/* Name of the module where the global 
>> >> variable is declared. */
>> >> +  unsigned long has_dynamic_init; /* This needed for C++ */
>> >
>> > This can be removed?
>> >
>>
>> No, compiler dictates layout of this struct. That probably deserves a 
>> comment.
>
> I see.  A link to the relevant gcc doc would be good.
>

There is no doc, only gcc source code.

> Perhaps the compiler provides a header file so clients of this feature
> don't need to write their own?
>

Nope.
Actually, we are the only client of this feature outside gcc code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 06/17] mm: slub: introduce metadata_access_enable()/metadata_access_disable()

[Andrew Morton]

On Sat, 31 Jan 2015 03:11:55 +0400 Andrey Ryabinin  
wrote:

> >> > kasan_disable_local/kasan_enable_local are also undocumented doesn't
> >> > help.
> >> >
> >>
> >> Ok, How about this?
> >>
> >> /*
> >>  * This hooks separate payload access from metadata access.
> >>  * Useful for memory checkers that have to know when slub
> >>  * accesses metadata.
> >>  */
> >
> > "These hooks".
> >
> > I still don't understand :( Maybe I'm having a more-stupid-than-usual
> > day.
> 
> I think it's me being stupid today ;) I'll try to explain better.
> 
> > How can a function "separate access"?  What does this mean?  More
> > details, please.  I think I've only once seen a comment which had too
> > much info!
> >
> 
> slub could access memory marked by kasan as inaccessible (object's metadata).
> Kasan shouldn't print report in that case because this access is valid.
> Disabling instrumentation of slub.c code is not enough to achieve this
> because slub passes pointer to object's metadata into memchr_inv().
> 
> We can't disable instrumentation for memchr_inv() because this is quite
> generic function.
> 
> So metadata_access_enable/metadata_access_disable wrap some
> places in slub.c where access to object's metadata starts/end.
> And kasan_disable_local/kasan_enable_local just disable/enable
> error reporting in this places.

ooh, I see.  Something like this?

/*
 * slub is about to manipulate internal object metadata.  This memory lies
 * outside the range of the allocated object, so accessing it would normally
 * be reported by kasan as a bounds error.  metadata_access_enable() is used
 * to tell kasan that these accesses are OK.
 */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 06/17] mm: slub: introduce metadata_access_enable()/metadata_access_disable()

[Andrey Ryabinin]

2015-01-31 0:42 GMT+03:00 Andrew Morton :
> On Fri, 30 Jan 2015 20:05:13 +0300 Andrey Ryabinin  
> wrote:
>
>> >> --- a/mm/slub.c
>> >> +++ b/mm/slub.c
>> >> @@ -467,13 +467,23 @@ static int slub_debug;
>> >>  static char *slub_debug_slabs;
>> >>  static int disable_higher_order_debug;
>> >>
>> >> +static inline void metadata_access_enable(void)
>> >> +{
>> >> +}
>> >> +
>> >> +static inline void metadata_access_disable(void)
>> >> +{
>> >> +}
>> >
>> > Some code comments here would be useful.  What they do, why they exist,
>> > etc.  The next patch fills them in with
>> > kasan_disable_local/kasan_enable_local but that doesn't help the reader
>> > to understand what's going on.  The fact that
>> > kasan_disable_local/kasan_enable_local are also undocumented doesn't
>> > help.
>> >
>>
>> Ok, How about this?
>>
>> /*
>>  * This hooks separate payload access from metadata access.
>>  * Useful for memory checkers that have to know when slub
>>  * accesses metadata.
>>  */
>
> "These hooks".
>
> I still don't understand :( Maybe I'm having a more-stupid-than-usual
> day.

I think it's me being stupid today ;) I'll try to explain better.

> How can a function "separate access"?  What does this mean?  More
> details, please.  I think I've only once seen a comment which had too
> much info!
>

slub could access memory marked by kasan as inaccessible (object's metadata).
Kasan shouldn't print report in that case because this access is valid.
Disabling instrumentation of slub.c code is not enough to achieve this
because slub passes pointer to object's metadata into memchr_inv().

We can't disable instrumentation for memchr_inv() because this is quite
generic function.

So metadata_access_enable/metadata_access_disable wrap some
places in slub.c where access to object's metadata starts/end.
And kasan_disable_local/kasan_enable_local just disable/enable
error reporting in this places.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] infiniband: Help gcc generate better code for ocrdma_srq_toggle_bit

[Rasmus Villemoes]

ping

On Fri, Jan 16 2015, Rasmus Villemoes  wrote:

> gcc emits a surprising amount of code in order to flip a bit. One
> would think that a single instruction is enough.
>
> $ scripts/bloat-o-meter /tmp/ocrdma_verbs.o 
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.o
> add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-142 (-142)
> function old new   delta
> ocrdma_post_srq_recv 498 460 -38
> ocrdma_poll_cq  20101962 -48
> ocrdma_discard_cqes  495 439 -56
>
> All three calls of ocrdma_srq_toggle_bit happen within spinlocks, so
> saving a few useless instructions might be worthwhile.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index fb8d8c4dfbb9..eff11e6c6183 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -1484,10 +1484,7 @@ static void ocrdma_srq_toggle_bit(struct ocrdma_srq 
> *srq, int idx)
>   int i = idx / 32;
>   unsigned int mask = (1 << (idx % 32));
>  
> - if (srq->idx_bit_fields[i] & mask)
> - srq->idx_bit_fields[i] &= ~mask;
> - else
> - srq->idx_bit_fields[i] |= mask;
> + srq->idx_bit_fields[i] ^= mask;
>  }
>  
>  static int ocrdma_hwq_free_cnt(struct ocrdma_qp_hwq_info *q)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm64: adding cpu lookup functionality

[mathieu . poirier]

From: Mathieu Poirier 

Adding a lookup function allowing for quick and easy mapping
between processor HWID (as found, for example) in DT specifications
and the CPU index known to the kernel.

Signed-off-by: Mathieu Poirier 
---
 arch/arm64/include/asm/smp_plat.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/include/asm/smp_plat.h 
b/arch/arm64/include/asm/smp_plat.h
index 59e282311b58..8e4b011303b1 100644
--- a/arch/arm64/include/asm/smp_plat.h
+++ b/arch/arm64/include/asm/smp_plat.h
@@ -19,6 +19,7 @@
 #ifndef __ASM_SMP_PLAT_H
 #define __ASM_SMP_PLAT_H
 
+#include 
 #include 
 
 struct mpidr_hash {
@@ -40,4 +41,15 @@ static inline u32 mpidr_hash_size(void)
 extern u64 __cpu_logical_map[NR_CPUS];
 #define cpu_logical_map(cpu)__cpu_logical_map[cpu]
 
+static inline int get_logical_index(u64 mpidr)
+{
+   int cpu;
+
+   for (cpu = 0; cpu < nr_cpu_ids; cpu++)
+   if (cpu_logical_map(cpu) == mpidr)
+   return cpu;
+   return -EINVAL;
+}
+
+
 #endif /* __ASM_SMP_PLAT_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Coresight Support for arm64

[mathieu . poirier]

From: Mathieu Poirier 

Other than tracers, the coresight IP blocks are 64-bit ready.  This
would normally be a trivial addition had it not been for the first
patch that is adding cpu index lookup functionality.

The feature exists in the 32 world and the fact that it doesn't on
64 bit means that 1) nobody needed it as of yet or 2) people have found
a different way to proceed.

Please have a look and tell me what you think.

Many thanks,
Mathieu

Mathieu Poirier (2):
  arm64: adding cpu lookup functionality
  coresight: Adding coresight support to arm64

 arch/arm64/Kconfig.debug| 48 +
 arch/arm64/include/asm/smp_plat.h   | 12 ++
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 4 files changed, 62 insertions(+), 2 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] coresight: Adding coresight support to arm64

[mathieu . poirier]

From: Mathieu Poirier 

Aside from tracers, all currently supported coresight IP blocks
are 64 bit ready.  As such add the required symbol definition to
compile the framework and drivers.

Also fixing a couple of warnings picked up by the 64bit compiler.

Signed-off-by: Mathieu Poirier 
---
 arch/arm64/Kconfig.debug| 48 +
 drivers/coresight/coresight-etb10.c |  2 +-
 drivers/coresight/coresight-tmc.c   |  2 +-
 3 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 5fdd6dce8061..77dfebbcbffe 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -66,4 +66,52 @@ config DEBUG_SET_MODULE_RONX
   against certain classes of kernel exploits.
   If in doubt, say "N".
 
+menuconfig CORESIGHT
+   bool "CoreSight Tracing Support"
+   select ARM_AMBA
+   help
+ This framework provides a kernel interface for the CoreSight debug
+ and trace drivers to register themselves with. It's intended to build
+ a topological view of the CoreSight components based on a DT
+ specification and configure the right serie of components when a
+ trace source gets enabled.
+
+if CORESIGHT
+config CORESIGHT_LINKS_AND_SINKS
+   bool "CoreSight Link and Sink drivers"
+   help
+ This enables support for CoreSight link and sink drivers that are
+ responsible for transporting and collecting the trace data
+ respectively.  Link and sinks are dynamically aggregated with a trace
+ entity at run time to form a complete trace path.
+
+config CORESIGHT_LINK_AND_SINK_TMC
+   bool "Coresight generic TMC driver"
+   depends on CORESIGHT_LINKS_AND_SINKS
+   help
+ This enables support for the Trace Memory Controller driver.
+ Depending on its configuration the device can act as a link (embedded
+ trace router - ETR) or sink (embedded trace FIFO).  The driver
+ complies with the generic implementation of the component without
+ special enhancement or added features.
+
+config CORESIGHT_SINK_TPIU
+   bool "Coresight generic TPIU driver"
+   depends on CORESIGHT_LINKS_AND_SINKS
+   help
+ This enables support for the Trace Port Interface Unit driver,
+ responsible for bridging the gap between the on-chip coresight
+ components and a trace for bridging the gap between the on-chip
+ coresight components and a trace port collection engine, typically
+ connected to an external host for use case capturing more traces than
+ the on-board coresight memory can handle.
+
+config CORESIGHT_SINK_ETBV10
+   bool "Coresight ETBv1.0 driver"
+   depends on CORESIGHT_LINKS_AND_SINKS
+   help
+ This enables support for the Embedded Trace Buffer version 1.0 driver
+ that complies with the generic implementation of the component without
+ special enhancement or added features.
+endif
 endmenu
diff --git a/drivers/coresight/coresight-etb10.c 
b/drivers/coresight/coresight-etb10.c
index c9acd406f0d0..aa47d31fe2a2 100644
--- a/drivers/coresight/coresight-etb10.c
+++ b/drivers/coresight/coresight-etb10.c
@@ -314,7 +314,7 @@ static ssize_t etb_read(struct file *file, char __user 
*data,
*ppos += len;
 
dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n",
-   __func__, len, (int) (depth * 4 - *ppos));
+   __func__, (int)len, (int)(depth * 4 - *ppos));
return len;
 }
 
diff --git a/drivers/coresight/coresight-tmc.c 
b/drivers/coresight/coresight-tmc.c
index 3ff232f9ddf7..d08460327bd2 100644
--- a/drivers/coresight/coresight-tmc.c
+++ b/drivers/coresight/coresight-tmc.c
@@ -534,7 +534,7 @@ static ssize_t tmc_read(struct file *file, char __user 
*data, size_t len,
*ppos += len;
 
dev_dbg(drvdata->dev, "%s: %d bytes copied, %d bytes left\n",
-   __func__, len, (int) (drvdata->size - *ppos));
+   __func__, (int)len, (int)(drvdata->size - *ppos));
return len;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: General protection fault in iscsi_rx_thread_pre_handler

[Nicholas A. Bellinger]

On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote:
> Hi Nicholas,
> 
> On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger
>  wrote:
> > On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote:
> >> Hi Nicolas,
> >>
> >> On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger
> >>  wrote:
> >> > Hi Gavin,
> >> >
> >> > On Thu, 2015-01-22 at 06:38 +0800, Gavin Guo wrote:
> >> >> Hi all,
> >> >>
> >> >> The general protection fault screenshot is attached.
> >> >>
> >> >> Summary:
> >> >> The kernel is Ubuntu-3.13.0-39.66. I've done basic analysis and found
> >> >> the fault is in list_del of iscsi_del_ts_from_active_list. And it
> >> >> looks like deleting the iscsi_thread_set *ts two times. The point to
> >> >> delete including iscsi_get_ts_from_inactive_list, was also checked but
> >> >> still can't find the clue. Really appreciate if anyone can provide any
> >> >> idea on the bug.
> >> >>
> >
> > 
> >
> >> >
> >> > Thanks for your detailed analysis.
> >> >
> >> > A similar bug was reported off-list some months back by a person using
> >> > iser-target + RoCE export on v3.12.y code.  Just to confirm, your
> >> > environment is using traditional iscsi-target + TCP export, right..?
> >>
> >> I am sorry that I'm not an expert of the field and already google RoCE
> >> on the internet but still don't really know what RoCE is. However, I
> >> can provide the informations.  We used iscsiadm on the initiator side
> >> and lio_node and tcm_node commands to create the targets for
> >> connection. I think it should be normal  iscsi-target using TCP
> >> export.
> >>
> >
> > Yep, that would be traditional iscsi-target + TCP export.
> >
> >> >
> >> > At the time, a different set of iser-target related changes ended up
> >> > avoiding this issue on his particular setup, so we thought it was likely
> >> > a race triggered by login failures specific to iser-target code.
> >> >
> >> > There was a untested patch (included inline below) to drop the legacy
> >> > active_ts_list usage all-together, but IIRC he was not able to reproduce
> >> > further so the patch didn't get picked up for mainline.
> >> >
> >> > If your able to reliability reproduce, please try with the following
> >> > patch and let us know your progress.
> >>
> >> Thanks for your time reading the mail. I'll let you know the result.
> >
> > Just curious, are you able to reliability reproduce this bug in a VM..?
> 
> Thanks for your caring, the machine is on the customer side, I've
> asked and now waiting for their response.

Hi Gavin,

Just curious if there has been any update on this yet..?

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] IRQ: don't suspend nested_thread irqs over system suspend.

[Rafael J. Wysocki]

On Saturday, January 31, 2015 09:25:45 AM NeilBrown wrote:
> 
> Nested IRQs can only fire when the parent irq fires.
> So when the parent is suspended, there is no need to suspend
> the child irq.
> 
> Suspending nested irqs can cause a problem is they are suspended or
> resumed in the wrong order.
> If an interrupt fires while the parent is active but the child is
> suspended, then the interrupt will not be acknowledged properly
> and so an interrupt storm can result.
> This is particularly likely if the parent is resumed before
> the child, and the interrupt was raised during suspend.
> 
> Ensuring correct ordering would be possible, but it is simpler
> to just never suspend nested interrupts.  This patch does that.

Clever. :-)

This is fine by me.  Thomas, what do you think?

> This patch allows the IRQF_EARLY_RESUME to be removed from
> twl4030_sih_setup().  That flag attempts to fix the same problem
> is a very different way, but causes
> 
> [   56.095825] WARNING: CPU: 0 PID: 3 at ../kernel/irq/manage.c:661 
> irq_nested_primary_handler+0x18/0x28()
> [   56.095825] Primary handler called for nested irq 348
> 
> warnings on resume.
> 
> Signed-off-by: NeilBrown 
> 
> diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
> index 3ca532592704..40cbcfb7fc43 100644
> --- a/kernel/irq/pm.c
> +++ b/kernel/irq/pm.c
> @@ -118,6 +118,8 @@ void suspend_device_irqs(void)
>   unsigned long flags;
>   bool sync;
>  
> + if (irq_settings_is_nested_thread(desc))
> + continue;
>   raw_spin_lock_irqsave(>lock, flags);
>   sync = suspend_device_irq(desc, irq);
>   raw_spin_unlock_irqrestore(>lock, flags);
> @@ -158,6 +160,8 @@ static void resume_irqs(bool want_early)
>  
>   if (!is_early && want_early)
>   continue;
> + if (irq_settings_is_nested_thread(desc))
> + continue;
>  
>   raw_spin_lock_irqsave(>lock, flags);
>   resume_irq(desc, irq);

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

signature.asc
Description: This is a digitally signed message part.

[PATCH 1/1 linux-next] task IO accounting: add conditional read/write counters

[Fabian Frederick]

This patch adds syscre and syscwe respectively effective read/write
syscall counters. We already had syscr/syscw which were
unconditionally incremented. Doing the difference between those
variables could give interesting statistics.

Signed-off-by: Fabian Frederick 
---
 Documentation/filesystems/proc.txt | 16 
 fs/proc/base.c |  4 
 include/linux/sched.h  |  2 ++
 include/linux/task_io_accounting.h |  4 
 4 files changed, 26 insertions(+)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index a07ba61..87f32d8 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1536,6 +1536,22 @@ I/O counter: write syscalls
 Attempt to count the number of write I/O operations, i.e. syscalls like
 write() and pwrite().
 
+syscre
+--
+
+I/O counter: Effective read syscalls
+Attempt to count the number of effective read I/O operations,
+i.e. syscalls like read() and pread().
+
+
+syscwe
+--
+
+I/O counter: Effective write syscalls
+Attempt to count the number of effective write I/O operations,
+i.e. syscalls like read() and pread().
+
+
 
 read_bytes
 --
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3f3d7ae..fad6a3f 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2357,6 +2357,8 @@ static int do_io_accounting(struct task_struct *task, 
struct seq_file *m, int wh
"wchar: %llu\n"
"syscr: %llu\n"
"syscw: %llu\n"
+   "syscre: %llu\n"
+   "syscwe: %llu\n"
"read_bytes: %llu\n"
"write_bytes: %llu\n"
"cancelled_write_bytes: %llu\n",
@@ -2364,6 +2366,8 @@ static int do_io_accounting(struct task_struct *task, 
struct seq_file *m, int wh
(unsigned long long)acct.wchar,
(unsigned long long)acct.syscr,
(unsigned long long)acct.syscw,
+   (unsigned long long)acct.syscre,
+   (unsigned long long)acct.syscwe,
(unsigned long long)acct.read_bytes,
(unsigned long long)acct.write_bytes,
(unsigned long long)acct.cancelled_write_bytes);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 22ee0d5..27519ae 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3012,11 +3012,13 @@ extern int task_can_switch_user(struct user_struct *up,
 #ifdef CONFIG_TASK_XACCT
 static inline void add_rchar(struct task_struct *tsk, ssize_t amt)
 {
+   tsk->ioac.syscre++;
tsk->ioac.rchar += amt;
 }
 
 static inline void add_wchar(struct task_struct *tsk, ssize_t amt)
 {
+   tsk->ioac.syscwe++;
tsk->ioac.wchar += amt;
 }
 
diff --git a/include/linux/task_io_accounting.h 
b/include/linux/task_io_accounting.h
index bdf855c..bc94291 100644
--- a/include/linux/task_io_accounting.h
+++ b/include/linux/task_io_accounting.h
@@ -18,6 +18,10 @@ struct task_io_accounting {
u64 syscr;
/* # of write syscalls */
u64 syscw;
+   /* # of effective read syscalls */
+   u64 syscre;
+   /* # of effective write syscalls */
+   u64 syscwe;
 #endif /* CONFIG_TASK_XACCT */
 
 #ifdef CONFIG_TASK_IO_ACCOUNTING
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pci-dma: Fix x86 dma_alloc_coherent to fully clear all pages returned

[Andi Kleen]

> We don't "need" any backward compatility, why not fix the broken drivers
> that are using memory outside of what they are asking for?  That's not
> ok no matter what, right?

How would you find them all?

We don't even know which place in XHCI is the culprit here.

Yes iff you can find them it would be good to fix.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support (V2)

[Bjorn Andersson]

On Fri, Jan 30, 2015 at 1:51 PM, Bjorn Andersson  wrote:
> On Tue, Jan 13, 2015 at 12:43 PM, Jilai Wang  wrote:
>> Add HDMI HDCP support including HDCP PartI/II/III authentication.
>> V1: Initial Change
>> V2: Address Bjorn's comments
>> Refactor the authentication process to use single work instead
>> of multiple work for different authentication stages.
>>
> Looks cleaner and the SCM parts look good now.
>
> But the ddc communication still makes me wonder, see below.
>

Rob made me aware about the fact that the hdmi driver is both
implementing a driver for the i2c controller and now for the hdcp
client and hence doesn't have an i2c_client handle.

So unless this is redesigned to be split in a separate i2c client
driver we probably have to have the ddc functions like this.

I'm fine with this as is for now.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] mmc: core: allow non-blocking form of mmc_claim_host

[NeilBrown]

Change the handling for the 'abort' flag so that if
it is set, but we can claim the host, then do the claim,
rather than aborting.

When the abort is async this just means that a race between aborting
an allowing a claim is resolved slightly differently.  Any
code must already be able to handle 'abort' being set just as the host
is claimed.

This allows extra functionality.  If __mmc_claim_host() is called
with an 'abort' pointer which is initialized to '1', it will effect a
non-blocking 'claim'.

Signed-off-by: NeilBrown 
---
 drivers/mmc/core/core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index e9eb721e3664..051198073d21 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -912,10 +912,11 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t 
*abort)
spin_lock_irqsave(>lock, flags);
}
set_current_state(TASK_RUNNING);
-   if (!stop) {
+   if (!host->claimed || host->claimer == current) {
host->claimed = 1;
host->claimer = current;
host->claim_cnt += 1;
+   stop = 0;
} else
wake_up(>wq);
spin_unlock_irqrestore(>lock, flags);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] mmc: sdio: support switching to 1-bit before turning off clocks

[NeilBrown]

According to section 7.1.2 of

http://www.sandisk.com/media/File/OEM/Manuals/SD_SDIO_specsv1.pdf

In the case where the interrupt mechanism is used to wake the host while
the card is in a low power state (i.e. no clocks), Both the card and the
host shall be placed into the 1-bit SD mode prior to stopping the clock.


This is particularly important for the Marvell "libertas" wifi chip
in the GTA04.  While in 4-bit mode it will only signal an interrupt
when the clock is running (which is why setting CLKEXTFREE is
important in omap_hsmmc).
In 1-bit mode, the interrupt is asynchronous (explained in OMAP3
TRM description of the CIRQ flag to MMCHS_STAT:

  In 1-bit mode, interrupt source is asynchronous (can be a source of
  asynchronous wakeup).
  In 4-bit mode, interrupt source is sampled during the interrupt
  cycle.

)

It is awkward to simply set 1-bit mode in ->runtime_suspend
as that will call mmc_set_ios which calls ops->set_ios(),
which will likely call pm_runtime_get_sync(), on the device that
is currently suspending.  This deadlocks.

So:
 - create a work_struct to schedule setting of 1-bit mode
 - introduce an 'sdio_narrowed' state flag which transitions:
 0 (normal) -> 1 (convert to 1-bit pending) ->
 2 (have switch to 1-bit mode) -> 0 (normal)
 - create a function mmc_sdio_want_no_clocks() which can be called
   when the driver wants to turn off clocks (presumably after an
   idle timeout).  This either succeeds (in 1-bit mode) or fails
   and schedules the work to switch to 1-bit mode.
 - when the host is claimed, if sdio_narrowed is 2, restore the
   4-bit bus
 - When the host is released, if sdio_narrowed is 1, then some
   caller other  than our worker claimed the host first, so
   clear sdio_narrowed.

This all allows a graceful and race-free switch to 1-bit mode
before switching off the clocks, if SDIO interrupts are enabled.

A host should call mmc_sdio_want_no_clocks() when about to turn of
clocks if sdio interrupts are enabled, and the ->disable() function
should not use a timeout (pm_runtime_put_autosuspend) if
->sdio_narrowed is 2.

Signed-off-by: NeilBrown 
---
 drivers/mmc/core/core.c  |   18 ++
 drivers/mmc/core/sdio.c  |   42 +-
 include/linux/mmc/core.h |2 ++
 include/linux/mmc/host.h |2 ++
 4 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 051198073d21..21068fe75c30 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -921,8 +921,14 @@ int __mmc_claim_host(struct mmc_host *host, atomic_t 
*abort)
wake_up(>wq);
spin_unlock_irqrestore(>lock, flags);
remove_wait_queue(>wq, );
-   if (host->ops->enable && !stop && host->claim_cnt == 1)
-   host->ops->enable(host);
+   if (!stop && host->claim_cnt == 1) {
+   if (host->ops->enable)
+   host->ops->enable(host);
+   if (atomic_read(>sdio_narrowed) == 2) {
+   sdio_enable_4bit_bus(host->card);
+   atomic_set(>sdio_narrowed, 0);
+   }
+   }
return stop;
 }
 
@@ -941,8 +947,12 @@ void mmc_release_host(struct mmc_host *host)
 
WARN_ON(!host->claimed);
 
-   if (host->ops->disable && host->claim_cnt == 1)
-   host->ops->disable(host);
+   if (host->claim_cnt == 1) {
+   if (atomic_read(>sdio_narrowed) == 1)
+   atomic_set(>sdio_narrowed, 0);
+   if (host->ops->disable)
+   host->ops->disable(host);
+   }
 
spin_lock_irqsave(>lock, flags);
if (--host->claim_cnt) {
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 5bc6c7dbbd60..9761e4d5f49b 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -288,7 +288,7 @@ static int sdio_disable_wide(struct mmc_card *card)
 }
 
 
-static int sdio_enable_4bit_bus(struct mmc_card *card)
+int sdio_enable_4bit_bus(struct mmc_card *card)
 {
int err;
 
@@ -313,6 +313,45 @@ static int sdio_enable_4bit_bus(struct mmc_card *card)
return err;
 }
 
+static void mmc_sdio_width_work(struct work_struct *work)
+{
+   struct mmc_host *host = container_of(work, struct mmc_host,
+sdio_width_work);
+   atomic_t noblock;
+
+   atomic_set(, 1);
+   if (__mmc_claim_host(host, ))
+   return;
+   if (atomic_read(>sdio_narrowed) != 1) {
+   /* Nothing to do */
+   mmc_release_host(host);
+   return;
+   }
+   if (sdio_disable_wide(host->card) == 0)
+   atomic_set(>sdio_narrowed, 2);
+   else
+   atomic_set(>sdio_narrowed, 0);
+   mmc_release_host(host);
+}
+
+int mmc_sdio_want_no_clocks(struct mmc_host *host)
+{
+   if (!(host->caps & MMC_CAP_SDIO_IRQ) ||
+   host->ios.bus_width == 

[PATCH 4/4] mmc: omap_hsmmc: switch to 1-bit before stopping clocks.

[NeilBrown]

Make use of the new mmc_sdio_want_no_clocks() call to avoid stopping
clocks while SD Card interrupts are enabled and we aren't in
1-bit mode.

Also stop clocks immediately in omap_hsmmc_disable_fclk() if
1-bit mode has been entered for this purpose.

With this, I can use my libertas wifi with a 4-bit bus, with
interrupts and runtime power-management enabled, and get around
14Mb/sec throughput (which is the best I've seen).

Signed-off-by: NeilBrown 
---
 drivers/mmc/host/omap_hsmmc.c |   13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb01716d..14fce3b92633 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1791,9 +1791,12 @@ static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
 {
struct omap_hsmmc_host *host = mmc_priv(mmc);
 
-   pm_runtime_mark_last_busy(host->dev);
-   pm_runtime_put_autosuspend(host->dev);
-
+   if (atomic_read(>sdio_narrowed) == 2)
+   pm_runtime_put_sync(host->dev);
+   else {
+   pm_runtime_mark_last_busy(host->dev);
+   pm_runtime_put_autosuspend(host->dev);
+   }
return 0;
 }
 
@@ -2311,6 +2314,10 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
spin_lock_irqsave(>irq_lock, flags);
if ((host->mmc->caps & MMC_CAP_SDIO_IRQ) &&
(host->flags & HSMMC_SDIO_IRQ_ENABLED)) {
+   if (mmc_sdio_want_no_clocks(host->mmc) == 0) {
+   ret = -EBUSY;
+   goto abort;
+   }
/* disable sdio irq handling to prevent race */
OMAP_HSMMC_WRITE(host->base, ISE, 0);
OMAP_HSMMC_WRITE(host->base, IE, 0);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH-v2 0/4] mmc: switch to 1-bit mode which stopping clocks.

[NeilBrown]

This is a new version which moves most of the code into
mmc/core so it is available to all drivers.

I was wrong about not being able to sleep in pm_runtime callbacks.
There are spinlocks, but not the ones I thought they were...

Anyway, I tried switching to 1-bit mode from within the
runtime_suspend callback and hit a different problem.
The sequence to switch to 1-bit involves calling set_ios
which, for omap_hsmmc at least, calls pm_runtime_get_sync().

Calling pm_runtime_get_sync from the runtime_suspend callback
deadlocks.

It would be possible to remove the pm_runtime_get_sync call
from set_ios() functions, and instead call host->enable(),
host->disable() around those mmc_set_ios() calls which don't
have the host claimed.  However that seems a bit fragile to me.

So for now I'm persisting with doing the width change from
a work-queue.  This set of patches does that.

If you think calling host->enable/disable around mmc_set_ios() calls
does make sense, I can post my other patch for review.

Thanks,
NeilBrown


---

NeilBrown (4):
  mmc: core: fold mmc_set_bus_width calls into sdio_enable_4bit_bus.
  mmc: core: allow non-blocking form of mmc_claim_host
  mmc: sdio: support switching to 1-bit before turning off clocks
  mmc: omap_hsmmc: switch to 1-bit before stopping clocks.


 drivers/mmc/core/core.c   |   21 +---
 drivers/mmc/core/sdio.c   |   74 +
 drivers/mmc/host/omap_hsmmc.c |   13 ++-
 include/linux/mmc/core.h  |2 +
 include/linux/mmc/host.h  |2 +
 5 files changed, 83 insertions(+), 29 deletions(-)

--
Signature

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] mmc: core: fold mmc_set_bus_width calls into sdio_enable_4bit_bus.

[NeilBrown]

Every call to sdio_enable_4bit_bus is followed (on success) but a call
to mmc_set_bus_width().

To simplify the code, include those calls directly in
sdio_enable_4bit_bus().

Signed-off-by: NeilBrown 
---
 drivers/mmc/core/sdio.c |   32 
 1 file changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index ce6cc47206b0..5bc6c7dbbd60 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -293,19 +293,22 @@ static int sdio_enable_4bit_bus(struct mmc_card *card)
int err;
 
if (card->type == MMC_TYPE_SDIO)
-   return sdio_enable_wide(card);
-
-   if ((card->host->caps & MMC_CAP_4_BIT_DATA) &&
-   (card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
+   err = sdio_enable_wide(card);
+   else if ((card->host->caps & MMC_CAP_4_BIT_DATA) &&
+(card->scr.bus_widths & SD_SCR_BUS_WIDTH_4)) {
err = mmc_app_set_bus_width(card, MMC_BUS_WIDTH_4);
if (err)
return err;
+   err = sdio_enable_wide(card);
+   if (err <= 0)
+   mmc_app_set_bus_width(card, MMC_BUS_WIDTH_1);
} else
return 0;
 
-   err = sdio_enable_wide(card);
-   if (err <= 0)
-   mmc_app_set_bus_width(card, MMC_BUS_WIDTH_1);
+   if (err > 0) {
+   mmc_set_bus_width(card->host, MMC_BUS_WIDTH_4);
+   err = 0;
+   }
 
return err;
 }
@@ -547,13 +550,8 @@ static int mmc_sdio_init_uhs_card(struct mmc_card *card)
/*
 * Switch to wider bus (if supported).
 */
-   if (card->host->caps & MMC_CAP_4_BIT_DATA) {
+   if (card->host->caps & MMC_CAP_4_BIT_DATA)
err = sdio_enable_4bit_bus(card);
-   if (err > 0) {
-   mmc_set_bus_width(card->host, MMC_BUS_WIDTH_4);
-   err = 0;
-   }
-   }
 
/* Set the driver strength for the card */
sdio_select_driver_type(card);
@@ -803,9 +801,7 @@ try_again:
 * Switch to wider bus (if supported).
 */
err = sdio_enable_4bit_bus(card);
-   if (err > 0)
-   mmc_set_bus_width(card->host, MMC_BUS_WIDTH_4);
-   else if (err)
+   if (err)
goto remove;
}
 finish:
@@ -983,10 +979,6 @@ static int mmc_sdio_resume(struct mmc_host *host)
} else if (mmc_card_keep_power(host) && mmc_card_wake_sdio_irq(host)) {
/* We may have switched to 1-bit mode during suspend */
err = sdio_enable_4bit_bus(host->card);
-   if (err > 0) {
-   mmc_set_bus_width(host, MMC_BUS_WIDTH_4);
-   err = 0;
-   }
}
 
if (!err && host->sdio_irqs) {


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] IRQ: don't suspend nested_thread irqs over system suspend.

[NeilBrown]

Nested IRQs can only fire when the parent irq fires.
So when the parent is suspended, there is no need to suspend
the child irq.

Suspending nested irqs can cause a problem is they are suspended or
resumed in the wrong order.
If an interrupt fires while the parent is active but the child is
suspended, then the interrupt will not be acknowledged properly
and so an interrupt storm can result.
This is particularly likely if the parent is resumed before
the child, and the interrupt was raised during suspend.

Ensuring correct ordering would be possible, but it is simpler
to just never suspend nested interrupts.  This patch does that.

This patch allows the IRQF_EARLY_RESUME to be removed from
twl4030_sih_setup().  That flag attempts to fix the same problem
is a very different way, but causes

[   56.095825] WARNING: CPU: 0 PID: 3 at ../kernel/irq/manage.c:661 
irq_nested_primary_handler+0x18/0x28()
[   56.095825] Primary handler called for nested irq 348

warnings on resume.

Signed-off-by: NeilBrown 

diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 3ca532592704..40cbcfb7fc43 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -118,6 +118,8 @@ void suspend_device_irqs(void)
unsigned long flags;
bool sync;
 
+   if (irq_settings_is_nested_thread(desc))
+   continue;
raw_spin_lock_irqsave(>lock, flags);
sync = suspend_device_irq(desc, irq);
raw_spin_unlock_irqrestore(>lock, flags);
@@ -158,6 +160,8 @@ static void resume_irqs(bool want_early)
 
if (!is_early && want_early)
continue;
+   if (irq_settings_is_nested_thread(desc))
+   continue;
 
raw_spin_lock_irqsave(>lock, flags);
resume_irq(desc, irq);


pgpVFs49s6VGE.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 2/4] gpio: add parameter to allow the use named gpios

[Dmitry Torokhov]

On Fri, Jan 30, 2015 at 02:16:00PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 30, 2015 at 11:12:53AM -0800, Bryan Wu wrote:
> > On Fri, Jan 30, 2015 at 5:46 AM, Linus Walleij  
> > wrote:
> > > On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl
> > >  wrote:
> > >
> > >> From: Olliver Schinagl 
> > >>
> > >> The gpio binding document says that new code should always use named
> > >> gpios. Patch 40b73183 added support to parse a list of gpios from child
> > >> nodes, but does not make it possible to use named gpios. This patch adds
> > >> the con_id property and implements it is done in gpiolib.c, where the
> > >> old-style of using unnamed gpios still works.
> > >>
> > >> Signed-off-by: Olliver Schinagl 
> > >> ---
> > >>  drivers/gpio/devres.c | 18 +-
> > >>  drivers/input/keyboard/gpio_keys_polled.c |  2 +-
> > >>  drivers/leds/leds-gpio.c  |  2 +-
> > >>  include/linux/gpio/consumer.h |  1 +
> > >
> > > Alexandre: does this match your vision of how it should work, i.e. ACK?
> > >
> > > Bryan/Dmitry: can you ACK the oneliners in your subsystems?
> > 
> > Sure, please take my Ack
> > Acked-by: Bryan Wu 
> 
> Mine as well:
> 
> Acked-by: Dmitry Torokhov 

Forgot to mention: the ack is for this patch only; the patch #4 is
NAKed because:

1. The logic of handling old and new name AFAICS is broken and
2. gpio_keys_polled-gpios as name is plain ugly.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/