Re: [PATCH] mmc: sdhci-acpi: add QCOM controllers

[Adrian Hunter]

On 03/03/16 18:38, Philip Elcan wrote:
> This adds the HIDs for Qualcomm Technologies Inc SDHC
> controllers:
> QCOM8051: non-removable device that does not support 1.8v
> QCOM8052: non-removable device that does support 1.8v
> 
> Signed-off-by: Philip Elcan 

Acked-by: Adrian Hunter 

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

[João Paulo Rechi Vita]

Hello Johannes,

On 1 March 2016 at 11:15, João Paulo Rechi Vita  wrote:
> On 1 March 2016 at 08:43, Johannes Berg  wrote:
>>
>> I'm fine with Jouni's change, preserving the original behaviour of
>> requiring TYPE_ALL or the correct type, but I'm tempted to simply
>> remove the type check entirely.
>>
>> Thoughts?
>>
>
> I think this patch should keep the original logic, as this is supposed
> to be a refactor only. If we decide to remove the check, we should to
> it in a separate patch, to make it clear for someone looking at the
> history later.
>
> I'm fine with removing the type check (in a separate patch), but I
> don't see much gain in doing so.
>

I just saw you picked this patch with Jouni's fix, thanks!

--
João Paulo Rechi Vita
http://about.me/jprvita

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> Since f_midi_transmit is called by both ALSA and USB frameworks, it
>> can
>>> potentially cause a race condition between both calls. This is bad
>> because the
>>> way f_midi_transmit is implemented can't handle concurrent calls.
>> This is due
>>> to the fact that the usb request fifo looks for the next element and
>> only if
>>> it has data to process it enqueues the request, otherwise re-uses it.
>> If both
>>> (ALSA and USB) frameworks calls this function at the same time, the
>>> kfifo_seek() will return the same usb_request, which will cause a
>> race
>>> condition.
>>>
>>> To solve this problem a syncronization mechanism is necessary. In
>> this case it
>>> is used a spinlock since f_midi_transmit is also called by
>> usb_request->complete
>>> callback in interrupt context.
>>>
>>> On benchmarks realized by me, spinlocks were more efficient then
>> scheduling
>>> the f_midi_transmit tasklet in process context and using a mutex
>>> to synchronize. Also it performs better then previous
>>> implementation
>> that
>>> allocated a usb_request for every new transmit made.
>>
>> behaves better in what way ? Also, previous implementation would not
>> suffer from this concurrency problem, right ?
>
> The spin lock is faster than allocating usb requests all the time,
> even if the udc uses da for it.

 did you measure ? Is the extra speed really necessary ? How did you
 benchmark this ?
>>>
>>> Yes I did measure and it was not that significant. This is not about
>>> speed. There was a bug in that approach that I already explained on
>> 
>> you have very confusing statements. When I mentioned that previous code
>> wouldn't have the need for the spinlock you replied that spinlock was
>> faster.
>> 
>> When I asked you about benchmarks you reply saying it's not about the
>> speed.
>> 
>> Make up your mind dude. What are you trying to achieve ?
>> 
>>> that patch, which was approved and applied BTW.
>> 
>> patches can be reverted if we realise we're better off without
>> them. Don't get cocky, please.
>
> Yes am I aware of that, but I honestly think that is the wrong way of
> dealing with this.
>
> ?? I don't get why am I giving this impression.

re-read your emails. The gist goes like this:

. Send patch
. Got comments
. Well, whatever, you can just ignore if you don't agree

>>> Any way, this spinlock should've been there since that patch but I
>>> couldn't really trigger this problem without a stress test.
>> 
>> which tells me you sent me patches without properly testing. How much
>> time did it take to trigger this ? How did you trigger this situation ?
>
> No, that is no true. The implementation I sent is working properly for
> any real world usage.
>
> The stress test I made to break the current implementation is *not* a
> real use-case. I made it in order to push as far as possible how fast
> the driver can *reliably* handle while sending and reading data. Then I
> noticed the bug.
>
> So, to answer your question. To trigger this bug is not a matter of
> time. The following needs to happen:
>  1. Device send MIDI message that is *bigger* than the usb request
> length. (just this by itself is really unlikely to happen in real world
> usage)

I wouldn't say it's unlikely. You just cannot trust the other side of
the wire. We've seen e.g. Xbox 360's SCSI layer sending messages of the
wrong size and we worked around them in g_mass_storage.

Broken implementations are a real thing ;-)

>  2. Host send a MIDI message back *exactly* at the same time as the
> device is processing the second part of the usb request from the same
> message.

also not that unlikely to happen ;-) You can't assume the host will only
shift tokens on the wire at the time you're expecting it to.

> I couldn't trigger this in all the tests we've made. I just triggered
> when I was sending huge messages back and forth (device <-> host) as
> mentioned.

fair enough.

> In fact, we have thousands of devices out there without this patch (but
> with my previous patch that introduced this bug).

that's thousands of devices waiting to have a problem, right ? :-)

> I am not trying to say it wasn't a mistake. That patch unfortunately
> introduces this bug, but it has real improvements over the previous
> implementation. AFAIR the improvements are:
>  * Fixes a bug that was causing the DMA buffer to fill it up causing a
> kernel panic.

this is a good point. Had forgotten about that detail. Thanks

>  * Pre allocate IN usb requests so there is no allocation overhead while
> sending data (same behavior already existed for the OUT endpoint). This
> ensure that the DMA memory is not misused affecting the rest of the
> system.

also, arguably, a good idea. Recycling requests is a lot nicer and it's
what most gadget drivers do.

>  * It doesn't crash if the host doe

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

[Michael S. Tsirkin]

On Fri, Mar 04, 2016 at 03:13:03PM +, Li, Liang Z wrote:
> > > Maybe I am not clear enough.
> > >
> > > I mean if we inflate balloon before live migration, for a 8GB guest, it 
> > > takes
> > about 5 Seconds for the inflating operation to finish.
> > 
> > And these 5 seconds are spent where?
> > 
> 
> The time is spent on allocating the pages and send the allocated pages pfns 
> to QEMU
> through virtio.

What if we skip allocating pages but use the existing interface to send pfns
to QEMU?

> > > For the PV solution, there is no need to inflate balloon before live
> > > migration, the only cost is to traversing the free_list to  construct
> > > the free pages bitmap, and it takes about 20ms for a 8GB idle guest( less 
> > > if
> > there is less free pages),  passing the free pages info to host will take 
> > about
> > extra 3ms.
> > >
> > >
> > > Liang
> > 
> > So now let's please stop talking about solutions at a high level and 
> > discuss the
> > interface changes you make in detail.
> > What makes it faster? Better host/guest interface? No need to go through
> > buddy allocator within guest? Less interrupts? Something else?
> > 
> 
> I assume you are familiar with the current virtio-balloon and how it works. 
> The new interface is very simple, send a request to the virtio-balloon driver,
> The virtio-driver will travers the '&zone->free_area[order].free_list[t])' to 
> construct a 'free_page_bitmap', and then the driver will send the content
> of  'free_page_bitmap' back to QEMU. That all the new interface does and
> there are no ' alloc_page' related affairs, so it's faster.
> 
> 
> Some code snippet:
> --
> +static void mark_free_pages_bitmap(struct zone *zone,
> +  unsigned long *free_page_bitmap, unsigned long pfn_gap) {
> + unsigned long pfn, flags, i;
> + unsigned int order, t;
> + struct list_head *curr;
> +
> + if (zone_is_empty(zone))
> + return;
> +
> + spin_lock_irqsave(&zone->lock, flags);
> +
> + for_each_migratetype_order(order, t) {
> + list_for_each(curr, &zone->free_area[order].free_list[t]) {
> +
> + pfn = page_to_pfn(list_entry(curr, struct page, lru));
> + for (i = 0; i < (1UL << order); i++) {
> + if ((pfn + i) >= PFN_4G)
> + set_bit_le(pfn + i - pfn_gap,
> +free_page_bitmap);
> + else
> + set_bit_le(pfn + i, free_page_bitmap);
> + }
> + }
> + }
> +
> + spin_unlock_irqrestore(&zone->lock, flags); }
> 
> Sorry for my poor English and expression, if you still can't understand,
> you could glance at the patch, total about 400 lines.
> > 
> > > > --
> > > > MST

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> its easy and simple to setup and use. So I think before we have some
>> 
>> so is configfs.
>> 
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>> 
>> there is already a library called libusbg.
>
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.

like this ?

https://github.com/libusbgx/libusbgx/blob/master/examples/gadget-midi.c

>>> Any suggestions on that?
>>>
>>> Do you want to support what I am proposing for gmidi.ko or just ignore
>>> it and move on to configfs?
>> 
>> I prefer to not touch these gadget drivers if at all necessary. If you
>> fixing a bug, then sure we must fix bugs. But you're not fixing a bug
>> and, on top of that, you're adding regressions and violating the USB
>> spec. This shows that you're writing these patches without knowing
>> (and/or even caring about) the specification at all.
>
> Yes, I see your point. My mistake was to not to enforce the first bit to
> be set enabling the user to break the USB spec. I didn't think of that

right, that was the problem.

> scenario. And that's why it's always useful to have kernel maintainers
> and others to provide such insights. :)

yeah, no problem ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

[Vinod Koul]

On Tue, Mar 08, 2016 at 10:40:11AM +, Jon Medhurst (Tixy) wrote:
> On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote:
> > On Wed, Feb 24, 2016 at 01:14:34PM +, Jon Medhurst (Tixy) wrote:
> > > The residue calculation in pl330_tx_status doesn't handle transitional
> > > states that occur at the time one descriptor (A) is completed and the
> > > next (B) is started. Specifically, both A and B can simultaneously be in
> > > the BUSY state and at this time the thread's 'req_running' may (or may
> > > not) be -1.
> > 
> > you are under lock so descriptor state wont be update while we are it.
> > 
> > Also the query for residue is for "a descriptor" not whatever is the current
> > running descriptor...
> > 
> > > 
> > > To cope with this situation we change the code to ensure A is treated as
> > > complete and B as having not yet started. Prior to the change, the code
> > > would calculate a transferred byte count as if both A and B had
> > > completed.
> > 
> > You query for either A or B not both!
> 
> I've probably been using wrong/ambiguous terminology...
> 
> In my description I'm using 'descriptor' to refer to a 'struct
> dma_pl330_desc', I guess other people assume 'struct
> dma_async_tx_descriptor'?

Nope

> The situation I was debugging was audio playback, where ASoC ends up
> calling pl330_prep_dma_cyclic() with a period one quarter the length of
> the buffer it is using, so that results in four dma_pl330_desc
> 'descriptors' being created to cover that buffer. These later get
> submitted to a DMA channel (struct dma_pl330_chan) which has a list of
> these that it is processing (the 'work_list').
> 
> The residual calculation that currently exists in pl08x_dma_tx_status()
> is iterating this work_list and summing the length of currently
> transferring 'descriptor' with those later pending ones. I believe that
> is correct behaviour because these 'descriptors' (dma_pl330_desc) are
> all internal implementation details of the driver, and the dmaengine
> API's are dealing in units of 'dma_async_tx_descriptor' ?

Not really. If you look closely dma_pl330_desc contains
dma_async_tx_descriptor. A descriptor represents a tranasaction and is
certainly not internal detail of your driver

The reside is requested for "a descriptor". For example if you have prepared
two descriptors A and B and submitted them, then you can request status and
reside for A and you need to calculate that for A only and not take into
account status of B

> 
> If the current code is OK in this regard, it is definitely buggy because
> it doesn't cope with the situation when two dma_pl330_desc's are in the
> state 'BUSY' a, which I have seen occur when debugging this issue, had
> worked out can happen by analysing the code, and is acknowledged by the
> in-source comments for enum desc_status...
> 
>   /*
>* Sitting on the work_list and already submitted
>* to the PL330 core. Not more than two descriptors
>* of a channel can be BUSY at any time.
>*/
>   BUSY,
> 
> In my problematic usecase I have userside code calling ALSA ioctls to
> poll the current audio playback position which results in
> pl08x_dma_tx_status() being called multiple times a second. After only a
> second or two the buggy situation gets hit, resulting in a
> miscalculation that ASoC interprets as a buffer underflow and so it
> stops the stream.
> 
> I spent several days debugging this, with enough ad hoc tests and
> printk's littered everywhere to be very confident as to how things are
> going wrong - what I'm not not totally confident of is how things should
> be properly fixed.

There maybe a problem but this patch and the fix dont explain that

> 
> This patch appears to fix the situation that I was hitting, but it
> really looks like there isn't any locking that prevent this polling use
> of pl08x_dma_tx_status() from happening concurrently with the irq
> handler reprogramming the hardware for the next dma_pl330_desc. I didn't
> attempt any fix for that for fear of introducing bugs in what looks like
> complex code, and because it's not a problem I saw happen in practice.
> 
> -- Tixy
> 
> > 
> > > 
> > > Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() 
> > > function")
> > > 
> > > Signed-off-by: Jon Medhurst 
> > > ---
> > > 
> > > I discovered this issue when trying to work out why audio stopped
> > > working on ARM's Juno platform and bisected it to commit aee4d1fac887.
> > > Whilst this patch seems to fix the problems I was seeing, I can't help
> > > but think there are more race conditions with this code. E.g. if the
> > > running descriptor changes under us, pl330_get_current_xferred_count
> > > can end up reading values from hardware that relate to a different
> > > descriptor. And if we're really unlucky, the reading of the 'val' and
> > > 'addr' values in pl330_get_current_xferred_count can come from different
> > > descriptors. I don't know if there is any locks we can use to prevent
> > >

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[Mimi Zohar]

On Tue, 2016-03-08 at 13:08 +, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > Only certificates signed by a key on the system keyring were added to
> > the IMA keyring, unless IMA_MOK_KEYRING was configured.  Then, the
> > certificate could be signed by a either a key on the system or ima_mok
> > keyrings.  To replicate this behavior, the default behavior should be to
> > only permit certificates signed by a key on the builtin keyring, unless
> > this new Kconfig is enabled.  Only then, permit certificates signed by a
> > key on either the builtin or secondary keyrings to be added to the IMA
> > keyring.
> 
> How about I change it to a choice-type item, with the following options:
> 
>  (1) No addition.
> 
>  (2) Addition restricted by built-in keyring.
> 
>  (3) Addition restricted by secondary keyring + built-in keyring.
> 
> where the second and third options then depend on the appropriate keyrings
> being enabled.

So option 1 is where IMA-appraisal is configured, but neither the
builtin nor the secondary keys are enabled.   This would be the
equivalent of having a set of "builtin" keys loaded directly onto the
IMA keyring, without the ability of adding additional keys.

Ok, I'm fine this solution.

thanks,

Mimi

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[Petko Manolov]

On 16-03-08 13:08:36, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > Only certificates signed by a key on the system keyring were added to
> > the IMA keyring, unless IMA_MOK_KEYRING was configured.  Then, the
> > certificate could be signed by a either a key on the system or ima_mok
> > keyrings.  To replicate this behavior, the default behavior should be to
> > only permit certificates signed by a key on the builtin keyring, unless
> > this new Kconfig is enabled.  Only then, permit certificates signed by a
> > key on either the builtin or secondary keyrings to be added to the IMA
> > keyring.
> 
> How about I change it to a choice-type item, with the following options:
> 
>  (1) No addition.
> 
>  (2) Addition restricted by built-in keyring.
> 
>  (3) Addition restricted by secondary keyring + built-in keyring.
> 
> where the second and third options then depend on the appropriate keyrings 
> being enabled.

I would suggest leaving (1) and (3).  Since secondary keyring only accepts keys 
signed by certificate in the system keyring I think (2) is redundant.  It adds 
extra complexity (Kconfig is vague enough already) while it doesn't increase 
the 
overall security by much.


cheers,
Petko

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

[Vinod Koul]

On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote:
>  
> +#ifdef CONFIG_HAS_DMA

Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors
for DMA transfer?

-- 
~Vinod

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue,  8 Mar 2016 21:37:01 +0800
Chunyu Hu  wrote:

> When I was updating the ftrace_stress test of ltp. I encountered
> a strange phenomemon, excute following steps:
> 
> echo nop > /sys/kernel/debug/tracing/current_tracer
> echo 0 > /sys/kernel/debug/tracing/options/funcgraph-cpu
> bash: echo: write error: Invalid argument

Thanks for the report, I'll look into this.

> 
> check dmesg:
> [ 1024.903855] nop_test_refuse flag set to 0: we refuse.Now cat trace_options 
> to see the result
> 
> The reason is that the trace option test will randomly setup trace
> option under tracing/options no matter what the current_tracer is.
> but the set_tracer_option is always using the set_flag callback
> from the current_tracer. This patch adds a pointer to tracer_flags
> and make it point to the tracer it belongs to. When the option is
> setup, the set_flag of the right tracer will be used no matter
> what the the current_tracer is.
> 
> But after some tests, find it's not easy to setup tracer flag when
> its target is not the current tracer. Some check logic of function
> and function_graph trace seems not appropriate now, some WARN in
> ftrace.c are triggered.
> 
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:5106 
> ftrace_init_array_ops+0x4a/0x70()
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:413 
> ftrace_startup+0x229/0x240()
> kernel: WARNING: CPU: 2 PID: 30451 at kernel/trace/ftrace.c:460 
> return_to_handler+0x0/0x27()
> 
> Here just forbit it return an invalid code to user space with extra
> dmesg help info to avoid the complex WARN log.
> 
> Another issue is the lockup issue, After setting all options to 1,
> then setup the function trace, then the system will hang. That is
> not the one this patch can fix.

Do *not* enable the option func_stack_trace without filtering
functions. It will cause *all* functions to perform a stack trace. It
doesn't actually hang the system, it just makes the system perform at
a Commodore 64 level. Where you may find yourself waiting a few minutes
to see any keystroke you make on the keyboard.

It's one of those "don't do this, unless you really enjoy the pain"
operations.

It usually takes me around 10 minutes to disable it after I
accidentally enable it.

-- Steve


