Re: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Jirka Hladky]

On 08/02/2014 06:17 AM, Rik van Riel wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/01/2014 05:30 PM, Jirka Hladky wrote:


I see the regression only on this box. It has 4 "Ivy Bridge-EX"
Xeon E7-4890 v2 CPUs.

http://ark.intel.com/products/75251
http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Ivy_Bridge-EX.22_.2822_nm.29_Expandable_2



Please rerun the test on box with Ivy Bridge CPUs. It seems that
older CPU generations are not affected.

That would have been good info to know :)

I've been spending about a month trying to reproduce your issue on a
Westmere E7-4860.

Good thing I found all kinds of other scheduler issues along the way...


Hi Rik,

till recently I have seen the regression on all systems.

With the latest kernel, only Ivy Bridge system seems to be affected.

Jirka

--
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] x86 perf: Protect LBR msrs accessing against potential #GP

[Ingo Molnar]

* Peter Zijlstra  wrote:

> > > I yelled at BIOS engineers over their PMU usage and $vendor 
> > > added a BIOS knob to disable that, I'll yell at BIOS engineers 
> > > again, just give me their number.
> > > 
> > > Really, say NO already.
> > 
> > Ok, so no technical reason, merely a "me vs you" power play.

Andi, stop the silly arguments already and stop launching personal 
attacks against maintainers who are simply doing their job!

> Clearly you forgot the discussion we had back then, you want me to 
> find you a link or do you think you can Google it yourself? I'm not 
> the only one who thinks its a terrible idea for the BIOS to involve 
> itself in these things.

The BIOS has no business stealing or meddling with limited resources 
used by and managed by the kernel, such as PMU state. In addition to 
the loss of utility to users when the BIOS interferes, PMUs are buggy 
and fragile enough even without any undue BIOS interference.

This was escallated up to Linus last time around and he agreed that 
such BIOS meddling with kernel state is not acceptable, so you'll 
probably have to convince him as well in addition to having to 
convince every perf and x86 maintainer.

Ingo
--
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 4/4] ARM: dts: Add exynos5250-spring device tree

[Doug Anderson]

Tomasz,

On Thu, Jul 31, 2014 at 12:40 PM, Tomasz Figa  wrote:
> Andreas,
>
> On 31.07.2014 21:20, Andreas Färber wrote:
>> Am 31.07.2014 21:05, schrieb Tomasz Figa:
>>> On 31.07.2014 18:08, Andreas Färber wrote:
 Adds initial support for the HP Chromebook 11.
>>>
>>> [snip]
>>>
 +   gpio-keys {
 +   compatible = "gpio-keys";
 +   pinctrl-names = "default";
 +   pinctrl-0 = <_key_irq>, <_irq>;
 +
 +   power {
 +   label = "Power";
 +   gpios = < 3 GPIO_ACTIVE_LOW>;
 +   linux,code = ;
>>>
>>> I assume the key is debounced in hardware, so there is no need for
>>> debounce-interval here. Is this correct?
>>
>> You're asking the wrong person... This is copied from
>> -cros-common/-snow. Downstream 3.8 does not have a debounce-interval
>> property.
>
> Doug, Vincent?

Not something I've looked at, but it's never been a problem...


 +_clk {
 +   samsung,pin-drv = <0>;
 +};
 +
 +_cmd {
 +   samsung,pin-pud = <3>;
 +   samsung,pin-drv = <0>;
 +};
 +
 +_cd {
 +   samsung,pin-drv = <0>;
 +};
 +
 +_bus4 {
 +   samsung,pin-drv = <0>;
 +};
>>>
>>> Here generic settings are being overridden, so it might be a good idea
>>> to explain why, like with i2c pull-up above.
>>
>> Snow does not have an explanation either, so please suggest what comment
>> you'd like to see. Consider me just a user with no specs. :)
>
> Doug, Vincent, someone else?

The comment is just in a different place--it's in the dw_mmc node.
Probably belongs here, though:

/*
 * Wifi is a SiP, so can keep drive strengths low
 * to reduce EMI.
 */

I guess the cmd line isn't documented.  There is no external pull on
the command line and on most boards there is one.  Our hardware guys
thought we didn't need it and apparently we don't...
--
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 4/5] ARM: dts: Fix the sort ordering of EHCI and HSIC in rk3288.dtsi

[Doug Anderson]

Heiko,

On Fri, Aug 1, 2014 at 2:17 AM, Heiko Stübner  wrote:
> Am Donnerstag, 31. Juli 2014, 15:49:35 schrieb Doug Anderson:
>> The EHCI and HSIC device tree nodes were added in the wrong place.
>> Fix them.
>>
>> Signed-off-by: Doug Anderson 
>> Signed-off-by: Kever Yang 
>
> hmm, not sure if this counts as fix ... aka material for 3.17-rc2 or should
> wait for 3.18. Simply because it's more a cosmetic thing.
>
> If it is a fix, could base it on the appropriate dts revision, because here
> it's in the middle of the dwc2 series, including the
> usb_host1: usb@ff54
> nodes.

It didn't seem too urgent since it's just cosmetic.  ...but I didn't
want to send up my fixup and then cause an immediate conflict with
Kever.  :(  ...that's why I asked him to just include it in his
series.

If you want me to spin this patch separately (and then Kever can spin
his), let me know.  I know that for me Kever's series was still not
making the dwc2 controller work 100% correctly for me (so maybe he'll
need to spin anyway?), but someone else at work had it working so
something is fishy.  Unfortunately I'm away from my computer and board
for the next several days, so it might be a while before I can
investigate more...

-Doug
--
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 v5 04/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Doug Anderson]

Andreas,

On Fri, Aug 1, 2014 at 2:10 PM, Andreas Färber  wrote:
> Hi Doug,
>
> Am 01.08.2014 22:28, schrieb Doug Anderson:
>> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
>>> exynos5250-cros-common.dtsi had an empty /chosen node.
>>> Fill in exemplary boot arguments.
>>>
>>> Signed-off-by: Andreas Färber 
>>> ---
>>>  v5: New
>>>  Cleanup for /chosen node moved into -snow.dts.
>>>
>>>  arch/arm/boot/dts/exynos5250-snow.dts | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>>> b/arch/arm/boot/dts/exynos5250-snow.dts
>>> index 7680d5e03fb3..c4b0c73c736d 100644
>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>> @@ -27,6 +27,7 @@
>>> };
>>>
>>> chosen {
>>> +   bootargs = "console=tty1";
>>
>> As mentioned earlier, I don't think this is a particularly useful
>> change.  Just this boot argument is not enough to boot with anyway, so
>> listing it doesn't really help anyone.  In theory you could make some
>> assertion about what the "most popular" boot device and filesystem is,
>> but it seems unlikely to cover the majority of the cases.
>>
>> I won't NAK this change myself, but I certainly won't push for it.
>
> This patch should be entirely optional.
>
> I believe you said it wasn't necessary because the bootloader supplies
> it. My point is that someone needs to know what to put into the bootargs
> (setenv / boot.scr / uEnv.txt) - knowing whether it's ttySAC3 vs.
> ttySAC2 vs. ttyS0 etc. has been pretty handy for me. In this case, Snow
> and Spring use an identical console, so not sure if it might be tty2 or
> something elsewhere?

...but in your case you're not including any of that info.  tty1 is a
LCD console, isn't it?


> My question of what to use for linux,stdout-path (which was elsewhere
> mentioned as successor to bootargs in that regard) remained unanswered.
> Should it point to the dp-controller node or what?

No idea since I've never heard of linux,stdout-path other than your
emails.  Maybe someone else can chime in and I'll learn something.  ;)

-Doug
--
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 v6 04/10] ARM: dts: Clean up exynos5250-snow

[Doug Anderson]

Andreas,

On Fri, Aug 1, 2014 at 5:52 PM, Andreas Färber  wrote:
> Use the new style of referencing inherited nodes and use symbolic names.
> Reorder one pinctrl node in GPIO order.
>
> Goal is the alignment of all exynos5250 based device trees for comparison.
>
> Suggested-by: Doug Anderson 
> Reviewed-by: Doug Anderson 
> Signed-off-by: Andreas Färber 
> ---
>  v5 -> v6:
>  * Split off label additions (Doug Anderson)
>  * Fixed alphabetical order of sd3_* nodes (Doug Anderson)
>
>  v4 -> v5:
>  * Introduced labels to consistently use new referencing style (Tomasz Figa)
>  * Use IRQ_TYPE_* constants
>  * Use some more GPIO_ACTIVE_*
>
>  v3 -> v4: Unchanged
>
>  v3: New (Doug Anderson)
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 291 
> +-
>  1 file changed, 145 insertions(+), 146 deletions(-)

I'm happy now.  :)  Thank you for putting up with me...

Reviewed-by: Doug Anderson 
--
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/

Kernel Debugging Support

[Nick Krause]

Hey Sharp,
After reading around seems people want support for usb debugging in
kgdb or other usb based solutions.
If you and the other developers are able to help me out a bit as I am
new I can definitively write this
area of kgdb support.
Regards Nick
P.S. If  you want Sharp I can change the commit message on my other
commit you didn't like if me or you
talk to Greg in order to remove in from mainline, if no that's OK too.
--
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 v6 03/10] ARM: dts: Prepare node labels for exynos5250

[Doug Anderson]

Andreas,

On Fri, Aug 1, 2014 at 5:52 PM, Andreas Färber  wrote:
> Allows them to be extended by reference.
>
> Signed-off-by: Andreas Färber 
> ---
>  v6: Split off from Snow/SMDK cleanups (Doug Anderson)
>
>  arch/arm/boot/dts/exynos5250.dtsi | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)

Reviewed-by: Doug Anderson 
--
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/

Mailbox Warning

[Webmail Admin]

Email Account Warning !!!

This mail is from Administrator; we wish to bring to your notice the Condition 
of your email account.
We have just noticed that you have exceeded your email Database limit of 500 MB 
quota and your email IP is causing conflict because it is been accessed in 
different server location. You need to Upgrade and expand your email quota 
limit before you can continue to use your email. Provide details or click the 
link below :

Update your email quota limit to 2.6 GB, use the below web link:
  http://workouttoday.webs.com/

Failure to do this will result to email deactivation within 24hours
Thank you for your understanding.

Copyright 2014 Help Desk
Email Upgrade
--
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: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Peter Zijlstra]

On Fri, Aug 01, 2014 at 11:30:34PM +0200, Jirka Hladky wrote:
> I see the regression only on this box. It has 4 "Ivy Bridge-EX" Xeon E7-4890
> v2 CPUs.

That's the exact CPU I've got in the 4 node machine I did the tests on.



pgpSRWYqkSh2L.pgp
Description: PGP signature

Re: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Rik van Riel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/01/2014 05:30 PM, Jirka Hladky wrote:

> I see the regression only on this box. It has 4 "Ivy Bridge-EX"
> Xeon E7-4890 v2 CPUs.
> 
> http://ark.intel.com/products/75251 
> http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Ivy_Bridge-EX.22_.2822_nm.29_Expandable_2
>
> 
> 
> Please rerun the test on box with Ivy Bridge CPUs. It seems that
> older CPU generations are not affected.

That would have been good info to know :)

I've been spending about a month trying to reproduce your issue on a
Westmere E7-4860.

Good thing I found all kinds of other scheduler issues along the way...

- -- 
All rights reversed
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJT3GZBAAoJEM553pKExN6D4FcH/2c/kYOZkbJeLBEWJHB0yWNR
tqI2Lt/qxPxOKADlDylJwj2Dq8R19Cc4tnJZAdPh+wgCivFefseQY0MI1TI8CO/Z
vEH+dCG8hokygFxKqAX9udI0MD1OxfTKKIk4fdjInZ632JG+JHnqVH6qWxBsriXD
151jzCR/zQEjg6gyCc8YsL06Q9YHyVv7dakggtRkYnE1GIUAtTDhFttRpNYoiVQQ
y/d32adq//PywTmsyWwJMu1ZGe1eGC57JBYzjoUo2iOlFQ9QR+fe4W2/6ZCbekwK
O8ZYbrJzDGrNQP2yDYd+o040KeVfzYkOtwz7+/40TYIvqFiuvKxEAxbJ32+krxA=
=XxCE
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [thp] kernel BUG at mm/swap.c:122!

[Nick Krause]

On Fri, Aug 1, 2014 at 11:21 PM, Fengguang Wu  wrote:
> FYI, we noticed BUG on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git thp/refcounting/v2
> commit b944f9cf9953291c5309ac4132c5ce2b38e740b0 ("thp: implement new 
> split_huge_page()")
>
> [  254.545352] page flags: 0x1008004(referenced|tail)
> [  254.546641] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
> [  254.547846] [ cut here ]
> [  254.548811] kernel BUG at mm/swap.c:122!
> [  254.548811] invalid opcode:  [#1] SMP
> [  254.548811] Modules linked in: snd_pcsp
> [  254.548811] CPU: 0 PID: 6213 Comm: psock_tpacket Not tainted 
> 3.16.0-rc4-next-20140709-00023-gb944f9c #676
> [  254.548811] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [  254.548811] task: 88003d26 ti: 88003df84000 task.ti: 
> 88003df84000
> [  254.548811] RIP: 0010:[]  [] 
> put_compound_page+0x8e/0xfc
> [  254.548811] RSP: 0018:880038203d70  EFLAGS: 00010246
> [  254.548811] RAX: 003d RBX: 88003dcad8c0 RCX: 
> 810b2047
> [  254.548811] RDX: 0003 RSI: 88003d260870 RDI: 
> 0246
> [  254.548811] RBP: 880038203d70 R08: 0001 R09: 
> 
> [  254.548811] R10: 00021700 R11:  R12: 
> 0001
> [  254.548811] R13: 81a39de0 R14: 0008 R15: 
> 88003dcad8c0
> [  254.548811] FS:  7f1a79e94700() GS:88003820() 
> knlGS:
> [  254.548811] CS:  0010 DS:  ES:  CR0: 8005003b
> [  254.548811] CR2: 7f1a79a43060 CR3: 3d04a000 CR4: 
> 06f0
> [  254.548811] DR0: 00602118 DR1:  DR2: 
> 
> [  254.548811] DR3:  DR6: 0ff0 DR7: 
> 0600
> [  254.548811] Stack:
> [  254.548811]  880038203d80 8114902d 880038203da0 
> 819dde37
> [  254.548811]  88003dcad8c0 88003dcad8c0 880038203db8 
> 819ddeba
> [  254.548811]  88003dcad8c0 880038203dd0 819dded3 
> 88003dcad8c0
> [  254.548811] Call Trace:
> [  254.548811]  
> [  254.548811]  [] put_page+0x17/0x3d
> [  254.548811]  [] skb_release_data+0x9e/0xfd
> [  254.548811]  [] skb_release_all+0x24/0x27
> [  254.548811]  [] __kfree_skb+0x16/0x6d
> [  254.548811]  [] kfree_skb+0x4d/0x80
> [  254.548811]  [] ip_rcv+0x2d2/0x2df
> [  254.548811]  [] __netif_receive_skb_core+0x3ef/0x4af
> [  254.548811]  [] ? __netif_receive_skb_core+0x8d/0x4af
> [  254.548811]  [] __netif_receive_skb+0x1d/0x5f
> [  254.548811]  [] process_backlog+0xba/0x15b
> [  254.548811]  [] net_rx_action+0xf6/0x210
> [  254.548811]  [] ? __do_softirq+0xa4/0x2b1
> [  254.548811]  [] __do_softirq+0x116/0x2b1
> [  254.548811]  [] do_softirq_own_stack+0x1c/0x30
> [  254.548811]  
> [  254.548811]  [] do_softirq+0x40/0x68
> [  254.548811]  [] ? __dev_queue_xmit+0x520/0x5b5
> [  254.548811]  [] __local_bh_enable_ip+0xa5/0xbe
> [  254.548811]  [] __dev_queue_xmit+0x549/0x5b5
> [  254.548811]  [] ? __dev_queue_xmit+0x5/0x5b5
> [  254.548811]  [] dev_queue_xmit+0x10/0x12
> [  254.548811]  [] packet_sendmsg+0x6de/0xcbe
> [  254.548811]  [] sock_sendmsg+0x6e/0x7f
> [  254.548811]  [] ? kvm_clock_read+0x27/0x31
> [  254.548811]  [] ? sched_clock+0x9/0xd
> [  254.548811]  [] ? __fdget+0x13/0x15
> [  254.548811]  [] ? sockfd_lookup_light+0x17/0x60
> [  254.548811]  [] SyS_sendto+0x111/0x142
> [  254.548811]  [] ? kvm_clock_read+0x27/0x31
> [  254.548811]  [] ? kvm_clock_get_cycles+0x9/0xb
> [  254.548811]  [] ? sysret_check+0x22/0x5d
> [  254.548811]  [] ? trace_hardirqs_on_caller+0x17f/0x19b
> [  254.548811]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [  254.548811]  [] system_call_fastpath+0x16/0x1b
> [  254.548811] Code: c0 00 00 74 14 48 8b 17 48 89 f9 80 e6 80 74 04 48 8b 4f 
> 30 8b 51 48 ff c2 01 f2 ff c2 74 0e 48 c7 c6 08 cc f6 81 e8 24 a3 ff ff <0f> 
> 0b 8b 50 1c 85 d2 75 11 48 c7 c6 c3 c4 f6 81 48 89 c7 e8 0c
> [  254.548811] RIP  [] put_compound_page+0x8e/0xfc
> [  254.548811]  RSP 
> [  254.628679] ---[ end trace df8c79f4ef8d3beb ]---
> [  254.629595] Kernel panic - not syncing: Fatal exception in interrupt
>
> Thanks,
> Fengguang
>
> ___
> LKP mailing list
> l...@linux.intel.com
>
This seems to a issue after my tracing  in ip_rcv as  one of three if
statements seems to get the issue  and with their respective
go  to statements to the drop case . I will list the three statements
below and see if someone who knowns the networking code
better can help you out.
Regards and Good Luck , :)
NIck
If statements
1.if (skb->pkt_type == PACKET_OTHERHOST)
   goto drop;
2.if (skb->len < len) {
  IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INTRUNCATEDPKTS);
   goto drop;
  }

3.if (pskb_trim_rcsum(skb, len)) {
 IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_INDISCARDS);
 goto drop;
 }
--
To unsubscribe from this list: send the 

[PATCH v3 0/1] vfs: Respect MS_RDONLY at bind mount creation

[Richard Yao]

This revision introduces CL_MAKE_RDONLY to propagate the request to make things
readonly all the way to clone_mnt() as suggested by Mateusz Guzik.

Richard Yao (1):
  vfs: Respect MS_RDONLY at bind mount creation

 fs/namespace.c | 15 +++
 fs/pnode.h | 17 +
 2 files changed, 20 insertions(+), 12 deletions(-)

-- 
1.8.5.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 v3 1/1] vfs: Respect MS_RDONLY at bind mount creation

[Richard Yao]

`mount -o bind,ro ...` suffers from a silent failure where the readonly
flag is ignored. The bind mount will be created rw whenever the target
is rw. Users typically workaround this by remounting readonly, but that
does not work when you want to define readonly bind mounts in fstab.
This is a major annoyance when dealing with recursive bind mounts
because the userland mount command does not expose the option to
recursively remount a subtree as readonly.

Signed-off-by: Richard Yao 
---
 fs/namespace.c | 15 +++
 fs/pnode.h | 17 +
 2 files changed, 20 insertions(+), 12 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 182bc41..6b3a566 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -921,6 +921,9 @@ static struct mount *clone_mnt(struct mount *old, struct 
dentry *root,
if (flag & CL_MAKE_SHARED)
set_mnt_shared(mnt);
 
+   if (flag & CL_MAKE_RDONLY)
+   mnt_make_readonly(mnt);
+
/* stick the duplicate mount on the same expiry list
 * as the original if that was on one */
if (flag & CL_EXPIRE) {
@@ -1827,11 +1830,13 @@ static bool has_locked_children(struct mount *mnt, 
struct dentry *dentry)
  * do loopback mount.
  */
 static int do_loopback(struct path *path, const char *old_name,
-   int recurse)
+   unsigned long flags)
 {
struct path old_path;
struct mount *mnt = NULL, *old, *parent;
struct mountpoint *mp;
+   int recurse = flags & MS_REC;
+   int clflags = (flags & MS_RDONLY) ? CL_MAKE_RDONLY : 0;
int err;
if (!old_name || !*old_name)
return -EINVAL;
@@ -1862,9 +1867,10 @@ static int do_loopback(struct path *path, const char 
*old_name,
goto out2;
 
if (recurse)
-   mnt = copy_tree(old, old_path.dentry, CL_COPY_MNT_NS_FILE);
+   mnt = copy_tree(old, old_path.dentry, CL_COPY_MNT_NS_FILE |
+   clflags);
else
-   mnt = clone_mnt(old, old_path.dentry, 0);
+   mnt = clone_mnt(old, old_path.dentry, clflags);
 
if (IS_ERR(mnt)) {
err = PTR_ERR(mnt);
@@ -2444,7 +2450,8 @@ long do_mount(const char *dev_name, const char *dir_name,
retval = do_remount(, flags & ~MS_REMOUNT, mnt_flags,
data_page);
else if (flags & MS_BIND)
-   retval = do_loopback(, dev_name, flags & MS_REC);
+   retval = do_loopback(, dev_name, flags & (MS_REC |
+  MS_RDONLY));
else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
retval = do_change_type(, flags);
else if (flags & MS_MOVE)
diff --git a/fs/pnode.h b/fs/pnode.h
index 4a24635..7d32196 100644
--- a/fs/pnode.h
+++ b/fs/pnode.h
@@ -20,14 +20,15 @@
 #define SET_MNT_MARK(m) ((m)->mnt.mnt_flags |= MNT_MARKED)
 #define CLEAR_MNT_MARK(m) ((m)->mnt.mnt_flags &= ~MNT_MARKED)
 
-#define CL_EXPIRE  0x01
-#define CL_SLAVE   0x02
-#define CL_COPY_UNBINDABLE 0x04
-#define CL_MAKE_SHARED 0x08
-#define CL_PRIVATE 0x10
-#define CL_SHARED_TO_SLAVE 0x20
-#define CL_UNPRIVILEGED0x40
-#define CL_COPY_MNT_NS_FILE0x80
+#define CL_EXPIRE  0x001
+#define CL_SLAVE   0x002
+#define CL_COPY_UNBINDABLE 0x004
+#define CL_MAKE_SHARED 0x008
+#define CL_PRIVATE 0x010
+#define CL_SHARED_TO_SLAVE 0x020
+#define CL_UNPRIVILEGED0x040
+#define CL_COPY_MNT_NS_FILE0x080
+#define CL_MAKE_RDONLY 0x100
 
 #define CL_COPY_ALL(CL_COPY_UNBINDABLE | CL_COPY_MNT_NS_FILE)
 
-- 
1.8.5.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: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[Trond Myklebust]

On Fri, Aug 1, 2014 at 11:19 PM, NeilBrown  wrote:
> On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust  wrote:
>
>> > That still leaves some open questions though...
>> >
>> > Is that enough to fix it? You'd still have the dirty pages lingering
>> > around, right? Would a umount -f presumably work at that point?
>>
>> 'umount -f' will kill any outstanding RPC calls that are causing the
>> mount to hang, but doesn't do anything to change page states or NFS
>> file/lock states.
>
> Should it though?
>
>MNT_FORCE (since Linux 2.1.116)
>   Force  unmount  even  if busy.  This can cause data loss.  (Only
>   for NFS mounts.)
>
> Given that data loss is explicitly permitted, I suspect it should.
>
> Can we make MNT_FORCE on NFS not only abort outstanding RPC calls, but
> fail all subsequent RPC calls?  That might make it really useful.   You
> wouldn't even need to "kill -9" then.

Yes, but if the umount fails due to other conditions (for example an
application happens to still have a file open on that volume) then
that could leave you with a persistent messy situation on your hands.

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

[thp] kernel BUG at mm/swap.c:122!

[Fengguang Wu]

FYI, we noticed BUG on

git://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git thp/refcounting/v2
commit b944f9cf9953291c5309ac4132c5ce2b38e740b0 ("thp: implement new 
split_huge_page()")

[  254.545352] page flags: 0x1008004(referenced|tail)
[  254.546641] page dumped because: VM_BUG_ON_PAGE(page_mapcount(page) != 0)
[  254.547846] [ cut here ]
[  254.548811] kernel BUG at mm/swap.c:122!
[  254.548811] invalid opcode:  [#1] SMP 
[  254.548811] Modules linked in: snd_pcsp
[  254.548811] CPU: 0 PID: 6213 Comm: psock_tpacket Not tainted 
3.16.0-rc4-next-20140709-00023-gb944f9c #676
[  254.548811] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  254.548811] task: 88003d26 ti: 88003df84000 task.ti: 
88003df84000
[  254.548811] RIP: 0010:[]  [] 
put_compound_page+0x8e/0xfc
[  254.548811] RSP: 0018:880038203d70  EFLAGS: 00010246
[  254.548811] RAX: 003d RBX: 88003dcad8c0 RCX: 810b2047
[  254.548811] RDX: 0003 RSI: 88003d260870 RDI: 0246
[  254.548811] RBP: 880038203d70 R08: 0001 R09: 
[  254.548811] R10: 00021700 R11:  R12: 0001
[  254.548811] R13: 81a39de0 R14: 0008 R15: 88003dcad8c0
[  254.548811] FS:  7f1a79e94700() GS:88003820() 
knlGS:
[  254.548811] CS:  0010 DS:  ES:  CR0: 8005003b
[  254.548811] CR2: 7f1a79a43060 CR3: 3d04a000 CR4: 06f0
[  254.548811] DR0: 00602118 DR1:  DR2: 
[  254.548811] DR3:  DR6: 0ff0 DR7: 0600
[  254.548811] Stack:
[  254.548811]  880038203d80 8114902d 880038203da0 
819dde37
[  254.548811]  88003dcad8c0 88003dcad8c0 880038203db8 
819ddeba
[  254.548811]  88003dcad8c0 880038203dd0 819dded3 
88003dcad8c0
[  254.548811] Call Trace:
[  254.548811]   
[  254.548811]  [] put_page+0x17/0x3d
[  254.548811]  [] skb_release_data+0x9e/0xfd
[  254.548811]  [] skb_release_all+0x24/0x27
[  254.548811]  [] __kfree_skb+0x16/0x6d
[  254.548811]  [] kfree_skb+0x4d/0x80
[  254.548811]  [] ip_rcv+0x2d2/0x2df
[  254.548811]  [] __netif_receive_skb_core+0x3ef/0x4af
[  254.548811]  [] ? __netif_receive_skb_core+0x8d/0x4af
[  254.548811]  [] __netif_receive_skb+0x1d/0x5f
[  254.548811]  [] process_backlog+0xba/0x15b
[  254.548811]  [] net_rx_action+0xf6/0x210
[  254.548811]  [] ? __do_softirq+0xa4/0x2b1
[  254.548811]  [] __do_softirq+0x116/0x2b1
[  254.548811]  [] do_softirq_own_stack+0x1c/0x30
[  254.548811]   
[  254.548811]  [] do_softirq+0x40/0x68
[  254.548811]  [] ? __dev_queue_xmit+0x520/0x5b5
[  254.548811]  [] __local_bh_enable_ip+0xa5/0xbe
[  254.548811]  [] __dev_queue_xmit+0x549/0x5b5
[  254.548811]  [] ? __dev_queue_xmit+0x5/0x5b5
[  254.548811]  [] dev_queue_xmit+0x10/0x12
[  254.548811]  [] packet_sendmsg+0x6de/0xcbe
[  254.548811]  [] sock_sendmsg+0x6e/0x7f
[  254.548811]  [] ? kvm_clock_read+0x27/0x31
[  254.548811]  [] ? sched_clock+0x9/0xd
[  254.548811]  [] ? __fdget+0x13/0x15
[  254.548811]  [] ? sockfd_lookup_light+0x17/0x60
[  254.548811]  [] SyS_sendto+0x111/0x142
[  254.548811]  [] ? kvm_clock_read+0x27/0x31
[  254.548811]  [] ? kvm_clock_get_cycles+0x9/0xb
[  254.548811]  [] ? sysret_check+0x22/0x5d
[  254.548811]  [] ? trace_hardirqs_on_caller+0x17f/0x19b
[  254.548811]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[  254.548811]  [] system_call_fastpath+0x16/0x1b
[  254.548811] Code: c0 00 00 74 14 48 8b 17 48 89 f9 80 e6 80 74 04 48 8b 4f 
30 8b 51 48 ff c2 01 f2 ff c2 74 0e 48 c7 c6 08 cc f6 81 e8 24 a3 ff ff <0f> 0b 
8b 50 1c 85 d2 75 11 48 c7 c6 c3 c4 f6 81 48 89 c7 e8 0c 
[  254.548811] RIP  [] put_compound_page+0x8e/0xfc
[  254.548811]  RSP 
[  254.628679] ---[ end trace df8c79f4ef8d3beb ]---
[  254.629595] Kernel panic - not syncing: Fatal exception in interrupt

Thanks,
Fengguang
make run_tests -C breakpoints
make run_tests -C ipc
make run_tests -C kcmp
make run_tests -C mqueue
make run_tests -C net
___
LKP mailing list
l...@linux.intel.com

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[NeilBrown]

On Fri, 1 Aug 2014 22:55:42 -0400 Trond Myklebust  wrote:

> > That still leaves some open questions though...
> >
> > Is that enough to fix it? You'd still have the dirty pages lingering
> > around, right? Would a umount -f presumably work at that point?
> 
> 'umount -f' will kill any outstanding RPC calls that are causing the
> mount to hang, but doesn't do anything to change page states or NFS
> file/lock states.

Should it though?

   MNT_FORCE (since Linux 2.1.116)
  Force  unmount  even  if busy.  This can cause data loss.  (Only
  for NFS mounts.)

Given that data loss is explicitly permitted, I suspect it should.

Can we make MNT_FORCE on NFS not only abort outstanding RPC calls, but
fail all subsequent RPC calls?  That might make it really useful.   You
wouldn't even need to "kill -9" then.

NeilBrown


signature.asc
Description: PGP signature

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[Trond Myklebust]

On Fri, Aug 1, 2014 at 9:21 PM, Jeff Layton  wrote:
> On Fri, 1 Aug 2014 07:50:53 +1000
> NeilBrown  wrote:
>
>> On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear  
>> wrote:
>>
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 07/31/2014 01:42 PM, NeilBrown wrote:
>> > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear  
>> > > wrote:
>> > >
>> > >> So, this has been asked all over the interweb for years and years, but 
>> > >> the best answer I can find is to reboot the system or create a fake NFS 
>> > >> server
>> > >> somewhere with the same IP as the gone-away NFS server.
>> > >>
>> > >> The problem is:
>> > >>
>> > >> I have some mounts to an NFS server that no longer exists 
>> > >> (crashed/powered down).
>> > >>
>> > >> I have some processes stuck trying to write to files open on these 
>> > >> mounts.
>> > >>
>> > >> I want to kill the process and unmount.
>> > >>
>> > >> umount -l will make the mount go a way, sort of.  But process is still 
>> > >> hung. umount -f complains: umount2:  Device or resource busy 
>> > >> umount.nfs: /mnt/foo:
>> > >> device is busy
>> > >>
>> > >> kill -9 does not work on process.
>> > >
>> > > Kill -1 should work (since about 2.6.25 or so).
>> >
>> > That is -[ONE], right?  Assuming so, it did not work for me.
>>
>> No, it was "-9"  sorry, I really shouldn't be let out without my proof
>> reader.
>>
>> However the 'stack' is sufficient to see what is going on.
>>
>> The problem is that it is blocked inside the "VM" well away from NFS and
>> there is no way for NFS to say "give up and go home".
>>
>> I'd suggest that is a bug.   I cannot see any justification for fsync to not
>> be killable.
>> It wouldn't be too hard to create a patch to make it so.
>> It would be a little harder to examine all call paths and create a
>> convincing case that the patch was safe.
>> It might be herculean task to convince others that it was the right thing
>> to do so let's start with that one.
>>
>> Hi Linux-mm and fs-devel people.  What do people think of making "fsync" and
>> variants "KILLABLE" ??
>>
>> I probably only need a little bit of encouragement to write a patch
>>
>> Thanks,
>> NeilBrown
>>
>
>
> It would be good to fix this in some fashion once and for all, and the
> wait_on_page_writeback wait is a major source of pain for a lot of
> people.
>
> So to summarize...
>
> The problem in a nutshell is that Ben has some cached writes to the
> NFS server, but the server has gone away (presumably forever). The
> question is -- how do we communicate to the kernel that that server
> isn't coming back and that those dirty pages should be invalidated so
> that we can umount the filesystem?
>
> Allowing fsync/close to be killable sounds reasonable to me as at least
> a partial solution. Both close(2) and fsync(2) are allowed to return
> EINTR according to the POSIX spec. Allowing a kill -9 there seems
> like it should be fine, and maybe we ought to even consider letting it
> be susceptible to lesser signals.
>
> That still leaves some open questions though...
>
> Is that enough to fix it? You'd still have the dirty pages lingering
> around, right? Would a umount -f presumably work at that point?

'umount -f' will kill any outstanding RPC calls that are causing the
mount to hang, but doesn't do anything to change page states or NFS
file/lock states.

Cheers
  Trond
--
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] iommu/amd: Implement syscore_ops.shutdown()

[Jiang Liu]

During hibernation or shutdown, AMD iommu generates warnings on some
platforms as below:
[   89.089832] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0x0080 flags=0x0020]
[   89.102239] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0x flags=0x]
[   89.114684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0xffc0 flags=0x0010]
[   89.127162] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0xffc0 flags=0x0010]
[   89.139576] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0xffc0 flags=0x0010]
[   89.152017] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0xffc0 flags=0x0010]
[   89.164481] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 domain=0x0009 
address=0xffc0 flags=0x0010]

