Re: [PATCH] Fix northbridge quirk to assign correct NUMA node

[Daniel J Blueman]

On 03/22/2014 12:11 AM, Bjorn Helgaas wrote:

[+cc Rafael, linux-acpi for _PXM questions]

On Thu, Mar 20, 2014 at 9:38 PM, Daniel J Blueman  wrote:

On 21/03/2014 06:07, Bjorn Helgaas wrote:

On Thu, Mar 13, 2014 at 5:43 AM, Daniel J Blueman 
wrote:


For systems with multiple servers and routed fabric, all northbridges get
assigned to the first server. Fix this by also using the node reported
from
the PCI bus. For single-fabric systems, the northbriges are on PCI bus 0
by definition, which are on NUMA node 0 by definition, so this is
invarient
on most systems.

Tested on fam10h and fam15h single and multi-fabric systems and candidate
for stable.



So I suspect the problem is more complicated, and maybe _PXM is
insufficient to describe the topology?  Are there subtrees that should
have nodes different from the host bridge?


Yes; see below.
...
The _PXM method associates each northbridge with the first NUMA node, 0 in
single-fabric systems, and eg 4 for the second server in a multi-fabric
system with 2 dual-module Opterons (with 2 NUMA nodes internally) etc, since
the northbridges appear in the PCI tree, under the host bridge, not above it
[1].

With _PXM, the rest of the PCI bus hierarchy has the right NUMA node
associated, but the northbridge PCI devices should be associated with their
actual NUMA node, 0, 1, 2, 3 for the first server in this example. The quirk
fixes this up; irqbalance at least uses this NUMA data exposed in /sys.


I'm confused about which devices we're talking about.  We currently
look at _PXM for PNP0A08 (and PNP0A03) ACPI devices.  The resulting
node is associated with every PCI device we enumerate below the
PNP0A08 bridge.  This association is made in pci_device_add().

When you say "northbridge PCI devices should be associated with their
actual NUMA node," I assume you mean the 00:18.x and 00:19.x devices
("AMD Family 10h Processor ..."), since those seem to be what the
quirk applies to.  You are *not* talking about 00:00.0 ("ATI RD890
Northbridge"), right?


Yes, on bus 0, devices 0x18 to 0x20 decode to the (up to) eight 
Hypertransport devices in the processor fabric, normally all processor 
northbridges.



You mention irqbalance; is the NUMA node information for the 00:18.x
and 00:19.x devices important because you get a lot of interrupts from
those devices?  Or is the issue with actual I/O devices (NICs, SCSI
adapters, etc.)?  If so, I don't see how this quirk would affect
those, because the node information for them comes from the PNP0A08
bridge (in pci_device_add()), not from the 00:00.0, 00:18.x, or
00:19.x devices.


I need to investigate the lockups irqbalance was causing on a customer 
system, and am not sure what interrupt source that was rewritten which 
causing hangs; disabling the daemon prevented the hangs.



The alternative to the quirk may be to explicitly express the northbridge
PCI devices in the AML with their own _PXM methods. If it's valid, it may be
the honest approach, though the quirk may be needed for most BIOSs; I can
check the AML on a few servers to confirm if helpful.


ACPI allows _PXM for any device, so this might be a possible approach.
  However, it looks like Linux only pays attention to _PXM for
PNP0A08/03, CPUs, memory and IOAPICs (which seems like a Linux defect
to me).



I'm really worried about the approach here:

 pci_read_config_dword(nb_ht, 0x60, &val);
 node = pcibus_to_node(dev->bus) | (val & 7);

because the pcibus_to_node() information comes indirectly from _PXM,
and the "val" part comes from the hardware, and I don't think these
are the same node number space.  If I understand correctly, the BIOS
can synthesize whatever numbers it wants for _PXM, which returns a
"proximity domain," and then Linux can make up its own mapping of
"proximity domain" to "logical Linux node."  So I don't see why we can
assume that it's valid to OR in the bits from a PCI config register to
this logical Linux node number.


pcibus_to_node uses the proximity domain values in the ACPI SRAT table, 
which is thus correctly mapped to the linux NUMA node ID, so my oneliner 
is still progress.


Linux allocates NUMA node ids using the ordering of PXM values seen in 
the SRAT table, ie first_unset_node(nodes_found_map). The APIC ids are 
initialised using the HyperTransport NodeId [1, p263 and p465], but the 
NodeId can be reprogrammed after the APIC ids are set (which also 
changes the PCI configuration device id from 0x18 on bus 0 it responds 
to), and the SRAT table needn't be emitted in order, perhaps except for 
the bootstrap core.


I guess fixing the original quirk depends on how important these cases 
really are.


Thanks,
  Daniel

[1] http://support.amd.com/TechDocs/42301_15h_Mod_00h-0Fh_BKDG.pdf
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordo

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Viresh Kumar]

On 24 March 2014 12:17, Lukasz Majewski  wrote:
> Viresh, will you find time for reviewing this RFC in a near future?

Yes. I have been trying hard last week but couldn't find some time
for it. Will try this week for sure.. Sorry to keep you waiting :(

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

Re: [patch 00/16] timers: Plug debugobject leaks and use del_timer_sync() in exit/teardown

[Julia Lawall]

On Mon, 24 Mar 2014, Thomas Gleixner wrote:

> On Sun, 23 Mar 2014, Julia Lawall wrote:
> > As far as I could tell, (part of) the issue is that any kind of exit or 
> > close function should use del_timer_sync, because they could be called 
> > from a different CPU than the one that started up the timer?
> > 
> > Here is a semantic patch that takes care of the case of simple module_exit 
> > functions:
> > 
> > @r@
> > declarer name module_exit;
> > identifier ex;
> > @@
> > 
> > module_exit(ex);
> > 
> > @@
> > identifier r.ex;
> > @@
> > 
> > ex(...) {
> >   <...
> > - del_timer
> > + del_timer_sync
> > (...)
> >   ...>
> > }
> > 
> > The transformations it makes are below.  I haven't had a chance to check 
> > which results overlap with what Thomas has already sent, but I could look 
> 
> Minimal overlap, but as I said I did just a few conversions.
> 
> > into it if this is the right idea.  I guess other kinds of close/exit 
> > functions would have to be identified manually, to make more rules.
> 
> If you look through the examples I sent, you'll find the close()
> callbacks of various devices. So everything which is a function
> pointer to a ops->close(), ops->remove(), ops_>teardown() is dangerous
> if using del_timer(). There are a few exceptions, but
> 
> Another thing I saw is 
> 
>   del_timer(&bla->timer);
>   
>   kfree(&bla);
> 
> That's also a potential source of trouble. You can't tell without
> analyzing the code, whether it's a problem or not. But making the
> responsible people to look at it is definitely a good thing.
>  
> > In what circumstance can one be sure that two instructions are executed on 
> > the same CPU?
> 
> If interrupts or preemption are disabled. But that's not the issue at
> hand.
> 
> The del_timer vs. del_timer_sync problem is:
> 
> CPU0   CPU1
> 
> add_timer(&bla->timer);
> 
>close(bla)
> timer expiresdel_timer(&bla->timer);
>   callback is invoked
>  kfree(bla);
> derefernces bla
> 
> I'll look at your findings on Tuesday, but feel free to send them to
> the relevant maintainers for review.

Thanks for all of the suggestions!

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

Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized

[Srivatsa S. Bhat]

On 03/21/2014 11:37 PM, Catalin Marinas wrote:
> On Fri, Mar 21, 2014 at 11:24:16AM +, Srivatsa S. Bhat wrote:
>> On 03/21/2014 04:35 PM, Catalin Marinas wrote:
>>> On Fri, Mar 21, 2014 at 09:21:02AM +, Viresh Kumar wrote:
 @Catalin: We have a problem here and need your expert advice. After 
 changing
 CPU frequency we need to call this code:

 cpufreq_notify_post_transition();
 policy->transition_ongoing = false;

 And the sequence must be like this only. Is this guaranteed without any
 memory barriers? cpufreq_notify_post_transition() isn't touching
 transition_ongoing at all..
>>>
>>> The above sequence doesn't say much. As rmk said, the compiler wouldn't
>>> reorder the transition_ongoing write before the function call. I think
>>> most architectures (not sure about Alpha) don't do speculative stores,
>>> so hardware wouldn't reorder them either. However, other stores inside
>>> the cpufreq_notify_post_transition() could be reordered after
>>> transition_ongoing store. The same for memory accesses after the
>>> transition_ongoing update, they could be reordered before.
>>>
>>> So what we actually need to know is what are the other relevant memory
>>> accesses that require strict ordering with transition_ongoing.
>>
>> Hmm.. The thing is, _everything_ inside the post_transition() function
>> should complete before writing to transition_ongoing. Because, setting the
>> flag to 'false' indicates the end of the critical section, and the next
>> contending task can enter the critical section.
> 
> smp_mb() is all about relative ordering. So if you want memory accesses
> in post_transition() to be visible to other observers before
> transition_ongoing = false, you also need to make sure that the readers
> of transition_ongoing have a barrier before subsequent memory accesses.
> 

The reader takes a spin-lock before reading the flag.. won't that suffice?

+wait:
+   wait_event(policy->transition_wait, !policy->transition_ongoing);
+
+   spin_lock(&policy->transition_lock);
+
+   if (unlikely(policy->transition_ongoing)) {
+   spin_unlock(&policy->transition_lock);
+   goto wait;
+   }

>>> What I find strange in your patch is that
>>> cpufreq_freq_transition_begin() uses spinlocks around transition_ongoing
>>> update but cpufreq_freq_transition_end() doesn't.
>>
>> The reason is that, by the time we drop the spinlock, we would have set
>> the transition_ongoing flag to true, which prevents any other task from
>> entering the critical section. Hence, when we call the _end() function,
>> we are 100% sure that only one task is executing it. Hence locks are not
>> necessary around that second update. In fact, that very update marks the
>> end of the critical section (which acts much like a spin_unlock(&lock)
>> in a "regular" critical section).
> 
> OK, I start to get it. Is there a risk of missing a wake_up event? E.g.
> one thread waking up earlier, noticing that transition is in progress
> and waiting indefinitely?
>

No, the only downside to having the CPU reorder the assignment to the
flag is that a new transition can begin while the old one is still
finishing up the frequency transition by calling the _post_transition()
notifiers.

Regards,
Srivatsa S. Bhat

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

[PATCH] cpufreq: set value of CPUFREQ_BOOST_FREQ to 0xABABABAB

[Viresh Kumar]

Ideally, .driver_data field of struct cpufreq_frequency_table must not be used
by core at all. But during a recent change if its value is same as
CPUFREQ_BOOST_FREQ macro, then it is treated specially by core.

The value of this macro was set to ~2 earlier, i.e. 0xFFFD. In case some
driver is using this field for its own data and sets this field to -3, then with
two's complement that value will also become 0xFFFD.

To fix this issue, lets change value of this flag to a very uncommon value which
shouldn't be used by any driver unless they want to use BOOST feature.

Along with this update comments to make this more clear.

Signed-off-by: Viresh Kumar 
---

Gautham/Vaidy: I hope this fixes the problem we discussed for your patchset.

 include/linux/cpufreq.h | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index c48e595..9f25d9d 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -455,12 +455,18 @@ extern struct cpufreq_governor cpufreq_gov_conservative;
  * FREQUENCY TABLE HELPERS   *
  */
 
+/* Special Values of .frequency field */
 #define CPUFREQ_ENTRY_INVALID ~0
 #define CPUFREQ_TABLE_END ~1
-#define CPUFREQ_BOOST_FREQ~2
+/* Special Values of .driver_data field */
+#define CPUFREQ_BOOST_FREQ0xABABABAB
 
 struct cpufreq_frequency_table {
-   unsigned intdriver_data; /* driver specific data, not used by core 
*/
+   /*
+* driver specific data, not used by core unless it is set to
+* CPUFREQ_BOOST_FREQ.
+*/
+   unsigned intdriver_data;
unsigned intfrequency; /* kHz - doesn't need to be in ascending
* order */
 };
-- 
1.7.12.rc2.18.g61b472e

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

Re: [RFC v3 0/5] cpufreq:LAB: Support for LAB governor.

[Lukasz Majewski]

Hi Viresh,

> Hi Viresh,
> 
> > On 17 March 2014 21:08, Lukasz Majewski 
> > wrote:
> > >> Despite this patch set is working and applicable on top of
> > >> 3.14-rc5, please regard it solely as a pure RFC.
> > >>
> > >> This patch provides support for LAB governor build on top of
> > >> ondemand. Previous version of LAB can be found here:
> > >> http://thread.gmane.org/gmane.linux.kernel/1484746/match=cpufreq
> > >>
> > >> LAB short reminder:
> > >>
> > >> LAB uses information about how many cores are in "idle" state
> > >> (the core idleness is represented as the value between 0 and
> > >> 100) and the overall load of the system (from 0 to 100) to
> > >> decide about frequency to be set. It is extremely useful with
> > >> SoCs like Exynos4412, which can set only one frequency for all
> > >> cores.
> > >>
> > >> Important design decisions:
> > >>
> > >> - Reuse well established ondemand governor's internal code. To do
> > >> this I had to expose some previously static internal ondemand
> > >> code. This allowed smaller LAB code when compared to previous
> > >> version.
> > >>
> > >> - LAB works on top of ondemand, which means that one via device
> > >> tree attributes can specify if and when e.g. BOOST shall be
> > >> enabled or if any particular frequency shall be imposed. For
> > >> situation NOT important from the power consumption reduction
> > >> viewpoint the ondemand is used to set proper frequency.
> > >>
> > >> - It is only possible to either compile in or not the LAB into
> > >> the kernel. There is no "M" option for Kconfig. It is done on
> > >> purpose, since ondemand itself can be also compiled as a module
> > >> and then it would be possible to remove ondemand when LAB is
> > >> working on top of it.
> > >>
> > >> - The LAB operation is specified (and thereof extendable) via
> > >> device tree lab-ctrl-freq attribute defined at /cpus/cpu0.
> > >>
> > >>
> > >> Problems:
> > >> - How the governor will work for big.LITTLE systems (especially
> > >> Global Task Scheduling).
> > >> - Will there be agreement to expose internal ondemand code to be
> > >> reused for more specialized governors.
> > >>
> > >> Test HW:
> > >>   Exynos4412 - Trats2 board.
> > >> Above patches were posted on top of Linux 3.14-rc5
> > >> (SHA1: 3f9590c281c66162bf8ae9b7b2d987f0a89043c6)
> > >>
> > >
> > > Any comments about those patches?
> > 
> > Sorry for being late on reviewing these..
> > 
> > I tried to go through the patches but didn't looked at the minutest
> > of the details. Its been a long time when you first sent this
> > patchset. And the memories have corrupted by now :) ..
> 
> Unfortunately memory is volatile ... since LAB governor is a follow up
> of BOOST, which review and inclusion took considerable time, some
> details could be forgotten. 
> 
> > 
> > To get context back, can we discuss again the fundamentals behind
> > this new governor you are proposing. And then we can discuss about
> > it again, its pros/cons, etc..
> 
> Please consider following links:
> 
> The original implementation - threads:
> http://thread.gmane.org/gmane.linux.power-management.general/32523/match=lab
> http://thread.gmane.org/gmane.linux.kernel/1484746/match=lab
> 
> 
> LAB justification data:
> http://article.gmane.org/gmane.linux.kernel/1472381
> 
> 
> > People are reluctant in getting another governor in and want to give
> > existing governors a try if possible.
> 
> As I've stated in the covering letter, this code is an extension of
> Ondemand.
> 
> This is totally different from what have been posted previously (v1,
> v2).
> The first LAB proposal was written with some parts copied from
> Ondemand. It was a separate, standalone governor.
> 
> 
> The approach proposed in those patches is very different. It simply
> reuses Ondemand code as much as possible (timers, default attributes
> exported to sysfs, etc.).
> 
> On top of the Ondemand we have the LAB, which thereof is its optional
> extension. The existing code is reused and can be easily extracted as
> a common code.
> 
> > 
> > So, please explain the basics behind your governor again and then
> > we can put our arguments again..
> > 
> 
> I hope that provided overview is sufficient. More in depth
> information can be found in posted patches or provided LKML archives.
> 

Viresh, will you find time for reviewing this RFC in a near future?

> > --
> > viresh
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

On Mon, 24 Mar 2014 17:23:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the akpm-current tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from include/linux/mm.h:897:0,
>  from include/linux/mman.h:4,
>  from arch/powerpc/kernel/asm-offsets.c:22:
> include/linux/vmstat.h: In function '__count_vm_event':
> include/linux/vmstat.h:36:2: error: implicit declaration of function 
> 'raw_cpu_inc' [-Werror=implicit-function-declaration]
>   raw_cpu_inc(vm_event_states.event[item]);
>   ^
> include/linux/vmstat.h: In function '__count_vm_events':
> include/linux/vmstat.h:46:2: error: implicit declaration of function 
> 'raw_cpu_add' [-Werror=implicit-function-declaration]
>   raw_cpu_add(vm_event_states.event[item], delta);
>   ^
> 
> Caused by commit "vmstat: use raw_cpu_ops to avoid false positives on
> preemption checks".
> 
> My kernel (even going back to v3.13) has no reference to
> raw_cpu_inc/add ... missed patch?  Ah, ha percpu-add-raw_cpu_ops.patch
> etc are in the later part of the series :-(
> 
> I just reverted "vmstat: use raw_cpu_ops to avoid false positives on
> preemption checks" and
> "vmstat-use-raw_cpu_ops-to-avoid-false-positives-on-preemption-checks-fix"
> for today.

I added them back at the end of the akpm tree (as part of the merge
commit, so you can't easily see them :-().

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


pgp6TxJMIscpi.pgp
Description: PGP signature

Re: [PATCH v6 2/2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support

[Jassi Brar]

On Tue, Mar 18, 2014 at 12:36 AM, Srikanth Thokala  wrote:

> +
> +/**
> + * xilinx_vdma_prep_slave_sg - prepare a descriptor for a DMA_SLAVE 
> transaction

Should be xilinx_vdma_dma_prep_interleaved here.

> +/**
> + * xilinx_vdma_channel_set_config - Configure VDMA channel
> + * Run-time configuration for Axi VDMA, supports:
> + * . halt the channel
> + * . configure interrupt coalescing and inter-packet delay threshold
> + * . start/stop parking
> + * . enable genlock
> + *
> + * @dchan: DMA channel
> + * @cfg: VDMA device configuration pointer
> + *
> + * Return: '0' on success and failure value on error
> + */
> +int xilinx_vdma_channel_set_config(struct dma_chan *dchan,
> +   struct xilinx_vdma_config *cfg)
> +{
> +   struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> +   u32 dmacr;
> +
> +   if (cfg->reset)
> +   return xilinx_vdma_chan_reset(chan);
> +
> +   dmacr = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR);
> +
> +   chan->config.frm_dly = cfg->frm_dly;
> +   chan->config.park = cfg->park;
> +
> +   /* genlock settings */
> +   chan->config.gen_lock = cfg->gen_lock;
> +   chan->config.master = cfg->master;
> +
> +   if (cfg->gen_lock && chan->genlock) {
> +   dmacr |= XILINX_VDMA_DMACR_GENLOCK_EN;
> +   dmacr |= cfg->master << XILINX_VDMA_DMACR_MASTER_SHIFT;
> +   }
> +
> +   chan->config.frm_cnt_en = cfg->frm_cnt_en;
> +   if (cfg->park)
> +   chan->config.park_frm = cfg->park_frm;
> +   else
> +   chan->config.park_frm = -1;
> +
> +   chan->config.coalesc = cfg->coalesc;
> +   chan->config.delay = cfg->delay;
> +
> +   if (cfg->coalesc <= XILINX_VDMA_DMACR_FRAME_COUNT_MAX) {
> +   dmacr |= cfg->coalesc << XILINX_VDMA_DMACR_FRAME_COUNT_SHIFT;
> +   chan->config.coalesc = cfg->coalesc;
> +   }
> +
> +   if (cfg->delay <= XILINX_VDMA_DMACR_DELAY_MAX) {
> +   dmacr |= cfg->delay << XILINX_VDMA_DMACR_DELAY_SHIFT;
> +   chan->config.delay = cfg->delay;
> +   }
> +
> +   /* FSync Source selection */
> +   dmacr &= ~XILINX_VDMA_DMACR_FSYNCSRC_MASK;
> +   dmacr |= cfg->ext_fsync << XILINX_VDMA_DMACR_FSYNCSRC_SHIFT;
> +
> +   vdma_ctrl_write(chan, XILINX_VDMA_REG_DMACR, dmacr);
> +
> +   return 0;
> +}
> +EXPORT_SYMBOL(xilinx_vdma_channel_set_config);
> +
Bypassing the DMAEngine api doesn't seem very neat.
Is there currently any client driver that /changes/ this configuration
between channel requests? If no, then simply get the configuration
from DT node and avoid this api.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net] virtio-net: don't free skb immediately on kick failure

[Michael S. Tsirkin]

On Mon, Mar 24, 2014 at 01:31:57PM +0800, Jason Wang wrote:
> On 03/23/2014 07:27 PM, Michael S. Tsirkin wrote:
> > On Fri, Mar 21, 2014 at 04:30:01PM +0800, Jason Wang wrote:
> >> We free the skb immediately on kick failure during xmit without detaching 
> >> it
> >> from the virtqueue. This may lead double free for the skb during
> >> free_unused_bufs(). This patch fixes this by not freeing it on kick 
> >> failure and
> >> let it to be freed through free_unused_bufs().
> >>
> >> Fixes 67975901183799af8e93ec60e322f9e2a1940b9b
> >> ("virtio_net: verify if virtqueue_kick() succeeded").
> > It's not even obvious we want to increment fifo errors
> > counter.
> > So basically we want to ignore these errors.
> > In that case how about just reverting this chunk
> > of the patch?
> 
> Sure, I think it's safe to do this.
> > Seems cleaner than adding more code.
> >
> > The chunk filling in RX also seems inappropriate:
> > it will cause RX work to be requeued which isn't what
> > we wanted.
> 
> True, we can also ignore the error here.

So let's do that - just revert most of that commit
except the bit that breaks out of look when we submit commands.

> >
> > Also, what happens with virtnet_send_command?
> 
> Looks ok, if vq is broken it will return error to the caller or jump out
> of the busy loop.
> > Looks like that patch is completely wrong.
> >
> >> Cc: Rusty Russell 
> >> Cc: Michael S. Tsirkin 
> >> Cc: Heinz Graalfs 
> >> Signed-off-by: Jason Wang 
> >> ---
> >>  drivers/net/virtio_net.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> >> index 5632a99..d833d38 100644
> >> --- a/drivers/net/virtio_net.c
> >> +++ b/drivers/net/virtio_net.c
> >> @@ -882,8 +882,10 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
> >> struct net_device *dev)
> >>if (net_ratelimit())
> >>dev_warn(&dev->dev,
> >> "Unexpected TXQ (%d) queue failure: %d\n", 
> >> qnum, err);
> >> -  dev->stats.tx_dropped++;
> >> -  kfree_skb(skb);
> >> +  if (err) {
> >> +  dev->stats.tx_dropped++;
> >> +  kfree_skb(skb);
> >> +  }
> >>return NETDEV_TX_OK;
> >>}
> >>  
> >> -- 
> >> 1.8.3.2
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

In file included from include/linux/mm.h:897:0,
 from include/linux/mman.h:4,
 from arch/powerpc/kernel/asm-offsets.c:22:
include/linux/vmstat.h: In function '__count_vm_event':
include/linux/vmstat.h:36:2: error: implicit declaration of function 
'raw_cpu_inc' [-Werror=implicit-function-declaration]
  raw_cpu_inc(vm_event_states.event[item]);
  ^
include/linux/vmstat.h: In function '__count_vm_events':
include/linux/vmstat.h:46:2: error: implicit declaration of function 
'raw_cpu_add' [-Werror=implicit-function-declaration]
  raw_cpu_add(vm_event_states.event[item], delta);
  ^

Caused by commit "vmstat: use raw_cpu_ops to avoid false positives on
preemption checks".