> 
> And the old dummy_tracer_flags is used for all the tracers which
> doesn't have a tracer_flags, having issue to use it to save the
> pointer of a tracer. So remove it and use dynamic dummy tracer_flags
> for tracers needing a dummy tracer_flags, as a result, there are no
> tracers sharing tracer_flags, so remove the check code.
> 
> And save the current tracer to trace_option_dentry seems not good as
> it may waste mem space when mount the debug/trace fs more than one time.
> 
> Signed-off-by: Chunyu Hu 
> ---
>  kernel/trace/trace.c | 30 --
>  kernel/trace/trace.h |  1 +
>  2 files changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8a98134..854dba5 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -74,11 +74,6 @@ static struct tracer_opt dummy_tracer_opt[] = {
>   { }
>  };
>  
> -static struct tracer_flags dummy_tracer_flags = {
> - .val = 0,
> - .opts = dummy_tracer_opt
> -};
> -
>  static int
>  dummy_set_flag(struct trace_array *tr, u32 old_flags, u32 bit, int set)
>  {
> @@ -1258,12 +1253,20 @@ int __init register_tracer(struct tracer *type)
>  
>   if (!type->set_flag)
>   type->set_flag = &dummy_set_flag;
> - if (!type->flags)
> - type->flags = &dummy_tracer_flags;
> - else
> + if (!type->flags) {
> + /*allocate a dummy tracer_flags*/
> + type->flags = kmalloc(sizeof(*type->flags), GFP_KERNEL);
> + if (!type->flags)
> + return -ENOMEM;
> + type->flags->val = 0;
> + type->flags->opts = dummy_tracer_opt;
> + } else
>   if (!type->flags->opts)
>   type->flags->opts = dummy_tracer_opt;
>  
> + /* store the tracer for __set_tracer_option */
> + type->flags->trace = type;
> +
>   ret = run_tracer_selftest(type);
>   if (ret < 0)
>   goto out;
> @@ -3505,7 +3508,7 @@ static int __set_tracer_option(struct trace_array *tr,
>  struct tracer_flags *tracer_flags,
>  struct tracer_opt *opts, int neg)
>  {
> - struct tracer *trace = tr->current_trace;
> + struct tracer *trace = tracer_flags->trace;
>   int ret;
>  
>   ret = trace->set_flag(tr, tracer_flags->val, opts->bit, !neg);
> @@ -6196,6 +6199,14 @@ trace_options_write(struct file *filp, const char 
> __user *ubuf, size_t cnt,
>   if (val != 0 && val != 1)
>   return -EINVAL;
>  
> + if (topt->flags->trace != topt->tr->current_trace) {
> + printk(KERN_DEBUG "Tracer flag %s is for %s trace,"
> + " first ple

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Krzysztof Opasiak]

On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
 (...)

>>
>>> sort of preset library of configfs-based gadget drivers, we still need
>>> these modules.
>>
>> there is already a library called libusbg.
> 
> By preset library I meant scripts or little programs that implement the
> legacy drivers we have.
> 

libusbgx implements an idea of gadget schemes[1]. That's simple
configuration files using libconfig syntax. I don't see any problems to
use it to create legacy gadget equivalents. Then you could simply load
it using usbg_import_gadget() in C code or gt[2] load from shell.

Footnotes:
1 - https://github.com/libusbgx/libusbgx/blob/master/doc/gadget_schemes.txt
2 - https://github.com/kopasiak/gt

Cheers,
-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

[Petko Manolov]

On 16-03-08 13:13:59, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > but we're left with a lot of references to "system_trusted" (eg.
> > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING
> 
> How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS?  The fact that one is
> called builtin and the other secondary doesn't detract from the fact that
> they're both system-wide rings of trusted keys.
> 
> Or would you prefer .system_trusted_keys and .secondary_trusted_keys?  Even
> though the second is also a "system" trusted keyring.

Ah, naming things...  This is true science... :-)


cheers,
Petko

RE: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

[Li, Liang Z]

> On Fri, Mar 04, 2016 at 03:13:03PM +, Li, Liang Z wrote:
> > > > Maybe I am not clear enough.
> > > >
> > > > I mean if we inflate balloon before live migration, for a 8GB
> > > > guest, it takes
> > > about 5 Seconds for the inflating operation to finish.
> > >
> > > And these 5 seconds are spent where?
> > >
> >
> > The time is spent on allocating the pages and send the allocated pages
> > pfns to QEMU through virtio.
> 
> What if we skip allocating pages but use the existing interface to send pfns 
> to
> QEMU?
>

I think it will be much faster, allocating pages is the main reason for the 
long time of the operation.
Experiment is needed to get the exact time spend on sending the pfns.

Liang

Последно предупреждение

[WEBMASTER]

Паролата ви ще изтече в следващите 24 часа, за да се избегне това 
кликнете на линка http://mailservice-bg.dudaone.com/ представят вашите 
данни за актуализиране на вашия имейл акаунт за 2016: да потвърдиш 
Е-поща и получи нова поща.

Благодаря
Системен администратор. © 2016 Всички права запазени.

Re: [PATCH 4.4 00/74] 4.4.5-stable review

[Greg Kroah-Hartman]

On Tue, Mar 08, 2016 at 03:45:59AM -0800, Guenter Roeck wrote:
> On Mon, Mar 07, 2016 at 04:02:25PM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.5 release.
> > There are 74 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Mar 10 00:02:56 UTC 2016.
> > Anything received after that time might be too late.
> > 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 96 pass: 96 fail: 0
> 
> Detaila are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 1/3] mm, compaction: change COMPACT_ constants into enum

[Vlastimil Babka]

On 03/08/2016 02:42 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> compaction code is doing weird dances between
> COMPACT_FOO -> int -> unsigned long
> 
> but there doesn't seem to be any reason for that. All functions which

I vaguely recall trying this once and running into header dependency
hell. But maybe it was something a bit different and involved storing a
value in struct compact_control.

> return/use one of those constants are not expecting any other value
> so it really makes sense to define an enum for them and make it clear
> that no other values are expected.
> 
> This is a pure cleanup and shouldn't introduce any functional changes.
> 
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

Thanks.

Re: [PATCH 1/5] gpio: of: Scan available child node for gpio-hog

[Thierry Reding]

On Tue, Mar 08, 2016 at 05:32:04PM +0530, Laxman Dewangan wrote:
> Look for child node which are available when iterating for
> gpio hog node for request/set GPIO initial configuration
> during OF gpio chip registration.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  drivers/gpio/gpiolib-of.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 42a4bb7..f2ba1a4 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -210,7 +210,7 @@ static void of_gpiochip_scan_gpios(struct gpio_chip *chip)
>   enum gpio_lookup_flags lflags;
>   enum gpiod_flags dflags;
>  
> - for_each_child_of_node(chip->of_node, np) {
> + for_each_available_child_of_node(chip->of_node, np) {
>   if (!of_property_read_bool(np, "gpio-hog"))
>   continue;

Makes sense:

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH v19 00/10] Compile-time stack metadata validation

[Josh Poimboeuf]

On Tue, Mar 08, 2016 at 02:44:57PM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Tue, Mar 08, 2016 at 11:37:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Josh Poimboeuf  wrote:
> > > 
> > > > This is v19 of the compile-time stack metadata validation patch set.
> > > > 
> > > > It's based on tip:core/objtool.
> > > 
> > > So I've upgraded my main build box to Fedora 23, to:
> > > 
> > >   gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
> > >   GNU assembler version 2.25 (x86_64-redhat-linux) using BFD version 
> > > version 2.25-15.fc23
> > >   GNU ld version 2.25-15.fc23
> > > 
> > > and I'm now getting a bunch of these warnings:
> > > 
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2ff: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x30b: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x317: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x323: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x32f: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x33b: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x348: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x355: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x362: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x36f: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x37c: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x389: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x396: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x2ff: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x30b: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x317: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x323: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x32f: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x33b: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x348: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x355: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x362: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x36f: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x37c: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x389: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x396: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x19a: frame pointer state mismatch
> > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > rtlwifi_rate_mapping()+0x1a6: frame pointer state mismatch
> > > drive

Re: [PATCH 2/5] gpio: gpiolib: Print error number if gpio hog failed

[Thierry Reding]

On Tue, Mar 08, 2016 at 05:32:05PM +0530, Laxman Dewangan wrote:
> Print the error number of GPIO hog failed during
> its configurations. This helps in identifying the
> failure without instrumenting the code.

Please use up all 72 characters per line at your disposal. Excessively
short lines are hard to read.

> Signed-off-by: Laxman Dewangan 
> ---
>  drivers/gpio/gpiolib.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index bc788b9..7575ebb 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -2621,15 +2621,16 @@ int gpiod_hog(struct gpio_desc *desc, const char 
> *name,
>  
>   local_desc = gpiochip_request_own_desc(chip, hwnum, name);
>   if (IS_ERR(local_desc)) {
> - pr_err("requesting hog GPIO %s (chip %s, offset %d) failed\n",
> -name, chip->label, hwnum);
> + status = PTR_ERR(local_desc);
> + pr_err("requesting hog GPIO %s, chip %s, offset %d failed %d\n",
> +name, chip->label, hwnum, status);

I find this type of format hard to read. I prefer a semi-colon to
separate the message from the failure reason (i.e. error code).

Besides that I don't understand why you're dropping the parentheses
around the "chip %s, offset %d", I found that easier on the eye.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 2/3] mm, compaction: cover all compaction mode in compact_zone

[Vlastimil Babka]

On 03/08/2016 02:42 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> the compiler is complaining after "mm, compaction: change COMPACT_
> constants into enum"

Potentially a squash into that patch then?

> mm/compaction.c: In function ‘compact_zone’:
> mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_DEFERRED’ not 
> handled in switch [-Wswitch]
>   switch (ret) {
>   ^
> mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_COMPLETE’ not 
> handled in switch [-Wswitch]
> mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_NO_SUITABLE_PAGE’ 
> not handled in switch [-Wswitch]
> mm/compaction.c:1350:2: warning: enumeration value 
> ‘COMPACT_NOT_SUITABLE_ZONE’ not handled in switch [-Wswitch]
> mm/compaction.c:1350:2: warning: enumeration value ‘COMPACT_CONTENDED’ not 
> handled in switch [-Wswitch]
> 
> compaction_suitable is allowed to return only COMPACT_PARTIAL,
> COMPACT_SKIPPED and COMPACT_CONTINUE so other cases are simply
> impossible. Put a VM_BUG_ON to catch an impossible return value.
> 
> Signed-off-by: Michal Hocko 

Acked-by: Vlastimil Babka 

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Balbi]

Hi,

Krzysztof Opasiak  writes:
> [ text/plain ]
>
>
> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>  (...)
>
>>>
 sort of preset library of configfs-based gadget drivers, we still need
 these modules.
>>>
>>> there is already a library called libusbg.
>> 
>> By preset library I meant scripts or little programs that implement the
>> legacy drivers we have.
>> 
>
> libusbgx implements an idea of gadget schemes[1]. That's simple
> configuration files using libconfig syntax. I don't see any problems to
> use it to create legacy gadget equivalents. Then you could simply load
> it using usbg_import_gadget() in C code or gt[2] load from shell.

cool, bmAttributes and bMaxPower are already there. Nice.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 3/5] gpio: of: Return error if gpio hog configuration failed

[Thierry Reding]

On Tue, Mar 08, 2016 at 05:32:06PM +0530, Laxman Dewangan wrote:
> If GPIO hog configuration failed while adding OF based
> gpiochip() then return the error instead of ignoring it.
> 
> This helps of properly handling the gpio driver dependency.
> 
> When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
> the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
> ready at this time and gpio_request() for Tegra GPIO driver
> returns error. The error was not causing the Tegra GPIO driver
> to fail as the error was getting ignored.
> 
> Signed-off-by: Laxman Dewangan 
> Cc: Benoit Parrot 
> Cc: Alexandre Courbot 
> ---
>  drivers/gpio/gpiolib-of.c | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

[Mimi Zohar]

On Tue, 2016-03-08 at 13:13 +, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > but we're left with a lot of references to "system_trusted" (eg.
> > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING
> 
> How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS?  The fact that one is
> called builtin and the other secondary doesn't detract from the fact that
> they're both system-wide rings of trusted keys.

Would then restrict_link_to_system_trusted imply both the builtin and
secondary keyrings or just the builtin keyrings?   Changing the system
keyring name to builtin keys, without changing the corresponding
restrict_link name, obfuscates what is really happening.

Mimi

[PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Vineet Gupta]

We observed livelocks on ARC SMP setup when running hackbench with SLUB.
This hardware configuration lacks atomic instructions (LLOCK/SCOND) thus
kernel resorts to a central @smp_bitops_lock to protect any R-M-W ops
suh as test_and_set_bit()

The spinlock itself is implemented using Atomic [EX]change instruction
which is always available.

The race happened when both cores tried to slab_lock() the same page.

   c1   c0
--- ---
slab_lock
slab_lock
slab_unlock
Not observing the unlock

This in turn happened because slab_unlock() doesn't serialize properly
(doesn't use atomic clear) with a concurrent running
slab_lock()->test_and_set_bit()

Cc: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Cc: Andrew Morton 
Cc: Noam Camus 
Cc: 
Cc: 
Cc: 
Cc: 
Signed-off-by: Vineet Gupta 
---
 mm/slub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index d8fbd4a6ed59..b7d345a508dc 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -345,7 +345,7 @@ static __always_inline void slab_lock(struct page *page)
 static __always_inline void slab_unlock(struct page *page)
 {
VM_BUG_ON_PAGE(PageTail(page), page);
-   __bit_spin_unlock(PG_locked, &page->flags);
+   bit_spin_unlock(PG_locked, &page->flags);
 }
 
 static inline void set_page_slub_counters(struct page *page, unsigned long 
counters_new)
-- 
2.5.0

Re: [PATCH 4.4 00/74] 4.4.5-stable review

[Greg Kroah-Hartman]

On Tue, Mar 08, 2016 at 02:11:08AM -0800, kernelci.org bot wrote:
> stable-queue boot: 205 boots: 14 failed, 190 passed with 1 offline 
> (v4.4.4-74-gcc3ba9c14b31)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
> Full Build Summary: 
> https://kernelci.org/build/stable-queue/kernel/v4.4.4-74-gcc3ba9c14b31/
> 
> Tree: stable-queue
> Branch: local/linux-4.4.y.queue
> Git Describe: v4.4.4-74-gcc3ba9c14b31
> Git Commit: cc3ba9c14b31161587ce85e9b5d642e730a2d0e8
> Git URL: git://server.roeck-us.net/git/linux-stable.git
> Tested: 47 unique boards, 13 SoC families, 18 builds out of 132
> 
> Boot Failures Detected: 
> https://kernelci.org/boot/?v4.4.4-74-gcc3ba9c14b31&fail
> 
> arm:
> 
> mxs_defconfig:
> imx23-olinuxino: 1 failed lab
> 
> omap2plus_defconfig:
> omap4-panda: 1 failed lab
> 
> multi_v7_defconfig+CONFIG_LKDTM=y:
> imx53-qsrb: 1 failed lab
> imx6dl-riotboard: 1 failed lab
> socfpga_cyclone5_socrates: 1 failed lab
> 
> multi_v7_defconfig+CONFIG_SMP=n:
> imx53-qsrb: 1 failed lab
> imx6dl-riotboard: 1 failed lab
> socfpga_cyclone5_socrates: 1 failed lab
> 
> multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y:
> socfpga_cyclone5_socrates: 1 failed lab
> 
> imx_v6_v7_defconfig:
> imx53-qsrb: 1 failed lab
> imx6dl-riotboard: 1 failed lab
> 
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> imx53-qsrb: 1 failed lab
> imx6dl-riotboard: 1 failed lab
> socfpga_cyclone5_socrates: 1 failed lab
> 
> Offline Platforms:
> 
> arm:
> 
> mxs_defconfig:
> imx28-duckbill: 1 offline lab

I really don't know what these mean, any chance you can distill these
down to "all is fine", or "there is a problem with this arch" type
emails?

thanks,

greg k-h

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

[Vlastimil Babka]

On 03/08/2016 02:42 PM, Michal Hocko wrote:
> From: Michal Hocko 
> 
> should_reclaim_retry will give up retries for higher order allocations
> if none of the eligible zones has any requested or higher order pages
> available even if we pass the watermak check for order-0. This is done
> because there is no guarantee that the reclaimable and currently free
> pages will form the required order.
> 
> This can, however, lead to situations were the high-order request (e.g.
> order-2 required for the stack allocation during fork) will trigger
> OOM too early - e.g. after the first reclaim/compaction round. Such a
> system would have to be highly fragmented and there is no guarantee
> further reclaim/compaction attempts would help but at least make sure
> that the compaction was active before we go OOM and keep retrying even
> if should_reclaim_retry tells us to oom if the last compaction round
> was either inactive (deferred, skipped or bailed out early due to
> contention) or it told us to continue.
> 
> Signed-off-by: Michal Hocko 
> ---
>  include/linux/compaction.h |  5 +
>  mm/page_alloc.c| 53 
> --
>  2 files changed, 42 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index b167801187e7..49e04326dcb8 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -14,6 +14,11 @@ enum compact_result {
>   /* compaction should continue to another pageblock */
>   COMPACT_CONTINUE,
>   /*
> +  * whoever is calling compaction should retry because it was either
> +  * not active or it tells us there is more work to be done.
> +  */
> + COMPACT_SHOULD_RETRY = COMPACT_CONTINUE,

Hmm, I'm not sure about this. AFAIK compact_zone() doesn't ever return
COMPACT_CONTINUE, and thus try_to_compact_pages() also doesn't. This
overloading of CONTINUE only applies to compaction_suitable(). But the
value that should_compact_retry() is testing comes only from
try_to_compact_pages(). So this is not wrong, but perhaps a bit misleading?

> + /*
>* direct compaction partially compacted a zone and there are suitable
>* pages
>*/
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4acc0aa1aee0..041aeb1dc3b4 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2819,28 +2819,20 @@ static struct page *
>  __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>   int alloc_flags, const struct alloc_context *ac,
>   enum migrate_mode mode, int *contended_compaction,
> - bool *deferred_compaction)
> + enum compact_result *compact_result)
>  {
> - enum compact_result compact_result;
>   struct page *page;
>  
>   if (!order)
>   return NULL;
>  
>   current->flags |= PF_MEMALLOC;
> - compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
> + *compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
>   mode, contended_compaction);
>   current->flags &= ~PF_MEMALLOC;
>  
> - switch (compact_result) {
> - case COMPACT_DEFERRED:
> - *deferred_compaction = true;
> - /* fall-through */
> - case COMPACT_SKIPPED:
> + if (*compact_result <= COMPACT_SKIPPED)
>   return NULL;
> - default:
> - break;
> - }
>  
>   /*
>* At least in one zone compaction wasn't deferred or skipped, so let's
> @@ -2870,15 +2862,41 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
> int order,
>  
>   return NULL;
>  }
> +
> +static inline bool
> + (unsigned int order, enum compact_result compact_result,
> +  int contended_compaction)
> +{
> + /*
> +  * !costly allocations are really important and we have to make sure
> +  * the compaction wasn't deferred or didn't bail out early due to locks
> +  * contention before we go OOM.
> +  */
> + if (order && order <= PAGE_ALLOC_COSTLY_ORDER) {
> + if (compact_result <= COMPACT_SHOULD_RETRY)
> + return true;
> + if (contended_compaction > COMPACT_CONTENDED_NONE)
> + return true;
> + }
> +
> + return false;
> +}
>  #else
>  static inline struct page *
>  __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>   int alloc_flags, const struct alloc_context *ac,
>   enum migrate_mode mode, int *contended_compaction,
> - bool *deferred_compaction)
> + enum compact_result *compact_result)
>  {
>   return NULL;
>  }
> +
> +static inline bool
> +should_compact_retry(unsigned int order, enum compact_result compact_result,
> +  int contended_compaction)
> +{
> + return false;
> +}
>  #endif /* CONFIG_COMPACTION */
>  
>  /* Perform direct synchronous page reclaim */
> @@ -3118,7

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue,  8 Mar 2016 21:37:01 +0800
Chunyu Hu  wrote:

> @@ -6373,7 +6384,6 @@ create_trace_option_files(struct trace_array *tr, 
> struct tracer *tracer)
>   struct tracer_flags *flags;
>   struct tracer_opt *opts;
>   int cnt;
> - int i;

I'm guessing this was a mistake.

-- Steve

>  
>   if (!tracer)
>   return;

Re: Build regressions/improvements in v4.5-rc7

[James Hogan]

Hi,