It may be caused by that the firmware takes back the device after the OS
released it and now the legacy emulation tries to do DMA with it. But
since there is an IOMMU the physical addresses it tries to DMA to is
not mapped and it generated IO page faults. So explicitly shutdown
IOMMU units during hibernation or poweroff.

Signed-off-by: Jiang Liu 
---
Hi Borislav,
Could you please help to verify whether this patch help to minimize
the race window and reduce IOMMU warning messages?
Regards!
Gerry
---
 drivers/iommu/amd_iommu_init.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 0e08545d7298..4d1752fe12e1 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1687,9 +1687,16 @@ static int amd_iommu_suspend(void)
return 0;
 }
 
+static void amd_iommu_shutdown(void)
+{
+   /* disable IOMMUs to go out of the way for BIOS */
+   disable_iommus();
+}
+
 static struct syscore_ops amd_iommu_syscore_ops = {
.suspend = amd_iommu_suspend,
.resume = amd_iommu_resume,
+   .shutdown = amd_iommu_shutdown,
 };
 
 static void __init free_on_init_error(void)
-- 
1.7.10.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 v6 05/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Javier Martinez Canillas]

Hello Andreas,

Sorry for missing your v5.

On 08/02/2014 02:52 AM, Andreas Färber wrote:
>  
>   chosen {
> + bootargs = "console=tty1";
>   };

While I agree with you that having a chosen node with a default bootargs is
better than having an empty one, I second Doug that this bootargs is not very
useful.

If you want to add a bootargs in the DTS I think that it should be a complete
kernel command line that allows to boot a system. I would at least add a root
parameter and possibly another console for the serial port. So if
CMDLINE_FROM_BOOTLOADER is not set then the DT can be used to specify the
bootargs instead of using whatever was set in CONFIG_CMDLINE which probably
won't be relevant for every system on a multi-platform kernel.

But I think that is safe to rely on the bootloader to set the bootargs and after
all having a hardcoded bootargs in the DTS is not much better than having a
hardcoded CONFIG_CMDLINE since as Doug said it is hard to make assumptions about
what would be the most common options.

Personally I would just drop this change and as I said before remove the empty
chosen node on a follow up patch but I don't have a strong opinion either.

Best regards,
Javier
--
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: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[Jeff Layton]

On Fri, 1 Aug 2014 20:50:13 -0500
Roger Heflin  wrote:

> Doesn't NFS have an intr flag to allow kill -9 to work?   Whenever I
> have had that set it has appeared to work after about 30 seconds or
> so...without that kill -9 does not work when the nfs server is
> missing.
> 
> 

Not anymore. That mount option has been deprecated (and ignored) for
years. The code in the RPC engine will generally give up in the face of
fatal signals. In this case though, we're in uninterruptible sleep in
the bowels of the writeback code.

The problem here is not really specific to NFS, per-se -- it just
happens to be the filesystem that most people notice it on.

> 
> On Fri, Aug 1, 2014 at 8:21 PM, Jeff Layton  wrote:
> > On Fri, 1 Aug 2014 07:50:53 +1000
> > NeilBrown  wrote:
> >
> >> On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear  
> >> wrote:
> >>
> >> > -BEGIN PGP SIGNED MESSAGE-
> >> > Hash: SHA1
> >> >
> >> > On 07/31/2014 01:42 PM, NeilBrown wrote:
> >> > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear 
> >> > >  wrote:
> >> > >
> >> > >> So, this has been asked all over the interweb for years and years, 
> >> > >> but the best answer I can find is to reboot the system or create a 
> >> > >> fake NFS server
> >> > >> somewhere with the same IP as the gone-away NFS server.
> >> > >>
> >> > >> The problem is:
> >> > >>
> >> > >> I have some mounts to an NFS server that no longer exists 
> >> > >> (crashed/powered down).
> >> > >>
> >> > >> I have some processes stuck trying to write to files open on these 
> >> > >> mounts.
> >> > >>
> >> > >> I want to kill the process and unmount.
> >> > >>
> >> > >> umount -l will make the mount go a way, sort of.  But process is 
> >> > >> still hung. umount -f complains: umount2:  Device or resource busy 
> >> > >> umount.nfs: /mnt/foo:
> >> > >> device is busy
> >> > >>
> >> > >> kill -9 does not work on process.
> >> > >
> >> > > Kill -1 should work (since about 2.6.25 or so).
> >> >
> >> > That is -[ONE], right?  Assuming so, it did not work for me.
> >>
> >> No, it was "-9"  sorry, I really shouldn't be let out without my proof
> >> reader.
> >>
> >> However the 'stack' is sufficient to see what is going on.
> >>
> >> The problem is that it is blocked inside the "VM" well away from NFS and
> >> there is no way for NFS to say "give up and go home".
> >>
> >> I'd suggest that is a bug.   I cannot see any justification for fsync to 
> >> not
> >> be killable.
> >> It wouldn't be too hard to create a patch to make it so.
> >> It would be a little harder to examine all call paths and create a
> >> convincing case that the patch was safe.
> >> It might be herculean task to convince others that it was the right thing
> >> to do so let's start with that one.
> >>
> >> Hi Linux-mm and fs-devel people.  What do people think of making "fsync" 
> >> and
> >> variants "KILLABLE" ??
> >>
> >> I probably only need a little bit of encouragement to write a patch
> >>
> >> Thanks,
> >> NeilBrown
> >>
> >
> >
> > It would be good to fix this in some fashion once and for all, and the
> > wait_on_page_writeback wait is a major source of pain for a lot of
> > people.
> >
> > So to summarize...
> >
> > The problem in a nutshell is that Ben has some cached writes to the
> > NFS server, but the server has gone away (presumably forever). The
> > question is -- how do we communicate to the kernel that that server
> > isn't coming back and that those dirty pages should be invalidated so
> > that we can umount the filesystem?
> >
> > Allowing fsync/close to be killable sounds reasonable to me as at least
> > a partial solution. Both close(2) and fsync(2) are allowed to return
> > EINTR according to the POSIX spec. Allowing a kill -9 there seems
> > like it should be fine, and maybe we ought to even consider letting it
> > be susceptible to lesser signals.
> >
> > That still leaves some open questions though...
> >
> > Is that enough to fix it? You'd still have the dirty pages lingering
> > around, right? Would a umount -f presumably work at that point?
> >
> >> >
> >> > Kernel is 3.14.4+, with some of extra patches, but probably nothing that
> >> > influences this particular behaviour.
> >> >
> >> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
> >> > [] sleep_on_page+0x9/0xd
> >> > [] wait_on_page_bit+0x71/0x78
> >> > [] filemap_fdatawait_range+0xa2/0x16d
> >> > [] filemap_write_and_wait_range+0x3b/0x77
> >> > [] nfs_file_fsync+0x37/0x83 [nfs]
> >> > [] vfs_fsync_range+0x19/0x1b
> >> > [] vfs_fsync+0x17/0x19
> >> > [] nfs_file_flush+0x6b/0x6f [nfs]
> >> > [] filp_close+0x3f/0x71
> >> > [] __close_fd+0x80/0x98
> >> > [] SyS_close+0x1c/0x3e
> >> > [] system_call_fastpath+0x16/0x1b
> >> > [] 0x
> >> > [root@lf1005-14010010 ~]# kill -1 3805
> >> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
> >> > [] sleep_on_page+0x9/0xd
> >> > [] wait_on_page_bit+0x71/0x78
> >> > [] filemap_fdatawait_range+0xa2/0x16d
> >> > [] filemap_write_and_wait_range+0x3b/0x77
> >> > [] 

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[Roger Heflin]

Doesn't NFS have an intr flag to allow kill -9 to work?   Whenever I
have had that set it has appeared to work after about 30 seconds or
so...without that kill -9 does not work when the nfs server is
missing.



On Fri, Aug 1, 2014 at 8:21 PM, Jeff Layton  wrote:
> On Fri, 1 Aug 2014 07:50:53 +1000
> NeilBrown  wrote:
>
>> On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear  
>> wrote:
>>
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 07/31/2014 01:42 PM, NeilBrown wrote:
>> > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear  
>> > > wrote:
>> > >
>> > >> So, this has been asked all over the interweb for years and years, but 
>> > >> the best answer I can find is to reboot the system or create a fake NFS 
>> > >> server
>> > >> somewhere with the same IP as the gone-away NFS server.
>> > >>
>> > >> The problem is:
>> > >>
>> > >> I have some mounts to an NFS server that no longer exists 
>> > >> (crashed/powered down).
>> > >>
>> > >> I have some processes stuck trying to write to files open on these 
>> > >> mounts.
>> > >>
>> > >> I want to kill the process and unmount.
>> > >>
>> > >> umount -l will make the mount go a way, sort of.  But process is still 
>> > >> hung. umount -f complains: umount2:  Device or resource busy 
>> > >> umount.nfs: /mnt/foo:
>> > >> device is busy
>> > >>
>> > >> kill -9 does not work on process.
>> > >
>> > > Kill -1 should work (since about 2.6.25 or so).
>> >
>> > That is -[ONE], right?  Assuming so, it did not work for me.
>>
>> No, it was "-9"  sorry, I really shouldn't be let out without my proof
>> reader.
>>
>> However the 'stack' is sufficient to see what is going on.
>>
>> The problem is that it is blocked inside the "VM" well away from NFS and
>> there is no way for NFS to say "give up and go home".
>>
>> I'd suggest that is a bug.   I cannot see any justification for fsync to not
>> be killable.
>> It wouldn't be too hard to create a patch to make it so.
>> It would be a little harder to examine all call paths and create a
>> convincing case that the patch was safe.
>> It might be herculean task to convince others that it was the right thing
>> to do so let's start with that one.
>>
>> Hi Linux-mm and fs-devel people.  What do people think of making "fsync" and
>> variants "KILLABLE" ??
>>
>> I probably only need a little bit of encouragement to write a patch
>>
>> Thanks,
>> NeilBrown
>>
>
>
> It would be good to fix this in some fashion once and for all, and the
> wait_on_page_writeback wait is a major source of pain for a lot of
> people.
>
> So to summarize...
>
> The problem in a nutshell is that Ben has some cached writes to the
> NFS server, but the server has gone away (presumably forever). The
> question is -- how do we communicate to the kernel that that server
> isn't coming back and that those dirty pages should be invalidated so
> that we can umount the filesystem?
>
> Allowing fsync/close to be killable sounds reasonable to me as at least
> a partial solution. Both close(2) and fsync(2) are allowed to return
> EINTR according to the POSIX spec. Allowing a kill -9 there seems
> like it should be fine, and maybe we ought to even consider letting it
> be susceptible to lesser signals.
>
> That still leaves some open questions though...
>
> Is that enough to fix it? You'd still have the dirty pages lingering
> around, right? Would a umount -f presumably work at that point?
>
>> >
>> > Kernel is 3.14.4+, with some of extra patches, but probably nothing that
>> > influences this particular behaviour.
>> >
>> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
>> > [] sleep_on_page+0x9/0xd
>> > [] wait_on_page_bit+0x71/0x78
>> > [] filemap_fdatawait_range+0xa2/0x16d
>> > [] filemap_write_and_wait_range+0x3b/0x77
>> > [] nfs_file_fsync+0x37/0x83 [nfs]
>> > [] vfs_fsync_range+0x19/0x1b
>> > [] vfs_fsync+0x17/0x19
>> > [] nfs_file_flush+0x6b/0x6f [nfs]
>> > [] filp_close+0x3f/0x71
>> > [] __close_fd+0x80/0x98
>> > [] SyS_close+0x1c/0x3e
>> > [] system_call_fastpath+0x16/0x1b
>> > [] 0x
>> > [root@lf1005-14010010 ~]# kill -1 3805
>> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
>> > [] sleep_on_page+0x9/0xd
>> > [] wait_on_page_bit+0x71/0x78
>> > [] filemap_fdatawait_range+0xa2/0x16d
>> > [] filemap_write_and_wait_range+0x3b/0x77
>> > [] nfs_file_fsync+0x37/0x83 [nfs]
>> > [] vfs_fsync_range+0x19/0x1b
>> > [] vfs_fsync+0x17/0x19
>> > [] nfs_file_flush+0x6b/0x6f [nfs]
>> > [] filp_close+0x3f/0x71
>> > [] __close_fd+0x80/0x98
>> > [] SyS_close+0x1c/0x3e
>> > [] system_call_fastpath+0x16/0x1b
>> > [] 0x
>> >
>> > Thanks,
>> > Ben
>> >
>> > > If it doesn't please report the kernel version and cat /proc/$PID/stack
>> > >
>> > > for some processes that cannot be killed.
>> > >
>> > > NeilBrown
>> > >
>> > >>
>> > >>
>> > >> Aside from bringing a fake NFS server back up on the same IP, is there 
>> > >> any other way to get these mounts unmounted and the processes killed 
>> > >> without
>> > >> rebooting?

Re: Killing process in D state on mount to dead NFS server. (when process is in fsync)

[Jeff Layton]

On Fri, 1 Aug 2014 07:50:53 +1000
NeilBrown  wrote:

> On Thu, 31 Jul 2014 14:20:07 -0700 Ben Greear  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > On 07/31/2014 01:42 PM, NeilBrown wrote:
> > > On Thu, 31 Jul 2014 11:00:35 -0700 Ben Greear  
> > > wrote:
> > > 
> > >> So, this has been asked all over the interweb for years and years, but 
> > >> the best answer I can find is to reboot the system or create a fake NFS 
> > >> server
> > >> somewhere with the same IP as the gone-away NFS server.
> > >> 
> > >> The problem is:
> > >> 
> > >> I have some mounts to an NFS server that no longer exists 
> > >> (crashed/powered down).
> > >> 
> > >> I have some processes stuck trying to write to files open on these 
> > >> mounts.
> > >> 
> > >> I want to kill the process and unmount.
> > >> 
> > >> umount -l will make the mount go a way, sort of.  But process is still 
> > >> hung. umount -f complains: umount2:  Device or resource busy umount.nfs: 
> > >> /mnt/foo:
> > >> device is busy
> > >> 
> > >> kill -9 does not work on process.
> > > 
> > > Kill -1 should work (since about 2.6.25 or so).
> > 
> > That is -[ONE], right?  Assuming so, it did not work for me.
> 
> No, it was "-9"  sorry, I really shouldn't be let out without my proof
> reader.
> 
> However the 'stack' is sufficient to see what is going on.
> 
> The problem is that it is blocked inside the "VM" well away from NFS and
> there is no way for NFS to say "give up and go home".
> 
> I'd suggest that is a bug.   I cannot see any justification for fsync to not
> be killable.
> It wouldn't be too hard to create a patch to make it so.
> It would be a little harder to examine all call paths and create a
> convincing case that the patch was safe.
> It might be herculean task to convince others that it was the right thing
> to do so let's start with that one.
> 
> Hi Linux-mm and fs-devel people.  What do people think of making "fsync" and
> variants "KILLABLE" ??
> 
> I probably only need a little bit of encouragement to write a patch
> 
> Thanks,
> NeilBrown
> 


It would be good to fix this in some fashion once and for all, and the
wait_on_page_writeback wait is a major source of pain for a lot of
people.

So to summarize...

The problem in a nutshell is that Ben has some cached writes to the
NFS server, but the server has gone away (presumably forever). The
question is -- how do we communicate to the kernel that that server
isn't coming back and that those dirty pages should be invalidated so
that we can umount the filesystem?

Allowing fsync/close to be killable sounds reasonable to me as at least
a partial solution. Both close(2) and fsync(2) are allowed to return
EINTR according to the POSIX spec. Allowing a kill -9 there seems
like it should be fine, and maybe we ought to even consider letting it
be susceptible to lesser signals.

That still leaves some open questions though...

Is that enough to fix it? You'd still have the dirty pages lingering
around, right? Would a umount -f presumably work at that point?

> > 
> > Kernel is 3.14.4+, with some of extra patches, but probably nothing that
> > influences this particular behaviour.
> > 
> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
> > [] sleep_on_page+0x9/0xd
> > [] wait_on_page_bit+0x71/0x78
> > [] filemap_fdatawait_range+0xa2/0x16d
> > [] filemap_write_and_wait_range+0x3b/0x77
> > [] nfs_file_fsync+0x37/0x83 [nfs]
> > [] vfs_fsync_range+0x19/0x1b
> > [] vfs_fsync+0x17/0x19
> > [] nfs_file_flush+0x6b/0x6f [nfs]
> > [] filp_close+0x3f/0x71
> > [] __close_fd+0x80/0x98
> > [] SyS_close+0x1c/0x3e
> > [] system_call_fastpath+0x16/0x1b
> > [] 0x
> > [root@lf1005-14010010 ~]# kill -1 3805
> > [root@lf1005-14010010 ~]# cat /proc/3805/stack
> > [] sleep_on_page+0x9/0xd
> > [] wait_on_page_bit+0x71/0x78
> > [] filemap_fdatawait_range+0xa2/0x16d
> > [] filemap_write_and_wait_range+0x3b/0x77
> > [] nfs_file_fsync+0x37/0x83 [nfs]
> > [] vfs_fsync_range+0x19/0x1b
> > [] vfs_fsync+0x17/0x19
> > [] nfs_file_flush+0x6b/0x6f [nfs]
> > [] filp_close+0x3f/0x71
> > [] __close_fd+0x80/0x98
> > [] SyS_close+0x1c/0x3e
> > [] system_call_fastpath+0x16/0x1b
> > [] 0x
> > 
> > Thanks,
> > Ben
> > 
> > > If it doesn't please report the kernel version and cat /proc/$PID/stack
> > > 
> > > for some processes that cannot be killed.
> > > 
> > > NeilBrown
> > > 
> > >> 
> > >> 
> > >> Aside from bringing a fake NFS server back up on the same IP, is there 
> > >> any other way to get these mounts unmounted and the processes killed 
> > >> without 
> > >> rebooting?
> > >> 
> > >> Thanks, Ben
> > >> 
> > > 
> > 
> > 
> > - -- 
> > Ben Greear 
> > Candela Technologies Inc  http://www.candelatech.com
> > 
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1.4.13 (GNU/Linux)
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> > 
> > iQEcBAEBAgAGBQJT2rLiAAoJELbHqkYeJT4OqPgH/0taKW6Be90c1mETZf9yeqZF
> > 

[PATCH] [sched] Rename a misleading variable in build_overlap_sched_groups()

[Zhihui Zhang]

The child variable in build_overlap_sched_groups() actually refers to the
peer or sibling domain of the given CPU. Rename it to sibling to be consistent
with the naming in build_group_mask().

Signed-off-by: Zhihui Zhang 
---
 kernel/sched/core.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index bc1638b..8ba66006 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5720,7 +5720,7 @@ build_overlap_sched_groups(struct sched_domain *sd, int 
cpu)
const struct cpumask *span = sched_domain_span(sd);
struct cpumask *covered = sched_domains_tmpmask;
struct sd_data *sdd = sd->private;
-   struct sched_domain *child;
+   struct sched_domain *sibling;
int i;
 
cpumask_clear(covered);
@@ -5731,10 +5731,10 @@ build_overlap_sched_groups(struct sched_domain *sd, int 
cpu)
if (cpumask_test_cpu(i, covered))
continue;
 
-   child = *per_cpu_ptr(sdd->sd, i);
+   sibling = *per_cpu_ptr(sdd->sd, i);
 
/* See the comment near build_group_mask(). */
-   if (!cpumask_test_cpu(i, sched_domain_span(child)))
+   if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
continue;
 
sg = kzalloc_node(sizeof(struct sched_group) + cpumask_size(),
@@ -5744,10 +5744,9 @@ build_overlap_sched_groups(struct sched_domain *sd, int 
cpu)
goto fail;
 
sg_span = sched_group_cpus(sg);
-   if (child->child) {
-   child = child->child;
-   cpumask_copy(sg_span, sched_domain_span(child));
-   } else
+   if (sibling->child)
+   cpumask_copy(sg_span, 
sched_domain_span(sibling->child));
+   else
cpumask_set_cpu(i, sg_span);
 
cpumask_or(covered, covered, sg_span);
-- 
1.8.1.2

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

[PATCH v4 1/2] mm/highmem: make kmap cache coloring aware

[Max Filippov]

User-visible effect:
Architectures that choose this method of maintaining cache coherency
(MIPS and xtensa currently) are able to use high memory on cores with
aliasing data cache. Without this fix such architectures can not use
high memory (in case of xtensa it means that at most 128 MBytes of
physical memory is available).

The problem:
VIPT cache with way size larger than MMU page size may suffer from
aliasing problem: a single physical address accessed via different
virtual addresses may end up in multiple locations in the cache.
Virtual mappings of a physical address that always get cached in
different cache locations are said to have different colors.
L1 caching hardware usually doesn't handle this situation leaving it
up to software. Software must avoid this situation as it leads to
data corruption.

What can be done:
One way to handle this is to flush and invalidate data cache every time
page mapping changes color. The other way is to always map physical page
at a virtual address with the same color. Low memory pages already have
this property. Giving architecture a way to control color of high memory
page mapping allows reusing of existing low memory cache alias handling
code.

How this is done with this patch:
Provide hooks that allow architectures with aliasing cache to align
mapping address of high pages according to their color. Such architectures
may enforce similar coloring of low- and high-memory page mappings and
reuse existing cache management functions to support highmem.

This code is based on the implementation of similar feature for MIPS by
Leonid Yegoshin .

Signed-off-by: Max Filippov 
---
Changes v3->v4:
- drop #include  from mm/highmem.c as it's done in
  linux/highmem.h;
- add 'User-visible effect' section to changelog.

Changes v2->v3:
- drop ARCH_PKMAP_COLORING, check gif et_pkmap_color is defined instead;
- add comment stating that arch should place definitions into
  asm/highmem.h, include it directly to mm/highmem.c;
- replace macros with inline functions, change set_pkmap_color to
  get_pkmap_color which better fits inline function model;
- drop get_last_pkmap_nr;
- replace get_next_pkmap_counter with get_pkmap_entries_count, leave
  original counting code;
- introduce get_pkmap_wait_queue_head and make sleeping/waking dependent
  on mapping color;
- move file-scope static variables last_pkmap_nr and pkmap_map_wait into
  get_next_pkmap_nr and get_pkmap_wait_queue_head respectively;
- document new functions;
- expand patch description and change authorship.

Changes v1->v2:
- define set_pkmap_color(pg, cl) as do { } while (0) instead of /* */;
- rename is_no_more_pkmaps to no_more_pkmaps;
- change 'if (count > 0)' to 'if (count)' to better match the original
  code behavior;

 mm/highmem.c | 86 
 1 file changed, 75 insertions(+), 11 deletions(-)

diff --git a/mm/highmem.c b/mm/highmem.c
index b32b70c..123bcd3 100644
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -44,6 +44,66 @@ DEFINE_PER_CPU(int, __kmap_atomic_idx);
  */
 #ifdef CONFIG_HIGHMEM
 
+/*
+ * Architecture with aliasing data cache may define the following family of
+ * helper functions in its asm/highmem.h to control cache color of virtual
+ * addresses where physical memory pages are mapped by kmap.
+ */
+#ifndef get_pkmap_color
+
+/*
+ * Determine color of virtual address where the page should be mapped.
+ */
+static inline unsigned int get_pkmap_color(struct page *page)
+{
+   return 0;
+}
+#define get_pkmap_color get_pkmap_color
+
+/*
+ * Get next index for mapping inside PKMAP region for page with given color.
+ */
+static inline unsigned int get_next_pkmap_nr(unsigned int color)
+{
+   static unsigned int last_pkmap_nr;
+
+   last_pkmap_nr = (last_pkmap_nr + 1) & LAST_PKMAP_MASK;
+   return last_pkmap_nr;
+}
+
+/*
+ * Determine if page index inside PKMAP region (pkmap_nr) of given color
+ * has wrapped around PKMAP region end. When this happens an attempt to
+ * flush all unused PKMAP slots is made.
+ */
+static inline int no_more_pkmaps(unsigned int pkmap_nr, unsigned int color)
+{
+   return pkmap_nr == 0;
+}
+
+/*
+ * Get the number of PKMAP entries of the given color. If no free slot is
+ * found after checking that many entries, kmap will sleep waiting for
+ * someone to call kunmap and free PKMAP slot.
+ */
+static inline int get_pkmap_entries_count(unsigned int color)
+{
+   return LAST_PKMAP;
+}
+
+/*
+ * Get head of a wait queue for PKMAP entries of the given color.
+ * Wait queues for different mapping colors should be independent to avoid
+ * unnecessary wakeups caused by freeing of slots of other colors.
+ */
+static inline wait_queue_head_t *get_pkmap_wait_queue_head(unsigned int color)
+{
+   static DECLARE_WAIT_QUEUE_HEAD(pkmap_map_wait);
+
+   return _map_wait;
+}
+#endif
+
 unsigned long totalhigh_pages __read_mostly;
 EXPORT_SYMBOL(totalhigh_pages);
 
@@ -68,13 +128,10 @@ unsigned int nr_free_highpages 

[PATCH v4 2/2] xtensa: support aliasing cache in kmap

[Max Filippov]

Define ARCH_PKMAP_COLORING and provide corresponding macro definitions
on cores with aliasing data cache.

Instead of single last_pkmap_nr maintain an array last_pkmap_nr_arr of
pkmap counters for each page color. Make sure that kmap maps physical
page at virtual address with color matching its physical address.

Signed-off-by: Max Filippov 
---
This patch is only a demonstration of new interface usage, it depends
on other patches from the xtensa tree. Please don't commit it.

Changes v3->v4:
- none.

Changes v2->v3:
- switch to new function names/prototypes;
- implement get_pkmap_wait_queue_head, add kmap_waitqueues_init.

Changes v1->v2:
- new file.

 arch/xtensa/include/asm/highmem.h | 40 +--
 arch/xtensa/mm/highmem.c  | 18 ++
 2 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/arch/xtensa/include/asm/highmem.h 
b/arch/xtensa/include/asm/highmem.h
index 2653ef5..2c7901e 100644
--- a/arch/xtensa/include/asm/highmem.h
+++ b/arch/xtensa/include/asm/highmem.h
@@ -12,19 +12,55 @@
 #ifndef _XTENSA_HIGHMEM_H
 #define _XTENSA_HIGHMEM_H
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-#define PKMAP_BASE (FIXADDR_START - PMD_SIZE)
-#define LAST_PKMAP PTRS_PER_PTE
+#define PKMAP_BASE ((FIXADDR_START - \
+ (LAST_PKMAP + 1) * PAGE_SIZE) & PMD_MASK)
+#define LAST_PKMAP (PTRS_PER_PTE * DCACHE_N_COLORS)
 #define LAST_PKMAP_MASK(LAST_PKMAP - 1)
 #define PKMAP_NR(virt) (((virt) - PKMAP_BASE) >> PAGE_SHIFT)
 #define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
 
 #define kmap_prot  PAGE_KERNEL
 
