Re: [PATCH 7/8] ASoC: atmel: document clock properties of the wm8904 driver

[Bo Shen]

Hi Mark,

On 03/17/2014 07:55 PM, Mark Brown wrote:

On Mon, Mar 17, 2014 at 05:45:40PM +0800, Bo Shen wrote:


- compatible: "atmel,asoc-wm8904"
- atmel,model: The user-visible name of this sound complex.
+  - clocks: A list of clocks needed by the wm8904 chip.
+  - clock-output-names: Driver related clock names. Shall contain "pck0".


If this is a clock for the CODEC it should be documented as part of the
binding for the CODEC and connected to the CODEC in the device tree
rather than being part of a machine driver binding.


This is a optional clock for CODEC which depends on hardware design. 
There are 3 options for this clock, wm8904 as an example.

1. Using internal FLL, so won't use this clock.
2. Using external oscillator, no need to retrieve this clock.
3. Using SoC provide this clock (we use this case).

After considering these 3 options, if we put this into CODEC driver to 
do it, I think it will be more complicate to do logic judgement. Do you 
think so?


And, in machine driver, it will depends on the clock option to decide 
whether to call snd_soc_dai_set_pll and snd_soc_dai_set_sysclk.


And also the  mentions the 
machine drivers responsibility (one is for clocking) as following:

--->8---
The ASoC machine (or board) driver is the code that glues together all the
component drivers (e.g. codecs, platforms and DAIs). It also describes the
relationships between each componnent which include audio paths, GPIOs,
interrupts, clocking, jacks and voltage regulators.
---8<---

So, I think put this into machine driver will be better. Do you have any 
other idea? Or if I misunderstand something, please point it out.


Thanks.

Best Regards,
Bo Shen
--
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/

linux-next: manual merge of the random tree with Linus' tree

[Stephen Rothwell]

Hi Theodore,

Today's linux-next merge of the random tree got a conflict in
arch/x86/include/asm/archrandom.h between commit 5bfce5ef55cb ("x86,
kaslr: Provide randomness functions") from Linus' tree and commits
e3be36e60bdc ("x86, random: Enable the RDSEED instruction") and
91a60dc7aa88 ("random: Add arch_has_random[_seed]()") from the random tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc arch/x86/include/asm/archrandom.h
index e6a92455740e,c7ed4a61e928..
--- a/arch/x86/include/asm/archrandom.h
+++ b/arch/x86/include/asm/archrandom.h
@@@ -39,20 -42,16 +42,30 @@@
  
  #ifdef CONFIG_ARCH_RANDOM
  
 +/* Instead of arch_get_random_long() when alternatives haven't run. */
 +static inline int rdrand_long(unsigned long *v)
 +{
 +  int ok;
 +  asm volatile("1: " RDRAND_LONG "\n\t"
 +   "jc 2f\n\t"
 +   "decl %0\n\t"
 +   "jnz 1b\n\t"
 +   "2:"
 +   : "=r" (ok), "=a" (*v)
 +   : "0" (RDRAND_RETRY_LOOPS));
 +  return ok;
 +}
 +
+ /* A single attempt at RDSEED */
+ static inline bool rdseed_long(unsigned long *v)
+ {
+   unsigned char ok;
+   asm volatile(RDSEED_LONG "\n\t"
+"setc %0"
+: "=qm" (ok), "=a" (*v));
+   return ok;
+ }
+ 
  #define GET_RANDOM(name, type, rdrand, nop)   \
  static inline int name(type *v)   \
  { \
@@@ -80,15 -95,14 +109,21 @@@ GET_SEED(arch_get_random_seed_int, unsi
  GET_RANDOM(arch_get_random_long, unsigned long, RDRAND_LONG, ASM_NOP3);
  GET_RANDOM(arch_get_random_int, unsigned int, RDRAND_INT, ASM_NOP3);
  
+ GET_SEED(arch_get_random_seed_long, unsigned long, RDSEED_LONG, ASM_NOP4);
+ GET_SEED(arch_get_random_seed_int, unsigned int, RDSEED_INT, ASM_NOP4);
+ 
  #endif /* CONFIG_X86_64 */
  
+ #define arch_has_random() static_cpu_has(X86_FEATURE_RDRAND)
+ #define arch_has_random_seed()static_cpu_has(X86_FEATURE_RDSEED)
+ 
 +#else
 +
 +static inline int rdrand_long(unsigned long *v)
 +{
 +  return 0;
 +}
 +
  #endif  /* CONFIG_ARCH_RANDOM */
  
  extern void x86_init_rdrand(struct cpuinfo_x86 *c);


pgpucwbxrLs8X.pgp
Description: PGP signature

[PATCH] cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}

[Viresh Kumar]

Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE were unused
since sometime. And so better remove them to clean code a bit.

Signed-off-by: Viresh Kumar 
---
 Documentation/cpu-freq/core.txt   | 4 
 arch/arm/kernel/smp.c | 3 +--
 arch/arm/kernel/smp_twd.c | 2 +-
 arch/arm/mach-pxa/viper.c | 3 ---
 arch/powerpc/oprofile/op_model_cell.c | 3 +--
 arch/sparc/kernel/time_64.c   | 3 +--
 arch/x86/kernel/tsc.c | 3 +--
 drivers/cpufreq/cpufreq.c | 3 +--
 drivers/pcmcia/sa11xx_base.c  | 3 ---
 drivers/tty/serial/sh-sci.c   | 3 +--
 include/linux/cpufreq.h   | 2 --
 11 files changed, 7 insertions(+), 25 deletions(-)

diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index ce0666e..0060d76 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -92,7 +92,3 @@ values:
 cpu- number of the affected CPU
 old- old frequency
 new- new frequency
-
-If the cpufreq core detects the frequency has changed while the system
-was suspended, these notifiers are called with CPUFREQ_RESUMECHANGE as
-second argument.
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index b7b4c86..7c4fada 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -674,8 +674,7 @@ static int cpufreq_callback(struct notifier_block *nb,
}
 
if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
-   (val == CPUFREQ_POSTCHANGE && freq->old > freq->new) ||
-   (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE)) {
+   (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
loops_per_jiffy = cpufreq_scale(global_l_p_j_ref,
global_l_p_j_ref_freq,
freq->new);
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 6591e26..dfc3213 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -166,7 +166,7 @@ static int twd_cpufreq_transition(struct notifier_block *nb,
 * frequency.  The timer is local to a cpu, so cross-call to the
 * changing cpu.
 */
-   if (state == CPUFREQ_POSTCHANGE || state == CPUFREQ_RESUMECHANGE)
+   if (state == CPUFREQ_POSTCHANGE)
smp_call_function_single(freqs->cpu, twd_update_frequency,
NULL, 1);
 
diff --git a/arch/arm/mach-pxa/viper.c b/arch/arm/mach-pxa/viper.c
index 29905b1..41f27f6 100644
--- a/arch/arm/mach-pxa/viper.c
+++ b/arch/arm/mach-pxa/viper.c
@@ -885,9 +885,6 @@ static int viper_cpufreq_notifier(struct notifier_block *nb,
viper_set_core_cpu_voltage(freq->new, 0);
}
break;
-   case CPUFREQ_RESUMECHANGE:
-   viper_set_core_cpu_voltage(freq->new, 0);
-   break;
default:
/* ignore */
break;
diff --git a/arch/powerpc/oprofile/op_model_cell.c 
b/arch/powerpc/oprofile/op_model_cell.c
index 1f0ebde..863d893 100644
--- a/arch/powerpc/oprofile/op_model_cell.c
+++ b/arch/powerpc/oprofile/op_model_cell.c
@@ -1121,8 +1121,7 @@ oprof_cpufreq_notify(struct notifier_block *nb, unsigned 
long val, void *data)
int ret = 0;
struct cpufreq_freqs *frq = data;
if ((val == CPUFREQ_PRECHANGE && frq->old < frq->new) ||
-   (val == CPUFREQ_POSTCHANGE && frq->old > frq->new) ||
-   (val == CPUFREQ_RESUMECHANGE || val == CPUFREQ_SUSPENDCHANGE))
+   (val == CPUFREQ_POSTCHANGE && frq->old > frq->new))
set_spu_profiling_frequency(frq->new, spu_cycle_reset);
return ret;
 }
diff --git a/arch/sparc/kernel/time_64.c b/arch/sparc/kernel/time_64.c
index c3d82b5..b397e05 100644
--- a/arch/sparc/kernel/time_64.c
+++ b/arch/sparc/kernel/time_64.c
@@ -659,8 +659,7 @@ static int sparc64_cpufreq_notifier(struct notifier_block 
*nb, unsigned long val
ft->clock_tick_ref = cpu_data(cpu).clock_tick;
}
if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
-   (val == CPUFREQ_POSTCHANGE && freq->old > freq->new) ||
-   (val == CPUFREQ_RESUMECHANGE)) {
+   (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
cpu_data(cpu).clock_tick =
cpufreq_scale(ft->clock_tick_ref,
  ft->ref_freq,
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfbe99f..7a9296a 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -914,8 +914,7 @@ static int time_cpufreq_notifier(struct notifier_block *nb, 
unsigned long val,
tsc_khz_ref = tsc_khz;
}
if ((val == CPUFREQ_PRECHANGE  && freq->old < freq->new) ||
-   (val == CPUFREQ_POSTCHANGE && freq->old > freq->new) ||
-   (val == 

Re: [firefly] [PATCH] staging: cxt1e1: hwprobe: Fix sparse warning

[Daniel Baluta]

>> Signed-off-by: Matei Oprea 
>> Cc: ROSEdu Kernel Community 
>
> Why the cc: for a non-maintainer / person?

We try to keep track of student's contributions in this way.
Also, patches are internally reviewed on this mailing list before
sending them to maintainers.

thanks,
Daniel.
--
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: [PATCHv4 3/5] mailbox: pl320: Introduce common API driver

[Jassi Brar]

On 19 March 2014 00:40, Rob Herring  wrote:
> On Tue, Mar 18, 2014 at 1:45 PM, Jassi Brar  wrote:
>> Convert the PL320 controller driver to work with the common
>> mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
>> to work with thee API. Drop the obsoleted driver pl320-ipc.c
>>
>> Signed-off-by: Jassi Brar 
>> ---
>>  drivers/cpufreq/highbank-cpufreq.c |  24 -
>>  drivers/mailbox/Makefile   |   2 +-
>>  drivers/mailbox/pl320-ipc.c| 198 --
>>  drivers/mailbox/pl320.c| 214 
>> +
>
> Would you mind resending with rename detection enabled.
>
> You can make that the default by adding this to your config:
>
> [diff]
> renames = true
>
The driver isn't just renamed. The new driver is quite different from
original. So '-M' option to git format-patch doesn't make it simpler.
Btw I do have "git config --global diff.renames true" as well.

-Jassi
--
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 v3 0/2] Add stop callback to the cpufreq_driver interface.

[Viresh Kumar]

On 19 March 2014 06:23, Rafael J. Wysocki  wrote:
> On Tuesday, March 18, 2014 12:25:14 PM Dirk Brandewie wrote:
>> On 03/18/2014 12:08 PM, Srivatsa S. Bhat wrote:
>> > On 03/18/2014 10:52 PM, dirk.brande...@gmail.com wrote:
>> >> From: Dirk Brandewie 
>> >>
>> >
>> > I don't mean to nitpick, but generally its easier to deal with
>> > patchsets if you post the subsequent versions in fresh email threads.
>> > Otherwise it can get a bit muddled along with too many other email
>> > discussions in the same thread :-(
>> >
>> >> Changes:
>> >> v2->v3
>> >> Changed the calling of the ->stop() callback to be conditional on the
>> >> core being the last core controlled by a given policy.
>> >>
>> >
>> > Wait, why? I'm sorry if I am not catching up with the discussions on
>> > this issue quickly enough, but I don't see why we should make it
>> > conditional on _that_. I thought we agreed that we should make it
>> > conditional in the sense that ->stop() should be invoked only for
>> > ->setpolicy drivers, right?
>>
>> This was done at Viresh's suggestion since thought there might be value
>> for ->target drivers.
>>
>> Any of the options work for me
>> called only for set_policy scaling drivers
>
> And that's what we should do *today* in my opinion, unless we want to add
> it to any ->target() drivers *right* now.  Do we want that?

We don't have a platform right now that might want to use it, but people
are doing this during suspend and so there is a high possibility that they
will use it while normal cpu offline as well..

This is what I think:
- We are adding a new callback to struct cpufreq_driver..
- We have a classic case here because a driver (set-policy ones) is both a
driver and governor. And that's why its special..
- All we want here is to give drivers a chance to do something useful on the
CPUs that are going down..
- There is nothing like GOV_STOP for setpolicy drivers as we never needed
it and if we really want that, probably we better register setpolicy drivers as
governors as well (only to a level where they would get GOV_START|STOP|etc)
callbacks and nothing else.
- And so I wanted the ->stop() callback to be more about the driver than the
governor.
- And because a policy contains only the CPUs that share clock line, its
only required to call stop() for last CPU of the policy.

--
viresh
--
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/4] blk-mq: add a exit_request method

[Ming Lei]

On Mon, Mar 17, 2014 at 9:18 PM, Christoph Hellwig  wrote:
> This gives drivers an easy way to free any resources allocated in
> ->init_request.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  block/blk-mq.c |   18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index c2ce99b..c7e723e 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -1000,6 +1000,16 @@ static void blk_mq_free_rq_map(struct blk_mq_hw_ctx 
> *hctx)
>  {
> struct page *page;
>
> +   if (hctx->rqs && hctx->queue->mq_ops->exit_request) {

exit_request definition is missed.


Thanks,
-- 
Ming Lei
--
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] intel_pstate: Set core to min P state during core offline

[Viresh Kumar]

On 19 March 2014 01:14, Dirk Brandewie  wrote:
> There was no problem per se.  In stop() all I really needed to do is stop
> the
> timer and set the P state to MIN.
>
> At init time I need to allocate memory and start timer.  If stopping the
> timer
> and deallocating memory are separated then I need code in init() to detect
> this case.

Sorry, I didn't understood what exactly is special here :(

If we return failure from CPU_POST_DEAD for some reason without
calling exit() then you will have memory leak in your init() as we are
allocating memory without checking if we already have that (nothing wrong
in it though as other parts of kernel should handle things properly here).

Probably the situation would be exactly same if we divide the exit path into
stop and exit routines, which I still feel is the right way forward. Because
ideally cpufreq shouldn't call init() if it hasn't called exit() (If
it is doing that
right now then its wrong and can be fixed). And so you must do the cleanup
in exit()..
--
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: [PATCHv4 2/5] mailbox: Introduce framework for mailbox

[Jassi Brar]

On 19 March 2014 09:30, Girish KS  wrote:
> On Wed, Mar 19, 2014 at 12:15 AM, Jassi Brar  wrote:

>> +int mbox_send_message(struct mbox_chan *chan, void *mssg)
>> +{
>> +   int t;
>> +
>> +   if (!chan || !chan->cl)
>> +   return -EINVAL;
>> +
>> +   t = _add_to_rbuf(chan, mssg);
>> +   if (t < 0) {
>> +   pr_err("Try increasing MBOX_TX_QUEUE_LEN\n");
>> +   return t;
>> +   }
>> +
>> +   _msg_submit(chan);
>> +
>> +   if (chan->txdone_method == TXDONE_BY_POLL)
>> +   poll_txdone((unsigned long)chan->con);
>
> I came across a panic in the complete function. When i traced bact the
> call sequence it was
> When a client sets chan->cl->tx_block = true, and polling is enabled
> for controller.
> 1.Client sends the message with  mbox_send_message. This function as
> seen above will call __msg_submit (this calls the controller specific
> send function).
> 2. Since the tx method is polling the above condition is satisfied and
> calls the poll_txdone function.
> 3. In this poll function, the tx_tick function is invoked.
> 4. In this tick function since the client has enabled the tx_block it
> calls the notify function complete(>tx_complete);
> 5. Here there is a panic. because the complete is called before
> initialization. init_completion needs to be called but not called.
>
Are you sure you have applied the patch "[PATCHv4 4/5] mailbox: Fix TX
completion init" ?

Thanks
Jassi
--
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 0/6] mm: support madvise(MADV_FREE)

[Johannes Weiner]

On Tue, Mar 18, 2014 at 05:23:37PM -0700, Andy Lutomirski wrote:
> On Tue, Mar 18, 2014 at 5:18 PM, Minchan Kim  wrote:
> > Hello,
> >
> > On Tue, Mar 18, 2014 at 10:55:24AM -0700, Andy Lutomirski wrote:
> >> On 03/13/2014 11:37 PM, Minchan Kim wrote:
> >> > This patch is an attempt to support MADV_FREE for Linux.
> >> >
> >> > Rationale is following as.
> >> >
> >> > Allocators call munmap(2) when user call free(3) if ptr is
> >> > in mmaped area. But munmap isn't cheap because it have to clean up
> >> > all pte entries, unlinking a vma and returns free pages to buddy
> >> > so overhead would be increased linearly by mmaped area's size.
> >> > So they like madvise_dontneed rather than munmap.
> >> >
> >> > "dontneed" holds read-side lock of mmap_sem so other threads
> >> > of the process could go with concurrent page faults so it is
> >> > better than munmap if it's not lack of address space.
> >> > But the problem is that most of allocator reuses that address
> >> > space soonish so applications see page fault, page allocation,
> >> > page zeroing if allocator already called madvise_dontneed
> >> > on the address space.
> >> >
> >> > For avoidng that overheads, other OS have supported MADV_FREE.
> >> > The idea is just mark pages as lazyfree when madvise called
> >> > and purge them if memory pressure happens. Otherwise, VM doesn't
> >> > detach pages on the address space so application could use
> >> > that memory space without above overheads.
> >>
> >> I must be missing something.
> >>
> >> If the application issues MADV_FREE and then writes to the MADV_FREEd
> >> range, the kernel needs to know that the pages are no longer safe to
> >> lazily free.  This would presumably happen via a page fault on write.
> >> For that to happen reliably, the kernel has to write protect the pages
> >> when MADV_FREE is called, which in turn requires flushing the TLBs.
> >
> > It could be done by pte_dirty bit check. Of course, if some architectures
> > don't support it by H/W, pte_mkdirty would make it CoW as you said.
> 
> If the page already has dirty PTEs, then you need to clear the dirty
> bits and flush TLBs so that other CPUs notice that the PTEs are clean,
> I think.
> 
> Also, this has very odd semantics wrt reading the page after MADV_FREE
> -- is reading the page guaranteed to un-free it?

MADV_FREE simply invalidates content.  Sure, you can read at a given
address repeatedly after it.  You might see a different page every
time you do it, but it doesn't matter; the content is undefined.

It's no different than doing malloc() and looking at the memory before
writing anything in it.  After MADV_FREE, the memory is like a freshly
malloc'd chunk: the first access may result in page faults and the
content is undefined until you write it.
--
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] cpufreq: Add stop callback to cpufreq_driver interface

[Viresh Kumar]

On 18 March 2014 22:52,   wrote:
> From: Dirk Brandewie 
>
> This callback allows the driver to do clean up before the CPU is
> completely down and its state cannot be modified.  This is used
> by the intel_pstate driver to reduce the requested P state prior to
> the core going away.  This is required because the requested P state
> of the offline core is used to select the package P state. This
> effectively sets the floor package P state to the requested P state on
> the offline core.
>
> Signed-off-by: Dirk Brandewie 
> ---
>  Documentation/cpu-freq/cpu-drivers.txt | 8 +++-
>  drivers/cpufreq/cpufreq.c  | 3 ++-
>  include/linux/cpufreq.h| 1 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/cpu-freq/cpu-drivers.txt 
> b/Documentation/cpu-freq/cpu-drivers.txt
> index 8b1a445..79def80 100644
> --- a/Documentation/cpu-freq/cpu-drivers.txt
> +++ b/Documentation/cpu-freq/cpu-drivers.txt
> @@ -61,7 +61,13 @@ target_index -   See below on the differences.
>
>  And optionally
>
> -cpufreq_driver.exit -  A pointer to a per-CPU cleanup function.
> +cpufreq_driver.exit -  A pointer to a per-CPU cleanup
> +   function called during CPU_POST_DEAD
> +   phase of cpu hotplug process.
> +
> +cpufreq_driver.stop -  A pointer to a per-CPU stop function
> +   called during CPU_DOWN_PREPARE phase of
> +   cpu hotplug process.
>
>  cpufreq_driver.resume -A pointer to a per-CPU resume function
> which is called with interrupts disabled
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index cf485d9..6e6beae 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1336,7 +1336,8 @@ static int __cpufreq_remove_dev_prepare(struct device 
> *dev,
> __func__, new_cpu, cpu);
> }
> }
> -   }
> +   } else if (cpufreq_driver->stop)
> +   cpufreq_driver->stop(policy);
>
> return 0;
>  }
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 4d89e0e..ff8db19 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -224,6 +224,7 @@ struct cpufreq_driver {
> int (*bios_limit)   (int cpu, unsigned int *limit);
>
> int (*exit) (struct cpufreq_policy *policy);
> +   int (*stop) (struct cpufreq_policy *policy);
> int (*suspend)  (struct cpufreq_policy *policy);
> int (*resume)   (struct cpufreq_policy *policy);
> struct freq_attr**attr;

Acked-by: Viresh Kumar 
--
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 0/2] Add exit_prepare callback to the cpufreq_driver interface.

[Viresh Kumar]

On 18 March 2014 17:46, Srivatsa S. Bhat
 wrote:
> Agreed. As far as I understand, for ->target drivers, today we use GOV_STOP
> to stop managing the CPU going offline. And for ->setpolicy drivers, we will
> use this new callback to achieve the same goal.

So a better question would be: What's the purpose of ->stop() call for a policy?
Stop managing CPUs of that policy? Or even do something on CPUs of a policy
before CPUs are offlined?

Probably in the current solution Dirk is doing both these things..

And so I thought maybe its better not to restrict ->stop() to just
setpolicy() drivers.
--
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 8/9] PCI: Ignore BAR contents when firmware left decoding disabled

[Ming Lei]

Hi,

Looks Sasha fixed the problem in lkvm tool[1].

Sasha, looks we both saw the problem, but from technical
view, I am wondering if the fix is correct, because PCI spec.
requires that the IO/MMIO bits in COMMAND register should
be cleared after reset, maybe there are some potential problem
in lkvm pci emulation.


[1],  commit 6478ce1416aacf1ce35530f79ea035f89fb21e90
Author: Sasha Levin 
Date:   Wed Mar 5 23:08:16 2014 -0500

kvm tools: mark our PCI card as PIO and MMIO able


Thanks,
--
Ming Lei

On Wed, Mar 19, 2014 at 11:32 AM, Ming Lei  wrote:
> On Tue, Mar 18, 2014 at 8:27 AM, Bjorn Helgaas  wrote:
>> On Fri, Mar 14, 2014 at 09:48:35AM +0800, Ming Lei wrote:
>>> On Fri, Mar 14, 2014 at 12:08 AM, Bjorn Helgaas  wrote:
>>> > On Thu, Mar 13, 2014 at 2:51 AM, Ming Lei  wrote:
>>> >> Hi Bjorn,
>>> >>
>>> >> I found this patch broke virtio-pci devices.
>>> >
>>> > Thanks a lot for testing this.
>>> >
>>> >> On Thu, Feb 27, 2014 at 3:37 AM, Bjorn Helgaas  
>>> >> wrote:
>>> >>> Don't rely on BAR contents when the command register says the BAR is
>>> >>> disabled.
>>> >>>
>>> >>> If we receive a PCI device from firmware (or a hot-added device that was
>>> >>> just powered up) with the MEMORY or IO enable bits in the PCI command
>>> >>> register cleared, there's no reason to believe the BARs contain valid
>>> >>> addresses.
>>> >>
>>> >> From PCI LOCAL BUS SPECIFICATION, REV. 3.0, both
>>> >> PCI_COMMAND_IO and PCI_COMMAND_MEM should be
>>> >> cleared after reset, so looks the patch sets IORESOURCE_UNSET
>>> >> too early because PCI drivers may call pci_enable_device()
>>> >> (->pci_enable_resources()) to enable the two bits of
>>> >> PCI_COMMAND explicitly.
>>> >
>>> > The point is that it's not safe to enable those two bits unless we're
>>> > certain that the BARs they control contain valid values that don't
>>> > conflict with anything else in the system.
>>> >
>>> > Maybe we should only set IORESOURCE_UNSET when we find a conflict or a
>>> > BAR that's not contained by an upstream bridge window, and we should
>>> > try to reallocate then.  I'm pretty sure we do that at least in some
>>> > cases, but it would probably simplify things if we did it more
>>> > consistently, and maybe we shouldn't set it at all here in
>>> > __pci_read_base().
>>>
>>> I think so because __pci_read_base() is called in device emulation
>>> path.
>>
>> Which path is this?  I don't know anything about virtio-pci, and I only see
>> calls to __pci_read_base() from:
>>
>>   sriov_init()
>>   pci_sriov_resource_alignment()
>>   pci_read_bases()
>>
>>> > But I'd like to understand your situation better, so can you provide
>>> > more details, please?  Complete before/after dmesg logs would go a
>>> > long way toward illustrating the problem you're seeing.
>>>
>>> Please see the two attachment log. The memory allocation failure
>>> is caused by mistaken value read from pci address after the device
>>> is failed to enable.
>>
>> Your logs are harder than necessary to compare because one has a lot more
>> debug turned on than the other.
>>
>> In the failing case, we ignore all the initial BAR values, but we do assign
>> values to all of them later:
>>
>>   pci :00:00.0: can't claim BAR 0 [mem size 0x0400]: no address 
>> assigned
>>   pci :00:00.0: can't claim BAR 1 [io  size 0x0400]: no address assigned
>>   ...
>>   pci :00:00.0: BAR 0: assigned [mem 0x4000-0x43ff]
>>   pci :00:00.0: BAR 1: assigned [io  0x1000-0x13ff]
>>   ...
>>
>> The newly-assigned values look valid, and as far as I can tell, they should
>> work.  Do you know why they don't?  Is there an assumption somewhere that
>> we never change BAR values?
>
> I don't know the cause, maybe it is related with the hypervisor
> implementation.
>
>>
>> Even if we don't need to ignore BAR values in as many cases as we do, it
>> should be legal to ignore them and reassign them, so I want to understand
>> what's going on here before reverting this.
>>
>> Is there an easy way I can reproduce the problem on my own box?
>
> It is not quite difficult, you can build a lkvm following the README in
> below link and test -next tree on the small kvm hypervisor:
>
>  https://github.com/penberg/linux-kvm/blob/master/tools/kvm/README
>
> Thanks,
> --
> Ming Lei