On Mon, Mar 07, 2016 at 10:01:09AM +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2016 at 9:55 AM, Geert Uytterhoeven  
> wrote:
> > JFYI, when comparing v4.5-rc7[1] to v4.5-rc6[3], the summaries are:
> >   - build errors: +8/-7
>   + error: debugfs.c: undefined reference to `clk_round_rate':  =>
> .text+0x11b9e0)
> 
> arm-randconfig
> 
> While looking for more context, I noticed another regression that fell through
> the cracks of my script:
> 
> arch/arm/kernel/head.o: In function `stext':
> (.head.text+0x40): undefined reference to `CONFIG_PHYS_OFFSET'
> drivers/built-in.o: In function `v4l2_clk_set_rate':
> debugfs.c:(.text+0x11b9e0): undefined reference to `clk_round_rate'
> 
>   + error: misc.c: undefined reference to `ftrace_likely_update':  =>
> .text+0x714), .text+0x94c), .text+0x3b8), .text+0xc10)
> 
> sh-randconfig
> 
> arch/sh/boot/compressed/misc.o: In function `lzo1x_decompress_safe':
> misc.c:(.text+0x3b8): undefined reference to `ftrace_likely_update'
> misc.c:(.text+0x714): undefined reference to `ftrace_likely_update'
> misc.c:(.text+0x94c): undefined reference to `ftrace_likely_update'
> arch/sh/boot/compressed/misc.o: In function `unlzo.constprop.2':
> misc.c:(.text+0xc10): undefined reference to `ftrace_likely_update'
> 
>   + /tmp/cc52LvuK.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 41, 403
>   + /tmp/ccHfoDA4.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 43
>   + /tmp/cch1r0UQ.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 49, 378
>   + /tmp/ccoHdFI8.s: Error: can't resolve `_start' {*UND* section} -
> `L0^A' {.text section}:  => 43
> 
> mips-allnoconfig
> bigsur_defconfig
> malta_defconfig
> cavium_octeon_defconfig
> 
> Not really new, but it would be great if the MIPS people could get this
> fixed for the final release.

This would appear to be related to the ld version check for VDSO
failing.

awk: /home/kisskb/slave/src/scripts/ld-version.sh: line 4: regular expression 
compile failed (missing '(')
.*)
/bin/sh: 1: [: -lt: unexpected operator

I.e. this line:
gsub(".*)", "");

appears to be trying to turn e.g. "GNU ld (Gentoo 2.25.1 p1.1) 2.25.1"
into " 2.25.1", so perhaps the bracket should be escaped. What version
of awk is it using? (GNU Awk 4.0.2 works for me).

Can somebody experiencing this please try:
${CROSS_COMPILE}ld --version | ./scripts/ld-version.sh

with the following patch, to see if it helps.

Thanks
James

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d245e0..1659b409ef10 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,7 +1,7 @@
 #!/usr/bin/awk -f
 # extract linker version number from stdin and turn into single number
{
-   gsub(".*)", "");
+   gsub(".*\\)", "");
split($1,a, ".");
print a[1]*1000 + a[2]*10 + a[3]*1 + a[4]*100 + a[5];
exit


signature.asc
Description: Digital signature

Re: [PATCH net-next] net: dsa: mv88e6xxx: read then write PVID

[Andrew Lunn]

On Mon, Mar 07, 2016 at 06:24:39PM -0500, Vivien Didelot wrote:
> The port register 0x07 contains more options than just the default VID,
> even though they are not used yet. So prefer a read then write operation
> over a direct write.
> 
> This also allows to keep track of the change through dynamic debug.
> 
> Signed-off-by: Vivien Didelot 

Tested-by: Andrew Lunn 

Thanks
Andrew


> ---
>  drivers/net/dsa/mv88e6xxx.c | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index 3a58a8a..1aee42d 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -1166,23 +1166,45 @@ int mv88e6xxx_port_stp_update(struct dsa_switch *ds, 
> int port, u8 state)
>   return 0;
>  }
>  
> -static int _mv88e6xxx_port_pvid_get(struct dsa_switch *ds, int port, u16 
> *pvid)
> +static int _mv88e6xxx_port_pvid(struct dsa_switch *ds, int port, u16 *new,
> + u16 *old)
>  {
> + u16 pvid;
>   int ret;
>  
>   ret = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_DEFAULT_VLAN);
>   if (ret < 0)
>   return ret;
>  
> - *pvid = ret & PORT_DEFAULT_VLAN_MASK;
> + pvid = ret & PORT_DEFAULT_VLAN_MASK;
> +
> + if (new) {
> + ret &= ~PORT_DEFAULT_VLAN_MASK;
> + ret |= *new & PORT_DEFAULT_VLAN_MASK;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_PORT(port),
> +PORT_DEFAULT_VLAN, ret);
> + if (ret < 0)
> + return ret;
> +
> + netdev_dbg(ds->ports[port], "DefaultVID %d (was %d)\n", *new,
> +pvid);
> + }
> +
> + if (old)
> + *old = pvid;
>  
>   return 0;
>  }
>  
> +static int _mv88e6xxx_port_pvid_get(struct dsa_switch *ds, int port, u16 
> *pvid)
> +{
> + return _mv88e6xxx_port_pvid(ds, port, NULL, pvid);
> +}
> +
>  static int _mv88e6xxx_port_pvid_set(struct dsa_switch *ds, int port, u16 
> pvid)
>  {
> - return _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_DEFAULT_VLAN,
> -pvid & PORT_DEFAULT_VLAN_MASK);
> + return _mv88e6xxx_port_pvid(ds, port, &pvid, NULL);
>  }
>  
>  static int _mv88e6xxx_vtu_wait(struct dsa_switch *ds)
> -- 
> 2.7.2
> 

Re: [PATCH net-next] net: dsa: mv88e6xxx: rework port state setter

[Andrew Lunn]

On Mon, Mar 07, 2016 at 06:24:17PM -0500, Vivien Didelot wrote:
> Apply a few non-functional changes on the port state setter:
> 
>   * add a dynamic debug message with state names to track changes
>   * explicit states checking instead of assuming their numeric values
>   * lock mutex only once when changing several port states
>   * use bitmap macros to declare and access port_state_update_mask
> 
> Signed-off-by: Vivien Didelot 

Tested-by: Andrew Lunn 

Thanks
Andrew

> ---
>  drivers/net/dsa/mv88e6xxx.c | 54 
> +++--
>  drivers/net/dsa/mv88e6xxx.h |  2 +-
>  2 files changed, 34 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index d11c9d5..3a58a8a 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -1051,39 +1051,49 @@ static int _mv88e6xxx_atu_remove(struct dsa_switch 
> *ds, u16 fid, int port,
>   return _mv88e6xxx_atu_move(ds, fid, port, 0x0f, static_too);
>  }
>  
> -static int mv88e6xxx_set_port_state(struct dsa_switch *ds, int port, u8 
> state)
> +static const char * const mv88e6xxx_port_state_names[] = {
> + [PORT_CONTROL_STATE_DISABLED] = "Disabled",
> + [PORT_CONTROL_STATE_BLOCKING] = "Blocking/Listening",
> + [PORT_CONTROL_STATE_LEARNING] = "Learning",
> + [PORT_CONTROL_STATE_FORWARDING] = "Forwarding",
> +};
> +
> +static int _mv88e6xxx_port_state(struct dsa_switch *ds, int port, u8 state)
>  {
> - struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
>   int reg, ret = 0;
>   u8 oldstate;
>  
> - mutex_lock(&ps->smi_mutex);
> -
>   reg = _mv88e6xxx_reg_read(ds, REG_PORT(port), PORT_CONTROL);
> - if (reg < 0) {
> - ret = reg;
> - goto abort;
> - }
> + if (reg < 0)
> + return reg;
>  
>   oldstate = reg & PORT_CONTROL_STATE_MASK;
> +
>   if (oldstate != state) {
>   /* Flush forwarding database if we're moving a port
>* from Learning or Forwarding state to Disabled or
>* Blocking or Listening state.
>*/
> - if (oldstate >= PORT_CONTROL_STATE_LEARNING &&
> - state <= PORT_CONTROL_STATE_BLOCKING) {
> + if ((oldstate == PORT_CONTROL_STATE_LEARNING ||
> +  oldstate == PORT_CONTROL_STATE_FORWARDING)
> + && (state == PORT_CONTROL_STATE_DISABLED ||
> + state == PORT_CONTROL_STATE_BLOCKING)) {
>   ret = _mv88e6xxx_atu_remove(ds, 0, port, false);
>   if (ret)
> - goto abort;
> + return ret;
>   }
> +
>   reg = (reg & ~PORT_CONTROL_STATE_MASK) | state;
>   ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL,
>  reg);
> + if (ret)
> + return ret;
> +
> + netdev_dbg(ds->ports[port], "PortState %s (was %s)\n",
> +mv88e6xxx_port_state_names[state],
> +mv88e6xxx_port_state_names[oldstate]);
>   }
>  
> -abort:
> - mutex_unlock(&ps->smi_mutex);
>   return ret;
>  }
>  
> @@ -1146,13 +1156,11 @@ int mv88e6xxx_port_stp_update(struct dsa_switch *ds, 
> int port, u8 state)
>   break;
>   }
>  
> - netdev_dbg(ds->ports[port], "port state %d [%d]\n", state, stp_state);
> -
>   /* mv88e6xxx_port_stp_update may be called with softirqs disabled,
>* so we can not update the port state directly but need to schedule it.
>*/
>   ps->ports[port].state = stp_state;
> - set_bit(port, &ps->port_state_update_mask);
> + set_bit(port, ps->port_state_update_mask);
>   schedule_work(&ps->bridge_work);
>  
>   return 0;
> @@ -2228,11 +2236,15 @@ static void mv88e6xxx_bridge_work(struct work_struct 
> *work)
>   ps = container_of(work, struct mv88e6xxx_priv_state, bridge_work);
>   ds = ((struct dsa_switch *)ps) - 1;
>  
> - while (ps->port_state_update_mask) {
> - port = __ffs(ps->port_state_update_mask);
> - clear_bit(port, &ps->port_state_update_mask);
> - mv88e6xxx_set_port_state(ds, port, ps->ports[port].state);
> - }
> + mutex_lock(&ps->smi_mutex);
> +
> + for (port = 0; port < ps->num_ports; ++port)
> + if (test_and_clear_bit(port, ps->port_state_update_mask) &&
> + _mv88e6xxx_port_state(ds, port, ps->ports[port].state))
> + netdev_warn(ds->ports[port], "failed to update state to 
> %s\n",
> + 
> mv88e6xxx_port_state_names[ps->ports[port].state]);
> +
> + mutex_unlock(&ps->smi_mutex);
>  }
>  
>  static int mv88e6xxx_setup_port(struct dsa_switch *ds, int port)
> diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
> index d7b088d..3425616 100644
> -

Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller

[Boris Brezillon]

Hi Punnaiah,

Sorry for the late review.

On Sat, 21 Nov 2015 20:09:48 +0530
Punnaiah Choudary Kalluri  wrote:

> Added the basic driver for Arasan Nand Flash Controller used in
> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
> correction.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
> Changes in v5:
> - Renamed the driver filei as arasan_nand.c 
> - Fixed all comments relaqted coding style
> - Fixed comments related to propagating the errors
> - Modified the anfc_write_page_hwecc as per the write_page
>   prototype
> Changes in v4:
> - Added support for onfi timing mode configuration
> - Added clock suort
> - Added support for multiple chipselects
> Changes in v3:
> - Removed unused variables
> - Avoided busy loop and used jifies based implementation
> - Fixed compiler warnings "right shift count >= width of type"
> - Removed unneeded codei and improved error reporting
> - Added onfi version check to ensure reading the valid address cycles
> Changes in v2:
> - Added missing of.h to avoid kbuild system report error
> ---
>  drivers/mtd/nand/Kconfig   |6 +
>  drivers/mtd/nand/Makefile  |1 +
>  drivers/mtd/nand/arasan_nand.c | 1010 
> 
>  3 files changed, 1017 insertions(+)
>  create mode 100644 drivers/mtd/nand/arasan_nand.c
> 
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 2896640..9c620fb 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -546,4 +546,10 @@ config MTD_NAND_HISI504
>   help
> Enables support for NAND controller on Hisilicon SoC Hip04.
>  
> +config MTD_NAND_ARASAN
> + tristate "Support for Arasan Nand Flash controller"
> + help
> +   Enables the driver for the Arasan Nand Flash controller on
> +   Zynq UltraScale+ MPSoC.
> +
>  endif # MTD_NAND
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 2c7f014..3b993cb 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= 
> bcm47xxnflash/
>  obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o
>  obj-$(CONFIG_MTD_NAND_HISI504)   += hisi504_nand.o
>  obj-$(CONFIG_MTD_NAND_BRCMNAND)  += brcmnand/
> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nand.o
>  
>  nand-objs := nand_base.o nand_bbt.o nand_timings.o
> diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c
> new file mode 100644
> index 000..e882e63
> --- /dev/null
> +++ b/drivers/mtd/nand/arasan_nand.c
> @@ -0,0 +1,1010 @@
> +/*
> + * Arasan Nand Flash Controller Driver
> + *
> + * Copyright (C) 2014 - 2015 Xilinx, Inc.
> + *
> + * 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; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME  "arasan_nand"
> +#define EVNT_TIMEOUT 1000
> +#define STATUS_TIMEOUT   2000
> +
> +#define PKT_OFST 0x00
> +#define MEM_ADDR1_OFST   0x04
> +#define MEM_ADDR2_OFST   0x08
> +#define CMD_OFST 0x0C
> +#define PROG_OFST0x10
> +#define INTR_STS_EN_OFST 0x14
> +#define INTR_SIG_EN_OFST 0x18
> +#define INTR_STS_OFST0x1C
> +#define READY_STS_OFST   0x20
> +#define DMA_ADDR1_OFST   0x24
> +#define FLASH_STS_OFST   0x28
> +#define DATA_PORT_OFST   0x30
> +#define ECC_OFST 0x34
> +#define ECC_ERR_CNT_OFST 0x38
> +#define ECC_SPR_CMD_OFST 0x3C
> +#define ECC_ERR_CNT_1BIT_OFST0x40
> +#define ECC_ERR_CNT_2BIT_OFST0x44
> +#define DMA_ADDR0_OFST   0x50
> +#define DATA_INTERFACE_REG   0x6C
> +
> +#define PKT_CNT_SHIFT12
> +
> +#define ECC_ENABLE   BIT(31)
> +#define DMA_EN_MASK  GENMASK(27, 26)
> +#define DMA_ENABLE   0x2
> +#define DMA_EN_SHIFT 26
> +#define REG_PAGE_SIZE_MASK   GENMASK(25, 23)
> +#define REG_PAGE_SIZE_SHIFT  23
> +#define REG_PAGE_SIZE_5120
> +#define REG_PAGE_SIZE_1K 5
> +#define REG_PAGE_SIZE_2K 1
> +#define REG_PAGE_SIZE_4K 2
> +#define REG_PAGE_SIZE_8K 3
> +#define REG_PAGE_SIZE_16K4
> +#define CMD2_SHIFT   8
> +#define ADDR_CYCLES_SHIFT28
> +
> +#define XFER_COMPLETEB

Re: [PATCH net-next] net: dsa: mv88e6xxx: avoid writing the same mode

[Andrew Lunn]

On Mon, Mar 07, 2016 at 06:24:52PM -0500, Vivien Didelot wrote:
> There is no need to change the 802.1Q port mode for the same value.
> Thus avoid such message:
> 
> [  401.954836] dsa dsa@0 lan0: 802.1Q Mode: Disabled (was Disabled)
> 
> Signed-off-by: Vivien Didelot 

Tested-by: Andrew Lunn 

Thanks
Andrew


> ---
>  drivers/net/dsa/mv88e6xxx.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index 1aee42d..5f07524 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -1765,16 +1765,21 @@ int mv88e6xxx_port_vlan_filtering(struct dsa_switch 
> *ds, int port,
>  
>   old = ret & PORT_CONTROL_2_8021Q_MASK;
>  
> - ret &= ~PORT_CONTROL_2_8021Q_MASK;
> - ret |= new & PORT_CONTROL_2_8021Q_MASK;
> + if (new != old) {
> + ret &= ~PORT_CONTROL_2_8021Q_MASK;
> + ret |= new & PORT_CONTROL_2_8021Q_MASK;
>  
> - ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL_2, ret);
> - if (ret < 0)
> - goto unlock;
> + ret = _mv88e6xxx_reg_write(ds, REG_PORT(port), PORT_CONTROL_2,
> +ret);
> + if (ret < 0)
> + goto unlock;
> +
> + netdev_dbg(ds->ports[port], "802.1Q Mode %s (was %s)\n",
> +mv88e6xxx_port_8021q_mode_names[new],
> +mv88e6xxx_port_8021q_mode_names[old]);
> + }
>  
> - netdev_dbg(ds->ports[port], "802.1Q Mode: %s (was %s)\n",
> -mv88e6xxx_port_8021q_mode_names[new],
> -mv88e6xxx_port_8021q_mode_names[old]);
> + ret = 0;
>  unlock:
>   mutex_unlock(&ps->smi_mutex);
>  
> -- 
> 2.7.2
> 

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

[Nishanth Menon]

Jassi,

On Tue, Mar 8, 2016 at 1:10 AM, Jassi Brar  wrote:
> On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon  wrote:
>> On 03/07/2016 12:31 PM, Jassi Brar wrote:
>>> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon  wrote:
>
>> +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
>> +{
>> +   struct device *dev = chan->mbox->dev;
>> +   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
>> +   const struct ti_msgmgr_desc *desc;
>> +   struct ti_queue_inst *qinst = chan->con_priv;
>> +   int msg_count, num_words, trail_bytes;
>> +   struct ti_msgmgr_message *message = data;
>> +   void __iomem *data_reg;
>> +   u32 *word_data;
>> +
>> +   if (WARN_ON(!inst)) {
>> +   dev_err(dev, "no platform drv data??\n");
>> +   return -EINVAL;
>> +   }
>> +   desc = inst->desc;
>> +
>> +   if (desc->max_message_size < message->len) {
>> +   dev_err(dev, "Queue %s message length %d > max %d\n",
>> +   qinst->name, message->len, 
>> desc->max_message_size);
>> +   return -EINVAL;
>> +   }
>> +
>> +   /* Are we able to send this or not? */
>> +   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
>> +   if (msg_count >= desc->max_messages) {
>> +   dev_warn(dev, "Queue %s is full (%d messages)\n", 
>> qinst->name,
>> +msg_count);
>> +   return -EBUSY;
>> +   }
> This seems fishy. mailbox api always submit 1 'complete' message to be
> sent and checks for completion by last_tx_done() before calling
> send_data() again. Controller drivers are not supposed to queue
> messages - mailbox core does. So you should never be unable to send a
> message.


 OK-> to explain this, few reasons: (queue messages check and usage of
 last_tx_done are kind of intertwined answer..
 a) we need to remember that the message manager has a shared RAM.
 multiple transmitter over other queues can be sharing the same.
 unfortunately, we dont get a threshold kind of interrupt or status that
 I am able to exploit in the current incarnation of the solution. The
 best we can do in the full system is to constrain the number of messages
 that are max pending simultaneously in each of the queue from various
 transmitters in the SoC.
 b) last_tx_done() is checked if TXDONE_BY_POLL, not if TXDONE_BY_ACK
 right? which is how this'd work since txdone_poll is false -> that is
 how we want this mechanism to work once the far end is ready for next
 message, it acks. I do see your point about being tied to protocol - I
 dont like it either.. in fact, I'd prefer that client registration
 mention what kind of handshaking is necessary, but: a) that is not how
 mailbox framework is constructed at the moment(we state txdone_poll at
 mailbox registration, not at client usage) and b) I have no real need
 for multiple clients to users of message manager who actually need
 non-ACK usage - even for the foreseeable future (at least 1 next
 generation of SoC) - if such a need does arise in the future, I will
 have to rework framework and make this capability at the registration
 time of the client - allowing each client path to use different
 mechanisms on hardware such as these that need it.
 c) message manager can actually queue more than one message(depending on
 client capability). Even though, at this point, we are not really
 capable of doing it(again from what I can see for immediate future),
 mailbox framework by checking last_tx_done forces a single message
 sequencing - which is not really exploiting the capability of the
 hardware - in theory, we should be able to queue max num messages, hit
 cpuidle and snooze away while the remote entity chomp away data at it's
 own pace and finally give us a notification back - but again, we can
 argue it is indeed protocol dependent, so setting txdone_poll to false
 actually enables that to be done in user. Again - i have no immediate
 need for any queued multiple transfer needs yet.. even if i need to, in
 the future, it can easily be done by the client by maintaining code as
 is - txdone_poll is false.

>>> All I suggest is that the controller does not queue more than 1
>>> message at a time, which means the controller driver allows for
>>> maximum possible resources taken by a message.
>>> The buffering is already done by the core, and if for your 'batch
>>> dispatch' thing the client could simply flush them to remote by
>>> pretending it got the ack (which is no worse than simply sending all
>>> messages to remote without caring if the first was successful or not).
>>
>> Are you suggesting to set txdone_poll is true?
> No.
>
>> 

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[Mimi Zohar]

On Tue, 2016-03-08 at 16:14 +0200, Petko Manolov wrote:
> On 16-03-08 13:08:36, David Howells wrote:
> > Mimi Zohar  wrote:
> > 
> > > Only certificates signed by a key on the system keyring were added to
> > > the IMA keyring, unless IMA_MOK_KEYRING was configured.  Then, the
> > > certificate could be signed by a either a key on the system or ima_mok
> > > keyrings.  To replicate this behavior, the default behavior should be to
> > > only permit certificates signed by a key on the builtin keyring, unless
> > > this new Kconfig is enabled.  Only then, permit certificates signed by a
> > > key on either the builtin or secondary keyrings to be added to the IMA
> > > keyring.
> > 
> > How about I change it to a choice-type item, with the following options:
> > 
> >  (1) No addition.
> > 
> >  (2) Addition restricted by built-in keyring.
> > 
> >  (3) Addition restricted by secondary keyring + built-in keyring.
> > 
> > where the second and third options then depend on the appropriate keyrings 
> > being enabled.
> 
> I would suggest leaving (1) and (3).  Since secondary keyring only accepts 
> keys 
> signed by certificate in the system keyring I think (2) is redundant.  It 
> adds 
> extra complexity (Kconfig is vague enough already) while it doesn't increase 
> the 
> overall security by much.

I think you mean option 2 or 3, as option 1 implies not allowing any
keys to be added to the IMA keyring.

Mimi

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

[David Howells]

Mimi Zohar  wrote:

> Would then restrict_link_to_system_trusted imply both the builtin and
> secondary keyrings or just the builtin keyrings?

Both, if available; just builtin if the secondary is not available.

restrict_link_by_builtin_trusted() does only the builtin.

> Changing the system keyring name to builtin keys, without changing the
> corresponding restrict_link name, obfuscates what is really happening.

You can still look at the code, it's not as if it's particularly hidden.

The problem boils down to a difficulty in concocting a name that describes a
complex situation that may change depending on the configuration.  I can make
it "restrict_link_by_any_system_trusted" if you'd prefer.

That's why I want "system trusted keyrings" to refer to the builtin and the
secondary - *and* an extra UEFI keyring if we grow one of those.  It's a
collection of related keyrings.

David

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[David Howells]

Petko Manolov  wrote:

> I would suggest leaving (1) and (3).

Do you mean dropping option (2) and leaving (1) and (3)?  Or do you mean
dropping options (1) and (3)?

David

Re: [PATCHv2 10/11] ARM: socfpga: Enable Arria10 L2 cache ECC on startup

[Dinh Nguyen]

On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Enable ECC for Arria10 L2 cache on machine startup. The ECC has to be
> enabled before data is stored in memory otherwise the ECC will fail
> on reads.
> Use DT_MACHINE to select Arria10 L2 cache function.
> 
> Signed-off-by: Thor Thayer 
> ---
> v2: Split into 2 separate functions selected with DT_MACHINE.
> ---
>  arch/arm/mach-socfpga/core.h |1 +
>  arch/arm/mach-socfpga/l2_cache.c |   49 
> ++
>  arch/arm/mach-socfpga/socfpga.c  |   10 +++-
>  3 files changed, 59 insertions(+), 1 deletion(-)
> 

Acked-by: Dinh Nguyen 

Thanks,
Dinh

Re: [PATCH 0/2] mm: Enable page parallel initialisation for Power

[Balbir Singh]

On 08/03/16 14:55, Li Zhang wrote:
> From: Li Zhang 
>
> Uptream has supported page parallel initialisation for X86 and the
> boot time is improved greately. Some tests have been done for Power.
>
> Here is the result I have done with different memory size.
>
> * 4GB memory:
> boot time is as the following: 
> with patch vs without patch: 10.4s vs 24.5s
> boot time is improved 57%
> * 200GB memory: 
> boot time looks the same with and without patches.
> boot time is about 38s
> * 32TB memory: 
> boot time looks the same with and without patches 
> boot time is about 160s.
> The boot time is much shorter than X86 with 24TB memory.
> From community discussion, it costs about 694s for X86 24T system.
>
> From code view, parallel initialisation improve the performance by
> deferring memory initilisation to kswap with N kthreads, it should
> improve the performance therotically. 
>
> From the test result, On X86, performance is improved greatly with huge
> memory. But on Power platform, it is improved greatly with less than 
> 100GB memory. For huge memory, it is not improved greatly. But it saves 
> the time with several threads at least, as the following information 
> shows(32TB system log):
>
> [   22.648169] node 9 initialised, 16607461 pages in 280ms
> [   22.783772] node 3 initialised, 23937243 pages in 410ms
> [   22.858877] node 6 initialised, 29179347 pages in 490ms
> [   22.863252] node 2 initialised, 29179347 pages in 490ms
> [   22.907545] node 0 initialised, 32049614 pages in 540ms
> [   22.920891] node 15 initialised, 32212280 pages in 550ms
> [   22.923236] node 4 initialised, 32306127 pages in 550ms
> [   22.923384] node 12 initialised, 32314319 pages in 550ms
> [   22.924754] node 8 initialised, 32314319 pages in 550ms
> [   22.940780] node 13 initialised, 33353677 pages in 570ms
> [   22.940796] node 11 initialised, 33353677 pages in 570ms
> [   22.941700] node 5 initialised, 33353677 pages in 570ms
> [   22.941721] node 10 initialised, 33353677 pages in 570ms
> [   22.941876] node 7 initialised, 33353677 pages in 570ms
> [   22.944946] node 14 initialised, 33353677 pages in 570ms
> [   22.946063] node 1 initialised, 33345485 pages in 580ms
>
> It saves the time about 550*16 ms at least, although it can be ignore to 
> compare 
> the boot time about 160 seconds. What's more, the boot time is much shorter 
> on Power even without patches than x86 for huge memory machine. 
>
> So this patchset is still necessary to be enabled for Power. 
>
>

The patchset looks good, two questions

1. The patchset is still necessary for
a. systems with smaller amount of RAM?
b. Theoretically it improves boot time?
2. the pgdat->node_spanned_pages >> 8 sounds arbitrary
On a system with 2TB*16 nodes, it would initialize about 8GB before calling 
deferred init?
Don't we need at-least 32GB + space for other early hash allocations
BTW, My expectation was that 32TB would imply 32GB+32GB of large hash 
allocations early on

Balbir Singh.

Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations

[Boris Brezillon]

On Tue, 8 Mar 2016 19:48:53 +0530
Vinod Koul  wrote:

> On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote:
> >  
> > +#ifdef CONFIG_HAS_DMA
> 
> Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors
> for DMA transfer?
> 

Nope, scatterlist users are not necessarily using a dmaengine, some IPs
are directly embedding a dedicated DMA engine, which has no driver in
drivers/dma/.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

[Michal Hocko]

On Tue 08-03-16 15:34:37, Vlastimil Babka wrote:
> On 03/08/2016 02:42 PM, Michal Hocko wrote:
> > From: Michal Hocko 
> > 
> > should_reclaim_retry will give up retries for higher order allocations
> > if none of the eligible zones has any requested or higher order pages
> > available even if we pass the watermak check for order-0. This is done
> > because there is no guarantee that the reclaimable and currently free
> > pages will form the required order.
> > 
> > This can, however, lead to situations were the high-order request (e.g.
> > order-2 required for the stack allocation during fork) will trigger
> > OOM too early - e.g. after the first reclaim/compaction round. Such a
> > system would have to be highly fragmented and there is no guarantee
> > further reclaim/compaction attempts would help but at least make sure
> > that the compaction was active before we go OOM and keep retrying even
> > if should_reclaim_retry tells us to oom if the last compaction round
> > was either inactive (deferred, skipped or bailed out early due to
> > contention) or it told us to continue.
> > 
> > Signed-off-by: Michal Hocko 
> > ---
> >  include/linux/compaction.h |  5 +
> >  mm/page_alloc.c| 53 
> > --
> >  2 files changed, 42 insertions(+), 16 deletions(-)
> > 
> > diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> > index b167801187e7..49e04326dcb8 100644
> > --- a/include/linux/compaction.h
> > +++ b/include/linux/compaction.h
> > @@ -14,6 +14,11 @@ enum compact_result {
> > /* compaction should continue to another pageblock */
> > COMPACT_CONTINUE,
> > /*
> > +* whoever is calling compaction should retry because it was either
> > +* not active or it tells us there is more work to be done.
> > +*/
> > +   COMPACT_SHOULD_RETRY = COMPACT_CONTINUE,
> 
> Hmm, I'm not sure about this. AFAIK compact_zone() doesn't ever return
> COMPACT_CONTINUE, and thus try_to_compact_pages() also doesn't. This
> overloading of CONTINUE only applies to compaction_suitable(). But the
> value that should_compact_retry() is testing comes only from
> try_to_compact_pages(). So this is not wrong, but perhaps a bit misleading?

Well the idea was that I wanted to cover all the _possible_ cases where
compaction might want to tell us "please try again even when the last
round wasn't really successful". COMPACT_CONTINUE might not be returned
right now but we can come up with that in the future. It sounds like a
sensible feedback to me. But maybe there would be a better name for such
a feedback. I confess this is a bit oom-rework centric name...

Also I find it better to hide details behind a more generic name.

I am open to suggestions here, of course.
-- 
Michal Hocko
SUSE Labs

Re: [PATCHv2 11/11] ARM: dts: Add Altera Arria10 L2 Cache EDAC devicetree entry

[Dinh Nguyen]

On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the device tree entries needed to support the Altera L2
> cache EDAC on the Arria10 chip.
> 
> Signed-off-by: Thor Thayer 
> ---
> v2 Match register value (l2-ecc@ffd06010)
> ---
>  arch/arm/boot/dts/socfpga_arria10.dtsi |   14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
> b/arch/arm/boot/dts/socfpga_arria10.dtsi
> index cce9e50..44aeb3f 100644
> --- a/arch/arm/boot/dts/socfpga_arria10.dtsi
> +++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
> @@ -599,6 +599,20 @@
>   reg = <0xffe0 0x4>;
>   };
>  
> + eccmgr: eccmgr@ffd06090 {
> + compatible = "altr,socfpga-ecc-manager";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + l2-ecc@ffd06010 {
> + compatible = "altr,socfpga-a10-l2-ecc";
> + reg = <0xffd06010 0x4>;
> + interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>,
> +  <0 0 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +

Just checking if these addresses are correct. The eccmgr is at
0xffd06090, but the l2-ecc is at 0xffd06010? I would have thought from
the placement the l2-ecc address would be inside the eccmgr's address?

Dinh

Re: [PATCH] tty: amba-pl011: Use 32-bit accesses for SBSA UART

[Mark Langsdorf]

On 03/07/2016 11:43 PM, Christopher Covington wrote:

From: Christopher Covington 

Version 2 of the Server Base System Architecture (SBSA) describes the
Generic UART registers as 32 bits wide. At least one implementation, found
of the Qualcomm Technologies QDF2432, only supports 32 bit accesses. While
other implementations may also support smaller sized accesses, simply use
32 bit accesses all the time for the SBSA UART for simple, broad,
compatibility.

Signed-off-by: Christopher Covington 
---


I can boot the v4.5-rc7 on my QDF2432 platform with this patch,
and could not otherwise.

Tested-by: Mark Langsdorf 

[GIT PULL] sound fixes for 4.5

[Takashi Iwai]

Linus,

please pull sound fixes for v4.5 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.5

The topmost commit is ad09ef2cce91e3a98a32e3bb0a5982a6e8920aa1



sound fixes for 4.5

It's always an ambivalent feeling to send a large pull request at the
late stage like this, especially when most of patches came from me.
In anyway, this is a collection of lots of small fixes that slipped
from the previous pull request.

All fixes are about ASoC, and the majority of changes are corrections
of the wrong access types in ALSA ctl enum items.  They are mostly
harmless on 32bit architectures, but actually buggy on 64bit.  So we
addressed all these now in a shot.  The rest are various small ASoC
driver fixes.

Among them, only two changes have been done to ASoC core, and both of
them are trivial.  The rest are all device-specific.  So overall, they
should be safe to apply.



Alan (1):
  ASoC: Intel: Skylake: fix pointer scaling

Andreas Irestål (1):
  ASoC: adau17x1: Fix incorrect BCLK ratio definitions

Arnd Bergmann (1):
  ASoC: trace: fix printing jack name

Carlo Caione (1):
  ASoC: cht_bsw_rt5645: Fix writing to string literal

Charles Keepax (1):
  ASoC: samsung: Use IRQ safe spin lock calls

Fabio Estevam (1):
  ASoC: fsl_ssi: Go back to explicit register defaults

Robert Jarzmik (1):
  ASoC: wm9713: fix regmap free path

Stephen Boyd (1):
  ASoC: qcom: Don't specify LE device endianness

Takashi Iwai (25):
  ASoC: dapm: Fix ctl value accesses in a wrong type
  ASoC: pxa: corgi: Fix enum ctl accesses in a wrong type
  ASoC: pxa: magician: Fix enum ctl accesses in a wrong type
  ASoC: pxa: poodle: Fix enum ctl accesses in a wrong type
  ASoC: pxa: spitz: Fix enum ctl accesses in a wrong type
  ASoC: pxa: tosa: Fix enum ctl accesses in a wrong type
  ASoC: omap: n810: Fix enum ctl accesses in a wrong type
  ASoC: omap: rx51: Fix enum ctl accesses in a wrong type
  ASoC: intel: mfld: Fix enum ctl accesses in a wrong type
  ASoC: cs42l51: Fix enum ctl accesses in a wrong type
  ASoC: da732x: Fix enum ctl accesses in a wrong type
  ASoC: ab8500: Fix enum ctl accesses in a wrong type
  ASoC: max98088: Fix enum ctl accesses in a wrong type
  ASoC: max98095: Fix enum ctl accesses in a wrong type
  ASoC: tlv320dac33: Fix enum ctl accesses in a wrong type
  ASoC: wl1273: Fix enum ctl accesses in a wrong type
  ASoC: wm8753: Fix enum ctl accesses in a wrong type
  ASoC: wm8904: Fix enum ctl accesses in a wrong type
  ASoC: wm8958: Fix enum ctl accesses in a wrong type
  ASoC: wm8983: Fix enum ctl accesses in a wrong type
  ASoC: wm8985: Fix enum ctl accesses in a wrong type
  ASoC: wm8994: Fix enum ctl accesses in a wrong type
  ASoC: wm8996: Fix enum ctl accesses in a wrong type
  ASoC: wm9081: Fix enum ctl accesses in a wrong type
  ASoC: wm_adsp: Fix enum ctl accesses in a wrong type

---
 include/trace/events/asoc.h |  8 +++
 sound/soc/codecs/ab8500-codec.c |  8 +++
 sound/soc/codecs/adau17x1.h |  6 ++---
 sound/soc/codecs/cs42l51.c  |  8 +++
 sound/soc/codecs/da732x.c   |  8 +++
 sound/soc/codecs/max98088.c |  2 +-
 sound/soc/codecs/max98095.c |  4 ++--
 sound/soc/codecs/tlv320dac33.c  |  9 ---
 sound/soc/codecs/wl1273.c   | 13 +-
 sound/soc/codecs/wm8753.c   |  6 ++---
 sound/soc/codecs/wm8904.c   |  4 ++--
 sound/soc/codecs/wm8958-dsp2.c  |  8 +++
 sound/soc/codecs/wm8983.c   | 14 +--
 sound/soc/codecs/wm8985.c   | 14 +--
 sound/soc/codecs/wm8994.c   |  4 ++--
 sound/soc/codecs/wm8996.c   |  2 +-
 sound/soc/codecs/wm9081.c   |  8 +++
 sound/soc/codecs/wm9713.c   |  2 +-
 sound/soc/codecs/wm_adsp.c  |  8 +++
 sound/soc/fsl/fsl_ssi.c | 42 -
 sound/soc/intel/boards/cht_bsw_rt5645.c |  6 -
 sound/soc/intel/boards/mfld_machine.c   | 16 ++---
 sound/soc/intel/skylake/skl-topology.c  |  2 +-
 sound/soc/omap/n810.c   | 18 +++---
 sound/soc/omap/rx51.c   | 18 +++---
 sound/soc/pxa/corgi.c   | 12 +-
 sound/soc/pxa/magician.c|  6 ++---
 sound/soc/pxa/poodle.c  | 12 +-
 sound/soc/pxa/spitz.c   | 12 +-
 sound/soc/pxa/tosa.c| 12 +-
 sound/soc/qcom/lpass-cpu.c  |  1 -
 sound/soc/samsung/i2s.c | 21 ++---
 sound/soc/soc-dapm.c|  8 +++
 33 files changed, 162 insertions(+), 160 deletions(-)

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue,  8 Mar 2016 21:37:01 +0800
Chunyu Hu  wrote:

> But after some tests, find it's not easy to setup tracer flag when
> its target is not the current tracer. Some check logic of function
> and function_graph trace seems not appropriate now, some WARN in
> ftrace.c are triggered.
> 
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:5106 
> ftrace_init_array_ops+0x4a/0x70()
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:413 
> ftrace_startup+0x229/0x240()
> kernel: WARNING: CPU: 2 PID: 30451 at kernel/trace/ftrace.c:460 
> return_to_handler+0x0/0x27()
> 
> Here just forbit it return an invalid code to user space with extra
> dmesg help info to avoid the complex WARN log.

This is not acceptable. The whole point of making the options visible
when the tracer is not active was to change the flags when the tracer
is not active.

I'll look deeper into this. Thanks.

-- Steve

Re: [PATCH 02/16] mtd: nand: sunxi: fix clk rate calculation

[Thomas Petazzoni]

Boris,

On Mon,  7 Mar 2016 17:18:19 +0100, Boris Brezillon wrote:
> Unlike what is specified in the Allwinner datasheets, the NAND clock rate
> is not equal to 2/T but 1/T. Fix the clock rate selection accordingly.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/nand/sunxi_nand.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 4d01e65..ab66d8d 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -1208,13 +1208,7 @@ static int sunxi_nand_chip_set_timings(struct 
> sunxi_nand_chip *chip,
>   /* Convert min_clk_period from picoseconds to nanoseconds */
>   min_clk_period = DIV_ROUND_UP(min_clk_period, 1000);
>  
> - /*
> -  * Convert min_clk_period into a clk frequency, then get the
> -  * appropriate rate for the NAND controller IP given this formula
> -  * (specified in the datasheet):
> -  * nand clk_rate = 2 * min_clk_rate
> -  */

When some HW works in a way that is *NOT* the one specified in the
datasheet, I think you should rather add *more* comments about this
aspect, rather than removing existing comments.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] net: dsa: Fix cleanup resources upon module removal

[Andrew Lunn]

On Tue, Mar 08, 2016 at 10:36:20AM +0100, Neil Armstrong wrote:
> The initial commit badly merged into the dsa_resume method instead
> of the dsa_remove_dst method.
> As consequence, the dst->master_netdev->dsa_ptr is not set to NULL on
> removal and re-bind of the dsa device fails with error -17.
> 
> Fixes: b0dc635d923c ("net: dsa: cleanup resources upon module removal ")
> Signed-off-by: Neil Armstrong 

Acked-by: Andrew Lunn 

Thanks

Andrew

Re: [PATCH 1/1] extcon: gpio: queue work only if debounce is NZ

[Guenter Roeck]

On Tue, Mar 08, 2016 at 05:15:53PM +0530, Venkat Reddy Talla wrote:
> Use queue_delayed_work only when debounce time is
> required to read gpio state properly, read the gpio
> state and set the extcon cable state in IRQ handler
> context if gpio settling time is not needed.
> 
> Signed-off-by: Venkat Reddy Talla 
> ---
>  drivers/extcon/extcon-gpio.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 279ff8f..1beb086 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -56,8 +56,12 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
>  {
>   struct gpio_extcon_data *data = dev_id;
>  
> - queue_delayed_work(system_power_efficient_wq, &data->work,
> + if (data->debounce_jiffies)
> + queue_delayed_work(system_power_efficient_wq, &data->work,
> data->debounce_jiffies);
> + else
> + gpio_extcon_work(&data->work.work);
> +

The interrupt is requested with devm_request_any_context_irq(), meaning
the handler may run in hard interrupt context. gpio_extcon_work() calls
gpiod_get_value_cansleep(), which may not be a good idea in hard interrupt
context.

Guenter

>   return IRQ_HANDLED;
>  }
>  
> -- 
> 2.1.4
> 
> 

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Christoph Lameter]

On Tue, 8 Mar 2016, Vineet Gupta wrote:

> This in turn happened because slab_unlock() doesn't serialize properly
> (doesn't use atomic clear) with a concurrent running
> slab_lock()->test_and_set_bit()

This is intentional because of the increased latency of atomic
instructions. Why would the unlock need to be atomic? This patch will
cause regressions.

Guess this is an architecture specific issue of modified
cachelines not becoming visible to other processors?

guter Tag

[ludvig]

guter Tag

Sie benötigen eine zuverlässige und kostengünstige Darlehen zu einem Zinssatz 
von 3%
Refinanzierung und Ihr Unternehmen / Investitionen verbessern?

UniCredit bietet eine zuverlässige und vertrauenswürdige Darlehen 
Dienstleistungen. wenn Sie überhaupt interessant uns, kontaktieren Sie uns 
bitte durch die folgenden Informationen für eine schnelle Bearbeitung Ihrer 
Kreditantrag ausfüllen:

Für weitere Informationen, füllen Sie bitte das Kreditantrag 

Name des Antragstellers:
Darlehensbetrag :
Länge des Darlehens:
Der Zweck des Darlehens:
Telefon:




E-mail: credituni.unicre...@gmail.com

Antonio Jefferson

Credit Manager

Re: [PATCH 3/3] mm, oom: protect !costly allocations some more

[Vlastimil Babka]

On 03/08/2016 03:48 PM, Michal Hocko wrote:
> On Tue 08-03-16 15:34:37, Vlastimil Babka wrote:
>>> --- a/include/linux/compaction.h
>>> +++ b/include/linux/compaction.h
>>> @@ -14,6 +14,11 @@ enum compact_result {
>>> /* compaction should continue to another pageblock */
>>> COMPACT_CONTINUE,
>>> /*
>>> +* whoever is calling compaction should retry because it was either
>>> +* not active or it tells us there is more work to be done.
>>> +*/
>>> +   COMPACT_SHOULD_RETRY = COMPACT_CONTINUE,
>>
>> Hmm, I'm not sure about this. AFAIK compact_zone() doesn't ever return
>> COMPACT_CONTINUE, and thus try_to_compact_pages() also doesn't. This
>> overloading of CONTINUE only applies to compaction_suitable(). But the
>> value that should_compact_retry() is testing comes only from
>> try_to_compact_pages(). So this is not wrong, but perhaps a bit misleading?
> 
> Well the idea was that I wanted to cover all the _possible_ cases where
> compaction might want to tell us "please try again even when the last
> round wasn't really successful". COMPACT_CONTINUE might not be returned
> right now but we can come up with that in the future. It sounds like a
> sensible feedback to me. But maybe there would be a better name for such
> a feedback. I confess this is a bit oom-rework centric name...

Hmm, I see. But it doesn't really tell use to please try again. That
interpretation is indeed oom-specific. What it's actually telling us is
either a) reclaim and then try again (COMPACT_SKIPPED), b) try again
just to overcome the deferred state (COMPACT_DEFERRED). COMPACT_CONTINUE
says "go ahead", but only from compaction_suitable().
So the attempt a generic name doesn't really work here I'm afraid :/

> Also I find it better to hide details behind a more generic name.
> 
> I am open to suggestions here, of course.
> 

[PATCH 1/6] perf tools: Fix hist_entry__filter() for hierarchy

[Namhyung Kim]

When hierarchy mode is enabled each output format is in a separate hpp
list.  So when applying filter it should check all formats in the list.
Currently it only checks a single ->fmt field which was not set properly.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 041f236379e0..2e803847046c 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1602,16 +1602,30 @@ int hist_entry__filter(struct hist_entry *he, int type, 
const void *arg)
 {
struct perf_hpp_fmt *fmt;
struct hpp_sort_entry *hse;
+   int ret = -1;
+   int r;
 
-   fmt = he->fmt;
-   if (fmt == NULL || !perf_hpp__is_sort_entry(fmt))
-   return -1;
+   perf_hpp_list__for_each_format(he->hpp_list, fmt) {
+   if (fmt == NULL || !perf_hpp__is_sort_entry(fmt))
+   continue;
 
-   hse = container_of(fmt, struct hpp_sort_entry, hpp);
-   if (hse->se->se_filter == NULL)
-   return -1;
+   hse = container_of(fmt, struct hpp_sort_entry, hpp);
+   if (hse->se->se_filter == NULL)
+   continue;
 
-   return hse->se->se_filter(he, type, arg);
+   /*
+* hist entry is filtered when all sort keys in the hpp list
+* is applied.  So if any sort key returns 0, it will *NOT*
+* filtered out.
+*/
+   r = hse->se->se_filter(he, type, arg);
+   if (r == 0)
+   return 0;
+   if (r > 0)
+   ret = 1;
+   }
+
+   return ret;
 }
 
 static int __sort_dimension__add_hpp_sort(struct sort_dimension *sd, int level)
-- 
2.7.2

[PATCH 3/6] perf tools: Fix command line filters in hierarchy mode

[Namhyung Kim]

When a command-line filter was applied in hierarchy mode, output was
broken especially when filtering on lower level.  The higher level
entries didn't show up so it's hard to see the result.

Also it needs to handle multi sort keys in a single level of hierarchy.

Before:

  $ perf report --hierarchy -s 'cpu,{dso,comm}' --comms swapper --stdio
  ...
  #Overhead  CPU / Shared Object+Command
  # ...  ...
  #
 13.79% [kernel.vmlinux]  swapper
  31.71% 000
 13.80% [kernel.vmlinux]  swapper
  0.43% [e1000e]  swapper
 11.89% [kernel.vmlinux]  swapper
  9.18% [kernel.vmlinux]  swapper

After:

  #Overhead  CPU / Shared Object+Command
  # ...  ...
  #
  33.09% 003
 13.79% [kernel.vmlinux]  swapper
  31.71% 000
 13.80% [kernel.vmlinux]  swapper
  0.43% [e1000e]  swapper
  21.90% 002
 11.89% [kernel.vmlinux]  swapper
  13.30% 001
  9.18% [kernel.vmlinux]  swapper

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/hist.c | 83 --
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 29da9e0d8db9..7c5eb11cabb6 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -1087,10 +1087,86 @@ int hist_entry__snprintf_alignment(struct hist_entry 
*he, struct perf_hpp *hpp,
  */
 
 static void hists__apply_filters(struct hists *hists, struct hist_entry *he);
+static void hists__remove_entry_filter(struct hists *hists, struct hist_entry 
*he,
+  enum hist_filter type);
+
+typedef bool (*fmt_chk_fn)(struct perf_hpp_fmt *fmt);
+
+static bool check_thread_entry(struct perf_hpp_fmt *fmt)
+{
+   return perf_hpp__is_thread_entry(fmt) || perf_hpp__is_comm_entry(fmt);
+}
+
+static void hist_entry__check_and_remove_filter(struct hist_entry *he,
+   enum hist_filter type,
+   fmt_chk_fn check)
+{
+   struct perf_hpp_fmt *fmt;
+   bool type_match = false;
+   struct hist_entry *parent = he->parent_he;
+
+   switch (type) {
+   case HIST_FILTER__THREAD:
+   if (symbol_conf.comm_list == NULL &&
+   symbol_conf.pid_list == NULL &&
+   symbol_conf.tid_list == NULL)
+   return;
+   break;
+   case HIST_FILTER__DSO:
+   if (symbol_conf.dso_list == NULL)
+   return;
+   break;
+   case HIST_FILTER__SYMBOL:
+   if (symbol_conf.sym_list == NULL)
+   return;
+   break;
+   case HIST_FILTER__PARENT:
+   case HIST_FILTER__GUEST:
+   case HIST_FILTER__HOST:
+   case HIST_FILTER__SOCKET:
+   default:
+   return;
+   }
+
+   /* if it's filtered by own fmt, it has to have filter bits */
+   perf_hpp_list__for_each_format(he->hpp_list, fmt) {
+   if (check(fmt)) {
+   type_match = true;
+   break;
+   }
+   }
+
+   if (type_match) {
+   if (!(he->filtered & (1 << type))) {
+   while (parent) {
+   parent->filtered &= ~(1 << type);
+   parent = parent->parent_he;
+   }
+   }
+   } else {
+   if (parent == NULL)
+   he->filtered |= (1 << type);
+   else
+   he->filtered |= (parent->filtered & (1 << type));
+   }
+}
+
+static void hist_entry__apply_hierarchy_filters(struct hist_entry *he)
+{
+   hist_entry__check_and_remove_filter(he, HIST_FILTER__THREAD,
+   check_thread_entry);
+
+   hist_entry__check_and_remove_filter(he, HIST_FILTER__DSO,
+   perf_hpp__is_dso_entry);
+
+   hist_entry__check_and_remove_filter(he, HIST_FILTER__SYMBOL,
+   perf_hpp__is_sym_entry);
+}
 
 static struct hist_entry *hierarchy_insert_entry(struct hists *hists,
 struct rb_root *root,
 struct hist_entry *he,
+struct hist_entry *parent_he,
 struct perf_hpp_list *hpp_list)
 {
struct rb_node **p = &root->rb_node;
@@ -1125,11 +1201,13 @@ static struct hist_entry *hierarchy_insert_entry(struct 
hists *hists,
if (new == NULL)
return NULL;
 
-   hists__apply_filters(hists, new);
hists->nr_entries++;
 
/* save related format list for ou

[PATCH 2/6] perf tools: Add more sort entry check functions

[Namhyung Kim]

Those function are to check given perf_hpp_fmt is filter-related sort
entries or not.  With hierarchy mode, it needs to check filters on the
hist entries with its own hpp format list.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/hist.h |  4 
 tools/perf/util/sort.c | 50 +++---
 2 files changed, 23 insertions(+), 31 deletions(-)

diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 2cb017f28f9e..6870a1bfd762 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -318,6 +318,10 @@ bool perf_hpp__defined_dynamic_entry(struct perf_hpp_fmt 
*fmt, struct hists *his
 bool perf_hpp__is_trace_entry(struct perf_hpp_fmt *fmt);
 bool perf_hpp__is_srcline_entry(struct perf_hpp_fmt *fmt);
 bool perf_hpp__is_srcfile_entry(struct perf_hpp_fmt *fmt);
+bool perf_hpp__is_thread_entry(struct perf_hpp_fmt *fmt);
+bool perf_hpp__is_comm_entry(struct perf_hpp_fmt *fmt);
+bool perf_hpp__is_dso_entry(struct perf_hpp_fmt *fmt);
+bool perf_hpp__is_sym_entry(struct perf_hpp_fmt *fmt);
 
 struct perf_hpp_fmt *perf_hpp_fmt__dup(struct perf_hpp_fmt *fmt);
 
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 2e803847046c..6bb831ddc6a7 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1488,38 +1488,26 @@ bool perf_hpp__is_sort_entry(struct perf_hpp_fmt 
*format)
return format->header == __sort__hpp_header;
 }
 
-bool perf_hpp__is_trace_entry(struct perf_hpp_fmt *fmt)
-{
-   struct hpp_sort_entry *hse;
+#define MK_SORT_ENTRY_CHK(key) \
+bool perf_hpp__is_ ## key ## _entry(struct perf_hpp_fmt *fmt)  \
+{  \
+   struct hpp_sort_entry *hse; \
+   \
+   if (!perf_hpp__is_sort_entry(fmt))  \
+   return false;   \
+   \
+   hse = container_of(fmt, struct hpp_sort_entry, hpp);\
+   return hse->se == &sort_ ## key ;   \
+}
+
+MK_SORT_ENTRY_CHK(trace)
+MK_SORT_ENTRY_CHK(srcline)
+MK_SORT_ENTRY_CHK(srcfile)
+MK_SORT_ENTRY_CHK(thread)
+MK_SORT_ENTRY_CHK(comm)
+MK_SORT_ENTRY_CHK(dso)
+MK_SORT_ENTRY_CHK(sym)
 
-   if (!perf_hpp__is_sort_entry(fmt))
-   return false;
-
-   hse = container_of(fmt, struct hpp_sort_entry, hpp);
-   return hse->se == &sort_trace;
-}
-
-bool perf_hpp__is_srcline_entry(struct perf_hpp_fmt *fmt)
-{
-   struct hpp_sort_entry *hse;
-
-   if (!perf_hpp__is_sort_entry(fmt))
-   return false;
-
-   hse = container_of(fmt, struct hpp_sort_entry, hpp);
-   return hse->se == &sort_srcline;
-}
-
-bool perf_hpp__is_srcfile_entry(struct perf_hpp_fmt *fmt)
-{
-   struct hpp_sort_entry *hse;
-
-   if (!perf_hpp__is_sort_entry(fmt))
-   return false;
-
-   hse = container_of(fmt, struct hpp_sort_entry, hpp);
-   return hse->se == &sort_srcfile;
-}
 
 static bool __sort__hpp_equal(struct perf_hpp_fmt *a, struct perf_hpp_fmt *b)
 {
-- 
2.7.2

[PATCH 4/6] perf tools: Remove hist_entry->fmt field

[Namhyung Kim]

It's not used anymore and the output format is accessed by the hpp_list
pointer instead when hierarchy is enabled.  Let's get rid of it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/sort.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index ea1f722cffea..151afc1b6c2f 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -129,7 +129,6 @@ struct hist_entry {
void*raw_data;
u32 raw_size;
void*trace_output;
-   struct perf_hpp_fmt *fmt;
struct perf_hpp_list*hpp_list;
struct hist_entry   *parent_he;
union {
-- 
2.7.2

[PATCH 5/6] perf hists browser: Cleanup hist_browser__fprintf_hierarchy_entry()

[Namhyung Kim]

The hist_browser__fprintf_hierarchy_entry() if to dump current output
into a file so it needs to be sync-ed with the corresponding function
hist_browser__show_hierarchy_entry().  So use hists->nr_hpp_node to
indent width and use first fmt_node to print overhead columns instead of
checking whether it's a sort entry (or dynamic entry).

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/browsers/hists.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index e0e217ec856b..aed9c8f011f7 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1928,8 +1928,7 @@ static int hist_browser__fprintf_entry(struct 
hist_browser *browser,
 
 static int hist_browser__fprintf_hierarchy_entry(struct hist_browser *browser,
 struct hist_entry *he,
-FILE *fp, int level,
-int nr_sort_keys)
+FILE *fp, int level)
 {
char s[8192];
int printed = 0;
@@ -1939,23 +1938,20 @@ static int hist_browser__fprintf_hierarchy_entry(struct 
hist_browser *browser,
.size = sizeof(s),
};
struct perf_hpp_fmt *fmt;
+   struct perf_hpp_list_node *fmt_node;
bool first = true;
int ret;
-   int hierarchy_indent = nr_sort_keys * HIERARCHY_INDENT;
+   int hierarchy_indent = (he->hists->nr_hpp_node - 2) * HIERARCHY_INDENT;
 
printed = fprintf(fp, "%*s", level * HIERARCHY_INDENT, "");
 
folded_sign = hist_entry__folded(he);
printed += fprintf(fp, "%c", folded_sign);
 
-   hists__for_each_format(he->hists, fmt) {
-   if (perf_hpp__should_skip(fmt, he->hists))
-   continue;
-
-   if (perf_hpp__is_sort_entry(fmt) ||
-   perf_hpp__is_dynamic_entry(fmt))
-   break;
-
+   /* the first hpp_list_node is for overhead columns */
+   fmt_node = list_first_entry(&he->hists->hpp_formats,
+   struct perf_hpp_list_node, list);
+   perf_hpp_list__for_each_format(&fmt_node->hpp, fmt) {
if (!first) {
ret = scnprintf(hpp.buf, hpp.size, "  ");
advance_hpp(&hpp, ret);
@@ -1992,7 +1988,6 @@ static int hist_browser__fprintf(struct hist_browser 
*browser, FILE *fp)
struct rb_node *nd = hists__filter_entries(rb_first(browser->b.entries),
   browser->min_pcnt);
int printed = 0;
-   int nr_sort = browser->hists->nr_sort_keys;
 
while (nd) {
struct hist_entry *h = rb_entry(nd, struct hist_entry, rb_node);
@@ -2000,8 +1995,7 @@ static int hist_browser__fprintf(struct hist_browser 
*browser, FILE *fp)
if (symbol_conf.report_hierarchy) {
printed += 
hist_browser__fprintf_hierarchy_entry(browser,
 h, fp,
-
h->depth,
-
nr_sort);
+
h->depth);
} else {
printed += hist_browser__fprintf_entry(browser, h, fp);
}
-- 
2.7.2

[PATCH 6/6] perf tools: Remove nr_sort_keys field

[Namhyung Kim]

The nr_sort_keys field is to carry the number of sort entries in a
hpp_list or hists to determine the depth of indentation of a hist entry.
As it's only used in hierarchy mode and now we have used nr_hpp_node for
this reason, there's no need to keep it anymore.  Let's get rid of it.

Signed-off-by: Namhyung Kim 
---
 tools/perf/ui/hist.c   |  3 ---
 tools/perf/util/hist.h |  2 --
 tools/perf/util/sort.c | 26 --
 3 files changed, 31 deletions(-)

diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index f03c4f70438f..3baeaa6e71b5 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -515,9 +515,6 @@ void perf_hpp_list__column_register(struct perf_hpp_list 
*list,
 void perf_hpp_list__register_sort_field(struct perf_hpp_list *list,
struct perf_hpp_fmt *format)
 {
-   if (perf_hpp__is_sort_entry(format) || 
perf_hpp__is_dynamic_entry(format))
-   list->nr_sort_keys++;
-
list_add_tail(&format->sort_list, &list->sorts);
 }
 
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 6870a1bfd762..ead18c82294f 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -79,7 +79,6 @@ struct hists {
int socket_filter;
struct perf_hpp_list*hpp_list;
struct list_headhpp_formats;
-   int nr_sort_keys;
int nr_hpp_node;
 };
 
@@ -241,7 +240,6 @@ struct perf_hpp_fmt {
 struct perf_hpp_list {
struct list_head fields;
struct list_head sorts;
-   int nr_sort_keys;
 };
 
 extern struct perf_hpp_list perf_hpp_list;
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 6bb831ddc6a7..be5fcb25496a 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -2695,29 +2695,6 @@ out:
return ret;
 }
 
-static void evlist__set_hists_nr_sort_keys(struct perf_evlist *evlist)
-{
-   struct perf_evsel *evsel;
-
-   evlist__for_each(evlist, evsel) {
-   struct perf_hpp_fmt *fmt;
-   struct hists *hists = evsel__hists(evsel);
-
-   hists->nr_sort_keys = perf_hpp_list.nr_sort_keys;
-
-   /*
-* If dynamic entries were used, it might add multiple
-* entries to each evsel for a single field name.  Set
-* actual number of sort keys for each hists.
-*/
-   perf_hpp_list__for_each_sort_list(&perf_hpp_list, fmt) {
-   if (perf_hpp__is_dynamic_entry(fmt) &&
-   !perf_hpp__defined_dynamic_entry(fmt, hists))
-   hists->nr_sort_keys--;
-   }
-   }
-}
-
 int setup_sorting(struct perf_evlist *evlist)
 {
int err;
@@ -2732,9 +2709,6 @@ int setup_sorting(struct perf_evlist *evlist)
return err;
}
 
-   if (evlist != NULL)
-   evlist__set_hists_nr_sort_keys(evlist);
-
reset_dimensions();
 
/*
-- 
2.7.2

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

[Mimi Zohar]

On Tue, 2016-03-08 at 14:43 +, David Howells wrote:
> The problem boils down to a difficulty in concocting a name that describes a
> complex situation that may change depending on the configuration.  I can make
> it "restrict_link_by_any_system_trusted" if you'd prefer.
> 
> That's why I want "system trusted keyrings" to refer to the builtin and the
> secondary - *and* an extra UEFI keyring if we grow one of those.  It's a
> collection of related keyrings.

Sigh, this is the same discussion we've had for years.  The UEFI keys
should not be trusted to validate the certificates being added to the
IMA keyring.  Neither should the keys on the secondary keyring, unless
specifically IMA Kconfig enabled, be used to validate the certificates
being added to the IMA keyring.  Just because the UEFI keys or the
secondary keyring is enabled, doesn't mean that certificates signed by a
key on either of those keyrings, should be added to the IMA keyring.

The machine/system owner should control which keys can be used to verify
certificates being added to the IMA keyring.

Mimi

[PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

[Yi Zhang]

the driver_data may be used for sanity check, it fails the
probe() if driver_data is NULL after it is re-triggered.
for example, soc_probe() in sound/soc/soc-core.c

Signed-off-by: Yi Zhang 
---
 drivers/base/dd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index c4da2df..30c53d3 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -402,7 +402,8 @@ pinctrl_bind_failed:
devres_release_all(dev);
driver_sysfs_remove(dev);
dev->driver = NULL;
-   dev_set_drvdata(dev, NULL);
+   if (ret != -EPROBE_DEFER)
+   dev_set_drvdata(dev, NULL);
if (dev->pm_domain && dev->pm_domain->dismiss)
dev->pm_domain->dismiss(dev);
pm_runtime_reinit(dev);
-- 
1.9.1

Re: [PATCH] mm, oom: protect !costly allocations some more (was: Re: [PATCH 0/3] OOM detection rework v4)

[Joonsoo Kim]

2016-03-08 1:08 GMT+09:00 Michal Hocko :
> On Mon 29-02-16 22:02:13, Michal Hocko wrote:
>> Andrew,
>> could you queue this one as well, please? This is more a band aid than a
>> real solution which I will be working on as soon as I am able to
>> reproduce the issue but the patch should help to some degree at least.
>
> Joonsoo wasn't very happy about this approach so let me try a different
> way. What do you think about the following? Hugh, Sergey does it help

I'm still not happy. Just ensuring one compaction run doesn't mean our
best. What's your purpose of OOM rework? From my understanding,
you'd like to trigger OOM kill deterministic and *not prematurely*.
This makes sense.

But, what you did in case of high order allocation is completely different
with original purpose. It may be deterministic but *completely premature*.
There is no way to prevent premature OOM kill. So, I want to ask one more
time. Why OOM kill is better than retry reclaiming when there is reclaimable
page? Deterministic is for what? It ensures something more?

Please see Hugh's latest vmstat. There are plenty of anon pages when
OOM kill happens and it may have enough swap space. Even if
compaction runs and fails, why do we need to kill something
in this case? OOM kill should be a last resort.

Please see Hugh's previous report and OOM dump.

[  796.540791] Mem-Info:
[  796.557378] active_anon:150198 inactive_anon:46022 isolated_anon:32
 active_file:5107 inactive_file:1664 isolated_file:57
 unevictable:3067 dirty:4 writeback:75 unstable:0
 slab_reclaimable:13907 slab_unreclaimable:23236
 mapped:8889 shmem:3171 pagetables:2176 bounce:0
 free:1637 free_pcp:54 free_cma:0
[  796.630465] Node 0 DMA32 free:13904kB min:3940kB low:4944kB
high:5948kB active_anon:588776kB inactive_anon:188816kB
active_file:20432kB inactive_file:6928kB unevictable:12268kB
isolated(anon):128kB isolated(file):8kB present:1046128kB
managed:1004892kB mlocked:12268kB dirty:16kB writeback:1400kB
mapped:35556kB shmem:12684kB slab_reclaimable:55628kB
slab_unreclaimable:92944kB kernel_stack:4448kB pagetables:8604kB
unstable:0kB bounce:0kB free_pcp:296kB local_pcp:164kB free_cma:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[  796.685815] lowmem_reserve[]: 0 0 0
[  796.687390] Node 0 DMA32: 969*4kB (UE) 184*8kB (UME) 167*16kB (UM)
19*32kB (UM) 3*64kB (UM) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB
0*4096kB = 8820kB
[  796.729696] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB

See [  796.557378] and [  796.630465].
In this 100 ms time interval, freepage increase a lot and
there are enough high order pages. OOM kill happen later
so freepage would come from reclaim. This shows
that your previous implementation which uses static retry number
causes premature OOM.

This attempt using compaction result looks not different to me.
It would also cause premature OOM kill.

I don't insist endless retry. I just want a more scientific criteria
that prevents
premature OOM kill. I'm really tire to say same thing again and again.
Am I missing something? This is the situation that I totally misunderstand
something? Please let me know.

Note: your current implementation doesn't consider which zone is compacted.
If DMA zone which easily fail to make high order page is compacted,
your implementation will not do retry. It also looks not our best.

Thanks.

> for your load? I have tested it with the Hugh's load and there was no
> major difference from the previous testing so at least nothing has blown
> up as I am not able to reproduce the issue here.
>
> Other changes in the compaction are still needed but I would like to not
> depend on them right now.
> ---
> From 0974f127e8eb7fe53e65f3a8b398db57effe9755 Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Mon, 7 Mar 2016 15:30:37 +0100
> Subject: [PATCH] mm, oom: protect !costly allocations some more
>
> should_reclaim_retry will give up retries for higher order allocations
> if none of the eligible zones has any requested or higher order pages
> available even if we pass the watermak check for order-0. This is done
> because there is no guarantee that the reclaimable and currently free
> pages will form the required order.
>
> This can, however, lead to situations were the high-order request (e.g.
> order-2 required for the stack allocation during fork) will trigger
> OOM too early - e.g. after the first reclaim/compaction round. Such a
> system would have to be highly fragmented and there is no guarantee
> further reclaim/compaction attempts would help but at least make sure
> that the compaction was active before we go OOM and keep retrying even
> if should_reclaim_retry tells us to oom if the last compaction round
> was either inactive (deferred, skipped or bailed out early due to
> contention) or it told us to continue.
>
> Additionally define COMPACT_NONE which reflects cases where the
> compaction is completely disabled.
>
> Signed-off-by: Michal Hocko 
> ---
>  include/linux/compa

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue, 8 Mar 2016 09:54:43 -0500
Steven Rostedt  wrote:


> > Here just forbit it return an invalid code to user space with extra
> > dmesg help info to avoid the complex WARN log.  
> 
> This is not acceptable. The whole point of making the options visible
> when the tracer is not active was to change the flags when the tracer
> is not active.
> 
> I'll look deeper into this. Thanks.

I made the modifications to your patch. Can you please test this. I'll
start running my own tests on it:

-- Steve

From: Chunyu Hu 

tracing: Make tracer_flags use the right set_flag callback

When I was updating the ftrace_stress test of ltp. I encountered
a strange phenomemon, excute following steps:

echo nop > /sys/kernel/debug/tracing/current_tracer
echo 0 > /sys/kernel/debug/tracing/options/funcgraph-cpu
bash: echo: write error: Invalid argument

check dmesg:
[ 1024.903855] nop_test_refuse flag set to 0: we refuse.Now cat trace_options 
to see the result

The reason is that the trace option test will randomly setup trace
option under tracing/options no matter what the current_tracer is.
but the set_tracer_option is always using the set_flag callback
from the current_tracer. This patch adds a pointer to tracer_flags
and make it point to the tracer it belongs to. When the option is
setup, the set_flag of the right tracer will be used no matter
what the the current_tracer is.

But after some tests, find it's not easy to setup tracer flag when
its target is not the current tracer. Some check logic of function
and function_graph trace seems not appropriate now, some WARN in
ftrace.c are triggered.

kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:5106 
ftrace_init_array_ops+0x4a/0x70()
kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:413 
ftrace_startup+0x229/0x240()
kernel: WARNING: CPU: 2 PID: 30451 at kernel/trace/ftrace.c:460 
return_to_handler+0x0/0x27()

Here just forbit it return an invalid code to user space with extra
dmesg help info to avoid the complex WARN log.

And the old dummy_tracer_flags is used for all the tracers which
doesn't have a tracer_flags, having issue to use it to save the
pointer of a tracer. So remove it and use dynamic dummy tracer_flags
for tracers needing a dummy tracer_flags, as a result, there are no
tracers sharing tracer_flags, so remove the check code.

And save the current tracer to trace_option_dentry seems not good as
it may waste mem space when mount the debug/trace fs more than one time.

Signed-off-by: Chunyu Hu 
---
 kernel/trace/trace.c   |   21 -
 kernel/trace/trace.h   |1 +
 kernel/trace/trace_functions.c |6 ++
 3 files changed, 19 insertions(+), 9 deletions(-)

Index: linux-trace.git/kernel/trace/trace.c
===
--- linux-trace.git.orig/kernel/trace/trace.c   2016-03-08 10:07:51.180345420 
-0500
+++ linux-trace.git/kernel/trace/trace.c2016-03-08 10:07:54.365296167 
-0500
@@ -74,11 +74,6 @@ static struct tracer_opt dummy_tracer_op
{ }
 };
 
-static struct tracer_flags dummy_tracer_flags = {
-   .val = 0,
-   .opts = dummy_tracer_opt
-};
-
 static int
 dummy_set_flag(struct trace_array *tr, u32 old_flags, u32 bit, int set)
 {
@@ -1258,12 +1253,20 @@ int __init register_tracer(struct tracer
 
if (!type->set_flag)
type->set_flag = &dummy_set_flag;
-   if (!type->flags)
-   type->flags = &dummy_tracer_flags;
-   else
+   if (!type->flags) {
+   /*allocate a dummy tracer_flags*/
+   type->flags = kmalloc(sizeof(*type->flags), GFP_KERNEL);
+   if (!type->flags)
+   return -ENOMEM;
+   type->flags->val = 0;
+   type->flags->opts = dummy_tracer_opt;
+   } else
if (!type->flags->opts)
type->flags->opts = dummy_tracer_opt;
 
+   /* store the tracer for __set_tracer_option */
+   type->flags->trace = type;
+
ret = run_tracer_selftest(type);
if (ret < 0)
goto out;
@@ -3505,7 +3508,7 @@ static int __set_tracer_option(struct tr
   struct tracer_flags *tracer_flags,
   struct tracer_opt *opts, int neg)
 {
-   struct tracer *trace = tr->current_trace;
+   struct tracer *trace = tracer_flags->trace;
int ret;
 
ret = trace->set_flag(tr, tracer_flags->val, opts->bit, !neg);
Index: linux-trace.git/kernel/trace/trace.h
===
--- linux-trace.git.orig/kernel/trace/trace.h   2016-03-08 10:07:51.180345420 
-0500
+++ linux-trace.git/kernel/trace/trace.h2016-03-08 10:07:54.366296151 
-0500
@@ -345,6 +345,7 @@ struct tracer_opt {
 struct tracer_flags {
u32 val;
struct tracer_opt   *opts;
+   struct tracer   *trace;
 };
 
 /* Makes more easy to def

Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

[Toshi Kani]

On Mon, 2016-03-07 at 22:16 -0500, Paul Gortmaker wrote:
> [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> disabled"] On 07/03/2016 (Mon 17:56) Toshi Kani wrote:
> 
> [..]
> 
> 
> > > > It may have seemed working before, but you did not have WC
> > > > configured
> > > > to PAT without calling pat_init().  There was not a proper check in
> > > > place to detect this error before.  Can you please check your code
> > > > to
> > > > see what caused this skip of pat_init()?  If you have a git tree, I
> > > > can
> > > > take a look as well. 
> > > 
> > > You already have git copies of what I'm running, since it is vanilla
> > > mainline commits.  No code changes at this end whatsoever.  I did the
> > > bisect on vanilla mainline.  All I took from yocto was their
> > > ".config"
> > > 
> > > To recap, v4.1-rc5-21-g9dac62909451 works,  v4.1-rc5-22-g9cd25aac1f44
> > > fails, and v4.5-rc6 also fails.  If pat_init() isn't called then this
> > > is a bug in current mainline.  I'll have a look later myself and see
> > > if I can trace out how we expect to get to pat_init() and how that
> > > might be skipped inadvertently unless someone beats me to it.
> > 
> > Oh, I see.  Can you send me the ".config" file?
> 
> I packaged the .config file for every bisect point in the original
> reproducer tarball.  Let me know if you can't find them.  It should
> look like this:
> 
> paul@dell760-paul:~/qemu-fail$ ls -al 00-configs/
> total 92
> drwxrwxr-x 23 paul paul 4096 Mar  3 10:59 .
> drwxrwxr-x  5 paul paul 4096 Mar  3 11:01 ..
> -rw-rw-r--  1 paul paul0 Mar  3 10:59 00-all-dot-configs-are-in-here
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1281-g43224b96af31
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-1625-g44d21c3f3a2e
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-3251-g4e241557fc1c
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-6547-g4570a37169d4
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-912-ge75c73ad6447
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc4-85-gd4688bdc6335
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-21-g9dac62909451
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-22-g9cd25aac1f44
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-23-g7202fdb1b329
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-27-gd838270e2516
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc5-35-g7ea402d01cb6
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-256-g9dda1658a9bd
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.1-rc6-296-g7ef3d7d58d9d
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.2-rc1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.3
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.4.1-348-g0194c7658611
> drwxrwxr-x  2 paul paul 4096 Mar  3 10:59 v4.5-rc6
> paul@dell760-paul:~/qemu-fail$ 
> 
> Please check if they are present in the reproducer you downloaded.
> Maybe somehow I uploaded a version without the config files.

Yes, I have these directories, but I do not see anything under them...  Now
that I do not think there is anything unique in your .config file, but it'd
be still good to check.  Please send me .config file for v4.5-rc6 (if you
do not have it now, .config for other ver is OK as well).

$ ls -Rl
.:
total 84
-rw-rw-r--. 1 toshi toshi0 Mar  3 08:59 00-all-dot-configs-are-in-here
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1281-g43224b96af31
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-1625-g44d21c3f3a2e
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-3251-g4e241557fc1c
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-6547-g4570a37169d4
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-912-ge75c73ad6447
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc4-85-gd4688bdc6335
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-21-g9dac62909451
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-22-g9cd25aac1f44
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-23-g7202fdb1b329
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-27-gd838270e2516
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc5-35-g7ea402d01cb6
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-256-g9dda1658a9bd
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.1-rc6-296-g7ef3d7d58d9d
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.2-rc1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.3
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.4.1-348-g0194c7658611
drwxrwxr-x. 2 toshi toshi 4096 Mar  3 08:59 v4.5-rc6

./v4.1:
total 0

./v4.1-1281-g43224b96af31:
total 0

./v4.1-1625-g44d21c3f3a2e:
total 0

./v4.1-3251-g4e241557fc1c:
total 0
./v4.1-6547-g4570a37169d4:
total 0

./v4.1-912-

Re: [PATCH 02/16] mtd: nand: sunxi: fix clk rate calculation

[Boris Brezillon]

On Tue, 8 Mar 2016 15:58:03 +0100
Thomas Petazzoni  wrote:

> Boris,
> 
> On Mon,  7 Mar 2016 17:18:19 +0100, Boris Brezillon wrote:
> > Unlike what is specified in the Allwinner datasheets, the NAND clock rate
> > is not equal to 2/T but 1/T. Fix the clock rate selection accordingly.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/nand/sunxi_nand.c | 8 +---
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> > index 4d01e65..ab66d8d 100644
> > --- a/drivers/mtd/nand/sunxi_nand.c
> > +++ b/drivers/mtd/nand/sunxi_nand.c
> > @@ -1208,13 +1208,7 @@ static int sunxi_nand_chip_set_timings(struct 
> > sunxi_nand_chip *chip,
> > /* Convert min_clk_period from picoseconds to nanoseconds */
> > min_clk_period = DIV_ROUND_UP(min_clk_period, 1000);
> >  
> > -   /*
> > -* Convert min_clk_period into a clk frequency, then get the
> > -* appropriate rate for the NAND controller IP given this formula
> > -* (specified in the datasheet):
> > -* nand clk_rate = 2 * min_clk_rate
> > -*/
> 
> When some HW works in a way that is *NOT* the one specified in the
> datasheet, I think you should rather add *more* comments about this
> aspect, rather than removing existing comments.

Fair enough (but you know how much I like documenting my code ;)). I'll
add a comment explaining why it differs from the datasheet
description :P.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Chunyu Hu]

- Original Message -
> From: "Steven Rostedt" 
> To: "Chunyu Hu" 
> Cc: li...@redhat.com, linux-kernel@vger.kernel.org
> Sent: Tuesday, March 8, 2016 10:33:17 PM
> Subject: Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag 
> callback
> 
> On Tue,  8 Mar 2016 21:37:01 +0800
> Chunyu Hu  wrote:
> 
> > @@ -6373,7 +6384,6 @@ create_trace_option_files(struct trace_array *tr,
> > struct tracer *tracer)
> > struct tracer_flags *flags;
> > struct tracer_opt *opts;
> > int cnt;
> > -   int i;
> 
> I'm guessing this was a mistake.

Thanks for the quick review! This is an mistake, the change below should be 
after it. From my
limited knowledge and observation, seems there is no tracer sharing the 
tracer_flag except the
dummy_tracer flag. As in the patch that flag is not shared any more, so i also 
removed these check
in the previous email.


@@ -6390,15 +6400,6 @@ create_trace_option_files(struct trace_array *tr, struct 
tracer *tracer)
if (!trace_ok_for_array(tracer, tr))
return;
 
-   for (i = 0; i < tr->nr_topts; i++) {
-   /*
-* Check if these flags have already been added.
-* Some tracers share flags.
-*/
-   if (tr->topts[i].tracer->flags == tracer->flags)
-   return;
-   }
-


> -- Steve
> 
> >  
> > if (!tracer)
> > return;
> 

-- 
Regards,
Chunyu Hu

Re: [PATCH v2 0/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[David Rivshin (Allworx)]

On Tue, 08 Mar 2016 10:43:35 +0100
Jacek Anaszewski  wrote:

> Hi David,
> 
> Thanks for posting the final version. Very nice driver.
> Applied whole series, after dropping leds-sn3218 with its
> DT bindings. Stefan, thanks for testing the driver on the
> Si-En hardware.

Thanks Jacek. And thanks also for your patience with all my 
questions along the way.

> 
> Thanks,
> Jacek Anaszewski
> 
> On 03/08/2016 01:57 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin 
> >
> > This series adds support for the ISSI IS31FL32xx family of I2C LED
> > controllers. Since the IS31FL3218/3216 are actually the same devices as
> > the SN3218/3216, adds their compatible strings as aliases.
> >
> > As requested, this series is based on the current linux-leds/for-next, minus
> > patch 2 and 3 of the standalone sn3218 driver. As such, it will not directly
> > apply to the current linux-next without minor merges in the leds Kconfig
> > and Makefile. This will apply cleanly to v4.5-rc7, albeit with a compiler
> > warning in patch 3 (which is fixed elsewhere in linux-next).
> >
> > Changes from v1 [1]:
> >   - swapped node name and label in binding example
> >   - removed line stating filename from file header comment of is31fl32xx.c
> >   - dropped #includes for err.h and of_platform.h
> >   - added #includes for device.h, of.h, and of_device.h
> >   - patch 4 no longer removes leds-sn3218, as that will be done separately
> >   - patch 4 commit log no longer references leds-sn3218 driver
> >   - added Rob's acks for patches 1, 2, and 4
> >   - added Tested-By from Stefan (for SN3218)
> >
> > Changes from RFC [2]:
> >   - Removed max-brightness DT property.
> >   - Added #address-cells and #size-cells properties to the example DT.
> >   - Refer to these devices as "LED controllers" in Kconfig.
> >   - Removed redundant last sentence from Kconfig entry
> >   - Removed unnecessary debug code.
> >   - Do not set led_classdev.brightness to 0 explicitly, as it is
> > already initialized to 0 by devm_kzalloc().
> >   - Used of_property_read_string() instead of of_get_property().
> >   - Fail immediately on DT parsing error in a child node, rather than
> > continuing on with the non-faulty ones.
> >   - Added additional comments for some things that might be non-obvious.
> >   - Added constants for the location of the SSD bit in the SHUTDOWN
> > register, and the 3216's CONFIG register.
> >   - Added special sw_shutdown_func for the 3216 device, as that bit
> > is in a different register, at a different position, and has reverse
> > polarity compared to all the other devices.
> >   - Refactored is31fl32xx_init_regs() to separate out some logic into
> > is31fl32xx_reset_regs() and is31fl32xx_software_shutdown().
> >   - Added 4th patch to replace the now-redundant leds-sn3218.
> >
> > [1] https://lkml.org/lkml/2016/3/2/1004
> > [2] http://www.spinics.net/lists/linux-leds/msg05564.html
> >
> > David Rivshin (4):
> >DT: Add vendor prefix for Integrated Silicon Solutions Inc.
> >DT: leds: Add binding for the ISSI IS31FL32xx family of LED
> >  controllers
> >leds: Add driver for the ISSI IS31FL32xx family of LED controllers
> >leds: Add SN3218 and SN3216 support to the IS31FL32XX driver
> >
> >   .../devicetree/bindings/leds/leds-is31fl32xx.txt   |  52 +++
> >   .../devicetree/bindings/vendor-prefixes.txt|   1 +
> >   drivers/leds/Kconfig   |   8 +
> >   drivers/leds/Makefile  |   1 +
> >   drivers/leds/leds-is31fl32xx.c | 508 
> > +
> >   5 files changed, 570 insertions(+)
> >   create mode 100644 
> > Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> >   create mode 100644 drivers/leds/leds-is31fl32xx.c
> >  

Re: [PATCH v19 00/10] Compile-time stack metadata validation

[Ingo Molnar]

* Josh Poimboeuf  wrote:

> On Tue, Mar 08, 2016 at 02:44:57PM +0100, Ingo Molnar wrote:
> > 
> > * Josh Poimboeuf  wrote:
> > 
> > > On Tue, Mar 08, 2016 at 11:37:16AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Josh Poimboeuf  wrote:
> > > > 
> > > > > This is v19 of the compile-time stack metadata validation patch set.
> > > > > 
> > > > > It's based on tip:core/objtool.
> > > > 
> > > > So I've upgraded my main build box to Fedora 23, to:
> > > > 
> > > >   gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
> > > >   GNU assembler version 2.25 (x86_64-redhat-linux) using BFD version 
> > > > version 2.25-15.fc23
> > > >   GNU ld version 2.25-15.fc23
> > > > 
> > > > and I'm now getting a bunch of these warnings:
> > > > 
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2ff: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x30b: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x317: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x323: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x32f: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x33b: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x348: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x355: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x362: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x36f: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x37c: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x389: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x396: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2e7: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2f3: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x2ff: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x30b: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x317: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x323: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x32f: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x33b: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x348: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x355: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x362: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x36f: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x37c: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x389: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate_mapping()+0x396: frame pointer state mismatch
> > > > drivers/net/wireless/realtek/rtlwifi/base.o: warning: objtool: 
> > > > rtlwifi_rate

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Ferreri Tonello]

Hi,

On 08/03/16 14:20, Felipe Balbi wrote:
> 
> Hi,
> 
> Krzysztof Opasiak  writes:
>> [ text/plain ]
>>
>>
>> On 03/08/2016 02:54 PM, Felipe Ferreri Tonello wrote:
>>  (...)
>>

> sort of preset library of configfs-based gadget drivers, we still need
> these modules.

 there is already a library called libusbg.
>>>
>>> By preset library I meant scripts or little programs that implement the
>>> legacy drivers we have.
>>>
>>
>> libusbgx implements an idea of gadget schemes[1]. That's simple
>> configuration files using libconfig syntax. I don't see any problems to
>> use it to create legacy gadget equivalents. Then you could simply load
>> it using usbg_import_gadget() in C code or gt[2] load from shell.
> 
> cool, bmAttributes and bMaxPower are already there. Nice.
> 

Yes! It is pretty awesome.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys

Re: [GIT PULL rcu/next] RCU commits for 4.6

[Paul E. McKenney]

On Tue, Mar 08, 2016 at 09:53:42AM +0100, Ingo Molnar wrote:
> 
> * Paul E. McKenney  wrote:
> 
> > Hello, Ingo,
> > 
> > Note that this series conflicts with some commits in Thomas Gleixner's
> > hotplug series and in Daniel Wagner's swait series, both of which are in
> > -tip.  I have suggested conflict-resolution commits for Daniel's commits
> > (25f0d48a4299 "Merge commit 'abedf8e2419fb873d919dd74de2e84b510259339'
> > into wagi.2016.03.01a") and for Thomas's commits (dc96aeda643f "Merge
> > commit '27d50c7eeb0f' into wagi.2016.03.01a"), which you might find
> > useful.  These merge commits pass rcutorture testing, 0day robot testing,
> > and -next testing.
> > 
> > The changes in this series include:
> > 
> > 1.  Documentation updates, including RCU data structure design-level
> > documentation.
> > 
> > https://lkml.org/lkml/2016/2/24/26
> > 
> > 2.  Miscellaneous fixes.
> > 
> > https://lkml.org/lkml/2016/2/24/34
> > 
> > 3.  Torture-test updates.
> > 
> > https://lkml.org/lkml/2016/2/24/50
> > 
> > As noted earlier, all of these changes have been subjected to 0day Test
> > robot and -next testing, and are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> > for-mingo
> > 
> > for you to fetch changes up to 2863b4e3dd92a9d697dd66b219710e478e0a4531:
> > 
> >   Merge branches 'doc.2015.02.23a', 'fixes.2015.02.23a' and 
> > 'torture.2015.02.23a' into HEAD (2016-02-23 20:05:19 -0800)
> > 
> > 
> > Boqun Feng (3):
> >   sparse: Add __private to privatize members of structs
> >   RCU: Privatize rcu_node::lock
> >   irq: Privatize irq_common_data::state_use_accessors
> > 
> > Chen Gang (1):
> >   rcu: Remove useless rcu_data_p when !PREEMPT_RCU
> > 
> > Paul E. McKenney (25):
> >   rcutorture: Add checks for rcutorture writer starvation
> >   rcutorture: Don't keep empty console.log.diags files
> >   rcutorture: Check for self-detected stalls
> >   documentation:  Add real-time requirements from CPU-bound workloads
> >   documentation: Fix control dependency and identical stores
> >   documentation: Fix memory-barriers.txt section references
> >   documentation: Add synchronize_rcu_mult() to the requirements
> >   documentation: Remove obsolete reference to RCU-protected indexes
> >   documentation: Subsequent writes ordered by rcu_dereference()
> >   documentation: Distinguish between local and global transitivity
> >   documentation:  Add alternative release-acquire outcome
> >   documentation: Add documentation for RCU's major data structures
> >   documentation: Explain why rcu_read_lock() needs no barrier()
> >   documentation: Transitivity is not cumulativity
> >   documentation: Document illegality of call_rcu() from offline CPUs
> >   documentation: Explain how RCU's combining tree fights contention
> >   rcu: Assign false instead of 0 for ->core_needs_qs
> >   rcu: Update rcu_report_qs_rsp() comment
> >   rcu: Stop treating in-kernel CPU-bound workloads as errors
> >   rcu: Set rdp->gpwrap when CPU is idle
> >   rcutorture: Correct no-expedite console messages
> >   rcu: Document unique-name limitation for DEFINE_STATIC_SRCU()
> >   rcu: Catch up rcu_report_qs_rdp() comment with reality
> >   rcu: Export rcu_gp_is_normal()
> >   Merge branches 'doc.2015.02.23a', 'fixes.2015.02.23a' and 
> > 'torture.2015.02.23a' into HEAD
> > 
> > Paul Gortmaker (1):
> >   rcu: Make rcu/tiny_plugin.h explicitly non-modular
> > 
> > SeongJae Park (1):
> >   documentation: Clarify compiler store-fusion example
> > 
> > Yang Shi (1):
> >   rcu: Remove rcu_user_hooks_switch
> > 
> >  .../Design/Data-Structures/BigTreeClassicRCU.svg   |  474 +++
> >  .../Design/Data-Structures/BigTreeClassicRCUBH.svg |  499 +++
> >  .../Data-Structures/BigTreeClassicRCUBHdyntick.svg |  695 ++
> >  .../Data-Structures/BigTreePreemptRCUBHdyntick.svg |  741 +++
> >  .../BigTreePreemptRCUBHdyntickCB.svg   |  858 
> >  .../Design/Data-Structures/Data-Structures.html| 1395 
> > 
> >  .../Design/Data-Structures/Data-Structures.htmlx   | 1295 
> > ++
> >  .../Design/Data-Structures/HugeTreeClassicRCU.svg  |  939 +
> >  .../RCU/Design/Data-Structures/TreeLevel.svg   |  828 
> >  .../RCU/Design/Data-Structures/TreeMapping.svg |  305 +
> >  .../Design/Data-Structures/TreeMappingLevel.svg|  380 ++
> >  .../RCU/Design/Data-Structures/blkd_task.svg   |  843 
> >  .../RCU/Design/Data-Structures/nxtlist.svg |  396 ++
> >  .../RCU/Design/Requirements/Requirements.html  |  225 +++-
> >  .../RCU/Design/Requirements/Requirements.htmlx |  121 +-
> >  Documentation/memory-barriers.txt  |  141 +-
> >  include

Re: [PATCH] KVM: Remove redundant smp_mb() in the kvm_mmu_commit_zap_page()

[Paolo Bonzini]

On 08/03/2016 09:36, Lan Tianyu wrote:
> Summary about smp_mb()s we met in this thread. If misunderstood, please
> correct me. Thanks.
> 
> The smp_mb() in the kvm_flush_remote_tlbs() was introduced by the commit
> a4ee1ca4 and it seems to keep the order of reading and cmpxchg
> kvm->tlbs_dirty.
> 
> Quote from Avi:
> | I don't think we need to flush immediately; set a "tlb dirty" bit
> somewhere
> | that is cleareded when we flush the tlb.
> kvm_mmu_notifier_invalidate_page()
> | can consult the bit and force a flush if set.
> 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Marcelo Tosatti 

Unfortunately that patch added a bad memory barrier: 1) it lacks a
comment; 2) it lacks obvious pairing; 3) it is an smp_mb() after a read,
so it's not even obvious that this memory barrier has to do with the
immediately preceding read of kvm->tlbs_dirty.  It also is not
documented in Documentation/virtual/kvm/mmu.txt (Guangrong documented
there most of his other work, back in 2013, but not this one :)).

The cmpxchg is ordered anyway against the read, because 1) x86 has
implicit ordering between earlier loads and later stores; 2) even
store-load barriers are unnecessary for accesses to the same variable
(in this case kvm->tlbs_dirty).

So offhand, I cannot say what it orders.  There are two possibilities:

1) it orders the read of tlbs_dirty with the read of mode.  In this
case, a smp_rmb() would have been enough, and it's not clear where is
the matching smp_wmb().

2) it orders the read of tlbs_dirty with the KVM_REQ_TLB_FLUSH request.
 In this case a smp_load_acquire would be better.

3) it does the same as kvm_mmu_commit_zap_page's smp_mb() but for other
callers of kvm_flush_remote_tlbs().  In this case, we know what's the
matching memory barrier (walk_shadow_page_lockless_*).

4) it is completely unnecessary.

My guess is either (2) or (3), but I am not sure.  We know that
anticipating kvm->tlbs_dirty should be safe; worst case, it causes the
cmpxchg to fail and an extra TLB flush on the next call to the MMU
notifier.  But I'm not sure of what happens if the processor moves the
read later.

> The smp_mb() in the kvm_mmu_commit_zap_page() was introduced by commit
> c142786c6 which was merged later than commit a4ee1ca4. It pairs with
> smp_mb() in the walk_shadow_page_lockless_begin/end() to keep order
> between modifications of the page tables and reading mode.

Yes; it also pairs with the smp_mb__after_srcu_unlock() in vcpu_enter_guest.

> The smp_mb() in the kvm_make_all_cpus_request() was introduced by commit
> 6b7e2d09. It keeps order between setting request bit and reading mode.

Yes.

>>  So you can:
>>
>> 1) add a comment to kvm_flush_remote_tlbs like:
>>
>>  /*
>>   * We want to publish modifications to the page tables before reading
>>   * mode.  Pairs with a memory barrier in arch-specific code.
>>   * - x86: smp_mb__after_srcu_read_unlock in vcpu_enter_guest.
>>   * - powerpc: smp_mb in kvmppc_prepare_to_enter.
>>   */
>>
>> 2) add a comment to vcpu_enter_guest and kvmppc_prepare_to_enter, saying
>> that the memory barrier also orders the write to mode from any reads
>> to the page tables done while the VCPU is running.  In other words, on
>> entry a single memory barrier achieves two purposes (write ->mode before
>> reading requests, write ->mode before reading page tables).
> 
> These sounds good.
> 
>> The same should be true in kvm_flush_remote_tlbs().  So you may investigate
>> removing the barrier from kvm_flush_remote_tlbs, because
>> kvm_make_all_cpus_request already includes a memory barrier.  Like
>> Thomas suggested, leave a comment in kvm_flush_remote_tlbs(),
>> saying which memory barrier you are relying on and for what.
> 
> If we remove the smp_mb() in the kvm_flush_remote_tlbs(), we need to
> leave comments both in the kvm_flush_remote_tlbs() and
> kvm_mmu_commit_zap_page(), right?

Yes.  In fact, instead of removing it, I would change it to

smp_mb__before_atomic();

with a comment that points to the addition of the barrier in commit
a4ee1ca4.  Unless Guangrong can enlighten us. :)

>>
>> And finally, the memory barrier in kvm_make_all_cpus_request can become
>> smp_mb__after_atomic, which is free on x86.
> 
> I found you have done this in your tree :)
> 
> commit 5b06b60b72b73cbe3805d2a64d223e0264bd0479
> Author: Paolo Bonzini 
> Date:   Wed Feb 24 12:44:17 2016 +0100
> 
> KVM: mark memory barrier with smp_mb__after_atomic
> 
> Signed-off-by: Paolo Bonzini 

Yeah, but I reverted it because it makes sense to do it together with
your patch.

Paolo

Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

[Ingo Molnar]

* Peter Zijlstra  wrote:

> Here's a thread on syz-kaller:
> 
>   
> lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tny...@mail.gmail.com
> 
> If things have shifted again I'm sure Dmitry is willing to help.

So I tried to install 'go' but it's a _really_ unintuitive tool I have to say.

I installed golang-go on Ubuntu, which gave me a 'go' command:

  triton:~> go version
  go version go1.5.1 linux/amd64

that was the only step that worked. It's a dead end from that point on:

 triton:~> go get github.com/google/syzkaller
 package github.com/google/syzkaller: cannot download, $GOPATH not set. For 
more details see: go help gopath

ok, so lets set GOPATH to the distro src directory:

 triton:~> export GOPATH=/usr/lib/go/src/
 triton:~> go get github.com/google/syzkaller
 package github.com/google/syzkaller: mkdir /usr/lib/go/src/src: permission 
denied

btw., this is what the directory contains:

 triton:~> ls /usr/lib/go/src/
 all.bash  bootstrap.bash  bytes   compress   debug flag  html  
iomake.bat   nacltest.bash  race.bash  run.bash  strconv  
testing  unsafe
 all.bat   bufio   clean.bash  container  encoding  fmt   image 
iostest.bash  Make.dist  netrace.bat   run.bat   strings  text
 androidtest.bash  buildall.bash   clean.bat   crypto errorsgoindex 
log   math   os reflectruntime   sync time
 archive   builtin cmd database   expvarhash  
internal  make.bash mime   path   regexp sort  syscall  
unicode

so, according to the error message it wants a writable directory. Lets try it 
that 
way:

 triton:~> mkdir go
 triton:~> 
 triton:~> export GOPATH=/home/mingo/go/
 triton:~> go get github.com/google/syzkaller
 can't load package: package github.com/google/syzkaller: no buildable Go 
source files in /home/mingo/go/src/github.com/google/syzkaller


looks like someone wants 'Go' to be used as little as possible! ;-)

Thanks,

Ingo

Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

[David Howells]

Mimi Zohar  wrote:

> > The problem boils down to a difficulty in concocting a name that describes a
> > complex situation that may change depending on the configuration.  I can 
> > make
> > it "restrict_link_by_any_system_trusted" if you'd prefer.
> > 
> > That's why I want "system trusted keyrings" to refer to the builtin and the
> > secondary - *and* an extra UEFI keyring if we grow one of those.  It's a
> > collection of related keyrings.
> 
> Sigh, this is the same discussion we've had for years.

No, it isn't.

> The UEFI keys should not be trusted to validate the certificates being added
> to the IMA keyring.

A machine-security (e.g. UEFI) keyring will conceivably live in
certs/system_keyring.c and only be enabled if CONFIG_SYSTEM_TRUSTED_KEYRINGS=y
and, say, CONFIG_MACHINE_TRUSTED_KEYRING=y.  I didn't say that IMA necessarily
has to use it.

What we need to do is define a set of functions allow IMA to get the
restrictions it wants, depending on configuration.  In the code I currently
have, I think we have those:

restrict_link_reject
restrict_link_by_builtin_trusted
restrict_link_by_system_trusted

If you really want, I can add a restrict_link_for_ima in there, but I'd rather
not if IMA can use whichever of the above three most suits it.  How about:

restrict_link_reject
restrict_link_by_builtin_trusted
restrict_link_by_builtin_or_secondary_trusted

> Neither should the keys on the secondary keyring, unless specifically IMA
> Kconfig enabled, be used to validate the certificates being added to the IMA
> keyring.

Yes.

David

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue, 8 Mar 2016 10:22:07 -0500 (EST)
Chunyu Hu  wrote:


> Thanks for the quick review! This is an mistake, the change below should be 
> after it. From my
> limited knowledge and observation, seems there is no tracer sharing the 
> tracer_flag except the
> dummy_tracer flag. As in the patch that flag is not shared any more, so i 
> also removed these check
> in the previous email.
> 
> 
> @@ -6390,15 +6400,6 @@ create_trace_option_files(struct trace_array *tr, 
> struct tracer *tracer)
> if (!trace_ok_for_array(tracer, tr))
> return;
>  
> -   for (i = 0; i < tr->nr_topts; i++) {
> -   /*
> -* Check if these flags have already been added.
> -* Some tracers share flags.
> -*/
> -   if (tr->topts[i].tracer->flags == tracer->flags)
> -   return;
> -   }
> -
> 

The latency tracers share flags (irqsoff, preemptoff and preemptirqsoff)

-- Steve

[PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver

[Sinan Kaya]

The code is using the compatible DT string to associate a reset driver with
the actual device itself. The compatible string does not exist on ACPI
based systems. HID is the unique identifier for a device driver instead.
The change allows a driver to register with DT compatible string or ACPI
HID and then match the object with one of these conditions.

Rules for loading the reset driver are as follow:
- ACPI HID needs match for ACPI systems
- DT compat needs to match for OF systems

Tested-by: Eric Auger  (device tree only)
Tested-by: Shanker Donthineni  (ACPI only)
Signed-off-by: Sinan Kaya 
---
 .../vfio/platform/reset/vfio_platform_amdxgbe.c|   4 +-
 .../platform/reset/vfio_platform_calxedaxgmac.c|   4 +-
 drivers/vfio/platform/vfio_platform_common.c   | 112 +
 drivers/vfio/platform/vfio_platform_private.h  |  43 
 4 files changed, 125 insertions(+), 38 deletions(-)

diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c 
b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
index d4030d0..170dcf5 100644
--- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
+++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
@@ -119,7 +119,9 @@ int vfio_platform_amdxgbe_reset(struct vfio_platform_device 
*vdev)
return 0;
 }
 
-module_vfio_reset_handler("amd,xgbe-seattle-v1a", vfio_platform_amdxgbe_reset);
+module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
+ vfio_platform_amdxgbe_reset);
+VFIO_PLATFORM_MODULE_ALIAS("amd,xgbe-seattle-v1a");
 
 MODULE_VERSION("0.1");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c 
b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
index e3d3d94..635c6e0 100644
--- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
+++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
@@ -77,7 +77,9 @@ int vfio_platform_calxedaxgmac_reset(struct 
vfio_platform_device *vdev)
return 0;
 }
 
-module_vfio_reset_handler("calxeda,hb-xgmac", 
vfio_platform_calxedaxgmac_reset);
+module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
+ vfio_platform_calxedaxgmac_reset);
+VFIO_PLATFORM_MODULE_ALIAS("calxeda,hb-xgmac");
 
 MODULE_VERSION(DRIVER_VERSION);
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/vfio/platform/vfio_platform_common.c 
b/drivers/vfio/platform/vfio_platform_common.c
index 418cdd9..c758e72 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
 static DEFINE_MUTEX(driver_lock);
 
 static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char *compat,
-   struct module **module)
+ const char *acpihid, struct module **module)
 {
struct vfio_platform_reset_node *iter;
vfio_platform_reset_fn_t reset_fn = NULL;
 
mutex_lock(&driver_lock);
list_for_each_entry(iter, &reset_list, link) {
-   if (!strcmp(iter->compat, compat) &&
+   if (acpihid && iter->acpihid &&
+   !strcmp(iter->acpihid, acpihid) &&
+   try_module_get(iter->owner)) {
+   *module = iter->owner;
+   reset_fn = iter->reset;
+   break;
+   }
+   if (compat && iter->compat &&
+   !strcmp(iter->compat, compat) &&
try_module_get(iter->owner)) {
*module = iter->owner;
reset_fn = iter->reset;
@@ -49,15 +58,30 @@ static vfio_platform_reset_fn_t 
vfio_platform_lookup_reset(const char *compat,
return reset_fn;
 }
 
-static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
+static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
 {
-   vdev->reset = vfio_platform_lookup_reset(vdev->compat,
-   &vdev->reset_module);
-   if (!vdev->reset) {
-   request_module("vfio-reset:%s", vdev->compat);
-   vdev->reset = vfio_platform_lookup_reset(vdev->compat,
-&vdev->reset_module);
-   }
+   int rc = 0;
+
+   vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
+&vdev->reset_module);
+   if (vdev->reset)
+   return 0;
+
+   if (vdev->acpihid)
+   rc = request_module("vfio-reset:%s", vdev->acpihid);
+
+   if (rc && vdev->compat)
+   rc = request_module("vfio-reset:%s", vdev->compat);
+
+   if (rc)
+   return rc;
+
+   vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
+&vdev->re

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Vlastimil Babka]

On 03/08/2016 03:30 PM, Vineet Gupta wrote:
> We observed livelocks on ARC SMP setup when running hackbench with SLUB.
> This hardware configuration lacks atomic instructions (LLOCK/SCOND) thus
> kernel resorts to a central @smp_bitops_lock to protect any R-M-W ops
> suh as test_and_set_bit()

Sounds like this architecture should then redefine __clear_bit_unlock
and perhaps other non-atomic __X_bit() variants to be atomic, and not
defer this requirement to places that use the API?

> The spinlock itself is implemented using Atomic [EX]change instruction
> which is always available.
> 
> The race happened when both cores tried to slab_lock() the same page.
> 
>c1 c0
> ---   ---
> slab_lock
>   slab_lock
> slab_unlock
>   Not observing the unlock
> 
> This in turn happened because slab_unlock() doesn't serialize properly
> (doesn't use atomic clear) with a concurrent running
> slab_lock()->test_and_set_bit()
> 
> Cc: Christoph Lameter 
> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Joonsoo Kim 
> Cc: Andrew Morton 
> Cc: Noam Camus 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Vineet Gupta 
> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index d8fbd4a6ed59..b7d345a508dc 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -345,7 +345,7 @@ static __always_inline void slab_lock(struct page *page)
>  static __always_inline void slab_unlock(struct page *page)
>  {
>   VM_BUG_ON_PAGE(PageTail(page), page);
> - __bit_spin_unlock(PG_locked, &page->flags);
> + bit_spin_unlock(PG_locked, &page->flags);
>  }
>  
>  static inline void set_page_slub_counters(struct page *page, unsigned long 
> counters_new)
> 

[PATCH 2/2] vfio, platform: add QTI HIDMA reset driver

[Sinan Kaya]

In situations where the userspace driver is stopped abnormally and the
VFIO platform device is released, the assigned HW device currently is
left running. As a consequence the HW device might continue issuing IRQs
and performing DMA accesses.

This patch is implementing a reset driver for HIDMA platform driver.
This gets called by the VFIO platform reset interface.

Reviewed-by: Eric Auger 
Signed-off-by: Sinan Kaya 
---
 drivers/vfio/platform/reset/Kconfig|   9 ++
 drivers/vfio/platform/reset/Makefile   |   2 +
 .../vfio/platform/reset/vfio_platform_qcomhidma.c  | 101 +
 3 files changed, 112 insertions(+)
 create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c

diff --git a/drivers/vfio/platform/reset/Kconfig 
b/drivers/vfio/platform/reset/Kconfig
index 705..d02b3b5 100644
--- a/drivers/vfio/platform/reset/Kconfig
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -13,3 +13,12 @@ config VFIO_PLATFORM_AMDXGBE_RESET
  Enables the VFIO platform driver to handle reset for AMD XGBE
 
  If you don't know what to do here, say N.
+
+config VFIO_PLATFORM_QCOMHIDMA_RESET
+   tristate "VFIO support for Qualcomm Technologies HIDMA reset"
+   depends on VFIO_PLATFORM
+   help
+ Enables the VFIO platform driver to handle reset for Qualcomm 
Technologies
+ HIDMA Channel.
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile 
b/drivers/vfio/platform/reset/Makefile
index 93f4e23..ec7748a 100644
--- a/drivers/vfio/platform/reset/Makefile
+++ b/drivers/vfio/platform/reset/Makefile
@@ -1,7 +1,9 @@
 vfio-platform-calxedaxgmac-y := vfio_platform_calxedaxgmac.o
 vfio-platform-amdxgbe-y := vfio_platform_amdxgbe.o
+vfio-platform-qcomhidma-y := vfio_platform_qcomhidma.o
 
 ccflags-y += -Idrivers/vfio/platform
 
 obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o
+obj-$(CONFIG_VFIO_PLATFORM_QCOMHIDMA_RESET) += vfio-platform-qcomhidma.o
 obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c 
b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
new file mode 100644
index 000..103d481
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
@@ -0,0 +1,101 @@
+/*
+ * Qualcomm Technologies HIDMA VFIO Reset Driver
+ *
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vfio_platform_private.h"
+
+#define TRCA_CTRLSTS_OFFSET0x000
+#define EVCA_CTRLSTS_OFFSET0x000
+
+#define CH_CONTROL_MASKGENMASK(7, 0)
+#define CH_STATE_MASK  GENMASK(7, 0)
+#define CH_STATE_BIT_POS   0x8
+
+#define HIDMA_CH_STATE(val)\
+   ((val >> CH_STATE_BIT_POS) & CH_STATE_MASK)
+
+#define EVCA_IRQ_EN_OFFSET 0x110
+
+#define CH_RESET   9
+#define CH_DISABLED0
+
+int vfio_platform_qcomhidma_reset(struct vfio_platform_device *vdev)
+{
+   struct vfio_platform_region *trreg;
+   struct vfio_platform_region *evreg;
+   u32 val;
+   int ret;
+
+   if (vdev->num_regions != 2)
+   return -ENODEV;
+
+   trreg = &vdev->regions[0];
+   if (!trreg->ioaddr) {
+   trreg->ioaddr =
+   ioremap_nocache(trreg->addr, trreg->size);
+   if (!trreg->ioaddr)
+   return -ENOMEM;
+   }
+
+   evreg = &vdev->regions[1];
+   if (!evreg->ioaddr) {
+   evreg->ioaddr =
+   ioremap_nocache(evreg->addr, evreg->size);
+   if (!evreg->ioaddr)
+   return -ENOMEM;
+   }
+
+   /* disable IRQ */
+   writel(0, evreg->ioaddr + EVCA_IRQ_EN_OFFSET);
+
+   /* reset both transfer and event channels */
+   val = readl(trreg->ioaddr + TRCA_CTRLSTS_OFFSET);
+   val &= ~(CH_CONTROL_MASK << 16);
+   val |= CH_RESET << 16;
+   writel(val, trreg->ioaddr + TRCA_CTRLSTS_OFFSET);
+
+   ret = readl_poll_timeout(trreg->ioaddr + TRCA_CTRLSTS_OFFSET, val,
+HIDMA_CH_STATE(val) == CH_DISABLED, 1000,
+1);
+   if (ret)
+   return ret;
+
+   val = readl(evreg->ioaddr + EVCA_CTRLSTS_OFFSET);
+   val &= ~(CH_CONTROL_MASK << 16);
+   val |= CH_RESET << 16;
+

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue, 8 Mar 2016 10:32:11 -0500
Steven Rostedt  wrote:


> The latency tracers share flags (irqsoff, preemptoff and preemptirqsoff)

Although, that may have changed recently. /me investigates.

-- Steve

Re: [v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

[Torsten Duwe]

On Wed, Mar 09, 2016 at 12:52:03AM +1100, Balbir Singh wrote:
> 
> On 08/03/16 21:45, Torsten Duwe wrote:
> > To be fair, my last mail still was not 100% correct, but the conclusion

Wrote a correction to the correction. It should be clear now. Please nag me
if it isn't clear why klp_return_helper and its stack frame is needed.

> > that the mini frame is not needed at all is invalid. Please leave it as it
> > was, I'm working on a test / demonstrator for how to handle these.
> Why, the magic will be in the patched function? Please share the 
> test/demonstrator

Here it comes...

> > NAKed-by: Torsten Duwe 
> Why? For using CR+4 or removing the frame? Or you believe there is a better 
> way to
> handle this that work, IOW what is broken?

The stack frame removal. You're risking a memory access or jump into nirvana
or and endless loop.

klp_return_helper will do the right thing, and functions like e.g. printk
I would live patch like this (untested :-) :

8<--
#include 

/* compile using "-ffixed-r14"! */
register unsigned long pass_TOC asm("r14");

/*
 * Function pre-prologue to pop the klp_return_helper
 * mini stack frame. The saved r2 TOC value is read and
 * passed in pass_TOC (r14), the original LR is passed
 * in r0 and the LR itself. R12 is updated appropriately
 * for local TOC recalculation.
 */
extern void caller(void) asm("printk");
void caller(void)
{
  asm("ld %0,24(1)" : "=r" (pass_TOC));
  asm("addi 1,1,32");
  asm("addi 12,12,(real_printk-printk)@l");
  asm("ld 0,16(1)\n\tmtlr 0");
  asm("b real_printk");
}

extern int vprintk_default(const char *fmt, va_list args);

extern int printk(const char *fmt, ...) asm("real_printk");
int printk(const char *fmt, ...)
{
va_list args;
int r;

va_start(args, fmt);

r = vprintk_default(fmt, args);

va_end(args);

asm("mr 2,%0" : : "r" (pass_TOC));
return r;
}
8<--
Signed-off-by: Torsten Duwe 

As you can see, the extra effort for args on the stack is limited.

Torsten

Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

[Dmitry Vyukov]

On Tue, Mar 8, 2016 at 4:29 PM, Ingo Molnar  wrote:
>
> * Peter Zijlstra  wrote:
>
>> Here's a thread on syz-kaller:
>>
>>   
>> lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tny...@mail.gmail.com
>>
>> If things have shifted again I'm sure Dmitry is willing to help.
>
> So I tried to install 'go' but it's a _really_ unintuitive tool I have to say.
>
> I installed golang-go on Ubuntu, which gave me a 'go' command:
>
>   triton:~> go version
>   go version go1.5.1 linux/amd64
>
> that was the only step that worked. It's a dead end from that point on:
>
>  triton:~> go get github.com/google/syzkaller
>  package github.com/google/syzkaller: cannot download, $GOPATH not set. For 
> more details see: go help gopath
>
> ok, so lets set GOPATH to the distro src directory:
>
>  triton:~> export GOPATH=/usr/lib/go/src/
>  triton:~> go get github.com/google/syzkaller
>  package github.com/google/syzkaller: mkdir /usr/lib/go/src/src: permission 
> denied
>
> btw., this is what the directory contains:
>
>  triton:~> ls /usr/lib/go/src/
>  all.bash  bootstrap.bash  bytes   compress   debug flag  
> html  iomake.bat   nacltest.bash  race.bash  run.bash  
> strconv  testing  unsafe
>  all.bat   bufio   clean.bash  container  encoding  fmt   
> image iostest.bash  Make.dist  netrace.bat   run.bat   
> strings  text
>  androidtest.bash  buildall.bash   clean.bat   crypto errorsgo
> index log   math   os reflectruntime   sync   
>   time
>  archive   builtin cmd database   expvarhash  
> internal  make.bash mime   path   regexp sort  
> syscall  unicode
>
> so, according to the error message it wants a writable directory. Lets try it 
> that
> way:
>
>  triton:~> mkdir go
>  triton:~>
>  triton:~> export GOPATH=/home/mingo/go/
>  triton:~> go get github.com/google/syzkaller
>  can't load package: package github.com/google/syzkaller: no buildable Go 
> source files in /home/mingo/go/src/github.com/google/syzkaller

Yes, GOPATH needs to be set a writable dir.
You can ignore "can't load package" error. The goal of that step is
checkout syzkaller with all dependencies into correct dirs under
GOPATH. That's already done by now.
Or you can do (/... at the end):
$ go get github.com/google/syzkaller/...
That will checkout and build.
Either way you can continue with the make step.



> looks like someone wants 'Go' to be used as little as possible! ;-)

You probably did not observe recently a noobie trying to build a C
project with sufficiently-complicate-build-system and a bunch of
dependencies that needs to be on specific, unknown revisions, and that
still does not compile with you compiler and does not link with your
linker, and then of course target machine has a wrong glibc version :)

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

2016-03-08 19:45 GMT+09:00 Xishi Qiu :
> On 2016/3/8 15:48, Joonsoo Kim wrote:
>
>> On Mon, Mar 07, 2016 at 01:59:12PM +0100, Vlastimil Babka wrote:
>>> On 03/07/2016 05:34 AM, Joonsoo Kim wrote:
 On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote:
>> Sad to hear that.
>>
>> Could you tell me your system's MAX_ORDER and pageblock_order?
>>
>
> MAX_ORDER is 11, pageblock_order is 9, thanks for your help!
>>>
>>> I thought that CMA regions/operations (and isolation IIRC?) were
>>> supposed to be MAX_ORDER aligned exactly to prevent needing these
>>> extra checks for buddy merging. So what's wrong?
>>
>> CMA isolates MAX_ORDER aligned blocks, but, during the process,
>> partialy isolated block exists. If MAX_ORDER is 11 and
>> pageblock_order is 9, two pageblocks make up MAX_ORDER
>> aligned block and I can think following scenario because pageblock
>> (un)isolation would be done one by one.
>>
>> (each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
>> MIGRATE_ISOLATE, respectively.
>>
>
> Hi Joonsoo,
>
>> CC -> IC -> II (Isolation)
>
>> II -> CI -> CC (Un-isolation)
>>
>> If some pages are freed at this intermediate state such as IC or CI,
>> that page could be merged to the other page that is resident on
>> different type of pageblock and it will cause wrong freepage count.
>>
>
> Isolation will appear when do cma alloc, so there are two following threads.
>
> C(free)C(used) -> start_isolate_page_range -> I(free)C(used) -> 
> I(free)I(someone free it) -> undo_isolate_page_range -> C(free)C(free)
> so free cma is 2M -> 0M -> 0M -> 4M, the increased 2M was freed by someone.

Your example is correct one but think about following one.
C(free)C(used) -> start_isolate_page_range -> I(free)C(used) ->
I(free)**C**(someone free it) -> undo_isolate_page_range ->
C(free)C(free)

it would be 2M -> 0M -> 2M -> 6M.
When we do I(free)C(someone free it), CMA freepage is added
because it is on CMA pageblock. But, bad merging happens and
4M buddy is made and it is in isolate buddy list.
Later, when we do undo_isolation, this 4M buddy is moved to
CMA buddy list and 4M is added to CMA freepage counter so
total is 6M.

Thanks.

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Steven Rostedt]

On Tue, 8 Mar 2016 10:33:51 -0500
Steven Rostedt  wrote:

> On Tue, 8 Mar 2016 10:32:11 -0500
> Steven Rostedt  wrote:
> 
> 
> > The latency tracers share flags (irqsoff, preemptoff and preemptirqsoff)  
> 
> Although, that may have changed recently. /me investigates.

Ah it did:

Commit 03905582fd0939 "tracing: Move "display-graph" option to main
options" removed duplicate trace options.

Thus, I guess your change is fine. I'll go back and include it.

-- Steve

Re: [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver

[Sinan Kaya]

On 3/8/2016 10:33 AM, Sinan Kaya wrote:
> + int rc = 0;
> +

I should have initialized this to -1. 

> + vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
> +  &vdev->reset_module);
> + if (vdev->reset)
> + return 0;
> +
> + if (vdev->acpihid)
> + rc = request_module("vfio-reset:%s", vdev->acpihid);
> +
> + if (rc && vdev->compat)
> + rc = request_module("vfio-reset:%s", vdev->compat);
> +


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Ferreri Tonello]

Hi Balbi,

On 08/03/16 14:01, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Ferreri Tonello  writes:
 Since f_midi_transmit is called by both ALSA and USB frameworks, it
>>> can
 potentially cause a race condition between both calls. This is bad
>>> because the
 way f_midi_transmit is implemented can't handle concurrent calls.
>>> This is due
 to the fact that the usb request fifo looks for the next element and
>>> only if
 it has data to process it enqueues the request, otherwise re-uses it.
>>> If both
 (ALSA and USB) frameworks calls this function at the same time, the
 kfifo_seek() will return the same usb_request, which will cause a
>>> race
 condition.

 To solve this problem a syncronization mechanism is necessary. In
>>> this case it
 is used a spinlock since f_midi_transmit is also called by
>>> usb_request->complete
 callback in interrupt context.

 On benchmarks realized by me, spinlocks were more efficient then
>>> scheduling
 the f_midi_transmit tasklet in process context and using a mutex
 to synchronize. Also it performs better then previous
 implementation
>>> that
 allocated a usb_request for every new transmit made.
>>>
>>> behaves better in what way ? Also, previous implementation would not
>>> suffer from this concurrency problem, right ?
>>
>> The spin lock is faster than allocating usb requests all the time,
>> even if the udc uses da for it.
>
> did you measure ? Is the extra speed really necessary ? How did you
> benchmark this ?

 Yes I did measure and it was not that significant. This is not about
 speed. There was a bug in that approach that I already explained on
>>>
>>> you have very confusing statements. When I mentioned that previous code
>>> wouldn't have the need for the spinlock you replied that spinlock was
>>> faster.
>>>
>>> When I asked you about benchmarks you reply saying it's not about the
>>> speed.
>>>
>>> Make up your mind dude. What are you trying to achieve ?
>>>
 that patch, which was approved and applied BTW.
>>>
>>> patches can be reverted if we realise we're better off without
>>> them. Don't get cocky, please.
>>
>> Yes am I aware of that, but I honestly think that is the wrong way of
>> dealing with this.
>>
>> ?? I don't get why am I giving this impression.
> 
> re-read your emails. The gist goes like this:
> 
> . Send patch
> . Got comments
> . Well, whatever, you can just ignore if you don't agree

This is one of the problems with email. It can give the wrong impression
and feelings. :)

That was not what I meant at all. I mean that for real, not in a
childish manner. I'm sorry if I gave you that impression.

> 
 Any way, this spinlock should've been there since that patch but I
 couldn't really trigger this problem without a stress test.
>>>
>>> which tells me you sent me patches without properly testing. How much
>>> time did it take to trigger this ? How did you trigger this situation ?
>>
>> No, that is no true. The implementation I sent is working properly for
>> any real world usage.
>>
>> The stress test I made to break the current implementation is *not* a
>> real use-case. I made it in order to push as far as possible how fast
>> the driver can *reliably* handle while sending and reading data. Then I
>> noticed the bug.
>>
>> So, to answer your question. To trigger this bug is not a matter of
>> time. The following needs to happen:
>>  1. Device send MIDI message that is *bigger* than the usb request
>> length. (just this by itself is really unlikely to happen in real world
>> usage)
> 
> I wouldn't say it's unlikely. You just cannot trust the other side of
> the wire. We've seen e.g. Xbox 360's SCSI layer sending messages of the
> wrong size and we worked around them in g_mass_storage.
> 
> Broken implementations are a real thing ;-)

Fair enough. And that's why I am pushing this fix. :)

> 
>>  2. Host send a MIDI message back *exactly* at the same time as the
>> device is processing the second part of the usb request from the same
>> message.
> 
> also not that unlikely to happen ;-) You can't assume the host will only
> shift tokens on the wire at the time you're expecting it to.
> 
>> I couldn't trigger this in all the tests we've made. I just triggered
>> when I was sending huge messages back and forth (device <-> host) as
>> mentioned.
> 
> fair enough.
> 
>> In fact, we have thousands of devices out there without this patch (but
>> with my previous patch that introduced this bug).
> 
> that's thousands of devices waiting to have a problem, right ? :-)

:X

> 
>> I am not trying to say it wasn't a mistake. That patch unfortunately
>> introduces this bug, but it has real improvements over the previous
>> implementation. AFAIR the improvements are:
>>  * Fixes a bug that was causing the DMA buffer to fil

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Tue, 8 Mar 2016 10:39:22 -0300
Mauro Carvalho Chehab  escreveu:

> Em Tue, 08 Mar 2016 05:13:13 -0700
> Dan Allen  escreveu:
> 
> > On Tue, Mar 8, 2016 at 4:29 AM, Mauro Carvalho Chehab <  
> > mche...@osg.samsung.com> wrote:
> >   
> > > pandoc did a really crap job on the conversion. To convert this
> > > into something useful, we'll need to spend a lot of time, as it lost
> > > most of the cross-references, as they were defined via DocBook macros.
> > >
> > 
> > I agree pandoc creates crappy AsciiDoc. We have a much better converter in
> > the works called DocBookRx.
> > 
> > https://github.com/opendevise/docbookrx
> > 
> > It has converted several very serious DocBook documents and we're
> > continuing to improve it. It's also a lot easier to hack than pandoc.  
> 
> Didn't work:
> 
> $ ./bin/docbookrx ~/devel/docbook_test/v4l2.xml 
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.
> No visitor defined for ! Skipping.

I tried to use docbookrx for the bits that were not properly converted,
like the manpage-like pages:

$  ../docbookrx/bin/docbookrx Documentation/DocBook/media/v4l/func-ioctl.xml
No visitor defined for ! Skipping.

Dan, if you want to take a look on what's going wrong here, 
the XML I'm trying to convert is:


https://git.linuxtv.org/media_tree.git/tree/Documentation/DocBook/media/v4l/func-ioctl.xml

If this would work, it should be generating something like:
https://git.linuxtv.org/mchehab/asciidoc-poc.git/tree/func-ioctl.adoc

Pandoc failed to fully convert it, but at least it left all the texts,
with prevented rewriting it from scratch. This is the manual fix
I applied to it:

https://git.linuxtv.org/mchehab/asciidoc-poc.git/commit/func-ioctl.adoc?id=801d336c3742f26731e08c284290c32c0b4632fc

FYI, we have 133 xml files at the media uAPI doc with refmeta.

-- 
Thanks,
Mauro

Re: [RFC 4/4] perf kvm: Fix output fields instead of 'trace' for perf kvm report on powerpc

[Ravi Bangoria]

Hi Arnaldo,

Gentle reminder :)  Any updates?

Regards,
Ravi

On Thursday 03 March 2016 06:49 AM, Ravi Bangoria wrote:

Thanks acme,

On Wednesday 02 March 2016 09:52 PM, Arnaldo Carvalho de Melo wrote:

Em Wed, Mar 02, 2016 at 09:16:48PM +0530, Ravi Bangoria escreveu:

Thanks Arnaldo,

Please find my comments.

On Wednesday 02 March 2016 07:55 PM, Arnaldo Carvalho de Melo wrote:

Em Wed, Feb 24, 2016 at 02:37:45PM +0530, Ravi Bangoria escreveu:

  use_browser = 0;
+if (!field_order &&
+is_perf_data_reorded_on_ppc(session->evlist) &&
+perf_guest_only())
+field_order = "overhead,comm,dso,sym";
+

Can you please do it as:

__weak void arch__override_field_order(struct perf_evlist *evlist, 
const char **field_order)

{
}
So you mean like this - Just implement only weak function and move 
code into

it?
ie. No strong implementation at this point of time.

Like,

__weak void arch__override_field_order(struct perf_evlist *evlist, 
const

char **f_order)
{
 if (!field_order &&
 is_perf_data_reorded_on_ppc(session->evlist) &&

Oh, I see, ugh, when running on x86_64 we wouldn't use this, so we need
to have per arch default field orders, now I have to recall why is it
that we need this per-arch field order :-\


Sorry, I'm little bit confused. We need arch specific functionality 
present

on all arch to make cross arch reporting possible.

for example, record perf.data on ppc and report on x86, we need
ppc specific function present in perf binary compiled on x86.

Please let me know if I understood it wrong.

Regads,
Ravi

Re: [PATCH 3.12 000/116] 3.12.56-stable review

[Jiri Slaby]

On 03/04/2016, 03:02 PM, Guenter Roeck wrote:
> On 03/04/2016 01:02 AM, Jiri Slaby wrote:
>> This is the start of the stable review cycle for the 3.12.56 release.
>> There are 116 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Tue Mar  8 10:01:48 CET 2016.
>> Anything received after that time might be too late.
>>
> 
> Build results:
> total: 124 pass: 124 fail: 0
> Qemu test results:
> total: 79 pass: 79 fail: 0

On 03/04/2016, 03:47 PM, Shuah Khan wrote:
> Compiled and booted on my test system. No dmesg regressions.

Thank you both!

-- 
js
suse labs

Re: [PATCH 2/5] gpio: gpiolib: Print error number if gpio hog failed

[Laxman Dewangan]

On Tuesday 08 March 2016 07:52 PM, Thierry Reding wrote:

On Tue, Mar 08, 2016 at 05:32:05PM +0530, Laxman Dewangan wrote:


Signed-off-by: Laxman Dewangan 
---
  drivers/gpio/gpiolib.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bc788b9..7575ebb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2621,15 +2621,16 @@ int gpiod_hog(struct gpio_desc *desc, const char *name,
  
  	local_desc = gpiochip_request_own_desc(chip, hwnum, name);

if (IS_ERR(local_desc)) {
-   pr_err("requesting hog GPIO %s (chip %s, offset %d) failed\n",
-  name, chip->label, hwnum);
+   status = PTR_ERR(local_desc);
+   pr_err("requesting hog GPIO %s, chip %s, offset %d failed %d\n",
+  name, chip->label, hwnum, status);

I find this type of format hard to read. I prefer a semi-colon to
separate the message from the failure reason (i.e. error code).

Besides that I don't understand why you're dropping the parentheses
around the "chip %s, offset %d", I found that easier on the eye.





I did to accommodate the  3 extra character ( %d) for string format on 
that line as it was already near to 80 column.

Just did not want to split in multiple lines.

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Vineet Gupta]

On Tuesday 08 March 2016 08:30 PM, Christoph Lameter wrote:
> On Tue, 8 Mar 2016, Vineet Gupta wrote:
> 
>> This in turn happened because slab_unlock() doesn't serialize properly
>> (doesn't use atomic clear) with a concurrent running
>> slab_lock()->test_and_set_bit()
> 
> This is intentional because of the increased latency of atomic
> instructions. Why would the unlock need to be atomic? This patch will
> cause regressions.
> 
> Guess this is an architecture specific issue of modified
> cachelines not becoming visible to other processors?

Absolutely not - we verified with the hardware coherency tracing that there was 
no
foul play there. And I would dare not point finger at code which was last 
updated
in 2011 w/o being absolutely sure.

Let me explain this in bit more detail. Like I mentioned in commitlog, this 
config
of ARC doesn't have exclusive load/stores (LLOCK/SCOND) so atomic ops are
implemented using a "central" spin lock. The spin lock itself is implemented 
using
EX instruction (atomic R-W)

Generated code for slab_lock() - essentially bit_spin_lock() is below (I've
removed generated code for CONFIG_PREEMPT for simplicity)

80543b0c :
80543b0c:   push_s blink
...
80543b3a:   mov_s  r15,0x809de168   <-- @smp_bitops_lock
80543b40:   mov_s  r17,1
80543b46:   mov_s  r16,0

# spin lock() inside test_and_set_bit() - see arc bitops.h (!LLSC code)
80543b78:   clri   r4
80543b7c:   dmb3
80543b80:   mov_s  r2,r17
80543b82:   ex r2,[r15]
80543b86:   breq   r2,1,80543b82
80543b8a:   dmb3

# set the bit
80543b8e:   ld_s   r2,[r13,0] <--- (A) Finds PG_locked is set
80543b90:   or r3,r2,1<--- (B) other core unlocks right here
80543b94:   st_s   r3,[r13,0] <--- (C) sets PG_locked (overwrites 
unlock)

# spin_unlock
80543b96:   dmb3
80543b9a:   mov_s  r3,r16
80543b9c:   ex r3,[r15]
80543ba0:   dmb3
80543ba4:   seti   r4

# check the old bit
80543ba8:   bbit0  r2,0,80543bb8   <--- bit was set, branch not taken
80543bac:   b_s80543b68<--- enter the test_bit() loop

   80543b68:ld_s   r2,[r13,0]  <-- (C) reads the bit, set by SELF
   80543b6a:bbit1r2,0,80543b68  spins infinitely

...


Now using hardware coherency tracing (and using the cycle timestamps) we 
verified
(A) and (B)

Thing is with exclusive load/store this race can't just happen since the
intervening ST will cause the ST in (C) to NOT commit and the LD/ST will be 
retried.

And there will be very few production systems which are SMP but lack exclusive
load/stores.

Are you convinced now !

-Vineet

Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"

[Toshi Kani]

On Mon, 2016-03-07 at 22:28 -0500, Paul Gortmaker wrote:
> [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> disabled"] On 07/03/2016 (Mon 18:35) Toshi Kani wrote:
> 
> > On Mon, 2016-03-07 at 17:56 -0700, Toshi Kani wrote:
> > > On Mon, 2016-03-07 at 18:53 -0500, Paul Gortmaker wrote:
> > > > [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> > > > disabled"] On 07/03/2016 (Mon 16:38) Toshi Kani wrote:
> > > > 
> > > > > On Mon, 2016-03-07 at 16:08 -0500, Paul Gortmaker wrote:
> > > > > > [dropping oe list and lkml since attaching dmesg files.]
> > > > > > 
> > > > 
> > > > [...]
> > > > 
> > > > > > > Yes, please send me full dmesg files.  Since I do not know
> > > > > > > your original state, the diff does not give me the whole
> > > > > > > picture.
> > > > > > 
> > > > > > Attached.
> > > > > 
> > > > > Thanks for the dmesg files!  As I suspected, there is no message
> > > > > from pat_init() in both cases.  That is, you are missing the
> > > > > following message, which shows how PAT is configured to support
> > > > > cache attributes.
> > > > > 
> > > > > # dmesg | grep PAT
> > > > > [0.00] x86/PAT: Configuration [0-7]:
> > > > > WB  WC  UC- UC  WB  WC  UC- WT  
> > > > 
> > > > Interesting...
> > > > 
> > > > > 
> > > > > It may have seemed working before, but you did not have WC
> > > > > configured to PAT without calling pat_init().  There was not a
> > > > > proper check in place to detect this error before.  Can you
> > > > > please check your code to see what caused this skip of
> > > > > pat_init()?  If you have a git tree, I can take a look as well. 
> > > > 
> > > > You already have git copies of what I'm running, since it is
> > > > vanilla mainline commits.  No code changes at this end
> > > > whatsoever.  I did the bisect on vanilla mainline.  All I took from
> > > > yocto was their ".config"
> > > > 
> > > > To recap, v4.1-rc5-21-g9dac62909451 works,  v4.1-rc5-22-
> > > > g9cd25aac1f44 fails, and v4.5-rc6 also fails.  If pat_init() isn't
> > > > called then this is a bug in current mainline.  I'll have a look
> > > > later myself and see if I can trace out how we expect to get to
> > > > pat_init() and how that might be skipped inadvertently unless
> > > > someone beats me to it.
> > > 
> > > Oh, I see.  Can you send me the ".config" file?
> > 
> > And also an output of /proc/cpuinfo, please?
> 
> Host?  Guest?  Both?

Guest.


> > I think I know what's going on.  I noticed that you have the following
> > message in your dmesg files.
> > 
> >  [0.00] MTRR: Disabled
> > 
> > MTRR is set to disabled when your CPU is Intel but does not support
> > MTRR.
> 
> I've run the test on a modern expensive xeon, a 4-5 year old xeon, and
> on an old pentium dual core (the cheaper dumbed down core2-duo that
> doesn't support virtualization) from around 2007.  In all cases the
> result was the same.  Perhaps that is because the qemu launch script
> appears to set the CPU type regardless?  (it uses "-cpu qemu32" but I
> confess that I do not know exactly what silicon that tries to emulate).

There is a matter of how qemu emulates CPU features.  There is no such
Intel CPU that supports PAT w/o MTRR.  This is why the current code assumes
this dependency.

> >  Perhaps, QEMU does not emulate MTRR?
> 
> I will be the 1st to admit that I am not a seasoned qemu user, so I've
> no idea if the above is true.  I still prefer testing on real hardware,
> even if that comes across as "old school".  :)

We can check it with /proc/cpuinfo on a guest. 

> > pat_init() is not called when MTRR is disabled.  I think this
> > dependency is wrong, and it needs to be fixed.
> > 
> > This issue has been there for a long time, and you have been running
> > essentially as PAT disabled in the past.  The commit in question simply
> > detected this issue.
> 
> OK, that sounds good -- in that it seems we are finally getting to the
> bottom of what happened here.  Any thoughts on why built-in vs. modular
> somehow managed to mask the issue?

No idea.  I do not think uvesafb being built-in vs. module has anything to
do with it.  But we need to verify your /proc/cpuinfo to be sure.  I will
work on the PAT fix once this issue is confirmed.

For the time being, please use "nopat" boot option to workaround this
issue.  This keeps the PAT state consistent as disabled in your env.

Thanks,
-Toshi

Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima_mok [ver #2]

[Petko Manolov]

On 16-03-08 14:44:24, David Howells wrote:
> Petko Manolov  wrote:
> 
> > I would suggest leaving (1) and (3).
> 
> Do you mean dropping option (2) and leaving (1) and (3)?  Or do you mean 
> dropping options (1) and (3)?

Dropping option (2) and leaving (1) and (3).

(2) is subset of (3) and IMHO adds unnecessary complexity.


Petko

Re: [PATCH v19 00/10] Compile-time stack metadata validation

[Ingo Molnar]

so there's a much more serious objtool bug that I found today, apparently it 
can 
get into an infinite loop with certain randconfigs:

   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND

  
104261 mingo 39  198672936840 R 100.0  0.0 115:03.97 objtool

  
104485 mingo 39  198672876780 R 100.0  0.0 115:03.71 objtool

  
115277 mingo 39  198808892796 R 100.0  0.0 114:59.38 objtool
  

unfortunately 'perf record -g' does not seem to be able to resolve it:

fomalhaut:~> perf record -g -p 104261 -a sleep 1
Warning:
PID/TID switch overriding SYSTEM[ perf record: Woken up 17 times to write data ]
[ perf record: Captured and wrote 4.076 MB perf.data (4015 samples) ]

Samples: 4K of event 'cycles:ppp', Event count (approx.): 3342262267

  
  Children  Self  Command  Shared Object  Symbol

  
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184bf00
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184bf70
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184bfe0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c050
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c0c0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c130
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c1a0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c210
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c280
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c2f0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c360
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c3d0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c440
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c4b0
+  100.00% 0.00%  objtool  [unknown]  [k] 0x0184c520

Plain 'perf top' shows:

Overhead  Shared Object   Symbol

  
  95.36%  objtool [.] validate_branch
   2.36%  objtool [.] find_symbol_by_offset
   0.50%  libc-2.22.so[.] __strcmp_sse2_unaligned
   0.47%  [kernel][k] nmi
   0.06%  [kernel][k] format_decode
   0.05%  objtool [.] strcmp@plt

I've attached the config that triggers it.

Thanks,

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

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KER

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

[Jon Medhurst (Tixy)]

On Tue, 2016-03-08 at 19:45 +0530, Vinod Koul wrote:
> On Tue, Mar 08, 2016 at 10:40:11AM +, Jon Medhurst (Tixy) wrote:
> > On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote:
> > > On Wed, Feb 24, 2016 at 01:14:34PM +, Jon Medhurst (Tixy) wrote:
> > > > The residue calculation in pl330_tx_status doesn't handle transitional
> > > > states that occur at the time one descriptor (A) is completed and the
> > > > next (B) is started. Specifically, both A and B can simultaneously be in
> > > > the BUSY state and at this time the thread's 'req_running' may (or may
> > > > not) be -1.
> > > 
> > > you are under lock so descriptor state wont be update while we are it.
> > > 
> > > Also the query for residue is for "a descriptor" not whatever is the 
> > > current
> > > running descriptor...
> > > 
> > > > 
> > > > To cope with this situation we change the code to ensure A is treated as
> > > > complete and B as having not yet started. Prior to the change, the code
> > > > would calculate a transferred byte count as if both A and B had
> > > > completed.
> > > 
> > > You query for either A or B not both!
> > 
> > I've probably been using wrong/ambiguous terminology...
> > 
> > In my description I'm using 'descriptor' to refer to a 'struct
> > dma_pl330_desc', I guess other people assume 'struct
> > dma_async_tx_descriptor'?
> 
> Nope
> 
> > The situation I was debugging was audio playback, where ASoC ends up
> > calling pl330_prep_dma_cyclic() with a period one quarter the length of
> > the buffer it is using, so that results in four dma_pl330_desc
> > 'descriptors' being created to cover that buffer. These later get
> > submitted to a DMA channel (struct dma_pl330_chan) which has a list of
> > these that it is processing (the 'work_list').
> > 
> > The residual calculation that currently exists in pl08x_dma_tx_status()
> > is iterating this work_list and summing the length of currently
> > transferring 'descriptor' with those later pending ones. I believe that
> > is correct behaviour because these 'descriptors' (dma_pl330_desc) are
> > all internal implementation details of the driver, and the dmaengine
> > API's are dealing in units of 'dma_async_tx_descriptor' ?
> 
> Not really. If you look closely dma_pl330_desc contains
> dma_async_tx_descriptor. A descriptor represents a tranasaction and is
> certainly not internal detail of your driver

I think that for this driver it's kinda both, which is why it's
confusing...

pl330_prep_dma_cyclic(), after creating a number of dma_pl330_desc
objects in a circular list, returns the address of the
dma_async_tx_descriptor contained in the last one. I'm guessing that as
far as users of the dmaengine API is concerned, this is treated as just
a single descriptor. pl330_prep_slave_sg() creates a similar circular
list.

When these descriptors are later submitted to the driver for transfer,
it is done by a call to pl330_tx_submit, which I has this comment...

/*
 * We returned the last one of the circular list of descriptor(s)
 * from prep_xxx, so the argument to submit corresponds to the last
 * descriptor of the list.
 */

This goes on to add all the linked descriptors to the pending queue for
sending to the DMA hardware, and then returns the cookie of the last
descriptor, maintaining the fiction to the dmaengine API's that there is
just a single descriptor.

> 
> The reside is requested for "a descriptor". For example if you have prepared
> two descriptors A and B and submitted them, then you can request status and
> reside for A and you need to calculate that for A only and not take into
> account status of B

But, in the case of the pl330 driver, A and B may each consist of
multiple internal/hidden descriptors. So the residue calculation has to
sum up the residue of all these internal/hidden descriptors as well.
This is what the current pl330_tx_status() function does, but has bugs.

I've only just managed to clearly understand all the above details
whilst writing this email, and this confusion obviously means the code
and any commit messages need to explain things better.

-- Tixy

> 
> > 
> > If the current code is OK in this regard, it is definitely buggy because
> > it doesn't cope with the situation when two dma_pl330_desc's are in the
> > state 'BUSY' a, which I have seen occur when debugging this issue, had
> > worked out can happen by analysing the code, and is acknowledged by the
> > in-source comments for enum desc_status...
> > 
> > /*
> >  * Sitting on the work_list and already submitted
> >  * to the PL330 core. Not more than two descriptors
> >  * of a channel can be BUSY at any time.
> >  */
> > BUSY,
> > 
> > In my problematic usecase I have userside code calling ALSA ioctls to
> > poll the current audio playback position which results in
> > pl08x_dma_tx_status() being called multiple times a second. After only a
> > second or two the buggy situation gets hit, resulting in a
> > miscalculation that ASoC interprets as a buffer

Linux kernel bug

[Allen Ashley]

I want to report a kernel bug: the kernel module
uas for usb storage repeatedly crashes. The
problem occurs for kernels 3.10.17, 4.4.1, and
4.4.2. To whom should I send details?

Thank you.

Re: [PATCH V14 8/9] vfio, platform: add support for ACPI while detecting the reset driver

[Sinan Kaya]

Hi,

On 3/8/2016 12:07 AM, Sinan Kaya wrote:
> On 3/7/2016 11:46 PM, Eric Auger wrote:
>>> #define module_vfio_reset_handler(compat, acpihid, reset) \
 MODULE_ALIAS("vfio-reset: dt: " compat); \
 MODULE_ALIAS("vfio-reset: acpi: " acpihid); \
>> My gut feeling is we must not create a dummy alias when the mode
>> (dt/acpi) is not supported/tested. It fills the modinfo section with
>> spurious data, aliases are visible to modinfo, ...
>>
>> So I personally foresee 2 solutions,
>> 1) we create a single alias using acpihid if supported or compat if not.
>> Then even in dt mode we try to load this module through the acpihid
>> alias. Looks weird but should work.
>> 2) We simply move the module alias declaration out of this macro (to the
>> reset module itself), define 2 aliases in case both dt and acpi are
>> supported & tested.
>>
>> My personal preference is 2 I think.
>>
>> Best Regards
>>
>> Eric
>>
> 
> I agree with your assessment of #2. We are trying to be too smart. 
> I'll post a patch with #2 solution.
> 

I split patch 8 and 9 from the series and posted a new set here.

http://www.spinics.net/lists/arm-kernel/msg489578.html

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

[PATCH v2 1/2] ACPI, APEI: Fix leaked resources

[Joshua Hunt]

We leak the NVS and arch resources (if used), in apei_resources_request.
They are allocated to make sure we exclude them from the APEI resources,
but they are never freed at the end of the function. Free them now.

Signed-off-by: Josh Hunt 
---
 drivers/acpi/apei/apei-base.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c
index a2c8d7a..da370e1 100644
--- a/drivers/acpi/apei/apei-base.c
+++ b/drivers/acpi/apei/apei-base.c
@@ -536,7 +536,8 @@ int apei_resources_request(struct apei_resources *resources,
goto err_unmap_ioport;
}
 
-   return 0;
+   goto arch_res_fini;
+
 err_unmap_ioport:
list_for_each_entry(res, &resources->ioport, list) {
if (res == res_bak)
@@ -551,7 +552,8 @@ err_unmap_iomem:
release_mem_region(res->start, res->end - res->start);
}
 arch_res_fini:
-   apei_resources_fini(&arch_res);
+   if (arch_apei_filter_addr)
+   apei_resources_fini(&arch_res);
 nvs_res_fini:
apei_resources_fini(&nvs_resources);
return rc;
-- 
1.7.9.5

[PATCH v2 0/2] ACPI, APEI: Memory leaks

[Joshua Hunt]

While investigating a possible memory leak using kmemleak I came across the
following five leaks coming from APEI and ERST:

unreferenced object 0x880402b6ee80 (size 32):
  comm "swapper/0", pid 1, jiffies 4294669373 (age 318.183s)
  hex dump (first 32 bytes):
58 fe ab fa 03 88 ff ff 58 fe ab fa 03 88 ff ff  X...X...
18 50 ea dc 00 00 00 00 3f 50 ea dc 00 00 00 00  .P..?P..
  backtrace:
[] create_object+0x103/0x2c0
[] kmemleak_alloc+0x82/0xc0
[] kmem_cache_alloc_trace+0x17b/0x210
[] apei_res_add+0x19a/0x200
[] collect_res_callback+0x82/0xa0
[] apei_exec_for_each_entry+0x85/0xb0
[] apei_exec_collect_resources+0x1a/0x20
[] erst_init+0x3d6/0x3e5
[] do_one_initcall+0x19d/0x1d0
[] kernel_init_freeable+0x13d/0x1d6
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x42/0x70
[] 0x
unreferenced object 0x880402b6ee40 (size 32):
  comm "swapper/0", pid 1, jiffies 4294670231 (age 317.326s)
  hex dump (first 32 bytes):
68 fe ab fa 03 88 ff ff 68 fe ab fa 03 88 ff ff  h...h...
b2 00 00 00 00 00 00 00 b3 00 00 00 00 00 00 00  
  backtrace:
[] create_object+0x103/0x2c0
[] kmemleak_alloc+0x82/0xc0
[] kmem_cache_alloc_trace+0x17b/0x210
[] apei_res_add+0x19a/0x200
[] collect_res_callback+0x9c/0xa0
[] apei_exec_for_each_entry+0x85/0xb0
[] apei_exec_collect_resources+0x1a/0x20
[] erst_init+0x3d6/0x3e5
[] do_one_initcall+0x19d/0x1d0
[] kernel_init_freeable+0x13d/0x1d6
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x42/0x70
[] 0x
unreferenced object 0x880402b6ee20 (size 32):
  comm "swapper/0", pid 1, jiffies 4294672240 (age 315.317s)
  hex dump (first 32 bytes):
88 fd ab fa 03 88 ff ff 00 ee b6 02 04 88 ff ff  
00 d0 15 cd 00 00 00 00 00 40 16 cd 00 00 00 00  .@..
  backtrace:
[] create_object+0x103/0x2c0
[] kmemleak_alloc+0x82/0xc0
[] kmem_cache_alloc_trace+0x17b/0x210
[] apei_res_add+0x19a/0x200
[] apei_get_res_callback+0x1a/0x20
[] acpi_nvs_for_each_region+0x2b/0x50
[] apei_resources_request+0x95/0x380
[] erst_init+0xe2/0x3e5
[] do_one_initcall+0x19d/0x1d0
[] kernel_init_freeable+0x13d/0x1d6
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x42/0x70
[] 0x
unreferenced object 0x880402b6ee00 (size 32):
  comm "swapper/0", pid 1, jiffies 4294672400 (age 315.157s)
  hex dump (first 32 bytes):
20 ee b6 02 04 88 ff ff 88 fd ab fa 03 88 ff ff   ...
00 80 f3 dc 00 00 00 00 00 60 a9 dd 00 00 00 00  .`..
  backtrace:
[] create_object+0x103/0x2c0
[] kmemleak_alloc+0x82/0xc0
[] kmem_cache_alloc_trace+0x17b/0x210
[] apei_res_add+0x19a/0x200
[] apei_get_res_callback+0x1a/0x20
[] acpi_nvs_for_each_region+0x2b/0x50
[] apei_resources_request+0x95/0x380
[] erst_init+0xe2/0x3e5
[] do_one_initcall+0x19d/0x1d0
[] kernel_init_freeable+0x13d/0x1d6
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x42/0x70
[] 0x
unreferenced object 0x880402b6ede0 (size 32):
  comm "swapper/0", pid 1, jiffies 4294672863 (age 314.698s)
  hex dump (first 32 bytes):
a8 fd ab fa 03 88 ff ff a8 fd ab fa 03 88 ff ff  
00 00 00 f8 00 00 00 00 00 00 00 fc 00 00 00 00  
  backtrace:
[] create_object+0x103/0x2c0
[] kmemleak_alloc+0x82/0xc0
[] kmem_cache_alloc_trace+0x17b/0x210
[] apei_res_add+0x19a/0x200
[] apei_get_res_callback+0x1a/0x20
[] pci_mmcfg_for_each_region+0x51/0x60
[] apei_resources_request+0x34a/0x380
[] erst_init+0xe2/0x3e5
[] do_one_initcall+0x19d/0x1d0
[] kernel_init_freeable+0x13d/0x1d6
[] kernel_init+0xe/0xf0
[] ret_from_fork+0x42/0x70
[] 0x