+#if DCACHE_WAY_SIZE > PAGE_SIZE
+#define get_pkmap_color get_pkmap_color
+static inline int get_pkmap_color(struct page *page)
+{
+   return DCACHE_ALIAS(page_to_phys(page));
+}
+
+extern unsigned int last_pkmap_nr_arr[];
+
+static inline unsigned int get_next_pkmap_nr(unsigned int color)
+{
+   last_pkmap_nr_arr[color] =
+   (last_pkmap_nr_arr[color] + DCACHE_N_COLORS) & LAST_PKMAP_MASK;
+   return last_pkmap_nr_arr[color] + color;
+}
+
+static inline int no_more_pkmaps(unsigned int pkmap_nr, unsigned int color)
+{
+   return pkmap_nr < DCACHE_N_COLORS;
+}
+
+static inline int get_pkmap_entries_count(unsigned int color)
+{
+   return LAST_PKMAP / DCACHE_N_COLORS;
+}
+
+extern wait_queue_head_t pkmap_map_wait_arr[];
+
+static inline wait_queue_head_t *get_pkmap_wait_queue_head(unsigned int color)
+{
+   return pkmap_map_wait_arr + color;
+}
+#endif
+
 extern pte_t *pkmap_page_table;
 
 void *kmap_high(struct page *page);
diff --git a/arch/xtensa/mm/highmem.c b/arch/xtensa/mm/highmem.c
index 466abae..8cfb71e 100644
--- a/arch/xtensa/mm/highmem.c
+++ b/arch/xtensa/mm/highmem.c
@@ -14,6 +14,23 @@
 
 static pte_t *kmap_pte;
 
+#if DCACHE_WAY_SIZE > PAGE_SIZE
+unsigned int last_pkmap_nr_arr[DCACHE_N_COLORS];
+wait_queue_head_t pkmap_map_wait_arr[DCACHE_N_COLORS];
+
+static void __init kmap_waitqueues_init(void)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(pkmap_map_wait_arr); ++i)
+   init_waitqueue_head(pkmap_map_wait_arr + i);
+}
+#else
+static inline void kmap_waitqueues_init(void)
+{
+}
+#endif
+
 static inline enum fixed_addresses kmap_idx(int type, unsigned long color)
 {
return (type + KM_TYPE_NR * smp_processor_id()) * DCACHE_N_COLORS +
@@ -72,4 +89,5 @@ void __init kmap_init(void)
/* cache the first kmap pte */
kmap_vstart = __fix_to_virt(FIX_KMAP_BEGIN);
kmap_pte = kmap_get_fixmap_pte(kmap_vstart);
+   kmap_waitqueues_init();
 }
-- 
1.8.1.4

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

Re: [PATCH 1/3] irq / PM: New driver interface for wakeup interruptsn

[Rafael J. Wysocki]

On Friday, August 01, 2014 04:29:40 PM Rafael J. Wysocki wrote:
> On Friday, August 01, 2014 03:43:21 PM Thomas Gleixner wrote:
> > On Fri, 1 Aug 2014, Rafael J. Wysocki wrote:
> > > OK, I guess "IRQ_HANDLED from a wakeup interrupt" may be interpreted as
> > > IRQ_HANDLED_PMWAKE.  On the other hand, if that's going to be handled in
> > > handle_irq_event_percpu(), then using a special return code would save us
> > > a brach for IRQ_HANDLED interrupts.  We could convert it to IRQ_HANDLED
> > > immediately then.
> > 
> > We can handle it at the end of the function by calling
> > note_interrupt() unconditionally do the following there:
> > 
> >   if (suspended) {
> >  if (ret == IRQ_NONE) {
> > if (shared)
> >yell_and_abort_or_resume();
> >  } else {
> > abort_or_resume();
> >  }
> >   }
> >   if (noirqdebug)
> >  return;
> 
> I see.
> 
> > > OK, I'll take a stab at the IRQF_SHARED thing if you don't mind.
> > 
> > Definitely not :)
> > 
> > > Here's my current understanding of what can be done for IRQF_NO_SUSPEND.
> > > 
> > > In suspend_device_irqs():
> > > 
> > > (1) If all actions in the list have the same setting (eg. IRQF_NO_SUSPEND 
> > > unset),
> > > keep the current behavior.
> > > (2) If the actions have different settings:
> > > - Actions with IRQF_NO_SUSPEND set are not modified.
> > > - Actions with IRQF_NO_SUSPEND unset are switched over to a stub 
> > > handler.
> > > - IRQS_SUSPEND_MODE (new flag) is set for the IRQ.
> > 
> > Can we please do that in setup_irq() and let the shared ones always
> > run through the stub? That keeps suspend/resume_device_irqs() simple.
> 
> OK

I've tried to do that, but encountered a problem.  The stub handler is called
with irq, dev_id as arguments and for the "interrupts are not suspended" case
(common) it has to use irq to find the irq_desc and then it has to use dev_id
to find the irqaction to call the original handler from there.  That seemed to
be a bit too much of a penalty to me.  Especially for people who never suspend
their machines. :-)

For this reason, I went for changing handlers in suspend_device_irqs() and
back in resume_device_irqs().  That's not terribly complicated (the restoration
in particular is pretty simple) and it should be easily reusable for the wakeup
interrupts case.  resume_device_irqs() wouldn't need any more changes for that,
for example.  It minimally affects systems that don't suspend too.

I also ended up adding a new interrupt handler return code (IRQ_SUSPENDED).
I could add a new irq_desc flag instead, but then the new code in 
suspend_device_irqs()
and the new check in note_interrupt() would need to be slightly more 
complicated.

Below is my current prototype.  Please have a look and let me know what you
think.

I gave it a little bit of testing with success.

Of course, I'd prefer to move the IRQ suspend/resume code to pm.c and get rid
of the third argument in __disable_irq() and __enable_irq() before making these
changes for real.

Rafael


---
 drivers/base/power/main.c   |1 +
 drivers/base/power/wakeup.c |   20 
 include/linux/interrupt.h   |2 ++
 include/linux/irqreturn.h   |2 ++
 include/linux/suspend.h |3 +++
 kernel/irq/handle.c |3 +--
 kernel/irq/manage.c |   35 ++-
 kernel/irq/pm.c |7 +--
 kernel/irq/spurious.c   |   16 
 9 files changed, 84 insertions(+), 5 deletions(-)

Index: linux-pm/kernel/irq/manage.c
===
--- linux-pm.orig/kernel/irq/manage.c
+++ linux-pm/kernel/irq/manage.c
@@ -382,11 +382,36 @@ setup_affinity(unsigned int irq, struct
 }
 #endif
 