-- 
Ming Lei
--
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] timer: remove code redundancy while calling get_nohz_timer_target()

[Viresh Kumar]

On 18 March 2014 21:14, Frederic Weisbecker  wrote:
> On Tue, Mar 18, 2014 at 04:26:07PM +0530, Viresh Kumar wrote:
>> + if (pinned || !get_sysctl_timer_migration() || !idle_cpu(cpu))
>> + return cpu;
>
> Maybe the pinned part should stay a caller detail. Although I don't really 
> mind.

I tried that initially, but in that case the callers would have to call
smp_processor_id() in the else part and so decided to put that as well into this
routine only.

> The patch looks good!

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] charger-manager: Fix checking of wrong return type

[Chanwoo Choi]

Ping.

Thanks,
Chanwoo Choi

On 03/17/2014 08:33 PM, Chanwoo Choi wrote:
> This patch fix minor issue about checking wrong return type.
> 
> The of_cm_parse_desc() return ERR_PTR(errnor number) when some error happen
> in this function. But, charger_manager_probe() has only checked whether
> desc is NULL or not. If of_cm_parse_desc() returns ERR_PTR(-ENOMEM), desc
> isn't NULL but desc is (void *)(-ENOMEM). Althouhg some error happen for 
> parsing
> DT, charger_manager_probe() can't detect error of desc instance.
> 
> Signed-off-by: Chanwoo Choi 
> Signed-off-by: Myungjoo Ham 
> ---
>  drivers/power/charger-manager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
> index 9e4dab4..a10fb57 100644
> --- a/drivers/power/charger-manager.c
> +++ b/drivers/power/charger-manager.c
> @@ -1677,7 +1677,7 @@ static int charger_manager_probe(struct platform_device 
> *pdev)
>   }
>   }
>  
> - if (!desc) {
> + if (IS_ERR(desc)) {
>   dev_err(>dev, "No platform data (desc) found\n");
>   return -ENODEV;
>   }
> 

--
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] INTEL-IGB: Convert iounmap to pci_iounmap

[Jeff Kirsher]

On Tue, 2014-03-18 at 17:11 +0100, Peter Senna Tschudin wrote:
> Use pci_iounmap instead of iounmap when the virtual mapping was done
> with pci_iomap. A simplified version of the semantic patch that finds
> this
> issue is as follows: (http://coccinelle.lip6.fr/)
> 
> // 
> @r@
> expression addr;
> @@
> addr = pci_iomap(...)
> 
> @rr@
> expression r.addr;
> @@
> * iounmap(addr)
> // 
> 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  Tested by compilation only.
> 
>  drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Thanks Peter, I have added you patch to my queue.


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

Re: [PATCH] staging: unisys: use kzalloc instead of kmalloc/memset 0

[DaeSeok Youn]

Thanks for reply.
I will do that.

Regards,
Daeseok Youn.

2014-03-19 11:31 GMT+09:00 Greg KH :
> On Wed, Mar 19, 2014 at 10:04:40AM +0900, DaeSeok Youn wrote:
>> oh...
>> You didn't get my reply about vmalloc usage.
>>
>> My replay attach again, below.
>>
>> > 2014-03-18 9:37 GMT+09:00 Greg KH :
>> >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote:
>> >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
>> >>> vmalloc/kmalloc directly.
>> >>
>> >> Yes.  Actually, just use kmalloc, I don't knwo why vmalloc is being
>> >> used, but cc: the driver maintainers just to be sure.
>> >
>> Here, need to check by you.
>> > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it
>> > trying to allocate with kmalloc()
>> > it has a possibility to fail because of memory fragmentation even if
>> > system has enough memory to use.
>> > Just my opinion. If I'm wrong, let me know.
>
> Check to see just how big you are allocating, you should know based on
> the flags which code path happened uislib_malloc().
>
> Just keep the logic the same and you should be fine.
>
> 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/

linux-next: manual merge of the staging tree with the drm tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got conflicts in
drivers/staging/imx-drm/imx-hdmi.c, drivers/staging/imx-drm/imx-ldb.c,
drivers/staging/imx-drm/imx-tve.c and
drivers/staging/imx-drm/parallel-display.c between commits 69fa5293bf8d
("drm/kms: rip out drm_mode_connector_detach_encoder") and fc1645ac826c
("drm/imx: remove drm_mode_connector_detach_encoder harder") from the drm
tree and commit 1b3f76756633 ("imx-drm: initialise drm components
directly") from the staging tree.

I fixed it up (I used the staging tree version as it was a superset of
the drm tree version) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpMScJKNe8pW.pgp
Description: PGP signature

Re: For review: open_by_name_at(2) man page [v2]

[NeilBrown]

On Tue, 18 Mar 2014 13:55:15 +0100 "Michael Kerrisk (man-pages)"
 wrote:

> Hi Aneesh, (and others)
> 
> After integrating review comments from NeilBown and Christoph Hellwig,
> here is draft 2 of a man page I've written for name_to_handle_at(2) and
> open_by_name_at(2). Especially thanks to Neil's comments, several parts
> of the page underwent a substantial rewrite. Would you be willing to 
> review it please, and let me know of any corrections/improvements?

I didn't notice before but above and in $SUBJ I see "open_by_name_at", which
is fictitious :-)

> 
> Together, the
> .I pathname
> and
> .I dirfd
> arguments identify the file for which a handle is to obtained.
  ^be


> 
> The
> .I flags
> argument is a bit mask constructed by ORing together
> zero or more of the following value:
 ^s


> .TP
> .B AT_EMPTY_PATH
> Allow
> .I pathname
> to be an empty string.
> See above.
> (which may have been obtained using the
> .BR open (2)
> .B O_PATH
> flag).

What "may have been obtained" ??


> The
> .I flags
> argument
> is as for
> .BR open (2).
> .\" FIXME: Confirm that the following is intended behavior.
> .\"(It certainly seems to be the behavior, from experimenting.)
> If
> .I handle
> refers to a symbolic link, the caller must specify the
> .B O_PATH
> flag, and the symbolic link is not dereferenced (the
> .B O_NOFOLLOW
> flag, if specified, is ignored).

It certainly sounds like reasonable behaviour.  I cannot comment on intention
though.
Are you bothered that O_PATH is needed for symlinks?  An fd on a symlink is a
sufficiently unusual thing that it seems reasonable for a programmer to
explicitly say they are expecting one.


> 
> In the event of an error, both system calls return \-1 and set
> .I errno
> to indicate the cause of the error.
> .SH ERRORS
> .BR name_to_handle_at ()
> and
> .BR open_by_handle_at ()
> can fail for the same errors as
> .BR openat (2).
> In addition, they can fail with the errors noted below.

Should you mention EFAULT if mount_id or handle are not valid pointers?


> 
> Not all filesystem types support the translation of pathnames to
> file handles.
> .\" FIXME NeilBrown noted:
> .\"ESTALE is also returned if the filesystem does not support
> .\"file-handle -> file mappings.
> .\"On filesystems which don't provide export_operations (/sys /proc
> .\"ubifs romfs cramfs nfs coda ... several others) name_to_handle_at
> .\"will produce a generic handle using the 32 bit inode and 32 bit
> .\"i_generation. open_by_name_at given this (or any) filehandle
> .\"will fail with ESTALE.
> .\" However, on /proc and /sys, at least, name_to_handle_at() fails with
> .\" EOPNOTSUPP. Are there really filesystems that can deliver ESTALE (the
> .\" same error as for an invalid file handle) in the above circumstances?

This is all wrong - discard it :-)

NeilBrown



signature.asc
Description: PGP signature

Re: [PATCH 2/2] arm64: dts: exynos: added mailbox node

[Girish KS]

On Mon, Mar 17, 2014 at 7:36 PM, Mark Rutland  wrote:
> On Mon, Mar 17, 2014 at 12:03:59PM +, Girish K S wrote:
>> This patch adds the dt node for the mailbox IP
>>
>> Signed-off-by: Girish K S 
>>
>> Change-Id: I35e45e9a62592887a84a909aee54f259a2f731fa
>> ---
>>  .../bindings/mailbox/samsung-mailbox.txt   |   24 +++
>>  arch/arm64/boot/dts/samsung-gh7.dtsi   |   66 
>> 
>>  arch/arm64/boot/dts/samsung-ssdk-gh7.dts   |3 +
>>  3 files changed, 93 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mailbox/samsung-mailbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/samsung-mailbox.txt 
>> b/Documentation/devicetree/bindings/mailbox/samsung-mailbox.txt
>> new file mode 100644
>> index 000..1908d71
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/samsung-mailbox.txt
>> @@ -0,0 +1,24 @@
>> +
>> +Samsung Mailbox Driver
>> +
>> +Required properties:
>> +- compatible:Should be one of the following,
>> + "samsung,gh7-mailbox" for
>> + Samsung GH7 SoC series
>> + "samsung,exynos-mailbox" for
>> + exynosx SoC series
>> +- reg:   Contains the mailbox register address range 
>> (base address
>> + and length)
>> +- interrupts:Contains the interrupt information for the 
>> mailbox
>> + device.
>
> How many interrupts?
just one receive interrupt
I will update this detail in binding doc
>
> What are they for?
It is only for receive from remote processor
>
>> +- samsung,mbox-names:Array of the names of the mailboxes
>
> Juding by the code there is one name per reg entry, but the description
> above implies a single entry (as all the dt fragments have).
>
> What values are expected? What is the consumer of these values? What are
> they used for?
These names are used to mention the links in the platform. tx and rx
link via mailbox.
i can mention of 2 consumers now. the ipmi driver and the cpu freq
driver. They are used
to exchange information with the remote processor
>
>> +
>> +Example:
>> +
>> +/* Samsung GH7 SoC */
>> +mailbox@100a {
>> + compatible = "samsung,gh7-mailbox";
>> + reg = <0x0 0x100a 0x0 0x1000>;
>> + interrupts = <0 310 0>;
>> + samsung,mbox-names = "a7q-scp";
>> +};
>> diff --git a/arch/arm64/boot/dts/samsung-gh7.dtsi 
>> b/arch/arm64/boot/dts/samsung-gh7.dtsi
>> index c3610bd..be4cce9 100644
>> --- a/arch/arm64/boot/dts/samsung-gh7.dtsi
>> +++ b/arch/arm64/boot/dts/samsung-gh7.dtsi
>> @@ -107,5 +107,71 @@
>>   interrupts = <0 420 0>;
>>   arm,primecell-periphid = <0x341011>; /* HACK */
>
> This looks odd.
>
> What tree is this against?

Sorry this was based on a internal tree. Will base it on Kukjin's gh7 base patch

>
> Cheers,
> Mark.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [PATCHv4 2/5] mailbox: Introduce framework for mailbox

[Girish KS]

On Wed, Mar 19, 2014 at 12:15 AM, Jassi Brar  wrote:
> Introduce common framework for client/protocol drivers and
> controller drivers of Inter-Processor-Communication (IPC).
>
> Client driver developers should have a look at
>  include/linux/mailbox_client.h to understand the part of
> the API exposed to client drivers.
> Similarly controller driver developers should have a look
> at include/linux/mailbox_controller.h
>
> Signed-off-by: Jassi Brar 
> ---
>  drivers/mailbox/Makefile   |   4 +
>  drivers/mailbox/mailbox.c  | 589 
> +
>  include/linux/mailbox.h|  18 ++
>  include/linux/mailbox_client.h |  48 +++
>  include/linux/mailbox_controller.h |  85 ++
>  5 files changed, 744 insertions(+)
>  create mode 100644 drivers/mailbox/mailbox.c
>  create mode 100644 include/linux/mailbox.h
>  create mode 100644 include/linux/mailbox_client.h
>  create mode 100644 include/linux/mailbox_controller.h
>
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index e0facb3..2fa343a 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -1,3 +1,7 @@
> +# Generic MAILBOX API
> +
> +obj-$(CONFIG_MAILBOX)  += mailbox.o
> +
>  obj-$(CONFIG_PL320_MBOX)   += pl320-ipc.o
>
>  obj-$(CONFIG_OMAP_MBOX)+= omap-mailbox.o
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> new file mode 100644
> index 000..79d576e
> --- /dev/null
> +++ b/drivers/mailbox/mailbox.c
> @@ -0,0 +1,589 @@
> +/*
> + * Mailbox: Common code for Mailbox controllers and users
> + *
> + * Copyright (C) 2014 Linaro Ltd.
> + * Author: Jassi Brar 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * The length of circular buffer for queuing messages from a client.
> + * 'msg_count' tracks the number of buffered messages while 'msg_free'
> + * is the index where the next message would be buffered.
> + * We shouldn't need it too big because every transferr is interrupt
> + * triggered and if we have lots of data to transfer, the interrupt
> + * latencies are going to be the bottleneck, not the buffer length.
> + * Besides, mbox_send_message could be called from atomic context and
> + * the client could also queue another message from the notifier 'tx_done'
> + * of the last transfer done.
> + * REVIST: If too many platforms see the "Try increasing MBOX_TX_QUEUE_LEN"
> + * print, it needs to be taken from config option or somesuch.
> + */
> +#define MBOX_TX_QUEUE_LEN  20
> +
> +#define TXDONE_BY_IRQ  (1 << 0) /* controller has remote RTR irq */
> +#define TXDONE_BY_POLL (1 << 1) /* controller can read status of last TX */
> +#define TXDONE_BY_ACK  (1 << 2) /* S/W ACK recevied by Client ticks the TX */
> +
> +struct mbox_chan {
> +   char name[16]; /* Physical link's name */
> +   struct mbox_con *con; /* Parent Controller */
> +   unsigned txdone_method;
> +
> +   /* Physical links */
> +   struct mbox_link *link;
> +   struct mbox_link_ops *link_ops;
> +
> +   /* client */
> +   struct mbox_client *cl;
> +   struct completion tx_complete;
> +
> +   void *active_req;
> +   unsigned msg_count, msg_free;
> +   void *msg_data[MBOX_TX_QUEUE_LEN];
> +   /* Access to the channel */
> +   spinlock_t lock;
> +   /* Hook to add to the controller's list of channels */
> +   struct list_head node;
> +   /* Notifier to all clients waiting on aquiring this channel */
> +   struct blocking_notifier_head avail;
> +} __aligned(32);
> +
> +/* Internal representation of a controller */
> +struct mbox_con {
> +   struct device *dev;
> +   char name[16]; /* controller_name */
> +   struct list_head channels;
> +   /*
> +* If the controller supports only TXDONE_BY_POLL,
> +* this timer polls all the links for txdone.
> +*/
> +   struct timer_list poll;
> +   unsigned period;
> +   /* Hook to add to the global controller list */
> +   struct list_head node;
> +} __aligned(32);
> +
> +static LIST_HEAD(mbox_cons);
> +static DEFINE_MUTEX(con_mutex);
> +
> +static int _add_to_rbuf(struct mbox_chan *chan, void *mssg)
> +{
> +   int idx;
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>lock, flags);
> +
> +   /* See if there is any space left */
> +   if (chan->msg_count == MBOX_TX_QUEUE_LEN) {
> +   spin_unlock_irqrestore(>lock, flags);
> +   return -ENOMEM;
> +   }
> +
> +   idx = chan->msg_free;
> +   chan->msg_data[idx] = mssg;
> +   chan->msg_count++;
> +
> +   if (idx == MBOX_TX_QUEUE_LEN - 1)
> +   chan->msg_free = 

Re: [PATCH 1/2] mailbox: samsung: added support for samsung mailbox

[Girish KS]

On Tue, Mar 18, 2014 at 4:26 PM, Joe Perches  wrote:
> On Tue, 2014-03-18 at 15:52 +0530, Girish KS wrote:
>> On Mon, Mar 17, 2014 at 5:33 PM, Girish K S  wrote:
>
> Hi, just some trivial notes about the patch
>
>> > diff --git a/drivers/mailbox/mailbox-samsung.c 
>> > b/drivers/mailbox/mailbox-samsung.c
> []
>> > @@ -0,0 +1,354 @@
>> > +/*
>> > + * Copyright 2013 Samsung Electronics Co. Ltd.
>> > + *
>> > + * This program is free software; you can redistribute it and/or modify it
>> > + * under the terms and conditions of the GNU General Public License,
>> > + * version 2, as published by the Free Software Foundation.
>> > + *
>> > + * This program is distributed in the hope it will be useful, but WITHOUT
>> > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> > + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
>> > for
>> > + * more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License 
>> > along with
>> > + * this program.  If not, see .
>> > + */
>
> Please add
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> before any #include so that error messages are
> prefixed in the output with "samsung-mailbox: "
> and the reader of the log has an idea what subsystem
> is emitting messages.
>
Sure will do it