The issue has been reported a handful of times upstream. Here is one of the 
previous
reports: https://lkml.org/lkml/2013/8/11/149

This series resolves the reported leaks and kmemleak is clean with these 
patches applied.

Changes from v1 as per Gong Chen's comments:
* Use existing apei_resources_fini calls to do the cleanup
* Update changelog in erst_init patch

Joshua Hunt (2):
  ACPI, APEI: Fix leaked resources
  ACPI, APEI, ERST: Fixed leaked resources in erst_init

 drivers/acpi/apei/apei-base.c |6 --
 drivers/acpi/apei/erst.c  |3 +++
 2 files changed, 7 insertions(+), 2 deletions(-)

-- 
1.7.9.5

RE: [PATCH V4 5/5] Microblaze: Modifying microblaze PCI subsytem to support generic Xilinx AXI PCIe Host Bridge IP driver

[Bharat Kumar Gogada]

Hi Bjorn,

Can you please take this in to your tree.

Thanks,
Bharat

> On 11.2.2016 17:28, Bharat Kumar Gogada wrote:
> > This patch does required modifications to microblaze PCI subsystem, to
> > work with generic driver (drivers/pci/host/pcie-xilinx.c) on
> > Microblaze and Zynq.
> >
> > Signed-off-by: Bharat Kumar Gogada 
> > Signed-off-by: Ravi Kiran Gummaluri 
> > ---
> > Changes:
> > Removed pcibios_get_phb_of_node in pci-common.c, using generic
> version
> > instead.
> > Modified pcibios_fixup_bus in pci-common.c, as per generic architecuture.
> > Modified pcibios_align_resource in pci-common.c, as per generic
> > architecuture, removed temporary variable.
> > Removed pci_domain_nr in pci-common.c, instead using generic code.
> > Added pcibios_add_device in pci-common.c, as per generic architecuture.
> > Adding Kernel configuration in arch/microblaze as required for generic
> > PCI domains.
> > Added kernel configuration for driver to support Microblaze.
> > ---
> >  arch/microblaze/Kconfig  |  3 +++
> >  arch/microblaze/pci/pci-common.c | 56 
> > +++---
> --
> >  drivers/pci/host/Kconfig |  2 +-
> >  3 files changed, 14 insertions(+), 47 deletions(-)
> >
> > diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig index
> > 0bce820..c3702b9 100644
> > --- a/arch/microblaze/Kconfig
> > +++ b/arch/microblaze/Kconfig
> > @@ -271,6 +271,9 @@ config PCI
> >  config PCI_DOMAINS
> > def_bool PCI
> >
> > +config PCI_DOMAINS_GENERIC
> > +   def_bool PCI_DOMAINS
> > +
> >  config PCI_SYSCALL
> > def_bool PCI
> >
> > diff --git a/arch/microblaze/pci/pci-common.c
> > b/arch/microblaze/pci/pci-common.c
> > index ae838ed..35654be 100644
> > --- a/arch/microblaze/pci/pci-common.c
> > +++ b/arch/microblaze/pci/pci-common.c
> > @@ -123,17 +123,6 @@ unsigned long pci_address_to_pio(phys_addr_t
> > address)  }  EXPORT_SYMBOL_GPL(pci_address_to_pio);
> >
> > -/*
> > - * Return the domain number for this bus.
> > - */
> > -int pci_domain_nr(struct pci_bus *bus) -{
> > -   struct pci_controller *hose = pci_bus_to_host(bus);
> > -
> > -   return hose->global_number;
> > -}
> > -EXPORT_SYMBOL(pci_domain_nr);
> > -
> >  /* This routine is meant to be used early during boot, when the
> >   * PCI bus numbers have not yet been assigned, and you need to
> >   * issue PCI config cycles to an OF device.
> > @@ -863,26 +852,10 @@ void pcibios_setup_bus_devices(struct pci_bus
> > *bus)
> >
> >  void pcibios_fixup_bus(struct pci_bus *bus)  {
> > -   /* When called from the generic PCI probe, read PCI<->PCI bridge
> > -* bases. This is -not- called when generating the PCI tree from
> > -* the OF device-tree.
> > -*/
> > -   if (bus->self != NULL)
> > -   pci_read_bridge_bases(bus);
> > -
> > -   /* Now fixup the bus bus */
> > -   pcibios_setup_bus_self(bus);
> > -
> > -   /* Now fixup devices on that bus */
> > -   pcibios_setup_bus_devices(bus);
> > +   /* nothing to do */
> >  }
> >  EXPORT_SYMBOL(pcibios_fixup_bus);
> >
> > -static int skip_isa_ioresource_align(struct pci_dev *dev) -{
> > -   return 0;
> > -}
> > -
> >  /*
> >   * We need to avoid collisions with `mirrored' VGA ports
> >   * and other strange ISA hardware, so we always want the @@ -899,20
> > +872,18 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
> > resource_size_t pcibios_align_resource(void *data, const struct resource
> *res,
> > resource_size_t size, resource_size_t align)  {
> > -   struct pci_dev *dev = data;
> > -   resource_size_t start = res->start;
> > -
> > -   if (res->flags & IORESOURCE_IO) {
> > -   if (skip_isa_ioresource_align(dev))
> > -   return start;
> > -   if (start & 0x300)
> > -   start = (start + 0x3ff) & ~0x3ff;
> > -   }
> > -
> > -   return start;
> > +   return res->start;
> >  }
> >  EXPORT_SYMBOL(pcibios_align_resource);
> >
> > +int pcibios_add_device(struct pci_dev *dev) {
> > +   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(pcibios_add_device);
> > +
> >  /*
> >   * Reparent resource children of pr that conflict with res
> >   * under res, and make res replace those children.
> > @@ -1333,13 +1304,6 @@ static void pcibios_setup_phb_resources(struct
> pci_controller *hose,
> >  (unsigned long)hose->io_base_virt - _IO_BASE);  }
> >
> > -struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus) -{
> > -   struct pci_controller *hose = bus->sysdata;
> > -
> > -   return of_node_get(hose->dn);
> > -}
> > -
> >  static void pcibios_scan_phb(struct pci_controller *hose)  {
> > LIST_HEAD(resources);
> > diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index
> > d5e58ba..7c56c2e 100644
> > --- a/drivers/pci/host/Kconfig
> > +++ b/drivers/pci/host/Kconfig
> > @@ -79,7 +79,7 @@ config PCI_KEYSTONE
> >
> >  config PCIE_XILINX
> > bool "Xilinx AXI PCIe host bridge support"
> >

Re: [PATCHv2 07/11] EDAC, altera: Add status offset & masks

[Thor Thayer]

Hi Boris,

On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

In preparation for the Arria10 peripheral ECCs, the IRQ
status needs to be determined because the IRQs are shared.
The IRQ status register is read to determine if the IRQ
was for this ECC peripheral. Cyclone5 and Arria5 have
dedicated IRQs so the confirmation mechanism is not
required and the mask is set to 0.

Signed-off-by: Thor Thayer 
---
v2: Split large patch into smaller patches. Determine
 if IRQ matches this ECC peripheral before handling it.
---
  drivers/edac/altera_edac.c |   41 +++--
  drivers/edac/altera_edac.h |3 +++
  2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index fd73a77..11b7291 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -556,19 +556,32 @@ static irqreturn_t altr_edac_device_handler(int irq, void 
*dev_id)
struct edac_device_ctl_info *dci = dev_id;
struct altr_edac_device_dev *drvdata = dci->pvt_info;
const struct edac_device_prv_data *priv = drvdata->data;
+   void __iomem *status_addr = drvdata->status + priv->err_status_ofst;
void __iomem *clear_addr = drvdata->status + priv->clear_err_ofst;

+   /*
+* CycloneV is directly mapped to a specific IRQ. Arria10
+* shares the IRQ with other ECCs so we must match first.
+*/
if (irq == drvdata->sb_irq) {
-   if (priv->ce_clear_mask)
-   writel(priv->ce_clear_mask, clear_addr);
-   edac_device_handle_ce(dci, 0, 0, drvdata->edac_dev_name);
-   ret_value = IRQ_HANDLED;
+   if (!priv->ce_status_mask ||
+   (priv->ce_status_mask & readl(status_addr))) {
+   if (priv->ce_clear_mask)
+   writel(priv->ce_clear_mask, clear_addr);
+   edac_device_handle_ce(dci, 0, 0,
+ drvdata->edac_dev_name);
+   ret_value = IRQ_HANDLED;
+   }
} else if (irq == drvdata->db_irq) {
-   if (priv->ue_clear_mask)
-   writel(priv->ue_clear_mask, clear_addr);
-   edac_device_handle_ue(dci, 0, 0, drvdata->edac_dev_name);
-   panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
-   ret_value = IRQ_HANDLED;
+   if (!priv->ue_status_mask ||
+   (priv->ue_status_mask & readl(status_addr))) {
+   if (priv->ue_clear_mask)
+   writel(priv->ue_clear_mask, clear_addr);
+   edac_device_handle_ue(dci, 0, 0,
+ drvdata->edac_dev_name);
+   panic("\nEDAC:ECC_DEVICE[Uncorrectable errors]\n");
+   ret_value = IRQ_HANDLED;
+   }
} else {
WARN_ON(1);
}