+/*
+ * Dummy handler for shared interrupts to use during system suspend.
+ */
+static irqreturn_t irq_pm_dummy_handler(int irq, void *dev_id)
+{
+   return IRQ_SUSPENDED;
+}
+
 void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
 {
if (suspend) {
-   if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
+   struct irqaction *action;
+
+   if (!desc->action)
return;
+
+   for (action = desc->action; action; action = action->next) {
+   if (action->flags & IRQF_NO_SUSPEND)
+   break;
+   }
+   if (action) {
+   for (action = desc->action; action; action = 
action->next) {
+   if (!(action->flags & IRQF_NO_SUSPEND)) {
+   action->saved_handler = action->handler;
+   action->handler = irq_pm_dummy_handler;
+   }
+   }
+   return;
+   }
+
desc->istate |= IRQS_SUSPENDED;
}
 
@@ 

[PATCH v4 0/2] mm/highmem: make kmap cache coloring aware

[Max Filippov]

Hi,

this series adds mapping color control to the generic kmap code, allowing
architectures with aliasing VIPT cache to use high memory. There's also
use example of this new interface by xtensa.

Changes since v3:
- drop #include  from mm/highmem.c as it's done in
  linux/highmem.h;
- add 'User-visible effect' section to changelog.

Max Filippov (2):
  mm/highmem: make kmap cache coloring aware
  xtensa: support aliasing cache in kmap

 arch/xtensa/include/asm/highmem.h | 40 +-
 arch/xtensa/mm/highmem.c  | 18 
 mm/highmem.c  | 86 ++-
 3 files changed, 131 insertions(+), 13 deletions(-)

-- 
1.8.1.4

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

Re: [PATCH v2 5/7] chipidea: usbmisc_imx: Add USB support for VF610 SoCs

[Peter Chen]

On Mon, Jul 28, 2014 at 04:57:31PM +0200, Stefan Agner wrote:
> This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6,
> however, the non-core registers are spread in two different register
> areas. Hence we support multiple instances of the USB misc driver
> and add the driver instance to the imx_usbmisc_data structure.
> 
> Signed-off-by: Stefan Agner 
> ---
> In the end, I decieded against the advice of Peter to integrate the
> multi-instance functionality in a second driver. To support multiple
> instances, I needed to extend the imx_usbmisc_data to point to the
> instance. Since this is part of the ci_hdrc_imx driver, I feel it's
> cleaner to extend the current driver rather to add a second driver
> and implement two different handlings in the ci_hdrc_imx driver.
> 
> Also, the current approach has a slight advantage for current users
> too: EPROBE_DEFER is returned earlier, when initializing the
> imx_usbmisc_data structure rather than later on, when accessing
> the driver by using imx_usbmisc_init/imx_usbmisc_init_post.
> 
> As a free bonus, this driver would now also support the mixed case:
> multiple non-core registers in different areas which each support
> multiple USB controllers...
> 
> Tell me if this is ok for you too.
> 
>  .../devicetree/bindings/usb/usbmisc-imx.txt|  1 +
>  drivers/usb/chipidea/ci_hdrc_imx.c |  8 
>  drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
>  drivers/usb/chipidea/usbmisc_imx.c | 52 
> +-
>  4 files changed, 51 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
> b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> index 97ce94e..c101a4b 100644
> --- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> +++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
> @@ -4,6 +4,7 @@ Required properties:
>  - #index-cells: Cells used to descibe usb controller index. Should be <1>
>  - compatible: Should be one of below:
>   "fsl,imx6q-usbmisc" for imx6q
> + "fsl,vf610-usbmisc" for Vybrid vf610
>  - reg: Should contain registers location and length
>  
>  Examples:
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 2e58f8d..9af12b4 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -54,6 +54,7 @@ struct ci_hdrc_imx_data {
>  
>  static struct imx_usbmisc_data *usbmisc_get_init_data(struct device *dev)
>  {
> + struct platform_device *misc_pdev;
>   struct device_node *np = dev->of_node;
>   struct of_phandle_args args;
>   struct imx_usbmisc_data *data;
> @@ -79,8 +80,15 @@ static struct imx_usbmisc_data 
> *usbmisc_get_init_data(struct device *dev)
>   }
>  
>   data->index = args.args[0];
> +
> + misc_pdev = of_find_device_by_node(args.np);
>   of_node_put(args.np);
>  
> + if (!misc_pdev)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + data->dev = _pdev->dev;
> +
>   if (of_find_property(np, "disable-over-current", NULL))
>   data->disable_oc = 1;
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.h 
> b/drivers/usb/chipidea/ci_hdrc_imx.h
> index 996ec93..4ed828f 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.h
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.h
> @@ -13,6 +13,7 @@
>  #define __DRIVER_USB_CHIPIDEA_CI_HDRC_IMX_H
>  
>  struct imx_usbmisc_data {
> + struct device *dev;
>   int index;
>  
>   unsigned int disable_oc:1; /* over current detect disabled */
> diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
> b/drivers/usb/chipidea/usbmisc_imx.c
> index 85293b8..926c997 100644
> --- a/drivers/usb/chipidea/usbmisc_imx.c
> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> @@ -57,6 +57,8 @@
>  
>  #define MX6_BM_OVER_CUR_DIS  BIT(7)
>  
> +#define VF610_OVER_CUR_DIS   BIT(7)
> +
>  struct usbmisc_ops {
>   /* It's called once when probe a usb device */
>   int (*init)(struct imx_usbmisc_data *data);
> @@ -71,10 +73,9 @@ struct imx_usbmisc {
>   const struct usbmisc_ops *ops;
>  };
>  
> -static struct imx_usbmisc *usbmisc;
> -
>  static int usbmisc_imx25_init(struct imx_usbmisc_data *data)
>  {
> + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
>   unsigned long flags;
>   u32 val = 0;
>  
> @@ -108,6 +109,7 @@ static int usbmisc_imx25_init(struct imx_usbmisc_data 
> *data)
>  
>  static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
>  {
> + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
>   void __iomem *reg;
>   unsigned long flags;
>   u32 val;
> @@ -130,6 +132,7 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data 
> *data)
>  
>  static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
>  {
> + struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
>   unsigned long flags;
>   u32 val;
>  
> @@ -160,6 +163,7 @@ static int 

[PATCH v6 04/10] ARM: dts: Clean up exynos5250-snow

[Andreas Färber]

Use the new style of referencing inherited nodes and use symbolic names.
Reorder one pinctrl node in GPIO order.

Goal is the alignment of all exynos5250 based device trees for comparison.

Suggested-by: Doug Anderson 
Reviewed-by: Doug Anderson 
Signed-off-by: Andreas Färber 
---
 v5 -> v6:
 * Split off label additions (Doug Anderson)
 * Fixed alphabetical order of sd3_* nodes (Doug Anderson)
 
 v4 -> v5:
 * Introduced labels to consistently use new referencing style (Tomasz Figa)
 * Use IRQ_TYPE_* constants
 * Use some more GPIO_ACTIVE_*

 v3 -> v4: Unchanged
 
 v3: New (Doug Anderson)

 arch/arm/boot/dts/exynos5250-snow.dts | 291 +-
 1 file changed, 145 insertions(+), 146 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1c36cd72905f..40cad43f8a11 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -6,9 +6,12 @@
  * 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.
-*/
+ */
 
 /dts-v1/;
+#include 
+#include 
+#include 
 #include "exynos5250.dtsi"
 
 / {
@@ -26,89 +29,19 @@
chosen {
};
 
-   rtc@101E {
-   status = "okay";
-   };
-
-   pinctrl@1140 {
-   ec_irq: ec-irq {
-   samsung,pins = "gpx1-6";
-   samsung,pin-function = <0>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
-   };
-
-   sd3_clk: sd3-clk {
-   samsung,pin-drv = <0>;
-   };
-
-   sd3_cmd: sd3-cmd {
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
-   };
-
-   sd3_bus4: sd3-bus-width4 {
-   samsung,pin-drv = <0>;
-   };
-
-   max98095_en: max98095-en {
-   samsung,pins = "gpx1-7";
-   samsung,pin-function = <0>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
-   };
-
-   tps65090_irq: tps65090-irq {
-   samsung,pins = "gpx2-6";
-   samsung,pin-function = <0>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
-   };
-
-   usb3_vbus_en: usb3-vbus-en {
-   samsung,pins = "gpx2-7";
-   samsung,pin-function = <1>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
-   };
-
-   hdmi_hpd_irq: hdmi-hpd-irq {
-   samsung,pins = "gpx3-7";
-   samsung,pin-function = <0>;
-   samsung,pin-pud = <1>;
-   samsung,pin-drv = <0>;
-   };
-   };
-
-   pinctrl@1340 {
-   arb_their_claim: arb-their-claim {
-   samsung,pins = "gpe0-4";
-   samsung,pin-function = <0>;
-   samsung,pin-pud = <3>;
-   samsung,pin-drv = <0>;
-   };
-
-   arb_our_claim: arb-our-claim {
-   samsung,pins = "gpf0-3";
-   samsung,pin-function = <1>;
-   samsung,pin-pud = <0>;
-   samsung,pin-drv = <0>;
-   };
-   };
-
gpio-keys {
compatible = "gpio-keys";
 
power {
label = "Power";
-   gpios = < 3 1>;
-   linux,code = <116>; /* KEY_POWER */
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   linux,code = ;
gpio-key,wakeup;
};
 
lid-switch {
label = "Lid";
-   gpios = < 5 1>;
+   gpios = < 5 GPIO_ACTIVE_LOW>;
linux,input-type = <5>; /* EV_SW */
linux,code = <0>; /* SW_LID */
debounce-interval = <1>;
@@ -129,8 +62,8 @@
 
i2c-parent = <&{/i2c@12CA}>;
 
-   our-claim-gpio = < 3 1>;
-   their-claim-gpios = < 4 1>;
+   our-claim-gpio = < 3 GPIO_ACTIVE_LOW>;
+   their-claim-gpios = < 4 GPIO_ACTIVE_LOW>;
slew-delay-us = <10>;
wait-retry-us = <3000>;
wait-free-us = <5>;
@@ -153,7 +86,7 @@
cros_ec: embedded-controller {
compatible = "google,cros-ec-i2c";
reg = <0x1e>;
-   interrupts = <6 0>;
+   

[PATCH v6 03/10] ARM: dts: Prepare node labels for exynos5250

[Andreas Färber]

Allows them to be extended by reference.

Signed-off-by: Andreas Färber 
---
 v6: Split off from Snow/SMDK cleanups (Doug Anderson)

 arch/arm/boot/dts/exynos5250.dtsi | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a5306f..cf94aeaeaa84 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -215,7 +215,7 @@
clock-names = "fimg2d";
};
 
-   codec@1100 {
+   mfc: codec@1100 {
compatible = "samsung,mfc-v6";
reg = <0x1100 0x1>;
interrupts = <0 96 0>;
@@ -224,7 +224,7 @@
clock-names = "mfc";
};
 
-   rtc@101E {
+   rtc: rtc@101E {
clocks = < CLK_RTC>;
clock-names = "rtc";
status = "disabled";
@@ -238,27 +238,27 @@
clock-names = "tmu_apbif";
};
 
-   serial@12C0 {
+   uart0: serial@12C0 {
clocks = < CLK_UART0>, < CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};
 
-   serial@12C1 {
+   uart1: serial@12C1 {
clocks = < CLK_UART1>, < CLK_SCLK_UART1>;
clock-names = "uart", "clk_uart_baud0";
};
 
-   serial@12C2 {
+   uart2: serial@12C2 {
clocks = < CLK_UART2>, < CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
 
-   serial@12C3 {
+   uart3: serial@12C3 {
clocks = < CLK_UART3>, < CLK_SCLK_UART3>;
clock-names = "uart", "clk_uart_baud0";
};
 
-   sata@122F {
+   sata: sata@122F {
compatible = "snps,dwc-ahci";
samsung,sata-freq = <66>;
reg = <0x122F 0x1ff>;
@@ -570,7 +570,7 @@
#phy-cells = <1>;
};
 
-   usb@1211 {
+   ehci: usb@1211 {
compatible = "samsung,exynos4210-ehci";
reg = <0x1211 0x100>;
interrupts = <0 71 0>;
@@ -585,7 +585,7 @@
};
};
 
-   usb@1212 {
+   ohci: usb@1212 {
compatible = "samsung,exynos4210-ohci";
reg = <0x1212 0x100>;
interrupts = <0 71 0>;
@@ -722,7 +722,7 @@
clock-names = "gscl";
};
 
-   hdmi {
+   hdmi: hdmi {
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x7>;
interrupts = <0 95 0>;
@@ -748,14 +748,14 @@
#phy-cells = <0>;
};
 
-   dp-controller@145B {
+   dp: dp-controller@145B {
clocks = < CLK_DP>;
clock-names = "dp";
phys = <_phy>;
phy-names = "dp";
};
 
-   fimd@1440 {
+   fimd: fimd@1440 {
clocks = < CLK_SCLK_FIMD1>, < CLK_FIMD1>;
clock-names = "sclk_fimd", "fimd";
};
-- 
1.9.3

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

[PATCH v6 05/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Andreas Färber]

exynos5250-cros-common.dtsi had an empty /chosen node.
Fill in exemplary boot arguments.

Reviewed-by: Tomasz Figa 
Signed-off-by: Andreas Färber 
---
 v5 -> v6: Unchanged

 v5: New
 Cleanup for /chosen node moved into -snow.dts.

 arch/arm/boot/dts/exynos5250-snow.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 40cad43f8a11..8d8e62de86c7 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -27,6 +27,7 @@
};
 
chosen {
+   bootargs = "console=tty1";
};
 
gpio-keys {
-- 
1.9.3

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

[PATCH v6 02/10] ARM: dts: Fold exynos5250-cros-common into exynos5250-snow

[Andreas Färber]

exynos5250-cros-common.dtsi was meant for sharing common pieces across
ChromeOS devices. This turned out premature, as several devices ended up
in the common file that are not common after all. Since the remaining
common ChromeOS pieces are fairly minor,  exynos5250-cros-common.dtsi
was requested to be merged into the Snow device tree, sharing only the
keyboard controller for now. This may be re-evaluated as both mature.

Suggested-by: Doug Anderson 
Reviewed-by: Tomasz Figa 
Reviewed-by: Doug Anderson 
Signed-off-by: Andreas Färber 
---
 v5 -> v6: Unchanged

 v4 -> v5:
 * Extended commit message (Tomasz Figa)

 v3 -> v4: Unchanged
 
 v2 -> v3:
 * Renamed subject to match Kukjin's style
 * Rebased onto MMC pinctrl bug fix (Doug Anderson)
 
 v2: New (Doug Anderson)

 arch/arm/boot/dts/exynos5250-cros-common.dtsi | 164 --
 arch/arm/boot/dts/exynos5250-snow.dts | 164 +++---
 2 files changed, 145 insertions(+), 183 deletions(-)
 delete mode 100644 arch/arm/boot/dts/exynos5250-cros-common.dtsi

diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
deleted file mode 100644
index e603e9c70142..
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ /dev/null
@@ -1,164 +0,0 @@
-/*
- * Common device tree include for all Exynos 5250 boards based off of Daisy.
- *
- * Copyright (c) 2012 Google, Inc
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-/ {
-   aliases {
-   };
-
-   memory {
-   reg = <0x4000 0x8000>;
-   };
-
-   chosen {
-   };
-
-   pinctrl@1140 {
-   /*
-* Disabled pullups since external part has its own pullups and
-* double-pulling gets us out of spec in some cases.
-*/
-   i2c2_bus: i2c2-bus {
-   samsung,pin-pud = <0>;
-   };
-   };
-
-   i2c@12C6 {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <378000>;
-   };
-
-   i2c@12C7 {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <378000>;
-   };
-
-   i2c@12C8 {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <66000>;
-
-   hdmiddc@50 {
-   compatible = "samsung,exynos4210-hdmiddc";
-   reg = <0x50>;
-   };
-   };
-
-   i2c@12C9 {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <66000>;
-   };
-
-   i2c@12CA {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <66000>;
-   };
-
-   i2c@12CB {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <66000>;
-   };
-
-   i2c@12CD {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <66000>;
-   };
-
-   i2c@12CE {
-   status = "okay";
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <378000>;
-
-   hdmiphy: hdmiphy@38 {
-   compatible = "samsung,exynos4212-hdmiphy";
-   reg = <0x38>;
-   };
-   };
-
-   mmc@1220 {
-   num-slots = <1>;
-   supports-highspeed;
-   broken-cd;
-   card-detect-delay = <200>;
-   samsung,dw-mshc-ciu-div = <3>;
-   samsung,dw-mshc-sdr-timing = <2 3>;
-   samsung,dw-mshc-ddr-timing = <1 2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _cd _bus4 _bus8>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <8>;
-   };
-   };
-
-   mmc@1222 {
-   num-slots = <1>;
-   supports-highspeed;
-   card-detect-delay = <200>;
-   samsung,dw-mshc-ciu-div = <3>;
-   samsung,dw-mshc-sdr-timing = <2 3>;
-   samsung,dw-mshc-ddr-timing = <1 2>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _cd _bus4>;
-
-   slot@0 {
-   reg = <0>;
-   bus-width = <4>;
-   wp-gpios = < 1 0>;
-   };
-   };
-
-   mmc@1223 {
-   num-slots = <1>;
-   supports-highspeed;
-   broken-cd;
- 

[PATCH v6 07/10] ARM: dts: Clean up exynos5250-arndale

[Andreas Färber]

Use the new style of referencing inherited nodes, use symbolic names,
tidy indentation and reorder includes.

Goal is the alignment of all exynos5250 based device trees for comparison.

Signed-off-by: Andreas Färber 
---
 v5 -> v6:
 * Updated for mfc node label
 
 v5: New
 Aligns with SMDK.

 arch/arm/boot/dts/exynos5250-arndale.dts | 929 ---
 1 file changed, 466 insertions(+), 463 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index d0de1f50d15b..aac41c394d43 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -7,12 +7,13 @@
  * 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.
-*/
+ */
 
 /dts-v1/;
-#include "exynos5250.dtsi"
+#include 
 #include 
 #include 
+#include "exynos5250.dtsi"
 
 / {
model = "Insignal Arndale evaluation board based on EXYNOS5250";
@@ -26,473 +27,52 @@
bootargs = "console=ttySAC2,115200";
};
 
-   rtc@101E {
-   status = "okay";
-   };
-
-   codec@1100 {
-   samsung,mfc-r = <0x4300 0x80>;
-   samsung,mfc-l = <0x5100 0x80>;
-   };
-
-   i2c@12C6 {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <2>;
-   samsung,i2c-slave-addr = <0x66>;
-   status = "okay";
-
-   s5m8767_pmic@66 {
-   compatible = "samsung,s5m8767-pmic";
-   reg = <0x66>;
-   interrupt-parent = <>;
-   interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
-
-   vinb1-supply = <_dc_reg>;
-   vinb2-supply = <_dc_reg>;
-   vinb3-supply = <_dc_reg>;
-   vinb4-supply = <_dc_reg>;
-   vinb5-supply = <_dc_reg>;
-   vinb6-supply = <_dc_reg>;
-   vinb7-supply = <_dc_reg>;
-   vinb8-supply = <_dc_reg>;
-   vinb9-supply = <_dc_reg>;
-
-   vinl1-supply = <_reg>;
-   vinl2-supply = <_reg>;
-   vinl3-supply = <_reg>;
-   vinl4-supply = <_dc_reg>;
-   vinl5-supply = <_dc_reg>;
-   vinl6-supply = <_dc_reg>;
-   vinl7-supply = <_dc_reg>;
-   vinl8-supply = <_reg>;
-   vinl9-supply = <_reg>;
-
-   s5m8767,pmic-buck2-dvs-voltage = <130>;
-   s5m8767,pmic-buck3-dvs-voltage = <110>;
-   s5m8767,pmic-buck4-dvs-voltage = <120>;
-   s5m8767,pmic-buck-dvs-gpios = < 0 0>,
-   < 1 0>,
-   < 2 0>;
-   s5m8767,pmic-buck-ds-gpios = < 3 0>,
-   < 4 0>,
-   < 5 0>;
-   regulators {
-   ldo1_reg: LDO1 {
-   regulator-name = "VDD_ALIVE_1.0V";
-   regulator-min-microvolt = <110>;
-   regulator-max-microvolt = <110>;
-   regulator-always-on;
-   regulator-boot-on;
-   op_mode = <1>;
-   };
-
-   ldo2_reg: LDO2 {
-   regulator-name = "VDD_28IO_DP_1.35V";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
-   regulator-always-on;
-   regulator-boot-on;
-   op_mode = <1>;
-   };
-
-   ldo3_reg: LDO3 {
-   regulator-name = "VDD_COMMON1_1.8V";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   regulator-always-on;
-   regulator-boot-on;
-   op_mode = <1>;
-   };
-
-   ldo4_reg: LDO4 {
-   regulator-name = "VDD_IOPERI_1.8V";
-   regulator-min-microvolt = <180>;
- 

[PATCH v6 08/10] ARM: dts: Fix apparent GPIO typo in exynos5250-arndale

[Andreas Färber]

The GPIO flag 2 has no constant assigned, so this was probably active-low.

Reviewed-by: Tomasz Figa 
Signed-off-by: Andreas Färber 
---
 v5 -> v6: Unchanged
 
 v5: New
 Spotted during cleanup.

 arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index aac41c394d43..cc8b9ffeecc1 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -159,7 +159,7 @@
 };
 
  {
-   hpd-gpio = < 7 2>;
+   hpd-gpio = < 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <_reg>;
vdd_pll-supply = <_reg>;
vdd-supply = <_reg>;
-- 
1.9.3

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

[PATCH v6 06/10] ARM: dts: Clean up exynos5250-smdk5250

[Andreas Färber]

Use the new style for referencing inherited nodes and use symbolic names.

Goal is the alignment of all exynos5250 based device trees for comparison.

Signed-off-by: Andreas Färber 
---
 v5 -> v6:
 * Renamed node label codec -> mfc for alignment with "add System MMU nodes"
 * Rebased for leaving dp_hpd in .dtsi
 
 v5: New
 Follow-up after adding dp_hpd pinctrl node new-style.

 arch/arm/boot/dts/exynos5250-smdk5250.dts | 632 +++---
 1 file changed, 318 insertions(+), 314 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index aaa055ac0fe3..6bcd64ff2ded 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -7,9 +7,11 @@
  * 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.
-*/
+ */
 
 /dts-v1/;
+#include 
+#include 
 #include "exynos5250.dtsi"
 
 / {
@@ -27,165 +29,6 @@
bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M 
console=ttySAC2,115200 init=/linuxrc";
};
 
-   rtc@101E {
-   status = "okay";
-   };
-
-   i2c@12C6 {
-   samsung,i2c-sda-delay = <100>;
-   samsung,i2c-max-bus-freq = <2>;
-   status = "okay";
-
-   eeprom@50 {
-   compatible = "samsung,s524ad0xd1";
-   reg = <0x50>;
-   };
-
-   max77686@09 {
-   compatible = "maxim,max77686";
-   reg = <0x09>;
-   interrupt-parent = <>;
-   interrupts = <2 0>;
-
-   voltage-regulators {
-   ldo1_reg: LDO1 {
-   regulator-name = "P1.0V_LDO_OUT1";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
-   regulator-always-on;
-   };
-
-   ldo2_reg: LDO2 {
-   regulator-name = "P1.2V_LDO_OUT2";
-   regulator-min-microvolt = <120>;
-   regulator-max-microvolt = <120>;
-   regulator-always-on;
-   };
-
-   ldo3_reg: LDO3 {
-   regulator-name = "P1.8V_LDO_OUT3";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   regulator-always-on;
-   };
-
-   ldo4_reg: LDO4 {
-   regulator-name = "P2.8V_LDO_OUT4";
-   regulator-min-microvolt = <280>;
-   regulator-max-microvolt = <280>;
-   };
-
-   ldo5_reg: LDO5 {
-   regulator-name = "P1.8V_LDO_OUT5";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   };
-
-   ldo6_reg: LDO6 {
-   regulator-name = "P1.1V_LDO_OUT6";
-   regulator-min-microvolt = <110>;
-   regulator-max-microvolt = <110>;
-   regulator-always-on;
-   };
-
-   ldo7_reg: LDO7 {
-   regulator-name = "P1.1V_LDO_OUT7";
-   regulator-min-microvolt = <110>;
-   regulator-max-microvolt = <110>;
-   regulator-always-on;
-   };
-
-   ldo8_reg: LDO8 {
-   regulator-name = "P1.0V_LDO_OUT8";
-   regulator-min-microvolt = <100>;
-   regulator-max-microvolt = <100>;
-   };
-
-   ldo10_reg: LDO10 {
-   regulator-name = "P1.8V_LDO_OUT10";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <180>;
-   };
-
-   

[PATCH v6 01/10] ARM: dts: Fix MMC pinctrl for exynos5250-snow

[Andreas Färber]

The pinctrl properties should be on the device directly and not on the
slot sub-node.

Reported-by: Doug Anderson 
Cc: Jaehoon Chung 
Reviewed-by: Tomasz Figa 
Reviewed-by: Doug Anderson 
Signed-off-by: Andreas Färber 
---
 v3 -> v4 -> v5 -> v6: Unchanged
 
 v3: New (Doug Anderson)
 Redundant with Jaehoon Chung's general slot@0 deprecation,
 in case that hits the tree earlier.

 arch/arm/boot/dts/exynos5250-snow.dts | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index f2b8c4116541..eb437f6afec1 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -240,10 +240,8 @@
 */
mmc@1223 {
status = "okay";
-   slot@0 {
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk _cmd _bus4>;
-   };
+   pinctrl-names = "default";
+   pinctrl-0 = <_clk _cmd _bus4>;
};
 
i2c@12CD {
-- 
1.9.3

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

[PATCH v6 09/10] ARM: dts: Simplify USB3503 on exynos5250-arndale

[Andreas Färber]

There's no need for a simple-bus, place the smsc,usb3503a directly into
the root node. That's what we're going to do on exynos5250-spring.

Reported-by: Tomasz Figa 
Reviewed-by: Tomasz Figa 
Signed-off-by: Andreas Färber 
---
 v5 -> v6: Unchanged
 
 v5: New
 Aligns with Spring's new USB3503 node.

 arch/arm/boot/dts/exynos5250-arndale.dts | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index cc8b9ffeecc1..b231bcff7403 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -108,18 +108,12 @@
};
};
 
-   usb_hub_bus {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <0>;
+   // SMSC USB3503 connected in hardware only mode as a PHY
+   usb_hub: usb-hub {
+   compatible = "smsc,usb3503a";
 
-   // SMSC USB3503 connected in hardware only mode as a PHY
-   usb_hub: usb_hub {
-   compatible = "smsc,usb3503a";
-
-   reset-gpios = < 5 GPIO_ACTIVE_LOW>;
-   connect-gpios = < 7 GPIO_ACTIVE_LOW>;
-   };
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+   connect-gpios = < 7 GPIO_ACTIVE_LOW>;
};
 };
 
-- 
1.9.3

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

[PATCH v6 10/10] ARM: dts: Add exynos5250-spring device tree

[Andreas Färber]

Adds initial support for the HP Chromebook 11.

Cc: Vincent Palatin 
Cc: Doug Anderson 
Cc: Stephan van Schaik 
Signed-off-by: Andreas Färber 
---
 v5 -> v6:
 * Updated for mfc node label
 * Reverted to dp-hpd-gpio node in pinctrl_0 (Doug Anderson)
 * Fixed alphabetical order of sd1_* nodes (Doug Anderson)
 
 v4 -> v5:
 * Dropped bogus USB3 regulator (Vincent Palatin, Tomasz Figa)
 * Fixed USB3503 reset GPIO (Tomasz Figa)
 * Introduced labels to use new referencing style consistently (Tomasz Figa)
 * Don't override dp_hpd, moved to pinctrl_0 instead (Tomasz Figa)
 * mmc_1: Added comment from Snow's mmc_3 (Tomasz Figa / Doug Anderson)
 * Override /codec samsung,mfc-{l,r} properties for alignment with Arndale
 * Use more GPIO_ACTIVE_* constants
 * Use IRQ_TYPE_* constants
 * Dropped s5m_ prefix for s5m8767 LDO regulator labels (max77686 is gone)
 * Labeled also all s5m8767 BUCK regulators
 
 v3 -> v4:
 * Fixed samsung,pin-function 1 -> 0 for dp-hpd-gpio
 * Replaced dp-hpd-gpio with existing dp_hpd, overriding it
 
 v2 -> v3:
 * Use GPIO_ACTIVE_{LOW,HIGH} (Doug Anderson)
 * Use symbolic KEY_POWER instead of comment
 * Moved hsic_reset to new USB3503 node's reset-gpios (Vincent Palatin)
 * Use dp_hpd_gpio for dp-controller (Doug Anderson, Ajay Kumar)
 * Override sd1_{clk,cmd,cd,bus4} pinctrl similar to Snow (Doug Anderson)
 * Added ec_irq pinctrl for cros_ec (Doug Anderson)
 * Reordered nodes to minimize diff against Snow (Doug Anderson)
 * Dropped obsolete mmc_2 override (Doug Anderson)
 * Added lid-switch node (Doug Anderson)
 * Added gpio-keys pinctrl (Doug Anderson)
 * Added bootargs to avoid empty /chosen node and to document console setting
 * Renamed s5m8767_pmic node to avoid underscore
 * Use new style for overriding inherited pinctrl nodes, too
 * Enable i2s0 node
 
 v1 -> v2:
 * Use label-based overriding/extension of nodes. (Doug Anderson)
 * Dropped tps65090 for now, until we know where to place it.
 * Dropped non-Spring nodes from -cros-common.dtsi rather than disabling them.
 * Enabled a missing MMC node for access to internal storage.
 * Dropped display-timings from dp-controller node. (Ajay Kumar)

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/exynos5250-spring.dts | 536 
 2 files changed, 537 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5250-spring.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 80a781f76e88..dec4c292f63d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -76,6 +76,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
+   exynos5250-spring.dtb \
exynos5260-xyref5260.dtb \
exynos5410-smdk5410.dtb \
exynos5420-arndale-octa.dtb \
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index ..f5566f84d885
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,536 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include 
+#include 
+#include 
+#include "exynos5250.dtsi"
+
+/ {
+   model = "Google Spring";
+   compatible = "google,spring", "samsung,exynos5250", "samsung,exynos5";
+
+   memory {
+   reg = <0x4000 0x8000>;
+   };
+
+   chosen {
+   bootargs = "console=tty1";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_key_irq>, <_irq>;
+
+   power {
+   label = "Power";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   linux,code = ;
+   gpio-key,wakeup;
+   };
+
+   lid-switch {
+   label = "Lid";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <5>; /* EV_SW */
+   linux,code = <0>; /* SW_LID */
+   debounce-interval = <1>;
+   gpio-key,wakeup;
+   };
+   };
+
+   usb-hub {
+   compatible = "smsc,usb3503a";
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti";
+   clock-frequency = <2400>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd_gpio>;
+   samsung,color-space = <0>;
+   samsung,dynamic-range = <0>;
+   

Re: [PATCH v2 2/2] xen/setup: Remap Xen Identity Mapped RAM

[Matthew Rushton]

On 08/01/14 08:56, Boris Ostrovsky wrote:

On 08/01/2014 11:52 AM, Matt Wilson wrote:

On Fri, Aug 01, 2014 at 03:52:28PM +0100, David Vrabel wrote:

On 31/07/14 18:43, David Vrabel wrote:

On 20/07/14 01:01, Matt Rushton wrote:
Instead of ballooning up and down dom0 memory this remaps the 
existing mfns
that were replaced by the identity map. The reason for this is 
that the
existing implementation ballooned memory up and and down which 
caused dom0
to have discontiguous pages. In some cases this resulted in the 
use of bounce
buffers which reduced network I/O performance significantly. This 
change will
honor the existing order of the pages with the exception of some 
boundary

conditions.

To do this we need to update both the Linux p2m table and the Xen 
m2p table.
Particular care must be taken when updating the p2m table since 
it's important
to limit table memory consumption and reuse the existing leaf 
pages which get
freed when an entire leaf page is set to the identity map. To 
implement this,
mapping updates are grouped into blocks with table entries getting 
cached

temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Applied to devel/for-linus-3.17

Unfortunately, this produces too many WARNINGs on some boxes or
with certain configurations.

Hi David,

Do you have more information about the systems or configurations that
showed a problem?




This appears to be happening on 32-bit dom0.

-boris


It's unclear to me why the m2p update would be failing in this case (on 
first attempt) which causes the subsequent errors. I'll try to repro on 
a 32-bit dom0.


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

Re: [PATCH v2 3/7] usb: phy: mxs: Add VF610 USB PHY support

[Peter Chen]

On Mon, Jul 28, 2014 at 04:57:29PM +0200, Stefan Agner wrote:
> This adds support for the USB PHY in Vybrid VF610. We assume that
> the disconnection without VBUS is also needed for Vybrid.
> 
> Tests showed, without MXS_PHY_NEED_IP_FIX, enumeration of devices
> behind a USB Hub fails with errors:
> 
> [  215.163507] usb usb1-port1: cannot reset (err = -32)
> [  215.170498] usb usb1-port1: cannot reset (err = -32)
> [  215.185120] usb usb1-port1: cannot reset (err = -32)
> [  215.191345] usb usb1-port1: cannot reset (err = -32)
> [  215.202487] usb usb1-port1: cannot reset (err = -32)
> [  215.207718] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [  215.219317] usb usb1-port1: unable to enumerate USB device
> 
> Hence we also enable the MXS_PHY_NEED_IP_FIX flag.
> 
> Signed-off-by: Stefan Agner 
> ---
>  Documentation/devicetree/bindings/usb/mxs-phy.txt | 1 +
>  drivers/usb/phy/phy-mxs-usb.c | 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt 
> b/Documentation/devicetree/bindings/usb/mxs-phy.txt
> index cef181a..fe3eed8 100644
> --- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
> +++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
> @@ -5,6 +5,7 @@ Required properties:
>   * "fsl,imx23-usbphy" for imx23 and imx28
>   * "fsl,imx6q-usbphy" for imx6dq and imx6dl
>   * "fsl,imx6sl-usbphy" for imx6sl
> + * "fsl,vf610-usbphy" for Vybrid vf610
>"fsl,imx23-usbphy" is still a fallback for other strings
>  - reg: Should contain registers location and length
>  - interrupts: Should contain phy interrupt
> diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
> index c42bdf0..8c2f23b 100644
> --- a/drivers/usb/phy/phy-mxs-usb.c
> +++ b/drivers/usb/phy/phy-mxs-usb.c
> @@ -125,10 +125,16 @@ static const struct mxs_phy_data imx6sl_phy_data = {
>   MXS_PHY_NEED_IP_FIX,
>  };
>  
> +static const struct mxs_phy_data vf610_phy_data = {
> + .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS |
> + MXS_PHY_NEED_IP_FIX,
> +};
> +
>  static const struct of_device_id mxs_phy_dt_ids[] = {
>   { .compatible = "fsl,imx6sl-usbphy", .data = _phy_data, },
>   { .compatible = "fsl,imx6q-usbphy", .data = _phy_data, },
>   { .compatible = "fsl,imx23-usbphy", .data = _phy_data, },
> + { .compatible = "fsl,vf610-usbphy", .data = _phy_data, },
>   { /* sentinel */ }
>  };
>  MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
> -- 
> 2.0.2
> 

Acked-by: Peter Chen 

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

Re: [PATCH 3/3] fpga sysfs interface

[Pavel Machek]

On Fri 2014-08-01 17:28:38, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Add basic sysfs interface.  Only exports two files:
> 
> /sys/class/fpga_manager/fpga0/name
>Name of low level driver.
> 
> /sys/class/fpga_manager/fpga0/status
>status of fpga framework as returned by core
>fpga-mgr.c's fpga_mgr_ops_framework_status
>function or by the low level driver's status
>function.

I believe sysfs additions need to be documented in
Documentation/ABI/. Otherwise it looks  good.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 2/3] fpga bus driver

[Pavel Machek]

Hi!

> Here's a simple example. Start with:
>   * the altera-gpio driver built in to the kernel but not in the
> device tree.
>   * raw fpga image at /lib/firmware/soc_system.rbf
>   * Load appropriate device tree overlay in configfs by doing
> $ mkdir /config/device-tree/overlays/1
> $ echo socfpga_overlay.dtbo > /config/device-tree/overlays/1/path
>   * This results in the FPGA getting programmed and the altera
> gpio driver getting probed.

Nice!

> +/* Find the fpga manager that is pointed to by a phandle */
> +struct fpga_manager *of_fpga_mgr_dev_lookup(struct device_node *node,
> + const char *mgr_property,
> + int *ret)
> +{
> + struct fpga_manager *mgr;
> + struct device_node *mgr_node;
> +
> + mgr_node = of_parse_phandle(node, mgr_property, 0);
> +
> + if (!mgr_node) {
> + *ret = -ENODEV;
> + return NULL;

Could IS_ERR_OR_NULL() and friends be used to get reasonable calling
convention?

Thanks, 
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 1/3] fpga manager framework core

[Pavel Machek]

Hi!

> + nr = ida_simple_get(_mgr_ida, start, FPGA_MAX_MINORS, GFP_KERNEL);
> +

Actually, are you sure ida framework is a good idea here? AFAICT, you
only use it to keep track of used minors. 
pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 1/3] fpga manager framework core

[Pavel Machek]

Hi!

> +static int fpga_mgr_get_new_minor(struct fpga_manager *mgr, int request_nr)
> +{
> + int nr, start;
> +
> + /* check specified minor number */
> + if (request_nr >= FPGA_MAX_MINORS) {
> + dev_err(mgr->parent, "Out of device minors (%d)\n", request_nr);
> + return -ENODEV;
> + }

if (request_nr < -1)
   return -EINVAL;
?

> + /* FPGA mangager isr */
> + irqreturn_t (*isr)(int irq, void *dev_id);
> +};

"manager"?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?

[Aniroop Mathur]

On Sat, Aug 2, 2014 at 4:11 AM, Greg KH  wrote:
> On Sat, Aug 02, 2014 at 03:54:32AM +0530, Aniroop Mathur wrote:
>> On Sat, Aug 2, 2014 at 12:53 AM, Greg KH  wrote:
>> > On Fri, Aug 01, 2014 at 10:43:23PM +0530, Aniroop Mathur wrote:
>> >> Dear Mr. Greg Kroah-Hartman and Linux Community,
>> >> Greetings of the day !! :)
>> >>
>> >> I am Aniroop Mathur working on Linux Kernel for last two years.
>> >> I am stuck at one point and could not find the solution over internet.
>> >> I posted on linuxquestions.org too.
>> >> So I need your help and suggestion for it.
>> >>
>> >> Can you please help in answering my query as below:
>> >>
>> >> =
>> >> In function device_add of /drivers/base/core.c file, it is mentioned:
>> >> /*
>> >> * for statically allocated devices, which should all be converted
>> >> * some day, we need to initialize the name. We prevent reading back
>> >> * the name, and force the use of dev_name()
>> >> */
>> >> if (dev->init_name) {
>> >> dev_set_name(dev, "%s", dev->init_name);
>> >> dev->init_name = NULL;
>> >> }
>> >>
>> >>
>> >> Except forcing the use of dev_name to read device name,
>> >> Is there any other reason to make init_name as NULL ?
>> >
>> > Why would you want init_name to not be NULL?
>> >
>>
>> Currently in kernel, we cannot set name of event node.
>
> What do you mean by "event node"?
>

I am referring to the device node which HAL/Application uses
as an interface to interact with kernel for read/write data operation.
like /dev/input/event0, /dev/input/event1, etc

int fd = open("/dev/input/event0", O_RDONLY);
int res = read(fd, _event, sizeof(input_event));

>> If dev->init_name is not set as NULL in device_add(),
>> then I can easily set name of event node in evdev_dev.c
>> file as below:
>>
>> if(dev->init_name) {
>>   sprintf(dev->init_name, "event_%s", dev->init_name);
>> }
>> error = device_add(>dev);
>>
>> And in some input device driver code, I will use like below:
>> dev->init_name = "accelerometer";
>> input_register_device(dev);
>
> What's wrong with:
> dev_set_name(dev, "%s", "accelerometer");
> input_register_device(dev);
>

It is good way for setting name of "Input node".
But it will not set name of "Event node".

input_register_device call sets name of two nodes
1. Input node - sys/class/input/input
2. Event node - /dev/input/event or sys/class/input/event

Here, input and event are default names set without using
dev_set_name in driver.
input - kobject name of struct input_dev;
event - kobject name of struct evdev;

In input_register_device(dev) function call,
dev refers to struct input_dev and not struct evdev.

struct input_dev is defined in input.h and
struct evdev is defined in evdev.c (not a header file).

So driver can use struct input_dev and set its name
using  dev_set_name(dev, "%s", "accelerometer");
But struct evdev is not accessible to driver as it is defined in
evdev.c file. So driver cannot use dev_set_name for evdev.
It can only be used in evdev.c file.

So above method output will be
sys/class/input/accelerometer
/dev/input/event and sys/class/input/event
(event node name not set)

>> So, overall output will be
>> /dev/input/event --> /dev/input/event_accelerometer
>> sys/class/input/input --> sys/class/input/accelerometer
>>
>> In short, input and event node names are set just by
>> adding one line, which i found quite efficient.
>> There is other way also to set name of event node but
>> it involves using extra variable and little more code,
>> So I am looking for best solution possible. :)
>
> Only use init_name for static struct devices, for a dynamic one, jsut
> set the name like everyone else does, how is that "more" code than
> anything else?
>

Can you please elaborate what do you mean by static struct devices ?
Can I consider embedded accelerometer, proximity, gyro sensor,
touch panel in android mobile devices as static devices ?

Input subsystem is setting default name of input and event node.
This is the normal method everyone uses.

I do not want to use default name like event0, event4, input2, etc
My aim is to set name of input and event node through driver as desired.
So after discussion of other ways to set name through driver,
we can compare which way is better.
In one other method, there is a need to add extra variable in
struct input_dev and hence more memory size.

>> >> And if it is not made NULL, is there any problem or side-effect ?
>> >
>> > Yes, people would start to use it thinking it was the real name of the
>> > device, when it might not be.
>> >
>>
>> As the name itself nicely suggests, it is just a initial name.
>
> So please do not use it, someday it will go away...
>
> thanks,
>

Thanks and Regards,
Aniroop Mathur
--
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  

Re: linux-next: manual merge of the driver-core tree with the tip tree

[Kees Cook]

On Thu, Jul 31, 2014 at 8:20 PM, Greg KH  wrote:
> On Thu, Jul 31, 2014 at 05:07:35PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the driver-core tree got a conflict in
>> lib/Kconfig.debug between commit e704f93af5a0 ("kernel: time: Add
>> udelay_test module to validate udelay") from the tip tree and commit
>> 0a8adf584759 ("test: add firmware_class loader test") from the
>> driver-core tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Looks good, thanks.

For keeping things regularized, could this module instead be named
"test_udelay", to match the rest of most of the test modules?
(Starting with "test_".)

-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 4/5] x86: entry_64.S: always allocate complete "struct pt_regs"

[Frederic Weisbecker]

On Fri, Aug 01, 2014 at 04:48:17PM +0200, Denys Vlasenko wrote:
>  
>  /* 0(%rsp): ~(interrupt number) */
>   .macro interrupt func
> - /* reserve pt_regs for scratch regs and rbp */
> - subq $ORIG_RAX-RBP, %rsp
> - CFI_ADJUST_CFA_OFFSET ORIG_RAX-RBP
> - cld
> - /* start from rbp in pt_regs and jump over */
> - movq_cfi rdi, (RDI-RBP)
> - movq_cfi rsi, (RSI-RBP)
> - movq_cfi rdx, (RDX-RBP)
> - movq_cfi rcx, (RCX-RBP)
> - movq_cfi rax, (RAX-RBP)
> - movq_cfi  r8,  (R8-RBP)
> - movq_cfi  r9,  (R9-RBP)
> - movq_cfi r10, (R10-RBP)
> - movq_cfi r11, (R11-RBP)
> -
> - /* Save rbp so that we can unwind from get_irq_regs() */
> - movq_cfi rbp, 0

Hmm SAVEE_C_REGS below doesn't seem to save rbp like we did before.
Perhaps it's implicitely saved somewhere?

> -
> - /* Save previous stack value */
> - movq %rsp, %rsi

Also rsp isn't saved in %rsi like before. Maybe
that's because we already save it in rdi? Makes sense since
now arg1 == rsp. More on that later.

> -
> - leaq -RBP(%rsp),%rdi/* arg1 for handler */
> - testl $3, CS-RBP(%rsi)
> + ALLOC_PTREGS_ON_STACK
> + SAVE_C_REGS
> + movq %rsp, %rdi /* arg1 for handler */
> + testl $3, CS(%rsp)
>   je 1f
>   SWAPGS
> - /*
> +1:   /*
>* irq_count is used to check if a CPU is already on an interrupt stack
>* or not. While this is essentially redundant with preempt_count it is
>* a little cheaper to use a separate counter in the PDA (short of
>* moving irq_enter into assembly, which would be too much work)
>*/
> -1:   incl PER_CPU_VAR(irq_count)
> + incl PER_CPU_VAR(irq_count)
>   cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
> - CFI_DEF_CFA_REGISTERrsi
> + CFI_DEF_CFA_REGISTERrdi
>  
>   /* Store previous stack value */
> - pushq %rsi
> + pushq %rdi

So you push rdi instead...

>   CFI_ESCAPE  0x0f /* DW_CFA_def_cfa_expression */, 6, \
>   0x77 /* DW_OP_breg7 */, 0, \
>   0x06 /* DW_OP_deref */, \
> - 0x08 /* DW_OP_const1u */, SS+8-RBP, \
> + 0x08 /* DW_OP_const1u */, SS+8, \
>   0x22 /* DW_OP_plus */
>   /* We entered an interrupt context - irqs are off: */
>   TRACE_IRQS_OFF
> -
>   call \func
>   .endm
>  
> @@ -749,10 +719,9 @@ ret_from_intr:
>  
>   /* Restore saved previous stack */
>   popq %rsi

And then you pop to rsi. Ok that indeed works but perhaps we should keep it 
symetrical
just for clarity? Any reason why we can't reuse rdi here?

> - CFI_DEF_CFA rsi,SS+8-RBP/* reg/off reset after def_cfa_expr */
> - leaq ARGOFFSET-RBP(%rsi), %rsp
> + CFI_DEF_CFA rsi,SS+8/* reg/off reset after def_cfa_expr */
> + movq %rsi, %rsp
>   CFI_DEF_CFA_REGISTERrsp
> - CFI_ADJUST_CFA_OFFSET   RBP-ARGOFFSET

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/

[GIT PULL] x86/Xen fix for v3.16[-rc8]

[H. Peter Anvin]

Hi Linus,

A single fix to not invoke the espfix code on Xen PV, as it turns out
to oops the guest when invoked after all.  This patch leaves some
amount of dead code, in particular unnecessary initialization of the
espfix stacks when they won't be used, but in the interest of keeping
the patch minimal that cleanup can wait for the next cycle.

The following changes since commit 64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91:

  Linux 3.16-rc7 (2014-07-27 12:41:55 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

for you to fetch changes up to 7209a75d2009dbf7745e2fd354abf25c3deb3ca3:

  x86_64/entry/xen: Do not invoke espfix64 on Xen (2014-07-28 15:25:40 -0700)


Andy Lutomirski (1):
  x86_64/entry/xen: Do not invoke espfix64 on Xen

 arch/x86/include/asm/irqflags.h |  2 +-
 arch/x86/kernel/entry_64.S  | 28 ++--
 arch/x86/kernel/paravirt_patch_64.c |  2 --
 3 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index bba3cf8..0a8b519 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -129,7 +129,7 @@ static inline notrace unsigned long 
arch_local_irq_save(void)
 
 #define PARAVIRT_ADJUST_EXCEPTION_FRAME/*  */
 
-#define INTERRUPT_RETURN   iretq
+#define INTERRUPT_RETURN   jmp native_iret
 #define USERGS_SYSRET64\
swapgs; \
sysretq;
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index b25ca96..c844f08 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -830,27 +830,24 @@ restore_args:
RESTORE_ARGS 1,8,1
 
 irq_return:
+   INTERRUPT_RETURN
+
+ENTRY(native_iret)
/*
 * Are we returning to a stack segment from the LDT?  Note: in
 * 64-bit mode SS:RSP on the exception stack is always valid.
 */
 #ifdef CONFIG_X86_ESPFIX64
testb $4,(SS-RIP)(%rsp)
-   jnz irq_return_ldt
+   jnz native_irq_return_ldt
 #endif
 
-irq_return_iret:
-   INTERRUPT_RETURN
-   _ASM_EXTABLE(irq_return_iret, bad_iret)
-
-#ifdef CONFIG_PARAVIRT
-ENTRY(native_iret)
+native_irq_return_iret:
iretq
-   _ASM_EXTABLE(native_iret, bad_iret)
-#endif
+   _ASM_EXTABLE(native_irq_return_iret, bad_iret)
 
 #ifdef CONFIG_X86_ESPFIX64
-irq_return_ldt:
+native_irq_return_ldt:
pushq_cfi %rax
pushq_cfi %rdi
SWAPGS
@@ -872,7 +869,7 @@ irq_return_ldt:
SWAPGS
movq %rax,%rsp
popq_cfi %rax
-   jmp irq_return_iret
+   jmp native_irq_return_iret
 #endif
 
.section .fixup,"ax"
@@ -956,13 +953,8 @@ __do_double_fault:
cmpl $__KERNEL_CS,CS(%rdi)
jne do_double_fault
movq RIP(%rdi),%rax
-   cmpq $irq_return_iret,%rax
-#ifdef CONFIG_PARAVIRT
-   je 1f
-   cmpq $native_iret,%rax
-#endif
+   cmpq $native_irq_return_iret,%rax
jne do_double_fault /* This shouldn't happen... */
-1:
movq PER_CPU_VAR(kernel_stack),%rax
subq $(6*8-KERNEL_STACK_OFFSET),%rax/* Reset to original stack */
movq %rax,RSP(%rdi)
@@ -1428,7 +1420,7 @@ error_sti:
  */
 error_kernelspace:
incl %ebx
-   leaq irq_return_iret(%rip),%rcx
+   leaq native_irq_return_iret(%rip),%rcx
cmpq %rcx,RIP+8(%rsp)
je error_swapgs
movl %ecx,%eax  /* zero extend */
diff --git a/arch/x86/kernel/paravirt_patch_64.c 
b/arch/x86/kernel/paravirt_patch_64.c
index 3f08f34..a1da673 100644
--- a/arch/x86/kernel/paravirt_patch_64.c
+++ b/arch/x86/kernel/paravirt_patch_64.c
@@ -6,7 +6,6 @@ DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
 DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
 DEF_NATIVE(pv_irq_ops, restore_fl, "pushq %rdi; popfq");
 DEF_NATIVE(pv_irq_ops, save_fl, "pushfq; popq %rax");
-DEF_NATIVE(pv_cpu_ops, iret, "iretq");
 DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax");
 DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax");
 DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3");
@@ -50,7 +49,6 @@ unsigned native_patch(u8 type, u16 clobbers, void *ibuf,
PATCH_SITE(pv_irq_ops, save_fl);
PATCH_SITE(pv_irq_ops, irq_enable);
PATCH_SITE(pv_irq_ops, irq_disable);
-   PATCH_SITE(pv_cpu_ops, iret);
PATCH_SITE(pv_cpu_ops, irq_enable_sysexit);
PATCH_SITE(pv_cpu_ops, usergs_sysret32);
PATCH_SITE(pv_cpu_ops, usergs_sysret64);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/5] x86: entry_64.S: always allocate complete "struct pt_regs"

[Frederic Weisbecker]

On Fri, Aug 01, 2014 at 04:48:17PM +0200, Denys Vlasenko wrote:
> 64-bit code was using six stack slots fewer by not saving/restoring
> registers which a callee-preserved according to C ABI,
> and not allocating space for them.
> 
> Only when syscall needed a complete "struct pt_regs",
> the complete area was allocated and filled in.
> 
> This proved to be a source of significant obfuscation and subtle bugs.
> For example, stub_fork had to pop the return address,
> extend the struct, save registers, and push return address back. Ugly.
> ia32_ptregs_common pops return address and "returns" via jmp insn,
> throwing a wrench into CPU return stack cache.
> 
> This patch changes code to always allocate a complete "struct pt_regs".
> The saving of registers is still done lazily.
> 
> Macros which manipulate "struct pt_regs" on stack are reworked:
> ALLOC_PTREGS_ON_STACK allocates the structure.
> SAVE_C_REGS saves to it those registers which are clobbered by C code.
> SAVE_EXTRA_REGS saves to it all other registers.
> Corresponding RESTORE_* and REMOVE_PTREGS_FROM_STACK macros reverse it.
> 
> ia32_ptregs_common, stub_fork and friends lost their ugly dance with
> return pointer.
> 
> LOAD_ARGS32 in ia32entry.S now uses a symbolic stack offsets
> instead of magic numbers.
> 
> Misleading and slightly wrong comments in "struct pt_regs" are fixed
> (four instances).
> 
> Patch was run-tested: 64-bit executables, 32-bit executables,
> strace works.
> 
> Signed-off-by: Denys Vlasenko 
> CC: Oleg Nesterov 
> CC: "H. Peter Anvin" 
> CC: Andy Lutomirski 
> CC: Frederic Weisbecker 
> CC: X86 ML 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/ia32/ia32entry.S  |  47 +++
>  arch/x86/include/asm/calling.h | 224 
> -
>  arch/x86/include/asm/irqflags.h|   4 +-
>  arch/x86/include/asm/ptrace.h  |  13 +-
>  arch/x86/include/uapi/asm/ptrace-abi.h |  16 ++-
>  arch/x86/include/uapi/asm/ptrace.h |  13 +-
>  arch/x86/kernel/entry_64.S | 132 ---
>  arch/x86/kernel/preempt.S  |  16 ++-
>  8 files changed, 232 insertions(+), 233 deletions(-)
> 
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 4299eb0..ef9ee16 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -62,12 +62,12 @@
>*/
>   .macro LOAD_ARGS32 offset, _r9=0
>   .if \_r9
> - movl \offset+16(%rsp),%r9d
> + movl \offset+R9(%rsp),%r9d
>   .endif
> - movl \offset+40(%rsp),%ecx
> - movl \offset+48(%rsp),%edx
> - movl \offset+56(%rsp),%esi
> - movl \offset+64(%rsp),%edi
> + movl \offset+RCX(%rsp),%ecx
> + movl \offset+RDX(%rsp),%edx
> + movl \offset+RSI(%rsp),%esi
> + movl \offset+RDI(%rsp),%edi
>   movl %eax,%eax  /* zero extension */
>   .endm
>   
> @@ -144,7 +144,8 @@ ENTRY(ia32_sysenter_target)
>   CFI_REL_OFFSET rip,0
>   pushq_cfi %rax
>   cld
> - SAVE_ARGS 0,1,0
> + ALLOC_PTREGS_ON_STACK
> + SAVE_C_REGS_EXCEPT_R891011
>   /* no need to do an access_ok check here because rbp has been
>  32bit zero extended */ 
>   ASM_STAC
> @@ -172,7 +173,8 @@ sysexit_from_sys_call:
>   andl  $~0x200,EFLAGS-R11(%rsp) 
>   movlRIP-R11(%rsp),%edx  /* User %eip */
>   CFI_REGISTER rip,rdx
> - RESTORE_ARGS 0,24,0,0,0,0
> + RESTORE_RSI_RDI

I heard there will be a v2 so I'll probably wait for it to review this patch
which really requires 0db where I sit.

But the macro names like above look much clearer as well!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, irq: Keep IRQ assignment for PCI devices during suspend/hibernation, bisected

[Borislav Petkov]

On Sat, Aug 02, 2014 at 12:14:10AM +0200, Jörg Rödel wrote:
> My guess is that the firmware takes back the device after the OS
> released it and now the legacy emulation tries to do DMA with it. But
> since there is an IOMMU the physical addresses it tries to DMA to is
> not mapped and it generated IO page faults
> 
> In a perfect world the BIOS would define Unity Mapping regions in the
> IVRS ACPI table for the USB controler so that the IOMMU driver would
> keep these regions mapped.  But I have never seen those regions defined
> by any BIOS of an AMD machine, so this is probably the cause why you are
> seeing these IO page faults.

Ok but what changed? Apparently we didn't have that small window earlier
as I have never seen those IOMMU PFs before. So Jiang's stuff simply
opens that hole now. And I bet this whole work is aiming at physical
hotplug which is all fine and dandy but it shouldn't cause regressions.

So, IIUC, the dynamic IOAPIC stuff of freeing an irq number during
suspend opens this hole. Which leads me to the naive thinking that maybe
this new behavior should be configurable so that systems can choose.

And I bet I won't be the last one to trigger those when those changes
hit 3.17...

> But this doesn't explain the GPU faults, though.

I think this got fixed by

https://lkml.kernel.org/r/1406766807-5745-1-git-send-email-jiang@linux.intel.com

which keeps the IRQ numbers across S/R.

I'll watch out for those though.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] usb: host: ehci-msm: Make of_device_id array const

[Greg KH]

On Wed, Jul 30, 2014 at 06:14:45PM +0530, Kiran Padwal wrote:
> Make of_device_id array const, because all OF functions handle it as const.
> 
> Signed-off-by: Kiran Padwal 
> ---
>  drivers/usb/host/ehci-msm.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-msm.c b/drivers/usb/host/ehci-msm.c
> index 982c09b..934b39d 100644
> --- a/drivers/usb/host/ehci-msm.c
> +++ b/drivers/usb/host/ehci-msm.c
> @@ -190,7 +190,7 @@ static const struct dev_pm_ops ehci_msm_dev_pm_ops = {
>   .resume  = ehci_msm_pm_resume,
>  };
>  
> -static struct of_device_id msm_ehci_dt_match[] = {
> +static const struct of_device_id msm_ehci_dt_match[] = {
>   { .compatible = "qcom,ehci-host", },
>   {}
>  };
> -- 
> 1.7.9.5

This patch is already in my tree, right?  Why submit it again?

confused,

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

Re: [PATCH] asm-generic/io.h: reorder funtions to form logical groups

[Sam Ravnborg]

> 
> Oh, by the way: would you prefer that I keep your patch separate or
> shall I just squash it into the one that has the major asm-generic/io.h
> cleanup?
Do whatever is the most convinient for you.
And do not bother with any attribution and such for such a simple patch.

Sam
--
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: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?

[Greg KH]

On Sat, Aug 02, 2014 at 03:54:32AM +0530, Aniroop Mathur wrote:
> On Sat, Aug 2, 2014 at 12:53 AM, Greg KH  wrote:
> > On Fri, Aug 01, 2014 at 10:43:23PM +0530, Aniroop Mathur wrote:
> >> Dear Mr. Greg Kroah-Hartman and Linux Community,
> >> Greetings of the day !! :)
> >>
> >> I am Aniroop Mathur working on Linux Kernel for last two years.
> >> I am stuck at one point and could not find the solution over internet.
> >> I posted on linuxquestions.org too.
> >> So I need your help and suggestion for it.
> >>
> >> Can you please help in answering my query as below:
> >>
> >> =
> >> In function device_add of /drivers/base/core.c file, it is mentioned:
> >> /*
> >> * for statically allocated devices, which should all be converted
> >> * some day, we need to initialize the name. We prevent reading back
> >> * the name, and force the use of dev_name()
> >> */
> >> if (dev->init_name) {
> >> dev_set_name(dev, "%s", dev->init_name);
> >> dev->init_name = NULL;
> >> }
> >>
> >>
> >> Except forcing the use of dev_name to read device name,
> >> Is there any other reason to make init_name as NULL ?
> >
> > Why would you want init_name to not be NULL?
> >
> 
> Currently in kernel, we cannot set name of event node.

What do you mean by "event node"?

> If dev->init_name is not set as NULL in device_add(),
> then I can easily set name of event node in evdev_dev.c
> file as below:
> 
> if(dev->init_name) {
>   sprintf(dev->init_name, "event_%s", dev->init_name);
> }
> error = device_add(>dev);
> 
> And in some input device driver code, I will use like below:
> dev->init_name = "accelerometer";
> input_register_device(dev);

What's wrong with:
dev_set_name(dev, "%s", "accelerometer");
input_register_device(dev);

> So, overall output will be
> /dev/input/event --> /dev/input/event_accelerometer
> sys/class/input/input --> sys/class/input/accelerometer
> 
> In short, input and event node names are set just by
> adding one line, which i found quite efficient.
> There is other way also to set name of event node but
> it involves using extra variable and little more code,
> So I am looking for best solution possible. :)

Only use init_name for static struct devices, for a dynamic one, jsut
set the name like everyone else does, how is that "more" code than
anything else?

> >> And if it is not made NULL, is there any problem or side-effect ?
> >
> > Yes, people would start to use it thinking it was the real name of the
> > device, when it might not be.
> >
> 
> As the name itself nicely suggests, it is just a initial name.

So please do not use it, someday it will go away...

thanks,

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

[PATCH 2/3] fpga bus driver

[atull]

From: Alan Tull 

This driver allows programming the fpga from
device tree overlays.

This code is dependent on Pantelis Antoniou's current
work on Device Tree overlays, a method of dynamically
altering the kerel's live Device Tree.  This patchset
was tested with Pantelis's and Grant Likely's stuff
that is in git plus some dtc fixups for compiling
overlays.

Resume is handled by re-requesting the firmware and
reprogramming the FPGA.

Here's a simple example. Start with:
  * the altera-gpio driver built in to the kernel but not in the
device tree.
  * raw fpga image at /lib/firmware/soc_system.rbf
  * Load appropriate device tree overlay in configfs by doing
$ mkdir /config/device-tree/overlays/1
$ echo socfpga_overlay.dtbo > /config/device-tree/overlays/1/path
  * This results in the FPGA getting programmed and the altera
gpio driver getting probed.

TODO:
  * Add ability to take fpga/cpu bridges out of reset.
  * To remove/clear FPGA image, remove device tree overlay by doing:
$ rmdir /config/device-tree/overlays/1

Device tree overlay looks like this:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target-path="/soc";
__overlay__ {
#address-cells = <1>;
#size-cells = <1>;

bridge@0xff20 {
compatible = "fpga-mgr-bus", "simple-bus";
reg = <0xff20 0x20>;
clocks = <0x2 0x2>;
clock-names = "h2f_lw_axi_clock", 
"f2h_sdram0_clock";
#address-cells = <0x2>;
#size-cells = <0x1>;
ranges = <0x1 0x10040 0xff210040 0x20>;

fpgamgr = <_0_fpgamgr>;
fpga-firmware = "soc_system.rbf";

gpio@0x100010040 {
compatible = "altr,pio-14.0", 
"altr,pio-1.0";
reg = <0x1 0x10040 0x20>;
clocks = <0x2>;
altr,gpio-bank-width = <0x4>;
resetvalue = <0x0>;
#gpio-cells = <0x2>;
gpio-controller;
linux,phandle = <0x2d>;
};
};
};
};
};

This patch adds one exported function to the core
(fpga-mgr.c):

EXPORT_SYMBOL_GPL(of_fpga_mgr_dev_lookup);
  Get pointer to fpga manager struct given a phandle.

Signed-off-by: Alan Tull 
---
 drivers/fpga/Kconfig |7 +++
 drivers/fpga/Makefile|1 +
 drivers/fpga/bus.c   |  145 ++
 drivers/fpga/fpga-mgr.c  |   26 +
 include/linux/fpga-mgr.h |4 ++
 5 files changed, 183 insertions(+)
 create mode 100644 drivers/fpga/bus.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 49293a3..9a2c25b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -10,4 +10,11 @@ config FPGA
  Say Y here if you want support for configuring FPGAs from the
  kernel.  The FPGA framework adds a FPGA manager class and FPGA
  manager drivers.
+
+config FPGA_MGR_BUS
+   bool "FPGA Manager Bus"
+   depends on FPGA
+   help
+ FPGA Manager Bus interface.  Allows loading FPGA images
+ from Device Tree or from other drivers.
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index c8a676f..e39911f 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@ fpga-mgr-core-y += fpga-mgr.o
 
 # Core FPGA Manager Framework
 obj-$(CONFIG_FPGA) += fpga-mgr-core.o
+obj-$(CONFIG_FPGA_MGR_BUS) += bus.o
 
 # FPGA Manager Drivers
diff --git a/drivers/fpga/bus.c b/drivers/fpga/bus.c
new file mode 100644
index 000..3aa4a8e
--- /dev/null
+++ b/drivers/fpga/bus.c
@@ -0,0 +1,145 @@
+/*
+ * FPGA Manager Bus Driver
+ *
+ *  Copyright (C) 2013-2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

[PATCH 0/3] Yet another stab at a fpga framework

[atull]

From: Alan Tull 

[resend with fixed email settings]

The idea of the framework is to provide consistent ways of
programming raw images into FPGA's.

Programming from device tree overlays is supported.

The core (fpga-mgr.c) does not include a userspace interface
and just exports kernel functions.

This approach separates the core from the interfaces.

Each interface can be enabled or disabled in the defconfig.
In some production contexts, interfaces that might be used
during development can be disabled.

The core exports kernel functions to:
  * write the fpga from a buffer or using the firmware layer
  * get fpga status
  * find a particular fpga manager from a device tree phandle
  * register/unregister lower level fpga drivers.

The bus allows us to:
  * program fpga from a device tree overlay using firmware.
  * automatically reload firmware and reprogram fpga during resume.

The sysfs interface:
  * read only, get the name and status of fpga manager.

I have a configfs interface patch which I haven't included,
adds configfs as a separate file.

TODO:
  * Enable bridges after fpga programming, disable during suspend

Alan Tull (3):
  fpga manager framework core
  fpga bus driver
  fpga sysfs interface

 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/fpga/Kconfig |   27 +++
 drivers/fpga/Makefile|   12 ++
 drivers/fpga/bus.c   |  145 
 drivers/fpga/fpga-mgr.c  |  431 ++
 drivers/fpga/sysfs.c |   69 
 include/linux/fpga-mgr.h |  137 +++
 8 files changed, 824 insertions(+)
 create mode 100644 drivers/fpga/Kconfig
 create mode 100644 drivers/fpga/Makefile
 create mode 100644 drivers/fpga/bus.c
 create mode 100644 drivers/fpga/fpga-mgr.c
 create mode 100644 drivers/fpga/sysfs.c
 create mode 100644 include/linux/fpga-mgr.h

-- 
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 3/3] fpga sysfs interface

[atull]

From: Alan Tull 

Add basic sysfs interface.  Only exports two files:

/sys/class/fpga_manager/fpga0/name
   Name of low level driver.

/sys/class/fpga_manager/fpga0/status
   status of fpga framework as returned by core
   fpga-mgr.c's fpga_mgr_ops_framework_status
   function or by the low level driver's status
   function.

Signed-off-by: Alan Tull 
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|1 +
 drivers/fpga/fpga-mgr.c  |2 ++
 drivers/fpga/sysfs.c |   69 ++
 include/linux/fpga-mgr.h |   12 
 5 files changed, 91 insertions(+)
 create mode 100644 drivers/fpga/sysfs.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 9a2c25b..113b8b4 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -17,4 +17,11 @@ config FPGA_MGR_BUS
help
  FPGA Manager Bus interface.  Allows loading FPGA images
  from Device Tree or from other drivers.
+
+config FPGA_MGR_SYSFS
+   bool "FPGA Manager SysFS Interface"
+   depends on FPGA
+   depends on SYSFS
+   help
+ FPGA Manager SysFS interface.
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index e39911f..cad3d8c 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -7,5 +7,6 @@ fpga-mgr-core-y += fpga-mgr.o
 # Core FPGA Manager Framework
 obj-$(CONFIG_FPGA) += fpga-mgr-core.o
 obj-$(CONFIG_FPGA_MGR_BUS) += bus.o
+obj-$(CONFIG_FPGA_MGR_SYSFS)   += sysfs.o
 
 # FPGA Manager Drivers
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 93327ea..a604de7 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -402,6 +402,8 @@ static int __init fpga_mgr_dev_init(void)
if (IS_ERR(fpga_mgr_class))
return PTR_ERR(fpga_mgr_class);
 
+   fpga_mgr_sysfs_init(fpga_mgr_class);
+
ret = alloc_chrdev_region(_mgr_dev, 0, FPGA_MAX_MINORS,
  "fpga_manager");
if (ret) {
diff --git a/drivers/fpga/sysfs.c b/drivers/fpga/sysfs.c
new file mode 100644
index 000..ba2332d
--- /dev/null
+++ b/drivers/fpga/sysfs.c
@@ -0,0 +1,69 @@
+/*
+ * FPGA Manager SysFS Interface
+ *
+ *  Copyright (C) 2013-2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * class attributes
+ */
+static ssize_t fpga_mgr_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct fpga_manager *mgr = dev_get_drvdata(dev);
+
+   return fpga_mgr_name(mgr, buf);
+}
+
+static ssize_t fpga_mgr_status_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct fpga_manager *mgr = dev_get_drvdata(dev);
+
+   return fpga_mgr_status_get(mgr, buf);
+}
+
+static DEVICE_ATTR(name, S_IRUGO, fpga_mgr_name_show, NULL);
+static DEVICE_ATTR(status, S_IRUGO, fpga_mgr_status_show, NULL);
+
+static struct attribute *fpga_mgr_attrs[] = {
+   _attr_name.attr,
+   _attr_status.attr,
+   NULL,
+};
+
+static const struct attribute_group fpga_mgr_group = {
+   .attrs = fpga_mgr_attrs,
+};
+
+const struct attribute_group *fpga_mgr_groups[] = {
+   _mgr_group,
+   NULL,
+};
+
+void fpga_mgr_sysfs_init(struct class *fpga_mgr_class)
+{
+   fpga_mgr_class->dev_groups = fpga_mgr_groups;
+}
+EXPORT_SYMBOL_GPL(fpga_mgr_sysfs_init);
+
+MODULE_AUTHOR("Alan Tull ");
+MODULE_DESCRIPTION("FPGA Manager framework driver sysfs interface");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/fpga-mgr.h b/include/linux/fpga-mgr.h
index 35d3380..86eeff5 100644
--- a/include/linux/fpga-mgr.h
+++ b/include/linux/fpga-mgr.h
@@ -105,6 +105,18 @@ struct fpga_manager {
 
 #if IS_ENABLED(CONFIG_FPGA)
 
+#ifdef CONFIG_FPGA_MGR_SYSFS
+
+void fpga_mgr_sysfs_init(struct class *fpga_mgr_class);
+
+#else
+
+static inline void fpga_mgr_sysfs_init(struct class *fpga_mgr_class)
+{
+}
+
+#endif /* CONFIG_FPGA_MGR_SYSFS */
+
 struct fpga_manager *of_fpga_mgr_dev_lookup(struct device_node *node,
const char *mgr_property,
int *ret);
-- 
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 

[PATCH 1/3] fpga manager framework core

[atull]

From: Alan Tull 

This core exports methods of doing operations on FPGAs.

EXPORT_SYMBOL_GPL(fpga_mgr_write);
  Write FPGA given a buffer and count.

EXPORT_SYMBOL_GPL(fpga_mgr_firmware_write);
  Request firmware and write that to a fpga

EXPORT_SYMBOL_GPL(fpga_mgr_status_get);
  Get a status string, including failure information

EXPORT_SYMBOL_GPL(fpga_mgr_name);
  Get name of FPGA manager

EXPORT_SYMBOL_GPL(register_fpga_manager);
EXPORT_SYMBOL_GPL(remove_fpga_manager);
  Register/unregister low level fpga driver

TODO: Add interface to set FPGA in specific state such
  as reset.

All userspace interfaces are in separate files so that
they can be compiled out on production builds where
appropriate.

Signed-off-by: Alan Tull 
---
 drivers/Kconfig  |2 +
 drivers/Makefile |1 +
 drivers/fpga/Kconfig |   13 ++
 drivers/fpga/Makefile|   10 ++
 drivers/fpga/fpga-mgr.c  |  403 ++
 include/linux/fpga-mgr.h |  121 ++
 6 files changed, 550 insertions(+)
 create mode 100644 drivers/fpga/Kconfig
 create mode 100644 drivers/fpga/Makefile
 create mode 100644 drivers/fpga/fpga-mgr.c
 create mode 100644 include/linux/fpga-mgr.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 0e87a34..b0cbbae 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -34,6 +34,8 @@ source "drivers/message/fusion/Kconfig"
 
 source "drivers/firewire/Kconfig"
 
+source "drivers/fpga/Kconfig"
+
 source "drivers/message/i2o/Kconfig"
 
 source "drivers/macintosh/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index f98b50d..afdd2aa 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_RESET_CONTROLLER)+= reset/
 # default.
 obj-y  += tty/
 obj-y  += char/
+obj-$(CONFIG_FPGA) += fpga/
 
 # gpu/ comes after char for AGP vs DRM startup
 obj-y  += gpu/
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
new file mode 100644
index 000..49293a3
--- /dev/null
+++ b/drivers/fpga/Kconfig
@@ -0,0 +1,13 @@
+#
+# FPGA framework configuration
+#
+
+menu "FPGA devices"
+
+config FPGA
+   tristate "FPGA Framework"
+   help
+ Say Y here if you want support for configuring FPGAs from the
+ kernel.  The FPGA framework adds a FPGA manager class and FPGA
+ manager drivers.
+endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
new file mode 100644
index 000..c8a676f
--- /dev/null
+++ b/drivers/fpga/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for the fpga framework and fpga manager drivers.
+#
+
+fpga-mgr-core-y += fpga-mgr.o
+
+# Core FPGA Manager Framework
+obj-$(CONFIG_FPGA) += fpga-mgr-core.o
+
+# FPGA Manager Drivers
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
new file mode 100644
index 000..0e2eba4
--- /dev/null
+++ b/drivers/fpga/fpga-mgr.c
@@ -0,0 +1,403 @@
+/*
+ * FPGA Manager Core
+ *
+ *  Copyright (C) 2013-2014 Altera Corporation
+ *
+ * With code from the mailing list:
+ * Copyright (C) 2013 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_mgr_ida);
+static int fpga_mgr_major;
+static struct class *fpga_mgr_class;
+
+#define FPGA_MAX_MINORS256
+
+static DEFINE_MUTEX(fpga_manager_mutex);
+static LIST_HEAD(fpga_manager_list);
+
+/*
+ * Unlocked version of fpga_mgr_write function.
+ *  Does not touch flags.  So caller must grab the FPGA_MGR_BUSY bit
+ *  and update the FPGA_MGR_FAIL bit.
+ */
+static int __fpga_mgr_write(struct fpga_manager *mgr, const char *buf,
+   size_t count)
+{
+   int ret;
+
+   if (mgr->mops->write_init) {
+   mgr->state = FPGA_MGR_WRITE_INIT;
+   ret = mgr->mops->write_init(mgr);
+   if (ret)
+   return ret;
+   }
+
+   mgr->state = FPGA_MGR_WRITE;
+   ret = mgr->mops->write(mgr, buf, count);
+   if (ret)
+   return ret;
+
+   if (mgr->mops->write_complete) {
+   mgr->state = FPGA_MGR_WRITE_COMPLETE;
+   ret = mgr->mops->write_complete(mgr);
+   if (ret)
+   return ret;
+   }
+
+   mgr->state = 

Re: [Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?

[Aniroop Mathur]

On Sat, Aug 2, 2014 at 12:53 AM, Greg KH  wrote:
> On Fri, Aug 01, 2014 at 10:43:23PM +0530, Aniroop Mathur wrote:
>> Dear Mr. Greg Kroah-Hartman and Linux Community,
>> Greetings of the day !! :)
>>
>> I am Aniroop Mathur working on Linux Kernel for last two years.
>> I am stuck at one point and could not find the solution over internet.
>> I posted on linuxquestions.org too.
>> So I need your help and suggestion for it.
>>
>> Can you please help in answering my query as below:
>>
>> =
>> In function device_add of /drivers/base/core.c file, it is mentioned:
>> /*
>> * for statically allocated devices, which should all be converted
>> * some day, we need to initialize the name. We prevent reading back
>> * the name, and force the use of dev_name()
>> */
>> if (dev->init_name) {
>> dev_set_name(dev, "%s", dev->init_name);
>> dev->init_name = NULL;
>> }
>>
>>
>> Except forcing the use of dev_name to read device name,
>> Is there any other reason to make init_name as NULL ?
>
> Why would you want init_name to not be NULL?
>

Currently in kernel, we cannot set name of event node.

If dev->init_name is not set as NULL in device_add(),
then I can easily set name of event node in evdev_dev.c
file as below:

if(dev->init_name) {
  sprintf(dev->init_name, "event_%s", dev->init_name);
}
error = device_add(>dev);

And in some input device driver code, I will use like below:
dev->init_name = "accelerometer";
input_register_device(dev);

So, overall output will be
/dev/input/event --> /dev/input/event_accelerometer
sys/class/input/input --> sys/class/input/accelerometer

In short, input and event node names are set just by
adding one line, which i found quite efficient.
There is other way also to set name of event node but
it involves using extra variable and little more code,
So I am looking for best solution possible. :)

>> And if it is not made NULL, is there any problem or side-effect ?
>
> Yes, people would start to use it thinking it was the real name of the
> device, when it might not be.
>

As the name itself nicely suggests, it is just a initial name.
It may not be the final name as developer can change the name
using dev_set_name. Also dev_name api is available to get
final/current name of the device.

Thanks and Regards,
Aniroop Mathur
--
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: [PATCHv9 1/3] mfd: altera: Add Altera SDRAM Controller

[Thor Thayer]

On 08/01/2014 03:13 AM, Lee Jones wrote:

On Thu, 31 Jul 2014, Thor Thayer wrote:

On 07/31/2014 03:26 AM, Lee Jones wrote:

On Wed, 30 Jul 2014, ttha...@opensource.altera.com wrote:


From: Thor Thayer 

Add a simple MFD for the Altera SDRAM Controller.

Signed-off-by: Alan Tull 
Signed-off-by: Thor Thayer 
---
v1-8: The MFD implementation was not included in the original series.

v9: New MFD implementation.
---
  MAINTAINERS|5 ++
  drivers/mfd/Kconfig|7 ++
  drivers/mfd/Makefile   |1 +
  drivers/mfd/altera-sdr.c   |  162 
  include/linux/mfd/altera-sdr.h |  102 +
  5 files changed, 277 insertions(+)
  create mode 100644 drivers/mfd/altera-sdr.c
  create mode 100644 include/linux/mfd/altera-sdr.h

[...]


+++ b/drivers/mfd/altera-sdr.c
@@ -0,0 +1,162 @@
+/*
+ * SDRAM Controller (SDR) MFD
+ *
+ * Copyright (C) 2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .

Can you use the shorter version of the licence?

Hi. This seems to be the shorter version of the license agreement
and is fairly common in the kernel, right?

This is the long(ish) version.  Many programs have the Copyright line
and the "This program is free software;" line.  It'll also be a good
idea to keep the link to the full licence.

[...]

Hi Lee.

Our legal department requires this header.  Their reasoning is that they 
want to retain the rights and warranty language with the file (just in 
case the COPYING file changes).



+   {
+   .name = "altr_sdram_edac",
+   .of_compatible = "altr,sdram-edac",

What other devices will there be?


There will be an FPGA bridge and a power control driver that will
need access to the SDR Controller registers.

Okay.  Do you know when they'll be upstreamed?

The other drivers are waiting on this file as a pre-requisite.

+u32 altera_sdr_readl(struct altera_sdr *sdr, u32 reg_offset)
+{
+   return readl(sdr->reg_base + reg_offset);
+}
+EXPORT_SYMBOL_GPL(altera_sdr_readl);
+
+void altera_sdr_writel(struct altera_sdr *sdr, u32 reg_offset, u32 value)
+{
+   writel(value, sdr->reg_base + reg_offset);
+}
+EXPORT_SYMBOL_GPL(altera_sdr_writel);

Why are you abstracting these?

Might be better to use Regmap even.

regmap seems unnecessarily complex for what we're doing which is why
this method was chosen.

Future drivers will access different sets of registers in the
device. These drivers won't share bitfields in the same register so
the MFD seemed like the best solution. Originally we implemented
this using syscon but that seems to be frowned upon so we changed to
using a MFD.

Why was the use of syscon frowned upon?  Can you link me to the
thread?  Writing directly to the registers sounds to me a lot worse
than using infrastructure which was designed for these kinds of
accesses.

If you do choose to fiddle with the registers in this manner, is there
any reason why you're calling back into here, rather than using
readl() and writel() directly?

We'd prefer to use syscon and that is what we started with. If you'd 
like to be our advocate, I will return to that because it was pretty 
clean. My primary concern is to get it upstreamed and if it is MFD then 
I'll make the changes.


Here are the threads.
http://marc.info/?l=linux-kernel=140128791902800=2
and
http://article.gmane.org/gmane.linux.kernel/1679601

+u32 altera_sdr_mem_size(struct altera_sdr *sdr)
+{
+   u32 size;
+   u32 read_reg, row, bank, col, cs, width;

Weird that size is on its own.  Either place on a single line or
separate them all.

OK. I will change this.

+   read_reg = altera_sdr_readl(sdr, SDR_DRAMADDRW_OFST);
+   if (read_reg < 0)
+   return 0;
+
+   width = altera_sdr_readl(sdr, SDR_DRAMIFWIDTH_OFST);
+   if (width < 0)
+   return 0;

u32s cant be < 0.  The 'u' means 'unsigned'.

Whoops. Good catch.

+   col = (read_reg & SDR_DRAMADDRW_COLBITS_MASK) >>
+   SDR_DRAMADDRW_COLBITS_LSB;
+   row = (read_reg & SDR_DRAMADDRW_ROWBITS_MASK) >>
+   SDR_DRAMADDRW_ROWBITS_LSB;
+   bank = (read_reg & SDR_DRAMADDRW_BANKBITS_MASK) >>
+   SDR_DRAMADDRW_BANKBITS_LSB;
+   cs = (read_reg & SDR_DRAMADDRW_CSBITS_MASK) >>
+   SDR_DRAMADDRW_CSBITS_LSB;

These would probably be better as macros.


OK. I will fix this.

+   /* 

Re: [PATCH] x86, irq: Keep IRQ assignment for PCI devices during suspend/hibernation, bisected

[Jörg Rödel]

On Fri, Aug 01, 2014 at 06:11:08PM +0200, Borislav Petkov wrote:
> [   89.040795] pcieport :00:04.0: System wakeup enabled by ACPI
> [   89.061697] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 
> domain=0x0014 address=0x20001000 flags=0x]
> [   89.071871] ACPI: Preparing to enter system sleep state S5
> [   89.072117] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query honored via 
> cmdline
> [   89.089832] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0x0080 flags=0x0020]
> [   89.102239] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0x flags=0x]
> [   89.114684] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0xffc0 flags=0x0010]
> [   89.127162] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0xffc0 flags=0x0010]
> [   89.139576] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0xffc0 flags=0x0010]
> [   89.152017] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0xffc0 flags=0x0010]
> [   89.164481] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:12.0 
> domain=0x0009 address=0xffc0 flags=0x0010]
> [   89.176994] AMD-Vi: Event logged [[   89.177657] reboot: Power down
> [   89.185286] acpi_power_off called
> 
> Now this device 00:12.0 is that OHCI thing for which we have the
> hcd-pci.c hunk applied above, AFAICT:
> 
> 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
> 
> so it must be still some timing issue there after disabling the device
> and *before* disabling the IOMMU.

My guess is that the firmware takes back the device after the OS
released it and now the legacy emulation tries to do DMA with it. But
since there is an IOMMU the physical addresses it tries to DMA to is
not mapped and it generated IO page faults

In a perfect world the BIOS would define Unity Mapping regions in the
IVRS ACPI table for the USB controler so that the IOMMU driver would
keep these regions mapped.  But I have never seen those regions defined
by any BIOS of an AMD machine, so this is probably the cause why you are
seeing these IO page faults.

But this doesn't explain the GPU faults, though.


Joerg

--
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: MNT_DETACH and mount namespace issue

[Eric W. Biederman]

Richard Weinberger  writes:

> Am 01.08.2014 17:44, schrieb Ram Pai:
>> On Fri, Aug 01, 2014 at 12:17:13AM +0200, Richard Weinberger wrote:
>>> Am 30.07.2014 22:46, schrieb Richard Weinberger:
 Am 30.07.2014 15:59, schrieb Richard Weinberger:
> If we use the plain list_empty() we might not see the
> hlist_del_init_rcu() and therefore miss one member of the
> list.
>
> It fixes the following issue:
> $ unshare -m /usr/bin/sleep 1 &
> $ mkdir -p foo/proc
> $ mount -t proc none foo/proc
> $ mount -t binfmt_misc none foo/proc/sys/fs/binfmt_misc
> $ umount -l foo/proc
> $ rmdir foo/proc
> rmdir: failed to remove ‘foo/proc’: Device or resource busy

 Although my fix was wrong, the issue is real, it seems to exist for a very 
 long
 time. Just was able to reproduce it on 2.6.32.
 Please note that you need a shared root subtree to trigger the issue.
 i.e. mount --shared /
 Maybe this is why nobody noticed it so far as only systemd distros
 have the root subtree shared by default.

 I hit the issue on openSUSE 13.1 where an application creates a chroot 
 environment
 and then lazy umounts /proc.
 It happened on very few machines. An analysis showed that only boxes with 
 an OpenVPN tunnel
 were affected. This did not make any sense until I discovered that the 
 OpenVPN systemd
 service file has set "PrivateTmp=true". This setting creates
 a mount namespace for the said service...

 In __propagate_umount() the following piece of code is interesting:

  /*
  * umount the child only if the child has no
  * other children
  */
 if (child && list_empty(>mnt_mounts)) {
 hlist_del_init_rcu(>mnt_hash);
 hlist_add_before_rcu(>mnt_hash, >mnt_hash);
 }

 child->mnt_mounts is non-empty for the "proc" although the "binfmt_misc"
 subtree was removed.
 I'm not sure whether this is only one more symptom or the main culprit.
>>>
>>> CC'ing Ram Pai.
>>>
>>> Ram, you are the author of the said code. Can you please explain why we 
>>> need that
>>> list_empty() check?
>>> To my (limited) understanding of VFS, the following change should be fine 
>>> to fix the issue:
>> 
>> We had made a rule then, that busy vfsmounts cannot be lazily unmounted
>> **implicitly**. Propagated unmounts are implicit unmounts, and if such
>> implicit vfsmounts have child-mounts than obviously they are busy, and
>> hence they cannot be lazy-unmounted implicitly.
>> 
>> the list_empty() is checking for no child-mounts on the vfsmount before
>> letting it unmount.
>> 
>> We did not want a bunch of mounts disappear without the users knowledge.
>> Hence we made the above rule.
>> 
>> Al Viro, will have more insights into this.
>
> Hmm, with the root subtree shared by default this policy will be problematic 
> and
> lead to problems.
> As I observe on openSUSE 13.1.
>
> Al, what do you think?

I have a pending patchset that causes the rmdir to cause all of the
mounts to go away.  It has passed review and has not been merged only
because of stack overflow concerns (which I have not had time to fully
address).

Sigh.  It badly breaks unix semantics for rmdir unlink with no mounts in
the local namespace to fail, and it introduces as denial of service
attack from unprivielged users.

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

Re: [PATCH 4/5] x86: entry_64.S: always allocate complete "struct pt_regs"

[H. Peter Anvin]

On 08/01/2014 03:11 PM, Denys Vlasenko wrote:
>>
>> Could you please try to see if there is a measurable change in the
>> latency of a trivial syscall?
> 
> Will do.
> Something along the lines of "how long does it take to execute two
> gazillions of getppid()?"
> 

Something like that, yes, but you have to run enough data points so you
can determine if the difference is statistically significant or just noise.

-hpa

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

[tip:x86/apic] x86/apic/vsmp: Make is_vsmp_box() static

[tip-bot for H. Peter Anvin]

Commit-ID:  5e3bf215f4f2efc0af89e6dbc5da789744aeb5d7
Gitweb: http://git.kernel.org/tip/5e3bf215f4f2efc0af89e6dbc5da789744aeb5d7
Author: H. Peter Anvin 
AuthorDate: Fri, 1 Aug 2014 14:47:56 -0700
Committer:  H. Peter Anvin 
CommitDate: Fri, 1 Aug 2014 15:09:45 -0700

x86/apic/vsmp: Make is_vsmp_box() static

Since checkin

411cf9ee2946 x86, vsmp: Remove is_vsmp_box() from apic_is_clustered_box()

... is_vsmp_box() is only used in vsmp_64.c and does not have any
header file declaring it, so make it explicitly static.

Reported-by: kbuild test robot 
Cc: Shai Fultheim 
Cc: Oren Twaig 
Link: 
http://lkml.kernel.org/r/1404036068-11674-1-git-send-email-o...@scalemp.com
Signed-off-by: H. Peter Anvin 
---
 arch/x86/kernel/vsmp_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/vsmp_64.c b/arch/x86/kernel/vsmp_64.c
index b99b9ad..ee22c1d 100644
--- a/arch/x86/kernel/vsmp_64.c
+++ b/arch/x86/kernel/vsmp_64.c
@@ -152,7 +152,7 @@ static void __init detect_vsmp_box(void)
is_vsmp = 1;
 }
 
-int is_vsmp_box(void)
+static int is_vsmp_box(void)
 {
if (is_vsmp != -1)
return is_vsmp;
@@ -166,7 +166,7 @@ int is_vsmp_box(void)
 static void __init detect_vsmp_box(void)
 {
 }
-int is_vsmp_box(void)
+static int is_vsmp_box(void)
 {
return 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 4/5] x86: entry_64.S: always allocate complete "struct pt_regs"

[Denys Vlasenko]

On Fri, Aug 1, 2014 at 8:35 PM, H. Peter Anvin  wrote:
> On 08/01/2014 07:48 AM, Denys Vlasenko wrote:
>>
>> Patch was run-tested: 64-bit executables, 32-bit executables,
>> strace works.
>>
>
> Could you please try to see if there is a measurable change in the
> latency of a trivial syscall?

Will do.
Something along the lines of "how long does it take to execute two
gazillions of getppid()?"

I'll send v2 shortly - I just figured out what was this mysterious
dance with allocating "not-quite-full struct pt_regs" on interrupt path:
It is intended to make nested interrupts to have better
backtraces. I broke that by this patch, v2 will have this feature retained.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/3] mm/hugetlb: take refcount under page table lock in follow_huge_pmd()

[Naoya Horiguchi]

On Fri, Aug 01, 2014 at 02:53:58PM -0700, Andrew Morton wrote:
> On Fri,  1 Aug 2014 13:37:41 -0400 Naoya Horiguchi 
>  wrote:
> 
> > We have a race condition between move_pages() and freeing hugepages,
> > where move_pages() calls follow_page(FOLL_GET) for hugepages internally
> > and tries to get its refcount without preventing concurrent freeing.
> > This race crashes the kernel, so this patch fixes it by moving FOLL_GET
> > code for hugepages into follow_huge_pmd() with taking the page table lock.
> > 
> > This patch passes the following test. And libhugetlbfs test shows no
> > regression.
> > 
> > ...
> 
> How were these bugs discovered?  Are we missing some Reported-by's?

Hugh pointed out this a few months ago, so I should have added his
Reported-by tag.

> > --- mmotm-2014-07-22-15-58.orig/include/linux/hugetlb.h
> > +++ mmotm-2014-07-22-15-58/include/linux/hugetlb.h
> > @@ -101,6 +101,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, 
> > unsigned long address,
> > pmd_t *pmd, int write);
> >  struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
> > pud_t *pud, int write);
> > +struct page *follow_huge_pmd_lock(struct vm_area_struct *vma,
> > +   unsigned long address, pmd_t *pmd, int flags);
> >  int pmd_huge(pmd_t pmd);
> >  int pud_huge(pud_t pmd);
> >  unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
> >
> > ...
> >
> > --- mmotm-2014-07-22-15-58.orig/mm/hugetlb.c
> > +++ mmotm-2014-07-22-15-58/mm/hugetlb.c
> > @@ -3687,6 +3687,33 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
> > address,
> >  
> >  #endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
> >  
> > +struct page *follow_huge_pmd_lock(struct vm_area_struct *vma,
> > +   unsigned long address, pmd_t *pmd, int flags)
> 
> Some documentation here wouldn't hurt.  Why it exists, what it does. 
> And especially: any preconditions to calling it (ie: locking).
> 
> > +{
> > +   struct page *page;
> > +   spinlock_t *ptl;
> > +
> > +   if (flags & FOLL_GET)
> > +   ptl = huge_pte_lock(hstate_vma(vma), vma->vm_mm, (pte_t *)pmd);
> > +
> > +   page = follow_huge_pmd(vma->vm_mm, address, pmd, flags & FOLL_WRITE);
> > +
> > +   if (flags & FOLL_GET) {
> > +   /*
> > +* Refcount on tail pages are not well-defined and
> > +* shouldn't be taken. The caller should handle a NULL
> > +* return when trying to follow tail pages.
> > +*/
> > +   if (PageHead(page))
> > +   get_page(page);
> > +   else
> > +   page = NULL;
> > +   spin_unlock(ptl);
> > +   }
> > +
> > +   return page;
> > +}
> > +
> >  #ifdef CONFIG_MEMORY_FAILURE
> 
> I can't find an implementation of follow_huge_pmd() which actually uses
> the fourth argument "write".  Zap?

OK, I'll post it later.

Thanks,
Naoya Horiguchi

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

Re: [PATCH v2 1/3] mm/hugetlb: take refcount under page table lock in follow_huge_pmd()

[Andrew Morton]

On Fri,  1 Aug 2014 13:37:41 -0400 Naoya Horiguchi  
wrote:

> We have a race condition between move_pages() and freeing hugepages,
> where move_pages() calls follow_page(FOLL_GET) for hugepages internally
> and tries to get its refcount without preventing concurrent freeing.
> This race crashes the kernel, so this patch fixes it by moving FOLL_GET
> code for hugepages into follow_huge_pmd() with taking the page table lock.
> 
> This patch passes the following test. And libhugetlbfs test shows no
> regression.
> 
> ...

How were these bugs discovered?  Are we missing some Reported-by's?

> --- mmotm-2014-07-22-15-58.orig/include/linux/hugetlb.h
> +++ mmotm-2014-07-22-15-58/include/linux/hugetlb.h
> @@ -101,6 +101,8 @@ struct page *follow_huge_pmd(struct mm_struct *mm, 
> unsigned long address,
>   pmd_t *pmd, int write);
>  struct page *follow_huge_pud(struct mm_struct *mm, unsigned long address,
>   pud_t *pud, int write);
> +struct page *follow_huge_pmd_lock(struct vm_area_struct *vma,
> + unsigned long address, pmd_t *pmd, int flags);
>  int pmd_huge(pmd_t pmd);
>  int pud_huge(pud_t pmd);
>  unsigned long hugetlb_change_protection(struct vm_area_struct *vma,
>
> ...
>
> --- mmotm-2014-07-22-15-58.orig/mm/hugetlb.c
> +++ mmotm-2014-07-22-15-58/mm/hugetlb.c
> @@ -3687,6 +3687,33 @@ follow_huge_pud(struct mm_struct *mm, unsigned long 
> address,
>  
>  #endif /* CONFIG_ARCH_WANT_GENERAL_HUGETLB */
>  
> +struct page *follow_huge_pmd_lock(struct vm_area_struct *vma,
> + unsigned long address, pmd_t *pmd, int flags)

Some documentation here wouldn't hurt.  Why it exists, what it does. 
And especially: any preconditions to calling it (ie: locking).

> +{
> + struct page *page;
> + spinlock_t *ptl;
> +
> + if (flags & FOLL_GET)
> + ptl = huge_pte_lock(hstate_vma(vma), vma->vm_mm, (pte_t *)pmd);
> +
> + page = follow_huge_pmd(vma->vm_mm, address, pmd, flags & FOLL_WRITE);
> +
> + if (flags & FOLL_GET) {
> + /*
> +  * Refcount on tail pages are not well-defined and
> +  * shouldn't be taken. The caller should handle a NULL
> +  * return when trying to follow tail pages.
> +  */
> + if (PageHead(page))
> + get_page(page);
> + else
> + page = NULL;
> + spin_unlock(ptl);
> + }
> +
> + return page;
> +}
> +
>  #ifdef CONFIG_MEMORY_FAILURE

I can't find an implementation of follow_huge_pmd() which actually uses
the fourth argument "write".  Zap?

Ditto for follow_huge_pud().

--
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] smpboot: add missing get_online_cpus() when register

[David Rientjes]

On Thu, 31 Jul 2014, Lai Jiangshan wrote:

> If the smpboot_register_percpu_thread() is called after 
> smpboot_create_threads()
> but before __cpu_up(), the smpboot thread of the online-ing CPU is not 
> created,
> and it results a bug.  So we use get_online_cpus() to prevent it.
> 

Do you have an example of the bug to include?  Maintainers are going to 
need to understand the implications of the problem before the 
sta...@kernel.org annotation is warranted.

> smpboot_unregister_percpu_thread() travels all possible CPU, it doesn't need
> get_online_cpus() which is removed in the patch.
> 
> CC: Thomas Gleixner 
> Cc: Rusty Russell 
> Cc: Peter Zijlstra 
> Cc: Srivatsa S. Bhat 
> CC: sta...@kernel.org
> Signed-off-by: Lai Jiangshan 
> ---
>  kernel/smpboot.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index eb89e18..8adab87 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struct 
> smp_hotplug_thread *plug_thread)
>   unsigned int cpu;
>   int ret = 0;
>  
> + get_online_cpus();
>   mutex_lock(_threads_lock);
>   for_each_online_cpu(cpu) {
>   ret = __smpboot_create_thread(plug_thread, cpu);
> @@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struct 
> smp_hotplug_thread *plug_thread)
>   list_add(_thread->list, _threads);
>  out:
>   mutex_unlock(_threads_lock);
> + put_online_cpus();
>   return ret;
>  }

I think the {get,put}_online_cpus() pair should be nested inside the 
smpboot_threads_lock for better lock ordering since not all cases 
smpboot_threads_lock will require it.

That way, you can also do put_online_cpus() before 
smpboot_destroy_threads(), which you have already proven doesn't need it:

@@ -280,14 +280,17 @@ int smpboot_register_percpu_thread(struct 
smp_hotplug_thread *plug_thread)
int ret = 0;
 
mutex_lock(_threads_lock);
+   get_online_cpus();
for_each_online_cpu(cpu) {
ret = __smpboot_create_thread(plug_thread, cpu);
if (ret) {
+   put_online_cpus();
smpboot_destroy_threads(plug_thread);
goto out;
}
smpboot_unpark_thread(plug_thread, cpu);
}
+   put_online_cpus();
list_add(_thread->list, _threads);
 out:
mutex_unlock(_threads_lock);

>  EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
> @@ -303,11 +305,9 @@ EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
>   */
>  void smpboot_unregister_percpu_thread(struct smp_hotplug_thread *plug_thread)
>  {
> - get_online_cpus();
>   mutex_lock(_threads_lock);
>   list_del(_thread->list);
>   smpboot_destroy_threads(plug_thread);
>   mutex_unlock(_threads_lock);
> - put_online_cpus();
>  }
>  EXPORT_SYMBOL_GPL(smpboot_unregister_percpu_thread);

This makes sense.
--
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] mm, oom: remove unnecessary check for NULL zonelist

[David Rientjes]

On Fri, 1 Aug 2014, Johannes Weiner wrote:

> > > out_of_memory() wants the zonelist that was used during allocation,
> > > not just the random first node's zonelist that's simply picked to
> > > serialize page fault OOM kills system-wide.
> > > 
> > > This would even change how panic_on_oom behaves for page fault OOMs
> > > (in a completely unpredictable way) if we get CONSTRAINED_CPUSET.
> > > 
> > > This change makes no sense to me.
> > > 
> > 
> > Allocations during fault will be constrained by the cpuset's mems, if we 
> > are oom then why would we panic when panic_on_oom == 1?
> 
> Can you please address the concerns I raised?
> 

I see one concern: that panic_on_oom == 1 will not trigger on pagefault 
when constrained by cpusets.  To address that, I'll state that, since 
cpuset-constrained allocations are the allocation context for pagefaults,
panic_on_oom == 1 should not trigger on pagefault when constrained by 
cpusets.

> And please describe user-visible changes in the changelog.
> 

Ok, Andrew please annotate the changelog for 
mm-oom-remove-unnecessary-check-for-null-zonelist.patch by including:

This also causes panic_on_oom == 1 to not panic the machine when the 
pagefault is constrained by the mems of current's cpuset.  That behavior 
agrees with the semantics of the sysctl in Documentation/sysctl/vm.txt.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] Add __designated_init, wrapping __attribute__((designated_init))

[josh]

On Fri, Aug 01, 2014 at 01:45:29PM -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2014 16:47:23 -0700 Josh Triplett  
> wrote:
> 
> > GCC 4.10 and newer, and Sparse, supports
> > __attribute__((designated_init)), which marks a structure as requiring
> > a designated initializer rather than a positional one.  This helps
> > reduce churn and errors when used with _ops structures and similar
> > structures designed for future extension.
> > 
> > Add a wrapper __designated_init, which turns into
> > __attribute__((designated_init)) for Sparse or sufficiently new GCC.
> > Enable the corresponding warning as an error.
> > 
> > The following semantic patch can help mark structures containing
> > function pointers as requiring designated initializers:
> > 
> > @@
> > identifier I, f;
> > type T;
> > @@
> > 
> > struct I {
> > ...
> > T (*f)(...);
> > ...
> > }
> > + __designated_init
> 
> hm, dunno about this.
> 
> I think that the kernel should always use designated initializers
> everywhere.  Perhaps there are a few special cases where positional
> initializers provide a superior result but I'm not sure where those
> might be.
> 
> In which case what we should do is to teach sparse to warn about
> positional initializers then go fix them all up (lol).  After that
> process is complete, this __designated_init tag would be just noise.
> 
> To support this perhaps a sparse tag would be needed which says
> "positional initializers are OK here".  This way we're adding the
> annotation to the exceptional cases, not to the common cases.

Before submitting this series, I actually used coccinelle to
automatically add __designated_init to nearly a thousand structures
(just in include/linux/ alone), and did a build with that.  Even just
adding it to structures with function pointers, some cases produce a
*huge* number of warnings.  I think it might make sense to work our way
through those warnings, but "go fix them all up" would be a gargantuan
effort.  (For an idea of scale: there were more warnings about
positional initialization than everything other warning combined, by a
substantial factor, and that's just from changing a few hundred
structures.)

I'm not at all convinced that we want to universally enforce designated
initializers *yet*.  They make sense for _ops structures and other
structures that contain function pointers (which is a small subset), but
for many other structures they just add a large amount of noise to
initialization.  If we could say "automatically add __designated_init to
structures matching these criteria", that could work, but "all
structures" not so much.  (For instance, a structure with a single
field, or two fields of incompatible types with an intuitive ordering,
doesn't gain much value from designated initialization.)

Now, some cases may make sense to fix despite the large volume.  For
instance, many users of dmi_system_id initialize it positionally, and
shouldn't; I've already written patches for quite a few of them, with
many more to go.  But, for instance, obs_kernel_param seems much less
worthwhile to fix, because we shouldn't add any new instances of it, and
we likely won't ever extend it.  The value in fixing this issue mostly
comes not with the current code, but with future changes to the
structure.  (And, as always happens with this kind of change, we'll end
up with a few holdouts who don't want to change their code, which will
stop us from eliminating the warning completely.)

In the course of introducing this change, we'll end up fixing a large
number of positional init warnings.  If in the course of doing so, it
starts making sense to enforce it everywhere, it seems easy enough to
sed away all the __designated_init tags.  But in terms of noise, the
actual additions of __designated_init will pale in comparison to the
patches fixing positional initializers.

Finally, by migrating over to this incrementally, structure by
structure, we can safely make the warning an error, which we could not
do if we applied it to every struct immediately.

- Josh Triplett
--
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: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Jirka Hladky]

On 08/01/2014 10:46 PM, Davidlohr Bueso wrote:

On Thu, 2014-07-31 at 18:16 +0200, Jirka Hladky wrote:

Peter, I'm seeing regressions for

SINGLE SPECjbb instance for number of warehouses being the same as total
number of cores in the box.

Example: 4 NUMA node box, each CPU has 6 cores => biggest regression is
for 24 warehouses.

By looking at your graph, that's around a 10% difference.

So I'm not seeing anywhere near as bad a regression on a 80-core box.
Testing single with 80 warehouses, I get:

tip/master baseline:
677476.36 bops
705826.70 bops
704870.87 bops
681741.20 bops
707014.59 bops

Avg: 695385.94 bops

tip/master + patch (NUMA_SCALE/8 variant):
698242.66 bops
693873.18 bops
707852.28 bops
691785.96 bops
747206.03 bopsthis

Avg: 707792.022 bops

So both these are pretty similar, however, when reverting, on avg we
increase the amount of bops a mere ~4%:

tip/master + reverted:
778416.02 bops
702602.62 bops
712557.32 bops
713982.90 bops
783300.36 bops

Avg: 738171.84 bops

Are there perhaps any special specjbb options you are using?



I see the regression only on this box. It has 4 "Ivy Bridge-EX" Xeon 
E7-4890 v2 CPUs.


http://ark.intel.com/products/75251
http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors#.22Ivy_Bridge-EX.22_.2822_nm.29_Expandable_2

Please rerun the test on box with Ivy Bridge CPUs. It seems that older 
CPU generations are not affected.


Thanks
Jirka


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

[GIT PULL] Staging driver fixes for 3.16-rc8

[Greg KH]

The following changes since commit 9a3c4145af32125c5ee39c0272662b47307a8323:

  Linux 3.16-rc6 (2014-07-20 21:04:16 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.16-rc8

for you to fetch changes up to 4aa0abed3a2a11b7d71ad560c1a3e7631c5a31cd:

  staging: vt6655: Fix disassociated messages every 10 seconds (2014-07-24 
15:10:42 -0700)


Staging driver bugfixes for 3.16-rc8

Here are some tiny staging driver bugfixes that I've had in my tree for
the past week that resolve some reported issues.  Nothing major at all,
but it would be good to get them merged for 3.16-rc8 or -final.

Signed-off-by: Greg Kroah-Hartman 


Greg Kroah-Hartman (1):
  Merge tag 'iio-fixes-for-3.16e' of git://git.kernel.org/.../jic23/iio 
into staging-linus

Jes Sorensen (1):
  staging: rtl8723au: rtw_resume(): release semaphore before exit on error

Lars-Peter Clausen (1):
  iio: buffer: Fix demux table creation

Malcolm Priestley (2):
  staging: vt6655: Fix Warning on boot handle_irq_event_percpu.
  staging: vt6655: Fix disassociated messages every 10 seconds

Peter Meerwald (2):
  iio:bma180: Fix scale factors to report correct acceleration units
  iio:bma180: Missing check for frequency fractional part

 drivers/iio/accel/bma180.c  | 8 +---
 drivers/iio/industrialio-buffer.c   | 2 +-
 drivers/staging/rtl8723au/os_dep/usb_intf.c | 4 +++-
 drivers/staging/vt6655/bssdb.c  | 2 +-
 drivers/staging/vt6655/device_main.c| 7 +--
 5 files changed, 15 insertions(+), 8 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: scheduler crash on Power

[Sukadev Bhattiprolu]

Dietmar Eggemann [dietmar.eggem...@arm.com] wrote:
| > ltcbrazos2-lp07 login: [  181.915974] [ cut here ]
| > [  181.915991] WARNING: at ../kernel/sched/core.c:5881
| 
| This warning indicates the problem. One of the struct sched_domains does
| not have it's groups member set.
| 
| And its happening during a rebuild of the sched domain hierarchy, not
| during the initial build.
| 
| You could run your system with the following patch-let (on top of
| https://lkml.org/lkml/2014/7/17/288)  w/ and w/o the perf related
| patches (w/ CONFIG_SCHED_DEBUG enabled).
| 
| @@ -5882,6 +5882,9 @@ static void init_sched_groups_capacity(int cpu,
| struct sched_domain *sd)
|  {
| struct sched_group *sg = sd->groups;
| 
| +#ifdef CONFIG_SCHED_DEBUG
| +   printk("sd name: %s span: %pc\n", sd->name, sd->span);
| +#endif
| WARN_ON(!sg);
| 
| do {
| 
| This will show if the rebuild of the sched domain hierarchy happens on
| both systems and hopefully indicate for which sched_domain the
| sd->groups is not set.

Thanks for the patch. It appears that the NUMA sched domain does not
have the sd->groups set - snippet of the error (with your patch and
Peter's patch)

[  181.914494] build_sched_groups: got group c6da with cpus: 
[  181.914498] build_sched_groups: got group c000dd83 with cpus: 
[  181.915234] sd name: SMT span: 8-15
[  181.915239] sd name: DIE span: 0-7
[  181.915242] sd name: NUMA span: 0-15
[  181.915250] [ cut here ]
[  181.915253] WARNING: at ../kernel/sched/core.c:5891

Patched code:

5884 static void init_sched_groups_capacity(int cpu, struct 
sched_domain *sd)
5885 {
5886 struct sched_group *sg = sd->groups;
5887 
5888 #ifdef CONFIG_SCHED_DEBUG
5889 printk("sd name: %s span: %pc\n", sd->name, sd->span);
5890 #endif
5891 WARN_ON(!sg);

Complete log below.

I was able to bisect it down to this patch in the 24x7 patchset

https://lkml.org/lkml/2014/5/27/804

I replaced the kfree(page) calls in the patch with
kmem_cache_free(hv_page_cache, page).

The problem sems to disappear if the call to create_events_from_catalog()
in hv_24x7_init() is skipped. I am continuing to debug the 24x7 patch.

While the patched kernel often crashes before the first ssh into it,
the unpatched kernel has been stable through multiple kernel builds.

Are there any scheduler specific tests I can run on the unpatched kernel ?

Sukadev

Complete log:

OF stdout device is: /vdevice/vty@3000
Preparing to boot Linux version 3.16.0-rc7-24x7-dbg+ 
(r...@ltcbrazos2-lp07.austin.ibm.com) (gcc version 4.8.2 20140120 (Red Hat 
4.8.2-16) (GCC) ) #38 SMP Fri Aug 1 12:14:18 EDT 2014
Detected machine type: 0101
Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
Calling ibm,client-architecture-support... done
command line: BOOT_IMAGE=/vmlinux-3.16.0-rc7-24x7-dbg+ 
root=UUID=e72c49fa-e137-43ff-ab41-44f3124572eb ro vconsole.keymap=us 
rd.lvm.lv=rhel_ltcbrazos2-lp07/root rd.lvm.lv=rhel_ltcbrazos2-lp07/swap 
crashkernel=auto vconsole.font=latarcyrheb-sun16
memory layout at init:
  memory_limit :  (16 MB aligned)
  alloc_bottom : 0a5f
  alloc_top: 1000
  alloc_top_hi : 1000
  rmo_top  : 1000
  ram_top  : 1000
instantiating rtas at 0x0ee2... done
prom_hold_cpus: skipped
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0a60 -> 0x0a6016d4
Device tree struct  0x0a61 -> 0x0a64
Calling quiesce...
returning from prom_init
[0.00] crashkernel: memory value expected
[0.00] Using pSeries machine description
[0.00] Page sizes from device-tree:
[0.00] base_shift=12: shift=12, sllp=0x, avpnm=0x, 
tlbiel=1, penc=0
[0.00] base_shift=12: shift=16, sllp=0x, avpnm=0x, 
tlbiel=1, penc=7
[0.00] base_shift=12: shift=24, sllp=0x, avpnm=0x, 
tlbiel=1, penc=56
[0.00] base_shift=16: shift=16, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=1
[0.00] base_shift=16: shift=24, sllp=0x0110, avpnm=0x, 
tlbiel=1, penc=8
[0.00] base_shift=24: shift=24, sllp=0x0100, avpnm=0x0001, 
tlbiel=0, penc=0
[0.00] base_shift=34: shift=34, sllp=0x0120, avpnm=0x07ff, 
tlbiel=0, penc=3
[0.00] Using 1TB segments
[0.00] kvm_cma: CMA: reserved 256 MiB
[0.00] Found initrd at 0xc9a0:0xca5ebcf8
[0.00] bootconsole [udbg0] enabled
[0.00] Partition configured for 32 cpus.
[0.00] CPU maps initialized for 8 threads per core
 -> smp_release_cpus()
spinning_secondaries = 15
 <- smp_release_cpus()
[0.00] Starting Linux PPC64 #38 SMP Fri Aug 1 12:14:18 EDT 2014
[0.00] 

Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[Saravana Kannan]

On 08/01/2014 12:54 PM, Stephen Boyd wrote:

On 08/01/14 12:43, Prarit Bhargava wrote:


On 08/01/2014 03:36 PM, Stephen Boyd wrote:

On 08/01/14 12:15, Prarit Bhargava wrote:

On 08/01/2014 01:18 PM, Stephen Boyd wrote:

On 08/01/14 03:27, Prarit Bhargava wrote:

Can you send me the test and the trace of the deadlock?  I'm not creating it 
with:


This was with conservative as the default, and switching to ondemand

# cd /sys/devices/system/cpu/cpu2/cpufreq
# ls
affected_cpus  scaling_available_governors
conservative   scaling_cur_freq
cpuinfo_cur_freq   scaling_driver
cpuinfo_max_freq   scaling_governor
cpuinfo_min_freq   scaling_max_freq
cpuinfo_transition_latency scaling_min_freq
related_cpus   scaling_setspeed
scaling_available_frequencies  stats
# cat conservative/down_threshold
20
# echo ondemand > scaling_governor

Thanks Stephen,

There's obviously a difference in our .configs.  I have a global conservative
directory, ie) /sys/devices/system/cpu/cpufreq/conservative instead of a per-cpu
governor file.

ie) what are your .config options for CPUFREQ?

Mine are:

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

Is there some other config option I have to set?

I have the same options. The difference is that my driver has a governor
per policy. That's set with the CPUFREQ_HAVE_GOVERNOR_PER_POLICY flag.
If I remove that flag I can't trigger the lockdep splat anymore with
this sequence and your patch.

I see -- so you're seeing this on arm then?  If so, let me know so I can reserve
one to work on :)



I only have ARM to test on. You can set this flag in your cpufreq driver
if you have independently scaling CPU frequencies, so it isn't
necessarily an ARM thing.



Sorry, forgot to mention this in the earlier email. But yeah, this is a 
totally SW feature. You should be able to enable this flag in your driver.


-Saravana

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

Good evening

[Monica Suwayd]

--
Hello
Good evening, I'm Monica Suwayd I would have like to have some
discussion with you. If you don't mind. Please let me know if my
letter is welcome. Regards Monica Suwayd
--
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 v5 04/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Andreas Färber]

Hi Doug,

Am 01.08.2014 22:28, schrieb Doug Anderson:
> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
>> exynos5250-cros-common.dtsi had an empty /chosen node.
>> Fill in exemplary boot arguments.
>>
>> Signed-off-by: Andreas Färber 
>> ---
>>  v5: New
>>  Cleanup for /chosen node moved into -snow.dts.
>>
>>  arch/arm/boot/dts/exynos5250-snow.dts | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index 7680d5e03fb3..c4b0c73c736d 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -27,6 +27,7 @@
>> };
>>
>> chosen {
>> +   bootargs = "console=tty1";
> 
> As mentioned earlier, I don't think this is a particularly useful
> change.  Just this boot argument is not enough to boot with anyway, so
> listing it doesn't really help anyone.  In theory you could make some
> assertion about what the "most popular" boot device and filesystem is,
> but it seems unlikely to cover the majority of the cases.
> 
> I won't NAK this change myself, but I certainly won't push for it.

This patch should be entirely optional.

I believe you said it wasn't necessary because the bootloader supplies
it. My point is that someone needs to know what to put into the bootargs
(setenv / boot.scr / uEnv.txt) - knowing whether it's ttySAC3 vs.
ttySAC2 vs. ttyS0 etc. has been pretty handy for me. In this case, Snow
and Spring use an identical console, so not sure if it might be tty2 or
something elsewhere?

My question of what to use for linux,stdout-path (which was elsewhere
mentioned as successor to bootargs in that regard) remained unanswered.
Should it point to the dp-controller node or what?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 v5 07/10] ARM: dts: Clean up exynos5250-arndale

[Tomasz Figa]

Just wanted to report one issue unrelated to your changes I spotted
while reviewing this patch. See below.

On 01.08.2014 06:54, Andreas Färber wrote:
> Use the new style of referencing inherited nodes, use symbolic names,
> tidy indentation and reorder includes.
> 
> Goal is the alignment of all exynos5250 based device trees for comparison.

[snip]

> - fimd: fimd@1440 {
> - status = "okay";
> - display-timings {
> - native-mode = <>;
> - timing0: timing@0 {
> - /* 2560x1600 DP panel */
> - clock-frequency = <5>;

This apparently makes little sense as I doubt anybody would be willing
to run a DP panel with refresh rate of 0,012 Hz...

Anyway, your patch just moves it, so this is just an unrelated report.

Best regards,
Tomasz
--
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 v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

[Tomasz Figa]

On 01.08.2014 22:54, Andreas Färber wrote:
> Doug,
> 
> Am 01.08.2014 22:33, schrieb Doug Anderson:
>> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
>>> Spring uses a different GPIO, so this is not a generic SoC piece.
>>>
>>> Suggested-by: Tomasz Figa 
>>> Signed-off-by: Andreas Färber 
>>> ---
>>>  v5: New (Tomasz Figa)
>>>  Frees dp_hpd for Spring.
>>>
>>>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
>>>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
>>>  arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
>>>  3 files changed, 16 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
>>> b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>>> index 886cfca044ac..ed0e5230514b 100644
>>> --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>>> @@ -581,13 +581,6 @@
>>> samsung,pin-pud = <0>;
>>> samsung,pin-drv = <0>;
>>> };
>>> -
>>> -   dp_hpd: dp_hpd {
>>> -   samsung,pins = "gpx0-7";
>>> -   samsung,pin-function = <3>;
>>> -   samsung,pin-pud = <0>;
>>> -   samsung,pin-drv = <0>;
>>> -   };
>>> };
>>>
>>> pinctrl@1340 {
>>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
>>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> index aaa055ac0fe3..5d30fe1dcda4 100644
>>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>>> @@ -414,3 +414,12 @@
>>> };
>>> };
>>>  };
>>> +
>>> +_0 {
>>> +   dp_hpd: dp_hpd {
>>> +   samsung,pins = "gpx0-7";
>>> +   samsung,pin-function = <3>;
>>> +   samsung,pin-pud = <0>;
>>> +   samsung,pin-drv = <0>;
>>> +   };
>>> +};
>>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>>> b/arch/arm/boot/dts/exynos5250-snow.dts
>>> index c4b0c73c736d..a9a2f2743794 100644
>>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>>> @@ -547,6 +547,13 @@
>>>  };
>>>
>>>  _0 {
>>> +   dp_hpd: dp_hpd {
>>> +   samsung,pins = "gpx0-7";
>>> +   samsung,pin-function = <3>;
>>> +   samsung,pin-pud = <0>;
>>> +   samsung,pin-drv = <0>;
>>> +   };
>>> +
>>
>> NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
>> Pin function 3 is special function.  This pin _is_ the hot plug detect
>> pin for display port.  When it's set as special function 3 it goes
>> straight into the hot plug logic of the display port controller.
>>
>> Spring may have had its reasons to detect hot plug events on a GPIO
>> instead of using this pin, but that doesn't make this pin any less the
>> "hot plug pin".
> 
> Please advise how to handle it then: Should there be two different
> pinctrl entries (if so, how should it be named?), 

IMHO this is the right way. Just name the GPIO variant dp_hpd_gpio.

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

Re: [PATCH v2 1/2] printk: Add function to return log buffer address and size

[Andrew Morton]

On Thu, 31 Jul 2014 16:00:06 +0530 Vasant Hegde 
 wrote:

> Platforms like IBM Power Systems supports service processor
> assisted dump. It provides interface to add memory region to
> be captured when system is crashed.
> 
> During initialization/running we can add kernel memory region
> to be collected.
> 
> Presently we don't have a way to get the log buffer base address
> and size. This patch adds support to return log buffer address
> and size.
> 
> ...
>
> --- a/include/linux/printk.h
> +++ b/include/linux/printk.h
> @@ -10,6 +10,9 @@
>  extern const char linux_banner[];
>  extern const char linux_proc_banner[];
>  
> +extern void *get_log_buf_addr(void);
> +extern u32 get_log_buf_len(void);
> +
>  static inline int printk_get_level(const char *buffer)
>  {
>   if (buffer[0] == KERN_SOH_ASCII && buffer[1]) {
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 13e839d..4049f7b 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -270,6 +270,18 @@ static char __log_buf[__LOG_BUF_LEN] 
> __aligned(LOG_ALIGN);
>  static char *log_buf = __log_buf;
>  static u32 log_buf_len = __LOG_BUF_LEN;
>  
> +/* Return log buffer address */
> +void *get_log_buf_addr(void)
> +{
> + return log_buf;
> +}
> +
> +/* Return log buffer size */
> +u32 get_log_buf_len(void)
> +{
> + return log_buf_len;
> +}
> +

This is the v1 patch.  The names are the same and get_log_buf_addr() still
returns void*.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

[Andreas Färber]

Doug,

Am 01.08.2014 22:33, schrieb Doug Anderson:
> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
>> Spring uses a different GPIO, so this is not a generic SoC piece.
>>
>> Suggested-by: Tomasz Figa 
>> Signed-off-by: Andreas Färber 
>> ---
>>  v5: New (Tomasz Figa)
>>  Frees dp_hpd for Spring.
>>
>>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
>>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
>>  arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
>>  3 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
>> b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>> index 886cfca044ac..ed0e5230514b 100644
>> --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
>> @@ -581,13 +581,6 @@
>> samsung,pin-pud = <0>;
>> samsung,pin-drv = <0>;
>> };
>> -
>> -   dp_hpd: dp_hpd {
>> -   samsung,pins = "gpx0-7";
>> -   samsung,pin-function = <3>;
>> -   samsung,pin-pud = <0>;
>> -   samsung,pin-drv = <0>;
>> -   };
>> };
>>
>> pinctrl@1340 {
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index aaa055ac0fe3..5d30fe1dcda4 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -414,3 +414,12 @@
>> };
>> };
>>  };
>> +
>> +_0 {
>> +   dp_hpd: dp_hpd {
>> +   samsung,pins = "gpx0-7";
>> +   samsung,pin-function = <3>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +};
>> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
>> b/arch/arm/boot/dts/exynos5250-snow.dts
>> index c4b0c73c736d..a9a2f2743794 100644
>> --- a/arch/arm/boot/dts/exynos5250-snow.dts
>> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
>> @@ -547,6 +547,13 @@
>>  };
>>
>>  _0 {
>> +   dp_hpd: dp_hpd {
>> +   samsung,pins = "gpx0-7";
>> +   samsung,pin-function = <3>;
>> +   samsung,pin-pud = <0>;
>> +   samsung,pin-drv = <0>;
>> +   };
>> +
> 
> NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
> Pin function 3 is special function.  This pin _is_ the hot plug detect
> pin for display port.  When it's set as special function 3 it goes
> straight into the hot plug logic of the display port controller.
> 
> Spring may have had its reasons to detect hot plug events on a GPIO
> instead of using this pin, but that doesn't make this pin any less the
> "hot plug pin".

Please advise how to handle it then: Should there be two different
pinctrl entries (if so, how should it be named?), or should spring
override the generic entry? As I reported, 3.8 has only one dp-hpd
pinctrl entry, so I dropped the dp-hpd-gpio naming.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 v9 00/22] Support ext4 on NV-DIMMs

[Ross Zwisler]

On Fri, 2014-08-01 at 09:27 -0400, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> One of the primary uses for NV-DIMMs is to expose them as a block device
> and use a filesystem to store files on the NV-DIMM.  While that works,
> it currently wastes memory and CPU time buffering the files in the page
> cache.  We have support in ext2 for bypassing the page cache, but it
> has some races which are unfixable in the current design.  This series
> of patches rewrite the underlying support, and add support for direct
> access to ext4.
> 
> This iteration of the patchset rebases to 3.16-rc7 and makes substantial
> changes based on feedback from Jan Kara, Boaz Harrosh and Kirill Shutemov:
> 
>  - Fixes a double-unlock on i_mmap_mutex
>  - Switch the order of calling delete_from_page_cache() and
>unmap_mapping_range() to match the truncate path
>  - Make dax_mkwrite a macro (Kirill)
>  - Drop vm_replace_mixed(); instead call unmap_mapping_range() before calling
>vm_insert_mixed() (Kirill)
>  - Avoid lock inversion between i_mmap_mutex and transaction start (Jan)
>  - Move alignment & length checks into bdev_direct_access() (Boaz)
>  - Fix bugs in COW code; unfortunately this means reintroducing the knowledge
>that the i_mmap_mutex protects PFNs to the core MM code.
> 
> Jan Kara (1):
>   ext4: Avoid lock inversion between i_mmap_mutex and transaction start
> 
> Matthew Wilcox (20):
>   axonram: Fix bug in direct_access
>   Change direct_access calling convention
>   Fix XIP fault vs truncate race
>   Allow page fault handlers to perform the COW
>   Introduce IS_DAX(inode)
>   Add copy_to_iter(), copy_from_iter() and iov_iter_zero()
>   Replace XIP read and write with DAX I/O
>   Replace ext2_clear_xip_target with dax_clear_blocks
>   Replace the XIP page fault handler with the DAX page fault handler
>   Replace xip_truncate_page with dax_truncate_page
>   Replace XIP documentation with DAX documentation
>   Remove get_xip_mem
>   ext2: Remove ext2_xip_verify_sb()
>   ext2: Remove ext2_use_xip
>   ext2: Remove xip.c and xip.h
>   Remove CONFIG_EXT2_FS_XIP and rename CONFIG_FS_XIP to CONFIG_FS_DAX
>   ext2: Remove ext2_aops_xip
>   Get rid of most mentions of XIP in ext2
>   xip: Add xip_zero_page_range
>   brd: Rename XIP to DAX
> 
> Ross Zwisler (1):
>   ext4: Add DAX functionality
> 
>  Documentation/filesystems/Locking  |   3 -
>  Documentation/filesystems/dax.txt  |  91 +++
>  Documentation/filesystems/ext4.txt |   2 +
>  Documentation/filesystems/xip.txt  |  68 --
>  arch/powerpc/sysdev/axonram.c  |  19 +-
>  drivers/block/Kconfig  |  13 +-
>  drivers/block/brd.c|  26 +-
>  drivers/s390/block/dcssblk.c   |  21 +-
>  fs/Kconfig |  21 +-
>  fs/Makefile|   1 +
>  fs/block_dev.c |  34 +++
>  fs/dax.c   | 476 
>  fs/exofs/inode.c   |   1 -
>  fs/ext2/Kconfig|  11 -
>  fs/ext2/Makefile   |   1 -
>  fs/ext2/ext2.h |  10 +-
>  fs/ext2/file.c |  45 +++-
>  fs/ext2/inode.c|  38 +--
>  fs/ext2/namei.c|  13 +-
>  fs/ext2/super.c|  53 ++--
>  fs/ext2/xip.c  |  91 ---
>  fs/ext2/xip.h  |  26 --
>  fs/ext4/ext4.h |   6 +
>  fs/ext4/file.c |  53 +++-
>  fs/ext4/indirect.c |  18 +-
>  fs/ext4/inode.c|  65 +++--
>  fs/ext4/namei.c|  10 +-
>  fs/ext4/super.c|  39 ++-
>  fs/open.c  |   5 +-
>  include/linux/blkdev.h |   6 +-
>  include/linux/fs.h |  49 +++-
>  include/linux/mm.h |   1 +
>  include/linux/uio.h|   3 +
>  mm/Makefile|   1 -
>  mm/fadvise.c   |   6 +-
>  mm/filemap.c   |   6 +-
>  mm/filemap_xip.c   | 483 
> -
>  mm/iov_iter.c  | 237 --
>  mm/madvise.c   |   2 +-
>  mm/memory.c|  33 ++-
>  40 files changed, 1206 insertions(+), 881 deletions(-)
>  create mode 100644 Documentation/filesystems/dax.txt
>  delete mode 100644 Documentation/filesystems/xip.txt
>  create mode 100644 fs/dax.c
>  delete mode 100644 fs/ext2/xip.c
>  delete mode 100644 fs/ext2/xip.h
>  delete mode 100644 mm/filemap_xip.c

I've updated the master branch of PRD's GitHub repo
(https://github.com/01org/prd) so that it is Linus's tip + DAX v9 + PRD.

I've also added a patch to PRD to enable dynamic allocation of partition
numbers.

- Ross


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

Re: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Davidlohr Bueso]

On Fri, 2014-08-01 at 13:46 -0700, Davidlohr Bueso wrote:
> So both these are pretty similar, however, when reverting, on avg we
> increase the amount of bops a mere ~4%:
> 
> tip/master + reverted:

Just to be clear, this is reverting a43455a1d57.

--
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: [LKP] [sched/numa] a43455a1d57: +94.1% proc-vmstat.numa_hint_faults_local

[Davidlohr Bueso]

On Thu, 2014-07-31 at 18:16 +0200, Jirka Hladky wrote:
> Peter, I'm seeing regressions for
> 
> SINGLE SPECjbb instance for number of warehouses being the same as total 
> number of cores in the box.
> 
> Example: 4 NUMA node box, each CPU has 6 cores => biggest regression is 
> for 24 warehouses.

By looking at your graph, that's around a 10% difference.

So I'm not seeing anywhere near as bad a regression on a 80-core box.
Testing single with 80 warehouses, I get:

tip/master baseline:
677476.36 bops
705826.70 bops
704870.87 bops
681741.20 bops 
707014.59 bops

Avg: 695385.94 bops

tip/master + patch (NUMA_SCALE/8 variant):
698242.66 bops
693873.18 bops 
707852.28 bops
691785.96 bops 
747206.03 bopsthis 

Avg: 707792.022 bops

So both these are pretty similar, however, when reverting, on avg we
increase the amount of bops a mere ~4%:

tip/master + reverted:
778416.02 bops 
702602.62 bops 
712557.32 bops 
713982.90 bops
783300.36 bops

Avg: 738171.84 bops

Are there perhaps any special specjbb options you are using?

--
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/5] Add __designated_init, wrapping __attribute__((designated_init))

[Andrew Morton]

On Thu, 31 Jul 2014 16:47:23 -0700 Josh Triplett  wrote:

> GCC 4.10 and newer, and Sparse, supports
> __attribute__((designated_init)), which marks a structure as requiring
> a designated initializer rather than a positional one.  This helps
> reduce churn and errors when used with _ops structures and similar
> structures designed for future extension.
> 
> Add a wrapper __designated_init, which turns into
> __attribute__((designated_init)) for Sparse or sufficiently new GCC.
> Enable the corresponding warning as an error.
> 
> The following semantic patch can help mark structures containing
> function pointers as requiring designated initializers:
> 
> @@
> identifier I, f;
> type T;
> @@
> 
> struct I {
>   ...
>   T (*f)(...);
>   ...
> }
> + __designated_init

hm, dunno about this.

I think that the kernel should always use designated initializers
everywhere.  Perhaps there are a few special cases where positional
initializers provide a superior result but I'm not sure where those
might be.

In which case what we should do is to teach sparse to warn about
positional initializers then go fix them all up (lol).  After that
process is complete, this __designated_init tag would be just noise.

To support this perhaps a sparse tag would be needed which says
"positional initializers are OK here".  This way we're adding the
annotation to the exceptional cases, not to the common cases.


--
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 v5 03/10] ARM: dts: Clean up exynos5250-snow

[Andreas Färber]

Am 01.08.2014 22:24, schrieb Doug Anderson:
> Andreas,
> 
> On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
>> Use the new style of referencing inherited nodes and use symbolic names.
>> Reorder one pinctrl node in GPIO order.
>>
>> Goal is the alignment of all exynos5250 based device trees for comparison.
>>
>> Suggested-by: Doug Anderson 
>> Signed-off-by: Andreas Färber 
>> ---
>>  v4 -> v5:
>>  * Introduced labels to consistently use new referencing style (Tomasz)
>>  * Use IRQ_TYPE_* constants
>>  * Use some more GPIO_ACTIVE_*
>>
>>  v3 -> v4: Unchanged
>>
>>  v3: New (Doug Anderson)
>>
>>  arch/arm/boot/dts/exynos5250-snow.dts | 291 
>> +-
>>  arch/arm/boot/dts/exynos5250.dtsi |  20 +--
> 
> As much as possible it's nice to touch the main exynos dtsi file and
> specific board files in different patches.  Among other things it
> makes backporting the patch and resolving merge conflicts easier (if
> someone doesn't care about snow they could just pick up the main dtsi,
> for instance).
> 
> I'm not a total stickler and I'd love to see this land quickly to
> avoid conflicts, though...
> 
> 
>> +_clk {
>> +   samsung,pin-drv = <0>;
>> +};
>> +
>> +_cmd {
>> +   samsung,pin-pud = <3>;
>> +   samsung,pin-drv = <0>;
>> +};
>> +
>> +_bus4 {
> 
> Itty bitty bitty nit that "bus" sorts alphabetically above "clk".  ;)

True. I guess I just reused the original order from within pinctrl.

> Maybe Kukjin would be willing to sort these when he applies?
>
>
> Thank you for all your hard work on this one.  Things look MUCH MUCH
> nicer!  I did a pretty thorough review of your changes and it all
> looks good.
> 
> Reviewed-by: Doug Anderson 

I need to respin anyway for a .dtsi label, so I can factor this out
while at it.

Patches 1-2 could meanwhile already be applied by Kukjin.

Thanks,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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 v5 06/10] ARM: dts: Clean up exynos5250-smdk5250

[Doug Anderson]

Andreas,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
> Use the new style for referencing inherited nodes and use symbolic names.
>
> Goal is the alignment of all exynos5250 based device trees for comparison.
>
> Signed-off-by: Andreas Färber 
> ---
>  v5: New
>  Follow-up after adding dp_hpd pinctrl node new-style.

Since I NAKed that one, are you going to drop this patch?  It's
probably still a useful thing to do.

It sounds like you might be spinning?  ...if so I'll review it in the
next cycle...  Note: same feedback as before about splitting changes
to exynos5250.dtsi and actual board files...

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

Re: [PATCH v2 1/1] vfs: Respect MS_RDONLY at bind mount creation

[Richard Yao]

On 08/01/2014 03:20 PM, Mateusz Guzik wrote:
> On Fri, Aug 01, 2014 at 02:12:24PM -0400, Richard Yao wrote:
>> `mount -o bind,ro ...` suffers from a silent failure where the readonly
>> flag is ignored. The bind mount will be created rw whenever the target
>> is rw. Users typically workaround this by remounting readonly, but that
>> does not work when you want to define readonly bind mounts in fstab.
>> This is a major annoyance when dealing with recursive bind mounts
>> because the userland mount command does not expose the option to
>> recursively remount a subtree as readonly.
>>
>> Signed-off-by: Richard Yao 
>> ---
>>  fs/namespace.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/namespace.c b/fs/namespace.c
>> index 182bc41..0d23525 100644
>> --- a/fs/namespace.c
>> +++ b/fs/namespace.c
>> @@ -1827,11 +1827,12 @@ static bool has_locked_children(struct mount *mnt, 
>> struct dentry *dentry)
>>   * do loopback mount.
>>   */
>>  static int do_loopback(struct path *path, const char *old_name,
>> -int recurse)
>> +unsigned long flags)
>>  {
>>  struct path old_path;
>> -struct mount *mnt = NULL, *old, *parent;
>> +struct mount *mnt = NULL, *old, *parent, *m;
>>  struct mountpoint *mp;
>> +int recurse = flags & MS_REC;
>>  int err;
>>  if (!old_name || !*old_name)
>>  return -EINVAL;
>> @@ -1871,6 +1872,10 @@ static int do_loopback(struct path *path, const char 
>> *old_name,
>>  goto out2;
>>  }
>>  
>> +if (flags & MS_RDONLY)
>> +for (m = mnt; m; m = (recurse ? next_mnt(m, mnt) : NULL))
>> +mnt_make_readonly(m);
>> +
>>  mnt->mnt.mnt_flags &= ~MNT_LOCKED;
>>  
>>  err = graft_tree(mnt, parent, mp);
>> @@ -2444,7 +2449,8 @@ long do_mount(const char *dev_name, const char 
>> *dir_name,
>>  retval = do_remount(, flags & ~MS_REMOUNT, mnt_flags,
>>  data_page);
>>  else if (flags & MS_BIND)
>> -retval = do_loopback(, dev_name, flags & MS_REC);
>> +retval = do_loopback(, dev_name, flags & (MS_REC |
>> +   MS_RDONLY));
>>  else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>>  retval = do_change_type(, flags);
>>  else if (flags & MS_MOVE)
> 
> I don't really know this code, but have to ask.
> 
> Would not it be much better to pass down info about rdonly request to
> copy_tree/clone_mnt (perhaps CL_MOUNT_RDONLY flag or a separate flags
> argument) and handle it there?
> 
> This would avoid fishy-looking traversal before graft_tree, which even
> if correct should not be necessary.
> 

I have a nagging feeling that people doing backports will hate me for
adding a power of 2 plus 1 bit, but your suggestion makes this more
readable. I will send v3 after I finish my regression tests.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

[Doug Anderson]

Andreas,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
> Spring uses a different GPIO, so this is not a generic SoC piece.
>
> Suggested-by: Tomasz Figa 
> Signed-off-by: Andreas Färber 
> ---
>  v5: New (Tomasz Figa)
>  Frees dp_hpd for Spring.
>
>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
>  arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
>  arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
>  3 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> index 886cfca044ac..ed0e5230514b 100644
> --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> @@ -581,13 +581,6 @@
> samsung,pin-pud = <0>;
> samsung,pin-drv = <0>;
> };
> -
> -   dp_hpd: dp_hpd {
> -   samsung,pins = "gpx0-7";
> -   samsung,pin-function = <3>;
> -   samsung,pin-pud = <0>;
> -   samsung,pin-drv = <0>;
> -   };
> };
>
> pinctrl@1340 {
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index aaa055ac0fe3..5d30fe1dcda4 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -414,3 +414,12 @@
> };
> };
>  };
> +
> +_0 {
> +   dp_hpd: dp_hpd {
> +   samsung,pins = "gpx0-7";
> +   samsung,pin-function = <3>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +};
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index c4b0c73c736d..a9a2f2743794 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -547,6 +547,13 @@
>  };
>
>  _0 {
> +   dp_hpd: dp_hpd {
> +   samsung,pins = "gpx0-7";
> +   samsung,pin-function = <3>;
> +   samsung,pin-pud = <0>;
> +   samsung,pin-drv = <0>;
> +   };
> +

NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
Pin function 3 is special function.  This pin _is_ the hot plug detect
pin for display port.  When it's set as special function 3 it goes
straight into the hot plug logic of the display port controller.

Spring may have had its reasons to detect hot plug events on a GPIO
instead of using this pin, but that doesn't make this pin any less the
"hot plug pin".

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

Re: [PATCH v3 1/2] mm/highmem: make kmap cache coloring aware

[Max Filippov]

On Sat, Aug 2, 2014 at 12:10 AM, Andrew Morton
 wrote:
> On Fri, 25 Jul 2014 23:43:46 +0400 Max Filippov  wrote:
>
>> VIPT cache with way size larger than MMU page size may suffer from
>> aliasing problem: a single physical address accessed via different
>> virtual addresses may end up in multiple locations in the cache.
>> Virtual mappings of a physical address that always get cached in
>> different cache locations are said to have different colors.
>> L1 caching hardware usually doesn't handle this situation leaving it
>> up to software. Software must avoid this situation as it leads to
>> data corruption.
>>
>> One way to handle this is to flush and invalidate data cache every time
>> page mapping changes color. The other way is to always map physical page
>> at a virtual address with the same color. Low memory pages already have
>> this property. Giving architecture a way to control color of high memory
>> page mapping allows reusing of existing low memory cache alias handling
>> code.
>>
>> Provide hooks that allow architectures with aliasing cache to align
>> mapping address of high pages according to their color. Such architectures
>> may enforce similar coloring of low- and high-memory page mappings and
>> reuse existing cache management functions to support highmem.
>>
>> This code is based on the implementation of similar feature for MIPS by
>> Leonid Yegoshin .
>>
>
> It's worth mentioning that xtensa needs this.
>
> What is (still) missing from these changelogs is a clear description of
> the end-user visible effects.  Does it fix some bug?  If so what?  Is
> it a performace optimisation?  If so how much?  This info is the
> top-line reason for the patchset and should be presented as such.

Ok, let me try again.

>> --- a/mm/highmem.c
>> +++ b/mm/highmem.c
>> @@ -28,6 +28,9 @@
>>  #include 
>>  #include 
>>  #include 
>> +#ifdef CONFIG_HIGHMEM
>> +#include 
>> +#endif
>
> Should be unneeded - the linux/highmem.h inclusion already did this.

Ok, I'll drop it.

> Apart from that it all looks OK to me.  I'm assuming this is 3.17-rc1
> material, but I am unsure because of the missing end-user-impact info.
> If it's needed in earlier kernels then we can tag it for -stable
> backporting but again, the -stable team (ie: Greg) will want so see the
> justification for that backport.

It's not a fix, for xtensa it's a part of a new feature, so no need
for backporting.

-- 
Thanks.
-- Max
--
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: [ANNOUNCE] scsi patch queue tree updated

[James Bottomley]

On Fri, 2014-08-01 at 05:20 -0700, Christoph Hellwig wrote:
> I've pushed out updates to both the core-for-3.17 and drivers-for-3.17
> branches.

So I'm afraid we missed the last -next build on these, so they can't go
in with the early SCSI pull.  I'm open to doing one mid merge window,
but Linus tends not to like that.

James


--
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 v5 04/10] ARM: dts: Fill in bootargs for exynos5250-snow

[Doug Anderson]

Hi,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
> exynos5250-cros-common.dtsi had an empty /chosen node.
> Fill in exemplary boot arguments.
>
> Signed-off-by: Andreas Färber 
> ---
>  v5: New
>  Cleanup for /chosen node moved into -snow.dts.
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
> b/arch/arm/boot/dts/exynos5250-snow.dts
> index 7680d5e03fb3..c4b0c73c736d 100644
> --- a/arch/arm/boot/dts/exynos5250-snow.dts
> +++ b/arch/arm/boot/dts/exynos5250-snow.dts
> @@ -27,6 +27,7 @@
> };
>
> chosen {
> +   bootargs = "console=tty1";

As mentioned earlier, I don't think this is a particularly useful
change.  Just this boot argument is not enough to boot with anyway, so
listing it doesn't really help anyone.  In theory you could make some
assertion about what the "most popular" boot device and filesystem is,
but it seems unlikely to cover the majority of the cases.

I won't NAK this change myself, but I certainly won't push for it.

-Doug
--
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] Save command pool address of Scsi_Host

[James Bottomley]

On Fri, 2014-08-01 at 05:03 -0700, Christoph Hellwig wrote:
> On Fri, Aug 01, 2014 at 08:27:05AM +0200, jgr...@suse.com wrote:
> > From: Juergen Gross 
> > 
> > If a scsi host driver specifies .cmd_len in it's scsi_host_template, a 
> > driver's
> > private command pool is needed. scsi_find_host_cmd_pool() will locate it, 
> > but
> > scsi_alloc_host_cmd_pool() isn't saving the pool address in the host 
> > template.
> > 
> > This will result in an access error when the host is removed.
> > 
> > Avoid the problem by saving the address of a new allocated command pool 
> > where
> > it is expected.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Looks good, but minor nitpick below:
> 
> > +   if (shost->hostt->cmd_size)
> > +   shost->hostt->cmd_pool = pool;
> > +
> 
> 
> We already have a local hostt variable for the host template in this
> function, please use it.

Wait, that's not right at all.  There looks to be a thinko in the
command pool handling code.  We have both a cmd_pool in the host
structure and in the host template structure, but there's confusion
about which one we're supposed to be using.

The origin of confusion seems to be the reference counting in the pool
itself ... you want the same pool for all hosts, since they can only
have one cmd_size, but you want it created on first host use and
destroyed again on the last one.

If you take this patch, a host that attached, detaches and then attaches
a host will panic because it will use a freed pool structure.

This whole mess is created by the attempt to refcount the pools.  What's
wrong with simply creating the pool at init time and deleting it again
at module removal ... that way no refcounting and no bogus problems like
this (and we can delete the cmd_pool from the host).  The restriction
this would give is that cmd_size can only be set in the template, but
that seems to be the only safe use anyway, since any driver trying to
vary this in its host add routines will get unexpected results.

James


--
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 v5 03/10] ARM: dts: Clean up exynos5250-snow

[Doug Anderson]

Andreas,

On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber  wrote:
> Use the new style of referencing inherited nodes and use symbolic names.
> Reorder one pinctrl node in GPIO order.
>
> Goal is the alignment of all exynos5250 based device trees for comparison.
>
> Suggested-by: Doug Anderson 
> Signed-off-by: Andreas Färber 
> ---
>  v4 -> v5:
>  * Introduced labels to consistently use new referencing style (Tomasz)
>  * Use IRQ_TYPE_* constants
>  * Use some more GPIO_ACTIVE_*
>
>  v3 -> v4: Unchanged
>
>  v3: New (Doug Anderson)
>
>  arch/arm/boot/dts/exynos5250-snow.dts | 291 
> +-
>  arch/arm/boot/dts/exynos5250.dtsi |  20 +--

As much as possible it's nice to touch the main exynos dtsi file and
specific board files in different patches.  Among other things it
makes backporting the patch and resolving merge conflicts easier (if
someone doesn't care about snow they could just pick up the main dtsi,
for instance).

I'm not a total stickler and I'd love to see this land quickly to
avoid conflicts, though...


> +_clk {
> +   samsung,pin-drv = <0>;
> +};
> +
> +_cmd {
> +   samsung,pin-pud = <3>;
> +   samsung,pin-drv = <0>;
> +};
> +
> +_bus4 {

Itty bitty bitty nit that "bus" sorts alphabetically above "clk".  ;)
Maybe Kukjin would be willing to sort these when he applies?


Thank you for all your hard work on this one.  Things look MUCH MUCH
nicer!  I did a pretty thorough review of your changes and it all
looks good.

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

Re: [PATCH v2 2/2] perf tools: Default to python version 2

[Arnaldo Carvalho de Melo]

Em Tue, Jul 29, 2014 at 03:57:20PM +0900, Namhyung Kim escreveu:
> According to PEP 394 recommendation [1], it's more portable to use
> python2 rather than plain python to refer python binary version 2.
> 
> Since there're distros using python3 by default like Arch, and we
> don't support python3 (yet), it'd be better using python2 explicitly.
> 
> But older versions (prior to 2.7) seem not to provide python2 but just
> python.  Given that it's only old version, try python2 first and then
> fallback to python.  It'll ensure that it always points to python 2.x.

It should fallback, right?

[acme@fedora14 linux]$ ls -la /usr/bin/python2-config
ls: cannot access /usr/bin/python2-config: No such file or directory
[acme@fedora14 linux]$ ls -la /usr/bin/python-config
lrwxrwxrwx. 1 root root 16 Mar 25 09:43 /usr/bin/python-config -> 
python2.7-config
[acme@fedora14 linux]$ rpm -qf /usr/bin/python-config 
python-devel-2.7-8.fc14.1.x86_64
[acme@fedora14 linux]$ cat /etc/fedora-release 
Fedora release 14 (Laughlin)
[acme@fedora14 linux]$ 

[acme@fedora14 linux]$ time make O=/tmp/build/perf -C tools/perf install
make: Entering directory `/home/acme/git/linux/tools/perf'
  BUILD:   Doing 'make -j4' parallel build
config/Makefile:126: The path '/usr/bin/python2-config' is not executable.
config/Makefile:339: No libdw DWARF unwind found, Please install
elfutils-devel/libdw-dev >= 0.158 and/or set LIBDW_DIR
config/Makefile:481: Missing perl devel files. Disabling perl scripting
support, consider installing perl-ExtUtils-Embed
config/Makefile:512: No python-config tool was found
config/Makefile:512: Python support will not be built
 
> [1] https://www.python.org/dev/peps/pep-0394
> 
> Suggested-by: Thomas Ilsche 
> Tested-by: Thomas Ilsche 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/config/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index e05d8f99424d..60177278a357 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -121,8 +121,8 @@ ifdef PARSER_DEBUG
>  endif
>  
>  ifndef NO_LIBPYTHON
> -  override PYTHON := \
> -$(call get-executable-or-default,PYTHON,python)
> +  PYTHON2 := $(if $(call get-executable,python2),python2,python)
> +  override PYTHON := $(call get-executable-or-default,PYTHON,$(PYTHON2))
>override PYTHON_CONFIG := \
>  $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON)-config)
>  
> -- 
> 2.0.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 v2] PM / sleep: Rename symbols, functions and variables related to sleep

[Pavel Machek]

On Fri 2014-08-01 16:33:12, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The names of several symbols, data types, functions and variables
> related to system sleep states are confusing and don't reflect the
> real behavior of those states correctly.
> 
> First of all, there generally are two sleep states that require
> platform support and one sleep state that is platform-independent.
> The first two of them are currently known as MEM and STANDBY,
> although these names really only match what the states do on full
> hardware ACPI compliant systems.  MEM in particular is supposed
> to mean "suspend-to-RAM", but in fact it means "the deepest sleep
> state available with platform support".  The definition of STANDBY
> is even more arbitrary.
> 
> Moreover, the remaining sleep state that doesn't need platform support
> is currently called FREEZE, which leads to double confusion with the
> process freezer (used during transitions to all sleep states) and
> with the freeze stage of processing devices during hibernation.
> 
> For these reasons, rename the PM_SUSPEND_MEM, PM_SUSPEND_STANDBY
> and PM_SUSPEND_FREEZE symbols to PM_SUSPEND_DEEP, PM_SUSPEND_SHALLOW
> and PM_IDLE_SLEEP, respectively, everywhere and rename data types,
> functions and variables related to those states to match the new names
> of the symbols.
> 
> This is a semi-mechanical replacement of names and it should not lead
> to any functional differences.
> 
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

[PATCH -mm v6 09/13] memcg: cleanup preparation for page table walk

[Naoya Horiguchi]

pagewalk.c can handle vma in itself, so we don't have to pass vma via
walk->private. And both of mem_cgroup_count_precharge() and
mem_cgroup_move_charge() do for each vma loop themselves, but now it's
done in pagewalk.c, so let's clean up them.

ChangeLog v4:
- use walk_page_range() instead of walk_page_vma() with for loop.

Signed-off-by: Naoya Horiguchi 
---
 mm/memcontrol.c | 49 -
 1 file changed, 16 insertions(+), 33 deletions(-)

diff --git mmotm-2014-07-30-15-57.orig/mm/memcontrol.c 
mmotm-2014-07-30-15-57/mm/memcontrol.c
index dc35886a1c89..e8b44a50ef1a 100644
--- mmotm-2014-07-30-15-57.orig/mm/memcontrol.c
+++ mmotm-2014-07-30-15-57/mm/memcontrol.c
@@ -5876,7 +5876,7 @@ static int mem_cgroup_count_precharge_pte_range(pmd_t 
*pmd,
unsigned long addr, unsigned long end,
struct mm_walk *walk)
 {
-   struct vm_area_struct *vma = walk->private;
+   struct vm_area_struct *vma = walk->vma;
pte_t *pte;
spinlock_t *ptl;
 
@@ -5902,20 +5902,13 @@ static int mem_cgroup_count_precharge_pte_range(pmd_t 
*pmd,
 static unsigned long mem_cgroup_count_precharge(struct mm_struct *mm)
 {
unsigned long precharge;
-   struct vm_area_struct *vma;
 
+   struct mm_walk mem_cgroup_count_precharge_walk = {
+   .pmd_entry = mem_cgroup_count_precharge_pte_range,
+   .mm = mm,
+   };
down_read(>mmap_sem);
-   for (vma = mm->mmap; vma; vma = vma->vm_next) {
-   struct mm_walk mem_cgroup_count_precharge_walk = {
-   .pmd_entry = mem_cgroup_count_precharge_pte_range,
-   .mm = mm,
-   .private = vma,
-   };
-   if (is_vm_hugetlb_page(vma))
-   continue;
-   walk_page_range(vma->vm_start, vma->vm_end,
-   _cgroup_count_precharge_walk);
-   }
+   walk_page_range(0, ~0UL, _cgroup_count_precharge_walk);
up_read(>mmap_sem);
 
precharge = mc.precharge;
@@ -6051,7 +6044,7 @@ static int mem_cgroup_move_charge_pte_range(pmd_t *pmd,
struct mm_walk *walk)
 {
int ret = 0;
-   struct vm_area_struct *vma = walk->private;
+   struct vm_area_struct *vma = walk->vma;
pte_t *pte;
spinlock_t *ptl;
enum mc_target_type target_type;
@@ -6151,7 +6144,10 @@ put: /* get_mctgt_type() gets the 
page */
 
 static void mem_cgroup_move_charge(struct mm_struct *mm)
 {
-   struct vm_area_struct *vma;
+   struct mm_walk mem_cgroup_move_charge_walk = {
+   .pmd_entry = mem_cgroup_move_charge_pte_range,
+   .mm = mm,
+   };
 
lru_add_drain_all();
 retry:
@@ -6167,24 +6163,11 @@ static void mem_cgroup_move_charge(struct mm_struct *mm)
cond_resched();
goto retry;
}
-   for (vma = mm->mmap; vma; vma = vma->vm_next) {
-   int ret;
-   struct mm_walk mem_cgroup_move_charge_walk = {
-   .pmd_entry = mem_cgroup_move_charge_pte_range,
-   .mm = mm,
-   .private = vma,
-   };
-   if (is_vm_hugetlb_page(vma))
-   continue;
-   ret = walk_page_range(vma->vm_start, vma->vm_end,
-   _cgroup_move_charge_walk);
-   if (ret)
-   /*
-* means we have consumed all precharges and failed in
-* doing additional charge. Just abandon here.
-*/
-   break;
-   }
+   /*
+* When we have consumed all precharges and failed in doing
+* additional charge, the page walk just aborts.
+*/
+   walk_page_range(0, ~0UL, _cgroup_move_charge_walk);
up_read(>mmap_sem);
 }
 
-- 
1.9.3

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

[PATCH -mm v6 07/13] numa_maps: fix typo in gather_hugetbl_stats

[Naoya Horiguchi]

Just doing s/gather_hugetbl_stats/gather_hugetlb_stats/g, this makes code
grep-friendly.

Signed-off-by: Naoya Horiguchi 
Acked-by: Kirill A. Shutemov 
---
 fs/proc/task_mmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git mmotm-2014-07-30-15-57.orig/fs/proc/task_mmu.c 
mmotm-2014-07-30-15-57/fs/proc/task_mmu.c
index e4c6cdb9647b..8b1eb1617445 100644
--- mmotm-2014-07-30-15-57.orig/fs/proc/task_mmu.c
+++ mmotm-2014-07-30-15-57/fs/proc/task_mmu.c
@@ -1340,7 +1340,7 @@ static int gather_pte_stats(pmd_t *pmd, unsigned long 
addr,
return 0;
 }
 #ifdef CONFIG_HUGETLB_PAGE
-static int gather_hugetbl_stats(pte_t *pte, unsigned long hmask,
+static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask,
unsigned long addr, unsigned long end, struct mm_walk *walk)
 {
struct numa_maps *md;
@@ -1359,7 +1359,7 @@ static int gather_hugetbl_stats(pte_t *pte, unsigned long 
hmask,
 }
 
 #else
-static int gather_hugetbl_stats(pte_t *pte, unsigned long hmask,
+static int gather_hugetlb_stats(pte_t *pte, unsigned long hmask,
unsigned long addr, unsigned long end, struct mm_walk *walk)
 {
return 0;
@@ -1391,7 +1391,7 @@ static int show_numa_map(struct seq_file *m, void *v, int 
is_pid)
 
md->vma = vma;
 
-   walk.hugetlb_entry = gather_hugetbl_stats;
+   walk.hugetlb_entry = gather_hugetlb_stats;
walk.pmd_entry = gather_pte_stats;
walk.private = md;
walk.mm = mm;
-- 
1.9.3

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

[PATCH -mm v6 10/13] arch/powerpc/mm/subpage-prot.c: use walk->vma and walk_page_vma()

[Naoya Horiguchi]

We don't have to use mm_walk->private to pass vma to the callback function
because of mm_walk->vma. And walk_page_vma() is useful if we walk over a
single vma.

Signed-off-by: Naoya Horiguchi 
Acked-by: Kirill A. Shutemov 
---
 arch/powerpc/mm/subpage-prot.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git mmotm-2014-07-30-15-57.orig/arch/powerpc/mm/subpage-prot.c 
mmotm-2014-07-30-15-57/arch/powerpc/mm/subpage-prot.c
index 6c0b1f5f8d2c..fa9fb5b4c66c 100644
--- mmotm-2014-07-30-15-57.orig/arch/powerpc/mm/subpage-prot.c
+++ mmotm-2014-07-30-15-57/arch/powerpc/mm/subpage-prot.c
@@ -134,7 +134,7 @@ static void subpage_prot_clear(unsigned long addr, unsigned 
long len)
 static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
  unsigned long end, struct mm_walk *walk)
 {
-   struct vm_area_struct *vma = walk->private;
+   struct vm_area_struct *vma = walk->vma;
split_huge_page_pmd(vma, addr, pmd);
return 0;
 }
@@ -163,9 +163,7 @@ static void subpage_mark_vma_nohuge(struct mm_struct *mm, 
unsigned long addr,
if (vma->vm_start >= (addr + len))
break;
vma->vm_flags |= VM_NOHUGEPAGE;
-   subpage_proto_walk.private = vma;
-   walk_page_range(vma->vm_start, vma->vm_end,
-   _proto_walk);
+   walk_page_vma(vma, _proto_walk);
vma = vma->vm_next;
}
 }
-- 
1.9.3

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

Re: [PATCH 1/2] perf tools: Ensure --symfs ends with '/'

[Arnaldo Carvalho de Melo]

Em Fri, Aug 01, 2014 at 08:38:02AM +0900, Namhyung Kim escreveu:
> Hi Arnaldo,
> 
> On Thu, 31 Jul 2014 09:26:21 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jul 31, 2014 at 01:25:52PM +0900, Namhyung Kim escreveu:
> >> Are you still against my approach - adding '/' at the end of the symfs
> >> string itself?  It seems that mine is simpler and shorter.

> > Yes, I am.

> > We are not just concatenating two strings, we are joining two path
> > components.

> > I think it is more clear and elegant to do it as python os.path.join()
> > does.

> Then I think you also need to care about trailing and leading '/' in the
> components so that, say, joining '/home/' and '/namhyung/' can result in
> '/home/namhyung/' not '/home///namhyung/'.

Well, "/home/namhyung/" is the same as "/home///namhyung/" for POSIX:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266

So, when we can easily avoid it, no use to have a sequence of slashes,
but otherwise it is harmless.
 
> Btw, it seems like python's os.path.join() just use latter if it's an
> absolute path.
> 
>   $ python
>   Python 2.7.3 (default, Jul 24 2012, 10:05:38) 
>   [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
>   Type "help", "copyright", "credits" or "license" for more information.
>   >>> import os.path
>   >>> os.path.join('/home/', '/namhyung/')
>   '/namhyung/'

Interesting, wonder what is the rationale for that or if this is a bug.

- Arnaldo
--
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] arch: tile: kernel: setup.c: Cleaning up missing null-terminate in conjunction with strncpy

[Chris Metcalf]

On 7/26/2014 10:04 AM, Rickard Strandqvist wrote:

Replacing strncpy with strlcpy to avoid strings that lacks null terminate.

Signed-off-by: Rickard Strandqvist 
---
  arch/tile/kernel/setup.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/tile/kernel/setup.c b/arch/tile/kernel/setup.c
index 112abab..1af7d19 100644
--- a/arch/tile/kernel/setup.c
+++ b/arch/tile/kernel/setup.c
@@ -1087,7 +1087,7 @@ static int __init setup_initramfs_file(char *str)
  {
if (str == NULL)
return -EINVAL;
-   strncpy(initramfs_file, str, sizeof(initramfs_file) - 1);
+   strlcpy(initramfs_file, str, sizeof(initramfs_file));
set_initramfs_file = 1;
  
  	return 0;


Thanks for the patch (this and the one for mpipe.c).  In general I'd rather
check the argument length and return a suitable error rather than using
strlcpy or strncpy to cause a corrupted partial string result.  I've done
this for the examples you pointed to (which I think is everything in arch/tile)
and I'll push those changes up.

--
Chris Metcalf, Tilera Corp.
http://www.tilera.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/