>> > +#include 
>> > +#include 
>> > +#include 
> []
>> > +static int samsung_mbox_send_data(struct ipc_link *link, void *msg)
>> > +{
> []
>> > +   /* Lock the mailbox for this transaction with the client id */
>> > +   writel(val, ipc_base + MBOX_REG_TXLOCK);
>> > +   do {
>> > +   if (time_after(jiffies, timeout)) {
>> > +   pr_err("cannot aquire the lock\n");
>
> This would be prefixed appropriately via pr_fmt.
> Also, there's a typo of aquire here: acquire

OK

>
>> > +static int samsung_mbox_startup(struct ipc_link *link, void *ignored)
>> > +{
> []
>> > +   ret = devm_request_irq(dev, samsung_link->irq, samsung_ipc_handler,
>> > +   IRQF_SHARED, link->link_name,
>> > +   samsung_link);
>> > +   if (unlikely(ret)) {
>> > +   pr_err("failed to register mailbox interrupt:%d\n", ret);
>
> Here too it would be prefixed

ok

>
>> > +static int samsung_mbox_probe(struct platform_device *pdev)
>> > +{
>> > +   struct samsung_mbox *samsung_mbox;
>> > +   struct samsung_mlink *mbox_link;
>> > +   struct resource res;
>> > +   struct ipc_link **link;
>> > +   int loop, count, ret = 0;
>> > +   struct device_node *node = pdev->dev.of_node;
>> > +
>> > +   if (!node) {
>> > +   dev_err(>dev, "driver doesnt support"
>> > +   "non-dt devices\n");
>
> Please coalesce the format fragments.
>
> You would notice the missing space between
> "support" and "non-dt"

ok

>
> dev_err(>dev, "driver does not support non-dt 
> devices\n");
>
> It's OK to exceed 80 columns for these format strings.
>
>> > diff --git a/include/linux/mailbox-samsung.h 
>> > b/include/linux/mailbox-samsung.h
> []
>> > +static inline unsigned long get_alligned_buffer(void)
>
> Typo: There's one l in aligned

will do it

>
>> > +{
>> > +   return __get_free_pages(GFP_KERNEL, REQUEST_PAGE_ORDER);
>> > +}
>> > +
>> > +static inline void put_alligned_buffer(unsigned long addr)
>> > +{
>
> here too
>
>> > +   free_pages(addr, REQUEST_PAGE_ORDER);
>> > +}
>> > +
>
>
--
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] mfd: sec-core: Fix I2C dummy device resource leak on probe failure

[Sachin Kamat]

On 18 March 2014 18:27, Krzysztof Kozlowski  wrote:
> Dummy I2C device allocated in sec_pmic_probe() leaked if
> devm_regmap_init_i2c() failed. Unregister it before returning from
> probe.
>
> Signed-off-by: Krzysztof Kozlowski 

Looks good.
Reviewed-by: Sachin Kamat 

-- 
With warm regards,
Sachin
--
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 RESEND -mm 1/2] mm: add !pte_present() check on existing hugetlb_entry callbacks

[Naoya Horiguchi]

Page table walker doesn't check non-present hugetlb entry in common path,
so hugetlb_entry() callbacks must check it. The reason for this behavior
is that some callers want to handle it in its own way.

However, some callers don't check it now, which causes unpredictable result,
for example when we have a race between migrating hugepage and reading
/proc/pid/numa_maps. This patch fixes it by adding !pte_present checks on
buggy callbacks.

This bug exists for years and got visible by introducing hugepage migration.

ChangeLog v2:
- fix if condition (check !pte_present() instead of pte_present())

Reported-by: Sasha Levin 
Signed-off-by: Naoya Horiguchi 
Cc: sta...@vger.kernel.org # 3.12+
---
 fs/proc/task_mmu.c | 3 +++
 mm/mempolicy.c | 6 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git v3.14-rc7-mmotm-2014-03-18-16-37.orig/fs/proc/task_mmu.c 
v3.14-rc7-mmotm-2014-03-18-16-37/fs/proc/task_mmu.c
index d9d9d4f41544..f75ce811d430 100644
--- v3.14-rc7-mmotm-2014-03-18-16-37.orig/fs/proc/task_mmu.c
+++ v3.14-rc7-mmotm-2014-03-18-16-37/fs/proc/task_mmu.c
@@ -1300,6 +1300,9 @@ static int gather_hugetlb_stats(pte_t *pte, unsigned long 
addr,
if (pte_none(*pte))
return 0;
 
+   if (!pte_present(*pte))
+   return 0;
+
page = pte_page(*pte);
if (!page)
return 0;
diff --git v3.14-rc7-mmotm-2014-03-18-16-37.orig/mm/mempolicy.c 
v3.14-rc7-mmotm-2014-03-18-16-37/mm/mempolicy.c
index af635c458dee..9d2ef4111a4c 100644
--- v3.14-rc7-mmotm-2014-03-18-16-37.orig/mm/mempolicy.c
+++ v3.14-rc7-mmotm-2014-03-18-16-37/mm/mempolicy.c
@@ -524,8 +524,12 @@ static int queue_pages_hugetlb(pte_t *pte, unsigned long 
addr,
unsigned long flags = qp->flags;
int nid;
struct page *page;
+   pte_t entry;
 
-   page = pte_page(huge_ptep_get(pte));
+   entry = huge_ptep_get(pte);
+   if (!pte_present(entry))
+   return 0;
+   page = pte_page(entry);
nid = page_to_nid(page);
if (node_isset(nid, *qp->nmask) == !!(flags & MPOL_MF_INVERT))
return 0;
-- 
1.8.5.3

--
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/3] bridge: preserve random init MAC address

[Luis R. Rodriguez]

On Tue, Mar 18, 2014 at 8:10 PM, Stephen Hemminger
 wrote:
> On Wed, 12 Mar 2014 20:15:25 -0700
> "Luis R. Rodriguez"  wrote:
>
>> As it is now if you add create a bridge it gets started
>> with a random MAC address and if you then add a net_device
>> as a slave but later kick it out you end up with a zero
>> MAC address. Instead preserve the original random MAC
>> address and use it.
>
> What is supposed to happen is that the recalculate chooses
> the lowest MAC address of the slaves. If there are no slaves
> it might as well just calculate a new random value. There is
> not great merit in preserving the original defunct address.

OK I'll go and add some changes for this then.

  Luis
--
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 8/9] PCI: Ignore BAR contents when firmware left decoding disabled

[Ming Lei]

On Tue, Mar 18, 2014 at 8:27 AM, Bjorn Helgaas  wrote:
> On Fri, Mar 14, 2014 at 09:48:35AM +0800, Ming Lei wrote:
>> On Fri, Mar 14, 2014 at 12:08 AM, Bjorn Helgaas  wrote:
>> > On Thu, Mar 13, 2014 at 2:51 AM, Ming Lei  wrote:
>> >> Hi Bjorn,
>> >>
>> >> I found this patch broke virtio-pci devices.
>> >
>> > Thanks a lot for testing this.
>> >
>> >> On Thu, Feb 27, 2014 at 3:37 AM, Bjorn Helgaas  
>> >> wrote:
>> >>> Don't rely on BAR contents when the command register says the BAR is
>> >>> disabled.
>> >>>
>> >>> If we receive a PCI device from firmware (or a hot-added device that was
>> >>> just powered up) with the MEMORY or IO enable bits in the PCI command
>> >>> register cleared, there's no reason to believe the BARs contain valid
>> >>> addresses.
>> >>
>> >> From PCI LOCAL BUS SPECIFICATION, REV. 3.0, both
>> >> PCI_COMMAND_IO and PCI_COMMAND_MEM should be
>> >> cleared after reset, so looks the patch sets IORESOURCE_UNSET
>> >> too early because PCI drivers may call pci_enable_device()
>> >> (->pci_enable_resources()) to enable the two bits of
>> >> PCI_COMMAND explicitly.
>> >
>> > The point is that it's not safe to enable those two bits unless we're
>> > certain that the BARs they control contain valid values that don't
>> > conflict with anything else in the system.
>> >
>> > Maybe we should only set IORESOURCE_UNSET when we find a conflict or a
>> > BAR that's not contained by an upstream bridge window, and we should
>> > try to reallocate then.  I'm pretty sure we do that at least in some
>> > cases, but it would probably simplify things if we did it more
>> > consistently, and maybe we shouldn't set it at all here in
>> > __pci_read_base().
>>
>> I think so because __pci_read_base() is called in device emulation
>> path.
>
> Which path is this?  I don't know anything about virtio-pci, and I only see
> calls to __pci_read_base() from:
>
>   sriov_init()
>   pci_sriov_resource_alignment()
>   pci_read_bases()
>
>> > But I'd like to understand your situation better, so can you provide
>> > more details, please?  Complete before/after dmesg logs would go a
>> > long way toward illustrating the problem you're seeing.
>>
>> Please see the two attachment log. The memory allocation failure
>> is caused by mistaken value read from pci address after the device
>> is failed to enable.
>
> Your logs are harder than necessary to compare because one has a lot more
> debug turned on than the other.
>
> In the failing case, we ignore all the initial BAR values, but we do assign
> values to all of them later:
>
>   pci :00:00.0: can't claim BAR 0 [mem size 0x0400]: no address 
> assigned
>   pci :00:00.0: can't claim BAR 1 [io  size 0x0400]: no address assigned
>   ...
>   pci :00:00.0: BAR 0: assigned [mem 0x4000-0x43ff]
>   pci :00:00.0: BAR 1: assigned [io  0x1000-0x13ff]
>   ...
>
> The newly-assigned values look valid, and as far as I can tell, they should
> work.  Do you know why they don't?  Is there an assumption somewhere that
> we never change BAR values?

I don't know the cause, maybe it is related with the hypervisor
implementation.

>
> Even if we don't need to ignore BAR values in as many cases as we do, it
> should be legal to ignore them and reassign them, so I want to understand
> what's going on here before reverting this.
>
> Is there an easy way I can reproduce the problem on my own box?

It is not quite difficult, you can build a lkvm following the README in
below link and test -next tree on the small kvm hypervisor:

 https://github.com/penberg/linux-kvm/blob/master/tools/kvm/README

Thanks,
-- 
Ming Lei
--
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 v3] mac80211: LLVMLinux: Remove VLAIS usage from mac80211

[behanw]

From: Jan-Simon Möller 

Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This is the original VLAIS struct.

struct {
struct aead_request req;
u8  priv[crypto_aead_reqsize(tfm)];
} aead_req;

This patch instead allocates the appropriate amount of memory using an char
array.

The new code can be compiled with both gcc and clang.

Signed-off-by: Jan-Simon Möller 
Signed-off-by: Behan Webster 
Signed-off-by: Vinícius Tinti 
Signed-off-by: Mark Charlebois 
---
 net/mac80211/aes_ccm.c | 40 ++--
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 7c7df47..20521f9 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -23,12 +23,14 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
   u8 *data, size_t data_len, u8 *mic)
 {
struct scatterlist assoc, pt, ct[2];
-   struct {
-   struct aead_request req;
-   u8  priv[crypto_aead_reqsize(tfm)];
-   } aead_req;
 
-   memset(_req, 0, sizeof(aead_req));
+   char aead_req_data[sizeof(struct aead_request) +
+   crypto_aead_reqsize(tfm)]
+   __aligned(__alignof__(struct aead_request));
+
+   struct aead_request *aead_req = (void *) aead_req_data;
+
+   memset(aead_req, 0, sizeof(aead_req_data));
 
sg_init_one(, data, data_len);
sg_init_one(, [2], be16_to_cpup((__be16 *)aad));
@@ -36,23 +38,25 @@ void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
sg_set_buf([0], data, data_len);
sg_set_buf([1], mic, IEEE80211_CCMP_MIC_LEN);
 
-   aead_request_set_tfm(_req.req, tfm);
-   aead_request_set_assoc(_req.req, , assoc.length);
-   aead_request_set_crypt(_req.req, , ct, data_len, b_0);
+   aead_request_set_tfm(aead_req, tfm);
+   aead_request_set_assoc(aead_req, , assoc.length);
+   aead_request_set_crypt(aead_req, , ct, data_len, b_0);
 
-   crypto_aead_encrypt(_req.req);
+   crypto_aead_encrypt(aead_req);
 }
 
 int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
  u8 *data, size_t data_len, u8 *mic)
 {
struct scatterlist assoc, pt, ct[2];
-   struct {
-   struct aead_request req;
-   u8  priv[crypto_aead_reqsize(tfm)];
-   } aead_req;
 
-   memset(_req, 0, sizeof(aead_req));
+   char aead_req_data[sizeof(struct aead_request) +
+   crypto_aead_reqsize(tfm) +
+   CRYPTO_MINALIGN] CRYPTO_MINALIGN_ATTR;
+
+   struct aead_request *aead_req = (void *) aead_req_data;
+
+   memset(aead_req, 0, sizeof(aead_req_data));
 
sg_init_one(, data, data_len);
sg_init_one(, [2], be16_to_cpup((__be16 *)aad));
@@ -60,12 +64,12 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
sg_set_buf([0], data, data_len);
sg_set_buf([1], mic, IEEE80211_CCMP_MIC_LEN);
 
-   aead_request_set_tfm(_req.req, tfm);
-   aead_request_set_assoc(_req.req, , assoc.length);
-   aead_request_set_crypt(_req.req, ct, ,
+   aead_request_set_tfm(aead_req, tfm);
+   aead_request_set_assoc(aead_req, , assoc.length);
+   aead_request_set_crypt(aead_req, ct, ,
   data_len + IEEE80211_CCMP_MIC_LEN, b_0);
 
-   return crypto_aead_decrypt(_req.req);
+   return crypto_aead_decrypt(aead_req);
 }
 
 struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[])
-- 
1.8.3.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: performance regression due to commit e82e0561("mm: vmscan: obey proportional scanning requirements for kswapd")

[Hugh Dickins]

On Tue, 18 Mar 2014, Yuanhan Liu wrote:
> On Sat, Mar 15, 2014 at 08:56:10PM -0700, Hugh Dickins wrote:
> > On Fri, 14 Mar 2014, Mel Gorman wrote:
> > > 
> > > You say it's already been tested for months but it would be nice if the
> > > workload that generated this thread was also tested.
> > 
> > Yes indeed: Yuanhan, do you have time to try this patch for your
> > testcase?  I'm hoping it will prove at least as effective as your
> > own suggested patch, but please let us know what you find - thanks.
> 
> Hi Hugh,
> 
> Sure, and sorry to tell you that this patch introduced another half
> performance descrease from avg 60 MB/s to 30 MB/s in this testcase.

Thanks a lot for trying it out.  I had been hoping that everything
would be wonderful, and I wouldn't have think at all about what's
going on.  You have made me sad :( but I can't blame your honesty!

I'll have to think a little after all, about your test, and Mel's
pertinent questions: I'll come back to you, nothing to say right now.

Hugh

> 
> Moreover, the dd throughput for each process was steady before, however,
> it's quite bumpy from 20 MB/s to 40 MB/s w/ this patch applied, and thus
> got a avg of 30 MB/s:
> 
> 11327188992 bytes (11 GB) copied, 300.014 s, 37.8 MB/s
> 1809373+0 records in
> 1809372+0 records out
> 7411187712 bytes (7.4 GB) copied, 300.008 s, 24.7 MB/s
> 3068285+0 records in
> 3068284+0 records out
> 12567691264 bytes (13 GB) copied, 300.001 s, 41.9 MB/s
> 1883877+0 records in
> 1883876+0 records out
> 7716356096 bytes (7.7 GB) copied, 300.002 s, 25.7 MB/s
> 1807674+0 records in
> 1807673+0 records out
> 7404228608 bytes (7.4 GB) copied, 300.024 s, 24.7 MB/s
> 1796473+0 records in
> 1796472+0 records out
> 7358349312 bytes (7.4 GB) copied, 300.008 s, 24.5 MB/s
> 1905655+0 records in
> 1905654+0 records out
> 7805558784 bytes (7.8 GB) copied, 300.016 s, 26.0 MB/s
> 2819168+0 records in
> 2819167+0 records out
> 11547308032 bytes (12 GB) copied, 300.025 s, 38.5 MB/s
> 1848381+0 records in
> 1848380+0 records out
> 7570964480 bytes (7.6 GB) copied, 300.005 s, 25.2 MB/s
> 3023133+0 records in
> 3023132+0 records out
> 12382748672 bytes (12 GB) copied, 300.024 s, 41.3 MB/s
> 1714585+0 records in
> 1714584+0 records out
> 7022936064 bytes (7.0 GB) copied, 300.011 s, 23.4 MB/s
> 1835132+0 records in
> 1835131+0 records out
> 7516696576 bytes (7.5 GB) copied, 299.998 s, 25.1 MB/s
> 1733341+0 records in
> 
> 
>   --yliu
> 
--
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: linux-next: build failure after merge of the final tree (net-next tree related)

[David Miller]

From: Stephen Rothwell 
Date: Tue, 18 Mar 2014 18:27:52 +1100

> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> net/netfilter/nft_hash.c: In function 'nft_hash_tbl_free':
> net/netfilter/nft_hash.c:79:3: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]

I've applied the patch below to fix this, thanks.

> Caused by commit ce6eb0d7c8ec ("netfilter: nft_hash: bug fixes and
> resizing") from the net-next tree.  See Rule 1 in
> Documentation/SubmitChecklist.

This slips through a lot, and would happen less often if core x86
headers didn't bring in vmalloc.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/3] bridge: preserve random init MAC address

[Stephen Hemminger]

On Wed, 12 Mar 2014 20:15:25 -0700
"Luis R. Rodriguez"  wrote:

> As it is now if you add create a bridge it gets started
> with a random MAC address and if you then add a net_device
> as a slave but later kick it out you end up with a zero
> MAC address. Instead preserve the original random MAC
> address and use it.

What is supposed to happen is that the recalculate chooses
the lowest MAC address of the slaves. If there are no slaves
it might as well just calculate a new random value. There is
not great merit in preserving the original defunct address.

Or something like this that just keeps the old value.
The bridge is in a meaningless state when there are no ports,
and when the first port is added back it will be used as the
new bridge id.

--- a/net/bridge/br_stp_if.c2014-02-12 08:21:56.733857356 -0800
+++ b/net/bridge/br_stp_if.c2014-03-18 20:09:09.334388826 -0700
@@ -235,6 +235,9 @@ bool br_stp_recalculate_bridge_id(struct
addr = p->dev->dev_addr;
 
}
+
+   if (addr == br_mac_zero)
+   return false;  /* keep original address */
 
if (ether_addr_equal(br->bridge_id.addr, addr))
return false;   /* no change */
--
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: linux-next: build failure after merge of the final tree (net-next tree related)

[David Miller]

From: Stephen Rothwell 
Date: Mon, 17 Mar 2014 21:21:00 +1100

> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> drivers/net/ethernet/intel/i40evf/built-in.o:(.data+0x1868): multiple 
> definition of `i40e_ptype_lookup'
> drivers/net/ethernet/intel/i40e/built-in.o:(.data+0x3f58): first defined here
> 
> Caused by commit 206812b5fccb ("i40e/i40evf: i40e implementation for
> skb_set_hash") from the net-next tree.
> 
> I applied this patch for today (there is probably a better way):
> 
> From 6964d39f8436eade2cdb0c5236734c579b8b0897 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell 
> Date: Mon, 17 Mar 2014 21:18:48 +1100
> Subject: [PATCH] i40e/i40evf: i40e implementation for skb_set_hash fix
> 
> Signed-off-by: Stephen Rothwell 

Jeff Kirsher gave me a patch today that fixes this, thanks Stephen.
--
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/4] blk-mq: replace blk_mq_init_commands with a ->init_request method

[Ming Lei]

On Mon, Mar 17, 2014 at 9:18 PM, Christoph Hellwig  wrote:
> Bedides a simpler and cleared interface this also allows to initialize the
> flush_rq properly.  The interface for that is still a bit messy as we don't
> have a hw_ctx available for the flush request, but that's something that
> should be fixable with a little work once the demand arises.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  block/blk-mq.c |   65 
> +---
>  drivers/block/virtio_blk.c |   22 +++
>  include/linux/blk-mq.h |9 +-
>  3 files changed, 50 insertions(+), 46 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index e3284f6..c2ce99b 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -996,33 +996,6 @@ static void blk_mq_hctx_notify(void *data, unsigned long 
> action,
> blk_mq_put_ctx(ctx);
>  }
>
> -static void blk_mq_init_hw_commands(struct blk_mq_hw_ctx *hctx,
> -   void (*init)(void *, struct blk_mq_hw_ctx 
> *,
> -   struct request *, unsigned int),
> -   void *data)
> -{
> -   unsigned int i;
> -
> -   for (i = 0; i < hctx->queue_depth; i++) {
> -   struct request *rq = hctx->rqs[i];
> -
> -   init(data, hctx, rq, i);
> -   }
> -}
> -
> -void blk_mq_init_commands(struct request_queue *q,
> - void (*init)(void *, struct blk_mq_hw_ctx *,
> -   struct request *, unsigned int),
> - void *data)
> -{
> -   struct blk_mq_hw_ctx *hctx;
> -   unsigned int i;
> -
> -   queue_for_each_hw_ctx(q, hctx, i)
> -   blk_mq_init_hw_commands(hctx, init, data);
> -}
> -EXPORT_SYMBOL(blk_mq_init_commands);
> -
>  static void blk_mq_free_rq_map(struct blk_mq_hw_ctx *hctx)
>  {
> struct page *page;
> @@ -1050,10 +1023,12 @@ static size_t order_to_size(unsigned int order)
>  }
>
>  static int blk_mq_init_rq_map(struct blk_mq_hw_ctx *hctx,
> - unsigned int reserved_tags, int node)
> +   struct blk_mq_reg *reg, void *driver_data, int node)
>  {
> +   unsigned int reserved_tags = reg->reserved_tags;
> unsigned int i, j, entries_per_page, max_order = 4;
> size_t rq_size, left;
> +   int error;
>
> INIT_LIST_HEAD(>page_list);
>
> @@ -1102,14 +1077,23 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx 
> *hctx,
> for (j = 0; j < to_do; j++) {
> hctx->rqs[i] = p;
> blk_mq_rq_init(hctx, hctx->rqs[i]);
> +   if (reg->ops->init_request) {
> +   error = reg->ops->init_request(driver_data,
> +   hctx, hctx->rqs[i], i);
> +   if (error)
> +   goto err_rq_map;
> +   }
> +
> p += rq_size;
> i++;
> }
> }
>
> -   if (i < (reserved_tags + BLK_MQ_TAG_MIN))
> +   if (i < (reserved_tags + BLK_MQ_TAG_MIN)) {
> +   error = -ENOMEM;
> goto err_rq_map;
> -   else if (i != hctx->queue_depth) {
> +   }
> +   if (i != hctx->queue_depth) {
> hctx->queue_depth = i;
> pr_warn("%s: queue depth set to %u because of low memory\n",
> __func__, i);
> @@ -1117,12 +1101,14 @@ static int blk_mq_init_rq_map(struct blk_mq_hw_ctx 
> *hctx,
>
> hctx->tags = blk_mq_init_tags(hctx->queue_depth, reserved_tags, node);
> if (!hctx->tags) {
> -err_rq_map:
> -   blk_mq_free_rq_map(hctx);
> -   return -ENOMEM;
> +   error = -ENOMEM;
> +   goto err_rq_map;
> }
>
> return 0;
> +err_rq_map:
> +   blk_mq_free_rq_map(hctx);
> +   return error;
>  }
>
>  static int blk_mq_init_hw_queues(struct request_queue *q,
> @@ -1155,7 +1141,7 @@ static int blk_mq_init_hw_queues(struct request_queue 
> *q,
> blk_mq_hctx_notify, hctx);
> blk_mq_register_cpu_notifier(>cpu_notifier);
>
> -   if (blk_mq_init_rq_map(hctx, reg->reserved_tags, node))
> +   if (blk_mq_init_rq_map(hctx, reg, driver_data, node))
> break;
>
> /*
> @@ -1334,6 +1320,17 @@ struct request_queue *blk_mq_init_queue(struct 
> blk_mq_reg *reg,
> if (!q->flush_rq)
> goto err_hw;
>
> +   if (reg->ops->init_request) {
> +   blk_rq_init(q, q->flush_rq);
> +   if (reg->cmd_size)
> +   q->flush_rq->special =
> +   blk_mq_rq_to_pdu(q->flush_rq);
> +
> +   if 

Re: [PATCH] printk: fix one circular lockdep warning about console_lock

[Jane Li]

On 02/12/2014 05:19 AM, Andrew Morton wrote:


On Tue, 11 Feb 2014 14:50:00 +0800  wrote:


From: Jane Li

This patch tries to fix a warning about possible circular locking
dependency.

If do in following sequence:
 enter suspend ->  resume ->  plug-out CPUx (echo 0 > cpux/online)
lockdep will show warning as following:

==
[ INFO: possible circular locking dependency detected ]
3.10.0 #2 Tainted: G   O
---
sh/1271 is trying to acquire lock:
(console_lock){+.+.+.}, at: [] console_cpu_notify+0x20/0x2c
but task is already holding lock:
(cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x2c/0x58
which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:
-> #2 (cpu_hotplug.lock){+.+.+.}:
[] lock_acquire+0x98/0x12c
[] mutex_lock_nested+0x50/0x3d8
[] cpu_hotplug_begin+0x2c/0x58
[] _cpu_up+0x24/0x154
[] cpu_up+0x64/0x84
[] smp_init+0x9c/0xd4
[] kernel_init_freeable+0x78/0x1c8
[] kernel_init+0x8/0xe4
[] ret_from_fork+0x14/0x2c

-> #1 (cpu_add_remove_lock){+.+.+.}:
[] lock_acquire+0x98/0x12c
[] mutex_lock_nested+0x50/0x3d8
[] disable_nonboot_cpus+0x8/0xe8
[] suspend_devices_and_enter+0x214/0x448
[] pm_suspend+0x1e4/0x284
[] try_to_suspend+0xa4/0xbc
[] process_one_work+0x1c4/0x4fc
[] worker_thread+0x138/0x37c
[] kthread+0xa4/0xb0
[] ret_from_fork+0x14/0x2c

-> #0 (console_lock){+.+.+.}:
[] __lock_acquire+0x1b38/0x1b80
[] lock_acquire+0x98/0x12c
[] console_lock+0x54/0x68
[] console_cpu_notify+0x20/0x2c
[] notifier_call_chain+0x44/0x84
[] __cpu_notify+0x2c/0x48
[] cpu_notify_nofail+0x8/0x14
[] _cpu_down+0xf4/0x258
[] cpu_down+0x24/0x40
[] store_online+0x30/0x74
[] dev_attr_store+0x18/0x24
[] sysfs_write_file+0x16c/0x19c
[] vfs_write+0xb4/0x190
[] SyS_write+0x3c/0x70
[] ret_fast_syscall+0x0/0x48

Chain exists of:
console_lock --> cpu_add_remove_lock --> cpu_hotplug.lock

Possible unsafe locking scenario:
CPU0CPU1

lock(cpu_hotplug.lock);
lock(cpu_add_remove_lock);
lock(cpu_hotplug.lock);
lock(console_lock);
   *** DEADLOCK ***

These traces hurt my brain.


There are three locks involved in two sequence:
a) pm suspend:
console_lock (@suspend_console())
cpu_add_remove_lock (@disable_nonboot_cpus())
cpu_hotplug.lock (@_cpu_down())

But but but.  suspend_console() releases console_sem again.  So the
sequence is actually

down(_sem) (@suspend_console())
up(_sem) (@suspend_console())
cpu_add_remove_lock (@disable_nonboot_cpus())
cpu_hotplug.lock (@_cpu_down())

So console_sem *doesn't* nest outside cpu_add_remove_lock and
cpu_hotplug.lock.


 Jan Kara and Jane have answered this question in other emails.


b) Plug-out CPUx:
cpu_add_remove_lock (@(cpu_down())
cpu_hotplug.lock (@_cpu_down())
console_lock (@console_cpu_notify()) => Lockdeps prints warning log.

There should be not real deadlock, as flag of console_suspended can
protect this.

console_lock() does down(_sem) *before* testing
console_suspended, so I don't understand this sentence - a more
detailed description would help.


Jane has answered this question in another email.


Printk registers cpu hotplug notify function. When CPUx is plug-out/in,
always execute console_lock() and console_unlock(). This patch
modifies that with console_trylock() and console_unlock(). Then use
that instead of the unconditional console_lock/unlock pair to avoid the
warning.

...

--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1893,6 +1893,20 @@ void resume_console(void)
  }
  
  /**

+ * console_flush - flush dmesg if console isn't suspended
+ *
+ * console_unlock always flushes the dmesg buffer, so just try to
+ * grab the console lock. If that fails we know that the current
+ * holder will eventually drop the console lock and so flush the dmesg
+ * buffers at the earliest possible time.
+ */

The comment should describe why we added this code, please: talk about
cpu_hotplug.lock and console_lock.


Daniel has answered this question in another email.


+void console_flush(void)
+{
+   if (console_trylock())
+   console_unlock();
+}
+
+/**
   * console_cpu_notify - print deferred console messages after CPU hotplug
   * @self: notifier struct
   * @action: CPU hotplug event
@@ -1911,8 +1925,7 @@ static int console_cpu_notify(struct notifier_block *self,
case CPU_DEAD:
case CPU_DOWN_FAILED:
case CPU_UP_CANCELED:
-   console_lock();
-   console_unlock();
+   console_flush();
}
return NOTIFY_OK;

Well, this is a bit hacky and makes the already-far-too-complex code
even more complex.  If it is indeed the case that the deadlock cannot
really occur then let's try to find a way of suppressing the lockdep
warning without 

[PATCH] checkpatch: Improve octal permissions test speed

[Joe Perches]

The current octal permissions test is very slow.

When commit 3fc9249967
("checkpatch: add checks for constant non-octal permissions")
was added, processing time approximately tripled.

Regain almost all of the performance by not looping through all the
possible functions unless the line contains one of the functions.

Signed-off-by: Joe Perches 
---
There's probably some perl "join('|', foo)" that would
simplify and remove the initial foreach loop, but I don't
know what it might be off the top of my head.  Andy?

 scripts/checkpatch.pl | 51 +++
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d44e440..ec65c54 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -388,6 +388,13 @@ our @mode_permission_funcs = (
["(?:CLASS|DEVICE|SENSOR)_ATTR", 2],
 );
 
+#Create a search pattern for all these functions to speed up a loop below
+our $mode_perms_search = "";
+foreach my $entry (@mode_permission_funcs) {
+   $mode_perms_search .= '|' if ($mode_perms_search ne "");
+   $mode_perms_search .= $entry->[0];
+}
+
 our $allowed_asm_includes = qr{(?x:
irq|
memory
@@ -4540,26 +4547,30 @@ sub process {
 "Exporting world writable files is usually an 
error. Consider more restrictive permissions.\n" . $herecurr);
}
 
-   foreach my $entry (@mode_permission_funcs) {
-   my $func = $entry->[0];
-   my $arg_pos = $entry->[1];
-
-   my $skip_args = "";
-   if ($arg_pos > 1) {
-   $arg_pos--;
-   $skip_args = 
"(?:\\s*$FuncArg\\s*,\\s*){$arg_pos,$arg_pos}";
-   }
-   my $test = 
"\\b$func\\s*\\(${skip_args}([\\d]+)\\s*[,\\)]";
-   if ($^V && $^V ge 5.10.0 &&
-   $line =~ /$test/) {
-   my $val = $1;
-   $val = $6 if ($skip_args ne "");
-
-   if ($val !~ /^0$/ &&
-   (($val =~ /^$Int$/ && $val !~ /^$Octal$/) ||
-length($val) ne 4)) {
-   ERROR("NON_OCTAL_PERMISSIONS",
- "Use 4 digit octal (0777) not 
decimal permissions\n" . $herecurr);
+# Mode permission misuses where it seems decimal should be octal
+# This uses a shortcut match to avoid unnecessary uses of a slow foreach loop
+   if ($^V && $^V ge 5.10.0 &&
+   $line =~ /$mode_perms_search/) {
+   foreach my $entry (@mode_permission_funcs) {
+   my $func = $entry->[0];
+   my $arg_pos = $entry->[1];
+
+   my $skip_args = "";
+   if ($arg_pos > 1) {
+   $arg_pos--;
+   $skip_args = 
"(?:\\s*$FuncArg\\s*,\\s*){$arg_pos,$arg_pos}";
+   }
+   my $test = 
"\\b$func\\s*\\(${skip_args}([\\d]+)\\s*[,\\)]";
+   if ($line =~ /$test/) {
+   my $val = $1;
+   $val = $6 if ($skip_args ne "");
+
+   if ($val !~ /^0$/ &&
+   (($val =~ /^$Int$/ && $val !~ 
/^$Octal$/) ||
+length($val) ne 4)) {
+   ERROR("NON_OCTAL_PERMISSIONS",
+ "Use 4 digit octal (0777) 
not decimal permissions\n" . $herecurr);
+   }
}
}
}


--
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: bad rss-counter message in 3.14rc5

[Linus Torvalds]

On Tue, Mar 18, 2014 at 7:37 PM, Hugh Dickins  wrote:
>
> For 3.15, and probably 3.16 too, we should keep in place whatever
> partial accommodations we have for the case (such as allowing for
> anon and swap in fremap's zap_pte), in case we do need to revert;
> but clean those away later on.  (Not many, I think: it was mainly
> a guilty secret that VM accounting didn't really hold together.)

Absolutely. See if it works to just stop doing that special COW, and
then later on, if we have decided "nobody even noticed", we can remove
the hacks we have to support the fact that shared mappings sometimes
have anon pages in them.

> :)  That fits with what I heard of HP-UX mmap,
> but I never had the pleasure of dealing with it.

They had purely virtually indexed caches, making coherency
"interesting". Together with a VM based on some really old BSD VM code
that everybody else had thrown out, and that didn't allow you to unmap
things partially etc. So HPUX mmap really didn't work, not even for
non-shared mmap's.

I think they fixed the interfaces in HP-UX 11. But not being coherent
meant that the shared mappings tended to still have trouble. nntp
largely died, but was replaced with the cyrus imapd that played
similar games.

At least out mmap was always coherent. Even in MAP_PRIVATE, and with
regards to both write() system calls and other mmap PROT_WRITE users.

Except when we had bugs. Shared mmap really isn't very simple to get right.

 Linus
--
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: [PATCHv2 4/8] devfreq: exynos4: Fix bug of resource leak and code clean on probe()

[Chanwoo Choi]

Hi Tomasz,

On 03/18/2014 09:18 PM, Tomasz Figa wrote:
> On 17.03.2014 06:05, Chanwoo Choi wrote:
>> Hi Tomasz,
>>
>> On 03/15/2014 02:49 AM, Tomasz Figa wrote:
>>> Hi Chanwoo,
>>>
>>> On 13.03.2014 09:17, Chanwoo Choi wrote:
 This patch fix bug about resource leak when happening probe fail and code 
 clean
 to add debug message.

 Signed-off-by: Chanwoo Choi 
 ---
drivers/devfreq/exynos/exynos4_bus.c | 32 
 ++--
1 file changed, 26 insertions(+), 6 deletions(-)

 diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
 b/drivers/devfreq/exynos/exynos4_bus.c
 index a2a3a47..152a3e9 100644
 --- a/drivers/devfreq/exynos/exynos4_bus.c
 +++ b/drivers/devfreq/exynos/exynos4_bus.c
 @@ -1152,8 +1152,11 @@ static int exynos4_busfreq_probe(struct 
 platform_device *pdev)
dev_err(dev, "Cannot determine the device id %d\n", data->type);
err = -EINVAL;
}
 -if (err)
 +if (err) {
 +dev_err(dev, "Cannot initialize busfreq table %d\n",
 + data->type);
return err;
 +}

rcu_read_lock();
opp = dev_pm_opp_find_freq_floor(dev,
 @@ -1176,7 +1179,7 @@ static int exynos4_busfreq_probe(struct 
 platform_device *pdev)
if (IS_ERR(data->devfreq)) {
dev_err(dev, "Failed to add devfreq device\n");
err = PTR_ERR(data->devfreq);
 -goto err_opp;
 +goto err_devfreq;
}

/*
 @@ -1185,18 +1188,35 @@ static int exynos4_busfreq_probe(struct 
 platform_device *pdev)
 */
busfreq_mon_reset(data);

 -devfreq_register_opp_notifier(dev, data->devfreq);
 +/* Register opp_notifier for Exynos4 busfreq */
 +err = devfreq_register_opp_notifier(dev, data->devfreq);
 +if (err < 0) {
 +dev_err(dev, "Failed to register opp notifier\n");
 +goto err_notifier_opp;
 +}

 +/* Register pm_notifier for Exynos4 busfreq */
err = register_pm_notifier(>pm_notifier);
if (err) {
dev_err(dev, "Failed to setup pm notifier\n");
 -devfreq_remove_device(data->devfreq);
 -return err;
 +goto err_notifier_pm;
}

return 0;

 -err_opp:
 +err_notifier_pm:
 +devfreq_unregister_opp_notifier(dev, data->devfreq);
 +err_notifier_opp:
 +/*
 + * The devfreq_remove_device() would execute finally devfreq->profile
 + * ->exit(). To avoid duplicate resource free operation, return 
 directly
 + * before executing resource free below 'err_devfreq' goto statement.
 + */
>>>
>>> I'm not quite sure about this. I believe that in this case 
>>> devfreq->profile->exit() would be exynos4_bus_exit() and all it does is 
>>> devfreq_unregister_opp_notifier(dev, data->devfreq), so all remaining 
>>> resources (regulators, clocks, etc.) would get leaked.
>>
>> This patch execute following sequence to probe exynos4_busfreq.c:
>>
>> 1. Parse dt node to get resource(regulator/clock/memory address).
>> 2. Enable regulator/clock and map memory.
>> 3. Add devfreq device using devfreq_add_device().
>> The devfreq_add_device() return devfreq instance(data->devfreq).
>> 4. Register opp_notifier using devfreq instance(data->devfreq) which is 
>> created in sequence #3.
>>
>> Case 1,
>> If an error happens in sequence #3 for registering devfreq_add_device(),
>>
>> this case can't execute devfreq->profile->exit() to free resource
>> because this case has failed to register devfreq->profile to devfreq_list.
>>
>> So, must goto 'err_devfreq' statement to free 
>> resource(regulator/clock/memory).
>>
>>
>> Case 2,
>> If an error happens in sequence #4 for registering opp_notifier,
>>
>> In contrast
>> this case can execute devfreq->profile->exit() to free resource.
>> But, After executed devfreq->profile->exit(),
>> should not execute 'err_devfreq' statement to free resource.
>> In case, will operate twice of resource.
>>
>> If my explanation is wrong, please reply your comment.
>>
> 
> OK, it will work indeed, however the code is barely readable with this.
> 
> For consistency (and readability), resources acquired in platform driver's 
> .probe() should be freed in .remove() and error path of .probe() should not 
> rely on external code to do the clean-up.
> 
> So, as I proposed in my previous reply:

OK, I'll modify it according to your previous comment.

> 
>>>
>>> I believe the correct thing to do would be to remove the .exit() callback 
>>> from exynos4_devfreq_profile struct and handle all the clean-up here in 
>>> error path.
>>>

Best Regards,
Chanwoo Choi
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More 

Re: [PATCHv2 3/8] devfreq: exynos4: Add ppmu's clock control and code clean about regulator control

[Chanwoo Choi]

Hi Tomasz,

On 03/18/2014 08:13 PM, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> On 17.03.2014 06:59, Chanwoo Choi wrote:
>> Hi Tomasz,
>>
>> On 03/17/2014 11:51 AM, Chanwoo Choi wrote:
>>> Hi Tomasz,
>>>
>>> On 03/15/2014 02:42 AM, Tomasz Figa wrote:
 Hi Chanwoo,

 On 13.03.2014 09:17, Chanwoo Choi wrote:
> There are not the clock controller of ppmudmc0/1. This patch control the 
> clock
> of ppmudmc0/1 which is used for monitoring memory bus utilization.
>
> Also, this patch code clean about regulator control and free resource
> when calling exit/remove function.
>
> For example,
> busfreq@106A {
>  compatible = "samsung,exynos4x12-busfreq";
>
>  /* Clock for PPMUDMC0/1 */
>  clocks = < CLK_PPMUDMC0>, < CLK_PPMUDMC1>;
>  clock-names = "ppmudmc0", "ppmudmc1";
>
>  /* Regulator for MIF/INT block */
>  vdd_mif-supply = <_reg>;
>  vdd_int-supply = <_reg>;
> };
>
> Signed-off-by: Chanwoo Choi 
>>
>> I modify this patch according your comment as following:
>>
>> Best Regards,
>> Chanwoo Choi
>>
>>> From c8f2fbc4c1166ec02fb2ad46164bc7ed9118721b Mon Sep 17 00:00:00 2001
>> From: Chanwoo Choi 
>> Date: Fri, 14 Mar 2014 12:05:54 +0900
>> Subject: [PATCH] devfreq: exynos4: Add ppmu's clock control and code clean
>>   about regulator control
>>
>> There are not the clock controller of ppmudmc0/1. This patch control the 
>> clock
>> of ppmudmc0/1 which is used for monitoring memory bus utilization.
>>
>> Also, this patch code clean about regulator control and free resource
>> when calling exit/remove function.
>>
>> For example,
>> busfreq@106A {
>> compatible = "samsung,exynos4x12-busfreq";
>>
>> /* Clock for PPMUDMC0/1 */
>> clocks = < CLK_PPMUDMC0>, < CLK_PPMUDMC1>;
>> clock-names = "ppmudmc0", "ppmudmc1";
>>
>> /* Regulator for MIF/INT block */
>> vdd_mif-supply = <_reg>;
>> vdd_int-supply = <_reg>;
>> };
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>   drivers/devfreq/exynos/exynos4_bus.c | 97 
>> +++-
>>   1 file changed, 84 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/devfreq/exynos/exynos4_bus.c 
>> b/drivers/devfreq/exynos/exynos4_bus.c
>> index 4c630fb..3956bcc 100644
>> --- a/drivers/devfreq/exynos/exynos4_bus.c
>> +++ b/drivers/devfreq/exynos/exynos4_bus.c
>> @@ -62,6 +62,11 @@ enum exynos_ppmu_idx {
>>   PPMU_END,
>>   };
>>
>> +static const char *exynos_ppmu_clk_name[] = {
>> +[PPMU_DMC0]= "ppmudmc0",
>> +[PPMU_DMC1]= "ppmudmc1",
>> +};
>> +
>>   #define EX4210_LV_MAXLV_2
>>   #define EX4x12_LV_MAXLV_4
>>   #define EX4210_LV_NUM(LV_2 + 1)
>> @@ -86,6 +91,7 @@ struct busfreq_data {
>>   struct regulator *vdd_mif; /* Exynos4412/4212 only */
>>   struct busfreq_opp_info curr_oppinfo;
>>   struct exynos_ppmu ppmu[PPMU_END];
>> +struct clk *clk_ppmu[PPMU_END];
>>
>>   struct notifier_block pm_notifier;
>>   struct mutex lock;
>> @@ -724,6 +730,17 @@ static void exynos4_bus_exit(struct device *dev)
>>   struct busfreq_data *data = dev_get_drvdata(dev);
>>   int i;
>>
>> +/*
>> + * Un-map memory map and disable regulator/clocks
>> + * to prevent power leakage.
>> + */
>> +regulator_disable(data->vdd_int);
>> +if (data->type == TYPE_BUSF_EXYNOS4x12)
>> +regulator_disable(data->vdd_mif);
>> +
>> +for (i = 0; i < PPMU_END; i++)
>> +clk_disable_unprepare(data->clk_ppmu[i]);
>> +
>>   for (i = 0; i < PPMU_END; i++)
>>   iounmap(data->ppmu[i].hw_base);
>>   }
>> @@ -989,6 +1006,7 @@ static int exynos4_busfreq_parse_dt(struct busfreq_data 
>> *data)
>>   {
>>   struct device *dev = data->dev;
>>   struct device_node *np = dev->of_node;
>> +const char **clk_name = exynos_ppmu_clk_name;
>>   int i, ret = 0;
>>
>>   if (!np) {
>> @@ -1006,8 +1024,67 @@ static int exynos4_busfreq_parse_dt(struct 
>> busfreq_data *data)
>>   }
>>   }
>>
>> +for (i = 0; i < PPMU_END; i++) {
>> +data->clk_ppmu[i] = devm_clk_get(dev, clk_name[i]);
>> +if (IS_ERR(data->clk_ppmu[i])) {
>> +dev_warn(dev, "Failed to get %s clock\n", clk_name[i]);
> 
> dev_err() since this is an error.

OK, I'll fix it.

> 
>> +goto err_clocks;
>> +}
>> +
>> +ret = clk_prepare_enable(data->clk_ppmu[i]);
>> +if (ret < 0) {
>> +dev_warn(dev, "Failed to enable %s clock\n", clk_name[i]);
> 
> Ditto.

OK, I'll fix it.

> 
>> +data->clk_ppmu[i] = NULL;
>> +goto err_clocks;
>> +}
>> +}
>> +
>> +/* Get regulator to control voltage of int block */
>> +data->vdd_int = devm_regulator_get(dev, "vdd_int");
>> +if (IS_ERR(data->vdd_int)) {
>> +dev_err(dev, "Failed to get the regulator of vdd_int\n");
>> +ret = PTR_ERR(data->vdd_int);
>> +goto err_clocks;
>> +}
>> +ret = 

[PATCH RESEND -mm 2/2] mm/mempolicy.c: add comment in queue_pages_hugetlb()

[Naoya Horiguchi]

We have a race where we try to migrate an invalid page, resulting in
hitting VM_BUG_ON_PAGE in isolate_huge_page().
queue_pages_hugetlb() is OK to fail, so let's check !PageHeadHuge to keep
invalid hugepage from queuing.

Reported-by: Sasha Levin 
Signed-off-by: Naoya Horiguchi 
---
 mm/mempolicy.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git v3.14-rc7-mmotm-2014-03-18-16-37.orig/mm/mempolicy.c 
v3.14-rc7-mmotm-2014-03-18-16-37/mm/mempolicy.c
index 9d2ef4111a4c..ae6e2d9dc855 100644
--- v3.14-rc7-mmotm-2014-03-18-16-37.orig/mm/mempolicy.c
+++ v3.14-rc7-mmotm-2014-03-18-16-37/mm/mempolicy.c
@@ -530,6 +530,17 @@ static int queue_pages_hugetlb(pte_t *pte, unsigned long 
addr,
if (!pte_present(entry))
return 0;
page = pte_page(entry);
+
+   /*
+* Trinity found that page could be a non-hugepage. This is an
+* unexpected behavior, but it's not clear how this problem happens.
+* So let's simply skip such corner case. Page migration can often
+* fail for various reasons, so it's ok to just skip the address
+* unsuitable to hugepage migration.
+*/
+   if (!PageHeadHuge(page))
+   return 0;
+
nid = page_to_nid(page);
if (node_isset(nid, *qp->nmask) == !!(flags & MPOL_MF_INVERT))
return 0;
-- 
1.8.5.3

--
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: bad rss-counter message in 3.14rc5

[Sasha Levin]

On 03/18/2014 10:12 PM, Hugh Dickins wrote:

On Tue, 18 Mar 2014, Sasha Levin wrote:

On 03/18/2014 08:38 PM, Hugh Dickins wrote:

On Tue, 11 Mar 2014, Dave Jones wrote:

On Tue, Mar 11, 2014 at 09:36:03PM +0400, Cyrill Gorcunov wrote:
   > On Tue, Mar 11, 2014 at 01:10:45PM -0400, Dave Jones wrote:
   > >  >
   > >  > Dave, iirc trinity can write log file pointing which exactly
syscall sequence
   > >  > was passed, right? Share it too please.
   > >
   > > Hm, I may have been mistaken, and the damage was done by a previous
run.
   > > I went from being able to reproduce it almost instantly to now not
being able
   > > to reproduce it at all.  Will keep trying.
   >
   > Sasha already gave a link to the syscalls sequence, so no rush.

It'd be nice to get a more concise reproducer, his list had a little of
everything in there.


I've so far failed to find any explanation for your swapops.h BUG;
but believe I have identified one cause for "Bad rss-counter"s.

My hunch is that the swapops.h BUG is "nearby", but I just cannot
fit it together (the swapops.h BUG comes when rmap cannot find all
all the migration entries it inserted earlier: it's a very useful
BUG for validating rmap).

Untested patch below: I can't quite say Reported-by, because it may
not even be one that you and Sasha have been seeing; but I'm hopeful,
remap_file_pages is in the list.

Please give this a try, preferably on 3.14-rc or earlier: I've never
seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
a lot more than most of us); but have seen them on mmotm/next, so
some other trigger is coming up there, I'll worry about that once
it reaches 3.15-rc.


The patch fixed the "Bad rss-counter" errors I've been seeing both in
3.14-rc7 and -next.


Great, thanks a lot, Sasha.  I was afraid that you'd hit those swapops
BUGs, which seemed perhaps to be paired with these; but glad to hear
a positive.  Let's see how Dave fares.  (I've not forgotten shmem
fallocate, by the way, but those probably aren't as high on my agenda
as you'd like.)


I do hit the swapops issue a lot, I didn't think that your patch was
supposed to fix that so I didn't mention it.

Thanks for keeping shmem in mind, I've removed shmem from testing for now
but I agree, it's not one of the more important issues to be taken care of.


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: bad rss-counter message in 3.14rc5

[Hugh Dickins]

On Tue, 18 Mar 2014, Linus Torvalds wrote:
> On Tue, Mar 18, 2014 at 7:06 PM, Hugh Dickins  wrote:
> >
> > I'd love that, if we can get away with it now: depends very
> > much on whether we then turn out to break userspace or not.
> 
> Right. I suspect we can, though, but it's one of those "we can try it
> and see". Remind me early in the 3.15 merge window, and we can just
> turn the "force" case into an error case and see if anybody hollers.

Super, I'll do that, thanks.

For 3.15, and probably 3.16 too, we should keep in place whatever
partial accommodations we have for the case (such as allowing for
anon and swap in fremap's zap_pte), in case we do need to revert;
but clean those away later on.  (Not many, I think: it was mainly
a guilty secret that VM accounting didn't really hold together.)

> 
> > If I remember correctly, it's been that way since early days,
> > in case ptrace were used to put a breakpoint into a MAP_SHARED
> > mapping of an executable: to prevent that modification from
> > reaching the file, if the file happened to be opened O_RDWR.
> > Usually it's not open for writing, and mapped MAP_PRIVATE anyway.
> 
> Yes, it's been that way since the very beginning, I think it goes back
> pretty much as far as MAP_SHARED does.
> 
> We used to play lots of games wrt MAP_SHARED - in fact I think we used
> to silently turn a MAP_SHARED RO mapping into MAP_PRIVATE because for
> the longest time there was no "true" writable MAP_SHARED at all, but
> we did have a coherent MAP_PRIVATE and something like the indexer for
> nntpd wanted a read-only shared mapping of the nntp spool or something
> like that. I forget the details, it's a _loong_ time ago.
> 
> So the whole "force turns a MAP_SHARED page into MAP_PRIVATE" all used
> to make a lot more sense in that kind of situation, when MAP_SHARED vs
> MAP_PRIVATE was much less of a black-and-white thing.
> 
> I really suspect nobody cares wrt ptrace, especially since presumably
> other systems haven't had those kinds of games (although who knows -
> HP-UX in particular had some of the shittiest mmap() implementations
> on the planet - it made even the original Linux mmap hacks look like a
> thing of pure beauty in comparison).

:)  That fits with what I heard of HP-UX mmap,
but I never had the pleasure of dealing with it.

Hugh
--
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: unisys: use kzalloc instead of kmalloc/memset 0

[Greg KH]

On Wed, Mar 19, 2014 at 10:04:40AM +0900, DaeSeok Youn wrote:
> oh...
> You didn't get my reply about vmalloc usage.
> 
> My replay attach again, below.
> 
> > 2014-03-18 9:37 GMT+09:00 Greg KH :
> >> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote:
> >>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
> >>> vmalloc/kmalloc directly.
> >>
> >> Yes.  Actually, just use kmalloc, I don't knwo why vmalloc is being
> >> used, but cc: the driver maintainers just to be sure.
> >
> Here, need to check by you.
> > It try to allocate 128KiB(131072byte) with vmalloc(). I think if it
> > trying to allocate with kmalloc()
> > it has a possibility to fail because of memory fragmentation even if
> > system has enough memory to use.
> > Just my opinion. If I'm wrong, let me know.

Check to see just how big you are allocating, you should know based on
the flags which code path happened uislib_malloc().

Just keep the logic the same and you should be fine.

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: bad rss-counter message in 3.14rc5

[Linus Torvalds]

On Tue, Mar 18, 2014 at 7:06 PM, Hugh Dickins  wrote:
>
> I'd love that, if we can get away with it now: depends very
> much on whether we then turn out to break userspace or not.

Right. I suspect we can, though, but it's one of those "we can try it
and see". Remind me early in the 3.15 merge window, and we can just
turn the "force" case into an error case and see if anybody hollers.

> If I remember correctly, it's been that way since early days,
> in case ptrace were used to put a breakpoint into a MAP_SHARED
> mapping of an executable: to prevent that modification from
> reaching the file, if the file happened to be opened O_RDWR.
> Usually it's not open for writing, and mapped MAP_PRIVATE anyway.

Yes, it's been that way since the very beginning, I think it goes back
pretty much as far as MAP_SHARED does.

We used to play lots of games wrt MAP_SHARED - in fact I think we used
to silently turn a MAP_SHARED RO mapping into MAP_PRIVATE because for
the longest time there was no "true" writable MAP_SHARED at all, but
we did have a coherent MAP_PRIVATE and something like the indexer for
nntpd wanted a read-only shared mapping of the nntp spool or something
like that. I forget the details, it's a _loong_ time ago.

So the whole "force turns a MAP_SHARED page into MAP_PRIVATE" all used
to make a lot more sense in that kind of situation, when MAP_SHARED vs
MAP_PRIVATE was much less of a black-and-white thing.

I really suspect nobody cares wrt ptrace, especially since presumably
other systems haven't had those kinds of games (although who knows -
HP-UX in particular had some of the shittiest mmap() implementations
on the planet - it made even the original Linux mmap hacks look like a
thing of pure beauty in comparison).

  Linus
--
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 RFC] sched: introduce add_wait_queue_exclusive_head

[Peng Tao]

On Wed, Mar 19, 2014 at 12:23 AM, Oleg Nesterov  wrote:
> On 03/18, Peng Tao wrote:
>>
>> On Tue, Mar 18, 2014 at 10:05 PM, Peter Zijlstra  
>> wrote:
>> >
>> > Unless you cannot use ___wait() and really need to open-code the
>> > wait_event() stuff.
>> >
>> Lustre's private l_wait_event() stuff takes care to (un)mask
>> LUSTRE_FATAL_SIGS
>
> Hmm. This is off-topic but after the quick grep LUSTRE_FATAL_SIGS/etc
> looks suspicious.
>
> Firtsly, cfs_block_sigs/cfs_block_sigsinv/etc are not exactly right,
> they need set_current_blocked(). And you can read "old" lockless.
>
It seems that set_current_blocked() is not exported. Can we ask to export it?

And looking at other similar places like coda_block_signals(), it
doesn't call set_current_blocked() either. So it needs
set_current_blocked() as well.

> And note that cfs_block_sigsinv(0) (which should block all signals)
> can't actually protect from SIGKILL (or in fact from another fatal
> signal) or SIGSTOP if the caller is multithreaded. Or ptrace, or
> freezer.
>
>> and always wait in TASK_INTERRUPTIBLE state.
>
> and it seems that __wstate passed to waitq_wait/waitq_timedwait is
> simply ignored.
>
Yes. That needs to be dropped.

>> It looks to me that we can at least wrap l_wait_event() on top of
>> wait_event_interruptible/wait_event_timeout_interruptible.
>
> l_wait_event looks really complicated ;) but perhaps you can rewrite
> it on top of ___wait_event(), note that condition/cmd can do anything
> you want.
>
Yeah, I meant to say __wait_event(). Thanks for correcting me.

Thanks,
Tao
--
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/3 Resend] tracing: Use inline task_nice() to get rid of an open coded implementation of it.

[Dongsheng Yang]

On 03/19/2014 10:15 AM, Steven Rostedt wrote:

On Wed, 12 Mar 2014 18:26:42 +0800
Dongsheng Yang  wrote:


Function task_nice() was reimplemented as inline function, we can use it here
to replace the open coded implementation.

Signed-off-by: Dongsheng Yang 
cc: Steven Rostedt 
---
  kernel/trace/trace.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 815c878..dba0e3d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1003,7 +1003,7 @@ __update_max_tr(struct trace_array *tr, struct 
task_struct *tsk, int cpu)
else
max_data->uid = task_uid(tsk);
  
-	max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO;

+   max_data->nice = task_nice(tsk);

task_nice() is still an extern function in mainline, and this is the
tracing side. I rather wait till it becomes inline in Linus's tree
before I take this.


Sounds reasonable to me.

Thanx.


-- Steve


max_data->policy = tsk->policy;
max_data->rt_priority = tsk->rt_priority;
  

--
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/



--
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/

[map_pages] 66431c4de99: -55.4% proc-vmstat.pgfault

[Fengguang Wu]

Hi Kirill,

FYI, we noticed decreased page faults and increased mapped pages on

git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 66431c4de9921a9b3c7f3556bada4285912aedb7 ("mm: implement ->map_pages for 
page cache")

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
591248 ~ 0% -56.1% 259664 ~ 0%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
   5090162 ~ 0% -55.4%2272005 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
   5681411 ~ 0% -55.4%2531670 ~ 0%  TOTAL proc-vmstat.pgfault

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  1413 ~ 0% +95.2%   2759 ~ 1%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
  1458 ~ 0% +94.4%   2835 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  2872 ~ 0% +94.8%   5594 ~ 1%  TOTAL time.maximum_resident_set_size

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  4332 ~ 0% +48.9%   6449 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  4332 ~ 0% +48.9%   6449 ~ 0%  TOTAL numa-meminfo.node1.Mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  1082 ~ 0% +48.9%   1612 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  1082 ~ 0% +48.9%   1612 ~ 0%  TOTAL numa-vmstat.node1.nr_mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  4349 ~ 0% +48.6%   6465 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  4349 ~ 0% +48.6%   6465 ~ 0%  TOTAL numa-meminfo.node0.Mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  1087 ~ 0% +48.7%   1616 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  1087 ~ 0% +48.7%   1616 ~ 0%  TOTAL numa-vmstat.node0.nr_mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  7426 ~ 0% +45.1%  10773 ~ 0%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
  8682 ~ 0% +48.7%  12911 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
 16108 ~ 0% +47.0%  23684 ~ 0%  TOTAL meminfo.Mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  1852 ~ 0% +45.4%   2693 ~ 0%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
  2170 ~ 0% +48.7%   3227 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  4022 ~ 0% +47.2%   5921 ~ 0%  TOTAL proc-vmstat.nr_mapped

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  0.93 ~ 4% +24.2%   1.15 ~ 5%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  0.93 ~ 4% +24.2%   1.15 ~ 5%  TOTAL 
perf-profile.cpu-cycles.vfs_write.sys_write.system_call_fastpath.write

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  1968 ~ 0% +17.5%   2313 ~ 1%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
  1968 ~ 0% +17.5%   2313 ~ 1%  TOTAL proc-vmstat.pgactivate

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  3.34 ~ 1% -10.7%   2.98 ~ 2%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
  3.34 ~ 1% -10.7%   2.98 ~ 2%  TOTAL 
perf-profile.cpu-cycles.ext4_mark_iloc_dirty.ext4_mark_inode_dirty.ext4_dirty_inode.__mark_inode_dirty.generic_write_end

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
  3258 ~ 0% -59.1%   1331 ~ 0%  
lkp-t410/micro/netperf/120s-200%-TCP_MAERTS
162827 ~ 0% -59.3%  66299 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
166085 ~ 0% -59.3%  67630 ~ 0%  TOTAL time.minor_page_faults

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
   5093318 ~ 0% -55.7%2257903 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
   5093318 ~ 0% -55.7%2257903 ~ 0%  TOTAL perf-stat.minor-faults

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
   5092110 ~ 0% -55.7%2257193 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
   5092110 ~ 0% -55.7%2257193 ~ 0%  TOTAL perf-stat.page-faults

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
 3.698e+11 ~ 0% -11.3%   3.28e+11 ~ 0%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
 3.698e+11 ~ 0% -11.3%   3.28e+11 ~ 0%  TOTAL 
perf-stat.L1-icache-load-misses

c9161c06019b342  66431c4de9921a9b3c7f3556b  
---  -  
 45.26 ~ 3%  +8.4%  49.05 ~ 3%  
lkp-ws02/micro/dd-write/11HDD-JBOD-cfq-ext4-10dd
 45.26 ~ 3%  +8.4%  49.05 ~ 3%  TOTAL iostat.sdd.wrqm/s

c9161c06019b342  

Re: [PATCH 3/3] sched: Use clamp() and clamp_val() to make it more readable.

[Dongsheng Yang]

On 03/19/2014 10:16 AM, Steven Rostedt wrote:

On Wed, 12 Mar 2014 18:26:44 +0800
Dongsheng Yang  wrote:


As Kees suggested, I use clamp() function to replace the if and
else branch, making it more readable and modular.

Suggested-by: Kees Cook 
Signed-off-by: Dongsheng Yang 
---
  kernel/sched/core.c | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 259ab85..85f4231 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3068,17 +3068,10 @@ SYSCALL_DEFINE1(nice, int, increment)
 * We don't have to worry. Conceptually one call occurs first
 * and we have a single winner.
 */
-   if (increment < -NICE_WIDTH)
-   increment = -NICE_WIDTH;
-   if (increment > NICE_WIDTH)
-   increment = NICE_WIDTH;
-

Patch 2 and 3 need to be merged into a single patch.


Okey, I will squash them into one.

Thanx


-- Steve


+   increment = clamp(increment, -NICE_WIDTH, NICE_WIDTH);
nice = task_nice(current) + increment;
-   if (nice < MIN_NICE)
-   nice = MIN_NICE;
-   if (nice > MAX_NICE)
-   nice = MAX_NICE;
  
+	nice = clamp_val(nice, MIN_NICE, MAX_NICE);

if (increment < 0 && !can_nice(current, nice))
return -EPERM;
  




--
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: bad rss-counter message in 3.14rc5

[Hugh Dickins]

On Tue, 18 Mar 2014, Dave Jones wrote:
> On Tue, Mar 18, 2014 at 10:06:02PM -0400, Dave Jones wrote:
>  > On Tue, Mar 18, 2014 at 09:32:36PM -0400, Sasha Levin wrote:
>  >  
>  >  > > Untested patch below: I can't quite say Reported-by, because it may
>  >  > > not even be one that you and Sasha have been seeing; but I'm hopeful,
>  >  > > remap_file_pages is in the list.
>  >  > >
>  >  > > Please give this a try, preferably on 3.14-rc or earlier: I've never
>  >  > > seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
>  >  > > a lot more than most of us); but have seen them on mmotm/next, so
>  >  > > some other trigger is coming up there, I'll worry about that once
>  >  > > it reaches 3.15-rc.
>  >  > 
>  >  > The patch fixed the "Bad rss-counter" errors I've been seeing both in
>  >  > 3.14-rc7 and -next.
>  >  
>  > It's looking good here too so far. I'll leave it running overnight to be 
> sure.
> 
> Of course, that isn't going to happen. Immediately after posting this, I hit 
> the
> swapops bug.  Patch does seem to have cured the bad rss counters though.

Another positive on the rss counters, great, thanks Dave.
That encourages me to think again on the swapops BUG, but no promises.

Hugh
--
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 RFC] sched: introduce add_wait_queue_exclusive_head

[Peng Tao]

On Tue, Mar 18, 2014 at 11:47 PM, Oleg Nesterov  wrote:
> On 03/18, Peter Zijlstra wrote:
>>
>> I think we can avoid the entire function if we add
>> WQ_FLAG_LIFO and make prepare_to_wait_event() DTRT.
>
> Agreed, this looks very natural.
>
> prepare_to_wait_event(WQ_FLAG_LIFO) should probably skip all "flags == 0"
> entries before list_add(). Given that it is supposed that the users won't
> mix exclusive and !exclusive, perhaps the additional list_for_each() won't
> hurt?
>
So please allow me to summary and define the semantics of wait/wake_up
w.r.t. this.

prepare_to_wait_event(0): task is added at the head of the queue.

prepare_to_wait_event(WQ_FLAG_LIFO): task is added at the head of
exclusive queue head

prepare_to_wait_event(WQ_FLAG_EXCLUSIVE): task is added at the tail of the queue

Maybe we should rename the flags to WQ_FLAG_EXCLUSIVE_FIFO and
WQ_FLAG_EXCLUSIVE_LIFO?

>> Then we only need to teach ___wait() about this; and I suppose we could
>> make .exclusive=-1 be the LIFO flag.
>
> Or we can change ___wait_event()
>
> -   if (exclusive)
>   \
> -   __wait.flags = WQ_FLAG_EXCLUSIVE; 
>   \
> -   else  
>   \
> -   __wait.flags = 0; 
>   \
> +   __wait.flags = exclusive; 
>   \
>
> and obviously change the callers. Perhaps this argument should be renamed
> then.
>
Current __wait.flags allows possible extension to the existing
interface. If we change it to __wait.flags = exclusive, we drop the
future extensibility. Is it acceptable?

Thanks,
Tao

> But I am fine either way, just I like the idea to extend the current
> interface.
>
> Oleg.
>
--
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] sched: Use clamp() and clamp_val() to make it more readable.

[Steven Rostedt]

On Wed, 12 Mar 2014 18:26:44 +0800
Dongsheng Yang  wrote:

> As Kees suggested, I use clamp() function to replace the if and
> else branch, making it more readable and modular.
> 
> Suggested-by: Kees Cook 
> Signed-off-by: Dongsheng Yang 
> ---
>  kernel/sched/core.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 259ab85..85f4231 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3068,17 +3068,10 @@ SYSCALL_DEFINE1(nice, int, increment)
>* We don't have to worry. Conceptually one call occurs first
>* and we have a single winner.
>*/
> - if (increment < -NICE_WIDTH)
> - increment = -NICE_WIDTH;
> - if (increment > NICE_WIDTH)
> - increment = NICE_WIDTH;
> -

Patch 2 and 3 need to be merged into a single patch.

-- Steve

> + increment = clamp(increment, -NICE_WIDTH, NICE_WIDTH);
>   nice = task_nice(current) + increment;
> - if (nice < MIN_NICE)
> - nice = MIN_NICE;
> - if (nice > MAX_NICE)
> - nice = MAX_NICE;
>  
> + nice = clamp_val(nice, MIN_NICE, MAX_NICE);
>   if (increment < 0 && !can_nice(current, nice))
>   return -EPERM;
>  

--
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/3 Resend] tracing: Use inline task_nice() to get rid of an open coded implementation of it.

[Steven Rostedt]

On Wed, 12 Mar 2014 18:26:42 +0800
Dongsheng Yang  wrote:

> Function task_nice() was reimplemented as inline function, we can use it here
> to replace the open coded implementation.
> 
> Signed-off-by: Dongsheng Yang 
> cc: Steven Rostedt 
> ---
>  kernel/trace/trace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 815c878..dba0e3d 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -1003,7 +1003,7 @@ __update_max_tr(struct trace_array *tr, struct 
> task_struct *tsk, int cpu)
>   else
>   max_data->uid = task_uid(tsk);
>  
> - max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO;
> + max_data->nice = task_nice(tsk);

task_nice() is still an extern function in mainline, and this is the
tracing side. I rather wait till it becomes inline in Linus's tree
before I take this.

-- Steve

>   max_data->policy = tsk->policy;
>   max_data->rt_priority = tsk->rt_priority;
>  

--
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: [tip:x86/urgent] x86 idle: Repair large-server 50-watt idle-power regression

[Jason Low]

On Tue, Mar 18, 2014 at 2:16 AM, Peter Zijlstra  wrote:
> On Mon, Mar 17, 2014 at 05:20:10PM -0700, Davidlohr Bueso wrote:
>> On Thu, 2013-12-19 at 11:51 -0800, tip-bot for Len Brown wrote:
>> > Commit-ID:  40e2d7f9b5dae048789c64672bf3027fbb663ffa
>> > Gitweb: 
>> > http://git.kernel.org/tip/40e2d7f9b5dae048789c64672bf3027fbb663ffa
>> > Author: Len Brown 
>> > AuthorDate: Wed, 18 Dec 2013 16:44:57 -0500
>> > Committer:  H. Peter Anvin 
>> > CommitDate: Thu, 19 Dec 2013 11:47:39 -0800
>> >
>> > x86 idle: Repair large-server 50-watt idle-power regression
>>
>> FYI this commit can cause some non trivial performance regressions for
>> larger core count systems. While not surprising because of the nature of
>> the change, having intel_idle do more cacheline invalidations, I still
>> wanted to let you guys know. For instance, on a 160 core Westmere
>> system, aim7 throughput can go down in a number of tests, anywhere from
>> -10% to -25%.
>>
>> I guess it comes down to one of those performance vs energy things. And
>> sure, max_cstate can be set to overcome this, but it's still something
>> that was previously taken for granted.
>
> -10% to -25% seems a lot for a single cacheline flush. Also I would
> expect the expected idle time to be very short while running aim7. So
> could it be the cacheflush is actually taking longer than the expected
> idle time?

Can we consider conditionally skipping the cacheline flush if the
approximate average CPU idle time is very short, for instance,
something along the lines of skipping if CPU average idle time <
(sched migration cost or "cacheline_flush_penalty")?
--
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: bad rss-counter message in 3.14rc5

[Hugh Dickins]

On Tue, 18 Mar 2014, Sasha Levin wrote:
> On 03/18/2014 08:38 PM, Hugh Dickins wrote:
> > On Tue, 11 Mar 2014, Dave Jones wrote:
> > > On Tue, Mar 11, 2014 at 09:36:03PM +0400, Cyrill Gorcunov wrote:
> > >   > On Tue, Mar 11, 2014 at 01:10:45PM -0400, Dave Jones wrote:
> > >   > >  >
> > >   > >  > Dave, iirc trinity can write log file pointing which exactly
> > > syscall sequence
> > >   > >  > was passed, right? Share it too please.
> > >   > >
> > >   > > Hm, I may have been mistaken, and the damage was done by a previous
> > > run.
> > >   > > I went from being able to reproduce it almost instantly to now not
> > > being able
> > >   > > to reproduce it at all.  Will keep trying.
> > >   >
> > >   > Sasha already gave a link to the syscalls sequence, so no rush.
> > > 
> > > It'd be nice to get a more concise reproducer, his list had a little of
> > > everything in there.
> > 
> > I've so far failed to find any explanation for your swapops.h BUG;
> > but believe I have identified one cause for "Bad rss-counter"s.
> > 
> > My hunch is that the swapops.h BUG is "nearby", but I just cannot
> > fit it together (the swapops.h BUG comes when rmap cannot find all
> > all the migration entries it inserted earlier: it's a very useful
> > BUG for validating rmap).
> > 
> > Untested patch below: I can't quite say Reported-by, because it may
> > not even be one that you and Sasha have been seeing; but I'm hopeful,
> > remap_file_pages is in the list.
> > 
> > Please give this a try, preferably on 3.14-rc or earlier: I've never
> > seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
> > a lot more than most of us); but have seen them on mmotm/next, so
> > some other trigger is coming up there, I'll worry about that once
> > it reaches 3.15-rc.
> 
> The patch fixed the "Bad rss-counter" errors I've been seeing both in
> 3.14-rc7 and -next.

Great, thanks a lot, Sasha.  I was afraid that you'd hit those swapops
BUGs, which seemed perhaps to be paired with these; but glad to hear
a positive.  Let's see how Dave fares.  (I've not forgotten shmem
fallocate, by the way, but those probably aren't as high on my agenda
as you'd like.)

Hugh
--
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: bad rss-counter message in 3.14rc5

[Dave Jones]

On Tue, Mar 18, 2014 at 10:06:02PM -0400, Dave Jones wrote:
 > On Tue, Mar 18, 2014 at 09:32:36PM -0400, Sasha Levin wrote:
 >  
 >  > > Untested patch below: I can't quite say Reported-by, because it may
 >  > > not even be one that you and Sasha have been seeing; but I'm hopeful,
 >  > > remap_file_pages is in the list.
 >  > >
 >  > > Please give this a try, preferably on 3.14-rc or earlier: I've never
 >  > > seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
 >  > > a lot more than most of us); but have seen them on mmotm/next, so
 >  > > some other trigger is coming up there, I'll worry about that once
 >  > > it reaches 3.15-rc.
 >  > 
 >  > The patch fixed the "Bad rss-counter" errors I've been seeing both in
 >  > 3.14-rc7 and -next.
 >  
 > It's looking good here too so far. I'll leave it running overnight to be 
 > sure.

Of course, that isn't going to happen. Immediately after posting this, I hit the
swapops bug.  Patch does seem to have cured the bad rss counters though.

Dave

--
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/

Fitted K*itchens North London

[gelaan]

Fitted K*itchens North London w w w . e x d i s p l a y k i t c h e n s 1 . c
o . u k.  Fitted K*itchens in North London for only £595 including
appliances. Full fitted K*itchens only £595. Fitted K*itchens North London



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/Fitted-K-itchens-North-London-tp826051.html
Sent from the Linux Kernel mailing list archive at Nabble.com.
--
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: bad rss-counter message in 3.14rc5

[Hugh Dickins]

On Tue, 18 Mar 2014, Linus Torvalds wrote:
> On Tue, Mar 18, 2014 at 5:38 PM, Hugh Dickins  wrote:
> >
> > And yes, it is possible (though very unusual) to find an anon page or
> > swap entry in a VM_SHARED nonlinear mapping: coming from that horrid
> > get_user_pages(write, force) case which COWs even in a shared mapping.
> 
> Hmm. Maybe we could just disallow that forced case.
> 
> It *used* to be a trivial "we can just do a COW", but that was back
> when the VM was much simpler and we had no rmap's etc. So "that horrid
> case" used to be a simple hack that wasn't painful. But I suspect we
> could very easily just fail it instead of forcing a COW, if that would
> make it simpler for the VM code.

I'd love that, if we can get away with it now: depends very
much on whether we then turn out to break userspace or not.

If I remember correctly, it's been that way since early days,
in case ptrace were used to put a breakpoint into a MAP_SHARED
mapping of an executable: to prevent that modification from
reaching the file, if the file happened to be opened O_RDWR.
Usually it's not open for writing, and mapped MAP_PRIVATE anyway.

That is still something worth protecting against, I presume;
but I'd much rather do it by failing the awkward case,
than by perverting the VM to break its own rules.

If I'm not mistaken, Konstantin (who happens to be already on this
Cc list) had a patch (that I hated) to complicate things, to fix up
some of the inconsistencies arising from this very odd and overlooked
corner-case.  I think he'd prefer this simplification to his patch too.

I'll look into it further, but not in haste.

Hugh
--
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: bad rss-counter message in 3.14rc5

[Dave Jones]

On Tue, Mar 18, 2014 at 09:32:36PM -0400, Sasha Levin wrote:
 
 > > Untested patch below: I can't quite say Reported-by, because it may
 > > not even be one that you and Sasha have been seeing; but I'm hopeful,
 > > remap_file_pages is in the list.
 > >
 > > Please give this a try, preferably on 3.14-rc or earlier: I've never
 > > seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
 > > a lot more than most of us); but have seen them on mmotm/next, so
 > > some other trigger is coming up there, I'll worry about that once
 > > it reaches 3.15-rc.
 > 
 > The patch fixed the "Bad rss-counter" errors I've been seeing both in
 > 3.14-rc7 and -next.
 
It's looking good here too so far. I'll leave it running overnight to be sure.

Dave

--
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: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree

[Ben Widawsky]

On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote:
> On Wed, 19 Mar 2014 11:53:50 +1100
> Stephen Rothwell  wrote:
> 
> 
> > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
> > from ring buffer in evict event").
> > 
> > I have used the drm-intel tree from next-20140318 for today.
> > 
> 
> Bah! I'm still suffering from jet lag (just came back from Linux-Tage
> in Chemnitz).
> 
> The next time I compile test a patch for a module, I'll make sure I have
> that module's config option set :-(  The woe of using localmodconfig. I
> should have picked the box with the i915. :-/
> 
> Below is the fix. I'll repost a v2 of the original patch.
> 
> Sorry about that.
> 

I was about to send out the same fix when I saw this.

Reviewed-by: Ben Widawsky 

> -- Steve
> 
> diff --git a/drivers/gpu/drm/i915/i915_trace.h 
> b/drivers/gpu/drm/i915/i915_trace.h
> index f3e8a90..783ae08 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm,
>   ),
>  
>   TP_fast_assign(
> -__entry->dev = dev->primary->index;
> +__entry->dev = vm->dev->primary->index;
>  __entry->vm = vm;
> ),
>  
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ben Widawsky, Intel Open Source Technology Center
--
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] gpio: iop: fix devm_ioremap_resource() return value checking

[Alexandre Courbot]

On Tue, Mar 18, 2014 at 6:58 PM, Bartlomiej Zolnierkiewicz
 wrote:
> devm_ioremap_resource() returns a pointer to the remapped memory or
> an ERR_PTR() encoded error code on failure.  Fix the check inside
> iop3xx_gpio_probe() accordingly.

Acked-by: Alexandre Courbot 
--
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/12] scsi/NCR5380: fix debugging macros and #include structure

[Joe Perches]

On Wed, 2014-03-19 at 12:46 +1100, Finn Thain wrote:
> On Tue, 18 Mar 2014, Joe Perches wrote:
> 
> > But using "if (0)" prevents the no_printk from occurring at all so there 
> > would be no side-effects and the format & args would still be verified 
> > by the compiler.
> 
> I'd prefer this (for symmetry and clarity):
> 
> #if NDEBUG
> #define dprintk(flg, fmt, ...) \
> do { if ((NDEBUG) & (flg)) pr_debug(fmt, ## __VA_ARGS__); } while (0)
> #else
> #define dprintk(flg, fmt, ...) \
> do { if (0) pr_debug(fmt, ## __VA_ARGS__); } while (0)
> #endif
> 
> But you seem to be asking for this instead:
> 
> #if NDEBUG
> #define dprintk(flg, fmt, ...) \
> do { if ((NDEBUG) & (flg)) pr_debug(fmt, ## __VA_ARGS__); } while (0)
> #else
> #define dprintk(flg, fmt, ...) \
> do { if (0) no_printk(fmt, ## __VA_ARGS__); } while (0)
> #endif
> 
> Why is that better?

It's not to me.

I suggested exactly your first block with if (0) pr_debug...
in the first thing I wrote.

https://lkml.org/lkml/2014/3/18/216

Geert suggested no_printk.

cheers, Joe


--
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] Documentation: LLVMLinux: Update Documentation/dontdiff

[behanw]

From: Jan-Simon Möller 

Clang has a few other kinds of derived files which shouldn't be added to a
patch. Add them to the Documentation/dontdiff file to prevent this.

Signed-off-by: Jan-Simon Möller 
Signed-off-by: Behan Webster 
Cc: PaX Team 
---
 Documentation/dontdiff | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index b89a739..9de9813 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -1,5 +1,6 @@
 *.a
 *.aux
+*.bc
 *.bin
 *.bz2
 *.cis
@@ -21,6 +22,7 @@
 *.i
 *.jpeg
 *.ko
+*.ll
 *.log
 *.lst
 *.lzma
@@ -35,6 +37,7 @@
 *.out
 *.patch
 *.pdf
+*.plist
 *.png
 *.pot
 *.ps
-- 
1.8.3.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/

[PATCH v3] net: netfilter: LLVMLinux: vlais-netfilter

[behanw]

From: Mark Charlebois 

Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in
xt_repldata.h with a C99 compliant flexible array member and then calculated
offsets to the other struct members. These other members aren't referenced by
name in this code, however this patch maintains the same memory layout and
padding as was previously accomplished using VLAIS.

Had the original structure been ordered differently, with the entries VLA at
the end, then it could have been a flexible member, and this patch would have
been a lot simpler. However since the data stored in this structure is
ultimately exported to userspace, the order of this structure can't be changed.

This patch makes no attempt to change the existing behavior, merely the way in
which the current layout is accomplished using standard C99 constructs. As such
the code can now be compiled with either gcc or clang.

Author: Mark Charlebois 
Signed-off-by: Mark Charlebois 
Signed-off-by: Behan Webster 
Signed-off-by: Vinícius Tinti 
---
 net/netfilter/xt_repldata.h | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/xt_repldata.h b/net/netfilter/xt_repldata.h
index 6efe4e5..343599e 100644
--- a/net/netfilter/xt_repldata.h
+++ b/net/netfilter/xt_repldata.h
@@ -5,23 +5,40 @@
  * they serve as the hanging-off data accessed through repl.data[].
  */
 
+/* tbl has the following structure equivalent, but is C99 compliant:
+ * struct {
+ * struct type##_replace repl;
+ * struct type##_standard entries[nhooks];
+ * struct type##_error term;
+ * } *tbl;
+ */
+
 #define xt_alloc_initial_table(type, typ2) ({ \
unsigned int hook_mask = info->valid_hooks; \
unsigned int nhooks = hweight32(hook_mask); \
unsigned int bytes = 0, hooknum = 0, i = 0; \
struct { \
struct type##_replace repl; \
-   struct type##_standard entries[nhooks]; \
-   struct type##_error term; \
-   } *tbl = kzalloc(sizeof(*tbl), GFP_KERNEL); \
+   struct type##_standard entries[]; \
+   } *tbl; \
+   struct type##_error *term; \
+   size_t entries_end = offsetof(typeof(*tbl), \
+   entries[nhooks-1]) + sizeof(tbl->entries[0]); \
+   size_t term_offset = (entries_end + __alignof__(*term) - 1) \
+   & ~(__alignof__(*term) - 1); \
+   size_t term_end = term_offset + sizeof(*term); \
+   size_t tbl_sz = (term_end + __alignof__(tbl->repl) - 1) \
+   & ~(__alignof__(tbl->repl) - 1); \
+   tbl = kzalloc(tbl_sz, GFP_KERNEL); \
if (tbl == NULL) \
return NULL; \
+   term = (struct type##_error *)&(((char *)tbl)[term_offset]); \
strncpy(tbl->repl.name, info->name, sizeof(tbl->repl.name)); \
-   tbl->term = (struct type##_error)typ2##_ERROR_INIT;  \
+   *term = (struct type##_error)typ2##_ERROR_INIT;  \
tbl->repl.valid_hooks = hook_mask; \
tbl->repl.num_entries = nhooks + 1; \
tbl->repl.size = nhooks * sizeof(struct type##_standard) + \
-sizeof(struct type##_error); \
+sizeof(struct type##_error); \
for (; hook_mask != 0; hook_mask >>= 1, ++hooknum) { \
if (!(hook_mask & 1)) \
continue; \
-- 
1.8.3.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] gpiolib: check if gpio_desc pointer is error or NULL

[Alexandre Courbot]

On Tue, Mar 18, 2014 at 7:41 PM, Ben Dooks  wrote:
> Some of the gpiod_ calls take a pointer to a gpio_desc as their
> argument but only check to see if it is NULL to validate the
> input.
>
> Calls such as devm_gpiod_get() return an error-pointer if they
> fail, so doing the following will not work:
>
> gpio = devm_gpiod_get(...);
> gpiod_direction_output(gpio, 0);
>
> The sequence produces an OOPS like:
>
> Unable to handle kernel paging request at virtual address fffe
>
> Change all calls that check for !desc to use IS_ERR_OR_NULL() to
> avoid these issues.

This change is certainly correct from a semantics point of view. Maybe
I'd argue that the burden is on the caller to check that gpiod_get()
returns a valid GPIO descriptor, but having extra security doesn't
hurt. However my problem with this change in its current form is that
it will hide such forgetfulnesses by making functions like
gpiod_get_value() fail silently instead of triggering a oops.

Could you make sure that any call of a gpiolib function on a non-valid
descriptor raises at least a message in the console, and while you are
at it harmonize the way these messages are output? Right now we are
using pr_debug(), pr_warn() or WARN_ON() depending on the location. I
would say that using an invalid GPIO descriptor is offending enough
that it should trigger a stack dump at every attempt.
--
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/PATCHSET 00/14] perf report: Add -F option for specifying output fields (v2)

[Namhyung Kim]

On Wed, Mar 19, 2014 at 1:43 AM, David Ahern  wrote:
> On 3/18/14, 7:30 PM, Namhyung Kim wrote:
>>
>> Hi David,
>>
>> On Tue, Mar 18, 2014 at 3:07 PM, David Ahern  wrote:
>>>
>>> On 3/18/14, 12:32 AM, Namhyung Kim wrote:


 This is a patchset implementing -F/--field option to setup output
 field/column as Ingo requested.  It depends on my perf/percentage
 patchset (with minor updates) [1].
>>>
>>>
>>>
>>> perf-report should be consistent with perf-script which uses --fields.
>>
>>
>> Right.  Did you mean s/--field/--fields/ then?
>
>
> yes. consistency is huge.

Okay, I'll keep that in mind.  Actually I wasn't aware of the
'perf-script --fields' when working on this. :)

Thanks,
Namhyung
--
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/12] scsi/NCR5380: fix debugging macros and #include structure

[Finn Thain]

On Tue, 18 Mar 2014, Joe Perches wrote:

> But using "if (0)" prevents the no_printk from occurring at all so there 
> would be no side-effects and the format & args would still be verified 
> by the compiler.

I'd prefer this (for symmetry and clarity):

#if NDEBUG
#define dprintk(flg, fmt, ...) \
do { if ((NDEBUG) & (flg)) pr_debug(fmt, ## __VA_ARGS__); } while (0)
#else
#define dprintk(flg, fmt, ...) \
do { if (0) pr_debug(fmt, ## __VA_ARGS__); } while (0)
#endif

But you seem to be asking for this instead:

#if NDEBUG
#define dprintk(flg, fmt, ...) \
do { if ((NDEBUG) & (flg)) pr_debug(fmt, ## __VA_ARGS__); } while (0)
#else
#define dprintk(flg, fmt, ...) \
do { if (0) no_printk(fmt, ## __VA_ARGS__); } while (0)
#endif

Why is that better?

-- 
--
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 v3]DM: dm-insitu-comp: a compressed DM target for SSD

[Shaohua Li]

On Tue, Mar 18, 2014 at 05:28:43PM -0400, Mike Snitzer wrote:
> On Tue, Mar 18 2014 at  3:41am -0400,
> Shaohua Li  wrote:
> 
> > On Mon, Mar 17, 2014 at 04:00:40PM -0400, Mike Snitzer wrote:
> > > 
> > > I folded your changes in, and then committed a patch ontop that cleans
> > > some code up.  But added 2 FIXMEs that still speak to pretty fundamental
> > > problems with the architecture of the dm-insitu-comp target, see:
> > > https://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=for-3.15-insitu-comp=8565ab6b04837591d03c94851c2f9f9162ce12f4
> > > 
> > > Unfortunately the single insitu_comp_wq workqueue that all insitu-comp
> > > targets are to share isn't a workable solution.  Each target needs to
> > > have resource isolation from other targets (imagine insitu-comp used for
> > > multiple SSDs).  This is important for suspend too because you'll need
> > > to flush/stop the workqueue.
> > 
> > Is this just because of suspend? I didn't see fundamental reason why the
> > workqueue can't be shared even for several targets.
> 
> I'm not seeing how you are guaranteeing that all queued work is
> completed during suspend.  insitu_comp_queue_req() just calls
> queue_work_on().
> 
> BTW, queue_work_on()'s comment above its implementation says:
> "We queue the work to a specific CPU, the caller must ensure it can't go
> away." -- you're not able to insure a cpu isn't hotplugged so... but I
> also see you've used it in your raid5 perf improvement changes so you
> obviously have experience with using this interface.

Good point, I did miss this. the raid5 case hold a lock, while this case
doesn't. A fix is attached below.

> > > You introduced a state machine for tracking suspending, suspended,
> > > resumed.  This really isn't necessary.  During suspend you need to
> > > flush_workqueue().  On resume you shouldn't need to do anything special.
> > > 
> > > As I noted in the commit, the thin and cache targets can serve as
> > > references for how you can manage the workqueue across suspend/resume
> > > and the lifetime of these workqueues relative to .ctr and .dtr.
> > 
> > As far as I checking the code, .postsuspend is called after all requests are
> > finished. This already guarantees no pending requests running in insitu-comp
> > workqueue.
> 
> I could easily be missing something obvious, but I don't see where that
> guarantee is implemented.

Alright, so this is the divergence. dm_suspend() calls dm_wait_for_completion()
and then dm_table_postsuspend_targets(). As far as I understand,
dm_wait_for_completion() will wait all pending requests to finish. The comments
declaim this too. Am I missing anything?

Basically the two kinds of IO. IO requests from upper layer, which
dm_wait_for_completion() will guarantee they are finished. Metadata IO
requests, which .postsuspend should make sure they are finished.
 
> > Doing a workqueue flush isn't required. The writeback thread is
> > running in background and waiting for requests completion can't guarantee 
> > the
> > thread isn't running, so we must make sure it is safely parked.
> 
> Sure, but you don't need a state machine to do that.  The DM core takes
> care of calling these hooks, so you just need to stop the writeback
> thread during suspend and (re)start/kick it on resume (preresume).

Yep, I need wait the writeback thread finish all pending metadata IO, the state
machine works well here.


---
 drivers/md/dm-insitu-comp.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Index: linux/drivers/md/dm-insitu-comp.c
===
--- linux.orig/drivers/md/dm-insitu-comp.c  2014-03-17 17:40:01.106660303 
+0800
+++ linux/drivers/md/dm-insitu-comp.c   2014-03-19 08:49:12.314627050 +0800
@@ -704,14 +704,19 @@ static void insitu_comp_queue_req(struct
  struct insitu_comp_req *req)
 {
unsigned long flags;
-   struct insitu_comp_io_worker *worker =
-   _comp_io_workers[req->cpu];
+   struct insitu_comp_io_worker *worker;
+
+   preempt_disable();
+   if (!cpu_online(req->cpu))
+   req->cpu = cpumask_any(cpu_online_mask);
+   worker = _comp_io_workers[req->cpu];
 
spin_lock_irqsave(>lock, flags);
list_add_tail(>sibling, >pending);
spin_unlock_irqrestore(>lock, flags);
 
queue_work_on(req->cpu, insitu_comp_wq, >work);
+   preempt_enable();
 }
 
 static void insitu_comp_queue_req_list(struct insitu_comp_info *info,
--
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/PATCHSET 00/14] perf report: Add -F option for specifying output fields (v2)

[David Ahern]

On 3/18/14, 7:30 PM, Namhyung Kim wrote:

Hi David,

On Tue, Mar 18, 2014 at 3:07 PM, David Ahern  wrote:

On 3/18/14, 12:32 AM, Namhyung Kim wrote:


This is a patchset implementing -F/--field option to setup output
field/column as Ingo requested.  It depends on my perf/percentage
patchset (with minor updates) [1].



perf-report should be consistent with perf-script which uses --fields.


Right.  Did you mean s/--field/--fields/ then?


yes. consistency is huge.

--
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/

Occational random segfault on Cortex-A15 when exiting SIGCHLD handler.

[Lennart Sorensen]

I have been trying to track down the cause of some random segfaults for
the last couple of weeks.  They were mostly showing up in one particular
program (confdc which is part of confd from tail-f, but is essentially
just the erlang 14 VM with some erlang modules running and the segfault
is happening in the main erlang code).  I have also seen occasional
segfaults in gcc and even gdb.

The system is a dra7xx-evm from TI (so an eval board for
the next OMAP5 chip), running a 3.8.13 based kernel from
git://git.omapzoom.org/kernel/omap.git (they are working on mainlining
the patches, but that's not done yet as far as I can tell) branch
p-ti-linux-3.8.y

The CPU has dual Cortex-A15 at 1.5GHz.  Core revision is r2p2.

The userspace is Debian Wheezy armhf.  Running the exact same code
(except the kernel) on a cubox never segfaults.  I initially wondered if
the hardware had a problem, but the failures seem too consistent to be
a random hardware failure, and nothing else ever seems to get corrupted.

The gdb backtraces from failures so far all indicated that there is a
segfault when exiting the SIGCHLD handler, which given it is happening
in multiple different programs seems like it can't just be a coincidence.

Some example traces:

gdb dying after running it a few thousand times with the same arguments
and not failing:

(wheezydev)root@omap5:~/rmf# gdb `which gdb` ./core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/gdb...done.
[New LWP 11964]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `gdb /usr/lib/confd/bin/confd mibs/core'.
Program terminated with signal 11, Segmentation fault.
#0  0x in ?? ()
(gdb) where
#0  0x in ?? ()
#1  0x00095a1e in sigchld_handler (signo=) at /root/gdb-7.4.1+dfsg/gdb/linux-nat.c:5530
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)

The code in question there is:

5511 /* SIGCHLD handler that serves two purposes: In non-stop/async mode,
5512so we notice when any child changes state, and notify the
5513event-loop; it allows us to use sigsuspend in linux_nat_wait_1
5514above to wait for the arrival of a SIGCHLD.  */
5515
5516 static void
5517 sigchld_handler (int signo)
5518 {
5519   int old_errno = errno;
5520
5521   if (debug_linux_nat)
5522 ui_file_write_async_safe (gdb_stdlog,
5523   "sigchld\n", sizeof ("sigchld\n") - 1);
5524
5525   if (signo == SIGCHLD
5526   && linux_nat_event_pipe[0] != -1)
5527 async_file_mark (); /* Let the event loop know that there are
5528events to handle.  */
5529
5530   errno = old_errno;
5531 }

And from the erlang/confd case:

(wheezydev)root@omap5:~/rmf# gdb /usr/lib/confd/bin/confd mibs/core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/confd/bin/confd...done.
[New LWP 29581]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Core was generated by `/usr/lib/confd/bin/confd -B -- -root /usr/lib/confd 
-progname confd -- -home /r'.
Program terminated with signal 11, Segmentation fault.
#0  0x in ?? ()
(gdb) where
#0  0x in ?? ()
#1  0x000b95ea in onchld (signum=) at sys/unix/sys.c:1150
#2  
#3  0x000efd4c in __udivsi3 ()
#4  0x000efdf0 in __aeabi_uidivmod ()
#5  0x000efdf0 in __aeabi_uidivmod ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The code there is:
1138 #if (defined(SIG_SIGSET) || defined(SIG_SIGNAL))
1139 static RETSIGTYPE onchld(void)
1140 #else
1141 static RETSIGTYPE onchld(int signum)
1142 #endif
1143 {
1144 #if CHLDWTHR
1145 ASSERT(0); /* We should *never* catch a SIGCHLD signal */
1146 #elif defined(ERTS_SMP)
1147 smp_sig_notify('C');
1148 #else
1149 children_died = 1;
1150 ERTS_CHK_IO_INTR(1); /* Make sure we don't sleep in poll */
1151 #endif
1152 }

CHLDWTHR and ERTS_SMP are NOT defined/true in this case, so the last
lines are the ones in use.

I have tried to use strace on the process, and 

Re: [PATCH v11 24/27] iommu/exynos: use exynos-iommu specific typedef

[Grant Grundler]

On Thu, Mar 13, 2014 at 10:13 PM, Cho KyongHo  wrote:
> This commit introduces sysmmu_pte_t for page table entries and
> sysmmu_iova_t vor I/O virtual address that is manipulated by
> exynos-iommu driver. The purpose of the typedef is to remove
> dependencies to the driver code from the change of CPU architecture
> from 32 bit to 64 bit.

hi Cho,
I noticed this before but understood this code was only compiled for
ILP-32 programming model. I'm assuming that is going to change in the
not-to-distant future. Good. :)

>
> Signed-off-by: Cho KyongHo 
> ---
>  drivers/iommu/exynos-iommu.c |  103 
> ++
>  1 file changed, 54 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index e375501..6e716cc 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -56,19 +56,19 @@
>  #define lv2ent_large(pent) ((*(pent) & 3) == 1)
>
>  #define section_phys(sent) (*(sent) & SECT_MASK)
> -#define section_offs(iova) ((iova) & 0xF)
> +#define section_offs(iova) ((sysmmu_iova_t)(iova) & 0xF)

The cast will mask abuses of iova. Define section_offs as a static
function and GCC can type check iova parameter to make sure it's a
sysmmu_iova_t.
Thoughts?

I was thinking "((iova) & (sysmmu_iova_t) 0XF)" might do what you
want but it doesn't warn on abuse that I tried. I believe GCC knows
the upper bits are being ignored.

cheers,
grant
--
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: bad rss-counter message in 3.14rc5

[Sasha Levin]

On 03/18/2014 08:38 PM, Hugh Dickins wrote:

On Tue, 11 Mar 2014, Dave Jones wrote:

On Tue, Mar 11, 2014 at 09:36:03PM +0400, Cyrill Gorcunov wrote:
  > On Tue, Mar 11, 2014 at 01:10:45PM -0400, Dave Jones wrote:
  > >  >
  > >  > Dave, iirc trinity can write log file pointing which exactly syscall 
sequence
  > >  > was passed, right? Share it too please.
  > >
  > > Hm, I may have been mistaken, and the damage was done by a previous run.
  > > I went from being able to reproduce it almost instantly to now not being 
able
  > > to reproduce it at all.  Will keep trying.
  >
  > Sasha already gave a link to the syscalls sequence, so no rush.

It'd be nice to get a more concise reproducer, his list had a little of 
everything in there.


I've so far failed to find any explanation for your swapops.h BUG;
but believe I have identified one cause for "Bad rss-counter"s.

My hunch is that the swapops.h BUG is "nearby", but I just cannot
fit it together (the swapops.h BUG comes when rmap cannot find all
all the migration entries it inserted earlier: it's a very useful
BUG for validating rmap).

Untested patch below: I can't quite say Reported-by, because it may
not even be one that you and Sasha have been seeing; but I'm hopeful,
remap_file_pages is in the list.

Please give this a try, preferably on 3.14-rc or earlier: I've never
seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
a lot more than most of us); but have seen them on mmotm/next, so
some other trigger is coming up there, I'll worry about that once
it reaches 3.15-rc.


The patch fixed the "Bad rss-counter" errors I've been seeing both in
3.14-rc7 and -next.


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: [RFC/PATCHSET 00/14] perf report: Add -F option for specifying output fields (v2)

[Namhyung Kim]

Hi David,

On Tue, Mar 18, 2014 at 3:07 PM, David Ahern  wrote:
> On 3/18/14, 12:32 AM, Namhyung Kim wrote:
>>
>> This is a patchset implementing -F/--field option to setup output
>> field/column as Ingo requested.  It depends on my perf/percentage
>> patchset (with minor updates) [1].
>
>
> perf-report should be consistent with perf-script which uses --fields.

Right.  Did you mean s/--field/--fields/ then?

Thanks,
Namhyung
--
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] pwm: add support for Intel Low Power Subsystem PWM

[Chew, Chiau Ee]

> On Fri, Feb 28, 2014 at 10:50:57PM +0800, Chew Chiau Ee wrote:
> > From: Mika Westerberg 
> >
> > Add support for Intel Low Power I/O subsystem PWM controllers found on
> > Intel BayTrail SoC.
> >
> > Signed-off-by: Mika Westerberg 
> > Signed-off-by: Chew, Kean Ho 
> > Signed-off-by: Chang, Rebecca Swee Fun
> > 
> > Signed-off-by: Chew, Chiau Ee 
> > ---
> >  drivers/pwm/Kconfig|   10 +++
> >  drivers/pwm/Makefile   |1 +
> >  drivers/pwm/pwm-lpss.c |  179
> > 
> >  3 files changed, 190 insertions(+), 0 deletions(-)  create mode
> > 100644 drivers/pwm/pwm-lpss.c
> 
> Sorry for taking so long to get back to you on this. Things have been somewhat
> crazy lately.
> 
> This generally looks very good, but I found two issues that escaped last time.
> See below.
>
> > diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> [...]
> > +static int pwm_lpss_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > +  int duty_ns, int period_ns)
> > +{
> > +   struct pwm_lpss_chip *lpwm = to_lpwm(chip);
> > +   u8 on_time_div;
> > +   unsigned long c = clk_get_rate(lpwm->clk);
> > +   unsigned long long base_unit, freq = NSECS_PER_SEC;
> > +   u32 ctrl;
> > +
> > +   do_div(freq, period_ns);
> > +
> > +   /* The equation is: base_unit = ((freq / c) * 65536) + correction */
> > +   base_unit = freq * 65536;
> > +   do_div(base_unit, c);
> 
> clk_get_rate() can return 0, so perhaps it would be safer to check for the
> validity of c before dividing by it. This will probably never happen for your
> driver or platform, but people may look at your driver for inspiration at some
> point, so it should still be handling this correctly.

Agreed. Will update the code accordingly.

> > +MODULE_DESCRIPTION("PWM driver for Intel LPSS");
> MODULE_AUTHOR("Mika
> > +Westerberg ");
> > +MODULE_LICENSE("GPLv2");
> 
> I think this needs to be "GPL v2".

Ok. Will update this as well.

Thanks for your review!

> 
> Thierry
--
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] drm/i915: Do not dereference pointers from ring buffer in evict event

[Steven Rostedt]

The TP_printk() should never dereference any pointers, because the ring
buffer can be read at some unknown time in the future. If a device no
longer exists, it can cause a kernel oops. This also makes this
event useless when saving the ring buffer in userspaces tools such as
perf and trace-cmd.

The i915_gem_evict_vm dereferences the vm pointer which may also not
exist when the ring buffer is read sometime in the future.

Link: 
http://lkml.kernel.org/r/1395095198-20034-3-git-send-email-artag...@gmail.com
Reported-by: Ramkumar Ramachandra 
Cc: sta...@vger.kernel.org # 3.13+
Fixes: bcccff847d1f "drm/i915: trace vm eviction instead of everything"
Signed-off-by: Steven Rostedt 
---
v2 - fixed build bug. This time tested on a box with an i915.

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index 6e580c9..783ae08 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -238,14 +238,16 @@ TRACE_EVENT(i915_gem_evict_vm,
TP_ARGS(vm),
 
TP_STRUCT__entry(
+__field(u32, dev)
 __field(struct i915_address_space *, vm)
),
 
TP_fast_assign(
+  __entry->dev = vm->dev->primary->index;
   __entry->vm = vm;
  ),
 
-   TP_printk("dev=%d, vm=%p", __entry->vm->dev->primary->index, 
__entry->vm)
+   TP_printk("dev=%d, vm=%p", __entry->dev, __entry->vm)
 );
 
 TRACE_EVENT(i915_gem_ring_sync_to,
--
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: linux-next: build failure after merge of the drm-intel tree

[Steven Rostedt]

On Wed, 19 Mar 2014 11:53:50 +1100
Stephen Rothwell  wrote:


> Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
> from ring buffer in evict event").
> 
> I have used the drm-intel tree from next-20140318 for today.
> 

Bah! I'm still suffering from jet lag (just came back from Linux-Tage
in Chemnitz).

The next time I compile test a patch for a module, I'll make sure I have
that module's config option set :-(  The woe of using localmodconfig. I
should have picked the box with the i915. :-/

Below is the fix. I'll repost a v2 of the original patch.

Sorry about that.

-- Steve

diff --git a/drivers/gpu/drm/i915/i915_trace.h 
b/drivers/gpu/drm/i915/i915_trace.h
index f3e8a90..783ae08 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm,
),
 
TP_fast_assign(
-  __entry->dev = dev->primary->index;
+  __entry->dev = vm->dev->primary->index;
   __entry->vm = vm;
  ),
 
--
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: [drbd] Kernel panic - not syncing: Out of memory and no killable processes...

[Fengguang Wu]

Hi Philipp,

On Tue, Mar 18, 2014 at 03:30:16PM +0100, Lars Ellenberg wrote:
> On Tue, Mar 18, 2014 at 10:07:17PM +0800, Fengguang Wu wrote:
> > Greetings,
> > 
> > We get the below OOM errors in our KVM boot tests and they are
> > bisected to
> > 
> > commit 23361cf32b58efdf09945a64e1d8d41fa6117157
> 
> We have been there before:

Yeah, sorry I forgot that.. Just tried the suggested
"drbd.minor_count=8" and it helps! Thank you all for the tip!

Cheers,
Fengguang

> .---
> | Date: Wed, 12 Jun 2013 18:11:43 +0800
> | From: Fengguang Wu 
> | To: Philipp Reisner , 
> drbd-u...@lists.linbit.com, linux-kernel@vger.kernel.org
> | Subject: Re: [drbd?] Kernel panic - not syncing: Out of memory and no 
> killable processes...
> | Message-ID: <20130612101143.GA13837@localhost>
> | 
> | On Tue, Jun 11, 2013 at 05:33:27PM +0200, Lars Ellenberg wrote:
> | > On Fri, Jun 07, 2013 at 10:31:54AM +0800, Fengguang Wu wrote:
> | > > Greetings,
> | > >
> | > > My "kvm -m 256" reliably goes Out Of Memory after this commit.  It may
> | > > not be the only one that eats up the memory, however I wonder how much
> | > > memory consumption this commit added? Thanks!
> 
> ...
> 
> | > We scale certain mempools and reserves with
> | > DRBD_MAX_BIO_SIZE/PAGE_SIZE * minor_count.
> | >
> | > DRBD_MAX_BIO_SIZE has been increased by this patch,
> | > resulting in more memory allocated to those reserved pools.
> | >
> | > Please just scale down the "minor_count" parameter.
> | > You can use the module parameter (e.g. modprobe drbd minor_count=8),
> | > or, compiled in, use the kernel command line parameter drbd.minor_count=8.
> | >
> | > Though "minor_count" at some point used to be the hard limit for the 
> number of
> | > minor devices (allocation of an array of corresponding size), that has
> | > long since changed, and now it is really only used as scaling factor for
> | > these mempools.
> | 
> | Got it, thank you very much for the helpful tips and explanations!
> | I'll add the drbd.minor_count=8 option.
> | 
> | Thanks,
> | Fengguang
> `---
> 
> Does that help?
> 
> -- 
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> 
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
--
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 v3 1/3] clk: s2mps11: Add support for S2MPS14 clocks

[Mike Turquette]

On Tue, Mar 18, 2014 at 6:09 PM, Mike Turquette  wrote:
> Quoting Krzysztof Kozlowski (2014-03-17 02:19:16)
>> This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
>> s2mps11 clock driver.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> Reviewed-by: Yadwinder Singh Brar 
>> Reviewed-by: Tomasz Figa 
>
> Taken into clk-next.

Oops. Please disregard. My auto patch application script sent his by
accident. I have not applied this patches, as indicated in my previous
mail were I gave out an Ack.

Regards,
Mike

>
> Regards,
> Mike
>
>> ---
>>  drivers/clk/Kconfig   |8 +++---
>>  drivers/clk/clk-s2mps11.c |   61 
>> ++---
>>  2 files changed, 50 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index 6f56d3a4f010..8f9ce8ba036d 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -65,12 +65,12 @@ config COMMON_CLK_SI570
>>   clock generators.
>>
>>  config COMMON_CLK_S2MPS11
>> -   tristate "Clock driver for S2MPS11/S5M8767 MFD"
>> +   tristate "Clock driver for S2MPS1X/S5M8767 MFD"
>> depends on MFD_SEC_CORE
>> ---help---
>> - This driver supports S2MPS11/S5M8767 crystal oscillator clock. 
>> These
>> - multi-function devices have 3 fixed-rate oscillators, clocked at
>> - 32KHz each.
>> + This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
>> + clock. These multi-function devices have two (S2MPS14) or three
>> + (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
>>
>>  config CLK_TWL6040
>> tristate "External McPDM functional clock from twl6040"
>> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
>> index 508875535e1e..8dafb552274f 100644
>> --- a/drivers/clk/clk-s2mps11.c
>> +++ b/drivers/clk/clk-s2mps11.c
>> @@ -1,7 +1,7 @@
>>  /*
>>   * clk-s2mps11.c - Clock driver for S2MPS11.
>>   *
>> - * Copyright (C) 2013 Samsung Electornics
>> + * Copyright (C) 2013,2014 Samsung Electornics
>>   *
>>   * This program is free software; you can redistribute  it and/or modify it
>>   * under  the terms of  the GNU General  Public License as published by the
>> @@ -13,10 +13,6 @@
>>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>   * GNU General Public License for more details.
>>   *
>> - * You should have received a copy of the GNU General Public License
>> - * along with this program; if not, write to the Free Software
>> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
>> - *
>>   */
>>
>>  #include 
>> @@ -27,6 +23,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -125,7 +122,21 @@ static struct clk_init_data 
>> s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
>> },
>>  };
>>
>> -static struct device_node *s2mps11_clk_parse_dt(struct platform_device 
>> *pdev)
>> +static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
>> +   [S2MPS11_CLK_AP] = {
>> +   .name = "s2mps14_ap",
>> +   .ops = _clk_ops,
>> +   .flags = CLK_IS_ROOT,
>> +   },
>> +   [S2MPS11_CLK_BT] = {
>> +   .name = "s2mps14_bt",
>> +   .ops = _clk_ops,
>> +   .flags = CLK_IS_ROOT,
>> +   },
>> +};
>> +
>> +static struct device_node *s2mps11_clk_parse_dt(struct platform_device 
>> *pdev,
>> +   struct clk_init_data *clks_init)
>>  {
>> struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
>> struct device_node *clk_np;
>> @@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
>> platform_device *pdev)
>> if (!clk_table)
>> return ERR_PTR(-ENOMEM);
>>
>> -   for (i = 0; i < S2MPS11_CLKS_NUM; i++)
>> +   for (i = 0; i < S2MPS11_CLKS_NUM; i++) {
>> +   if (!clks_init[i].name)
>> +   continue; /* Skip clocks not present in some devices 
>> */
>> of_property_read_string_index(clk_np, "clock-output-names", 
>> i,
>> -   _clks_init[i].name);
>> +   _init[i].name);
>> +   }
>>
>> return clk_np;
>>  }
>> @@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device 
>> *pdev)
>> struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
>> struct device_node *clk_np = NULL;
>> unsigned int s2mps11_reg;
>> +   struct clk_init_data *clks_init;
>> int i, ret = 0;
>> u32 val;
>>
>> @@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device 
>> *pdev)
>>
>> s2mps11_clk = s2mps11_clks;
>>
>> -   clk_np = s2mps11_clk_parse_dt(pdev);
>> -   if (IS_ERR(clk_np))
>> -   return PTR_ERR(clk_np);
>> -
>> switch (platform_get_device_id(pdev)->driver_data) {
>> case S2MPS11X:
>> s2mps11_reg = S2MPS11_REG_RTC_CTRL;

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

sound/soc/generic/simple-card.c: In function 'asoc_simple_card_parse_of':
sound/soc/generic/simple-card.c:188:47: error: 'struct simple_card_data' has no 
member named 'daifmt'
   ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
   ^
sound/soc/generic/simple-card.c:201:47: error: 'struct simple_card_data' has no 
member named 'daifmt'
   ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
   ^

Caused by commit 56556f333ae3 ("ASoC: simple-card: overwrite cpu_dai->fmt
with codec_dai->fmt"). daifmt was removed from struct simple_card_data in
commit c56c4d74c6f9 ("ASoC: simple-card: Simplify code").

I have used the sound-asoc tree from next-20140318 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpUCKRpdM0t1.pgp
Description: PGP signature

Re: [PATCH 1/3] bridge: preserve random init MAC address

[Luis R. Rodriguez]

On Tue, Mar 18, 2014 at 6:04 PM, Toshiaki Makita
 wrote:
> (2014/03/19 9:50), Luis R. Rodriguez wrote:
>> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
>>  wrote:
>>> nit,
>>> If the last detached port happens to have the same addr as
>>> random_init_addr, this seems to call br_stp_change_bridge_id() even
>>> though bridge_id is not changed.
>>
>> Ah good point.
>>
>>> Shouldn't the assignment of random_init_addr be done before the check of
>>> "no change"?
>>
>> Good question, should we even allow two ports to have the same MAC
>> address or should we complain and refuse to add it? If so that should
>> mean we should also have to monitor any manual address changes or
>> events for address changes on the ports.
>
> This was recently discussed by Stephen and me.
> I'm thinking it should be allowed.
>
> http://marc.info/?l=linux-netdev=139182743919257=2

Great now that that's sorted out though I still think calling
br_stp_change_bridge_id() is right just as calling the update features
as the device is different. It could however be confusing when this
situation is run and folks might report odd bugs unless we could tell
them apart clearly. Thoughts?

  Luis
--
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 v3 1/3] clk: s2mps11: Add support for S2MPS14 clocks

[Mike Turquette]

Quoting Krzysztof Kozlowski (2014-03-17 02:19:16)
> This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
> s2mps11 clock driver.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Yadwinder Singh Brar 
> Reviewed-by: Tomasz Figa 

Taken into clk-next.

Regards,
Mike

> ---
>  drivers/clk/Kconfig   |8 +++---
>  drivers/clk/clk-s2mps11.c |   61 
> ++---
>  2 files changed, 50 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 6f56d3a4f010..8f9ce8ba036d 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -65,12 +65,12 @@ config COMMON_CLK_SI570
>   clock generators.
>  
>  config COMMON_CLK_S2MPS11
> -   tristate "Clock driver for S2MPS11/S5M8767 MFD"
> +   tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> depends on MFD_SEC_CORE
> ---help---
> - This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
> - multi-function devices have 3 fixed-rate oscillators, clocked at
> - 32KHz each.
> + This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
> + clock. These multi-function devices have two (S2MPS14) or three
> + (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
>  
>  config CLK_TWL6040
> tristate "External McPDM functional clock from twl6040"
> diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
> index 508875535e1e..8dafb552274f 100644
> --- a/drivers/clk/clk-s2mps11.c
> +++ b/drivers/clk/clk-s2mps11.c
> @@ -1,7 +1,7 @@
>  /*
>   * clk-s2mps11.c - Clock driver for S2MPS11.
>   *
> - * Copyright (C) 2013 Samsung Electornics
> + * Copyright (C) 2013,2014 Samsung Electornics
>   *
>   * This program is free software; you can redistribute  it and/or modify it
>   * under  the terms of  the GNU General  Public License as published by the
> @@ -13,10 +13,6 @@
>   * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>   * GNU General Public License for more details.
>   *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> - *
>   */
>  
>  #include 
> @@ -27,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -125,7 +122,21 @@ static struct clk_init_data 
> s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
> },
>  };
>  
> -static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
> +static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
> +   [S2MPS11_CLK_AP] = {
> +   .name = "s2mps14_ap",
> +   .ops = _clk_ops,
> +   .flags = CLK_IS_ROOT,
> +   },
> +   [S2MPS11_CLK_BT] = {
> +   .name = "s2mps14_bt",
> +   .ops = _clk_ops,
> +   .flags = CLK_IS_ROOT,
> +   },
> +};
> +
> +static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
> +   struct clk_init_data *clks_init)
>  {
> struct sec_pmic_dev *iodev = dev_get_drvdata(pdev->dev.parent);
> struct device_node *clk_np;
> @@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
> platform_device *pdev)
> if (!clk_table)
> return ERR_PTR(-ENOMEM);
>  
> -   for (i = 0; i < S2MPS11_CLKS_NUM; i++)
> +   for (i = 0; i < S2MPS11_CLKS_NUM; i++) {
> +   if (!clks_init[i].name)
> +   continue; /* Skip clocks not present in some devices 
> */
> of_property_read_string_index(clk_np, "clock-output-names", i,
> -   _clks_init[i].name);
> +   _init[i].name);
> +   }
>  
> return clk_np;
>  }
> @@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
> struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
> struct device_node *clk_np = NULL;
> unsigned int s2mps11_reg;
> +   struct clk_init_data *clks_init;
> int i, ret = 0;
> u32 val;
>  
> @@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device 
> *pdev)
>  
> s2mps11_clk = s2mps11_clks;
>  
> -   clk_np = s2mps11_clk_parse_dt(pdev);
> -   if (IS_ERR(clk_np))
> -   return PTR_ERR(clk_np);
> -
> switch (platform_get_device_id(pdev)->driver_data) {
> case S2MPS11X:
> s2mps11_reg = S2MPS11_REG_RTC_CTRL;
> +   clks_init = s2mps11_clks_init;
> +   break;
> +   case S2MPS14X:
> +   s2mps11_reg = S2MPS14_REG_RTCCTRL;
> +   clks_init = s2mps14_clks_init;
> break;
> case S5M8767X:
> s2mps11_reg = S5M8767_REG_CTRL1;
> +   clks_init = s2mps11_clks_init;
> break;
>  

Re: bad rss-counter message in 3.14rc5

[Linus Torvalds]

On Tue, Mar 18, 2014 at 5:38 PM, Hugh Dickins  wrote:
>
> And yes, it is possible (though very unusual) to find an anon page or
> swap entry in a VM_SHARED nonlinear mapping: coming from that horrid
> get_user_pages(write, force) case which COWs even in a shared mapping.

Hmm. Maybe we could just disallow that forced case.

It *used* to be a trivial "we can just do a COW", but that was back
when the VM was much simpler and we had no rmap's etc. So "that horrid
case" used to be a simple hack that wasn't painful. But I suspect we
could very easily just fail it instead of forcing a COW, if that would
make it simpler for the VM code.

   Linus
--
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 v3 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

On Tue, Mar 18, 2014 at 4:47 PM, Tim Kryger  wrote:
> On Tue, Mar 18, 2014 at 2:52 PM, Thierry Reding
>  wrote:
>> On Wed, Mar 12, 2014 at 01:15:43PM -0700, Tim Kryger wrote:

>>> +
>>> + /* There is polarity support in HW but it is easier to manage in SW */
>>> + if (pwm->polarity == PWM_POLARITY_INVERSED)
>>> + duty_ns = period_ns - duty_ns;
>>
>> No, this is wrong. You're not actually changing the *polarity* here.
>
> Please elaborate.  I don't understand what is wrong here.
>
> Does polarity influence the output while a PWM is disabled?
>

>>> +static int kona_pwmc_set_polarity(struct pwm_chip *chip, struct pwm_device 
>>> *pwm,
>>> +   enum pwm_polarity polarity)
>>> +{
>>> + /*
>>> +  * The framework only allows the polarity to be changed when a PWM is
>>> +  * disabled so no immediate action is required here.  When a channel 
>>> is
>>> +  * enabled, the polarity gets handled as part of the re-config step.
>>> +  */
>>> +
>>> + return 0;
>>> +}
>>
>> See above. If you don't want to implement the hardware support for
>> inversed polarity, then simply don't implement this.
>
> I had originally planned to omit polarity support but because it
> affects the binding (which is treated as ABI), it wouldn't be possible
> to add it in later without defining a new compatible string.

I would like to get this right but it occurred to me that there may be
a way to defer the implementation of this feature without disrupting
the binding.

Would it be acceptable to continue using #pwm-cells = <3> and
of_pwm_xlate_with_flags but return -EINVAL from kona_pwmc_set_polarity
if PWM_POLARITY_INVERSED is specified?
--
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/3] bridge: preserve random init MAC address