My kernel (even going back to v3.13) has no reference to
raw_cpu_inc/add ... missed patch?  Ah, ha percpu-add-raw_cpu_ops.patch
etc are in the later part of the series :-(

I just reverted "vmstat: use raw_cpu_ops to avoid false positives on
preemption checks" and
"vmstat-use-raw_cpu_ops-to-avoid-false-positives-on-preemption-checks-fix"
for today.

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


pgpb69QGJc7EP.pgp
Description: PGP signature

Re: [patch 03/16] s390: net: lcs: Add missing destroy_timer_on_stack()

[Heiko Carstens]

On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote:
> Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled.


>  drivers/s390/net/lcs.c |1 +
>  1 file changed, 1 insertion(+)
> 
> Index: tip/drivers/s390/net/lcs.c
> ===
> --- tip.orig/drivers/s390/net/lcs.c
> +++ tip/drivers/s390/net/lcs.c
> @@ -899,6 +899,7 @@ lcs_send_lancmd(struct lcs_card *card, s
>   add_timer(&timer);
>   wait_event(reply->wait_q, reply->received);
>   del_timer_sync(&timer);
> + destroy_timer_on_stack(&timer);

Applied, thanks.

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

Re: [patch 02/16] s390: tape: Add missing destroy_timer_on_stack()

[Heiko Carstens]

On Sun, Mar 23, 2014 at 03:09:25PM -, Thomas Gleixner wrote:
> Otherwise we leak a tracking object when DEBUG_OBJECTS is enabled.
> 

[...]

>   del_timer_sync(&timeout);
> + destroy_timer_on_stack(&timeout);

Applied, thanks.

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

Re: [PATCH] drivers/net: Use RCU_INIT_POINTER(x, NULL) in tun.c

[Michael S. Tsirkin]

On Sun, Mar 23, 2014 at 10:25:27PM -0700, Eric Dumazet wrote:
> On Mon, 2014-03-24 at 07:09 +0200, Michael S. Tsirkin wrote:
> 
> > Seems an incredibly strict requirement for something that just
> > silences a warning.
> > What exactly should I test?
> > I intended to just verify this produces same code as before
> > d322f45ceed525daa under a recent gcc.
> 
> Thats because many rcu_assign_pointer(X, NULL) were already converted to
> RCU_INIT_POINTER(X, NULL)
> 
> Quite frankly I don't know why you bother at all.
> 
> Adding back the lazy test in rcu_assign_pointer() doesn't help to make
> the API cleaner and easier to understand.
> 
> People are usually using RCU API without really understanding
> all the issues. They tend to add superfluous barriers because they feel
> better. 

Cute.  This is exactly what d322f45ceed525daa did actually -
made the barrier unconditional even when not needed.

> Having separate RCU_INIT_POINTER() and rcu_assign_pointer() serve as
> better documentation of the code, I find it more easier to immediately
> check what is going on while reviewing stuff.
> 
> Presumably, checkpatch.pl could be augmented to suggest to use
> RCU_INIT_POINTER(X, NULL) instead of rcu_assign_pointer(X, NULL)
> 
> 


What happens if someone then changes that NULL to something else?
Things will start to break in subtle way, won't they?

To me RCU_INIT_POINTER seems to say "safe to use when initializing
pointer field when no one can access the structure".
The patch that started it all changed a path that clearly
does not satisfy this: it is mutating a field not initializing
it before use. After looking at the implementation, it does
seem safe.  So if some people actually like this API, I don't mind.
A matter of taste I guess.

If someone still wants to make rcu_assign_pointer more optimal, without
a warning, I see a cleaner way to do this now, below.
Lightly tested - if someone sees value in this but requires more testing, let 
me know,
if no one responds I'll just drop the whole thing.

--->

rcu: optimize rcu_assign_pointer with NULL

The rcu_assign_pointer() dropped __builtin_constant_p check to
avoid a compiler warning, but we can actually work around it
using an inline wrapper, without adding code.

Signed-off-by: Michael S. Tsirkin 

---

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 72bf3a0..0d45b6d 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -585,9 +585,18 @@ static inline void rcu_preempt_sleep_check(void)
  * please be careful when making changes to rcu_assign_pointer() and the
  * other macros that it invokes.
  */
+/* The inline wrapper is here to prevent gcc from emitting a warning when
+ * passed a pointer to a variable.
+ */
+static inline _rcu_safe_smp_wmb_unless_null(const void *v)
+{
+   if (!__builtin_constant_p(v) || ((v) != NULL))
+   smp_wmb();
+}
+
 #define rcu_assign_pointer(p, v) \
do { \
-   smp_wmb(); \
+   _rcu_safe_smp_wmb_unless_null((__force const void *)(v)); \
ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
} while (0)
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/16] s390: tape: Use del_timer_sync()

[Heiko Carstens]

On Sun, Mar 23, 2014 at 03:09:24PM -, Thomas Gleixner wrote:
> del_timer() does not wait for a possible running callback to
> complete. So the call side might free request and the associated
> objects while on another cpu the timer handler runs.

[...]

>  
> - del_timer(&timeout);
> + del_timer_sync(&timeout);

Applied, thanks.

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

Re: [PATCH V2] mmc: sdhci: don't read cd-gpio while holding spinlock

[Adrian Hunter]

On 24.03.2014 03:43, Andrew Bresticker wrote:
> sdhci_request() and sdhci_card_event() read the cd-gpio via
> mmc_gpio_get_cd(), which can sleep, while holding host->lock.
> This may result in the following BUG:
> 
>   BUG: spinlock wrong CPU on CPU#2, kworker/u8:16/4296
>   lock: 0xea6b9c80, .magic: dead4ead, .owner: kworker/u8:16/4296, .owner_cpu: > 0
>   CPU: 2 PID: 4296 Comm: kworker/u8:16 Tainted: G C   3.10.18 #137
>   Workqueue: kmmcd mmc_rescan
>   [<8020cf8c>] (unwind_backtrace+0x0/0x118) from [<8020a0c8>] 
> (show_stack+0x20/0x24)
>   [<8020a0c8>] (show_stack+0x20/0x24) from [<8075e5b8>] (dump_stack+0x20/0x28)
>   [<8075e5b8>] (dump_stack+0x20/0x28) from [<804184a8>] (spin_dump+0x80/0x94)
>   [<804184a8>] (spin_dump+0x80/0x94) from [<804184e8>] (spin_bug+0x2c/0x30)
>   [<804184e8>] (spin_bug+0x2c/0x30) from [<80418790>] 
> (do_raw_spin_unlock+0x94/0xd4)
>   [<80418790>] (do_raw_spin_unlock+0x94/0xd4) from [<80761a44>] 
> (_raw_spin_unlock_irqrestore+0x1c/0x24)
>   [<80761a44>] (_raw_spin_unlock_irqrestore+0x1c/0x24) from [<805ff66c>] 
> (sdhci_request+0x1c8/0x1d0)
>   [<805ff66c>] (sdhci_request+0x1c8/0x1d0) from [<805ebb5c>] 
> (mmc_start_request+0xec/0xf4)
>   [<805ebb5c>] (mmc_start_request+0xec/0xf4) from [<805ebcbc>] 
> (mmc_wait_for_req+0x80/0xf4)
>   ...
> 
> Read the cd-gpio before acquiring the spinlock instead.
> 
> Signed-off-by: Andrew Bresticker 
> ---
>  drivers/mmc/host/sdhci.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 04a5e25..328b250 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1340,6 +1340,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
> mmc_request *mrq)
>   u32 tuning_opcode;
>  
>   host = mmc_priv(mmc);
> + present = mmc_gpio_get_cd(host->mmc);
>  
>   sdhci_runtime_pm_get(host);
>  
> @@ -1371,7 +1372,6 @@ static void sdhci_request(struct mmc_host *mmc, struct 
> mmc_request *mrq)
>* zero: cd-gpio is used, and card is removed
>* one: cd-gpio is used, and card is present
>*/
> - present = mmc_gpio_get_cd(host->mmc);
>   if (present < 0) {
>   /* If polling, assume that the card is always present. */
>   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
> @@ -2082,15 +2082,16 @@ static void sdhci_card_event(struct mmc_host *mmc)
>  {
>   struct sdhci_host *host = mmc_priv(mmc);
>   unsigned long flags;
> + int present;
>  
>   /* First check if client has provided their own card event */
>   if (host->ops->card_event)
>   host->ops->card_event(host);
>  
> + present = sdhci_get_cd(mmc);

Shouldn't that be sdhci_do_get_cd(mmc) ?

>   spin_lock_irqsave(&host->lock, flags);
>  
> - /* Check host->mrq first in case we are runtime suspended */
> - if (host->mrq && !sdhci_do_get_cd(host)) {
> + if (host->mrq && !present) {
>   pr_err("%s: Card removed during transfer!\n",
>   mmc_hostname(host->mmc));
>   pr_err("%s: Resetting controller.\n",
> 

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

Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized

[Viresh Kumar]

On 21 March 2014 16:35, Catalin Marinas  wrote:
> The above sequence doesn't say much. As rmk said, the compiler wouldn't
> reorder the transition_ongoing write before the function call. I think
> most architectures (not sure about Alpha) don't do speculative stores,
> so hardware wouldn't reorder them either. However, other stores inside
> the cpufreq_notify_post_transition() could be reordered after
> transition_ongoing store. The same for memory accesses after the
> transition_ongoing update, they could be reordered before.

I got confused again. If we see what cpufreq_notify_post_transition() does:
Just calling a list of routines from a notifiers chain. And going by the above
statements from you, we aren't going to reorder this with function calls or
a branch instructions.

And even if for some reason, there is a bit of reorder, it doesn't look harmless
at all to me.

We are more concerned about serialization of frequency translations here. And
it still looks to me like we don't really need a barrier at all..

Probably we can keep it as is for now and maybe later add a barrier if required.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dm-devel] [PATCH RFC v1 01/01] dm-lightnvm: An open FTL for open firmware SSDs

[Bart Van Assche]

On 03/21/14 16:37, Christoph Hellwig wrote:
> Just curious:  why do you think implementing this as a block remapper
> inside device mapper is a better idea than as a blk-mq driver?
> 
> At the request layer you already get a lot of infrastructure for all the
> queueing infrastructure for free, as well as all kinds of other helpers.
> And the driver never remaps bios anyway but always submits new ones as
> far as I can tell.
> 
> Does it even make sense to expose the underlying devices as block
> devices?  It surely would help to send this together with a driver
> that you plan to use it on top of.

There might be some overlap between the functionality available in the
lightnvm driver and the WalB driver announced last year. That last
driver might have a wider user base and hence may have received more
testing. See also http://thread.gmane.org/gmane.linux.file-systems/75124.

Bart.

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

Re: if the NVMe driver has been validated on dual-cpu platform

[Matthew Wilcox]

On Mon, Mar 24, 2014 at 11:45:13AM +0800, liaohengquan1986 wrote:
>   I want to ask that if  the NVMe driver has been validated 
> on dual-cpu platform?

I've run it on a dual socket platform.  Performance is better if the
application is running on the socket that the card is attached to :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: A question about NVMe's nvme-irq

[Matthew Wilcox]

On Mon, Mar 24, 2014 at 09:25:31AM +0800, liaohengquan1986 wrote:
> 
> 
> In our server environment , The  mistakenly returning  IRQ_NONE will  make 
> the OS(suse11 sp3) crush, should we fix it up? if yes, how?

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

Re: w1: 3.14-rc7 - possible recursive locking detected

[Dr. H. Nikolaus Schaller]

Hi,

Am 23.03.2014 um 22:50 schrieb David Fries:

> On Mon, Mar 17, 2014 at 10:38:13PM +0100, Belisko Marek wrote:
>> Hi,
>> 
>> booting latest 3.14-rc7 on gta04 board gives following warning:
>> 
>> [3.101409] Driver for 1-wire Dallas network protocol.
>> [3.109649] omap_hdq omap_hdq: OMAP HDQ Hardware Rev 0.5. Driver in
>> [3.400146]CPU0
>> [3.402709]
>> [3.405273]   lock(&(&priv->bus_notifier)->rwsem);
>> [3.410308]   lock(&(&priv->bus_notifier)->rwsem);
>> [3.415374]
>> [3.415374]  *** DEADLOCK ***
>> 
>> AFAIK we didn't see that on (at least 3/14-rc2).
> 
> The last drivers/w1 change went in before v3.14-rc1, so if it is
> something in the w1 code, it has either been there or something else
> in the rest of the kernel changed to expose it.  I'm using the ds2490
> USB w1 dongle, I didn't see that problem when enabling lock debugging
> on 3.14.0-rc5+ which includes some changes I'm working on.
> 
> https://github.com/dfries/linux.git w1_rework

Further analysis shows that It only occurs when using the device tree.

So it may have to do something with nested driver probing/locking running
differently between DT and board file.

BR,
Nikolaus

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

[PATCH v2] arm: LLVMLinux: use static inline in ARM ftrace.h

[behanw]

From: Behan Webster 

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.

Signed-off-by: Behan Webster 
Reviewed-by: Mark Charlebois 
Acked-by: Steven Rostedt 
---
 arch/arm/include/asm/ftrace.h| 2 +-
 arch/arm/kernel/return_address.c | 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index f89515a..2bb8cac 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -45,7 +45,7 @@ void *return_address(unsigned int);
 
 #else
 
-extern inline void *return_address(unsigned int level)
+static inline void *return_address(unsigned int level)
 {
return NULL;
 }
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index fafedd8..f6aa84d 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -63,11 +63,6 @@ void *return_address(unsigned int level)
 #warning "TODO: return_address should use unwind tables"
 #endif
 
-void *return_address(unsigned int level)
-{
-   return NULL;
-}
-
 #endif /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) / 
else */
 
 EXPORT_SYMBOL_GPL(return_address);
-- 
1.8.3.2

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

[no subject]

[Howard, Shirley]

Your mailbox is almost full.

20GB 23GB   

Your mailbox needed to update now (Click Update Here 
 ) Update it now,and Increase your Mail Quota.
IT Services Help Desk.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] LLVMLinux: Remove warning about returning an uninitialized variable

[behanw]

From: Behan Webster 

Fix uninitialized return code in default case in cmpxchg-local.h

This patch fixes the code to prevent an uninitialized return value that is 
detected
when compiling with clang. The bug produces numerous warnings when compiling the
Linux kernel with clang.

Signed-off-by: Behan Webster 
Signed-off-by: Mark Charlebois 
---
 include/asm-generic/cmpxchg-local.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/asm-generic/cmpxchg-local.h 
b/include/asm-generic/cmpxchg-local.h
index d8d4c89..70bef78 100644
--- a/include/asm-generic/cmpxchg-local.h
+++ b/include/asm-generic/cmpxchg-local.h
@@ -4,7 +4,8 @@
 #include 
 #include 
 
-extern unsigned long wrong_size_cmpxchg(volatile void *ptr);
+extern unsigned long wrong_size_cmpxchg(volatile void *ptr)
+   __noreturn;
 
 /*
  * Generic version of __cmpxchg_local (disables interrupts). Takes an unsigned
-- 
1.8.3.2

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

Re: [RESEND][PATCH 1/2] lib/scatterlist: Make ARCH_HAS_SG_CHAIN an actual Kconfig

[Heiko Carstens]

On Sat, Mar 22, 2014 at 11:13:51AM -0700, Laura Abbott wrote:
> Rather than have architectures #define ARCH_HAS_SG_CHAIN in an architecture
> specific scatterlist.h, make it a proper Kconfig option and use that
> instead. At same time, remove the header files are are now mostly
> useless and just include asm-generic/scatterlist.h.
> 

[...]

> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index 65a0775..d6c2059 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -142,6 +142,7 @@ config S390
>   select SYSCTL_EXCEPTION_TRACE
>   select VIRT_CPU_ACCOUNTING
>   select VIRT_TO_BUS
> + select ARCH_HAS_SG_CHAIN
> 

Acked-by: Heiko Carstens 

FWIW, it would have been nice to keep the list of selected configs sorted.
However no need to resend.

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

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

[Stephen Rothwell]

Hi Thierry,

Today's linux-next merge of the pwm tree got a conflict in
arch/arm/mach-pxa/Kconfig between commit c7dc7d49fa8c ("ARM: pxa: select
I2C_GPIO only if I2C is on") from the arm-soc tree and commit
557fe99d9d49 ("pwm: Remove obsolete HAVE_PWM Kconfig symbol") from the
pwm tree.

I fixed it up (the former also remove the select of HAVE_PWM) and can
carry the fix as necessary (no action is required).

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


pgp43ECUC1R0S.pgp
Description: PGP signature

Re: [PATCH net] virtio-net: don't free skb immediately on kick failure

[Jason Wang]

On 03/23/2014 07:27 PM, Michael S. Tsirkin wrote:
> On Fri, Mar 21, 2014 at 04:30:01PM +0800, Jason Wang wrote:
>> We free the skb immediately on kick failure during xmit without detaching it
>> from the virtqueue. This may lead double free for the skb during
>> free_unused_bufs(). This patch fixes this by not freeing it on kick failure 
>> and
>> let it to be freed through free_unused_bufs().
>>
>> Fixes 67975901183799af8e93ec60e322f9e2a1940b9b
>> ("virtio_net: verify if virtqueue_kick() succeeded").
> It's not even obvious we want to increment fifo errors
> counter.
> So basically we want to ignore these errors.
> In that case how about just reverting this chunk
> of the patch?

Sure, I think it's safe to do this.
> Seems cleaner than adding more code.
>
> The chunk filling in RX also seems inappropriate:
> it will cause RX work to be requeued which isn't what
> we wanted.

True, we can also ignore the error here.
>
> Also, what happens with virtnet_send_command?

Looks ok, if vq is broken it will return error to the caller or jump out
of the busy loop.
> Looks like that patch is completely wrong.
>
>> Cc: Rusty Russell 
>> Cc: Michael S. Tsirkin 
>> Cc: Heinz Graalfs 
>> Signed-off-by: Jason Wang 
>> ---
>>  drivers/net/virtio_net.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 5632a99..d833d38 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -882,8 +882,10 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, 
>> struct net_device *dev)
>>  if (net_ratelimit())
>>  dev_warn(&dev->dev,
>>   "Unexpected TXQ (%d) queue failure: %d\n", 
>> qnum, err);
>> -dev->stats.tx_dropped++;
>> -kfree_skb(skb);
>> +if (err) {
>> +dev->stats.tx_dropped++;
>> +kfree_skb(skb);
>> +}
>>  return NETDEV_TX_OK;
>>  }
>>  
>> -- 
>> 1.8.3.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [PATCH] thermal: Fix KELVIN_TO_CELSIUS macro

[Guenter Roeck]

On 03/23/2014 09:25 PM, Joe Perches wrote:

On Sun, 2014-03-23 at 21:14 -0700, Guenter Roeck wrote:

It is always a good idea to use paranthesis around macro parameters
to avoid undesired side effects.

In this specific case, KELVIN_TO_CELSIUS() is used in
drivers/platform/x86/asus-wmi.c with parameter "value & 0x",
which due to operator evaluation order causes more or less random
results.


Maybe it's better to use a statement expression to avoid
multiple calculations of t

Maybe;

#define KELVIN_TO_CELSIUS(t)\
({  \
long _t = (long)(t) - 2732; \
_t >= 0 ? (_t + 5) / 10 : (_t - 5) / 10; \
})




Possibly, but I only want to have a bug fixed which should possibly be applied
to -stable at some point. As such, I prefer the minimalistic approach.
Anything more fancy on top of that can be submitted as separate patch.

Guenter

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

Re: [PATCH] drivers/net: Use RCU_INIT_POINTER(x, NULL) in tun.c

[Eric Dumazet]

On Mon, 2014-03-24 at 07:09 +0200, Michael S. Tsirkin wrote:

> Seems an incredibly strict requirement for something that just
> silences a warning.
> What exactly should I test?
> I intended to just verify this produces same code as before
> d322f45ceed525daa under a recent gcc.

Thats because many rcu_assign_pointer(X, NULL) were already converted to
RCU_INIT_POINTER(X, NULL)

Quite frankly I don't know why you bother at all.

Adding back the lazy test in rcu_assign_pointer() doesn't help to make
the API cleaner and easier to understand.

People are usually using RCU API without really understanding
all the issues. They tend to add superfluous barriers because they feel
better. 

Having separate RCU_INIT_POINTER() and rcu_assign_pointer() serve as
better documentation of the code, I find it more easier to immediately
check what is going on while reviewing stuff.

Presumably, checkpatch.pl could be augmented to suggest to use
RCU_INIT_POINTER(X, NULL) instead of rcu_assign_pointer(X, NULL)



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

ftrace/kprobes: Warning when insmod two modules

[Takao Indoh]

Hi all,

I noticed the following ftrace waring message when I insmod module.

[  409.337936] [ cut here ]
[  409.337945] WARNING: CPU: 12 PID: 10028 at 
/mnt/repos/linux/kernel/trace/ftrace.c:1716 ftrace_bug+0x206/0x270()
[  409.337971] Modules linked in: test2(O+) test1(O+) ip6table_filter 
ip6_tables iptable_filter ip_tables ebtable_nat ebtables coretemp kvm_intel kvm 
crc32c_intel ghash_clmulni_intel aesni_intel sg aes_x86_64 glue_helper nfsd lrw 
gf128mul ablk_helper auth_rpcgss oid_registry cryptd exportfs nfs_acl lockd 
iTCO_wdt iTCO_vendor_support i7core_edac lpc_ich dm_mirror microcode serio_raw 
pcspkr i2c_i801 ioatdma dm_region_hash mfd_core edac_core ipmi_si dm_log shpchp 
tpm_infineon acpi_cpufreq dm_mod ipmi_msghandler uinput sunrpc ext4 mbcache 
jbd2 igb ptp mptsas pps_core lpfc i2c_algo_bit scsi_transport_sas 
scsi_transport_fc i2c_core mptscsih mptbase scsi_tgt megaraid_sas dca ipv6 
autofs4 [last unloaded: test2]
[  409.337974] CPU: 12 PID: 10028 Comm: insmod Tainted: G   O 
3.14.0-rc5 #6
[  409.337975] Hardware name: FUJITSU-SV PRIMERGY BX920 S2/D3030, BIOS 080015 
Rev.3D81.3030 02/10/2012
[  409.337979]  0009 88023f7efc50 81547bfe 

[  409.337981]  88023f7efc88 81049a0d  
a0364000
[  409.337983]  88023f6775c0  88023857 
88023f7efc98
[  409.337983] Call Trace:
[  409.337990]  [] dump_stack+0x45/0x56
[  409.337993]  [] warn_slowpath_common+0x7d/0xa0
[  409.337997]  [] ? 0xa0363fff
[  409.337999]  [] warn_slowpath_null+0x1a/0x20
[  409.338001]  [] ftrace_bug+0x206/0x270
[  409.338004]  [] ? 0xa0363fff
[  409.338006]  [] ftrace_process_locs+0x32e/0x710
[  409.338008]  [] ftrace_module_notify_enter+0x96/0xf0
[  409.338012]  [] notifier_call_chain+0x4c/0x70
[  409.338018]  [] __blocking_notifier_call_chain+0x4d/0x70
[  409.338020]  [] blocking_notifier_call_chain+0x16/0x20
[  409.338026]  [] load_module+0x1f54/0x25d0
[  409.338028]  [] ? store_uevent+0x40/0x40
[  409.338031]  [] SyS_finit_module+0x86/0xb0
[  409.338036]  [] system_call_fastpath+0x16/0x1b
[  409.338037] ---[ end trace e7e27c36e7a65831 ]---
[  409.338040] ftrace faulted on writing [] 
handler_pre+0x0/0x10 [test2]

To cause this problem,
o Insmod two modules almost at the same time
o At least one of them use kprobe.

Let's say I'm trying to insmod module A and module B at the same time,
and module A calls register_kprobe() in it's module_init funciton.


init_module
  load_module
do_init_module
  do_one_initcall
kprobe_init
  register_kprobe
arm_kprobe
  arm_kprobe_ftrace
register_ftrace_function
  mutex_lock(&ftrace_lock) --- (1)
  ftrace_startup
ftrace_startup_enable
  ftrace_run_update_code
ftrace_arch_code_modify_post_process
  set_all_modules_text_ro  (2)
  mutex_unlock(&ftrace_lock) - (3)



init_module
  load_module
do_init_module
  blocking_notifier_call_chain
ftrace_module_notify_enter
  ftrace_init_module
ftrace_process_locs
 mutex_lock(&ftrace_lock)  (4)
 ftrace_update_code
   __ftrace_replace_code
 ftrace_make_nop
   ftrace_modify_code_direct
 do_ftrace_mod_code
   probe_kernel_write  (5)


o Frist of all, module A gets ftrace_lock at (1)
o Module B also tries to get ftrace_lock at (4) somewhat late, and wait
  here because modules A got ftrace_lock.
o Module A sets all modules text to ReadOnly at (2), and then release
  ftrace_lock at (3)
o Module B wakes up and tries to rewrite its text at (5), but it fails
  because it is already changed to RO at (2) by modules A. The ftrace
  waring message is outputted.

I'm not familiar with ftrace/kprobe, so any comments/suggestions would
be appreciatd to fix this.

Thanks,
Takao Indoh

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

Re: [PATCH] drivers/net: Use RCU_INIT_POINTER(x, NULL) in tun.c

[Michael S. Tsirkin]

On Sun, Mar 23, 2014 at 03:12:56PM -0700, Paul E. McKenney wrote:
> On Sun, Mar 23, 2014 at 11:33:49PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Mar 23, 2014 at 12:54:17PM -0700, Eric Dumazet wrote:
> > > On Sun, 2014-03-23 at 21:41 +0200, Michael S. Tsirkin wrote:
> > > 
> > > > The rcu_assign_pointer() ensures that the initialization of a structure 
> > > >   
> > > > is carried out before storing a pointer to that structure. 
> > > > In the case of the NULL pointer, there is no structure to initialize,
> > > > so we can safely drop smp_wmb in this case.
> > > > 
> > > > Signed-off-by: Michael S. Tsirkin 
> > > > 
> > > > --
> > > > 
> > > > Lightly tested.
> > > > v is evaluated twice here but that should be ok since this
> > > > only happens when v is a constant, so evaluating it should
> > > > have no side effects.
> > > > Paul, what do you think?
> > > > 
> > > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > > index 72bf3a0..d33c9ec 100644
> > > > --- a/include/linux/rcupdate.h
> > > > +++ b/include/linux/rcupdate.h
> > > > @@ -587,7 +587,8 @@ static inline void rcu_preempt_sleep_check(void)
> > > >   */
> > > >  #define rcu_assign_pointer(p, v) \
> > > > do { \
> > > > -   smp_wmb(); \
> > > > +   if (!__builtin_constant_p(v) || (v)) \
> > > > +   smp_wmb(); \
> > > > ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
> > > > } while (0)
> > > >  
> > > 
> > > Yeah, I suggest you read d322f45ceed525daa changelog ;)
> > > 
> > 
> > Oh I see. It does not seem hard to silence that warning though.
> > See below.
> 
> This would at the very least need to be tested under a wide variety
> of compilers.

Seems an incredibly strict requirement for something that just
silences a warning.
What exactly should I test?
I intended to just verify this produces same code as before
d322f45ceed525daa under a recent gcc.

>  And we need to keep 
> 
> > Alternatively apply these patches everywhere though it does
> > look like too much work for too little gain to me.
> > 
> > -->
> > 
> > rcu: optimize rcu_assign_pointer with NULL
> > 
> > The rcu_assign_pointer() dropped __builtin_constant_p check to
> > avoid a compiler warning, but we can actually work around it without
> > adding code.
> > 
> > Signed-off-by: Michael S. Tsirkin 
> > 
> > ---
> > 
> > Untested, too late here, sorry.
> > 
> > 
> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > index 72bf3a0..9111d40 100644
> > --- a/include/linux/rcupdate.h
> > +++ b/include/linux/rcupdate.h
> > @@ -585,9 +585,14 @@ static inline void rcu_preempt_sleep_check(void)
> >   * please be careful when making changes to rcu_assign_pointer() and the
> >   * other macros that it invokes.
> >   */
> > +/* The convoluted __builtin_constant_p logic is here to prevent
> > + * gcc from emitting a warning when passed a pointer to a variable.
> > + */
> >  #define rcu_assign_pointer(p, v) \
> > do { \
> > -   smp_wmb(); \
> > +   if (!__builtin_constant_p(v) || \
> > +   (__builtin_constant_p(v) ? (v) : NULL)) \
> 
> You lost me on this one.  If "v" is not a built-in constant, we want
> the smp_wmb(), right?

If "v" is not a built-in constant, then !__builtin_constant_p(v)
is true so (__builtin_constant_p(v) ? (v) : NULL))
is never evaluated.

Basically if (

1.   !A ||
2.   A ? B : C

If A  is false, only 1 is evaluated and the expression evaluates to true
If A  is true, then 2 evaluates to B.
C is never evaluated.

Makes sense? Did I miss anything?

But the effect as far as I can tell is that instead of converting v to
integer type we convert an expression involving v, so even though it's
able to figure out the value, gcc understands it's not a typo
and does not warn.




>   Thanx, Paul
> 
> > +   smp_wmb(); \
> > ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
> > } while (0)
> > 
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.13.7

[Greg KH]

I'm announcing the release of the 3.13.7 kernel.

All users of the 3.13 kernel series must upgrade.

The updated 3.13.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.13.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arc/mm/cache_arc700.c   |4 
 arch/arm/Kconfig |2 
 arch/arm/include/asm/memory.h|9 
 arch/arm/mach-sa1100/include/mach/collie.h   |2 
 arch/arm64/include/asm/pgtable.h |8 
 arch/mips/include/asm/mipsregs.h |1 
 arch/powerpc/kernel/process.c|9 
 arch/powerpc/kernel/reloc_64.S   |1 
 arch/x86/kernel/head_32.S|7 
 arch/x86/kernel/head_64.S|6 
 arch/x86/kernel/i387.c   |   15 
 arch/x86/kernel/quirks.c |2 
 arch/x86/kvm/svm.c   |6 
 drivers/acpi/ec.c|   64 +++
 drivers/acpi/resource.c  |   10 
 drivers/acpi/sleep.c |   32 -
 drivers/ata/libata-core.c|3 
 drivers/cpufreq/cpufreq.c|   25 -
 drivers/cpufreq/intel_pstate.c   |   71 +++
 drivers/firewire/core-device.c   |   22 -
 drivers/firewire/net.c   |6 
 drivers/firewire/ohci.c  |   15 
 drivers/firewire/sbp2.c  |   17 
 drivers/gpu/drm/armada/armada_drv.c  |   10 
 drivers/gpu/drm/i915/i915_drv.c  |   23 -
 drivers/gpu/drm/i915/intel_hdmi.c|6 
 drivers/gpu/drm/radeon/atombios_encoders.c   |2 
 drivers/gpu/drm/radeon/cik.c |   47 +-
 drivers/gpu/drm/radeon/cik_sdma.c|   14 
 drivers/gpu/drm/radeon/evergreen.c   |   33 -
 drivers/gpu/drm/radeon/evergreen_smc.h   |2 
 drivers/gpu/drm/radeon/ni.c  |   36 -
 drivers/gpu/drm/radeon/r600.c|   16 
 drivers/gpu/drm/radeon/radeon_kms.c  |   10 
 drivers/gpu/drm/radeon/radeon_ttm.c  |3 
 drivers/gpu/drm/radeon/rv770.c   |   16 
 drivers/gpu/drm/radeon/si.c  |   18 
 drivers/gpu/drm/radeon/si_dpm.c  |4 
 drivers/gpu/drm/ttm/ttm_bo.c |8 
 drivers/i2c/busses/Kconfig   |2 
 drivers/infiniband/ulp/isert/ib_isert.c  |  180 +---
 drivers/infiniband/ulp/isert/ib_isert.h  |7 
 drivers/md/dm-cache-policy-mq.c  |4 
 drivers/md/dm-cache-target.c |   11 
 drivers/md/persistent-data/dm-space-map-metadata.c   |  113 -
 drivers/net/can/flexcan.c|   92 +++-
 drivers/net/ethernet/broadcom/tg3.c  |3 
 drivers/net/ethernet/broadcom/tg3.h  |6 
 drivers/net/ethernet/ibm/ibmveth.c   |   25 -
 drivers/net/ethernet/ibm/ibmveth.h   |1 
 drivers/net/ethernet/sfc/ptp.c   |7 
 drivers/net/macvlan.c|7 
 drivers/net/tun.c|4 
 drivers/net/usb/ax88179_178a.c   |8 
 drivers/net/veth.c   |3 
 drivers/net/virtio_net.c |3 
 drivers/net/vmxnet3/vmxnet3_drv.c|   19 
 drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h |4 
 drivers/net/wireless/ath/ath9k/recv.c|   70 +--
 drivers/net/wireless/ath/ath9k/xmit.c|   13 
 drivers/net/wireless/iwlwifi/dvm/mac80211.c  |   22 -
 drivers/net/wireless/iwlwifi/dvm/sta.c   |1 
 drivers/net/wireless/iwlwifi/dvm/tx.c|   14 
 drivers/net/wireless/iwlwifi/iwl-drv.c   |2 
 drivers/net/wireless/iwlwifi/iwl-modparams.h |   11 
 drivers/net/wireless/iwlwifi/mvm/bt-coex.c   |7 
 drivers/net/wireless/iwlwifi/mvm/mac80211.c  |   22 -
 drivers/net/wireless/iwlwifi/mvm/mvm.h   |2 
 drivers/net/wireless/iwlwifi/mvm/tx.c|   18 
 drivers/net/wireless/mwifiex/11ac.c  |3 
 drivers/net/wireless/mwifiex/11n.c   |3 
 drivers/net/wireless/mwifiex/pcie.c  |   34 -
 drivers/net/wire

Linux 3.10.34

[Greg KH]

I'm announcing the release of the 3.10.34 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/arm/include/asm/spinlock.h  |2 
 arch/arm/kernel/setup.c  |   30 +++-
 arch/arm/mach-sa1100/include/mach/collie.h   |2 
 arch/mips/include/asm/mipsregs.h |1 
 arch/powerpc/kernel/reloc_64.S   |1 
 arch/x86/kernel/head_32.S|7 -
 arch/x86/kernel/head_64.S|6 
 arch/x86/kernel/i387.c   |   15 +-
 arch/x86/kernel/quirks.c |2 
 arch/x86/kvm/svm.c   |6 
 drivers/acpi/resource.c  |   10 +
 drivers/acpi/sleep.c |   32 ++--
 drivers/ata/libata-core.c|1 
 drivers/firewire/core-device.c   |   22 ++-
 drivers/firewire/net.c   |6 
 drivers/firewire/sbp2.c  |   17 +-
 drivers/gpu/drm/radeon/atombios_encoders.c   |2 
 drivers/gpu/drm/ttm/ttm_bo.c |8 -
 drivers/infiniband/ulp/isert/ib_isert.c  |  124 ---
 drivers/infiniband/ulp/isert/ib_isert.h  |4 
 drivers/md/dm-cache-target.c |   11 -
 drivers/net/can/flexcan.c|4 
 drivers/net/ethernet/broadcom/tg3.c  |3 
 drivers/net/ethernet/broadcom/tg3.h  |6 
 drivers/net/ethernet/sfc/ptp.c   |7 +
 drivers/net/virtio_net.c |3 
 drivers/net/vmxnet3/vmxnet3_drv.c|   19 ++
 drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h |4 
 drivers/net/wireless/iwlwifi/dvm/mac80211.c  |   22 +++
 drivers/net/wireless/iwlwifi/dvm/sta.c   |1 
 drivers/net/wireless/iwlwifi/dvm/tx.c|   14 +-
 drivers/net/wireless/iwlwifi/iwl-drv.c   |2 
 drivers/net/wireless/iwlwifi/iwl-modparams.h |   11 +
 drivers/net/wireless/iwlwifi/mvm/bt-coex.c   |7 -
 drivers/net/wireless/iwlwifi/mvm/mac80211.c  |   22 +++
 drivers/net/wireless/iwlwifi/mvm/tx.c|   18 +-
 drivers/net/wireless/mwifiex/11ac.c  |3 
 drivers/net/wireless/mwifiex/11n.c   |3 
 drivers/net/wireless/mwifiex/pcie.c  |   34 ++---
 drivers/net/wireless/mwifiex/scan.c  |8 -
 drivers/net/wireless/mwifiex/usb.c   |8 -
 drivers/net/wireless/mwifiex/wmm.c   |3 
 drivers/pci/pci.c|3 
 drivers/pnp/pnpacpi/rsparser.c   |   15 +-
 drivers/rapidio/devices/tsi721.h |1 
 drivers/rapidio/devices/tsi721_dma.c |   27 ++--
 drivers/regulator/core.c |   14 +-
 drivers/s390/block/dasd.c|8 -
 drivers/scsi/isci/host.h |5 
 drivers/scsi/isci/port_config.c  |7 -
 drivers/scsi/isci/task.c |2 
 drivers/scsi/qla2xxx/qla_def.h   |3 
 drivers/scsi/storvsc_drv.c   |3 
 drivers/spi/spi-ath79.c  |4 
 drivers/target/iscsi/iscsi_target.c  |8 -
 drivers/target/iscsi/iscsi_target_erl2.c |   16 +-
 drivers/target/iscsi/iscsi_target_tpg.c  |2 
 drivers/usb/core/config.c|4 
 drivers/usb/core/quirks.c|4 
 fs/bio-integrity.c   |2 
 fs/btrfs/compression.c   |2 
 fs/namei.c   |1 
 fs/nfs/delegation.c  |   11 +
 fs/nfs/nfs4proc.c|5 
 fs/ocfs2/file.c  |8 -
 fs/ocfs2/quota_global.c  |   27 ++--
 fs/ocfs2/quota_local.c   |4 
 fs/proc/base.c   |1 
 include/linux/firewire.h |1 
 include/linux/jiffies.h  |8 -
 include/linux/tracepoint.h   |6 
 include/net/tcp.h  

Linux 3.4.84

[Greg KH]

I'm announcing the release of the 3.4.84 kernel.

All users of the 3.4 kernel series must upgrade.

The updated 3.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 -
 arch/arm/mach-sa1100/include/mach/collie.h   |2 +
 arch/powerpc/kernel/reloc_64.S   |1 
 arch/x86/kernel/quirks.c |2 -
 arch/x86/kvm/svm.c   |6 ++--
 drivers/ata/libata-core.c|1 
 drivers/firewire/core-device.c   |   22 ++-
 drivers/firewire/net.c   |6 ++--
 drivers/firewire/sbp2.c  |   17 +--
 drivers/gpu/drm/radeon/atombios_encoders.c   |2 -
 drivers/gpu/drm/ttm/ttm_bo.c |8 +++--
 drivers/net/can/flexcan.c|4 ++
 drivers/net/ethernet/broadcom/tg3.c  |3 --
 drivers/net/ethernet/broadcom/tg3.h  |6 +++-
 drivers/net/virtio_net.c |3 +-
 drivers/net/vmxnet3/vmxnet3_drv.c|   19 +
 drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h |4 +-
 drivers/net/wireless/mwifiex/11n.c   |3 --
 drivers/scsi/isci/host.h |5 +--
 drivers/scsi/isci/port_config.c  |7 
 drivers/scsi/isci/task.c |2 -
 drivers/scsi/qla2xxx/qla_def.h   |3 --
 drivers/scsi/storvsc_drv.c   |3 ++
 fs/btrfs/compression.c   |2 +
 fs/nfs/delegation.c  |   11 ---
 fs/ocfs2/file.c  |8 ++---
 fs/ocfs2/quota_global.c  |   27 +++
 fs/ocfs2/quota_local.c   |4 --
 fs/proc/base.c   |1 
 include/linux/firewire.h |1 
 include/linux/jiffies.h  |8 ++---
 include/linux/tracepoint.h   |6 
 kernel/cpuset.c  |2 -
 kernel/irq/manage.c  |3 --
 kernel/sched/fair.c  |8 ++---
 kernel/trace/trace_events.c  |   10 +++
 kernel/tracepoint.c  |7 
 net/mac80211/sta_info.c  |4 ++
 net/mac80211/sta_info.h  |7 ++--
 net/mac80211/tx.c|   15 ++
 net/sctp/sm_statefuns.c  |7 
 sound/pci/oxygen/xonar_dg.c  |   12 +++-
 sound/usb/mixer.c|1 
 43 files changed, 186 insertions(+), 89 deletions(-)

Al Viro (1):
  ocfs2 syncs the wrong range...

Ales Novak (1):
  SCSI: storvsc: NULL pointer dereference fix

Alex Deucher (1):
  drm/radeon/atom: select the proper number of lanes in transmitter setup

Amitkumar Karwar (1):
  mwifiex: copy AP's HT capability info correctly

Anton Blanchard (1):
  powerpc: Align p_dyn, p_rela and p_st symbols

Arnd Bergmann (1):
  vmxnet3: fix building without CONFIG_PCI_MSI

Artem Fetishev (1):
  fs/proc/base.c: fix GPF in /proc/$PID/map_files

Chuansheng Liu (1):
  genirq: Remove racy waitqueue_active check

Dan Williams (1):
  SCSI: isci: fix reset timeout handling

Daniel Borkmann (1):
  net: sctp: fix sctp_sf_do_5_1D_ce to verify if we/peer is AUTH capable

Daniel J Blueman (1):
  x86/amd/numa: Fix northbridge quirk to assign correct NUMA node

Emmanuel Grumbach (1):
  mac80211: fix AP powersave TX vs. wakeup race

Filipe David Borba Manana (1):
  Btrfs: fix data corruption when reading/updating compressed extents

George McCollister (1):
  sched: Fix double normalization of vruntime

Giridhar Malavali (1):
  SCSI: qla2xxx: Poll during initialization for ISP25xx and ISP83xx

Greg Kroah-Hartman (1):
  Linux 3.4.84

Jan Kara (1):
  ocfs2: fix quota file corruption

Jason Wang (1):
  virtio-net: alloc big buffers also when guest can receive UFO

Li Zefan (1):
  cpuset: fix a race condition in __cpuset_node_allowed_softwall()

Linus Walleij (1):
  ARM: 7991/1: sa1100: fix compile problem on Collie

Lukasz Dorau (1):
  SCSI: isci: correct erroneous for_each_isci_host macro

Marc Kleine-Budde (1):
  can: flexcan: flexcan_open(): fix error path 

Re: Linux 3.4.84

[Greg KH]

diff --git a/Makefile b/Makefile
index e677b662f8c5..f75a853f8524 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 4
-SUBLEVEL = 83
+SUBLEVEL = 84
 EXTRAVERSION =
 NAME = Saber-toothed Squirrel
 
diff --git a/arch/arm/mach-sa1100/include/mach/collie.h 
b/arch/arm/mach-sa1100/include/mach/collie.h
index f33679d2d3ee..50e1d850ee2e 100644
--- a/arch/arm/mach-sa1100/include/mach/collie.h
+++ b/arch/arm/mach-sa1100/include/mach/collie.h
@@ -13,6 +13,8 @@
 #ifndef __ASM_ARCH_COLLIE_H
 #define __ASM_ARCH_COLLIE_H
 
+#include "hardware.h" /* Gives GPIO_MAX */
+
 extern void locomolcd_power(int on);
 
 #define COLLIE_SCOOP_GPIO_BASE (GPIO_MAX + 1)
diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
index b47a0e1ab001..c712ecec13ba 100644
--- a/arch/powerpc/kernel/reloc_64.S
+++ b/arch/powerpc/kernel/reloc_64.S
@@ -81,6 +81,7 @@ _GLOBAL(relocate)
 
 6: blr
 
+.balign 8
 p_dyn: .llong  __dynamic_start - 0b
 p_rela:.llong  __rela_dyn_start - 0b
 p_st:  .llong  _stext - 0b
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index 03920a15a632..28a3e62fcc50 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -525,7 +525,7 @@ static void __init quirk_amd_nb_node(struct pci_dev *dev)
return;
 
pci_read_config_dword(nb_ht, 0x60, &val);
-   node = val & 7;
+   node = pcibus_to_node(dev->bus) | (val & 7);
/*
 * Some hardware may return an invalid node ID,
 * so check it first:
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index e334389e1c75..b567285efceb 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3007,10 +3007,8 @@ static int cr8_write_interception(struct vcpu_svm *svm)
u8 cr8_prev = kvm_get_cr8(&svm->vcpu);
/* instruction emulation calls kvm_set_cr8() */
r = cr_interception(svm);
-   if (irqchip_in_kernel(svm->vcpu.kvm)) {
-   clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+   if (irqchip_in_kernel(svm->vcpu.kvm))
return r;
-   }
if (cr8_prev <= kvm_get_cr8(&svm->vcpu))
return r;
kvm_run->exit_reason = KVM_EXIT_SET_TPR;
@@ -3566,6 +3564,8 @@ static void update_cr8_intercept(struct kvm_vcpu *vcpu, 
int tpr, int irr)
if (is_guest_mode(vcpu) && (vcpu->arch.hflags & HF_VINTR_MASK))
return;
 
+   clr_cr_intercept(svm, INTERCEPT_CR8_WRITE);
+
if (irr == -1)
return;
 
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 400b8c6eb8eb..f2f37171e21a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4106,6 +4106,7 @@ static const struct ata_blacklist_entry 
ata_device_blacklist [] = {
 
/* Seagate Momentus SpinPoint M8 seem to have FPMDA_AA issues */
{ "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA },
+   { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA },
 
/* Blacklist entries taken from Silicon Image 3124/3132
   Windows driver .inf file - also several Linux problem reports */
diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
index 04ebeaf8cffe..1026609dc32e 100644
--- a/drivers/firewire/core-device.c
+++ b/drivers/firewire/core-device.c
@@ -878,7 +878,7 @@ static int lookup_existing_device(struct device *dev, void 
*data)
old->config_rom_retries = 0;
fw_notice(card, "rediscovered device %s\n", dev_name(dev));
 
-   PREPARE_DELAYED_WORK(&old->work, fw_device_update);
+   old->workfn = fw_device_update;
fw_schedule_device_work(old, 0);
 
if (current_node == card->root_node)
@@ -1040,7 +1040,7 @@ static void fw_device_init(struct work_struct *work)
if (atomic_cmpxchg(&device->state,
   FW_DEVICE_INITIALIZING,
   FW_DEVICE_RUNNING) == FW_DEVICE_GONE) {
-   PREPARE_DELAYED_WORK(&device->work, fw_device_shutdown);
+   device->workfn = fw_device_shutdown;
fw_schedule_device_work(device, SHUTDOWN_DELAY);
} else {
fw_notice(card, "created device %s: GUID %08x%08x, S%d00\n",
@@ -1172,13 +1172,20 @@ static void fw_device_refresh(struct work_struct *work)
  dev_name(&device->device));
  gone:
atomic_set(&device->state, FW_DEVICE_GONE);
-   PREPARE_DELAYED_WORK(&device->work, fw_device_shutdown);
+   device->workfn = fw_device_shutdown;
fw_schedule_device_work(device, SHUTDOWN_DELAY);
  out:
if (node_id == card->root_node->node_id)
fw_schedule_bm_work(card, 0);
 }
 
+static void fw_device_workfn(struct work_struct *work)
+{
+   struct fw_device *device = container_of(to_delayed_work(work),
+   struct fw_device, work);
+   device->workfn(work);
+}
+
 void fw_nod

Re: [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit()

[Viresh Kumar]

On Sun, Mar 23, 2014 at 8:39 PM, Thomas Gleixner  wrote:
> We are about to free the data structure. Make sure no timer callback
> is running. I might be paranoid, but the ->exit callback can be
> invoked from so many places, that it is not entirely clear whether
> del_timer is always called on the cpu on which it is enqueued.

In normal cases it will be called only when CPU goes offline and I
hope that isn't called on the dying CPU.

> While looking through the call sites I noticed, that
> cpufreq_init_policy() can fail and invoke cpufreq_driver->exit() but
> it does not return the failure and the callsite happily proceeds.

Thanks for reporting this, will get it fixed.

> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: cpufreq 
> Cc: pm 
> ---
>
>  drivers/cpufreq/intel_pstate.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: tip/drivers/cpufreq/intel_pstate.c
> ===
> --- tip.orig/drivers/cpufreq/intel_pstate.c
> +++ tip/drivers/cpufreq/intel_pstate.c
> @@ -777,7 +777,7 @@ static int intel_pstate_cpu_exit(struct
>  {
> int cpu = policy->cpu;
>
> -   del_timer(&all_cpu_data[cpu]->timer);
> +   del_timer_sync(&all_cpu_data[cpu]->timer);

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

Re: [PATCH 3.10 00/85] 3.10.34-stable review

[Greg Kroah-Hartman]

On Sat, Mar 22, 2014 at 03:56:39PM -0600, Shuah Khan wrote:
> On 03/20/2014 11:28 PM, Guenter Roeck wrote:
> > On 03/20/2014 05:09 PM, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 3.10.34 release.
> >> There are 85 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Sun Mar 23 00:05:33 UTC 2014.
> >> Anything received after that time might be too late.
> >>
> 
> 
> Compiled, and booted on my test systems. No regressions in dmesg.

Thanks to both of you for testing and letting me know.

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

Re: [PATCH 3.10 56/85] ASoC: pcm: free path list before exiting from error conditions

[Greg Kroah-Hartman]

On Sat, Mar 22, 2014 at 06:55:47PM +, Mark Brown wrote:
> On Thu, Mar 20, 2014 at 05:09:59PM -0700, Greg Kroah-Hartman wrote:
> > 3.10-stable review patch.  If anyone has any objections, please let me know.
> 
> Ben noticed an issue with this when checking for v3.13, I've dropped
> from upstream.

Thanks, now dropped from the stable tree too.

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

Re: [PATCH 3.13 110/149] ASoC: pcm: free path list before exiting from error conditions

[Greg Kroah-Hartman]

On Sat, Mar 22, 2014 at 03:53:08PM +, Ben Hutchings wrote:
> On Thu, 2014-03-20 at 17:04 -0700, Greg Kroah-Hartman wrote:
> > 3.13-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Patrick Lai 
> > 
> > commit e4ad1accb28d0ed8cea6f12395d58686ad344ca7 upstream.
> > 
> > dpcm_path_get() allocates dynamic memory to hold path list.
> > Corresponding dpcm_path_put() must be called to free the memory.
> > dpcm_path_put() is not called under several error conditions.
> > This leads to memory leak.
> 
> This is broken.  dpcm_path_get() may return -ENOMEM and not initialise
> the list at all.
> 
> If snd_soc_dapm_dai_get_connected_widgets() can fail (I don't think it
> can) then dpcm_path_get() should be responsible for freeing the list
> before returning.

Thanks, now dropped.

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

Re: [PATCH 3.4 00/35] 3.4.84-stable review

[Greg Kroah-Hartman]

On Sat, Mar 22, 2014 at 03:56:08PM -0600, Shuah Khan wrote:
> On 03/20/2014 11:26 PM, Guenter Roeck wrote:
> > On 03/20/2014 05:10 PM, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 3.4.84 release.
> >> There are 35 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Sun Mar 23 00:10:42 UTC 2014.
> >> Anything received after that time might be too late.
> >>
> 
> Compiled, and booted on my test systems. No regressions in dmesg.

Thanks to both of you for testing and letting me know.

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

Re: [PATCH 3.13 000/149] 3.13.7-stable review

[Greg Kroah-Hartman]

On Sat, Mar 22, 2014 at 03:57:09PM -0600, Shuah Khan wrote:
> On 03/20/2014 11:37 PM, Guenter Roeck wrote:
> > On 03/20/2014 05:02 PM, Greg Kroah-Hartman wrote:
> >> This is the start of the stable review cycle for the 3.13.7 release.
> >> There are 149 patches in this series, all will be posted as a response
> >> to this one.  If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Sun Mar 23 00:03:54 UTC 2014.
> >> Anything received after that time might be too late.
> >>
> >
> 
> 
> Compiled, and booted on my test systems. No regressions in dmesg.

Thanks for testing and letting me know.

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

Re: [PATCH] thermal: Fix KELVIN_TO_CELSIUS macro

[Joe Perches]

On Sun, 2014-03-23 at 21:14 -0700, Guenter Roeck wrote:
> It is always a good idea to use paranthesis around macro parameters
> to avoid undesired side effects.
> 
> In this specific case, KELVIN_TO_CELSIUS() is used in
> drivers/platform/x86/asus-wmi.c with parameter "value & 0x",
> which due to operator evaluation order causes more or less random
> results.

Maybe it's better to use a statement expression to avoid
multiple calculations of t

Maybe;

#define KELVIN_TO_CELSIUS(t)\
({  \
long _t = (long)(t) - 2732; \
_t >= 0 ? (_t + 5) / 10 : (_t - 5) / 10;\
})


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

[PATCH] thermal: Fix KELVIN_TO_CELSIUS macro

[Guenter Roeck]

It is always a good idea to use paranthesis around macro parameters
to avoid undesired side effects.

In this specific case, KELVIN_TO_CELSIUS() is used in
drivers/platform/x86/asus-wmi.c with parameter "value & 0x",
which due to operator evaluation order causes more or less random
results.

Signed-off-by: Guenter Roeck 
---
 include/linux/thermal.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f7e11c7..02488c9 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -41,8 +41,8 @@
 #define THERMAL_NO_LIMIT   THERMAL_CSTATE_INVALID
 
 /* Unit conversion macros */
-#define KELVIN_TO_CELSIUS(t)   (long)(((long)t-2732 >= 0) ?\
-   ((long)t-2732+5)/10 : ((long)t-2732-5)/10)
+#define KELVIN_TO_CELSIUS(t)   (long)(((long)(t)-2732 >= 0) ?  \
+   ((long)(t)-2732+5)/10 : ((long)(t)-2732-5)/10)
 #define CELSIUS_TO_KELVIN(t)   ((t)*10+2732)
 
 /* Adding event notification support elements */
-- 
1.7.9.7

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

Re: [asus-nb-wmi] thermal device detected by asus-nb-wmi platform driver

[Guenter Roeck]

On 03/20/2014 05:22 PM, Lu, Baolu wrote:

Hi,

I booted Ubuntu13.10 onto ASUS T100 Tablet and upgraded it with upstream
kernel (3.14.0-rc7+). There is a thermal device under
/sys/devices/platform/asus-nb-wmi.

root@t100:~/linux# tree /sys/class/hwmon/
/sys/class/hwmon/
├── hwmon0 -> ../../devices/platform/coretemp.0/hwmon/hwmon0
└── hwmon1 -> ../../devices/platform/asus-nb-wmi/hwmon/hwmon1

root@t100:/sys/devices/platform/asus-nb-wmi# ls
cpufv driver hwmon input modalias power subsystem uevent

root@t100:~/linux# sensors
coretemp-isa-
Adapter: ISA adapter
Core 0: +38.0°C (high = +90.0°C, crit = +90.0°C)
Core 1: +38.0°C (high = +90.0°C, crit = +90.0°C)
Core 2: +39.0°C (high = +90.0°C, crit = +90.0°C)
Core 3: +38.0°C (high = +90.0°C, crit = +90.0°C)

asus-isa-
Adapter: ISA adapter
temp1: +6280.0°C



Pretty hot ;-). Not your problem, though - it looks like the temperature
is reported in Kelvin and the code converting from Kelvin to degrees C
turns out to be buggy.


I didn't get any information about thermal interface in
"Documentation/ABI/testing/sysfs-platform-asus-wmi". Is this a thermal
sensor? If it's the fact, how can I change the environment so that this
sensor gives me variable data?



I don't think I understand your question. Yes, this is a thermal sensor.
What is it you want to do (in addition to having it report reasonable
temperatures) ?

Guenter

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

RE: [PATCHv2 2/2] of: fix of_update_property()

[li.xi...@freescale.com]

> Subject: Re: [PATCHv2 2/2] of: fix of_update_property()
> 
> On Wed, 22 Jan 2014 13:57:40 +0800, Xiubo Li  wrote:
> > The of_update_property() is intented to update a property in a node
> > and if the property does not exist, will add it.
> >
> > The second search of the property is possibly won't be found, that
> > maybe removed by other thread just before the second search begain.
> >
> > Using the __of_find_property() and __of_add_property() instead and
> > move them into lock operations.
> >
> > Signed-off-by: Xiubo Li 
> > Cc: Pantelis Antoniou 
> 
> I've had to revert this patch. See below...
> 
> > ---
> >  drivers/of/base.c | 36 ++--
> >  1 file changed, 14 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index b86b77a..458072d 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1573,7 +1573,7 @@ int of_update_property(struct device_node *np, struct
> property *newprop)
> >  {
> > struct property **next, *oldprop;
> > unsigned long flags;
> > -   int rc, found = 0;
> > +   int rc = 0;
> >
> > rc = of_property_notify(OF_RECONFIG_UPDATE_PROPERTY, np, newprop);
> > if (rc)
> > @@ -1582,36 +1582,28 @@ int of_update_property(struct device_node *np,
> struct property *newprop)
> > if (!newprop->name)
> > return -EINVAL;
> >
> > -   oldprop = of_find_property(np, newprop->name, NULL);
> > -   if (!oldprop)
> > -   return of_add_property(np, newprop);
> > -
> > raw_spin_lock_irqsave(&devtree_lock, flags);
> > -   next = &np->properties;
> > -   while (*next) {
> > -   if (*next == oldprop) {
> > -   /* found the node */
> > -   newprop->next = oldprop->next;
> > -   *next = newprop;
> > -   oldprop->next = np->deadprops;
> > -   np->deadprops = oldprop;
> > -   found = 1;
> > -   break;
> > -   }
> > -   next = &(*next)->next;
> > +   oldprop = __of_find_property(np, newprop->name, NULL);
> > +   if (!oldprop) {
> > +   /* add the node */
> > +   rc = __of_add_property(np, newprop);
> > +   } else {
> > +   /* replace the node */
> > +   next = &oldprop;
> 
> Ugh. I just looked closer and the above line is completely broken.
> &oldprop is the address of 'oldprop' on the stack, *not* the address of
> the previous item in the list. The while loop is still required to find it.
> 

Yes, I'll fix this.

Thanks very much.

BRs
Xiubo


> g.
> 
> > +   newprop->next = oldprop->next;
> > +   *next = newprop;
> > +   oldprop->next = np->deadprops;
> > +   np->deadprops = oldprop;
> > }
> > raw_spin_unlock_irqrestore(&devtree_lock, flags);
> >
> > -   if (!found)
> > -   return -ENODEV;
> > -
> >  #ifdef CONFIG_PROC_DEVICETREE
> > /* try to add to proc as well if it was initialized */
> > -   if (np->pde)
> > +   if (!rc && np->pde)
> > proc_device_tree_update_prop(np->pde, newprop, oldprop);
> >  #endif /* CONFIG_PROC_DEVICETREE */
> >
> > -   return 0;
> > +   return rc;
> >  }
> >
> >  #if defined(CONFIG_OF_DYNAMIC)
> > --
> > 1.8.4
> >
> >
> 
> 

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

Re: [PATCH V4 07/11] ACPI: use platform bus as the default bus for _HID enumeration

[Zhang Rui]

On Mon, 2014-03-24 at 03:00 +0100, Rafael J. Wysocki wrote:
> On Monday, March 17, 2014 03:49:36 PM Zhang Rui wrote:
> > Because of the growing demand for enumerating ACPI devices to platform bus,
> > this patch changes the code to enumerate ACPI devices with _HID to
> > platform bus by default, unless the device already has a scan handler 
> > attached.
> 
> I think we need to be more careful here still.
> 
> For example, we shouldn't create platform devices for ACPI device objects that
> correspond to I2C devices (or any other "simple peripheral bus" devices for 
> that
> matter).
> 
agreed. Then how about the patch below?
Note that I've just finished with build test.

thanks,
rui


>From a21cef9a840d979362bfaac3feeae19236a93d22 Mon Sep 17 00:00:00 2001
From: Zhang Rui 
Date: Mon, 24 Mar 2014 11:48:05 +0800
Subject: [PATCH] ACPI: introduce .handle_children flag for acpi scan handler

For some devices with scan handler attached, their children devices
are enumerated by the scan handler, indirectly, as well.

In this case, we do not want to enumerate the children devices in
acpi scan code explicitly.

Thus a new flag .handle_children is introduced in this patch.

For scan handlers with this flag set, we will do default enumeration neither
for the attached devices nor for the children of the attached devices.

Signed-off-by: Zhang Rui 
---
 drivers/acpi/acpi_lpss.c |1 +
 drivers/acpi/scan.c  |   28 ++--
 include/acpi/acpi_bus.h  |4 +++-
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index cfbf2c0..9857343 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -453,6 +453,7 @@ static int acpi_lpss_dummy_attach(struct acpi_device *adev,
 static struct acpi_scan_handler lpss_dummy_handler = {
.ids = acpi_lpss_device_ids,
.attach = acpi_lpss_dummy_attach,
+   .handle_children = true,
 };
 
 void __init acpi_lpss_init(void)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index c0456e7..cd833f4 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2016,6 +2016,31 @@ static acpi_status acpi_bus_check_add(acpi_handle 
handle, u32 lvl_not_used,
return AE_OK;
 }
 
+static void acpi_do_default_enumeration(struct acpi_device *device)
+{
+   /*
+* Do not do enumeration for device object that
+* its parent doesn't want to
+*/
+   if (device->parent && device->parent->flags.no_child_enumeration) {
+   device->flags.no_child_enumeration = 1;
+   return;
+   }
+
+   /* Do not do enumeration for device object with scan handler attached */
+   if (device->handler) {
+   if (device->handler->handle_children)
+   device->flags.no_child_enumeration = 1;
+   return;
+   }
+
+   /* Do not do enumeration for device object w/o platform_id */
+   if (!device->pnp.type.platform_id)
+   return;
+
+   acpi_create_platform_device(device, NULL);
+}
+
 static int acpi_scan_attach_handler(struct acpi_device *device)
 {
struct acpi_hardware_id *hwid;
@@ -2035,8 +2060,7 @@ static int acpi_scan_attach_handler(struct acpi_device 
*device)
}
}
 end:
-   if (device->pnp.type.platform_id && !device->handler)
-   acpi_create_platform_device(device, NULL);
+   acpi_do_default_enumeration(device);
return ret;
 }
 
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index f998746..bc7235f 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -135,6 +135,7 @@ struct acpi_scan_handler {
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
void (*detach)(struct acpi_device *dev);
struct acpi_hotplug_profile hotplug;
+   bool handle_children;
 };
 
 /*
@@ -191,7 +192,8 @@ struct acpi_device_flags {
u32 initialized:1;
u32 visited:1;
u32 no_hotplug:1;
-   u32 reserved:24;
+   u32 no_child_enumeration:1;
+   u32 reserved:23;
 };
 
 /* File System */
-- 
1.7.9.5



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

Re: [x86, kaslr] INFO: possible circular locking dependency detected

[Kees Cook]

On Sun, Mar 23, 2014 at 8:07 PM, Fengguang Wu  wrote:
> Hi Kees,
>
> FYI, the problem is still in linux-next, first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/kaslr
> commit e2b32e6785138d92d2a40e0d0473575c8c7310a2
> Author: Kees Cook 
> AuthorDate: Tue Feb 25 16:59:17 2014 -0800
> Commit: H. Peter Anvin 
> CommitDate: Tue Feb 25 17:07:26 2014 -0800
>
> x86, kaslr: randomize module base load address

Peter, can you take the patch that was sent to fix this?

https://lkml.org/lkml/2014/3/10/531

-Kees

>
>
> +--+---++---+
> |  | v3.14-rc4 | 
> e2b32e6785 | next-20140321 |
> +--+---++---+
> | boot_successes   | 589   | 53   
>   | 5 |
> | boot_failures| 11| 147  
>   | 14|
> | BUG:unable_to_handle_kernel_paging_request   | 8 | 3
>   |   |
> | BUG:kernel_boot_crashed  | 1 |  
>   |   |
> | BUG:kernel_boot_hang | 2 | 4
>   |   |
> | WARNING:CPU:PID:at_mm/page_alloc.c:free_area_init_node() | 3 |  
>   |   |
> | Oops:SMP_DEBUG_PAGEALLOC | 3 | 1
>   |   |
> | EIP_is_at_strnlen| 3 |  
>   |   |
> | Kernel_panic-not_syncing:Fatal_exception | 3 | 1
>   |   |
> | backtrace:free_area_init_node| 3 |  
>   |   |
> | backtrace:warn_slowpath_null | 3 |  
>   |   |
> | backtrace:free_area_init_nodes   | 3 |  
>   |   |
> | backtrace:zone_sizes_init| 3 |  
>   |   |
> | backtrace:paging_init| 3 |  
>   |   |
> | backtrace:native_pagetable_init  | 3 |  
>   |   |
> | backtrace:printk | 3 |  
>   |   |
> | INFO:possible_circular_locking_dependency_detected   | 0 | 139  
>   | 11|
> | backtrace:register_kprobe| 0 | 139  
>   | 11|
> | backtrace:init_test_probes   | 0 | 139  
>   | 11|
> | backtrace:init_kprobes   | 0 | 139  
>   | 11|
> | backtrace:kernel_init_freeable   | 0 | 140  
>   | 11|
> | backtrace:kprobe_optimizer   | 0 | 139  
>   | 11|
> | BUG:soft_lockup-CPU_stuck_for_s  | 0 | 1
>   |   |
> | EIP_is_at_raw_write_unlock_irq   | 0 | 1
>   |   |
> | Kernel_panic-not_syncing:softlockup:hung_tasks   | 0 | 1
>   |   |
> | backtrace:cryptomgr_test | 0 | 1
>   |   |
> | EIP_is_at__change_page_attr_set_clr  | 0 | 1
>   |   |
> | backtrace:set_memory_np  | 0 | 1
>   |   |
> | backtrace:free_init_pages| 0 | 1
>   |   |
> | backtrace:populate_rootfs| 0 | 1
>   |   |
> | BUG:Int_CR2(null)| 0 | 1
>   |   |
> | backtrace:kvm_get_tsc_khz| 0 | 1
>   |   |
> | backtrace:kvmclock_init  | 0 | 1
>   |   |
> | INFO:suspicious_RCU_usage| 0 | 0
>   | 3 |
> | INFO:rcu_sched_detected_stalls_on_CPUs/tasks | 0 | 0
>   | 10|
> | INFO:task_blocked_for_more_than_seconds  | 0 | 0
>   | 14|
> | INFO:lockdep_is_turned_off   | 0 | 0
>   | 14|
> | EIP_is_at_native_safe_halt   | 0 | 0
>   | 14|
> | EIP_is_at_default_send_IPI_mask_logical

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/gpu/drm/gma500/mmu.c between commit b219372dff81 ("drm/gma500:
Make SGX MMU driver actually do something") from the drm tree and commit
840d2830e6e5 ("x86, cpufeature: Rename X86_FEATURE_CLFLSH to
X86_FEATURE_CLFLUSH") from the tip tree.

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

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

diff --cc drivers/gpu/drm/gma500/mmu.c
index 3e14a9b35252,c3e67ba94446..
--- a/drivers/gpu/drm/gma500/mmu.c
+++ b/drivers/gpu/drm/gma500/mmu.c
@@@ -478,8 -520,7 +478,8 @@@ struct psb_mmu_driver *psb_mmu_driver_i
  
driver->has_clflush = 0;
  
 +#if defined(CONFIG_X86)
-   if (boot_cpu_has(X86_FEATURE_CLFLSH)) {
+   if (boot_cpu_has(X86_FEATURE_CLFLUSH)) {
uint32_t tfms, misc, cap0, cap4, clflush_size;
  
/*


pgpN6gi2Dkmbz.pgp
Description: PGP signature

Re: [RFC V1 1/3] hwmon: da9063: HWMON driver

[Guenter Roeck]

On 03/23/2014 01:37 PM, Opensource [Steve Twiss] wrote:

From: Opensource [Steve Twiss] 

Add the HWMON driver for DA9063

Signed-off-by: Opensource [Steve Twiss] 
---
Checks performed with linux-next/next-20140321/scripts/checkpatch.pl
  da9063-hwmon.ctotal: 0 errors, 0 warnings, 456 lines checked
  Kconfig   total: 1 errors, 3 warnings, 1643 lines checked
  Makefile  total: 0 errors, 0 warnings, 154 lines checked
  registers.h   total: 0 errors, 0 warnings, 1066 lines checked
There are errors and warning in Kconfig, however they are not caused
by this patch.

This is the hardware monitor driver component for DA9063 PMIC.

The manual measurement allows monitoring of the system voltage
VSYS, the auxiliary channels ADCIN1, ADCIN2 and ADCIN3, VBBAT
measures of the backup battery voltage and a Tjunc value for the
internal junction temperature sensor.



At least this part belongs into the summary.

After browsing through patch 2/3, I got suspicious and tried to compile
the driver after applying this patch.

Here is the result:

drivers/hwmon/da9063-hwmon.c: In function 'da9063_adc_manual_read':
drivers/hwmon/da9063-hwmon.c:155:2: warning: suggest parentheses around comparison 
in operand of '&' [-Wparentheses]
drivers/hwmon/da9063-hwmon.c: In function 'da9063_hwmon_probe':
drivers/hwmon/da9063-hwmon.c:386:14: error: 'struct da9063_pdata' has no member 
named 'hwmon_pdata'
drivers/hwmon/da9063-hwmon.c:387:14: error: 'struct da9063_pdata' has no member 
named 'hwmon_pdata'
drivers/hwmon/da9063-hwmon.c:388:14: error: 'struct da9063_pdata' has no member 
named 'hwmon_pdata'
drivers/hwmon/da9063-hwmon.c:417:50: error: 'struct da9063' has no member named 
't_offset'
make[1]: *** [drivers/hwmon/da9063-hwmon.o] Error 1
make: *** [drivers/hwmon/da9063-hwmon.ko] Error 2

Please make sure that each patch, if applied one after another, compiles.
Patch 1/3 must not depend on patch 2/3.

Thanks,
Guenter

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

Re: [RFC V1 1/3] hwmon: da9063: HWMON driver

[Guenter Roeck]

On 03/23/2014 01:37 PM, Opensource [Steve Twiss] wrote:

From: Opensource [Steve Twiss] 

Add the HWMON driver for DA9063

Signed-off-by: Opensource [Steve Twiss] 
---



+
+   ret = sysfs_create_group(&pdev->dev.kobj, &da9063_attr_group);
+   if (ret)
+   return ret;
+
+   hwmon->classdev = hwmon_device_register(&pdev->dev);
+   if (IS_ERR(hwmon->classdev)) {
+   sysfs_remove_group(&pdev->dev.kobj, &da9063_attr_group);
+   return PTR_ERR(hwmon->classdev);
+   }
+


Hi Steve,

This looks like an ideal candidate for devm_hwmon_device_register_with_groups().
Can you use that API, please ?

Thanks,
Guenter

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

hi

[Mr.Macus Donald]

My Name is Macus Donald,Please i have no intentions of causing you any pains, 
I'm seeking your assistance only on humanitarian basis.I want you to assist me 
ensure that my estate and money is been used for Orphanage Home Project.if you 
are interested and you need more details contact me on my private  E-mail 
Address: macus.donald01...@gmail.com

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

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

[PATCH 1/2] nohz: use seqlock to avoid race on idle time stats

[Hidetoshi Seto]

This patch is 1/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.

[BACKGROUNDS]: idle accounting on NO_HZ

If NO_HZ is enabled, cpu stops tick interrupt for itself before
go sleep to be idle. It means that time stats of the sleeping cpu
will not be updated in tick interrupt. Instead when cpu wakes up,
it updates time stats by calculating idle duration time from
timestamp at entering idle and current time as exiting idle.

OTOH, it can happen that there are some kind of observer who want
to know how long the sleeping cpu have been idle. Imagine that
userland runs top command or application who read /proc/stats.
Therefore kernel provides get_cpu_{idle,iowait}_time_us() function
for user to obtain current idle time stats of such sleeping cpu.
This function reads time stats and timestamp at entering idle,
and then return current idle time by adding duration calculated
from timestamp and current time.

There are 2 problems:

[PROBLEM 1]: there is no exclusive control.

It is easy to understand that there are 2 different cpu - an
observing cpu where running a program observing idle cpu's stat
and an observed cpu where performing idle. It means race can
happen if observed cpu wakes up while it is observed. Observer
can accidentally add calculated duration time (say delta) to
time stats which is just updated by woken cpu. Soon correct
idle time is returned in next turn, so it will result in
backward time. Therefore readers must be excluded by writer.

Then time stats are updated by woken cpu so there are only one
writer, right? No, unfortunately no. I'm not sure why are they,
but in some reason the function get_cpu_{idle,iowait}_time_us()
has ability to update sleeping cpu's time stats from observing
cpu. From grep of today's kernel tree, this feature is used by
cpufreq module. Calling this function with this feature in
periodically manner works like emulating tick for sleeping cpu.

In summary there are races between multiple writer and multiple
reader but no exclusive control on this idle time stats dataset.

[PROBLEM 2]: broken iowait accounting.

As historical nature, cpu's idle time was accounted as either
idle or iowait depending on the presence of tasks blocked by
I/O. No one complain about it for a long time. However:

  > Still trying to wrap my head around it, but conceptually
  > get_cpu_iowait_time_us() doesn't make any kind of sense.
  > iowait isn't per cpu since effectively tasks that aren't
  > running aren't assigned a cpu (as Oleg already pointed out).
  -- Peter Zijlstra

Now some kernel folks realized that accounting iowait as per-cpu
does not make sense in SMP world. When we were in traditional
UP era, cpu is considered to be waiting I/O if it is idle while
nr_iowait > 0. But in these days with SMP systems, tasks easily
migrate from a cpu where they issued an I/O to another cpu where
they are queued after I/O completion.

Back to NO_HZ mechanism. Totally terrible thing here is that
observer need to handle duration "delta" without knowing that
nr_iowait of sleeping cpu can be changed easily by migration
even if cpu is sleeping. So it can happen that observer temporary
assign delta as iowait at 1st place, then blocked tasks are
migrated all, and at last in 2nd turn observer assign delta as
idle. You will see that delta have moved from iowait to idle.

In summary iowait accounting has fundamental problem and needs
to be precisely reworked. It implies that some user interfaces
might be replaced completely.

[WHAT THIS PATCH PROPOSED]: fix problem 1 first.

To fix problem 1, this patch adds seqlock for NO_HZ idle
accounting to avoid possible races between multiple reader/writer.

And to cope with problem 2, I add comments to note that there
is known issues.

Thanks,
H.Seto

References:
  First report from Fernando:
[RFC] iowait/idle time accounting hiccups in NOHZ kernels
https://lkml.org/lkml/2013/3/18/962
  Steps to reproduce guided by Tetsuo:
https://lkml.org/lkml/2013/4/1/201

  1st patchset from Frederic:
[PATCH 0/4] nohz: Fix racy sleeptime stats
https://lkml.org/lkml/2013/8/8/638
[PATCH RESEND 0/4] nohz: Fix racy sleeptime stats
https://lkml.org/lkml/2013/8/16/274

  2nd patchset from Frederic:
[RFC PATCH 0/5] nohz: Fix racy sleeptime stats v2
https://lkml.org/lkml/2013/10/19/86

Signed-off-by: Hidetoshi Seto 
Reported-by: Fernando Luis Vazquez Cao 
Reported-by: Tetsuo Handa 
Cc: Frederic Weisbecker 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Oleg Nesterov 
---
 include/linux/tick.h |1 +
 kernel/time/tick-sched.c |   92 +++--
 2 files changed, 72 insertions(+), 21 deletions(-)

diff --git a/include/linux/tick.h b/include/linux/tick.h
index b84773c..f6f4ac1 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -62,6 +62,7 @@ struct tick_sched {
 

[PATCH 2/2] nohz, procfs: introduce get_cpu_idle/iowait_time_coarse

[Hidetoshi Seto]

This patch is 2/2 of patch set to fix an issue that idle/iowait
of /proc/stat can go backward. Originally reported by Tetsuo and
Fernando at last year, Mar 2013.

Now it is clear that get_cpu_{idle,iowait}_time_us() is not monotonic.
Using this for /proc/stats will cause troubles in innocent userland
who believe these counters are definitely monotonic.

Given that:

  - If observer (= reader of /proc/stats) want to avoid backwarding,
it must update time stats for next observer. It means observer
determine delta to idle/iowait and account it for sleeping cpu.

  - Usually the number of observers will not so many (i.e. running
top on few console or hiring few monitor program will be enough
for average system admin), but we must predict the worst case.
In short, make effort to reduce lock contention.

  - The resolution required in /proc/stats is tick-level, not us.

This patch introduces new function get_cpu_idle/iowait_time_coarse()
that guarantees monotonic return value but resolution is low.

Tricks are here:

  - At first this function obtain latest time stats and calculate
"delta" which indicates duration from time when the time stats
is updated last time to current time.

  - If delta is less than tick length, use obtained time stats
as if it was sampled in tick interrupt recently happened.

  - If delta is greater than tick, perform update of time stats
as if it emulates tick for sleeping observed cpu.

  - As the result the rate of updating time stats by observer is
limited to once per tick. In other words, in case if there is
observer who are monitoring sleeping cpu, we leave tick
emulation job during idle to the observer.

I confirmed this patch fix the monotonicity of /proc/stats, by
running reproducer and stressor for a day. The rate of reproduce
is different for different system, but in my case, running
"git gc" on kernel source repository aside of checker works fine.

Thanks,
H.Seto

Signed-off-by: Hidetoshi Seto 
Reported-by: Fernando Luis Vazquez Cao 
Reported-by: Tetsuo Handa 
Cc: Frederic Weisbecker 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Arjan van de Ven 
Cc: Oleg Nesterov 
---
 fs/proc/stat.c   |   16 +++--
 include/linux/tick.h |4 ++
 kernel/time/tick-sched.c |   79 ++
 3 files changed, 89 insertions(+), 10 deletions(-)

diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index 6f599c6..3dbe282 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -45,32 +45,28 @@ static cputime64_t get_iowait_time(int cpu)
 
 static u64 get_idle_time(int cpu)
 {
-   u64 idle, idle_time = -1ULL;
+   u64 idle = -1ULL;
 
if (cpu_online(cpu))
-   idle_time = get_cpu_idle_time_us(cpu, NULL);
+   idle = get_cpu_idle_time_coarse(cpu);
 
-   if (idle_time == -1ULL)
+   if (idle == -1ULL)
/* !NO_HZ or cpu offline so we can rely on cpustat.idle */
idle = kcpustat_cpu(cpu).cpustat[CPUTIME_IDLE];
-   else
-   idle = usecs_to_cputime64(idle_time);
 
return idle;
 }
 
 static u64 get_iowait_time(int cpu)
 {
-   u64 iowait, iowait_time = -1ULL;
+   u64 iowait = -1ULL;
 
if (cpu_online(cpu))
-   iowait_time = get_cpu_iowait_time_us(cpu, NULL);
+   iowait = get_cpu_iowait_time_coarse(cpu);
 
-   if (iowait_time == -1ULL)
+   if (iowait == -1ULL)
/* !NO_HZ or cpu offline so we can rely on cpustat.iowait */
iowait = kcpustat_cpu(cpu).cpustat[CPUTIME_IOWAIT];
-   else
-   iowait = usecs_to_cputime64(iowait_time);
 
return iowait;
 }
diff --git a/include/linux/tick.h b/include/linux/tick.h
index f6f4ac1..3b4674d 100644
--- a/include/linux/tick.h
+++ b/include/linux/tick.h
@@ -140,6 +140,8 @@ extern void tick_nohz_irq_exit(void);
 extern ktime_t tick_nohz_get_sleep_length(void);
 extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
 extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
+extern u64 get_cpu_idle_time_coarse(int cpu);
+extern u64 get_cpu_iowait_time_coarse(int cpu);
 
 # else /* !CONFIG_NO_HZ_COMMON */
 static inline int tick_nohz_tick_stopped(void)
@@ -158,6 +160,8 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
 }
 static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
 static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
+static inline u64 get_cpu_idle_time_coarse(int cpu) { return -1; }
+static inline u64 get_cpu_iowait_time_coarse(int cpu) { return -1; }
 # endif /* !CONFIG_NO_HZ_COMMON */
 
 #ifdef CONFIG_NO_HZ_FULL
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index da37125..178ffdc 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -574,6 +574,85 @@ u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time)
 }
 EXPORT_SYMBOL_GPL(get_cpu_i

[PATCH 0/2] nohz: fix idle accounting in NO_HZ kernels

[Hidetoshi Seto]

Hi all,

This patch set (based on v3.14-rc7) will fix an issue that
idle/iowait of /proc/stat can go backward. Originally reported
by Tetsuo and Fernando at last year, Mar 2013.

Reviews are welcome.

Thanks,
H.Seto


Hidetoshi Seto (2):
  nohz: use seqlock to avoid race on idle time stats
  nohz, procfs: introduce get_cpu_idle/iowait_time_coarse

 fs/proc/stat.c   |   16 ++---
 include/linux/tick.h |5 ++
 kernel/time/tick-sched.c |  171 --
 3 files changed, 161 insertions(+), 31 deletions(-)

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

Re: [PATCH -tip v8 07/26] [BUGFIX] x86: Prohibit probing on thunk functions and restore

[Masami Hiramatsu]

(2014/03/22 10:00), Steven Rostedt wrote:
> On Wed, 05 Mar 2014 20:59:32 +0900
> Masami Hiramatsu  wrote:
> 
>>  thunk_ra trace_hardirqs_on_thunk,trace_hardirqs_on_caller
>> diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
>> index a63efd6..92d9fea 100644
>> --- a/arch/x86/lib/thunk_64.S
>> +++ b/arch/x86/lib/thunk_64.S
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  /* rdi: arg1 ... normal C conventions. rax is saved/restored. */
>>  .macro THUNK name, func, put_ret_addr_in_rdi=0
>> @@ -25,6 +26,7 @@
>>  call \func
>>  jmp  restore
>>  CFI_ENDPROC
>> +_ASM_NOKPROBE(\name)
>>  .endm
>>  
>>  #ifdef CONFIG_TRACE_IRQFLAGS
>> @@ -43,3 +45,4 @@ restore:
>>  RESTORE_ARGS
>>  ret
>>  CFI_ENDPROC
>> +_ASM_NOKPROBE(restore)
>>
> 
> Does kallsyms return something for this? I'm curious to what it does.
> It might find something that we didn't expect. Do you have debug code
> to list out all the black listed items found at boot up?

Yes, with [19/26] the blacklisted functions are shown in debugfs
(kprobes/blacklist) :)

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH 2/3] ARM: dts: vf610-twr: Add PWM0's pinctrl node

[Shawn Guo]

On Mon, Mar 24, 2014 at 02:52:56AM +, li.xi...@freescale.com wrote:
> 
> > Subject: Re: [PATCH 2/3] ARM: dts: vf610-twr: Add PWM0's pinctrl node
> > 
> > On Thu, Mar 20, 2014 at 01:12:04PM +0800, Xiubo Li wrote:
> > > Signed-off-by: Xiubo Li 
> > 
> > Patch #2 and #3 can be reasonably merged into one.
> > 
> 
> Yes, they are.
> 
> But the Patch #2 is a new one, not reviewed by Sascha Hauer and Yao Yuan.
> I'm not sure could it be merged with Patch #3 ? Or just split them into
> Two patches like this ?

Okay, since you have some reason for doing that.

Shawn

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

RE: [PATCH 1/3] ARM: dts: vf610: Add Freescale FTM PWM node.

[li.xi...@freescale.com]

> Subject: Re: [PATCH 1/3] ARM: dts: vf610: Add Freescale FTM PWM node.
> 
> On Thu, Mar 20, 2014 at 01:12:03PM +0800, Xiubo Li wrote:
> > This adds devicetree node for VF610, and there are 8 channels
> > supported.
> >
> > Signed-off-by: Xiubo Li 
> > Reviewed-by: Sascha Hauer 
> > Reviewed-by: Yuan Yao 
> 
> Please copy list linux-arm-kernel instead of linux-kernel on arch/arm/
> changes, and also be noted that my email and git addresses just got
> updated [1].
> 

Okey.

> > ---
> >  arch/arm/boot/dts/vf610.dtsi | 13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> > index acf544e..ccc6d35 100644
> > --- a/arch/arm/boot/dts/vf610.dtsi
> > +++ b/arch/arm/boot/dts/vf610.dtsi
> > @@ -192,6 +192,19 @@
> > status = "disabled";
> > };
> >
> > +   pwm0: pwm@40038000 {
> 
> The node should be sorted in unit-address.  So shouldn't it be put right
> after pit node?
> 

Yes, I will fix it.

Thanks,

BRs,
Xiubo


> Shawn
> 
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f1c
> 12837220c54c8d7138a4ee4a08c1ec67b68a2
> 
> > +   compatible = "fsl,vf610-ftm-pwm";
> > +   #pwm-cells = <3>;
> > +   reg = <0x40038000 0x1000>;
> > +   clock-names = "ftm_sys", "ftm_ext",
> > + "ftm_fix", "ftm_cnt_clk_en";
> > +   clocks = <&clks VF610_CLK_FTM0>,
> > +   <&clks VF610_CLK_FTM0_EXT_SEL>,
> > +   <&clks VF610_CLK_FTM0_FIX_SEL>,
> > +   <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
> > +   status = "disabled";
> > +   };
> > +
> > wdog@4003e000 {
> > compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
> > reg = <0x4003e000 0x1000>;
> > --
> > 1.8.4
> >
> >

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

RE: [PATCH 2/3] ARM: dts: vf610-twr: Add PWM0's pinctrl node

[li.xi...@freescale.com]

> Subject: Re: [PATCH 2/3] ARM: dts: vf610-twr: Add PWM0's pinctrl node
> 
> On Thu, Mar 20, 2014 at 01:12:04PM +0800, Xiubo Li wrote:
> > Signed-off-by: Xiubo Li 
> 
> Patch #2 and #3 can be reasonably merged into one.
> 

Yes, they are.

But the Patch #2 is a new one, not reviewed by Sascha Hauer and Yao Yuan.
I'm not sure could it be merged with Patch #3 ? Or just split them into
Two patches like this ?

Thanks,

BRs
Xiubo

> Shawn
> 
> > ---
> >  arch/arm/boot/dts/vf610-twr.dts | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-
> twr.dts
> > index f3af8ea..3fabdb5 100644
> > --- a/arch/arm/boot/dts/vf610-twr.dts
> > +++ b/arch/arm/boot/dts/vf610-twr.dts
> > @@ -213,6 +213,17 @@
> > >;
> > };
> >
> > +   pinctrl_pwm0: pwm0grp {
> > +   fsl,pins = <
> > +   VF610_PAD_PTB0__FTM0_CH00x1582
> > +   VF610_PAD_PTB1__FTM0_CH10x1582
> > +   VF610_PAD_PTB2__FTM0_CH20x1582
> > +   VF610_PAD_PTB3__FTM0_CH30x1582
> > +   VF610_PAD_PTB6__FTM0_CH60x1582
> > +   VF610_PAD_PTB7__FTM0_CH70x1582
> > +   >;
> > +   };
> > +
> > pinctrl_sai2: sai2grp {
> > fsl,pins = <
> > VF610_PAD_PTA16__SAI2_TX_BCLK   0x02ed
> > --
> > 1.8.4
> >
> >

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

Re: [RFC] csum experts, csum_replace2() is too expensive

[Eric Dumazet]

On Fri, 2014-03-21 at 14:52 -0400, David Miller wrote:
> From: Eric Dumazet 
> Date: Fri, 21 Mar 2014 05:50:50 -0700
> 
> > It looks like a barrier() would be more appropriate.
> 
> barrier() == __asm__ __volatile__(:::"memory")

Indeed, but now you mention it, ip_fast_csum() do not uses volatile
keyword on x86_64, and has no "m" constraint either.

This means that for the following hypothetical networking code :

void foobar(struct iphdr *iph, __be16 newlen, __be16 newid)
{
iph->tot_len = newlen;
iph->check = 0;
iph->check = ip_fast_csum((u8 *)iph, 5);

pr_err("%p\n", iph);

iph->id = newid;
iph->check = 0;
iph->check = ip_fast_csum((u8 *)iph, 5);
}


ip_fast_csum() is done _once_ only.

Following patch seems needed. Thats one another call for x86 code factorization 
...

diff --git a/arch/x86/include/asm/checksum_64.h 
b/arch/x86/include/asm/checksum_64.h
index e6fd8a026c7b..c67778544880 100644
--- a/arch/x86/include/asm/checksum_64.h
+++ b/arch/x86/include/asm/checksum_64.h
@@ -46,7 +46,7 @@ static inline __sum16 ip_fast_csum(const void *iph, unsigned 
int ihl)
 {
unsigned int sum;
 
-   asm("  movl (%1), %0\n"
+   asm volatile("  movl (%1), %0\n"
"  subl $4, %2\n"
"  jbe 2f\n"
"  addl 4(%1), %0\n"


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

Re: [PATCH 2/3] ARM: dts: vf610-twr: Add PWM0's pinctrl node

[Shawn Guo]

On Thu, Mar 20, 2014 at 01:12:04PM +0800, Xiubo Li wrote:
> Signed-off-by: Xiubo Li 

Patch #2 and #3 can be reasonably merged into one.

Shawn

> ---
>  arch/arm/boot/dts/vf610-twr.dts | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
> index f3af8ea..3fabdb5 100644
> --- a/arch/arm/boot/dts/vf610-twr.dts
> +++ b/arch/arm/boot/dts/vf610-twr.dts
> @@ -213,6 +213,17 @@
>   >;
>   };
>  
> + pinctrl_pwm0: pwm0grp {
> + fsl,pins = <
> + VF610_PAD_PTB0__FTM0_CH00x1582
> + VF610_PAD_PTB1__FTM0_CH10x1582
> + VF610_PAD_PTB2__FTM0_CH20x1582
> + VF610_PAD_PTB3__FTM0_CH30x1582
> + VF610_PAD_PTB6__FTM0_CH60x1582
> + VF610_PAD_PTB7__FTM0_CH70x1582
> + >;
> + };
> +
>   pinctrl_sai2: sai2grp {
>   fsl,pins = <
>   VF610_PAD_PTA16__SAI2_TX_BCLK   0x02ed
> -- 
> 1.8.4
> 
> 

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

Re: [PATCH 1/3] ARM: dts: vf610: Add Freescale FTM PWM node.

[Shawn Guo]

On Thu, Mar 20, 2014 at 01:12:03PM +0800, Xiubo Li wrote:
> This adds devicetree node for VF610, and there are 8 channels
> supported.
> 
> Signed-off-by: Xiubo Li 
> Reviewed-by: Sascha Hauer 
> Reviewed-by: Yuan Yao 

Please copy list linux-arm-kernel instead of linux-kernel on arch/arm/
changes, and also be noted that my email and git addresses just got
updated [1].

> ---
>  arch/arm/boot/dts/vf610.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index acf544e..ccc6d35 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -192,6 +192,19 @@
>   status = "disabled";
>   };
>  
> + pwm0: pwm@40038000 {

The node should be sorted in unit-address.  So shouldn't it be put right
after pit node?

Shawn

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f1c12837220c54c8d7138a4ee4a08c1ec67b68a2

> + compatible = "fsl,vf610-ftm-pwm";
> + #pwm-cells = <3>;
> + reg = <0x40038000 0x1000>;
> + clock-names = "ftm_sys", "ftm_ext",
> +   "ftm_fix", "ftm_cnt_clk_en";
> + clocks = <&clks VF610_CLK_FTM0>,
> + <&clks VF610_CLK_FTM0_EXT_SEL>,
> + <&clks VF610_CLK_FTM0_FIX_SEL>,
> + <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
> + status = "disabled";
> + };
> +
>   wdog@4003e000 {
>   compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
>   reg = <0x4003e000 0x1000>;
> -- 
> 1.8.4
> 
> 

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

Re: [PATCH] #CleanUp non-gender-neutral README

[Sarah Sharp]

http://knowyourmeme.com/memes/events/c-plus-equality-c

Don't feed the trolls.

>  From: Feminist-Software-Foundation 
> 
> 
> This patch started as an effort inspired by EthicalCode's #CleanUpGitHub 
> project  to find and replace 
> either hateful, hurtful or discriminatory text in GitHub repositories.  
> The Linux kernel, being the de facto crown jewel of FOSS, deserves 
> better than to conform to non-gender-neutral pronouns and articles in 
> its README.  This patch rectifies that.
> 
> We are the Feminist Software Foundation.  We are the inventor of C+=, 
> world's first feminist programming language 
> ).  As 
> our latest effort, we are lending our help to a very popular feminist 
> phenomenon in the programming scene: purging popular FOSS repositories 
> of their Patriarchal influences.
> 
> As reported by several developers, Linux's kernel development does not 
> follow the activities on GitHub.  Whereby, we are submitting this patch 
> to the LKML in hope that this will garner a more professional response, 
> in contrast to the blatant sexism and booing that this patch has 
> received from the GitHub brogrammer community.
> 
> Singed-off-by: Feminist-Software-Foundation 
> 
> ---
> --- README.orig   2014-03-24 00:28:33.506830489 +
> +++ README2014-03-24 00:27:37.754554028 +
> @@ -1,64 +1,64 @@
>   Linux kernel release 3.x 
> 
> -These are the release notes for Linux version 3.  Read them carefully,
> -as they tell you what this is all about, explain how to install the
> +These are xhe release notes for Linux version 3.  Read xhem carefully,
> +as xhey tell you what this is all about, explain how to install xhe
>   kernel, and what to do if something goes wrong.
> 
>   WHAT IS LINUX?
> 
> -  Linux is a clone of the operating system Unix, written from scratch 
> by
> +  Linux is a clone of xhe operating system Unix, written from scratch 
> by
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] scripts: objdiff: detect object code changes between two commits

[Jason Cooper]

objdiff is useful when doing large code cleanups.  For example, when
removing checkpatch warnings and errors from new drivers in the staging
tree.

objdiff can be used in conjunction with a git rebase to confirm that
each commit made no changes to the resulting object code.  It has the
same return values as diff(1).

This was written specifically to support adding the skein and threefish
cryto drivers to the staging tree.  I needed a programmatic way to
confirm that commits changing >90% of the lines didn't inadvertently
change the code.

Signed-off-by: Jason Cooper 
---
Changes from RFC:

 - separated from staging/skein series

 - assume 'HEAD^ HEAD' for 'objdiff diff' w/o args.

Original submission here:

  
https://lkml.kernel.org/r/cc773270b6481ffe69516d994fbe98c13bcfdb5a.1394570067.git.ja...@lakedaemon.net

Example usage here:

  https://lkml.kernel.org/r/20140312165501.gc7...@titan.lakedaemon.net

thx,

Jason.

 scripts/objdiff | 131 
 1 file changed, 131 insertions(+)
 create mode 100755 scripts/objdiff

diff --git a/scripts/objdiff b/scripts/objdiff
new file mode 100755
index ..c5d22b1814ba
--- /dev/null
+++ b/scripts/objdiff
@@ -0,0 +1,131 @@
+#!/bin/bash
+
+# objdiff - a small script for validating that a commit or series of commits
+# didn't change object code.
+#
+# Copyright 2014, Jason Cooper 
+#
+# Licensed under the terms of the GNU GPL version 2
+
+# usage example:
+#
+# $ git checkout COMMIT_A
+# $ 
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ git checkout COMMIT_B
+# $ 
+# $ ./scripts/objdiff record path/to/*.o
+#
+# $ ./scripts/objdiff diff COMMIT_A COMMIT_B
+# $
+
+# And to clean up (everything is in /tmp/objdiff-*)
+# $ ./scripts/objdiff clean all
+
+usage() {
+   echo "Usage: $0  "
+   echo "  record"
+   echo "  diff   "
+   echo "  clean all | "
+   exit 1
+}
+
+dorecord() {
+   [ $# -eq 0 ] && usage
+
+   FILES="$*"
+
+   CMT="`git rev-parse --short HEAD`"
+
+   OBJDUMP="${CROSS_COMPILE}objdump"
+   OBJDIFFD="/tmp/objdiff-$CMT"
+
+   [ ! -d "$OBJDIFFD" ] && mkdir -p "$OBJDIFFD"
+
+   for f in $FILES; do
+   dn="${f%/*}"
+   bn="${f##*/}"
+
+   [ ! -d "$OBJDIFFD/$dn" ] && mkdir -p "$OBJDIFFD/$dn"
+
+   # remove addresses for a more clear diff
+   # 
http://dummdida.tumblr.com/post/60924060451/binary-diff-between-libc-from-scientificlinux-and
+   $OBJDUMP -D "$f" | sed "s/^[[:space:]]\+[0-9a-f]\+//" \
+   >"$OBJDIFFD/$dn/$bn"
+
+   # force rebuild
+   rm -f "$f"
+   done
+}
+
+dodiff() {
+   [ $# -ne 2 ] && [ $# -ne 0 ] && usage
+
+   if [ $# -eq 0 ]; then
+   SRC="`git rev-parse --short HEAD^`"
+   DST="`git rev-parse --short HEAD`"
+   else
+   SRC="`git rev-parse --short $1`"
+   DST="`git rev-parse --short $2`"
+   fi
+
+   DIFF="`which colordiff`"
+
+   if [ ${#DIFF} -eq 0 ] || [ ! -x "$DIFF" ]; then
+   DIFF="`which diff`"
+   fi
+
+   SRCD="/tmp/objdiff-$SRC"
+   DSTD="/tmp/objdiff-$DST"
+
+   if [ ! -d "$SRCD" ]; then
+   echo "ERROR: $SRCD doesn't exist"
+   exit 1
+   fi
+
+   if [ ! -d "$DSTD" ]; then
+   echo "ERROR: $DSTD doesn't exist"
+   exit 1
+   fi
+
+   $DIFF -Nurd $SRCD $DSTD
+}
+
+doclean() {
+   [ $# -eq 0 ] && usage
+   [ $# -gt 1 ] && usage
+
+   if [ "x$1" = "xall" ]; then
+   rm -rf /tmp/objdiff-*
+   else
+   CMT="`git rev-parse --short $1`"
+
+   if [ -d "/tmp/objdiff-$CMT" ]; then
+   rm -rf /tmp/objdiff-$CMT
+   else
+   echo "$CMT not found"
+   fi
+   fi
+}
+
+[ $# -eq 0 ] &&usage
+
+case "$1" in
+   record)
+   shift
+   dorecord $*
+   ;;
+   diff)
+   shift
+   dodiff $*
+   ;;
+   clean)
+   shift
+   doclean $*
+   ;;
+   *)
+   echo "Unrecognized command '$1'"
+   exit 1
+   ;;
+esac
-- 
1.9.1

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

Re: [PATCH] ARM: shmobile: r8a7778/bockw: Move "select RENESAS_INTC_IRQPIN" under SoC

[Simon Horman]

On Sun, Mar 23, 2014 at 08:36:18PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> Move the "select RENESAS_INTC_IRQPIN" from the two bockw-specific sections
> to the one r8a7778-specific section, like is done for the other SoCs.
> 
> Signed-off-by: Geert Uytterhoeven 

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

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

[Stephen Rothwell]

Hi Dave,

Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/intel_ddi.c and
drivers/gpu/drm/i915/intel_dp.c between commit 825938307f81 ("Revert
"drm/i915: don't touch the VDD when disabling the panel"") from Linus'
tree and commits 4be7378004a0 ("drm/i915: drop ironlake_ prefix from edp
panel/backlight functions"), dce56b3c626f ("drm/i915: save some time when
waiting the eDP timings") and b3064154dfd3 ("drm/i915: Don't just say it,
actually force edp vdd") from the drm tree.

This latter commit in the drm tree seems to be solving the same problem
as the one in Linus' tree (but slightly differently), so I just
effectively dropped the patch from Linus' tree and can carry the fix as
necessary (no action is required).

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


pgpzjuYxuMhvz.pgp
Description: PGP signature

Re: [PATCH 2/2] ARM: shmobile: kzm9g-reference dts: Use KEY_* macros for gpio-keys

[Simon Horman]

On Sun, Mar 23, 2014 at 08:35:02PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> Signed-off-by: Geert Uytterhoeven 

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

Re: [PATCH 1/2] ARM: shmobile: armadillo-reference dts: Use KEY_* macros for gpio-keys

[Simon Horman]

On Sun, Mar 23, 2014 at 08:35:01PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> Signed-off-by: Geert Uytterhoeven 

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

[GIT PULL] ACPI and power management updates for v3.15-rc1

[Rafael Wysocki]

Hi Linus,

I'll be travelling during the whole next week, so just in case you release
the final 3.14 before I'm back home, please consider pulling from the tag at

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-3.15-rc1

to receive ACPI and power management updates for v3.15-rc1 with
top-most commit 0ecfe310f4517d7505599be738158087c165be7c

 Merge branch 'pm-devfreq'

on top of commit dcb99fd9b08cfe1afe426af4d8d3cbc429190f15

 Linux 3.14-rc7

The majority of this material spent some time in linux-next, some of it even
several weeks.  There are a few relatively fresh commits in it, but they are
mostly fixes and simple cleanups.

ACPI took the lead this time, both in terms of the number of commits and the
number of modified lines of code, cpufreq follows and there are a few changes
in the PM core and in cpuidle too.

A new feature that already got some LWN.net's attention is the device PM QoS
extension allowing latency tolerance requirements to be propagated from leaf
devices to their ancestors with hardware interfaces for specifying latency
tolerance.  That should help systems with hardware-driven power management
to avoid going too far with it in cases when there are latency tolerance
constraints.

There also are some significant changes in the ACPI core related to the way
in which hotplug notifications are handled.  They affect PCI hotplug (ACPIPHP)
and the ACPI dock station code too.  The bottom line is that all those
notification now go through the root notify handler and are propagated to
the interested subsystems by means of callbacks instead of having to install
a notify handler for each device object that we can potentially get hotplug
notifications for.

In addition to that ACPICA will now advertise "Windows 2013" compatibility
for _OSI, because some systems out there don't work correctly if that is not
done (some of them don't even boot).

On the system suspend side of things, all of the device suspend and resume
callbacks, except for ->prepare() and ->complete(), are now going to be
executed asynchronously as that turns out to speed up system suspend and
resume on some platforms quite significantly and we have a few more
optimizations in that area.

Apart from that, there are some new device IDs and fixes and cleanups all
over.  In particular, the system suspend and resume handling by cpufreq
should be improved and the cpuidle menu governor should be a bit more
robust now.

Specifics:

 - Device PM QoS support for latency tolerance constraints on systems with
   hardware interfaces allowing such constraints to be specified.  That is
   necessary to prevent hardware-driven power management from becoming
   overly aggressive on some systems and to prevent power management
   features leading to excessive latencies from being used in some cases.

 - Consolidation of the handling of ACPI hotplug notifications for device
   objects.  This causes all device hotplug notifications to go through
   the root notify handler (that was executed for all of them anyway
   before) that propagates them to individual subsystems, if necessary,
   by executing callbacks provided by those subsystems (those callbacks
   are associated with struct acpi_device objects during device
   enumeration).  As a result, the code in question becomes both smaller
   in size and more straightforward and all of those changes should not
   affect users.

 - ACPICA update, including fixes related to the handling of _PRT in cases
   when it is broken and the addition of "Windows 2013" to the list of
   supported "features" for _OSI (which is necessary to support systems
   that work incorrectly or don't even boot without it).  Changes from
   Bob Moore and Lv Zheng.

 - Consolidation of ACPI _OST handling from Jiang Liu.

 - ACPI battery and AC fixes allowing unusual system configurations to
   be handled by that code from Alexander Mezin.

 - New device IDs for the ACPI LPSS driver from Chiau Ee Chew.

 - ACPI fan and thermal optimizations related to system suspend and resume
   from Aaron Lu.

 - Cleanups related to ACPI video from Jean Delvare.

 - Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan Tianyu,
   Paul Bolle, Tomasz Nowicki.

 - Intel RAPL (Running Average Power Limits) driver cleanups from Jacob Pan.

 - intel_pstate fixes and cleanups from Dirk Brandewie.

 - cpufreq fixes related to system suspend/resume handling from Viresh Kumar.

 - cpufreq core fixes and cleanups from Viresh Kumar, Stratos Karafotis,
   Saravana Kannan, Rashika Kheria, Joe Perches.

 - cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob Herring.

 - cpuidle fixes related to the menu governor from Tuukka Tikkanen.

 - cpuidle fix related to coupled CPUs handling from Paul Burton.

 - Asynchronous execution of all device suspend and resume callbacks,
   except for ->prepare and ->complete, during system suspend and resume
   from Chuansheng Liu.

 - Delayed resuming of runtime-suspended devices d

Re: [PATCH -next] clocksource: CMT, MTU2, TMU and STI should depend on GENERIC_CLOCKEVENTS

[Simon Horman]

On Thu, Mar 20, 2014 at 03:05:50PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> If GENERIC_CLOCKEVENTS=n:
> 
> drivers/clocksource/sh_cmt.c:54:28: error: field 'ced' has incomplete type
> drivers/clocksource/sh_cmt.c: In function 'sh_cmt_interrupt':
> drivers/clocksource/sh_cmt.c:407:23: error: 'CLOCK_EVT_MODE_ONESHOT' 
> undeclared (first use in this function)
> 
> drivers/clocksource/sh_mtu2.c:44:28: error: field 'ced' has incomplete type
> drivers/clocksource/sh_mtu2.c: In function 'ced_to_sh_mtu2':
> drivers/clocksource/sh_mtu2.c:184:70: warning: initialization from 
> incompatible pointer type [enabled by default]
> drivers/clocksource/sh_mtu2.c: At top level:
> drivers/clocksource/sh_mtu2.c:188:16: warning: 'enum clock_event_mode' 
> declared inside parameter list [enabled by default]
> 
> drivers/clocksource/sh_tmu.c:45:28: error: field 'ced' has incomplete type
> drivers/clocksource/sh_tmu.c: In function 'sh_tmu_interrupt':
> drivers/clocksource/sh_tmu.c:207:21: error: 'CLOCK_EVT_MODE_ONESHOT' 
> undeclared (first use in this function)
> 
> drivers/clocksource/em_sti.c:44:28: error: field 'ced' has incomplete type
> drivers/clocksource/em_sti.c: In function 'ced_to_em_sti':
> drivers/clocksource/em_sti.c:251:69: warning: initialization from 
> incompatible pointer type [enabled by default]
> drivers/clocksource/em_sti.c: At top level:
> drivers/clocksource/em_sti.c:255:16: warning: 'enum clock_event_mode' 
> declared inside parameter list [enabled by default]
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Simon Horman 

> ---
> http://kisskb.ellerman.id.au/kisskb/buildresult/10807476/
> 
>  drivers/clocksource/Kconfig |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 143f1aff486b..837b7804775e 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -158,6 +158,7 @@ config SYS_SUPPORTS_EM_STI
>  
>  config SH_TIMER_CMT
>   bool "Renesas CMT timer driver" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
>   default SYS_SUPPORTS_SH_CMT
>   help
> This enables build of a clocksource and clockevent driver for
> @@ -166,6 +167,7 @@ config SH_TIMER_CMT
>  
>  config SH_TIMER_MTU2
>   bool "Renesas MTU2 timer driver" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
>   default SYS_SUPPORTS_SH_MTU2
>   help
> This enables build of a clockevent driver for the Multi-Function
> @@ -174,6 +176,7 @@ config SH_TIMER_MTU2
>  
>  config SH_TIMER_TMU
>   bool "Renesas TMU timer driver" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
>   default SYS_SUPPORTS_SH_TMU
>   help
> This enables build of a clocksource and clockevent driver for
> @@ -182,6 +185,7 @@ config SH_TIMER_TMU
>  
>  config EM_TIMER_STI
>   bool "Renesas STI timer driver" if COMPILE_TEST
> + depends on GENERIC_CLOCKEVENTS
>   default SYS_SUPPORTS_EM_STI
>   help
> This enables build of a clocksource and clockevent driver for
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 03/26] kprobes: Prohibit probing on .entry.text code

[Masami Hiramatsu]

(2014/03/22 7:04), Steven Rostedt wrote:
> On Wed, 05 Mar 2014 20:59:04 +0900
> Masami Hiramatsu  wrote:
> 
> 
>>  struct kprobe_insn_cache {
>>  struct mutex mutex;
>> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
>> index ceeadfc..5b5ac76 100644
>> --- a/kernel/kprobes.c
>> +++ b/kernel/kprobes.c
>> @@ -96,9 +96,6 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned 
>> long hash)
>>  static struct kprobe_blackpoint kprobe_blacklist[] = {
>>  {"preempt_schedule",},
>>  {"native_get_debugreg",},
>> -{"irq_entries_start",},
>> -{"common_interrupt",},
>> -{"mcount",},/* mcount can be called from everywhere */
> 
> Is mcount in the entry.text section? Also, what about ftrace_caller and
> friends.

I saw mcount(and ftrace_caller) in arch/x86/kernel/entry_*.S, and
almost all code in it are in ".entry.text" section as far as I can see,
or do I miss something?

Thank you,

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH V4 07/11] ACPI: use platform bus as the default bus for _HID enumeration

[Rafael J. Wysocki]

On Monday, March 17, 2014 03:49:36 PM Zhang Rui wrote:
> Because of the growing demand for enumerating ACPI devices to platform bus,
> this patch changes the code to enumerate ACPI devices with _HID to
> platform bus by default, unless the device already has a scan handler 
> attached.

I think we need to be more careful here still.

For example, we shouldn't create platform devices for ACPI device objects that
correspond to I2C devices (or any other "simple peripheral bus" devices for that
matter).

> Signed-off-by: Zhang Rui 
> ---
>  drivers/acpi/acpi_platform.c |   28 
>  drivers/acpi/scan.c  |   12 ++--
>  2 files changed, 6 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index dbfe49e..33376a9 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -22,24 +22,6 @@
>  
>  ACPI_MODULE_NAME("platform");
>  
> -/*
> - * The following ACPI IDs are known to be suitable for representing as
> - * platform devices.
> - */
> -static const struct acpi_device_id acpi_platform_device_ids[] = {
> -
> - { "PNP0D40" },
> - { "ACPI0003" },
> - { "VPC2004" },
> - { "BCM4752" },
> -
> - /* Intel Smart Sound Technology */
> - { "INT33C8" },
> - { "80860F28" },
> -
> - { }
> -};
> -
>  /**
>   * acpi_create_platform_device - Create platform device for ACPI device node
>   * @adev: ACPI device node to create a platform device for.
> @@ -125,13 +107,3 @@ int acpi_create_platform_device(struct acpi_device *adev,
>   kfree(resources);
>   return 1;
>  }
> -
> -static struct acpi_scan_handler platform_handler = {
> - .ids = acpi_platform_device_ids,
> - .attach = acpi_create_platform_device,
> -};
> -
> -void __init acpi_platform_init(void)
> -{
> - acpi_scan_add_handler(&platform_handler);
> -}
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index e41b5e6..c0456e7 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -2028,14 +2028,15 @@ static int acpi_scan_attach_handler(struct 
> acpi_device *device)
>   handler = acpi_scan_match_handler(hwid->id, &devid);
>   if (handler) {
>   ret = handler->attach(device, devid);
> - if (ret > 0) {
> + if (ret > 0)
>   device->handler = handler;
> - break;
> - } else if (ret < 0) {
> - break;
> - }
> + if (ret)
> + goto end;
>   }
>   }
> +end:
> + if (device->pnp.type.platform_id && !device->handler)
> + acpi_create_platform_device(device, NULL);
>   return ret;
>  }
>  
> @@ -2191,7 +2192,6 @@ int __init acpi_scan_init(void)
>   acpi_pci_root_init();
>   acpi_pci_link_init();
>   acpi_processor_init();
> - acpi_platform_init();
>   acpi_lpss_init();
>   acpi_cmos_rtc_init();
>   acpi_container_init();
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] mmc: sdhci: don't read cd-gpio while holding spinlock

[Andrew Bresticker]

sdhci_request() and sdhci_card_event() read the cd-gpio via
mmc_gpio_get_cd(), which can sleep, while holding host->lock.
This may result in the following BUG:

  BUG: spinlock wrong CPU on CPU#2, kworker/u8:16/4296
  lock: 0xea6b9c80, .magic: dead4ead, .owner: kworker/u8:16/4296, .owner_cpu: 0
  CPU: 2 PID: 4296 Comm: kworker/u8:16 Tainted: G C   3.10.18 #137
  Workqueue: kmmcd mmc_rescan
  [<8020cf8c>] (unwind_backtrace+0x0/0x118) from [<8020a0c8>] 
(show_stack+0x20/0x24)
  [<8020a0c8>] (show_stack+0x20/0x24) from [<8075e5b8>] (dump_stack+0x20/0x28)
  [<8075e5b8>] (dump_stack+0x20/0x28) from [<804184a8>] (spin_dump+0x80/0x94)
  [<804184a8>] (spin_dump+0x80/0x94) from [<804184e8>] (spin_bug+0x2c/0x30)
  [<804184e8>] (spin_bug+0x2c/0x30) from [<80418790>] 
(do_raw_spin_unlock+0x94/0xd4)
  [<80418790>] (do_raw_spin_unlock+0x94/0xd4) from [<80761a44>] 
(_raw_spin_unlock_irqrestore+0x1c/0x24)
  [<80761a44>] (_raw_spin_unlock_irqrestore+0x1c/0x24) from [<805ff66c>] 
(sdhci_request+0x1c8/0x1d0)
  [<805ff66c>] (sdhci_request+0x1c8/0x1d0) from [<805ebb5c>] 
(mmc_start_request+0xec/0xf4)
  [<805ebb5c>] (mmc_start_request+0xec/0xf4) from [<805ebcbc>] 
(mmc_wait_for_req+0x80/0xf4)
  ...

Read the cd-gpio before acquiring the spinlock instead.

Signed-off-by: Andrew Bresticker 
---
 drivers/mmc/host/sdhci.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 04a5e25..328b250 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1340,6 +1340,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
u32 tuning_opcode;
 
host = mmc_priv(mmc);
+   present = mmc_gpio_get_cd(host->mmc);
 
sdhci_runtime_pm_get(host);
 
@@ -1371,7 +1372,6 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 * zero: cd-gpio is used, and card is removed
 * one: cd-gpio is used, and card is present
 */
-   present = mmc_gpio_get_cd(host->mmc);
if (present < 0) {
/* If polling, assume that the card is always present. */
if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -2082,15 +2082,16 @@ static void sdhci_card_event(struct mmc_host *mmc)
 {
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
+   int present;
 
/* First check if client has provided their own card event */
if (host->ops->card_event)
host->ops->card_event(host);
 
+   present = sdhci_get_cd(mmc);
spin_lock_irqsave(&host->lock, flags);
 
-   /* Check host->mrq first in case we are runtime suspended */
-   if (host->mrq && !sdhci_do_get_cd(host)) {
+   if (host->mrq && !present) {
pr_err("%s: Card removed during transfer!\n",
mmc_hostname(host->mmc));
pr_err("%s: Resetting controller.\n",
-- 
1.9.1.423.g4596e3a

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

Re: [patch 15/16] cpufreq: intel-pstate: Use del_timer_sync in intel_pstate_cpu_exit()

[Rafael J. Wysocki]

On Sunday, March 23, 2014 03:09:32 PM Thomas Gleixner wrote:
> We are about to free the data structure. Make sure no timer callback
> is running. I might be paranoid, but the ->exit callback can be
> invoked from so many places, that it is not entirely clear whether
> del_timer is always called on the cpu on which it is enqueued.
> 
> While looking through the call sites I noticed, that
> cpufreq_init_policy() can fail and invoke cpufreq_driver->exit() but
> it does not return the failure and the callsite happily proceeds.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: "Rafael J. Wysocki" 
> Cc: cpufreq 
> Cc: pm 

Dirk?

> ---
> 
>  drivers/cpufreq/intel_pstate.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: tip/drivers/cpufreq/intel_pstate.c
> ===
> --- tip.orig/drivers/cpufreq/intel_pstate.c
> +++ tip/drivers/cpufreq/intel_pstate.c
> @@ -777,7 +777,7 @@ static int intel_pstate_cpu_exit(struct
>  {
>   int cpu = policy->cpu;
>  
> - del_timer(&all_cpu_data[cpu]->timer);
> + del_timer_sync(&all_cpu_data[cpu]->timer);
>   kfree(all_cpu_data[cpu]);
>   all_cpu_data[cpu] = NULL;
>   return 0;
> 
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mmc: rtsx: add new cmd type handle and modify error handle

[micky_ching]

From: Micky Ching 

Add new command type(R1 without CRC) handle, without this
patch mmc card initialize will be failed.

Using a more careful handle in request timeout, this would
improve error recover capability. Debug info is printed
using non DMA mode, this would help print more accurately
for DMA command failed. Smatch warning was removed.

Micky Ching (2):
  mmc: rtsx: add R1-no-CRC mmc command type handle
  mmc: rtsx: modify error handle and remove smatch warnings

 drivers/mmc/host/rtsx_pci_sdmmc.c |  121 -
 1 file changed, 67 insertions(+), 54 deletions(-)

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

[PATCH 2/2] mmc: rtsx: modify error handle and remove smatch warnings

[micky_ching]

From: Micky Ching 

Using non-DMA dump-regs, which would be more exactly for DMA transfer failed.

More careful handle when cmd/data timeout, add stop(CMD12) cmd before go to
finish request when multi-rw timeout.

Remove some static checher warings.
on commit: 
drivers/mmc/host/rtsx_pci_sdmmc.c:194 sd_finish_request()
error: we previously assumed 'mrq' could be null (see line 158)
drivers/mmc/host/rtsx_pci_sdmmc.c:504 sd_get_rsp()
error: we previously assumed 'cmd' could be null (see line 434)
drivers/mmc/host/rtsx_pci_sdmmc.c:525 sd_pre_dma_transfer()
warn: we tested 'next' before and it was 'false'

Signed-off-by: Micky Ching 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |  118 -
 1 file changed, 64 insertions(+), 54 deletions(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 0d8904a..d00a94e 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -81,25 +81,23 @@ static inline void sd_clear_error(struct realtek_pci_sdmmc 
*host)
 }
 
 #ifdef DEBUG
+static inline void sd_print_reg(struct realtek_pci_sdmmc *host, u16 reg)
+{
+   u8 val;
+   if (rtsx_pci_read_register(host->pcr, reg, &val) < 0)
+   dev_dbg(sdmmc_dev(host), "read 0x%04x failed\n", reg);
+   else
+   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", reg, val);
+}
+
 static void sd_print_debug_regs(struct realtek_pci_sdmmc *host)
 {
-   struct rtsx_pcr *pcr = host->pcr;
u16 i;
-   u8 *ptr;
-
-   /* Print SD host internal registers */
-   rtsx_pci_init_cmd(pcr);
-   for (i = 0xFDA0; i <= 0xFDAE; i++)
-   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
-   for (i = 0xFD52; i <= 0xFD69; i++)
-   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
-   rtsx_pci_send_cmd(pcr, 100);
 
-   ptr = rtsx_pci_get_cmd_data(pcr);
for (i = 0xFDA0; i <= 0xFDAE; i++)
-   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   sd_print_reg(host, i);
for (i = 0xFD52; i <= 0xFD69; i++)
-   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   sd_print_reg(host, i);
 }
 #else
 #define sd_print_debug_regs(host)
@@ -125,19 +123,27 @@ static void sd_request_timeout(unsigned long host_addr)
spin_lock_irqsave(&host->lock, flags);
 
if (!host->mrq) {
-   dev_err(sdmmc_dev(host), "error: no request exist\n");
-   goto out;
+   dev_err(sdmmc_dev(host), "error: request not exist\n");
+   spin_unlock_irqrestore(&host->lock, flags);
+   return;
}
 
-   if (host->cmd)
+   if (host->cmd && host->data)
+   dev_err(sdmmc_dev(host), "error: cmd and data conflict\n");
+
+   if (host->cmd) {
host->cmd->error = -ETIMEDOUT;
-   if (host->data)
-   host->data->error = -ETIMEDOUT;
+   dev_dbg(sdmmc_dev(host), "timeout for cmd %d\n",
+   host->cmd->opcode);
+   tasklet_schedule(&host->cmd_tasklet);
+   }
 
-   dev_dbg(sdmmc_dev(host), "timeout for request\n");
+   if (host->data) {
+   host->data->error = -ETIMEDOUT;
+   dev_dbg(sdmmc_dev(host), "timeout for data transfer\n");
+   tasklet_schedule(&host->data_tasklet);
+   }
 
-out:
-   tasklet_schedule(&host->finish_tasklet);
spin_unlock_irqrestore(&host->lock, flags);
 }
 
@@ -157,7 +163,8 @@ static void sd_finish_request(unsigned long host_addr)
mrq = host->mrq;
if (!mrq) {
dev_err(sdmmc_dev(host), "error: no request need finish\n");
-   goto out;
+   spin_unlock_irqrestore(&host->lock, flags);
+   return;
}
 
cmd = mrq->cmd;
@@ -167,11 +174,6 @@ static void sd_finish_request(unsigned long host_addr)
(mrq->stop && mrq->stop->error) ||
(cmd && cmd->error) || (data && data->error);
 
-   if (any_error) {
-   rtsx_pci_stop_cmd(pcr);
-   sd_clear_error(host);
-   }
-
if (data) {
if (any_error)
data->bytes_xfered = 0;
@@ -188,7 +190,6 @@ static void sd_finish_request(unsigned long host_addr)
host->cmd = NULL;
host->data = NULL;
 
-out:
spin_unlock_irqrestore(&host->lock, flags);
mutex_unlock(&pcr->pcr_mutex);
mmc_request_done(host->mmc, mrq);
@@ -373,8 +374,11 @@ static void sd_send_cmd(struct realtek_pci_sdmmc *host, 
struct mmc_command *cmd)
if (cmd->opcode == SD_SWITCH_VOLTAGE) {
err = rtsx_pci_write_register(pcr, SD_BUS_STAT,
0xFF, SD_CLK_TOGGLE_EN);
-   if (err < 0)
+   if (err < 0) {
+   rtsx_pci_write_register(pcr, SD_BUS_STAT,
+   SD_CLK_TOGGLE_EN | SD_CLK_FORC

[PATCH 1/2] mmc: rtsx: add R1-no-CRC mmc command type handle

[micky_ching]

From: Micky Ching 

commit a27fbf2f067b0cd6f172c8b696b9a44c58bfaa7a

produced a cmd.flags unhandled in realtek pci host driver.
This will make MMC card failed initialize, this patch is
used to handle the new cmd.flags condition and MMC card can be used.

Signed-off-by: Micky Ching 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 5fb994f..0d8904a 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -346,6 +346,9 @@ static void sd_send_cmd(struct realtek_pci_sdmmc *host, 
struct mmc_command *cmd)
case MMC_RSP_R1:
rsp_type = SD_RSP_TYPE_R1;
break;
+   case MMC_RSP_R1 & ~MMC_RSP_CRC:
+   rsp_type = SD_RSP_TYPE_R1 | SD_NO_CHECK_CRC7;
+   break;
case MMC_RSP_R1B:
rsp_type = SD_RSP_TYPE_R1b;
break;
-- 
1.7.9.5

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

Re: [PATCHv4 0/5] devfreq: exynos: Fix minor issue and code clean to remove legacy method

[Chanwoo Choi]

Hi Tomasz,

On 03/22/2014 11:52 PM, Tomasz Figa wrote:
> Hi,
> 
> [fixing mistyped addresses of me and Bartlomiej]
> 
> On 20.03.2014 03:59, Chanwoo Choi wrote:
>> This patchset use SIMPLE_DEV_PM_OPS macro intead of legacy method and fix
>> probe fail if CONFIG_PM_OPP is disabled. Also, this patchset fix minor issue.
>>
>> Changes from v3:
>> - Discard patches related to DT support because DT support patch of patchset
>>don't satisfy the basic of dt concept. So, I'm going to implement DT 
>> support
>>patch regardless this patchset separately.
>> - Use SIMPLE_DEV_PM_OPS macro instead of SET_SYSTEM_SLEEP_PM_OPS macro
>> - Delete devfreq->profile->exit callback to improve readability when failure
>>happen in probe().
>> - Add exynos5 patch to clean code
>>
>> Changes from v2:
>> - Add detailed description to 
>> Documentation/devicetree/bindings/exynos4_bus.txt
>>and change patch description of patch#8
>> - Change the sequence of patchset in patch #1 ~ #4
>> - Fix minor issue
>>
>> Changes from v1:
>> - Add exynos4_bus.txt documentation for devicetree guide
>> - Fix probe failure if CONFIG_PM_OPP is disabled
>> - Fix typo and resource leak(regulator/clock/memory) when happening probe 
>> failure
>> - Add additionally comment for PPMU usage instead of previous PPC
>> - Split separate patch to remove ambiguous of patch
>>
>> Chanwoo Choi (5):
>>devfreq: exynos4: Fix bug of resource leak and code clean on probe()
>>devfreq: exynos4: Use SIMPLE_DEV_PM_OPS macro
>>devfreq: exynos4: Add CONFIG_PM_OPP dependency to fix probe fail
>>devfreq: exynos5: Use SIMPLE_DEV_PM_OPS macro
>>devfreq: exynos5: Add CONFIG_PM_OPP dependency to fix probe fail
>>
>>   drivers/devfreq/Kconfig  |  2 ++
>>   drivers/devfreq/exynos/exynos4_bus.c | 43 
>> ++--
>>   drivers/devfreq/exynos/exynos5_bus.c |  7 --
>>   3 files changed, 34 insertions(+), 18 deletions(-)
>>
> 
> Reviewed-by: Tomasz Figa 
> 

Thanks for your review always.

Best Regards,
Chanwoo Choi

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

btrfs: kernel BUG at fs/btrfs/extent_io.c:676!

[Sasha Levin]

Hi all,

While fuzzing with trinity inside KVM tools guest running latest -next kernel
I've stumbled on the following spew.

This is a result of a failed allocation in alloc_extent_state_atomic() which
triggers a BUG_ON when the return value is NULL. It's a bit weird that it
BUGs on failed allocations, since it's obviously not a critical failure.

[  447.705167] kernel BUG at fs/btrfs/extent_io.c:676!
[  447.706201] invalid opcode:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  447.707732] Dumping ftrace buffer:
[  447.708473](ftrace buffer empty)
[  447.709684] Modules linked in:
[  447.710246] CPU: 17 PID: 4195 Comm: kswapd17 Tainted: GW 
3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #265
[  447.710253] task: 88066be9b000 ti: 88066be82000 task.ti: 
88066be82000
[  447.710253] RIP:  clear_extent_bit (fs/btrfs/extent_io.c:676)
[  447.710253] RSP: :88066be83768  EFLAGS: 00010246
[  447.710253] RAX:  RBX: 00d00fff RCX: 0006
[  447.710253] RDX: 58e0 RSI: 88066be9bd60 RDI: 0286
[  447.710253] RBP: 88066be837e8 R08:  R09: 
[  447.710253] R10: 0001 R11: 454a4e495f544c55 R12: 01ff
[  447.710253] R13:  R14: 88007b89fd08 R15: 00d0
[  447.710253] FS:  () GS:8804acc0() 
knlGS:
[  447.710253] CS:  0010 DS:  ES:  CR0: 8005003b
[  447.710253] CR2: 02aec968 CR3: 05e29000 CR4: 06a0
[  447.710253] DR0: 00698000 DR1: 00698000 DR2: 
[  447.710253] DR3:  DR6: 0ff0 DR7: 0600
[  447.710253] Stack:
[  447.710253]  88066be83788 844fc4d5  
8804ab4800e8
[  447.710253]   0001 8804ab4800c8 
fbf7
[  447.710253]  88066be837c8  0006 
ea0007aaf340
[  447.710253] Call Trace:
[  447.710253]  ? _raw_spin_unlock (arch/x86/include/asm/preempt.h:98 
include/linux/spinlock_api_smp.h:152 kernel/locking/spinlock.c:183)
[  447.710253]  try_release_extent_mapping (fs/btrfs/extent_io.c:3998 
fs/btrfs/extent_io.c:4058)
[  447.710253]  __btrfs_releasepage (fs/btrfs/inode.c:7521)
[  447.710253]  btrfs_releasepage (fs/btrfs/inode.c:7534)
[  447.710253]  try_to_release_page (mm/filemap.c:2984)
[  447.710253]  invalidate_inode_page (mm/truncate.c:165 mm/truncate.c:215)
[  447.710253]  invalidate_mapping_pages (mm/truncate.c:517)
[  447.710253]  inode_lru_isolate (arch/x86/include/asm/current.h:14 
include/linux/swap.h:33 fs/inode.c:724)
[  447.710253]  ? insert_inode_locked (fs/inode.c:687)
[  447.710253]  list_lru_walk_node (mm/list_lru.c:89)
[  447.710253]  prune_icache_sb (fs/inode.c:759)
[  447.710253]  super_cache_scan (fs/super.c:96)
[  447.710253]  shrink_slab_node (mm/vmscan.c:306)
[  447.710253]  shrink_slab (mm/vmscan.c:381)
[  447.710253]  kswapd_shrink_zone (mm/vmscan.c:2909)
[  447.710253]  kswapd (mm/vmscan.c:3090 mm/vmscan.c:3296)
[  447.710253]  ? mem_cgroup_shrink_node_zone (mm/vmscan.c:3213)
[  447.710253]  kthread (kernel/kthread.c:219)
[  447.710253]  ? __tick_nohz_task_switch (arch/x86/include/asm/paravirt.h:809 
kernel/time/tick-sched.c:272)
[  447.710253]  ? kthread_create_on_node (kernel/kthread.c:185)
[  447.710253]  ret_from_fork (arch/x86/kernel/entry_64.S:555)
[  447.710253]  ? kthread_create_on_node (kernel/kthread.c:185)
[  447.710253] Code: e9 a9 00 00 00 0f 1f 00 48 39 c3 0f 82 87 00 00 00 4c 39 e3 0f 
83 7e 00 00 00 48 8b 7d a0 e8 45 ef ff ff 48 85 c0 49 89 c5 75 05 <0f> 0b 0f 1f 
00 48 8b 7d b0 48 8d 4b 01 48 89 c2 4c 89 f6 e8 c5
[  447.710253] RIP  clear_extent_bit (fs/btrfs/extent_io.c:676)
[  447.710253]  RSP 


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

[PATCH] #CleanUp non-gender-neutral README

[Feminist Software Foundation]

From: Feminist-Software-Foundation 



This patch started as an effort inspired by EthicalCode's #CleanUpGitHub 
project  to find and replace 
either hateful, hurtful or discriminatory text in GitHub repositories.  
The Linux kernel, being the de facto crown jewel of FOSS, deserves 
better than to conform to non-gender-neutral pronouns and articles in 
its README.  This patch rectifies that.


We are the Feminist Software Foundation.  We are the inventor of C+=, 
world's first feminist programming language 
).  As 
our latest effort, we are lending our help to a very popular feminist 
phenomenon in the programming scene: purging popular FOSS repositories 
of their Patriarchal influences.


As reported by several developers, Linux's kernel development does not 
follow the activities on GitHub.  Whereby, we are submitting this patch 
to the LKML in hope that this will garner a more professional response, 
in contrast to the blatant sexism and booing that this patch has 
received from the GitHub brogrammer community.


Singed-off-by: Feminist-Software-Foundation 


---
--- README.orig 2014-03-24 00:28:33.506830489 +
+++ README  2014-03-24 00:27:37.754554028 +
@@ -1,64 +1,64 @@
 Linux kernel release 3.x 

-These are the release notes for Linux version 3.  Read them carefully,
-as they tell you what this is all about, explain how to install the
+These are xhe release notes for Linux version 3.  Read xhem carefully,
+as xhey tell you what this is all about, explain how to install xhe
 kernel, and what to do if something goes wrong.

 WHAT IS LINUX?

-  Linux is a clone of the operating system Unix, written from scratch 
by
+  Linux is a clone of xhe operating system Unix, written from scratch 
by
   Linus Torvalds with assistance from a loosely-knit team of hackers 
across
-  the Net. It aims towards POSIX and Single UNIX Specification 
compliance.
+  xhe Net. It aims towards POSIX and Single UNIX Specification 
compliance.


-  It has all the features you would expect in a modern fully-fledged 
Unix,
+  It has all xhe features you would expect in a modern fully-fledged 
Unix,

   including true multitasking, virtual memory, shared libraries, demand
   loading, shared copy-on-write executables, proper memory management,
   and multistack networking including IPv4 and IPv6.

-  It is distributed under the GNU General Public License - see the
+  It is distributed under xhe GNU General Public License - see xhe
   accompanying COPYING file for more details.

 ON WHAT HARDWARE DOES IT RUN?

   Although originally developed first for 32-bit x86-based PCs (386 or 
higher),
-  today Linux also runs on (at least) the Compaq Alpha AXP, Sun SPARC 
and
+  today Linux also runs on (at least) xhe Compaq Alpha AXP, Sun SPARC 
and
   UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, 
Cell,
   IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS 
CRIS,

   Xtensa, Tilera TILE, AVR32 and Renesas M32R architectures.

   Linux is easily portable to most general-purpose 32- or 64-bit 
architectures
-  as long as they have a paged memory management unit (PMMU) and a port 
of the
-  GNU C compiler (gcc) (part of The GNU Compiler Collection, GCC). 
Linux has
+  as long as xhey have a paged memory management unit (PMMU) and a port 
of xhe
+  GNU C compiler (gcc) (part of xhe GNU Compiler Collection, GCC). 
Linux has
   also been ported to a number of architectures without a PMMU, 
although

   functionality is then obviously somewhat limited.
-  Linux has also been ported to itself. You can now run the kernel as a
+  Linux has also been ported to itself. You can now run xhe kernel as a
   userspace application - this is called UserMode Linux (UML).

 DOCUMENTATION:

  - There is a lot of documentation available both in electronic form on
-   the Internet and in books, both Linux-specific and pertaining to
-   general UNIX questions.  I'd recommend looking into the 
documentation
-   subdirectories on any Linux FTP site for the LDP (Linux 
Documentation

-   Project) books.  This README is not meant to be documentation on the
+   xhe Internet and in books, both Linux-specific and pertaining to
+   general UNIX questions.  I'd recommend looking into xhe 
documentation
+   subdirectories on any Linux FTP site for xhe LDP (Linux 
Documentation

+   Project) books.  This README is not meant to be documentation on xhe
system: there are much better sources available.

- - There are various README files in the Documentation/ subdirectory:
+ - There are various README files in xhe Documentation/ subdirectory:
these typically contain kernel-specific installation notes for some
drivers for example. See Documentation/00-INDEX for a list of what
-   is contained in each file.  Please read the Changes file, as it
-   contains information about the problems, which m

Re: Re: [PATCH -tip v8 01/26] [BUGFIX]kprobes/x86: Fix page-fault handling logic

[Masami Hiramatsu]

(2014/03/22 6:39), Steven Rostedt wrote:
>> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
>> index 79a3f96..b482e96 100644
>> --- a/arch/x86/kernel/kprobes/core.c
>> +++ b/arch/x86/kernel/kprobes/core.c
>> @@ -897,9 +897,7 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
>> int trapnr)
>>  struct kprobe *cur = kprobe_running();
>>  struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>  
>> -switch (kcb->kprobe_status) {
>> -case KPROBE_HIT_SS:
>> -case KPROBE_REENTER:
>> +if (unlikely(regs->ip == (unsigned long)cur->ainsn.insn)) {
> 
> I wonder if we should add a:
> 
>   WARN_ON(kcb->kprobe_status != KPROBE_HIT_SS &&
>   kcb->kprobe_status != KPROBE_REENTER);

Ah, right. I'll add it for verifying the status.

Thanks!

-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH/RFC 8/8] DT: Add documentation for exynos4-is camera-flash property

[Sakari Ailus]

Hi Jacek,

On Thu, Mar 20, 2014 at 03:51:10PM +0100, Jacek Anaszewski wrote:
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> ---
>  .../devicetree/bindings/media/samsung-fimc.txt |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt 
> b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> index 922d6f8..88f9287 100644
> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> @@ -108,6 +108,8 @@ Image sensor nodes
>  The sensor device nodes should be added to their control bus controller (e.g.
>  I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
>  using the common video interfaces bindings, defined in video-interfaces.txt.
> +If the sensor device has a led flash device associated with it then its 
> phandle
> +should be assigned to the camera-flash property.
>  
>  Example:
>  
> @@ -125,6 +127,7 @@ Example:
>   clock-frequency = <2400>;
>   clocks = <&camera 1>;
>   clock-names = "mclk";
> + camera-flash = <&led_flash>;
>  
>   port {
>   s5k6aa_ep: endpoint {

It's indeed an interesting idea to declare the flash controller in the
sensor's properties rather than those of the ISP. The obvious upside is that
this way it's easy to figure out which subdev group the flash controller
belongs to.

There are a few other things to consider as well:

- You can't have a flash without a sensor. I can't think of why this would
  be a real issue, though.

- Relations other than one-to-one become difficult. One flash but two
  cameras --- think of stereo cameras.

- One camera and two flashes. I haven't seen any but I don't think
  that's unthinkable.

- It's not very nice of the ISP driver to just go and parse the
  sensor's properties.

- As the property is FIMC specific, the sensor DT node now carries FIMC
  related information.

A generic solution would be preferrable as this is not a FIMC related
problem.

I have to admit that I can't think of a better solution right now than just
putting a list of the flash device phandles to the ISP device's DT node, and
then adding information on which sensor (numeric ID) the flash is related to
as an array. Better ideas would be welcome.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 16/16] input: serio: hp_sdc: Use del_timer_sync() in exit path

[Dmitry Torokhov]

On Sun, Mar 23, 2014 at 03:09:33PM -, Thomas Gleixner wrote:
> Make sure that no callback is running before we teardown the module.
> 

Applied, thank you Thomas.

> Signed-off-by: Thomas Gleixner 
> Cc: Dmitry Torokhov 
> Cc: input 
> ---
>  drivers/input/serio/hp_sdc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: tip/drivers/input/serio/hp_sdc.c
> ===
> --- tip.orig/drivers/input/serio/hp_sdc.c
> +++ tip/drivers/input/serio/hp_sdc.c
> @@ -984,7 +984,7 @@ static void hp_sdc_exit(void)
>   free_irq(hp_sdc.irq, &hp_sdc);
>   write_unlock_irq(&hp_sdc.lock);
>  
> - del_timer(&hp_sdc.kicker);
> + del_timer_sync(&hp_sdc.kicker);
>  
>   tasklet_kill(&hp_sdc.task);
>  
> 
> 

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

hi

[Mr.Macus Donald]

My Name is Macus Donald,Please i have no intentions of causing you any pains, 
I'm seeking your assistance only on humanitarian basis.I want you to assist me 
ensure that my estate and money is been used for Orphanage Home Project.if you 
are interested and you need more details contact me on my private  E-mail 
Address: macus.donald01...@gmail.com

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

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

RE: PATCH[60485 Bug adding breakpoint]

[Nick Krause]

Here is my new patch as corrected for the the bug 60845.
https://bugzilla.kernel.org/show_bug.cgi?id=60845
This is the link to the bug and my comments / conversation on to get the 
corrections needed.
 Below is my patch for the bug, please let me know if it gets added finally 
Alan .

 --- linux-3.13.6/arch/mips/pci/msi-octeon.c.orig    2014-03-22 
17:32:44.762754254 -0400
 +++ linux-3.13.6/arch/mips/pci/msi-octeon.c    2014-03-22 17:34:19.974753699 
-0400
 @@ -150,6 +150,7 @@ msi_irq_allocated:
      msg.address_lo =
          ((128ul << 20) + CVMX_PCI_MSI_RCV) & 0x;
      msg.address_hi = ((128ul << 20) + CVMX_PCI_MSI_RCV)>> 32;
 +        break;
  case OCTEON_DMA_BAR_TYPE_BIG:
        /* When using big bar, Bar 0 is based at 0 */
      msg.address_lo = (0 + CVMX_PCI_MSI_RCV) & 0x; Signed-off-by: 
nickkra...@sympatico.ca
Nick


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

Re: [PATCH/RFC 4/8] media: Add registration helpers for V4L2 flash sub-devices

[Sakari Ailus]

Hi Jacek,

On Thu, Mar 20, 2014 at 03:51:06PM +0100, Jacek Anaszewski wrote:
> This patch adds helper functions for registering/unregistering
> LED class flash devices as V4L2 subdevs. The functions should
> be called from the LED subsystem device driver. In case the
> Multimedia Framework support is disabled in the kernel config
> the functions' empty versions will be used.
> 
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> ---
>  drivers/media/v4l2-core/Makefile |2 +-
>  drivers/media/v4l2-core/v4l2-flash.c |  320 
> ++
>  include/media/v4l2-flash.h   |  102 +++
>  3 files changed, 423 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/v4l2-core/v4l2-flash.c
>  create mode 100644 include/media/v4l2-flash.h
> 
> diff --git a/drivers/media/v4l2-core/Makefile 
> b/drivers/media/v4l2-core/Makefile
> index c6ae7ba..63e8f03 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -6,7 +6,7 @@ tuner-objs:=  tuner-core.o
>  
>  videodev-objs:=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o 
> \
>   v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> - v4l2-async.o
> + v4l2-async.o v4l2-flash.o
>  ifeq ($(CONFIG_COMPAT),y)
>videodev-objs += v4l2-compat-ioctl32.o
>  endif
> diff --git a/drivers/media/v4l2-core/v4l2-flash.c 
> b/drivers/media/v4l2-core/v4l2-flash.c
> new file mode 100644
> index 000..6be0ba9
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-flash.c
> @@ -0,0 +1,320 @@
> +/*
> + * V4L2 flash LED subdevice registration helpers.
> + *
> + *   Copyright (C) 2014 Samsung Electronics Co., Ltd
> + *   Author: Jacek Anaszewski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation."
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Alphabetical order, please.

> +
> +static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
> +
> +{
> + struct v4l2_flash *flash = ctrl_to_flash(c);
> + struct led_classdev *led_cdev = flash->led_cdev;
> + unsigned int fault;
> + int ret;
> +
> + switch (c->id) {
> + case V4L2_CID_FLASH_STROBE_STATUS:
> + ret = led_update_brightness(led_cdev);
> + if (ret < 0)
> + return ret;
> + c->val = !!ret;
> + return 0;
> + case V4L2_CID_FLASH_FAULT:
> + /* led faults map directly to V4L2 flash faults */
> + ret = led_get_flash_fault(led_cdev, &fault);
> + if (!ret)
> + c->val = fault;
> + return ret;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int v4l2_flash_set_intensity(struct v4l2_flash *flash,
> + unsigned int intensity)
> +{
> + struct led_classdev *led_cdev = flash->led_cdev;
> + unsigned int fault;
> + int ret;
> +
> + ret = led_get_flash_fault(led_cdev, &fault);
> + if (ret < 0 || fault)
> + return -EINVAL;

Is it meaningful to check the faults here?

The existing flash controller drivers mostly do not. The responsibility is
left to the user --- something the user should probably do after the strobe
has expectedly finished. This isn't particularly very well documented in the
spec, though.

Also, the presence of every fault does not prevent using the flash.

> + led_set_brightness(led_cdev, intensity);

Where do you convert between the LED framework brightness and the value used
by the V4L2 controls?

> +
> + return ret;
> +}
> +
> +static int v4l2_flash_s_ctrl(struct v4l2_ctrl *c)
> +{
> + struct v4l2_flash *flash = ctrl_to_flash(c);
> + struct led_classdev *led_cdev = flash->led_cdev;
> + int ret = 0;
> +
> + switch (c->id) {
> + case V4L2_CID_FLASH_LED_MODE:
> + switch (c->val) {
> + case V4L2_FLASH_LED_MODE_NONE:
> + /* clear flash mode on releae */

It's not uncommon for the user to leave the mode to something else than none
when the user goes away. Could there be other ways to mediate access?

> + ret = led_set_flash_mode(led_cdev, false);
> + if (ret < 0)
> + return ret;
> + mutex_lock(&led_cdev->led_lock);
> + led_sysfs_unlock(led_cdev);
> + mutex_unlock(&led_cdev->led_lock);
> + break;
> + case V4L2_FLASH_LED_MODE_FLASH:
> + mutex_lock(&led_cdev->led_lock);
> + led_sysfs_lock(led_cdev);
> + mutex_unlock(&led_cdev->led_lock);
> +
> + ret = led_set_flash_mode(led_cdev, true);
> + if (ret < 

Re: [PATCH 4/5] vrange: Set affected pages referenced when marking volatile

[KOSAKI Motohiro]

On Fri, Mar 21, 2014 at 2:17 PM, John Stultz  wrote:
> One issue that some potential users were concerned about, was that
> they wanted to ensure that all the pages from one volatile range
> were purged before we purge pages from a different volatile range.
> This would prevent the case where they have 4 large objects, and
> the system purges one page from each object, casuing all of the
> objects to have to be re-created.
>
> The counter-point to this case, is when an application is using the
> SIGBUS semantics to continue to access pages after they have been
> marked volatile. In that case, the desire was that the most recently
> touched pages be purged last, and only the "cold" pages be purged
> from the specified range.
>
> Instead of adding option flags for the various usage model (at least
> initially), one way of getting a solutoin for both uses would be to
> have the act of marking pages as volatile in effect mark the pages
> as accessed. Since all of the pages in the range would be marked
> together, they would be of the same "age" and would (approximately)
> be purged together. Further, if any pages in the range were accessed
> after being marked volatile, they would be moved to the end of the
> lru and be purged later.

If you run after two hares, you will catch neither. I suspect this patch
doesn't make happy any user.
I suggest to aim former case (object level caching) and aim latter by
another patch-kit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] vrange: Add page purging logic & SIGBUS trap

[KOSAKI Motohiro]

On Fri, Mar 21, 2014 at 2:17 PM, John Stultz  wrote:
> This patch adds the hooks in the vmscan logic to discard volatile pages
> and mark their pte as purged. With this, volatile pages will be purged
> under pressure, and their ptes swap entry's marked. If the purged pages
> are accessed before being marked non-volatile, we catch this and send a
> SIGBUS.
>
> This is a simplified implementation that uses logic from Minchan's earlier
> efforts, so credit to Minchan for his work.
>
> Cc: Andrew Morton 
> Cc: Android Kernel Team 
> Cc: Johannes Weiner 
> Cc: Robert Love 
> Cc: Mel Gorman 
> Cc: Hugh Dickins 
> Cc: Dave Hansen 
> Cc: Rik van Riel 
> Cc: Dmitry Adamushko 
> Cc: Neil Brown 
> Cc: Andrea Arcangeli 
> Cc: Mike Hommey 
> Cc: Taras Glek 
> Cc: Jan Kara 
> Cc: KOSAKI Motohiro 
> Cc: Michel Lespinasse 
> Cc: Minchan Kim 
> Cc: linux...@kvack.org 
> Signed-off-by: John Stultz 
> ---
>  include/linux/vrange.h |   2 +
>  mm/internal.h  |   2 -
>  mm/memory.c|  21 +
>  mm/rmap.c  |   5 +++
>  mm/vmscan.c|  12 ++
>  mm/vrange.c| 114 
> +
>  6 files changed, 154 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/vrange.h b/include/linux/vrange.h
> index 986fa85..d93ad21 100644
> --- a/include/linux/vrange.h
> +++ b/include/linux/vrange.h
> @@ -8,4 +8,6 @@
>  #define VRANGE_VOLATILE 1
>  #define VRANGE_VALID_FLAGS (0) /* Don't yet support any flags */
>
> +extern int discard_vpage(struct page *page);
> +
>  #endif /* _LINUX_VRANGE_H */
> diff --git a/mm/internal.h b/mm/internal.h
> index 29e1e76..ea66bf9 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -225,10 +225,8 @@ static inline void mlock_migrate_page(struct page 
> *newpage, struct page *page)
>
>  extern pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma);
>
> -#ifdef CONFIG_TRANSPARENT_HUGEPAGE
>  extern unsigned long vma_address(struct page *page,
>  struct vm_area_struct *vma);
> -#endif
>  #else /* !CONFIG_MMU */
>  static inline int mlocked_vma_newpage(struct vm_area_struct *v, struct page 
> *p)
>  {
> diff --git a/mm/memory.c b/mm/memory.c
> index 22dfa61..db5f4da 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -60,6 +60,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -3643,6 +3644,8 @@ static int handle_pte_fault(struct mm_struct *mm,
>
> entry = *pte;
> if (!pte_present(entry)) {
> +   swp_entry_t vrange_entry;
> +retry:
> if (pte_none(entry)) {
> if (vma->vm_ops) {
> if (likely(vma->vm_ops->fault))
> @@ -3652,6 +3655,24 @@ static int handle_pte_fault(struct mm_struct *mm,
> return do_anonymous_page(mm, vma, address,
>  pte, pmd, flags);
> }
> +
> +   vrange_entry = pte_to_swp_entry(entry);
> +   if (unlikely(is_vpurged_entry(vrange_entry))) {
> +   if (vma->vm_flags & VM_VOLATILE)
> +   return VM_FAULT_SIGBUS;
> +
> +   /* zap pte */
> +   ptl = pte_lockptr(mm, pmd);
> +   spin_lock(ptl);
> +   if (unlikely(!pte_same(*pte, entry)))
> +   goto unlock;
> +   flush_cache_page(vma, address, pte_pfn(*pte));
> +   ptep_clear_flush(vma, address, pte);
> +   pte_unmap_unlock(pte, ptl);
> +   goto retry;

This looks strange why we need zap pte here?

> +   }
> +
> +
> if (pte_file(entry))
> return do_nonlinear_fault(mm, vma, address,
> pte, pmd, flags, entry);
> diff --git a/mm/rmap.c b/mm/rmap.c
> index d9d4231..2b6f079 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -728,6 +728,11 @@ int page_referenced_one(struct page *page, struct 
> vm_area_struct *vma,
> referenced++;
> }
> pte_unmap_unlock(pte, ptl);
> +   if (vma->vm_flags & VM_VOLATILE) {
> +   pra->mapcount = 0;
> +   pra->vm_flags |= VM_VOLATILE;
> +   return SWAP_FAIL;
> +   }
> }
>
> if (referenced) {
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index a9c74b4..34f159a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -683,6 +684,7 @@ enum page_references {
> PAGEREF_RECLAIM,
> PAGEREF_RECLAIM_CLEAN,
> PAGEREF_KEEP,
> +   PAGEREF_DISCARD,

"discard" is alread used in various place for another meanings.
another name is better.

> PAGEREF_ACTIVATE,

Re: [patch 00/16] timers: Plug debugobject leaks and use del_timer_sync() in exit/teardown

[Thomas Gleixner]

On Sun, 23 Mar 2014, Julia Lawall wrote:
> As far as I could tell, (part of) the issue is that any kind of exit or 
> close function should use del_timer_sync, because they could be called 
> from a different CPU than the one that started up the timer?
> 
> Here is a semantic patch that takes care of the case of simple module_exit 
> functions:
> 
> @r@
> declarer name module_exit;
> identifier ex;
> @@
> 
> module_exit(ex);
> 
> @@
> identifier r.ex;
> @@
> 
> ex(...) {
>   <...
> - del_timer
> + del_timer_sync
> (...)
>   ...>
> }
> 
> The transformations it makes are below.  I haven't had a chance to check 
> which results overlap with what Thomas has already sent, but I could look 

Minimal overlap, but as I said I did just a few conversions.

> into it if this is the right idea.  I guess other kinds of close/exit 
> functions would have to be identified manually, to make more rules.

If you look through the examples I sent, you'll find the close()
callbacks of various devices. So everything which is a function
pointer to a ops->close(), ops->remove(), ops_>teardown() is dangerous
if using del_timer(). There are a few exceptions, but

Another thing I saw is 

del_timer(&bla->timer);

kfree(&bla);

That's also a potential source of trouble. You can't tell without
analyzing the code, whether it's a problem or not. But making the
responsible people to look at it is definitely a good thing.
 
> In what circumstance can one be sure that two instructions are executed on 
> the same CPU?

If interrupts or preemption are disabled. But that's not the issue at
hand.

The del_timer vs. del_timer_sync problem is:

CPU0 CPU1

add_timer(&bla->timer);

 close(bla)
timer expires  del_timer(&bla->timer);
  callback is invoked
   kfree(bla);
derefernces bla

I'll look at your findings on Tuesday, but feel free to send them to
the relevant maintainers for review.

Thanks,

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

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

[Stephen Rothwell]

Hi Kukjin,

Today's linux-next merge of the samsung tree got a conflict in
arch/arm/Kconfig.debug between commit 886545ea7d0b ("ARM: efm32: allow
uncompress debug output") from the arm-soc tree and commit 90266754801c
("ARM: SAMSUNG: use generic uncompress.h") from the samsung tree.

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

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

diff --cc arch/arm/Kconfig.debug
index e5a00d421cc4,a160744312ab..
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@@ -1167,7 -1162,7 +1167,7 @@@ config DEBUG_UNCOMPRES
  config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
-   ARCH_EXYNOS || ARCH_EFM32
 -  PLAT_SAMSUNG
++  PLAT_SAMSUNG || ARCH_EFM32
default "mach/uncompress.h"
  
  config EARLY_PRINTK


pgphXOH7mMPkC.pgp
Description: PGP signature

Re: rb tree hrtimer lockup bug (found by perf_fuzzer)

[Thomas Gleixner]

On Sun, 23 Mar 2014, Thomas Gleixner wrote:
> On Sat, 22 Mar 2014, Thomas Gleixner wrote:
> > On Sat, 22 Mar 2014, Thomas Gleixner wrote:
> > > On Fri, 21 Mar 2014, Vince Weaver wrote:
> > > 
> > > > On Fri, 21 Mar 2014, Thomas Gleixner wrote:
> > > > > 
> > > > > I'm a complete idiot. I was staring at oaddr and did not notice that
> > > > > descr->name is the real culprit. Sorry. Delta patch below.
> > > > 
> > > > OK.  The log was much longer this time, attached.
> > > 
> > > Hmmm.
> > > 
> > > [2.739858] NULL pointer dereference at   (null)
> > > [2.747390] IP: [<  (null)>]   (null)
> > > [2.752970] PGD 0
> > > [2.755287] Oops: 0010 [#1] SMP
> > > 
> > > So this time the CPU branched to NULL. So let me recap.
> > > 
> > > First you had the explosion in the hrtimer code. After enabling debug
> > > stuff it went to the timer_list and now it looks different again.
> > > 
> > > So that looks more like a random memory corruption.
> > > 
> > > Nasty to debug. And of course it does not reproduce here. I'll throw
> > > your config at more machines in the hope that something will trigger
> > > it.
> > 
> > I've refined the trace_printk stuff in the hope to get a bit more info
> > out of it.
> 
> You might also try with the trace_printks removed. That wont give us
> the history, but maybe then the bug happens again at some decodable
> place.
> 

I tried to reproduce on a few machines, but no luck.

But I tooks some time to tweak the debugobjects patch further in the
hope that it helps.

I wonder whether it might be helpful to instrument memset/memcpy with
debugobjects. Those are pretty much the same as a free from an active
object POV. But that's a non trivial thing to do.

I'm traveling tomorrow, so I wont be able to respond before Tuesday.

Thanks,

tglx

--->
 include/linux/debugobjects.h |4 ++
 kernel/timer.c   |7 +++
 lib/debugobjects.c   |   83 +--
 3 files changed, 90 insertions(+), 4 deletions(-)

Index: linux-2.6/include/linux/debugobjects.h
===
--- linux-2.6.orig/include/linux/debugobjects.h
+++ linux-2.6/include/linux/debugobjects.h
@@ -30,6 +30,7 @@ struct debug_obj {
unsigned intastate;
void*object;
struct debug_obj_descr  *descr;
+   void*hint;
 };
 
 /**
@@ -68,6 +69,7 @@ extern void debug_object_deactivate(void
 extern void debug_object_destroy   (void *addr, struct debug_obj_descr *descr);
 extern void debug_object_free  (void *addr, struct debug_obj_descr *descr);
 extern void debug_object_assert_init(void *addr, struct debug_obj_descr 
*descr);
+extern void debug_object_info(void *addr, struct debug_obj_descr *descr);
 
 /*
  * Active state:
@@ -95,6 +97,8 @@ static inline void
 debug_object_free  (void *addr, struct debug_obj_descr *descr) { }
 static inline void
 debug_object_assert_init(void *addr, struct debug_obj_descr *descr) { }
+static inline void
+debug_object_info(void *addr, struct debug_obj_descr *descr) { }
 
 static inline void debug_objects_early_init(void) { }
 static inline void debug_objects_mem_init(void) { }
Index: linux-2.6/kernel/timer.c
===
--- linux-2.6.orig/kernel/timer.c
+++ linux-2.6/kernel/timer.c
@@ -1081,7 +1081,12 @@ static int cascade(struct tvec_base *bas
 * don't have to detach them individually.
 */
list_for_each_entry_safe(timer, tmp, &tv_list, entry) {
-   BUG_ON(tbase_get_base(timer->base) != base);
+   if (tbase_get_base(timer->base) != base) {
+   pr_err("Invalid timer base: tmr %p tmr->base %p base 
%p\n",
+  timer, timer->base, base);
+   debug_object_info(timer, &timer_debug_descr);
+   BUG();
+   }
/* No accounting, while moving them */
__internal_add_timer(base, timer);
}
Index: linux-2.6/lib/debugobjects.c
===
--- linux-2.6.orig/lib/debugobjects.c
+++ linux-2.6/lib/debugobjects.c
@@ -70,13 +70,14 @@ static int __init disable_object_debug(c
 early_param("debug_objects", enable_object_debug);
 early_param("no_debug_objects", disable_object_debug);
 
-static const char *obj_states[ODEBUG_STATE_MAX] = {
+static const char *obj_states[ODEBUG_STATE_MAX + 1] = {
[ODEBUG_STATE_NONE] = "none",
[ODEBUG_STATE_INIT] = "initialized",
[ODEBUG_STATE_INACTIVE] = "inactive",
[ODEBUG_STATE_ACTIVE]   = "active",
[ODEBUG_STATE_DESTROYED]= "destroyed",
[ODEBUG_STATE_NOTAVAILABLE] = "not available",
+   [ODEBUG_STATE_MAX]  = "free",
 };
 
 static void fill_pool(void)
@@ -1

Re: [PATCH/RFC 2/8] leds: Improve and export led_update_brightness function

[Sakari Ailus]

Hi Jacek,

On Thu, Mar 20, 2014 at 03:51:04PM +0100, Jacek Anaszewski wrote:
> led_update_brightness helper function used to be exploited
> only locally in the led-class.c module, where its result was
> being passed to the brightness_show sysfs callback. With the
> introduction of v4l2-flash subdevice the same functionality
> became required for checking the current flash strobe status.
> This patch adds checking brightness_get callback error code
> and adds the function to the LED subsystem public API.
> 
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Bryan Wu 
> Cc: Richard Purdie 
> ---
>  drivers/leds/led-class.c |6 --
>  drivers/leds/led-core.c  |   17 +
>  include/linux/leds.h |   10 ++
>  3 files changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 0510532..04de352 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -27,12 +27,6 @@
>  
>  static struct class *leds_class;
>  
> -static void led_update_brightness(struct led_classdev *led_cdev)
> -{
> - if (led_cdev->brightness_get)
> - led_cdev->brightness = led_cdev->brightness_get(led_cdev);
> -}
> -
>  static ssize_t brightness_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index 093703c..21ceda1 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -166,6 +166,23 @@ void led_set_brightness(struct led_classdev *led_cdev,
>  }
>  EXPORT_SYMBOL(led_set_brightness);
>  
> +int led_update_brightness(struct led_classdev *led_cdev)
> +{
> + int ret;
> +
> + if (led_cdev->brightness_get == NULL)
> + return -EINVAL;
> +
> + ret = led_cdev->brightness_get(led_cdev);
> + if (ret >= 0)
> + led_cdev->brightness = ret;
> + else
> + return ret;

You don't really need the else branch here. It'd be cleaner without, I
think.

> +
> + return 0;
> +}
> +EXPORT_SYMBOL(led_update_brightness);
> +
>  int led_set_flash_mode(struct led_classdev *led_cdev,
>   bool flash_mode)
>  {
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 1bf0ab3..5bf05cc 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -190,6 +190,16 @@ extern void led_blink_set_oneshot(struct led_classdev 
> *led_cdev,
>  extern void led_set_brightness(struct led_classdev *led_cdev,
>  enum led_brightness brightness);
>  /**
> + * led_update_brightness - update LED brightness
> + * @led_cdev: the LED to query about
> + *
> + * Get an LED's current brightness and update led_cdev->brightness
> + * member with the obtained value.
> + *
> + * Returns: 0 on success or negative error value on failure
> + */
> +extern int led_update_brightness(struct led_classdev *led_cdev);
> +
>  /**
>   * led_set_flash_mode - set LED flash mode
>   * @led_cdev: the LED to set

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC 1/8] leds: Add sysfs and kernel internal API for flash LEDs

[Sakari Ailus]

Hi Jacek,

Thanks for the patchset. It's very nice in general. I have a few comments
below.

On Thu, Mar 20, 2014 at 03:51:03PM +0100, Jacek Anaszewski wrote:
> Some LED devices support two operation modes - torch and
> flash. This patch provides support for flash LED devices
> in the LED subsystem by introducing new sysfs attributes
> and kernel internal interface. The attributes being
> introduced are: flash_mode, flash_timeout, max_flash_timeout,
> flash_fault and hw_triggered.
> The modifications aim to be compatible with V4L2 framework
> requirements related to the flash devices management. The
> design assumes that V4L2 driver can take of the LED class
> device control and communicate with it through the kernel
> internal interface. The LED sysfs interface is made
> unavailable then.
> 
> Signed-off-by: Jacek Anaszewski 
> Acked-by: Kyungmin Park 
> Cc: Bryan Wu 
> Cc: Richard Purdie 
> ---
>  drivers/leds/led-class.c|  216 
> +--
>  drivers/leds/led-core.c |  124 +++--
>  drivers/leds/led-triggers.c |   17 +++-
>  drivers/leds/leds.h |9 ++
>  include/linux/leds.h|  136 +++
>  5 files changed, 486 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index f37d63c..0510532 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -4,6 +4,9 @@
>   * Copyright (C) 2005 John Lenz 
>   * Copyright (C) 2005-2007 Richard Purdie 
>   *
> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
> + * Author: Jacek Anaszewski 
> + *
>   * 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.
> @@ -13,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

The list seems to be in quite a disarray. Could you order it as you're
adding a new header to it?

>  #include 
>  #include 
>  #include 
> @@ -45,28 +49,186 @@ static ssize_t brightness_store(struct device *dev,
>  {
>   struct led_classdev *led_cdev = dev_get_drvdata(dev);
>   unsigned long state;
> - ssize_t ret = -EINVAL;
> + ssize_t ret;
> +
> + mutex_lock(&led_cdev->led_lock);
> +
> + if (led_sysfs_is_locked(led_cdev)) {
> + ret = -EBUSY;
> + goto exit_unlock;
> + }
>  
>   ret = kstrtoul(buf, 10, &state);
>   if (ret)
> - return ret;
> + goto exit_unlock;
>  
>   if (state == LED_OFF)
>   led_trigger_remove(led_cdev);
> - __led_set_brightness(led_cdev, state);
> + led_set_brightness(led_cdev, state);
> + ret = size;
>  
> - return size;
> +exit_unlock:
> + mutex_unlock(&led_cdev->led_lock);
> + return ret;
>  }
>  static DEVICE_ATTR_RW(brightness);
>  
> -static ssize_t led_max_brightness_show(struct device *dev,
> +static ssize_t max_brightness_show(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
>   struct led_classdev *led_cdev = dev_get_drvdata(dev);
>  
>   return sprintf(buf, "%u\n", led_cdev->max_brightness);
>  }
> -static DEVICE_ATTR(max_brightness, 0444, led_max_brightness_show, NULL);
> +static DEVICE_ATTR_RO(max_brightness);
> +
> +static ssize_t flash_mode_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + unsigned long flash_mode;
> + ssize_t ret;
> +
> + mutex_lock(&led_cdev->led_lock);
> +
> + if (led_sysfs_is_locked(led_cdev)) {
> + ret = -EBUSY;
> + goto exit_unlock;
> + }
> +
> + ret = kstrtoul(buf, 10, &flash_mode);
> + if (ret)
> + goto exit_unlock;
> +
> + if (flash_mode < 0 && flash_mode > 1)
> + return -EINVAL;
> +
> + if (led_is_flash_mode(led_cdev) == flash_mode) {
> + ret = size;
> + goto exit_unlock;
> + }
> +
> + led_trigger_remove(led_cdev);
> +
> + led_set_flash_mode(led_cdev, flash_mode);
> + ret = size;
> +
> +exit_unlock:
> + mutex_unlock(&led_cdev->led_lock);
> + return ret;
> +}
> +
> +static ssize_t flash_mode_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> +
> + return sprintf(buf, "%u\n", led_is_flash_mode(led_cdev));
> +}
> +static DEVICE_ATTR_RW(flash_mode);
> +
> +static ssize_t flash_timeout_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t size)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + unsigned long flash_timeout;
> + ssize_t ret;
> +
> + mutex_lock(&led_cdev->led_lock);
> +
> + if (led_sysfs_is_locked(led_cdev)) {
> + ret = -EBUSY;
> + goto exit_unlock;
> + 

Re: [PATCH 2/2] ARM: mm: keep rodata non-executable

[Kees Cook]

On Sun, Mar 23, 2014 at 4:37 PM, Nicolas Pitre  wrote:
> On Sun, 23 Mar 2014, Kees Cook wrote:
>
>> On Sun, Mar 23, 2014 at 12:47 PM, Laura Abbott  wrote:
>> > On 2/17/2014 4:34 AM, Dave Martin wrote:
>> >> On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
>> >>> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin  wrote:
>>  On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
>> > Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
>> > the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
>> > sets rodata read-only (but executable), where as this option 
>> > additionally
>> > splits rodata from the kernel text (resulting in potentially more 
>> > memory
>> > lost to padding) and sets it non-executable as well. The end result is
>> > that on builds with CONFIG_DEBUG_RODATA=y (like x86) the rodata with be
>> > marked purely read-only.
>> 
>>  This triggers an Oops in kexec, because we have a block of code in .text
>>  which is a template for generating baremetal code to relocate the new
>>  kernel, and some literal words are written into it before copying.
>> >>>
>> >>> You're writing into the text area? I would imagine that
>> >>> CONFIG_ARM_KERNMEM_PERMS would break that. However, that's not the
>> >>> right place to be building code -- shouldn't the module area be used
>> >>> for that?
>> >>>
>>  Possibly this should be in .rodata, not .text.
>> >>>
>> >>> Well, rodata should be neither writable nor executable.
>> >>
>> >> We're not writing into code exactly.
>> >>
>> >> This code is never executed in-place in vmlinux.  It gets copied, and
>> >> only copies are ever executed.
>> >>
>> >> Some pointers and offsets get poked into the code to configure it.
>> >>
>> >> I think it would be better simply to put the code in .rodata, and
>> >> poke paramaters into the copy, not the original -- but that's a bit
>> >> more awkward to code up, since the values can't be poked simply by
>> >> writing global variables.
>> >>
>> >>>
>>  There may be a few other instances of this kind of thing.
>> >>>
>> >>> This config will certainly find them! :) But, that's why it's behind a 
>> >>> config.
>> >>
>> >> I haven't tested exhaustively, but it think this is sufficient for a
>> >> Tested-by.  The patch does seem to be doing what it is intended to
>> >> do, and doesn't seem to be triggering false positives all over the
>> >> place.
>> >>
>> >>>
>>  Are you aware of similar situations on other arches?
>> >>>
>> >>> I think there were some problems a long time ago on x86 for rodata too.
>> >>
>> >> It would be good to get this kexec case fixed -- I'll try to hack up
>> >> a separate patch.
>> >>
>> >
>> > FWIW, we've hit issues not just with kexec but kprobes as well. The same
>> > problems exist with this series:
>>
>> For this stage, how about I make this "depends on KEXEC=n &&
>> KPROBES=n"? Then as these areas get fixed, we can drop those
>> requirements.
>
> Do they really need "fixing"?
>
> The goal here is to increase security by preventing kernel code to be
> modified.  And now it would require hole punching in order to support
> kprobes.
>
> If security is important enough for this option to be attractive to you,
> then wouldn't you want to keep kprobes firmly turned off as well?

I couldn't agree more. :) I don't build with these options, but if
someone wants both of these, we'll have to deal with that. Until then,
we should keep it disabled with the negative "depends on".

-Kees

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

Re: [PATCH v2] drm/i2c: tda998x: Change the compatible strings

[Sebastian Hesselbarth]

On 03/23/2014 09:03 PM, Russell King - ARM Linux wrote:

On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote:

On 03/23/2014 11:19 AM, Jean-Francois Moine wrote:

On Fri, 21 Mar 2014 14:37:52 +0100
Sebastian Hesselbarth  wrote:

Required properties;
-  - compatible: must be "nxp,tda998x"
+  - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"


There is a "DT is ABI" policy and although there is no mainline Linux
user of current compatible, the correct way would be to deprecate
"nxp,tda998x" and introduce new compatibles.


Pratically, what is this way?


Currently, there is no effective way to deprecate a binding or
compatible. You just add the one(s) that are more sensible and
you mark the old one as DEPRECATED by simply writing it in the
binding doc.

The driver should support the old binding at least for a while.


It doesn't need to - it's only been in development trees so far, and
never been in a mainline full release.  Until it does, the binding
does not become stable.


Ok, I see. Thanks for the clarification. A note about it would
have been nice though. Anyway, sorry for the noise.

Sebastian

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

Re: [PATCH 2/2] ARM: mm: keep rodata non-executable

[Nicolas Pitre]

On Sun, 23 Mar 2014, Kees Cook wrote:

> On Sun, Mar 23, 2014 at 12:47 PM, Laura Abbott  wrote:
> > On 2/17/2014 4:34 AM, Dave Martin wrote:
> >> On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin  wrote:
>  On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
> > Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
> > the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
> > sets rodata read-only (but executable), where as this option 
> > additionally
> > splits rodata from the kernel text (resulting in potentially more memory
> > lost to padding) and sets it non-executable as well. The end result is
> > that on builds with CONFIG_DEBUG_RODATA=y (like x86) the rodata with be
> > marked purely read-only.
> 
>  This triggers an Oops in kexec, because we have a block of code in .text
>  which is a template for generating baremetal code to relocate the new
>  kernel, and some literal words are written into it before copying.
> >>>
> >>> You're writing into the text area? I would imagine that
> >>> CONFIG_ARM_KERNMEM_PERMS would break that. However, that's not the
> >>> right place to be building code -- shouldn't the module area be used
> >>> for that?
> >>>
>  Possibly this should be in .rodata, not .text.
> >>>
> >>> Well, rodata should be neither writable nor executable.
> >>
> >> We're not writing into code exactly.
> >>
> >> This code is never executed in-place in vmlinux.  It gets copied, and
> >> only copies are ever executed.
> >>
> >> Some pointers and offsets get poked into the code to configure it.
> >>
> >> I think it would be better simply to put the code in .rodata, and
> >> poke paramaters into the copy, not the original -- but that's a bit
> >> more awkward to code up, since the values can't be poked simply by
> >> writing global variables.
> >>
> >>>
>  There may be a few other instances of this kind of thing.
> >>>
> >>> This config will certainly find them! :) But, that's why it's behind a 
> >>> config.
> >>
> >> I haven't tested exhaustively, but it think this is sufficient for a
> >> Tested-by.  The patch does seem to be doing what it is intended to
> >> do, and doesn't seem to be triggering false positives all over the
> >> place.
> >>
> >>>
>  Are you aware of similar situations on other arches?
> >>>
> >>> I think there were some problems a long time ago on x86 for rodata too.
> >>
> >> It would be good to get this kexec case fixed -- I'll try to hack up
> >> a separate patch.
> >>
> >
> > FWIW, we've hit issues not just with kexec but kprobes as well. The same
> > problems exist with this series:
> 
> For this stage, how about I make this "depends on KEXEC=n &&
> KPROBES=n"? Then as these areas get fixed, we can drop those
> requirements.

Do they really need "fixing"?

The goal here is to increase security by preventing kernel code to be 
modified.  And now it would require hole punching in order to support 
kprobes.

If security is important enough for this option to be attractive to you, 
then wouldn't you want to keep kprobes firmly turned off as well?


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

Re: [patch 00/16] timers: Plug debugobject leaks and use del_timer_sync() in exit/teardown

[Julia Lawall]

As far as I could tell, (part of) the issue is that any kind of exit or 
close function should use del_timer_sync, because they could be called 
from a different CPU than the one that started up the timer?

Here is a semantic patch that takes care of the case of simple module_exit 
functions:

@r@
declarer name module_exit;
identifier ex;
@@

module_exit(ex);

@@
identifier r.ex;
@@

ex(...) {
  <...
- del_timer
+ del_timer_sync
(...)
  ...>
}

The transformations it makes are below.  I haven't had a chance to check 
which results overlap with what Thomas has already sent, but I could look 
into it if this is the right idea.  I guess other kinds of close/exit 
functions would have to be identified manually, to make more rules.

In what circumstance can one be sure that two instructions are executed on 
the same CPU?

julia

diff -u -p a/arch/mips/lasat/picvue_proc.c b/arch/mips/lasat/picvue_proc.c
--- a/arch/mips/lasat/picvue_proc.c
+++ b/arch/mips/lasat/picvue_proc.c
@@ -175,7 +175,7 @@ static void pvc_proc_cleanup(void)
remove_proc_entry("scroll", pvc_display_dir);
remove_proc_entry(DISPLAY_DIR_NAME, NULL);
 
-   del_timer(&timer);
+   del_timer_sync(&timer);
 }
 
 static int __init pvc_proc_init(void)
diff -u -p a/drivers/tty/serial/mux.c b/drivers/tty/serial/mux.c
--- a/drivers/tty/serial/mux.c
+++ b/drivers/tty/serial/mux.c
@@ -613,7 +613,7 @@ static void __exit mux_exit(void)
 {
/* Delete the Mux timer. */
if(port_cnt > 0) {
-   del_timer(&mux_timer);
+   del_timer_sync(&mux_timer);
 #ifdef CONFIG_SERIAL_MUX_CONSOLE
unregister_console(&mux_console);
 #endif
diff -u -p a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -984,7 +984,7 @@ static void hp_sdc_exit(void)
free_irq(hp_sdc.irq, &hp_sdc);
write_unlock_irq(&hp_sdc.lock);
 
-   del_timer(&hp_sdc.kicker);
+   del_timer_sync(&hp_sdc.kicker);
 
tasklet_kill(&hp_sdc.task);
 
diff -u -p a/drivers/isdn/sc/init.c b/drivers/isdn/sc/init.c
--- a/drivers/isdn/sc/init.c
+++ b/drivers/isdn/sc/init.c
@@ -390,8 +390,8 @@ static void __exit sc_exit(void)
/*
 * kill the timers
 */
-   del_timer(&(sc_adapter[i]->reset_timer));
-   del_timer(&(sc_adapter[i]->stat_timer));
+   del_timer_sync(&(sc_adapter[i]->reset_timer));
+   del_timer_sync(&(sc_adapter[i]->stat_timer));
 
/*
 * Tell I4L we're toast
diff -u -p a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -2381,7 +2381,7 @@ static void __exit isdn_exit(void)
}
isdn_tty_exit();
unregister_chrdev(ISDN_MAJOR, "isdn");
-   del_timer(&dev->timer);
+   del_timer_sync(&dev->timer);
/* call vfree with interrupts enabled, else it will hang */
vfree(dev);
printk(KERN_NOTICE "ISDN-subsystem unloaded\n");
diff -u -p a/drivers/isdn/hardware/mISDN/hfcpci.c 
b/drivers/isdn/hardware/mISDN/hfcpci.c
--- a/drivers/isdn/hardware/mISDN/hfcpci.c
+++ b/drivers/isdn/hardware/mISDN/hfcpci.c
@@ -2352,7 +2352,7 @@ static void __exit
 HFC_cleanup(void)
 {
if (timer_pending(&hfc_tl))
-   del_timer(&hfc_tl);
+   del_timer_sync(&hfc_tl);
 
pci_unregister_driver(&hfc_driver);
 }
diff -u -p a/drivers/isdn/act2000/module.c b/drivers/isdn/act2000/module.c
--- a/drivers/isdn/act2000/module.c
+++ b/drivers/isdn/act2000/module.c
@@ -796,7 +796,7 @@ static void __exit act2000_exit(void)
act2000_card *last;
while (card) {
unregister_card(card);
-   del_timer(&card->ptimer);
+   del_timer_sync(&card->ptimer);
card = card->next;
}
card = cards;
diff -u -p a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -1184,7 +1184,7 @@ static void __exit yam_cleanup_driver(vo
struct yam_mcs *p;
int i;
 
-   del_timer(&yam_timer);
+   del_timer_sync(&yam_timer);
for (i = 0; i < NR_PORTS; i++) {
struct net_device *dev = yam_devs[i];
if (dev) {
diff -u -p a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2218,7 +2218,7 @@ static void __exit speakup_exit(void)
unregister_keyboard_notifier(&keyboard_notifier_block);
unregister_vt_notifier(&vt_notifier_block);
speakup_unregister_devsynth();
-   del_timer(&cursor_timer);
+   del_timer_sync(&cursor_timer);
kthread_stop(speakup_task);
speakup_task = NULL;
mutex_lock(&spk_mutex);
diff -u -p a/drivers/staging/panel/panel.c b/drivers/staging/panel

Disabling gcc inline operation

[anish singh]

Many a time i have got a crash and it is difficult
to find out the exact function which crashed
because the crash stack doesn't show the "real"
function because gcc inlines many functions when
ever it desires or when it optimizes for speed.

So i don't want gcc to inline any function instead
just call the function so that i can see the crash
stack of each function called. I just want to do
this for debugging. Please let me know how can
i do that?

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

Re: [PATCH 2/2] ARM: mm: keep rodata non-executable

[Kees Cook]

On Sun, Mar 23, 2014 at 12:32 PM, Laura Abbott  wrote:
> On 3/13/2014 12:07 PM, Kees Cook wrote:
>> On Fri, Feb 21, 2014 at 2:09 PM, Kees Cook  wrote:
>>> On Fri, Feb 21, 2014 at 5:20 AM, Russell King - ARM Linux
>>>  wrote:
 On Fri, Feb 21, 2014 at 12:37:04PM +, Dave Martin wrote:
> It would be good if someone who's more familiar with the parms and
> vmlinux.lds stuff could take a look at it, though I don't see any
> obvious problem yet.

 The biggest issue with it is that we end up with:

 - the .text section rounded up to 1MB
 - the .rodata section rounded up to 1MB

 That means we can end up wasting up to 1MB of memory for each (in the
 worst case where we encroach into the next 1MB aligned region by a few
 bytes) and this memory can't be re-used.

 The alternative is to adjust the maps such that we end up mapping the
 .text / .rodata overlap 1MB using 4K pages, taking the additional TLB
 hit by doing so.

 The .text is aligned to 1MB, so the majority of the first 0x8000 to
 0x10 is unused.  The end of the .text section is aligned to 1MB,
 and the start of the .data section is also aligned to 1MB.

 So, the minimum kernel size is: 0x10 + MB_ALIGN(sizeof(.text)) +
 MB_ALIGN(sizeof(.rodata)) + MB_ALIGN(sizeof(init sections)) + sizeof(.data)
 - 0x8000

 So, looking at this kernel I've recently built:

 Idx Name  Size  VMA   LMA   File off  Algn
   0 .head.text0204  c0008000  c0008000  8000  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE

 --- .text this gets set to 0xc010, we lose 0xc0008240 to 0xc010

   1 .text 006c4530  c0008240  c0008240  8240  2**6
   CONTENTS, ALLOC, LOAD, READONLY, CODE
   2 .text.head004c  c06cc770  c06cc770  006cc770  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE

 --- sizeof(.text) + sizeof(.text.head) becomes 0x70
 --- .rodata starts at 0xc080 instead of 0xc06cd000

   3 .rodata   0022f568  c06cd000  c06cd000  006cd000  2**6
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 __bug_table   873c  c08fc568  c08fc568  008fc568  2**0
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   5 .pci_fixup0030  c0904ca4  c0904ca4  00904ca4  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   6 __ksymtab 8158  c0904cd4  c0904cd4  00904cd4  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   7 __ksymtab_gpl 6858  c090ce2c  c090ce2c  0090ce2c  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   8 __kcrctab 40ac  c0913684  c0913684  00913684  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
   9 __kcrctab_gpl 342c  c0917730  c0917730  00917730  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  10 __ksymtab_strings 00022a08  c091ab5c  c091ab5c  0091ab5c  2**0
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  11 __param   0c70  c093d564  c093d564  0093d564  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  12 __modver  0e2c  c093e1d4  c093e1d4  0093e1d4  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  13 __ex_table0f18  c093f000  c093f000  0093f000  2**3
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  14 .notes0024  c093ff18  c093ff18  0093ff18  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  15 .vectors  0020    c094  0094  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  16 .stubs0240  1000  c0940020  00941000  2**5
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  17 .init.text00051760  c0940260  c0940260  00948260  2**5
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  18 .exit.text2130  c09919c0  c09919c0  00c0  2**2
   CONTENTS, ALLOC, LOAD, READONLY, CODE
  19 .init.arch.info 0108  c0993af0  c0993af0  0099baf0  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  20 .init.tagtable 0048  c0993bf8  c0993bf8  0099bbf8  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  21 .init.smpalt  32f8  c0993c40  c0993c40  0099bc40  2**2
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  22 .init.pv_table 0314  c0996f38  c0996f38  0099ef38  2**0
   CONTENTS, ALLOC, LOAD, READONLY, DATA
  23 .init.datac19c  c0997250  c0997250  0099f250  2**3
   CONTENTS, ALLOC, LOAD, DATA
  24 .data..percpu 35c0  c09a4000  c09a4000  009ac000  2**6
   CONTENTS, ALLOC, LOAD, DATA

 --- sizeof previous sections is 0x2db000, 

Re: [PATCH 2/2] ARM: mm: keep rodata non-executable

[Kees Cook]

On Sun, Mar 23, 2014 at 12:47 PM, Laura Abbott  wrote:
> On 2/17/2014 4:34 AM, Dave Martin wrote:
>> On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
>>> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin  wrote:
 On Thu, Feb 13, 2014 at 05:04:10PM -0800, Kees Cook wrote:
> Introduce "CONFIG_DEBUG_RODATA" to mostly match the x86 config, though
> the behavior is different: it depends on STRICT_KERNMEM_PERMS, which
> sets rodata read-only (but executable), where as this option additionally
> splits rodata from the kernel text (resulting in potentially more memory
> lost to padding) and sets it non-executable as well. The end result is
> that on builds with CONFIG_DEBUG_RODATA=y (like x86) the rodata with be
> marked purely read-only.

 This triggers an Oops in kexec, because we have a block of code in .text
 which is a template for generating baremetal code to relocate the new
 kernel, and some literal words are written into it before copying.
>>>
>>> You're writing into the text area? I would imagine that
>>> CONFIG_ARM_KERNMEM_PERMS would break that. However, that's not the
>>> right place to be building code -- shouldn't the module area be used
>>> for that?
>>>
 Possibly this should be in .rodata, not .text.
>>>
>>> Well, rodata should be neither writable nor executable.
>>
>> We're not writing into code exactly.
>>
>> This code is never executed in-place in vmlinux.  It gets copied, and
>> only copies are ever executed.
>>
>> Some pointers and offsets get poked into the code to configure it.
>>
>> I think it would be better simply to put the code in .rodata, and
>> poke paramaters into the copy, not the original -- but that's a bit
>> more awkward to code up, since the values can't be poked simply by
>> writing global variables.
>>
>>>
 There may be a few other instances of this kind of thing.
>>>
>>> This config will certainly find them! :) But, that's why it's behind a 
>>> config.
>>
>> I haven't tested exhaustively, but it think this is sufficient for a
>> Tested-by.  The patch does seem to be doing what it is intended to
>> do, and doesn't seem to be triggering false positives all over the
>> place.
>>
>>>
 Are you aware of similar situations on other arches?
>>>
>>> I think there were some problems a long time ago on x86 for rodata too.
>>
>> It would be good to get this kexec case fixed -- I'll try to hack up
>> a separate patch.
>>
>
> FWIW, we've hit issues not just with kexec but kprobes as well. The same
> problems exist with this series:

For this stage, how about I make this "depends on KEXEC=n &&
KPROBES=n"? Then as these areas get fixed, we can drop those
requirements.

-Kees

>
> / # echo p:nl 0xc01d5c00 >> /sys/kernel/debug/tracing/kprobe_events
> / # echo 1 > /sys/kernel/debug/tracing/events/kprobes/nl/enable
> [ 1639.739629] Unable to handle kernel paging request at virtual address 
> c01d5c00
> [ 1639.739655] pgd = edbc4000
> [ 1639.745730] [c01d5c00] *pgd=0001141e(bad)
> [ 1639.752413] Internal error: Oops: 80d [#1] PREEMPT SMP ARM
> [ 1639.752503] Modules linked in:
> [ 1639.760920] CPU: 0 PID: 58 Comm: sh Not tainted 
> 3.14.0-rc7-next-20140318-4-ga0191b7-dirty #170
> [ 1639.761015] task: edb90d80 ti: ed018000 task.ti: ed018000
> [ 1639.769870] PC is at patch_text+0x4/0x10
> [ 1639.775333] LR is at arm_kprobe+0x28/0x38
> [ 1639.779327] pc : []lr : []psr: 2013
> [ 1639.779327] sp : ed019f10  ip : a013  fp : 01e7fb34
> [ 1639.783241] r10:   r9 : 01e80ab8  r8 : 0002
> [ 1639.794517] r7 : ed019f80  r6 : ed900bc4  r5 : edb19fa0  r4 : edb19f08
> [ 1639.799727] r3 : c01d5c00  r2 : ed019f08  r1 : e7f001f8  r0 : c01d5c00
> [ 1639.806326] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [ 1639.812837] Control: 10c5787d  Table: 2dbc406a  DAC: 0015
> [ 1639.820040] Process sh (pid: 58, stack limit = 0xed018240)
> [ 1639.825768] Stack: (0xed019f10 to 0xed01a000)
> [ 1639.831150] 9f00:  c058bd5c 
> ed900ba0 c018b724
> [ 1639.835584] 9f20: ed6fab00  edb2d240 0002 ed019f80 c018bdc4 
>  0001
> [ 1639.843743] 9f40: edb2d240 01e80ab8 ed019f80 0002 0002 c01e1b1c 
> 01e7fb34 c011c3c0
> [ 1639.851902] 9f60: 0003   edb2d240 edb2d240 0002 
> 01e80ab8 c01e2108
> [ 1639.860063] 9f80:   00200200 00157ecc 0001 01e80ab8 
> 0004 c0106e64
> [ 1639.868222] 9fa0: ed018000 c0106ce0 00157ecc 0001 0001 01e80ab8 
> 0002 
> [ 1639.876381] 9fc0: 00157ecc 0001 01e80ab8 0004 0020 01e7fb48 
> 01e7fb14 01e7fb34
> [ 1639.884542] 9fe0:  bef4562c 0001ee5d a8cc 6010 0001 
>  
> [ 1639.892709] [] (patch_text) from [] 
> (arm_kprobe+0x28/0x38)
> [ 1639.900862] [] (arm_kprobe) from [] 
> (enable_kprobe+0x88/0x94)
> [ 1639.907983] [] (enable_kprobe) from [] 
> (__ftrace_event_enable_disable+0x13c/0x200)
> [ 1639.915537] []

Re: [PATCH] drivers/net: Use RCU_INIT_POINTER(x, NULL) in tun.c

[Paul E. McKenney]

On Sun, Mar 23, 2014 at 11:33:49PM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 23, 2014 at 12:54:17PM -0700, Eric Dumazet wrote:
> > On Sun, 2014-03-23 at 21:41 +0200, Michael S. Tsirkin wrote:
> > 
> > > The rcu_assign_pointer() ensures that the initialization of a structure   
> > > 
> > > is carried out before storing a pointer to that structure. 
> > > In the case of the NULL pointer, there is no structure to initialize,
> > > so we can safely drop smp_wmb in this case.
> > > 
> > > Signed-off-by: Michael S. Tsirkin 
> > > 
> > > --
> > > 
> > > Lightly tested.
> > > v is evaluated twice here but that should be ok since this
> > > only happens when v is a constant, so evaluating it should
> > > have no side effects.
> > > Paul, what do you think?
> > > 
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index 72bf3a0..d33c9ec 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -587,7 +587,8 @@ static inline void rcu_preempt_sleep_check(void)
> > >   */
> > >  #define rcu_assign_pointer(p, v) \
> > >   do { \
> > > - smp_wmb(); \
> > > + if (!__builtin_constant_p(v) || (v)) \
> > > + smp_wmb(); \
> > >   ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
> > >   } while (0)
> > >  
> > 
> > Yeah, I suggest you read d322f45ceed525daa changelog ;)
> > 
> 
> Oh I see. It does not seem hard to silence that warning though.
> See below.

This would at the very least need to be tested under a wide variety
of compilers.  And we need to keep 

> Alternatively apply these patches everywhere though it does
> look like too much work for too little gain to me.
> 
> -->
> 
> rcu: optimize rcu_assign_pointer with NULL
> 
> The rcu_assign_pointer() dropped __builtin_constant_p check to
> avoid a compiler warning, but we can actually work around it without
> adding code.
> 
> Signed-off-by: Michael S. Tsirkin 
> 
> ---
> 
> Untested, too late here, sorry.
> 
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 72bf3a0..9111d40 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -585,9 +585,14 @@ static inline void rcu_preempt_sleep_check(void)
>   * please be careful when making changes to rcu_assign_pointer() and the
>   * other macros that it invokes.
>   */
> +/* The convoluted __builtin_constant_p logic is here to prevent
> + * gcc from emitting a warning when passed a pointer to a variable.
> + */
>  #define rcu_assign_pointer(p, v) \
>   do { \
> - smp_wmb(); \
> + if (!__builtin_constant_p(v) || \
> + (__builtin_constant_p(v) ? (v) : NULL)) \

You lost me on this one.  If "v" is not a built-in constant, we want
the smp_wmb(), right?

Thanx, Paul

> + smp_wmb(); \
>   ACCESS_ONCE(p) = RCU_INITIALIZER(v); \
>   } while (0)
> 
> 

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

Re: w1: 3.14-rc7 - possible recursive locking detected

[David Fries]

On Mon, Mar 17, 2014 at 10:38:13PM +0100, Belisko Marek wrote:
> Hi,
> 
> booting latest 3.14-rc7 on gta04 board gives following warning:
> 
> [3.101409] Driver for 1-wire Dallas network protocol.
> [3.109649] omap_hdq omap_hdq: OMAP HDQ Hardware Rev 0.5. Driver in
> [3.400146]CPU0
> [3.402709]
> [3.405273]   lock(&(&priv->bus_notifier)->rwsem);
> [3.410308]   lock(&(&priv->bus_notifier)->rwsem);
> [3.415374]
> [3.415374]  *** DEADLOCK ***
> 
> AFAIK we didn't see that on (at least 3/14-rc2).

The last drivers/w1 change went in before v3.14-rc1, so if it is
something in the w1 code, it has either been there or something else
in the rest of the kernel changed to expose it.  I'm using the ds2490
USB w1 dongle, I didn't see that problem when enabling lock debugging
on 3.14.0-rc5+ which includes some changes I'm working on.

https://github.com/dfries/linux.git w1_rework

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