While working on subsequent ECC components to upstream, I realized that 
the above is not an optimal solution for Arria10.


The Arria10 is significantly different from the Cyclone5/Arria5 and 
therefore should be it's own implementation.


Please disregard this patch series. I'll redo the series with a 
different IRQ implementation that is cleaner - it will be closer to the 
Xgene driver.


Sorry for the noise.

Thor



@@ -882,6 +895,10 @@ const struct edac_device_prv_data ocramecc_data = {
.ce_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_SERR),
.ue_clear_mask = (ALTR_OCR_ECC_EN | ALTR_OCR_ECC_DERR),
.clear_err_ofst = ALTR_OCR_ECC_REG_OFFSET,
+   /* Cyclone5 & Arria5 have separate IRQs so status = 0 */
+   .ce_status_mask = 0,
+   .ue_status_mask = 0,
+   .err_status_ofst = 0,
.dbgfs_name = "altr_ocram_trigger",
.alloc_mem = ocram_alloc_mem,
.free_mem = ocram_free_mem,
@@ -957,7 +974,11 @@ const struct edac_device_prv_data l2ecc_data = {
.setup = altr_l2_check_deps,
.ce_clear_mask = 0,
.ue_clear_mask = 0,
-   .clear_err_ofst = ALTR_L2_ECC_REG_OFFSET,
+   .clear_err_ofst = ALTR_MAN_GRP_L2_ECC_OFFSET,
+   /* Cyclone5 & Arria5 have separate IRQs so status = 0 */
+   .ce_status_mask = 0,
+   .ue_status_mask = 0,
+   .err_status_ofst = 0,
.dbgfs_name = "altr_l2_trigger",
.alloc_mem = l2_alloc_mem,
.free_mem = l2_free_mem,
diff --git a/drivers/edac/altera_edac.h b/drivers/edac/altera_edac.h
index b262f74..43e0dae 100644
--- a/drivers/edac/altera_edac.h
+++ b/drivers/edac/altera_edac.h
@@ -226,6 +226,9 @@ struct edac_device_prv_data {
int ce_clear_mask;
int ue_clear_mask;
int clear_err_ofst;
+   int ce_status_mask;
+   int ue_status_mask;
+   int err_status_ofst;
char dbgfs_name[20];
void * (*alloc_mem)(size_t size, void **other);

Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

[Ingo Molnar]

* Dmitry Vyukov  wrote:

> > so, according to the error message it wants a writable directory. Lets try 
> > it that
> > way:
> >
> >  triton:~> mkdir go
> >  triton:~>
> >  triton:~> export GOPATH=/home/mingo/go/
> >  triton:~> go get github.com/google/syzkaller
> >  can't load package: package github.com/google/syzkaller: no buildable Go 
> > source files in /home/mingo/go/src/github.com/google/syzkaller
> 
> Yes, GOPATH needs to be set a writable dir.
> You can ignore "can't load package" error. The goal of that step is
> checkout syzkaller with all dependencies into correct dirs under
> GOPATH. That's already done by now.
> Or you can do (/... at the end):
> $ go get github.com/google/syzkaller/...
> That will checkout and build.
> Either way you can continue with the make step.

Cool, the '/...' trick works.


> > looks like someone wants 'Go' to be used as little as possible! ;-)
> 
> You probably did not observe recently a noobie trying to build a C
> project with sufficiently-complicate-build-system and a bunch of
> dependencies that needs to be on specific, unknown revisions, and that
> still does not compile with you compiler and does not link with your
> linker, and then of course target machine has a wrong glibc version :)