[Toshiaki Makita]

(2014/03/19 9:50), Luis R. Rodriguez wrote:
> On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
>  wrote:
>> nit,
>> If the last detached port happens to have the same addr as
>> random_init_addr, this seems to call br_stp_change_bridge_id() even
>> though bridge_id is not changed.
> 
> Ah good point.
> 
>> Shouldn't the assignment of random_init_addr be done before the check of
>> "no change"?
> 
> Good question, should we even allow two ports to have the same MAC
> address or should we complain and refuse to add it? If so that should
> mean we should also have to monitor any manual address changes or
> events for address changes on the ports.

This was recently discussed by Stephen and me.
I'm thinking it should be allowed.

http://marc.info/?l=linux-netdev=139182743919257=2

Toshiaki Makita

> 
> Stephen?
> 
>   Luis
--
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: unisys: use kzalloc instead of kmalloc/memset 0

[DaeSeok Youn]

oh...
You didn't get my reply about vmalloc usage.

My replay attach again, below.

> 2014-03-18 9:37 GMT+09:00 Greg KH :
>> On Tue, Mar 18, 2014 at 09:26:07AM +0900, DaeSeok Youn wrote:
>>> I think vmalloc/kmalloc in uislib_malloc() can be removed and just use
>>> vmalloc/kmalloc directly.
>>
>> Yes.  Actually, just use kmalloc, I don't knwo why vmalloc is being
>> used, but cc: the driver maintainers just to be sure.
>
Here, need to check by you.
> It try to allocate 128KiB(131072byte) with vmalloc(). I think if it
> trying to allocate with kmalloc()
> it has a possibility to fail because of memory fragmentation even if
> system has enough memory to use.
> Just my opinion. If I'm wrong, let me know.
>
>>
>>> (UISMALLOC() macro is also removed.)
>>
>> Yes.
>>
>>> And uislib_malloc() is renamed to "uislib_trace_buffer_status()" which
>>> is just tracing buffer status(Malloc_FailuresAlloc, Malloc_BytesInUse
>>> ...) for info_proc_read_helper().
>>
>> The whole tracing stuff needs to be ripped out, so no problem deleting
>> it here as well.
>
> OK. I will remove that information in info_proc_read_helper().
>
>>
>>> If this change is accepted, it also need to change uislib_free().
>>
>> Drop it and just use kfree().
> OK. replace kfree() with uislib_free().
>
>>
>> thanks,
>>
>> greg k-h

2014-03-19 9:58 GMT+09:00 Greg KH :
> On Wed, Mar 19, 2014 at 09:03:49AM +0900, DaeSeok Youn wrote:
>> Hi, greg.
>>
>> Review my comment below.
>
> What comment?
>
> 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 v11 17/27] iommu/exynos: remove calls to Runtime PM API functions

[Cho KyongHo]

On Tue, 18 Mar 2014 16:09:50 +0100, Tomasz Figa wrote:
> On 18.03.2014 10:56, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
> >> Hi KyongHo,
> >>
> >> On 14.03.2014 06:08, Cho KyongHo wrote:
> 
> [snip]
> 
> >>> -static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
> >>> +static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
> >>
> >> If you are changing the names anyway, it would be probably a good idea
> >> to reduce code obfuscation a bit and drop the underscores from
> >> beginnings of function names. Also I'd suggest keeping the "exynos_" 
> >> prefix.
> >
> > Thanks for the suggestion.
> > __exynos_sysmmu_disable is splitted into 2 functions: __sysmmu_disable
> > and __sysmmu_disable_nocount.
> > I agree with you that it is good idea to reduce code obfuscation but
> > I don't think dropping beginning underscores of function names reduces
> > obfuscation.
> >
> 
> Well, if you are ending up with a function like 
> __sysmmu_enable_nocount() below with every line starting with two 
> underscores, do you think this improves code readability?
> 
> Of course this is a minor issue, but let's keep some code quality level 
> in Linux kernel.
> 