Nah, old Linux tools very much suck, we know that and we suffer from it.

But new tools should not suck! :-)

So, going from the description at:

http://lkml.kernel.org/r/CACT4Y+Ym0TZLkmRrM0ZGgLpu8kqS-YjoWTMrvaLz=tx2tny...@mail.gmail.com

I now have it built, and created 
$GOPATH/src/github.com/google/syzkaller/perf.cfg 
with:


triton:~/go/src/github.com/google/syzkaller> cat perf.cfg 
{
"http": "localhost:5",
"workdir": "/home/mingo/go/src/github.com/google/syzkaller/workdir",
"syzkaller": "/home/mingo/go/src/github.com/google/syzkaller",
"vmlinux": "-",
"type": "local",
"count": 1,
"procs": 16,
"nocover": true,
"nodropprivs": true,
"enable_syscalls": [
"getpid",
"perf_event_open",
"ioctl$PERF*",
"prctl$void",
"bpf$*",
"sched_yield"
]
}

Then I tried to do:

   $ bin/syz-manager -config perf.cfg

in ~/go/src/github.com/google/syzkaller, but that doesn't work because there's 
no 
'bin' directory:

  triton:~/go/src/github.com/google/syzkaller> bin/syz-manager -config perf.cfg
  bash: bin/syz-manager: No such file or directory