Ok. understood what your are concerning about.

> >>
> >>>{
> >>> - unsigned long flags;
> >>> - bool disabled = false;
> >>> -
> >>> - write_lock_irqsave(>lock, flags);
> 
> [snip]
> 
> Here's the function mentioned above:
> 
> >>> +
> >>> +static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
> >>> +{
> >>> + __master_clk_enable(data);
> >>> + __sysmmu_clk_enable(data);
> >>> +
> >>> + __raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
> >>> +
> >>> + __sysmmu_init_config(data);
> >>> +
> >>> + __sysmmu_set_ptbase(data->sfrbase, data->pgtable);
> >>> +
> >>> + __raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
> >>> +
> >>> + __master_clk_disable(data);
> >>> +}
> >>> +
> 
> [snip]
> 
> >>>
> >>> @@ -629,7 +700,7 @@ err_pgtable:
> >>>static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
> >>>{
> >>>   struct exynos_iommu_domain *priv = domain->priv;
> >>> - struct sysmmu_drvdata *data;
> >>> + struct exynos_iommu_owner *owner;
> >>>   unsigned long flags;
> >>>   int i;
> >>>
> >>> @@ -637,11 +708,14 @@ static void exynos_iommu_domain_destroy(struct 
> >>> iommu_domain *domain)
> >>>
> >>>   spin_lock_irqsave(>lock, flags);
> >>>
> >>> - list_for_each_entry(data, >clients, node) {
> >>> - while (!exynos_sysmmu_disable(data->dev))
> >>> + list_for_each_entry(owner, >clients, client) {
> >>> + while (!exynos_sysmmu_disable(owner->dev))
> >>>   ; /* until System MMU is actually disabled */
> >>
> >> What about using list_for_each_entry_safe() and calling list_del_init()
> >> here directly?
> >>
> >
> > That require another variable to be defined.
> 
> Is it a problem?
> 
That is not a problem.
But I think using list_for_each_entry() is not a problem likewise.

> > I just wanted to avoid that because I think it is prettier.
> > Moreover, list_del_init() below the empty while() clause may make
> > the source code readers misunderstood..
> 
> This raises another question, why the loop above is even needed. 
> exynos_sysmmu_disable() should make sure that SYSMMU is actually 
> disabled, without any need for looping like this.

Some driver needs enabling sysmmu to be counted due to its complex structure.
It can be also removed by the driver with an extra effort
but the reality is important.
Device driver is not only for the scholarship but also for the real use.

> >>>   }
> >>>
> >>> + while (!list_empty(>clients))
> >>> + list_del_init(priv->clients.next);
> >>> +
> >>>   spin_unlock_irqrestore(>lock, flags);
> >>>
> >>>   for (i = 0; i < NUM_LV1ENTRIES; i++)
> 
> [snip]
> 
> >>> +static int sysmmu_hook_driver_register(struct notifier_block *nb,
> >>> + unsigned long val,
> >>> + void *p)
> >>> +{
> >>> + struct device *dev = p;
> >>> +
> >>> + switch (val) {
> >>> + case BUS_NOTIFY_BIND_DRIVER:
> >>> + {
> >>> + struct exynos_iommu_owner *owner;
> >>
> >> Please move this variable to the top of the function and drop the braces
> >> around case blocks.
> >
> > I don't think it is required because this function is modified
> > by the following patches.
> 
> OK, if so, and similar issue is not present after further patches.
> 
> >
> >>
> >>> +
> >>> + /* No System MMU assigned. See exynos_sysmmu_probe(). */
> >>> + if (dev->archdata.iommu == NULL)
> >>> + break;
> >>
> >> This looks strange... (see below)
> >>
> >> Also this looks racy. There are no guarantees about device probing
> >> order, so you may end up with master devices being probed before the
> >> IOMMUs. Deferred probing should be used to handle this correctly.
> >
> > System MMU driver must be probed 

Re: [PATCH] staging: wlags49_h2: Coding style correction

[Greg KH]

On Wed, Mar 19, 2014 at 01:52:09AM +0100, Mathieu Maret wrote:
> As the file was mixing tab and space, reindent the file
> Mainly correct use of C99 comments,
> space between parenthesis,
> remove commented code
> 
> Signed-off-by: Mathieu Maret 
> ---
>  drivers/staging/wlags49_h2/wl_netdev.c | 1990 
> 
>  1 file changed, 1007 insertions(+), 983 deletions(-)

That's way too big to review easily, can you do that?  :)

Please break it up into "do one thing at a time" type patch, so that it
can be reviewed and applied properly.

thanks,

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] s390: correct misuses of module_put in appldata_generic_handler.

[Zhouyi Zhou]

Delicate design!  thanks for replying, sorry for the trouble

On Tue, Mar 18, 2014 at 9:34 PM, Gerald Schaefer
 wrote:
> On Tue, 18 Mar 2014 09:24:55 +0800
> Zhouyi Zhou  wrote:
>
>> Thanks Gerald for reviewing and sorry for not elaborated it in the e-mail.
>>
>> Firstly, I think you can't call module_put after fail try_module_get
>
> There is another try_module_get() in this function before that, so I need
> to call module_put() once if the second try_module_get() fails.
>
> The first try_module_get() is only needed within the function, while the
> second one is needed to prevent a module from being unloaded while its
> callback is registered, so that reference is kept as long as the module
> is active.
>
>>
>> Secondly, there exists duplicate module_put on the program path (the last
>> one is before return 0)
>
> There is one module_put() for every try_module_get(). If "1" is written
> to the sysctl, the function exits with one "missing" module_put(), which
> is held to protect the callback. When "0" is written, this reference
> is returned again with an "extra" module_put().
>
>>
>> On Mon, Mar 17, 2014 at 9:28 PM, Gerald Schaefer
>>  wrote:
>> > On Sat, 15 Mar 2014 21:35:40 +0800
>> > Zhouyi Zhou  wrote:
>> >
>> >> correct misuses of module_put in  appldata_generic_handler
>> >
>> > Sorry, I don't see any misuse, could you elaborate?
>> >
>> >>
>> >> Signed-off-by: Zhouyi Zhou 
>> >> ---
>> >>  arch/s390/appldata/appldata_base.c | 3 ---
>> >>  1 file changed, 3 deletions(-)
>> >>
>> >> diff --git a/arch/s390/appldata/appldata_base.c 
>> >> b/arch/s390/appldata/appldata_base.c
>> >> index 47c8630..683e0282 100644
>> >> --- a/arch/s390/appldata/appldata_base.c
>> >> +++ b/arch/s390/appldata/appldata_base.c
>> >> @@ -343,7 +343,6 @@ appldata_generic_handler(struct ctl_table *ctl, int 
>> >> write,
>> >>   // protect work queue callback
>> >>   if (!try_module_get(ops->owner)) {
>> >>   mutex_unlock(_ops_mutex);
>> >> - module_put(ops->owner);
>> >>   return -ENODEV;
>> >>   }
>> >>   ops->callback(ops->data);   // init record
>> >> @@ -354,7 +353,6 @@ appldata_generic_handler(struct ctl_table *ctl, int 
>> >> write,
>> >>   if (rc != 0) {
>> >>   pr_err("Starting the data collection for %s "
>> >>  "failed with rc=%d\n", ops->name, rc);
>> >> - module_put(ops->owner);
>> >>   } else
>> >>   ops->active = 1;
>> >>   } else if ((buf[0] == '0') && (ops->active == 1)) {
>> >> @@ -365,7 +363,6 @@ appldata_generic_handler(struct ctl_table *ctl, int 
>> >> write,
>> >>   if (rc != 0)
>> >>   pr_err("Stopping the data collection for %s "
>> >>  "failed with rc=%d\n", ops->name, rc);
>> >> - module_put(ops->owner);
>> >>   }
>> >>   mutex_unlock(_ops_mutex);
>> >>  out:
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-s390" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
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: unisys: use kzalloc instead of kmalloc/memset 0

[Greg KH]

On Wed, Mar 19, 2014 at 09:03:49AM +0900, DaeSeok Youn wrote:
> Hi, greg.
> 
> Review my comment below.

What comment?

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] staging: unisys: use kzalloc instead of kmalloc/memset 0

[Greg KH]

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Mar 19, 2014 at 09:09:59AM +0900, DaeSeok Youn wrote:
> Hi, Ken
> Thanks for review.
> 
> But I have a question,  I wan to know why tracing buffer
> status(Malloc_FailuresAlloc, Malloc_BytesInUse...) for
> info_proc_read_helper() are needed.
> If it doesn't need, whole tracing stuff for memory can be removed.

Yes, that is something that also should be removed.


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 9/9] powerpc/pm: support deep sleep feature on T1040

[Chenhui Zhao]

On Tue, Mar 18, 2014 at 05:42:09PM -0500, Scott Wood wrote:
> On Mon, 2014-03-17 at 19:19 +0800, Chenhui Zhao wrote:
> > On Fri, Mar 14, 2014 at 06:18:27PM -0500, Scott Wood wrote:
> > > On Wed, 2014-03-12 at 18:40 +0800, Chenhui Zhao wrote:
> > > > On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > > > > > From: Zhao Chenhui 
> > > > > > 
> > > > > > T1040 supports deep sleep feature, which can switch off most parts 
> > > > > > of
> > > > > > the SoC when it is in deep sleep mode. This way, it becomes more
> > > > > > energy-efficient.
> > > > > > 
> > > > > > The DDR controller will also be powered off in deep sleep. 
> > > > > > Therefore,
> > > > > > the last stage (the latter part of fsl_dp_enter_low) will run 
> > > > > > without DDR
> > > > > > access. This piece of code and related TLBs will be prefetched.
> > > > > > 
> > > > > > Due to the different initialization code between 32-bit and 64-bit, 
> > > > > > they
> > > > > > have seperate resume entry and precedure.
> > > > > > 
> > > > > > The feature supports 32-bit and 64-bit kernel mode.
> > > > > > 
> > > > > > Signed-off-by: Zhao Chenhui 
> > > > > > ---
> > > > > >  arch/powerpc/include/asm/booke_save_regs.h |3 +
> > > > > >  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   17 ++
> > > > > >  arch/powerpc/kernel/head_fsl_booke.S   |   30 +++
> > > > > >  arch/powerpc/platforms/85xx/Makefile   |2 +-
> > > > > >  arch/powerpc/platforms/85xx/deepsleep.c|  201 
> > > > > > +++
> > > > > >  arch/powerpc/platforms/85xx/qoriq_pm.c |   38 
> > > > > >  arch/powerpc/platforms/85xx/sleep.S|  295 
> > > > > > 
> > > > > >  arch/powerpc/sysdev/fsl_soc.h  |7 +
> > > > > >  8 files changed, 592 insertions(+), 1 deletions(-)
> > > > > >  create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> > > > > >  create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > > > > > 
> > > > > > diff --git a/arch/powerpc/include/asm/booke_save_regs.h 
> > > > > > b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > index 87c357a..37c1f6c 100644
> > > > > > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > > > > > @@ -88,6 +88,9 @@
> > > > > >  #define HIBERNATION_FLAG   1
> > > > > >  #define DEEPSLEEP_FLAG 2
> > > > > >  
> > > > > > +#define CPLD_FLAG  1
> > > > > > +#define FPGA_FLAG  2
> > > > > 
> > > > > What is this?
> > > > 
> > > > We have two kind of boards, QDS and RDB.
> > > > They have different register map. Use the flag to indicate the current 
> > > > board is using which kind
> > > > of register map.
> > > 
> > > CPLD versus FPGA is not a meaningful difference.  We don't care what
> > > technology is used to implement programmable logic -- we care what
> > > programming interface is exposed.  Customers will have their own boards
> > > that will likely not imitate either of these programming interfaces, but
> > > what they do have will still probably be implemented in a CPLD or FPGA.
> > > Likewise, Freescale may have future reference boards whose CPLD/FPGA is
> > > not compatible.
> > 
> > Will use a better name.
> > 
> > > 
> > > So use better naming, and structure the code so it's easy to plug in
> > > implementations for new or custom boards.
> > >  
> > > > > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
> > > > > > b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > index 20204fe..3285752 100644
> > > > > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > > > > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> > > > > >  #include "fsl_booke_entry_mapping.S"
> > > > > >  #undef ENTRY_MAPPING_BOOT_SETUP
> > > > > >  
> > > > > > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > > > > > +   /* if deep_sleep_flag != 0, jump to the deep sleep resume entry 
> > > > > > */
> > > > > > +   LOAD_REG_ADDR(r4, deep_sleep_flag)
> > > > > > +   lwz r3, 0(r4)
> > > > > > +   cmpwi   r3, 0
> > > > > > +   beq 11f
> > > > > > +   /* clear deep_sleep_flag */
> > > > > > +   li  r3, 0
> > > > > > +   stw r3, 0(r4)
> > > > > > +   b   fsl_deepsleep_resume
> > > > > > +11:
> > > > > > +#endif
> > > > > 
> > > > > Why do you come in via the normal kernel entry, versus specifying a
> > > > > direct entry point for deep sleep resume?  How does U-Boot even know
> > > > > what the normal entry is when resuming?
> > > > 
> > > > I wish to return to a specified point (like 64-bit mode), but the code 
> > > > in
> > > > fsl_booke_entry_mapping.S only can run in the first page. Because it
> > > > only setups a temp mapping of 4KB.
> > > 
> > > Why do you need the entry mapping on 32-bit but not 64-bit?
> > 
> > fsl_booke_entry_mapping.S is for 32-bit. 64-bit calls
> > initial_tlb_book3e() in exceptions-64e.S.
> 
> The answer I 

linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/trace/define_trace.h:90:0,
 from drivers/gpu/drm/i915/i915_trace.h:520,
 from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function 
'ftrace_raw_event_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use 
in this function)
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
drivers/gpu/drm/i915/./i915_trace.h:246:22: note: each undeclared identifier is 
reported only once for each function it appears in
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
In file included from include/trace/define_trace.h:90:0,
 from drivers/gpu/drm/i915/i915_trace.h:520,
 from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function 'perf_trace_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use 
in this function)
   __entry->dev = dev->primary->index;
  ^
include/trace/ftrace.h:708:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(i915_gem_evict_vm,
 ^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^

Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers
from ring buffer in evict event").

I have used the drm-intel tree from next-20140318 for today.

-- 
Cheers,
Stephen Rothwell 


pgpVfa3HCVJ7H.pgp
Description: PGP signature

Re: [PATCH 1/3] bridge: preserve random init MAC address

[Luis R. Rodriguez]

On Tue, Mar 18, 2014 at 5:42 PM, Toshiaki Makita
 wrote:
> nit,
> If the last detached port happens to have the same addr as
> random_init_addr, this seems to call br_stp_change_bridge_id() even
> though bridge_id is not changed.

Ah good point.

> Shouldn't the assignment of random_init_addr be done before the check of
> "no change"?

Good question, should we even allow two ports to have the same MAC
address or should we complain and refuse to add it? If so that should
mean we should also have to monitor any manual address changes or
events for address changes on the ports.

Stephen?

  Luis
--
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/12] scsi/NCR5380: fix debugging macros and #include structure

[Joe Perches]

On Wed, 2014-03-19 at 10:14 +1100, Finn Thain wrote:
> As for side-effects, chip register accesses would be affected if dprintk() 
> expanded to no_printk() when NDEBUG & flg == 0.
> 
> E.g. NCR5380.c line 1213:
> dprintk(NDEBUG_INTR, "scsi : unknown interrupt, BASR 0x%X, MR 0x%X, SR 
> 0x%x\n",
>  basr, NCR5380_read(MODE_REG), NCR5380_read(STATUS_REG));
> 
> I don't want to re-introduce side-effects into a dozen different NCR5380 
> drivers on three different architectures when I can test only one of those 
> drivers. It's difficult to get good code coverage even for one driver.

Hi again Finn.

If dprintk expanded directly to no_printk, then true.

But using "if (0)" prevents the no_printk from
occurring at all so there would be no side-effects
and the format & args would still be verified by the
compiler.

So I believe you shouldn't worry about side-effects.

cheers, Joe


--
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 0/6] perf tools: Share map groups within process

[Namhyung Kim]

Hi Jiri,

On Tue, Mar 18, 2014 at 2:46 PM, Jiri Olsa  wrote:
> hi,
> this patchset moves thread's map_groups to be dynamically
> allocated and shared within process threads.
>
> The main benefit would be to be able to look up memory
> map from any thread that belongs to the process.
>
> This implements one of the solution ideas for issue
> described by Don in following thread:
> http://marc.info/?l=linux-kernel=139403876017159=2
>
> RFC changes:
>   - added automated test for thread map groups get/put methods
>   - fix reference count for case described by Namhyung
>   - rename the mmap-events.c test to mmap-thread-lookup.c
>   - added PROT_EXEC to mmap call in tests/mmap-thread-lookup.c
> as it's not implied by default on all archs (Namhyung)
>   - lazy mg allocation in thread__find_addr_map (Namhyung)
>   - fix compilation failures (Arnaldo)

Looks good to me!

Reviewed-by: Namhyung Kim 

Thanks,
Namhyung
--
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/3] bridge: preserve random init MAC address

[Toshiaki Makita]

(2014/03/13 12:15), Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" 
> 
> As it is now if you add create a bridge it gets started
> with a random MAC address and if you then add a net_device
> as a slave but later kick it out you end up with a zero
> MAC address. Instead preserve the original random MAC
> address and use it.
> 
> If you manually set the bridge address that will always
> be respected. This change only takes effect if at the time
> of computing the new root port we determine we have found
> no candidates.
> 
> Cc: Stephen Hemminger 
> Cc: bri...@lists.linux-foundation.org
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> Cc: k...@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez 
> ---
>  net/bridge/br_device.c  | 1 +
>  net/bridge/br_private.h | 1 +
>  net/bridge/br_stp_if.c  | 3 +++
>  3 files changed, 5 insertions(+)
> 
> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> index b063050..5f13eac 100644
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> @@ -368,6 +368,7 @@ void br_dev_setup(struct net_device *dev)
>   br->bridge_id.prio[1] = 0x00;
>  
>   ether_addr_copy(br->group_addr, eth_reserved_addr_base);
> + ether_addr_copy(br->random_init_addr, dev->dev_addr);
>  
>   br->stp_enabled = BR_NO_STP;
>   br->group_fwd_mask = BR_GROUPFWD_DEFAULT;
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index e1ca1dc..32a06da 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -240,6 +240,7 @@ struct net_bridge
>   unsigned long   bridge_hello_time;
>   unsigned long   bridge_forward_delay;
>  
> + u8  random_init_addr[ETH_ALEN];
>   u8  group_addr[ETH_ALEN];
>   u16 root_port;
>  
> diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
> index 189ba1e..4c9ad45 100644
> --- a/net/bridge/br_stp_if.c
> +++ b/net/bridge/br_stp_if.c
> @@ -239,6 +239,9 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
>   if (ether_addr_equal(br->bridge_id.addr, addr))
>   return false;   /* no change */
>  
> + if (ether_addr_equal(addr, br_mac_zero))
> + addr = br->random_init_addr;
> +
>   br_stp_change_bridge_id(br, addr);
>   return true;
>  }

nit,
If the last detached port happens to have the same addr as
random_init_addr, this seems to call br_stp_change_bridge_id() even
though bridge_id is not changed.

Shouldn't the assignment of random_init_addr be done before the check of
"no change"?

Toshiaki Makita
--
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: bad rss-counter message in 3.14rc5

[Hugh Dickins]

On Tue, 11 Mar 2014, Dave Jones wrote:
> On Tue, Mar 11, 2014 at 09:36:03PM +0400, Cyrill Gorcunov wrote:
>  > On Tue, Mar 11, 2014 at 01:10:45PM -0400, Dave Jones wrote:
>  > >  > 
>  > >  > Dave, iirc trinity can write log file pointing which exactly syscall 
> sequence
>  > >  > was passed, right? Share it too please.
>  > > 
>  > > Hm, I may have been mistaken, and the damage was done by a previous run.
>  > > I went from being able to reproduce it almost instantly to now not being 
> able
>  > > to reproduce it at all.  Will keep trying.
>  > 
>  > Sasha already gave a link to the syscalls sequence, so no rush.
> 
> It'd be nice to get a more concise reproducer, his list had a little of 
> everything in there.

I've so far failed to find any explanation for your swapops.h BUG;
but believe I have identified one cause for "Bad rss-counter"s.