So that should really read something like:

  cd ~/go
  bin/syz-manager -config src/github.com/google/syzkaller/perf.cfg

next roadblock:

fomalhaut:~/go> bin/syz-manager -config src/github.com/google/syzkaller/perf.cfg
2016/03/08 16:53:44 bad config syzkaller param: can't find bin/syz-fuzzer

so how do I proceed from here?

Thanks,

Ingo

Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag callback

[Chunyu Hu]

- Original Message -
> From: "Steven Rostedt" 
> To: "Chunyu Hu" 
> Cc: li...@redhat.com, linux-kernel@vger.kernel.org
> Sent: Tuesday, March 8, 2016 11:14:51 PM
> Subject: Re: [PATCH 1/2] tracing: make tracer_flags use the right set_flag 
> callback
> 
> On Tue, 8 Mar 2016 09:54:43 -0500
> Steven Rostedt  wrote:
> 
> 
> > > Here just forbit it return an invalid code to user space with extra
> > > dmesg help info to avoid the complex WARN log.
> > 
> > This is not acceptable. The whole point of making the options visible
> > when the tracer is not active was to change the flags when the tracer
> > is not active.
> > 
> > I'll look deeper into this. Thanks.
> 
> I made the modifications to your patch. Can you please test this. I'll
> start running my own tests on it:

Sure! But my patch/build work are all manual, so I guess I can't keep with
your speed, but i will do. Thx.

> -- Steve
> 
> From: Chunyu Hu 
> 
> tracing: Make tracer_flags use the right set_flag callback
> 
> When I was updating the ftrace_stress test of ltp. I encountered
> a strange phenomemon, excute following steps:
> 
> echo nop > /sys/kernel/debug/tracing/current_tracer
> echo 0 > /sys/kernel/debug/tracing/options/funcgraph-cpu
> bash: echo: write error: Invalid argument
> 
> check dmesg:
> [ 1024.903855] nop_test_refuse flag set to 0: we refuse.Now cat trace_options
> to see the result
> 
> The reason is that the trace option test will randomly setup trace
> option under tracing/options no matter what the current_tracer is.
> but the set_tracer_option is always using the set_flag callback
> from the current_tracer. This patch adds a pointer to tracer_flags
> and make it point to the tracer it belongs to. When the option is
> setup, the set_flag of the right tracer will be used no matter
> what the the current_tracer is.
> 
> But after some tests, find it's not easy to setup tracer flag when
> its target is not the current tracer. Some check logic of function
> and function_graph trace seems not appropriate now, some WARN in
> ftrace.c are triggered.
> 
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:5106
> ftrace_init_array_ops+0x4a/0x70()
> kernel: WARNING: CPU: 2 PID: 5522 at kernel/trace/ftrace.c:413
> ftrace_startup+0x229/0x240()
> kernel: WARNING: CPU: 2 PID: 30451 at kernel/trace/ftrace.c:460
> return_to_handler+0x0/0x27()
> 
> Here just forbit it return an invalid code to user space with extra
> dmesg help info to avoid the complex WARN log.
> 
> And the old dummy_tracer_flags is used for all the tracers which
> doesn't have a tracer_flags, having issue to use it to save the
> pointer of a tracer. So remove it and use dynamic dummy tracer_flags
> for tracers needing a dummy tracer_flags, as a result, there are no
> tracers sharing tracer_flags, so remove the check code.
> 
> And save the current tracer to trace_option_dentry seems not good as
> it may waste mem space when mount the debug/trace fs more than one time.
> 
> Signed-off-by: Chunyu Hu 
> ---
>  kernel/trace/trace.c   |   21 -
>  kernel/trace/trace.h   |1 +
>  kernel/trace/trace_functions.c |6 ++
>  3 files changed, 19 insertions(+), 9 deletions(-)
> 
> Index: linux-trace.git/kernel/trace/trace.c
> ===
> --- linux-trace.git.orig/kernel/trace/trace.c 2016-03-08 10:07:51.180345420
> -0500
> +++ linux-trace.git/kernel/trace/trace.c  2016-03-08 10:07:54.365296167 
> -0500
> @@ -74,11 +74,6 @@ static struct tracer_opt dummy_tracer_op
>   { }
>  };
>  
> -static struct tracer_flags dummy_tracer_flags = {
> - .val = 0,
> - .opts = dummy_tracer_opt
> -};
> -
>  static int
>  dummy_set_flag(struct trace_array *tr, u32 old_flags, u32 bit, int set)
>  {
> @@ -1258,12 +1253,20 @@ int __init register_tracer(struct tracer
>  
>   if (!type->set_flag)
>   type->set_flag = &dummy_set_flag;
> - if (!type->flags)
> - type->flags = &dummy_tracer_flags;
> - else
> + if (!type->flags) {
> + /*allocate a dummy tracer_flags*/
> + type->flags = kmalloc(sizeof(*type->flags), GFP_KERNEL);
> + if (!type->flags)
> + return -ENOMEM;
> + type->flags->val = 0;
> + type->flags->opts = dummy_tracer_opt;
> + } else
>   if (!type->flags->opts)
>   type->flags->opts = dummy_tracer_opt;
>  
> + /* store the tracer for __set_tracer_option */
> + type->flags->trace = type;
> +
>   ret = run_tracer_selftest(type);
>   if (ret < 0)
>   goto out;
> @@ -3505,7 +3508,7 @@ static int __set_tracer_option(struct tr
>  struct tracer_flags *tracer_flags,
>  struct tracer_opt *opts, int neg)
>  {
> - struct tracer *trace = tr->current_trace;
> + struct tracer *trace = tracer_flags->trace;
>   int ret;
>  
>   ret = tra

Re: [PATCHv2 11/11] ARM: dts: Add Altera Arria10 L2 Cache EDAC devicetree entry

[Thor Thayer]

Hi Dinh,

On 03/08/2016 08:50 AM, Dinh Nguyen wrote:



On 03/07/2016 01:43 PM, ttha...@opensource.altera.com wrote:

From: Thor Thayer 

Add the device tree entries needed to support the Altera L2
cache EDAC on the Arria10 chip.

Signed-off-by: Thor Thayer 
---
v2 Match register value (l2-ecc@ffd06010)
---
  arch/arm/boot/dts/socfpga_arria10.dtsi |   14 ++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi 
b/arch/arm/boot/dts/socfpga_arria10.dtsi
index cce9e50..44aeb3f 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -599,6 +599,20 @@
reg = <0xffe0 0x4>;
};

+   eccmgr: eccmgr@ffd06090 {
+   compatible = "altr,socfpga-ecc-manager";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2-ecc@ffd06010 {
+   compatible = "altr,socfpga-a10-l2-ecc";
+   reg = <0xffd06010 0x4>;
+   interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>,
+<0 0 IRQ_TYPE_LEVEL_HIGH>;
+   };
+   };
+


Just checking if these addresses are correct. The eccmgr is at
0xffd06090, but the l2-ecc is at 0xffd06010? I would have thought from
the placement the l2-ecc address would be inside the eccmgr's address?

Dinh



Yes, this is confusing and I'll clarify/reorganize in the next series. 
The eccmgr is pointing to the ECC IRQ mask bits. These registers and the 
L2 ECC registers are organized in different areas within the system manager.


I'm actually redoing the series since the Arria10 IRQ handling is 
significantly different.


Since this change will affect the bindings and dti (the eccmgr will have 
the IRQs), please disregard this series.


Sorry for the noise.

Thor

Re: linux-next: manual merge of the watchdog tree with the arm-soc tree

[André Przywara]

On 07/03/16 11:04, Stephen Rothwell wrote:
> Hi Wim,
> 
> Today's linux-next merge of the watchdog tree got a conflict in:
> 
>   arch/arm64/boot/dts/arm/foundation-v8.dts
> 
> between commit:
> 
>   d11a89796678 ("arm64: dts: split Foundation model dts to put the GIC 
> separately")
> 
> from the arm-soc tree and commit:
> 
>   fe3a97e8ed02 ("ARM64: add SBSA Generic Watchdog device node in 
> foundation-v8.dts")
> 
> from the watchdog tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

But unfortunately this is the wrong solution. The watchdog DT node
belongs into the (newly created) common foundation-v8.dtsi, not into the
GICv2-only .dts.
So whoever now provides the watchdog patch, can it be rebased on top of
the foundation model .dts rework, so that the new node ends up in the
.dtsi file?
If this is too much hassle I could also send a fix after -rc1 (as the
breakage is not really critical).

Cheers,
Andre.