My hunch is that the swapops.h BUG is "nearby", but I just cannot
fit it together (the swapops.h BUG comes when rmap cannot find all
all the migration entries it inserted earlier: it's a very useful
BUG for validating rmap).

Untested patch below: I can't quite say Reported-by, because it may
not even be one that you and Sasha have been seeing; but I'm hopeful,
remap_file_pages is in the list.

Please give this a try, preferably on 3.14-rc or earlier: I've never
seen "Bad rss-counter"s there myself (trinity uses remap_file_pages
a lot more than most of us); but have seen them on mmotm/next, so
some other trigger is coming up there, I'll worry about that once
it reaches 3.15-rc.

(Cyrill, entirely unrelated, but in preparing this patch I noticed
your soft_dirty work in install_file_pte(): which looked good at
first, until I realized that it's propagating the soft_dirty of a
pte it's about to zap completely, to the unrelated entry it's about
to insert in its place.  Which seems very odd to me.)


[PATCH] mm: fix bad rss-counter if remap_file_pages raced migration

Fix some "Bad rss-counter state" reports on exit, arising from the
interaction between page migration and remap_file_pages(): zap_pte()
must count a migration entry when zapping it.

And yes, it is possible (though very unusual) to find an anon page or
swap entry in a VM_SHARED nonlinear mapping: coming from that horrid
get_user_pages(write, force) case which COWs even in a shared mapping.

Signed-off-by: Hugh Dickins 
---

 mm/fremap.c |   28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

--- 3.14-rc7/mm/fremap.c2014-01-19 18:40:07.0 -0800
+++ linux/mm/fremap.c   2014-03-18 16:32:39.288612346 -0700
@@ -23,28 +23,44 @@
 
 #include "internal.h"
 
+static int mm_counter(struct page *page)
+{
+   return PageAnon(page) ? MM_ANONPAGES : MM_FILEPAGES;
+}
+
 static void zap_pte(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
 {
pte_t pte = *ptep;
+   struct page *page;
+   swp_entry_t entry;
 
if (pte_present(pte)) {
-   struct page *page;
-
flush_cache_page(vma, addr, pte_pfn(pte));
pte = ptep_clear_flush(vma, addr, ptep);
page = vm_normal_page(vma, addr, pte);
if (page) {
if (pte_dirty(pte))
set_page_dirty(page);
+   update_hiwater_rss(mm);
+   dec_mm_counter(mm, mm_counter(page));
page_remove_rmap(page);
page_cache_release(page);
+   }
+   } else {/* zap_pte() is not called when pte_none() */
+   if (!pte_file(pte)) {
update_hiwater_rss(mm);
-   dec_mm_counter(mm, MM_FILEPAGES);
+   entry = pte_to_swp_entry(pte);
+   if (non_swap_entry(entry)) {
+   if (is_migration_entry(entry)) {
+   page = migration_entry_to_page(entry);
+   dec_mm_counter(mm, mm_counter(page));
+   }
+   } else {
+   free_swap_and_cache(entry);
+   dec_mm_counter(mm, MM_SWAPENTS);
+   }
}
-   } else {
-   if (!pte_file(pte))
-   free_swap_and_cache(pte_to_swp_entry(pte));
pte_clear_not_present_full(mm, addr, ptep, 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 v11 20/27] iommu/exynos: allow having multiple System MMUs for a master H/W

[Cho KyongHo]

On Tue, 18 Mar 2014 15:26:48 +0100, Tomasz Figa wrote:
> 
> 
> On 18.03.2014 14:01, Cho KyongHo wrote:
> > On Fri, 14 Mar 2014 17:12:03 +0100, Tomasz Figa wrote:
> >> Hi KyongHo,
> >>
> >> On 14.03.2014 06:10, Cho KyongHo wrote:
> >>> Some master device descriptor like fimc-is which is an abstraction
> >>> of very complex H/W may have multiple System MMUs. For those devices,
> >>> the design of the link between System MMU and its master H/W is needed
> >>> to be reconsidered.
> >>>
> >>> A link structure, sysmmu_list_data is introduced that provides a link
> >>> to master H/W and that has a pointer to the device descriptor of a
> >>> System MMU. Given a device descriptor of a master H/W, it is possible
> >>> to traverse all System MMUs that must be controlled along with the
> >>> master H/W.
> >>
> >> NAK.
> >>
> >> A device driver should handle particular hardware instances separately,
> >> without abstracting a virtual hardware instance consisting of multiple
> >> physical ones.
> >>
> >> If such abstraction is needed, it should be done above the exynos-iommu
> >> driver, e.g. by something like iommu-composite driver that would
> >> aggregate several IOMMUs. Keep in mind that such IOMMUs in a group could
> >> be different, e.g. different Exynos SysMMU versions or even completely
> >> different IPs handled by different drivers.
> >>
> >> Still, I don't think there is a real need for such abstraction. Instead,
> >> related drivers shall be fixed to properly handle multiple memory
> >> masters and their IOMMUs.
> >>
> >
> > G2D, Scalers and FIMD of Exynos5420 has 2 System MMUs while aother SoC like
> > Exynos5250 does not.
> >
> > I don't understand why you are negative to this approach.
> > This is the simplest than the others.
> >
> > Let me show you an example.
> > FIMC-IS driver just controls MCU in FIMC-IS subsystem and the firmware of
> > the MCU controls all other peripherals in the subsystem. Each peripherals
> > have their own System MMU. Moreover, the configuration of the peripherals
> > varies according to the SoCs.
> >
> > If System MMU driver accepts multiple masters, everything is done in DT.
> > But I worry that it is not easy if System MMU driver does not support
> > multiple masters.
> 
> I believe I have stated enough reasons why this kind of implementation 
> is bad. I'm not going to waste time repeating myself.
> 
> Your concerns presented above are valid, however they are not related to 
> what is wrong with this patch. I have given you two proper ways to 
> handle this, none should be forced upon particular IOMMU master drivers 
> - their authors should have the chance to select the method that works 
> best for them.
> 

I don't still understand why you think this patch is wrong.
I think this is the best way not to think for all the driver developers
about other things than their business logic.

This does not hurt anyone and I think this is good enough.

If you want to provide another layer between master device and system mmu
as you mentioned, you do that. This patch does not restrict it.

Regards,

KyongHo

--
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 v3 0/2] Add stop callback to the cpufreq_driver interface.

[Rafael J. Wysocki]

On Tuesday, March 18, 2014 12:25:14 PM Dirk Brandewie wrote:
> On 03/18/2014 12:08 PM, Srivatsa S. Bhat wrote:
> > On 03/18/2014 10:52 PM, dirk.brande...@gmail.com wrote:
> >> From: Dirk Brandewie 
> >>
> >
> > I don't mean to nitpick, but generally its easier to deal with
> > patchsets if you post the subsequent versions in fresh email threads.
> > Otherwise it can get a bit muddled along with too many other email
> > discussions in the same thread :-(
> >
> >> Changes:
> >> v2->v3
> >> Changed the calling of the ->stop() callback to be conditional on the
> >> core being the last core controlled by a given policy.
> >>
> >
> > Wait, why? I'm sorry if I am not catching up with the discussions on
> > this issue quickly enough, but I don't see why we should make it
> > conditional on _that_. I thought we agreed that we should make it
> > conditional in the sense that ->stop() should be invoked only for
> > ->setpolicy drivers, right?
> 
> This was done at Viresh's suggestion since thought there might be value
> for ->target drivers.
> 
> Any of the options work for me
> called only for set_policy scaling drivers

And that's what we should do *today* in my opinion, unless we want to add
it to any ->target() drivers *right* now.  Do we want that?

Rafael

--
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/5] f2fs: increase pages_skipped when skipping writepages

[Jaegeuk Kim]

This patch increases pages_skipped when skipping writepages.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c | 11 ++-
 fs/f2fs/data.c   |  6 +-
 fs/f2fs/node.c   |  6 +-
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 1f52b70..aef32f3 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -190,12 +190,9 @@ static int f2fs_write_meta_pages(struct address_space 
*mapping,
int nrpages = nr_pages_to_skip(sbi, META);
long written;
 
-   if (wbc->for_kupdate)
-   return 0;
-
/* collect a number of dirty meta pages and write together */
-   if (get_pages(sbi, F2FS_DIRTY_META) < nrpages)
-   return 0;
+   if (wbc->for_kupdate || get_pages(sbi, F2FS_DIRTY_META) < nrpages)
+   goto skip_write;
 
/* if mounting is failed, skip writing node pages */
mutex_lock(>cp_mutex);
@@ -203,6 +200,10 @@ static int f2fs_write_meta_pages(struct address_space 
*mapping,
mutex_unlock(>cp_mutex);
wbc->nr_to_write -= written;
return 0;
+
+skip_write:
+   wbc->pages_skipped += get_pages(sbi, F2FS_DIRTY_META);
+   return 0;
 }
 
 long sync_meta_pages(struct f2fs_sb_info *sbi, enum page_type type,
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index e3b7cfa..3bc3809 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -870,7 +870,7 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
 
if (S_ISDIR(inode->i_mode) && wbc->sync_mode == WB_SYNC_NONE &&
get_dirty_dents(inode) < nr_pages_to_skip(sbi, DATA))
-   return 0;
+   goto skip_write;
 
if (wbc->nr_to_write < MAX_DESIRED_PAGES_WP) {
desired_nrtw = MAX_DESIRED_PAGES_WP;
@@ -892,6 +892,10 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
 
wbc->nr_to_write -= excess_nrtw;
return ret;
+
+skip_write:
+   wbc->pages_skipped += get_dirty_dents(inode);
+   return 0;
 }
 
 static int f2fs_write_begin(struct file *file, struct address_space *mapping,
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index cb514f1..7cc146b 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1209,7 +1209,7 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
 
/* collect a number of dirty node pages and write together */
if (get_pages(sbi, F2FS_DIRTY_NODES) < nr_pages_to_skip(sbi, NODE))
-   return 0;
+   goto skip_write;
 
/* if mounting is failed, skip writing node pages */
wbc->nr_to_write = 3 * max_hw_blocks(sbi);
@@ -1218,6 +1218,10 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
wbc->nr_to_write = nr_to_write - (3 * max_hw_blocks(sbi) -
wbc->nr_to_write);
return 0;
+
+skip_write:
+   wbc->pages_skipped += get_pages(sbi, F2FS_DIRTY_NODES);
+   return 0;
 }
 
 static int f2fs_set_node_page_dirty(struct page *page)
-- 
1.8.4.474.g128a96c

--
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/5] f2fs: introduce get_dirty_dents for readability

[Jaegeuk Kim]

The get_dirty_dents gives us the number of dirty dentry pages.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c | 2 +-
 fs/f2fs/f2fs.h   | 5 +
 fs/f2fs/inode.c  | 2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 911b6f9..4c0e98d 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -619,7 +619,7 @@ void remove_dirty_dir_inode(struct inode *inode)
return;
 
spin_lock(>dir_inode_lock);
-   if (atomic_read(_I(inode)->dirty_dents)) {
+   if (get_dirty_dents(inode)) {
spin_unlock(>dir_inode_lock);
return;
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 292cc3c..59fac1a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -704,6 +704,11 @@ static inline int get_pages(struct f2fs_sb_info *sbi, int 
count_type)
return atomic_read(>nr_pages[count_type]);
 }
 
+static inline int get_dirty_dents(struct inode *inode)
+{
+   return atomic_read(_I(inode)->dirty_dents);
+}
+
 static inline int get_blocktype_secs(struct f2fs_sb_info *sbi, int block_type)
 {
unsigned int pages_per_sec = sbi->segs_per_sec *
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index d518e37..0d8e4a2 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -273,7 +273,7 @@ void f2fs_evict_inode(struct inode *inode)
inode->i_ino == F2FS_META_INO(sbi))
goto no_delete;
 
-   f2fs_bug_on(atomic_read(_I(inode)->dirty_dents));
+   f2fs_bug_on(get_dirty_dents(inode));
remove_dirty_dir_inode(inode);
 
if (inode->i_nlink || is_bad_inode(inode))
-- 
1.8.4.474.g128a96c

--
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 4/5] f2fs: introduce nr_pages_to_write for segment alignment

[Jaegeuk Kim]

This patch introduces nr_pages_to_write to align page writes to the segment
or other operational unit size, which can be tuned according to the system
environment.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c | 11 ++-
 fs/f2fs/data.c   | 12 +++-
 fs/f2fs/node.c   |  8 +++-
 fs/f2fs/segment.h| 24 
 4 files changed, 36 insertions(+), 19 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index aef32f3..2a00c94 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -187,18 +187,19 @@ static int f2fs_write_meta_pages(struct address_space 
*mapping,
struct writeback_control *wbc)
 {
struct f2fs_sb_info *sbi = F2FS_SB(mapping->host->i_sb);
-   int nrpages = nr_pages_to_skip(sbi, META);
-   long written;
+   long diff, written;
 
/* collect a number of dirty meta pages and write together */
-   if (wbc->for_kupdate || get_pages(sbi, F2FS_DIRTY_META) < nrpages)
+   if (wbc->for_kupdate ||
+   get_pages(sbi, F2FS_DIRTY_META) < nr_pages_to_skip(sbi, META))
goto skip_write;
 
/* if mounting is failed, skip writing node pages */
mutex_lock(>cp_mutex);
-   written = sync_meta_pages(sbi, META, nrpages);
+   diff = nr_pages_to_write(sbi, META, wbc);
+   written = sync_meta_pages(sbi, META, wbc->nr_to_write);
mutex_unlock(>cp_mutex);
-   wbc->nr_to_write -= written;
+   wbc->nr_to_write = max((long)0, wbc->nr_to_write - written - diff);
return 0;
 
 skip_write:
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 3bc3809..b0c923a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -844,8 +844,6 @@ redirty_out:
return AOP_WRITEPAGE_ACTIVATE;
 }
 
-#define MAX_DESIRED_PAGES_WP   4096
-
 static int __f2fs_writepage(struct page *page, struct writeback_control *wbc,
void *data)
 {
@@ -862,7 +860,7 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
bool locked = false;
int ret;
-   long excess_nrtw = 0, desired_nrtw;
+   long diff;
 
/* deal with chardevs and other special file */
if (!mapping->a_ops->writepage)
@@ -872,11 +870,7 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
get_dirty_dents(inode) < nr_pages_to_skip(sbi, DATA))
goto skip_write;
 
-   if (wbc->nr_to_write < MAX_DESIRED_PAGES_WP) {
-   desired_nrtw = MAX_DESIRED_PAGES_WP;
-   excess_nrtw = desired_nrtw - wbc->nr_to_write;
-   wbc->nr_to_write = desired_nrtw;
-   }
+   diff = nr_pages_to_write(sbi, DATA, wbc);
 
if (!S_ISDIR(inode->i_mode)) {
mutex_lock(>writepages);
@@ -890,7 +884,7 @@ static int f2fs_write_data_pages(struct address_space 
*mapping,
 
remove_dirty_dir_inode(inode);
 
-   wbc->nr_to_write -= excess_nrtw;
+   wbc->nr_to_write = max((long)0, wbc->nr_to_write - diff);
return ret;
 
 skip_write:
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 7cc146b..5e9c38e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1202,7 +1202,7 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
struct writeback_control *wbc)
 {
struct f2fs_sb_info *sbi = F2FS_SB(mapping->host->i_sb);
-   long nr_to_write = wbc->nr_to_write;
+   long diff;
 
/* balancing f2fs's metadata in background */
f2fs_balance_fs_bg(sbi);
@@ -1211,12 +1211,10 @@ static int f2fs_write_node_pages(struct address_space 
*mapping,
if (get_pages(sbi, F2FS_DIRTY_NODES) < nr_pages_to_skip(sbi, NODE))
goto skip_write;
 
-   /* if mounting is failed, skip writing node pages */
-   wbc->nr_to_write = 3 * max_hw_blocks(sbi);
+   diff = nr_pages_to_write(sbi, NODE, wbc);
wbc->sync_mode = WB_SYNC_NONE;
sync_node_pages(sbi, 0, wbc);
-   wbc->nr_to_write = nr_to_write - (3 * max_hw_blocks(sbi) -
-   wbc->nr_to_write);
+   wbc->nr_to_write = max((long)0, wbc->nr_to_write - diff);
return 0;
 
 skip_write:
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index bbd9761..9fc46ee 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -683,3 +683,27 @@ static inline int nr_pages_to_skip(struct f2fs_sb_info 
*sbi, int type)
else
return 0;
 }
+
+/*
+ * When writing pages, it'd better align nr_to_write for segment size.
+ */
+static inline long nr_pages_to_write(struct f2fs_sb_info *sbi, int type,
+   struct writeback_control *wbc)
+{
+   long nr_to_write, desired;
+
+   if (wbc->sync_mode != WB_SYNC_NONE)
+   return 0;
+
+   nr_to_write = wbc->nr_to_write;
+
+   if (type == DATA)
+   desired = 

[PATCH 5/5] f2fs: call f2fs_wait_on_page_writeback instead of native function

[Jaegeuk Kim]

If a page is on writeback, f2fs can face with deadlock due to under writepages.
This is caused by merging IOs inside f2fs, so if it comes to detect, let's throw
merged IOs, which is implemented by f2fs_wait_on_page_writeback.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/checkpoint.c |  6 ++
 fs/f2fs/dir.c|  9 +++--
 fs/f2fs/file.c   |  6 +++---
 fs/f2fs/node.c   | 10 +-
 fs/f2fs/recovery.c   |  2 +-
 5 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 2a00c94..d0c5065 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -33,14 +33,12 @@ struct page *grab_meta_page(struct f2fs_sb_info *sbi, 
pgoff_t index)
struct address_space *mapping = META_MAPPING(sbi);
struct page *page = NULL;
 repeat:
-   page = grab_cache_page(mapping, index);
+   page = grab_cache_page_write_begin(mapping, index, 0);
if (!page) {
cond_resched();
goto repeat;
}
 
-   /* We wait writeback only inside grab_meta_page() */
-   wait_on_page_writeback(page);
SetPageUptodate(page);
return page;
 }
@@ -168,7 +166,7 @@ static int f2fs_write_meta_page(struct page *page,
if (unlikely(is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)))
goto no_write;
 
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, META);
write_meta_page(sbi, page);
 no_write:
dec_page_count(sbi, F2FS_DIRTY_META);
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index f3a80ce..7c9b17c 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -253,7 +253,7 @@ void f2fs_set_link(struct inode *dir, struct f2fs_dir_entry 
*de,
struct page *page, struct inode *inode)
 {
lock_page(page);
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, DATA);
de->ino = cpu_to_le32(inode->i_ino);
set_de_type(de, inode);
kunmap(page);
@@ -352,14 +352,11 @@ static struct page *init_inode_metadata(struct inode 
*inode,
err = f2fs_init_security(inode, dir, name, page);
if (err)
goto put_error;
-
-   wait_on_page_writeback(page);
} else {
page = get_node_page(F2FS_SB(dir->i_sb), inode->i_ino);
if (IS_ERR(page))
return page;
 
-   wait_on_page_writeback(page);
set_cold_node(inode, page);
}
 
@@ -494,7 +491,7 @@ start:
++level;
goto start;
 add_dentry:
-   wait_on_page_writeback(dentry_page);
+   f2fs_wait_on_page_writeback(dentry_page, DATA);
 
page = init_inode_metadata(inode, dir, name);
if (IS_ERR(page)) {
@@ -543,7 +540,7 @@ void f2fs_delete_entry(struct f2fs_dir_entry *dentry, 
struct page *page,
int i;
 
lock_page(page);
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, DATA);
 
dentry_blk = (struct f2fs_dentry_block *)kaddr;
bit_pos = dentry - (struct f2fs_dir_entry *)dentry_blk->dentry;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index a4cc1d6..e755ee5 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -76,7 +76,7 @@ static int f2fs_vm_page_mkwrite(struct vm_area_struct *vma,
trace_f2fs_vm_page_mkwrite(page, DATA);
 mapped:
/* fill the page */
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, DATA);
 out:
sb_end_pagefault(inode->i_sb);
return block_page_mkwrite_return(err);
@@ -245,7 +245,7 @@ static void truncate_partial_data_page(struct inode *inode, 
u64 from)
f2fs_put_page(page, 1);
return;
}
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, DATA);
zero_user(page, offset, PAGE_CACHE_SIZE - offset);
set_page_dirty(page);
f2fs_put_page(page, 1);
@@ -422,7 +422,7 @@ static void fill_zero(struct inode *inode, pgoff_t index,
f2fs_unlock_op(sbi);
 
if (!IS_ERR(page)) {
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, DATA);
zero_user(page, start, len);
set_page_dirty(page);
f2fs_put_page(page, 1);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 5e9c38e..707fd20 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -725,7 +725,7 @@ skip_partial:
f2fs_put_page(page, 1);
goto restart;
}
-   wait_on_page_writeback(page);
+   f2fs_wait_on_page_writeback(page, NODE);
ri->i_nid[offset[0] - NODE_DIR1_BLOCK] = 0;
set_page_dirty(page);
unlock_page(page);
@@ -814,7 +814,7 @@ struct page *new_node_page(struct dnode_of_data *dn,
if