RE: [Intel-wired-lan] [PATCH v5] ixgbe: Add module parameter to disable VLAN filter

[Hiroshi Shimamoto]

> On 05/21/2015 06:10 AM, Hiroshi Shimamoto wrote:
> > From: Hiroshi Shimamoto 
> >
> > Introduce module parameter "disable_hw_vlan_filter" to disable HW VLAN
> > filter on ixgbe module load.
> >
> >  From the hardware limitation, there are only 64 VLAN entries for HW VLAN
> > filter, and it leads to limit the number of VLANs up to 64 among PF and
> > VFs. For SDN/NFV case, we need to handle unlimited VLAN packets on VF.
> > In such case, every VLAN packet can be transmitted to each VF.
> >
> > When we try to make VLAN devices on VF, the 65th VLAN registration fails
> > and never be able to receive a packet with that VLAN tag.
> > If we do the below command on VM, ethX.65 to ethX.100 cannot be created.
> ># for i in `seq 1 100`; do \
> >  ip link add link ethX name ethX.$i type vlan id $i; done
> >
> > There is a capability to disable HW VLAN filter and that makes all VLAN
> > tagged packets can be transmitted to every VFs. After VLAN filter stage,
> > unicast packets are transmitted to VF which has the MAC address same as
> > the transmitting packet.
> >
> > With this patch and "disable_hw_vlan_filter=1", we can use unlimited
> > number of VLANs on VF.
> >
> > Disabling HW VLAN filter breaks some NIC features such as DCB and FCoE.
> > DCB and FCoE are disabled when HW VLAN filter is disabled by this module
> > parameter.
> > Because of that reason, the administrator has to know that before turning
> > off HW VLAN filter.
> 
> You might also want to note that it makes the system susceptible to
> broadcast/multicast storms since it eliminates any/all VLAN isolation.
> So a broadcast or multicast packet on one VLAN is received on ALL
> interfaces regardless of their VLAN configuration. In addition the
> current VF driver is likely to just receive the packet as untagged, see
> ixgbevf_process_skb_fields().  As a result one or two VFs can bring the
> entire system to a crawl by saturating the PCIe bus via
> broadcast/multicast traffic since there is nothing to prevent them from
> talking to each other over VLANs that are no longer there.

that's right.

On the other hand, an untagged packet is not isolated,
doesn't it same broadcast/multicast storm on untagged network?

> 
> For the sake of backwards compatibility I would say that a feature like
> this should be mutually exclusive with SR-IOV as well since it will
> cause erratic behavior.  The VF will receive requests from all VLANs
> thinking the traffic is untagged, and then send replies back to VLAN 0
> even though that isn't where the message originated.

Sorry, I couldn't catch the above part.
Could you explain a bit more?

thanks,
Hiroshi

> Until the VF issue
> is fixed this type of feature is a no-go.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: zynq: change error code for pinctrl_register failure

[Masahiro Yamada]

Hi Sören,

2015-05-27 3:37 GMT+09:00 Sören Brinkmann :
> On Tue, 2015-05-26 at 10:12AM +0200, Arnd Bergmann wrote:
>> On Tuesday 26 May 2015 13:18:29 Masahiro Yamada wrote:
>> > diff --git a/drivers/pinctrl/pinctrl-zynq.c 
>> > b/drivers/pinctrl/pinctrl-zynq.c
>> > index 04748a4..0ff653c 100644
>> > --- a/drivers/pinctrl/pinctrl-zynq.c
>> > +++ b/drivers/pinctrl/pinctrl-zynq.c
>> > @@ -1141,7 +1141,7 @@ static int zynq_pinctrl_probe(struct platform_device 
>> > *pdev)
>> >
>> > pctrl->pctrl = pinctrl_register(&zynq_desc, &pdev->dev, pctrl);
>> > if (!pctrl->pctrl)
>> > -   return -ENOMEM;
>> > +   return -EINVAL;
>> >
>> > platform_set_drvdata(pdev, pctrl);
>> >
>> >
>>
>> One choice seems as bad as the other to me ;-)
>>
>> Could we add a pinctrl_register_reason() variant that returns a meaningful
>> error code as ERR_PTR?
>
> I agree with Arnd. As long as we don't get a precise error code we can
> just keep the current one.

OK. Let's not do this way.


I will try pinctrl_register_reason().



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/16] ia64: fix up obsolete cpu function usage.

[Rusty Russell]

Tony Luck  writes:
> On Mon, Mar 2, 2015 at 3:35 AM, Rusty Russell  wrote:
>> Thanks to spatch, then a sweep for for_each_cpu_mask => for_each_cpu.
>>
>> Signed-off-by: Rusty Russell 
>
> I'm seeing a bunch of warnings building the ia64 tree:

Indeed, here's the forgotten fix sitting in my patch collection.

> Should cpumask_set_cpu() and friends specify a volatile argument???

It's weird, but it turns out hardly anyone wants that.

Cheers,
Rusty.

ia64: make cpu_callin_map non-volatile.

cpumask_test_cpu() doesn't take volatile, unlike the obsoleted
cpu_isset.  The only place ia64 really cares is the spin waiting for a
bit; udelay() is probably a barrier but insert rmb() to be sure.

Signed-off-by: Rusty Russell 

diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index 15051e9c2c6f..629975b56608 100644
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -127,7 +127,7 @@ int smp_num_siblings = 1;
 volatile int ia64_cpu_to_sapicid[NR_CPUS];
 EXPORT_SYMBOL(ia64_cpu_to_sapicid);
 
-static volatile cpumask_t cpu_callin_map;
+static cpumask_t cpu_callin_map;
 
 struct smp_boot_data smp_boot_data __initdata;
 
@@ -477,6 +477,7 @@ do_boot_cpu (int sapicid, int cpu, struct task_struct *idle)
for (timeout = 0; timeout < 10; timeout++) {
if (cpumask_test_cpu(cpu, &cpu_callin_map))
break;  /* It has booted */
+   rmb(); /* Make sure we re-read cpu_callin_map */
udelay(100);
}
Dprintk("\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] atm:he - Change 0 to false for bool type variable initialization.

[Shailendra Verma]

The variable sdh is bool type so initializing it with false value
instead of 0.

Signed-off-by: Shailendra Verma 
---
 drivers/atm/he.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 93dca2e..eb5bebc 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -116,8 +116,8 @@ static bool disable64;
 static short nvpibits = -1;
 static short nvcibits = -1;
 static short rx_skb_reserve = 16;
-static bool irq_coalesce = 1;
-static bool sdh = 0;
+static bool irq_coalesce = true;
+static bool sdh = false;
 
 /* Read from EEPROM =  0011b */
 static unsigned int readtab[] = {
-- 
1.7.9.5

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

Re: [PATCH 000/208] big x86 FPU code rewrite

[Bobby Powers]

Hello,

Ingo Molnar  wrote:
> Please have a look.

I've been running this for ~ 2 weeks.  I've only seen one issue, when
emerging mesa 10.5.6:

[May26 20:41] traps: aclocal-1.15[27452] trap invalid opcode
ip:7f6331031ab0 sp:7ffe73ece880 error:0 in
libperl.so.5.20.2[7f6330f18000+19e000]
[  +0.51] [ cut here ]
[  +0.05] WARNING: CPU: 0 PID: 27452 at
arch/x86/kernel/fpu/core.c:324 fpu__activate_stopped+0x8a/0xa0()
[  +0.02] Modules linked in: bnep iwlmvm btusb btintel bluetooth iwlwifi
[  +0.07] CPU: 0 PID: 27452 Comm: aclocal-1.15 Not tainted 4.1.0-rc5+ #163
[  +0.01] Hardware name: LENOVO 20BSCTO1WW/20BSCTO1WW, BIOS
N14ET24W (1.02 ) 10/27/2014
[  +0.01]  82172735 88017cccb998 81c4f534
8000
[  +0.02]   88017cccb9d8 8112611a
88017cccb9f8
[  +0.02]  88018e352400  
8801ef813a00
[  +0.02] Call Trace:
[  +0.04]  [] dump_stack+0x4f/0x7b
[  +0.03]  [] warn_slowpath_common+0x8a/0xc0
[  +0.03]  [] warn_slowpath_null+0x1a/0x20
[  +0.02]  [] fpu__activate_stopped+0x8a/0xa0
[  +0.02]  [] xfpregs_get+0x31/0x90
[  +0.01]  [] ? getreg+0xa9/0x130
[  +0.03]  [] elf_core_dump+0x531/0x1490
[  +0.03]  [] do_coredump+0xbd1/0xef0
[  +0.04]  [] ? try_to_wake_up+0x1f8/0x350
[  +0.02]  [] get_signal+0x38c/0x700
[  +0.03]  [] do_signal+0x28/0x760
[  +0.02]  [] ? do_trap+0x6d/0x150
[  +0.02]  [] ? vfs_read+0x11e/0x140
[  +0.03]  [] ? trace_hardirqs_off_thunk+0x17/0x19
[  +0.02]  [] do_notify_resume+0x70/0x80
[  +0.02]  [] retint_signal+0x42/0x80
[  +0.02] ---[ end trace 8baea2e2110d6ca1 ]---

This trace is a bit off - the path to fpu__activate_stopped from
elf_core_dump looks like:

fpu__activate_stopped
xfgregs_get
fill_thread_core_info
fill_note_info
elf_core_dump

It looks like the WARN_ON_FPU there is just invalid?  If we're
dumping, we have a valid case for curr == target.

I can reproduce this and I have the coredump, but I have no hope in
creating a test case out of this.

yours,
Bobby
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: swap: nfs: Sleeping function called from an rcu read section in nfs_swap_activate

[Jeff Layton]

On Tue, 26 May 2015 09:56:14 -0400
Jeff Layton  wrote:

> On Tue, 26 May 2015 15:20:46 +0200
> Jerome Marchand  wrote:
> 
> > 
> > Commit dad2b015 added an rcu read lock around the call to xs_swapper()
> > in nfs_activate()/deactivate(), which can sleep, thus raising a bug at
> > each swapon and swapoff over NFS.
> > I'm not sure if this is related or not, but swapoff also triggers the
> > WARN_ON(sk->sk_forward_alloc) in sk_clear_memalloc().
> > 
> > [  243.668067] ===
> > [  243.668665] [ INFO: suspicious RCU usage. ]
> > [  243.669293] 4.1.0-rc1-lock_stat-dbg-next-20150430+ #235 Not tainted
> > [  243.670301] ---
> > [  243.670905] include/linux/rcupdate.h:570 Illegal context switch in RCU 
> > read-side critical section!
> > [  243.672163] 
> > other info that might help us debug this:
> > 
> > [  243.673025] 
> > rcu_scheduler_active = 1, debug_locks = 0
> > [  243.673565] 2 locks held by swapon/1176:
> > [  243.673893]  #0:  (&sb->s_type->i_mutex_key#17){+.+.+.}, at: 
> > [] SyS_swapon+0x2b0/0x1000
> > [  243.674758]  #1:  (rcu_read_lock){..}, at: [] 
> > nfs_swap_activate+0x5/0x180 [nfs]
> > [  243.675591] 
> > stack backtrace:
> > [  243.675957] CPU: 0 PID: 1176 Comm: swapon Not tainted 
> > 4.1.0-rc1-lock_stat-dbg-next-20150430+ #235
> > [  243.676687] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [  243.677179]   ef88d841 88003327bcd8 
> > 818861f0
> > [  243.677854]   880078e38000 88003327bd08 
> > 8110d237
> > [  243.678514]   81c650e4 0268 
> > 880078e38000
> > [  243.679171] Call Trace:
> > [  243.679383]  [] dump_stack+0x4c/0x65
> > [  243.679811]  [] lockdep_rcu_suspicious+0xe7/0x120
> > [  243.680348]  [] ___might_sleep+0xaf/0x250
> > [  243.680815]  [] __might_sleep+0x4d/0x90
> > [  243.681279]  [] mutex_lock_nested+0x47/0x430
> > [  243.681762]  [] static_key_slow_inc+0x7c/0xc0
> > [  243.682264]  [] sk_set_memalloc+0x27/0x30
> > [  243.682736]  [] xs_swapper+0x54/0x60 [sunrpc]
> > [  243.683238]  [] nfs_swap_activate+0x93/0x180 [nfs]
> > [  243.683760]  [] ? nfs_swap_activate+0x5/0x180 [nfs]
> > [  243.684316]  [] SyS_swapon+0xad4/0x1000
> > [  243.684766]  [] ? syscall_return+0x16/0x59
> > [  243.685245]  [] system_call_fastpath+0x12/0x76
> > [  243.685743] BUG: sleeping function called from invalid context at 
> > kernel/locking/mutex.c:616
> > [  243.686439] in_atomic(): 1, irqs_disabled(): 0, pid: 1176, name: swapon
> > [  243.687053] INFO: lockdep is turned off.
> > [  243.687429] CPU: 0 PID: 1176 Comm: swapon Not tainted 
> > 4.1.0-rc1-lock_stat-dbg-next-20150430+ #235
> > [  243.688313] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [  243.688845]   ef88d841 88003327bd08 
> > 818861f0
> > [  243.689570]   880078e38000 88003327bd38 
> > 810df29c
> > [  243.690353]  8801 81c650e4 0268 
> > 
> > [  243.691057] Call Trace:
> > [  243.691315]  [] dump_stack+0x4c/0x65
> > [  243.691785]  [] ___might_sleep+0x18c/0x250
> > [  243.692306]  [] __might_sleep+0x4d/0x90
> > [  243.692807]  [] mutex_lock_nested+0x47/0x430
> > [  243.693346]  [] static_key_slow_inc+0x7c/0xc0
> > [  243.693887]  [] sk_set_memalloc+0x27/0x30
> > [  243.694416]  [] xs_swapper+0x54/0x60 [sunrpc]
> > [  243.694959]  [] nfs_swap_activate+0x93/0x180 [nfs]
> > [  243.695535]  [] ? nfs_swap_activate+0x5/0x180 [nfs]
> > [  243.696193]  [] SyS_swapon+0xad4/0x1000
> > [  243.696699]  [] ? syscall_return+0x16/0x59
> > [  243.697299]  [] system_call_fastpath+0x12/0x76
> > [  243.702101] Adding 524284k swap on /mnt/swapfile512.  Priority:-2 
> > extents:1 across:524284k FS
> > [  325.151350] BUG: sleeping function called from invalid context at 
> > kernel/locking/mutex.c:616
> > [  325.152688] in_atomic(): 1, irqs_disabled(): 0, pid: 1199, name: swapoff
> > [  325.153737] INFO: lockdep is turned off.
> > [  325.154457] CPU: 1 PID: 1199 Comm: swapoff Not tainted 
> > 4.1.0-rc1-lock_stat-dbg-next-20150430+ #235
> > [  325.156204] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [  325.157120]   a7682b83 88007ac3fce8 
> > 818861f0
> > [  325.158361]   880032434c00 88007ac3fd18 
> > 810df29c
> > [  325.159592]   81c650e4 0268 
> > 
> > [  325.160798] Call Trace:
> > [  325.161251]  [] dump_stack+0x4c/0x65
> > [  325.162071]  [] ___might_sleep+0x18c/0x250
> > [  325.163073]  [] __might_sleep+0x4d/0x90
> > [  325.163934]  [] mutex_lock_nested+0x47/0x430
> > [  325.164927]  [] atomic_dec_and_mutex_lock+0x4f/0x70
> > [  325.166020]  [] __static_key_slow_dec+0x27/0xc0
> > [  325.166942]  [] static_key_slow_dec+0x26/0x50
> > [  325.167955]  [] sk_clear_memalloc+0x2f/0x80
> > [  325.169075]  [] xs_swapper+0x41/0x60 [sun

[PATCH] staging:nvec: fix typo in comment

[Shailendra Verma]

Fix spelling error in comment in function tegra_nvec_remove.

Signed-off-by: Shailendra Verma 
---
 drivers/staging/nvec/nvec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 1bdc8d0..164634d 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -916,7 +916,7 @@ static int tegra_nvec_remove(struct platform_device *pdev)
nvec_unregister_notifier(nvec, &nvec->nvec_status_notifier);
cancel_work_sync(&nvec->rx_work);
cancel_work_sync(&nvec->tx_work);
-   /* FIXME: needs check wether nvec is responsible for power off */
+   /* FIXME: needs check whether nvec is responsible for power off */
pm_power_off = NULL;
 
return 0;
-- 
1.7.9.5

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

Re: Re: [RFC PATCH] suspend/resume performance improvement

[EunTaik Lee]

>> When a task that calls state_store() to suspend
>> the device has used up most of its time slice,
>> suspend sometimes take too long. (User noticeable)
>> 
>> Suspend/resume is a system wide operation.
>> So, instead of depending on a userspace task's time
>> slice, let kworker do the work to avoid a long wait
>> on the runqueue.

> All of that seems to duplicate the existing autosleep.c functionality.

Yes, the effect of using the kworker in autosleep will be same performance-wise.
But if a platform doesn't use the autosleep functionality then we still have 
the problem.
So doesn't it make sense to implement it for the autosleep-disabled use cases?

Re: [PATCH v3 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu, Baolu]

On 05/26/2015 10:50 PM, Felipe Balbi wrote:

Hi,

On Mon, May 25, 2015 at 02:24:00PM +0800, Lu, Baolu wrote:


On 05/23/2015 12:08 AM, David Cohen wrote:

Hi,

On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:

Phy drivers and the ulpi interface providers depend on the
registeration of the ulpi bus.  Ulpi registers the bus in
module_init(). This could result in a load order issue, i.e.

It's still not an issue :(
I'd say "unnecessary probe delays".

I managed to boot a kernel built from the top of Felipe's
remotes/origin/next branch under an Ubuntu environment
on Intel's Bay Trail tablet.

The same panic (as I found in the Android environment previously)
shows up as well. And if I replace module_init() with sys_initcall(),
the panic disappears.

the problem is something else... Moving things around in the init levels
is just a workaround for another issue. Seems like there's some missing
EPROBE_DEFER somewhere.


Yes, I agree.

Heikki, I assume "missing EPROBE_DEFER issue" will be fixed by
Sasha's patch. I will resend the patch with a new commit
message.

Thanks,
Baolu





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

Re: [RFC PATCH V2 1/2] x86/cpu hotplug: make apicid <--> cpuid mapping persistent

[Gu Zheng]

ping...

Any comments or suggestions are welcomed.

Regards,
Gu

On 05/14/2015 07:33 PM, Gu Zheng wrote:

> Yasuaki Ishimatsu found that with node online/offline, cpu<->node
> relationship is established. Because workqueue uses a info which
> was established at boot time, but it may be changed by node hotpluging.
> 
> Once pool->node points to a stale node, following allocation failure
> happens.
>   ==
>  SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
>   cache: kmalloc-192, object size: 192, buffer size: 192, default
> order:
> 1, min order: 0
>   node 0: slabs: 6172, objs: 259224, free: 245741
>   node 1: slabs: 3261, objs: 136962, free: 127656
>   ==
> 
> As the apicid <---> pxm and pxm <--> node relationship are persistent, then
> the apicid <--> node mapping is persistent, so the root cause is the
> cpu-id <-> lapicid mapping is not persistent (because the currently
> implementation always choose the first free cpu id for the new added cpu).
> If we can build persistent cpu-id <-> lapicid relationship, this problem
> will be fixed.
> 
> This patch tries to build the whole world mapping cpuid <-> apicid <-> pxm 
> <-> node
> for all possible processor at the boot, the detail implementation are 2 steps:
> 
> Step1: generate a logic cpu id for all the local apic (both enabled and 
> dsiabled)
>when register local apic
> Step2: map the cpu to the phyical node via an additional acpi ns walk for 
> processor.
> 
> Please refer to:
> https://lkml.org/lkml/2015/2/27/145
> https://lkml.org/lkml/2015/3/25/989
> for the previous discussion.
> ---
>  V2: rebase on latest upstream.
> ---
> 
> Signed-off-by: Gu Zheng 
> ---
>  arch/ia64/kernel/acpi.c   |   2 +-
>  arch/x86/include/asm/mpspec.h |   1 +
>  arch/x86/kernel/acpi/boot.c   |   8 ++-
>  arch/x86/kernel/apic/apic.c   |  73 -
>  arch/x86/mm/numa.c|  20 ---
>  drivers/acpi/acpi_processor.c |   2 +-
>  drivers/acpi/bus.c|   3 ++
>  drivers/acpi/processor_core.c | 121 
> ++
>  include/linux/acpi.h  |   2 +
>  9 files changed, 172 insertions(+), 60 deletions(-)
> 
> diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> index b1698bc..7db5563 100644
> --- a/arch/ia64/kernel/acpi.c
> +++ b/arch/ia64/kernel/acpi.c
> @@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
>   *  ACPI based hotplug CPU support
>   */
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
> -static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
> +int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
>  {
>  #ifdef CONFIG_ACPI_NUMA
>   /*
> diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
> index b07233b..db902d8 100644
> --- a/arch/x86/include/asm/mpspec.h
> +++ b/arch/x86/include/asm/mpspec.h
> @@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
>  #endif
>  
>  int generic_processor_info(int apicid, int version);
> +int __generic_processor_info(int apicid, int version, bool enabled);
>  
>  #define PHYSID_ARRAY_SIZEBITS_TO_LONGS(MAX_LOCAL_APIC)
>  
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index dbe76a1..c79115b 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
>   return -EINVAL;
>   }
>  
> - if (!enabled) {
> + if (!enabled)
>   ++disabled_cpus;
> - return -EINVAL;
> - }
>  
>   if (boot_cpu_physical_apicid != -1U)
>   ver = apic_version[boot_cpu_physical_apicid];
>  
> - return generic_processor_info(id, ver);
> + return __generic_processor_info(id, ver, enabled);
>  }
>  
>  static int __init
> @@ -726,7 +724,7 @@ static void __init acpi_set_irq_model_ioapic(void)
>  #ifdef CONFIG_ACPI_HOTPLUG_CPU
>  #include 
>  
> -static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
> +void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
>  {
>  #ifdef CONFIG_ACPI_NUMA
>   int nid;
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index dcb5285..7fbf2cb 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1977,7 +1977,38 @@ void disconnect_bsp_APIC(int virt_wire_setup)
>   apic_write(APIC_LVT1, value);
>  }
>  
> -int generic_processor_info(int apicid, int version)
> +/*
> + * Logic cpu number(cpuid) to local APIC id persistent mappings.
> + * Do not clear the mapping even if cpu hot removed.
> + * */
> +static int apicid_to_cpuid[] = {
> + [0 ... NR_CPUS - 1] = -1,
> +};
> +
> +/*
> + * Internal cpu id bits, set the bit once cpu present, and never clear it.
> + * */
> +static cpumask_t cpuid_mask = CPU_MASK_NONE;
> +
> +static int get_cpuid(int apicid)
> +{
> + int free_id, i;
> +
> + free_id = cpumask_next_zero(-1, &cpuid_mask);
> + if (free_id >=

[PATCH] lguest: fix out-by-one error in address checking.

[Rusty Russell]

This bug has been there since day 1; addresses in the top guest
physical page weren't considered valid.  You could map that page (the
check in check_gpte() is correct), but if a guest tried to put a
pagetable there we'd check that address manually when walking it, and
kill the guest.

Signed-off-by: Rusty Russell 
Cc: sta...@kernel.org

diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 7dc93aa004c8..312ffd3d0017 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -173,7 +173,7 @@ static void unmap_switcher(void)
 bool lguest_address_ok(const struct lguest *lg,
   unsigned long addr, unsigned long len)
 {
-   return (addr+len) / PAGE_SIZE < lg->pfn_limit && (addr+len >= addr);
+   return addr+len <= lg->pfn_limit * PAGE_SIZE && (addr+len >= addr);
 }
 
 /*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [RFC PATCH] suspend/resume performance improvement

[EunTaik Lee]

> Instead of replicating code in state_store here, does it make sense to
> move into a common part, so that fixes/optimization can be done in one
> place?
> Also why another config? If this has proven benefit then it can be
> default path.
I agree. I will resend the patch if this patch is agreed to be useful.

Re: [c++std-parallel-1651] Re: Compilers and RCU readers: Once more unto the breach!

[Paul E. McKenney]

On Tue, May 26, 2015 at 07:08:35PM +0200, Torvald Riegel wrote:
> On Tue, 2015-05-19 at 17:55 -0700, Paul E. McKenney wrote: 
> > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf
> 
> I have been discussing Section 7.9 with Paul during last week.
> 
> While I think that 7.9 helps narrow down the problem somewhat, I'm still
> concerned that it effectively requires compilers to either track
> dependencies or conservatively prevent optimizations like value
> speculation and specialization based on that.  Neither is a good thing
> for a compiler.

I do believe that we can find some middle ground.

> 7.9 adds requirements that dependency chains stop if the program itself
> informs the compiler about the value of something in the dependency
> chain (e.g., as shown in Figure 33).  Also, if a correct program that
> does not have undefined behavior must use a particular value, this is
> also considered as "informing" the compiler about that value.  For
> example:
>   int arr[2];
>   int* x = foo.load(mo_consume);
>   if (x > arr)   // implies same object/array, so x is in arr[]
> int r1 = *x; // compiler knows x == arr + 1
> The program, assuming no undefined behavior, first tells the compiler
> that x should be within arr, and then the comparison tells the compiler
> that x!=arr, so x==arr+1 must hold because there are just two elements
> in the array.

The updated version of Section 7.9 says that if undefined behavior
allows the compiler to deduce the exact pointer value, as in the
case you show above, the dependency chain is broken.

> Having these requirements is generally good, but we don't yet know how
> to specify this properly.  For example, I suppose we'd need to also say
> that the compiler cannot assume to know anything about a value returned
> from an mo_consume load; otherwise, nothing prevents a compiler from
> using knowledge about the stores that the mo_consume load can read from
> (see Section 7.2).

I expect that the Linux kernel's rcu_dereference() primitives would
map to volatile memory_order_consume loads for this reason.

> Also, a compiler is still required to not do value-speculation or
> optimizations based on that.  For example, this program:
> 
> void op(type *p)
> {
>   foo /= p->a;
>   bar = p->b;
> }
> void bar()
> {
>   pointer = ppp.load(mo_consume);
>   op(pointer);
> }
> 
> ... must not be transformed into this program, even if the compiler
> knows that global_var->a == 1:
> 
> void op(type *p) { /* unchanged */}
> void bar()
> {
> pointer = ppp.load(mo_consume);
>   if (pointer != global_var) {
> op(pointer);
>   else // specialization for global_var
> {
>   // compiler knows global_var->a==1;
>   // compiler uses global_var directly, inlines, optimizes:
>   bar = global_var->b;
> }
> 
> The compiler could optimize out the division if pointer==global_var but
> it must not access field b directly through global_var.  This would be
> pretty awkwaard; the compiler may work based on an optimized expression
> in the specialization (ie, create code that assumes global_var instead
> of pointer) but it would still have to carry around and use the
> non-optimized expression.

Exactly how valuable is this sort of optimization in real code?  And
how likely is the compiler to actually be able to apply it?

(I nevertheless will take another pass through the Linux kernel looking
for global variables being added to RCU-protected linked structures.
Putting a global into an RCU-protected structure seems more likely than
is an RCU-protected pointer into a two-element array.)

> This wouldn't be as bad if it were easily constrained to code sequences
> that really need the dependencies.  However, 7.9 does not effectively
> contain dependencies to only the code that really needs them, IMO.
> Unless the compiler proves otherwise, it has to assume that a load from
> a pointer carries a dependency.  Proving that is often very hard because
> it requires points-to analysis; 7.9 restricts this to intra-thread
> analysis but that is still nontrivial.
> Michael Matz' had a similar concern (in terms of what it results in).

Again, I will be looking through the Linux kernel for vulnerabilities to
this sort of transformation.  However, I am having a very hard time seeing
how the compiler is going to know that much about the vast majority of
the Linux-kernel use cases.  The linked structures are allocated on the
heap, not in arrays or in globals.

> Given that mo_consume is useful but a very specialized feature, I
> wouldn't be optimistic that 7.9 would actually be supported by many
> compilers.  The trade-off between having to track dependencies or having
> to disallow optimizations is a bad one to make.  The simple way out for
> a compiler would be to just emit mo_acquire instead of mo_consume and be
> done with all -- and this might be the most practical decision overall,
> or the default general-purpose implementation.  At least I haven't heard
> any compiler impl

[PATCH] char:agp:amd64-agp - Change 1 to true for bool type

[Shailendra Verma]

The variable agp_try_unsupported is bool type.Hence initializing with
bool value true instead of 1.

Signed-off-by: Shailendra Verma 
---
 drivers/char/agp/amd64-agp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 0ef3500..6b6af5a 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -33,7 +33,7 @@
 #define ULI_X86_64_ENU_SCR_REG 0x54
 
 static struct resource *aperture_resource;
-static bool __initdata agp_try_unsupported = 1;
+static bool __initdata agp_try_unsupported = true;
 static int agp_bridges_found;
 
 static void amd64_tlbflush(struct agp_memory *temp)
-- 
1.7.9.5

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

Re: [Intel-wired-lan] [PATCH v5] ixgbe: Add module parameter to disable VLAN filter

[Alexander Duyck]

On 05/26/2015 06:11 PM, Hiroshi Shimamoto wrote:

On 05/21/2015 06:10 AM, Hiroshi Shimamoto wrote:

From: Hiroshi Shimamoto 

Introduce module parameter "disable_hw_vlan_filter" to disable HW VLAN
filter on ixgbe module load.

  From the hardware limitation, there are only 64 VLAN entries for HW VLAN
filter, and it leads to limit the number of VLANs up to 64 among PF and
VFs. For SDN/NFV case, we need to handle unlimited VLAN packets on VF.
In such case, every VLAN packet can be transmitted to each VF.

When we try to make VLAN devices on VF, the 65th VLAN registration fails
and never be able to receive a packet with that VLAN tag.
If we do the below command on VM, ethX.65 to ethX.100 cannot be created.
# for i in `seq 1 100`; do \
  ip link add link ethX name ethX.$i type vlan id $i; done

There is a capability to disable HW VLAN filter and that makes all VLAN
tagged packets can be transmitted to every VFs. After VLAN filter stage,
unicast packets are transmitted to VF which has the MAC address same as
the transmitting packet.

With this patch and "disable_hw_vlan_filter=1", we can use unlimited
number of VLANs on VF.

Disabling HW VLAN filter breaks some NIC features such as DCB and FCoE.
DCB and FCoE are disabled when HW VLAN filter is disabled by this module
parameter.
Because of that reason, the administrator has to know that before turning
off HW VLAN filter.

You might also want to note that it makes the system susceptible to
broadcast/multicast storms since it eliminates any/all VLAN isolation.
So a broadcast or multicast packet on one VLAN is received on ALL
interfaces regardless of their VLAN configuration. In addition the
current VF driver is likely to just receive the packet as untagged, see
ixgbevf_process_skb_fields().  As a result one or two VFs can bring the
entire system to a crawl by saturating the PCIe bus via
broadcast/multicast traffic since there is nothing to prevent them from
talking to each other over VLANs that are no longer there.

that's right.

On the other hand, an untagged packet is not isolated,
doesn't it same broadcast/multicast storm on untagged network?


Yes, that is one of the reasons for VLANs.  It provides isolation so 
that if you have two entities on the same network you won't have entity 
A able to talk to entity B.  The problem is with VLAN promiscuous 
enabled if entity B is a VF it will see the traffic but has no way to 
know that it was VLAN tagged and a part of entity A's VLAN.





For the sake of backwards compatibility I would say that a feature like
this should be mutually exclusive with SR-IOV as well since it will
cause erratic behavior.  The VF will receive requests from all VLANs
thinking the traffic is untagged, and then send replies back to VLAN 0
even though that isn't where the message originated.

Sorry, I couldn't catch the above part.
Could you explain a bit more?

thanks,
Hiroshi


Until the VF issue
is fixed this type of feature is a no-go.




The current behavior for a VF is that if it receives a VLAN that it 
didn't request it assumes it is operating in port VLAN mode.  The 
problem is with your patch the VF will be receiving all traffic but have 
no idea which VLAN it came from.  As a result it could be replying to 
multicast or broadcast requests on one VLAN with the wrong VLAN ID.


The VLAN behavior of the VF drivers will need to be fixed before 
something like that could be supported with ANY of the VFs.  As such you 
will probably need to fix the VF driver in order to allow any of them to 
come online when VLAN filtering is disabled, as the driver will need to 
report the VLAN tag ID up to the stack.


- Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Lu Baolu]

Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus.  Ulpi registers the bus in
module_init(). This could cause unnecessary probe delays.

Reported-by: Zhuo Qiuxu 
Signed-off-by: Lu Baolu 
Acked-by: Heikki Krogerus 
---
 drivers/usb/common/ulpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..01c0c04 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -242,7 +242,7 @@ static int __init ulpi_init(void)
 {
return bus_register(&ulpi_bus);
 }
-module_init(ulpi_init);
+subsys_initcall(ulpi_init);
 
 static void __exit ulpi_exit(void)
 {
-- 
2.1.4

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

[PATCH] char:agp:amd64-agp - fix for warning __initdata

[Shailendra Verma]

The below checkpatch warning fixed in this patch. 
WARNING: __initdata should be placed after agp_try_unsupported
static bool __initdata agp_try_unsupported = true;

Signed-off-by: Shailendra Verma 
---
 drivers/char/agp/amd64-agp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/agp/amd64-agp.c b/drivers/char/agp/amd64-agp.c
index 6b6af5a..14900ea 100644
--- a/drivers/char/agp/amd64-agp.c
+++ b/drivers/char/agp/amd64-agp.c
@@ -33,7 +33,7 @@
 #define ULI_X86_64_ENU_SCR_REG 0x54
 
 static struct resource *aperture_resource;
-static bool __initdata agp_try_unsupported = true;
+static bool agp_try_unsupported __initdata = true;
 static int agp_bridges_found;
 
 static void amd64_tlbflush(struct agp_memory *temp)
-- 
1.7.9.5

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

Re: [PATCH 1/1] dw_mmc: insmod followed by rmmod will hung for eMMC

[Jaehoon Chung]

Hi, Pradu.

Sorry for late.
I will wait for your next version than i will check yours.

To Ulf.

Thanks for review!

Best Regards,
Jaehoon Chung

On 05/22/2015 10:21 PM, Ulf Hansson wrote:
> On 18 May 2015 at 16:23, Prabu Thangamuthu  wrote:
>> Removing dw_mmc driver immediately after inserting the dw_mmc driver is
> 
> I guess it hangs even if you remove it after a couple of days? :-)
> 
> Perhaps makes this a bit more clear?
> 
>> getting hung for eMMC device. Root cause for this issue is, dw_mci_remove
>> will disable all the interrupts then it will call dw_mci_cleanup_slot.
>> dw_mci_cleanup_slot is issuing CMD6 to disable boot partition access and
>> it's waiting for command complete interrupt. Since INTMASK was already
>> cleared by dw_mci_remove, command complete interrupt is not reaching
>> the system. This leads to process hung.
> 
> /s dw_mci_remove / dw_mci_remove()
> 
>>
>> Signed-off-by: Prabu Thangamuthu 
> 
> This patch looks good overall, but please send a new version with
> updated changelog. Moreover, please use "mmc: dw_mmc:" as prefix for
> the commit message header.
> 
> Kind regards
> Uffe
> 
>> ---
>>  drivers/mmc/host/dw_mmc.c |6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 5f5adaf..f0a0aff 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2941,15 +2941,15 @@ void dw_mci_remove(struct dw_mci *host)
>>  {
>> int i;
>>
>> -   mci_writel(host, RINTSTS, 0x);
>> -   mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
>> -
>> for (i = 0; i < host->num_slots; i++) {
>> dev_dbg(host->dev, "remove slot %d\n", i);
>> if (host->slot[i])
>> dw_mci_cleanup_slot(host->slot[i], i);
>> }
>>
>> +   mci_writel(host, RINTSTS, 0x);
>> +   mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
>> +
>> /* disable clock to CIU */
>> mci_writel(host, CLKENA, 0);
>> mci_writel(host, CLKSRC, 0);
>> --
>> 1.7.6.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:Re: Question about "Make sched entity usage tracking scale-invariant"

[Chao Xie]

At 2015-05-26 19:05:36, "Morten Rasmussen"  wrote:
>Hi,
>
>[Adding maintainers and others to cc]
>
>On Mon, May 25, 2015 at 02:19:43AM +0100, Chao Xie wrote:
>> hi
>> I saw the patch “sched: Make sched entity usage tracking
>> scale-invariant” that will make the usage to be freq scaled.
>> So if delta period that the calculation of usage based on cross a
>> frequency change, so how can you make sure the usage calculation is
>> correct?
>> The delta period may last hundreds of microseconds, and frequency
>> change window may be 10-20 microseconds, so many frequency change can
>> happen during the delta period.
>> It seems the patch does not consider about it, and it just pick up the
>> current one.
>> So how can you resolve this issue?
>
>Right. We don't know how many times the frequency may have changed since
>last time we updated the entity usage tracking for the particular
>entity. All we do is to call arch_scale_freq_capacity() and use that
>scaling factor to compensate for whatever changes might have taken
>place.
>
>The easiest implementation of arch_scale_freq_capacity() for most
>architectures is to just return a scaling factor computed based on the
>current frequency and ignoring when exactly the change happened and
>ignoring if multiple changes happened. Depending on how often the
>frequency might change this might be an acceptable approximation. While
>the task is running the sched tick will update the entity usage tracking
>(every 10ms by default on most ARM systems), hence we shouldn't be more
>than a tick off in term of when the frequency change is accounted for.
>Under normal circumstances the delta period should therefore be <10ms
>and generally shorter than that if you have more than one task runnable
>on the cpu or the task(s) are not always-running. It is not perfect but
>it is a lot better than the utilization tracking currently used by
>cpufreq governors and better than the scheduler being completely unaware
>of frequency scaling.
>
>For systems with very frequent frequency changes, i.e. fast hardware and
>an aggressive governor leading to multiple changes in less than 10ms,
>the solution above might not be sufficient. In that case, I think a
>better solution might be to track the average frequency using hardware
>counters or whatever tracking metrics the system might have to let
>arch_scale_freq_capacity() return the average performance delivered over
>the most recent period of time. AFAIK, x86 already has performance
>counters (APERF/MPERF) that could be used for this purpose. The delta
>period for each entity tracking update isn't fixed, but it might
>sufficient to just average over some fixed period of time. Accurate
>tracking would require some time-stamp information to be stored in each
>sched_entity for the true average to be computed for the delta period.
>That quickly becomes rather messy but not impossible. I did look at it
>briefly a while back, but decided not to go down that route until we
>know that using current frequency or some fixed period average isn't
>going to be sufficient. Usage or utilization is and average of something
>that might be constantly changing anyways, so it never going to be very
>accurate anyway. If it does turn out that we can't get the overall
>picture right, we will need to improve it.
>
>Updating the entity tracking for each frequency change adds to much
>overhead I think and seems unnecessary if we do with an average scaling
>factor.
>
>I hope that answers your question. Have you observed any problems with
>the usage tracking?
>

Thanks for the explanation.

I agree that the "delta" is less than 10ms at most situation, but i think at 
least one period
need to be considered.
If the frequency change happens just a little, for example, 10us before the 
task start to
calculate its utilization which may have a delta of 10ms. The almost whole 
delta will be calculated
based on new frequency, not the old one. The frequency change can be from the 
lowest to highest,
so for this time the delta calculation has big deviation, and this situation is 
not rare.

>Thanks,
>Morten

Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors

[Jaehoon Chung]

Hi, All.

Thanks for your effort and sorry for late!

On 05/27/2015 05:44 AM, Doug Anderson wrote:
> Alim,
> 
> On Tue, May 26, 2015 at 11:02 AM, Alim Akhtar  wrote:
>> Hi Doug,
>> On peach-pi, I got a hung task once in 4 cold boot as [1].
> 
> OK, I'll have to get my peach-pi or peach-pit up and running again.  I
> ran out of desk space and I haven't gotten it set back up.  :(
> 
> I've been testing on an rk3288-based device.  Past experience has
> taught me that the rk3288 dw_mmc works differently than the exynos
> one, so perhaps this is a difference.
> 
> Could you possibly patch in something like
>  and provide the
> console for the failure?  I'll put it on my list to try this myself,
> too

I don't test with this..but if needs, i will test.
It needs to fix the Alim's problem.

> 
> 
>> I was checking on v4.1-rc5, git hash as below:
>>
>> 862e58a mmc: dw_mmc: Wait for data transfer after response errors
>> ba155e2 Linux 4.1-rc5
>> 5b13966
>>
>> Not sure if I missed any dependent patch??
> 
> I'm currently testing out of tree, but my dw_mmc is very close to mainline.
> 
> 
>> Have not checked the dw TRM for this change, will do that as soon as I
>> get access to it.
> 
> OK, sounds good.  I have some old version of the DesignWare TRM, so
> possibly something is different in the newer one...

Which version do you have? I also need to check the TRM version.

Best Regards,
Jaehoon Chung

> 
> 
> -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] scripts:checkpatch - Do not give error if static bool or global bool variables are assigned to false value.

[Joe Perches]

On Wed, 2015-05-27 at 06:39 +0530, Shailendra Verma wrote:
> The bool value false is not always to be 0.

By definition (7.16 Boolean type and values ),
false is integer 0.

Setting a boolean variable to 0 is equivalent to
setting it to false.

What I think you mean is that a boolean variable can be
set to 0 when false might be more intelligible.

> So this patch will
> prevent for error if static bool or global bool are initialized
> with false value.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
>  # check for global initialisers.
> - if ($line =~ 
> /^\+(\s*$Type\sa*$Ident\s*(?:\s+$Modifier))*\s*=\s*(0|NULL|false)\s*;/) {
> + if ($line =~ 
> /^\+(\s*$Type\s*$Ident\s*(?:\s+$Modifier))*\s*=\s*(0|NULL)\s*;/) {
>   if (ERROR("GLOBAL_INITIALISERS",
> "do not initialise globals to 0 or NULL\n" .
> $herecurr) &&

I think using false adds some clarity for the reader and
even if something were to be applied, the error message
should probably be "do not initialize globals to $2\n"

(choose the spelling of your choice for initialise/initialize)

The (0|NULL|false) regex could probably be expanded to
(0x0+|0|NULL|false) or that regex could be saved as a
$our zero_value and tested using that new variable.

[]
>  # check for static initialisers.
> - if ($line =~ /^\+.*\bstatic\s.*=\s*(0|NULL|false)\s*;/) {
> + if ($line =~ /^\+.*\bstatic\s.*=\s*(0|NULL)\s*;/) {
>   if (ERROR("INITIALISED_STATIC",
> "do not initialise statics to 0 or NULL\n" .
> $herecurr) &&

$1 here

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

linux-next: build failure after merge of the wireless-drivers-next tree

[Stephen Rothwell]

Hi Kalle,

After merging the wireless-drivers-next tree, today's linux-next build
(arm multi_v7_defconfig) failed like this:

drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c: In function 
'brcmf_ops_sdio_probe':
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c:1139:7: error: dereferencing 
pointer to incomplete type
   adev->flags.power_manageable = 0;
   ^

Caused by commit f0992ace680c ("brcmfmac: prohibit ACPI power
management for brcmfmac driver").

I have used the wireless-drivers-next from next-20150526 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpZSLupObXbr.pgp
Description: OpenPGP digital signature

Re: [PATCH] PCI / ACPI: Do not set ACPI companions for host bridges with parents

[Boris Ostrovsky]

On 05/26/2015 08:07 PM, Rafael J. Wysocki wrote:

On Tuesday, May 26, 2015 10:32:03 AM Boris Ostrovsky wrote:

On 05/25/2015 10:17 PM, Rafael J. Wysocki wrote:

On Tuesday, May 26, 2015 03:08:17 AM Rafael J. Wysocki wrote:

On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote:

On Tuesday, May 26, 2015 01:22:12 AM Rafael J. Wysocki wrote:

On Friday, May 22, 2015 09:53:37 PM Boris Ostrovsky wrote:

On 05/22/2015 04:11 AM, Sander Eikelenboom wrote:

Hello Sander,


[cut]


(+Rafael again)

So the immediate cause of those errors is that pdev->evtchn is 0.
Backend is not notified and things not go well then.

And it is indeed caused by 97badf873ab60e841243b66133ff9eff2a46ef29:

We allocate pcifront_sd in pcifront_scan_root() and then pass it to
pci_scan_bus_parented() as sysdata. Eventually this sysdata is used in
pcibios_root_bridge_prepare() as pci_sysdata. It is dereferenced as
pci_sysdata->companion (which I believe is aliased to pcifront_sd->pdev)

Well, there is an int node field between them, so I'm not sure.


and then set_primary_fwnode() writes it, thus corrupting
pcifront_sd->pdev (and I think this is what sets evtchn to zero).

So the corruption happens when set_primary_fwnode() writes NULL to the
'secondary' field of object pointed to by 'fwnode'.

This isn't strictly necessary and we might avoid the crash by only
writing to fwnode->secondary if fn is not NULL.

So, Sander please test the patch below too if possible.

Of course, that doesn't solve a problem of passing an incorrect pointer
to ACPI_COMPANION_SET() in pcibios_root_bridge_prepare().

And here's one more thing to test.

And the below is how I'd fix it, so you can simply test this patch and skip the
previous ones.

---
From: Rafael J. Wysocki 
Subject: PCI / ACPI: Do not set ACPI companions for host bridges with parents

Commit 97badf873ab6 (device property: Make it possible to use
secondary firmware nodes) uncovered a bug in the x86 (and ia64) PCI
host bridge initialization code that assumes bridge->bus->sysdata
to always point to a struct pci_sysdata object which need not be
the case (in particular, the Xen PCI frontend driver sets it to point
to a different data type).  If it is not the case, an incorrect
pointer (or a piece of data that is not a pointer at all) will be
passed to ACPI_COMPANION_SET() and that may cause interesting
breakage to happen going forward.

To work around this problem use the observation that the ACPI
host bridge initialization always passes NULL as parent to
pci_create_root_bus(), so if pcibios_root_bridge_prepare() sees
a non-NULL parent of the bridge, it should not attempt to set
an ACPI companion for it, because that means that
pci_create_root_bus() has been called by someone else.


I am wondering whether at some point we might want to use companion
information in Xen as well.

Another option might be to require that whoever creates their own
sysdata structure to have pci_sysdata as its first element, e.g.

Well, I was thinking about that, but it would be x86-specific and I believe
that Xen is supposed to work on other architectures too (or at least will be
in the future).


--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -52,7 +52,12 @@ struct pcifront_device {
   };

   struct pcifront_sd {
+   /*
+* Must be the first element of this structure since pcifront_sd
+* is assigned to bus' sysdata and may later be dereferenced as
+* pci_sysdata.
+*/
+   struct pci_sysdata sd;
  struct pcifront_device *pdev;
   };

Also if you want to use an ACPI companion, it will be a good question *which* 
one.

My half-way educated guess is that will be the ACPI companion of the parent,
in which case it's better to modify pcibios_root_bridge_prepare().  In any
case, we need to talk about that beforehand, so please let me know when you
have more specific plans.


I don't have anything specific. And after looking at this code some more 
I am not sure pcifront will ever want to use companions since ACPI is 
not part of device initialization here (it's done via xenbus, which is a 
purely software construct).





As for 4.1 (which currently is broken for Sander), I think the $subject patch
is the cleanest and least intrusive thing we can do.


OK. Thank you for fixing this.

-boris

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

Re: [PATCH 2/2] base: power : opp.c: fixed a typo error

[Viresh Kumar]

On Wed, May 27, 2015 at 12:00 AM, Sriram Dash  wrote:
> From: dashsriram 
>
> Fixed a typo error in the file
>
> Signed-off-by: Sriram Dash 
> ---
>  drivers/base/power/opp.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> index 677fb28..300941b 100644
> --- a/drivers/base/power/opp.c
> +++ b/drivers/base/power/opp.c
> @@ -675,7 +675,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_remove);
>   * share a common logic which is isolated here.
>   *
>   * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> - * copy operation, returns 0 if no modifcation was done OR modification was
> + * copy operation, returns 0 if no modification was done OR modification was
>   * successful.
>   *
>   * Locking: The internal device_opp and opp structures are RCU protected.
> @@ -763,7 +763,7 @@ unlock:
>   * mutex locking or synchronize_rcu() blocking calls cannot be used.
>   *
>   * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> - * copy operation, returns 0 if no modifcation was done OR modification was
> + * copy operation, returns 0 if no modification was done OR modification was
>   * successful.
>   */
>  int dev_pm_opp_enable(struct device *dev, unsigned long freq)
> @@ -789,7 +789,7 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_enable);
>   * mutex locking or synchronize_rcu() blocking calls cannot be used.
>   *
>   * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> - * copy operation, returns 0 if no modifcation was done OR modification was
> + * copy operation, returns 0 if no modification was done OR modification was
>   * successful.
>   */
>  int dev_pm_opp_disable(struct device *dev, unsigned long freq)

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

Re: [RFC PATCH v2 09/15] perf probe: Support $params without debuginfo

[He Kuang]

hi, Alexei

On 2015/5/27 1:50, Alexei Starovoitov wrote:
> On 5/25/15 1:33 AM, He Kuang wrote:
>> Right, I learnt regparm(3) is mandatory in x86_32, according to rules,
>> the first three args will go to regparm(ax, dx, cx). But we should not
>> refer arg1~3 to ax, dx, cx because of 64bit parameters (other reasons?).
>>
>> Consider this keyword is used for generating bpf prologue which fetches
>> formal parameters when no debuginfo is provided, for this purpose, we can:
>>  1) We just help fetch the $regs or $regparms(If the keyword is
>> $regparms, ax/dx/cx is fetched, nothing related to args) to bpf arglists
>> and leave the rest things to bpf prog writer.
>>
>>  2) Keep that on platforms like x86_64 and skip this feature on
>> platforms like x86_32.
>>
>> or any other suggestions?
> 
> Single argument like $regparam or whatever name cannot work on all
> architectures, that's why in the very beginning I suggested
> 'func(long, char, void*)' syntax to describe arguments when debuginfo
> is not available. Calling convention for scalars is simple enough on
> all major architectures. x64_64 - trivial, i64_32 - a bit more involved,
> but simple enough so that list of types of arguments is enough to figure
> out which register or register pair or stack should be used to fetch
> argN.
> 
> 
As Masami has reminded,  the use of 'asmlinkage' forces regparm=0, and
we can't destinguish them without debuginfo, so 'func(long, char,
void*)' syntax not work in everywhere.

In fact, all the context infos are there in bpf prog(pt_regs in arg1).
To the non-debuginfo case, without the help of prologue, user steps
following flow to fetch params:

1. pt_regs(arg1) + architecture => calling regs

2. calling regs + function prototype(SEC) + gcc attributes(like
asmlinkage) => formal parameters

 '$regparms' do the 1st step, though not a full workaround. But for the
lack of gcc attributes, it seems we can't do the 2nd step. Any ideas?

Thanks

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

[PATCH] usb: dwc2: fix unnecessary USB overcurrent condition

[dinguyen]

From: Dinh Nguyen 

For platforms that use a ULPI phy, we should enable the external VbusValid
signal instead.

Signed-off-by: Dinh Nguyen 
Cc: Gregory Herrero 
Cc: Mian Yousaf Kaukab 
Cc: Felipe Balbi 
---
 drivers/usb/dwc2/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index e5b546f..08ffdc6 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -807,6 +807,11 @@ int dwc2_core_init(struct dwc2_hsotg *hsotg, bool 
select_phy, int irq)
if (hsotg->core_params->ts_dline > 0)
usbcfg |= GUSBCFG_TERMSELDLPULSE;
 
+   /* Set external VBUS indicator as needed. */
+   if (hsotg->core_params->phy_type == DWC2_PHY_TYPE_PARAM_ULPI)
+   usbcfg |= (GUSBCFG_ULPI_INT_VBUS_IND |
+  GUSBCFG_INDICATORPASSTHROUGH);
+
writel(usbcfg, hsotg->regs + GUSBCFG);
 
/* Reset the Controller */
-- 
2.2.1

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

Re: [RFC v2 1/4] fs: Add generic file system event notifications

[Greg KH]

On Tue, May 26, 2015 at 06:39:48PM +0200, Beata Michalska wrote:
> Hi,
> 
> Things has gone a bit quiet thread wise ...
> As I believe I've managed to snap back to reality, I was hoping we could 
> continue with this?
> I'm not sure if we've got everything cleared up or ... have we reached a dead 
> end?
> Please let me know if we can move to the next stage? Or, if there are any 
> showstoppers?

Please resend if you think it's ready and you have addressed the issues
raised so far.

thanks,

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

Re: [GIT PULL] USB fixes for v4.1-rc5

[Greg KH]

On Tue, May 26, 2015 at 10:35:16AM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> My final pull request for this -rc cycle. Sorry for being
> rather late, but I had a ton of things to catch up on after
> only 5 days out.
> 
> cheers
> 
> The following changes since commit c94e289f195e0e13cf34d27f9338d28221a85751:
> 
>   usb: gadget: remove incorrect __init/__exit annotations (2015-04-27 
> 14:45:35 -0500)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v4.1-rc5

Pulled and pushed out, thanks.

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

Re: [PATCH v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Greg Kroah-Hartman]

On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> Phy drivers and the ulpi interface providers depend on the
> registration of the ulpi bus.  Ulpi registers the bus in
> module_init(). This could cause unnecessary probe delays.

What do you mean by "probe delays"?

> 
> Reported-by: Zhuo Qiuxu 
> Signed-off-by: Lu Baolu 
> Acked-by: Heikki Krogerus 
> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index 0e6f968..01c0c04 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -242,7 +242,7 @@ static int __init ulpi_init(void)
>  {
>   return bus_register(&ulpi_bus);
>  }
> -module_init(ulpi_init);
> +subsys_initcall(ulpi_init);

Hasn't this already been rejected?

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 v4 1/1] usb: ulpi: ulpi_init should be executed in subsys_initcall

[Greg Kroah-Hartman]

On Wed, May 27, 2015 at 09:45:37AM +0800, Lu Baolu wrote:
> Phy drivers and the ulpi interface providers depend on the
> registration of the ulpi bus.  Ulpi registers the bus in
> module_init(). This could cause unnecessary probe delays.
> 
> Reported-by: Zhuo Qiuxu 
> Signed-off-by: Lu Baolu 
> Acked-by: Heikki Krogerus 
> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

A v4 patch with no "changelog" as to what is different from previous
versions?  That's reason enough for me to just ignore this :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ulpi: don't register drivers if bus doesn't exist

[Greg KH]

On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> Greg KH  writes:
> 
> > If there are other bus drivers that do this, I'll go fix them up,
> > pointers to those files would be appreciated.
> 
> git grep -E 'if .*\.p\W' found a couple of interesting candidates you
> might want to check out:
> 
>  drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p))) {
>  drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p)))
>  drivers/spmi/spmi.c:if (WARN_ON(!spmi_bus_type.p))
> 
> And this looks somewhat suspicious too, but could very well be OK for
> all I know (very close to nothing :)
> 
>  drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p) {
>  drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p)

Thanks, when I get a chance I'll look into this...

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] usb: ulpi: don't register drivers if bus doesn't exist

[Greg KH]

On Tue, May 26, 2015 at 10:54:01AM -0700, David Cohen wrote:
> Hi,
> 
> On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> > Greg KH  writes:
> > 
> > > If there are other bus drivers that do this, I'll go fix them up,
> > > pointers to those files would be appreciated.
> > 
> > git grep -E 'if .*\.p\W' found a couple of interesting candidates you
> > might want to check out:
> > 
> >  drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p))) {
> >  drivers/i2c/i2c-core.c: if (unlikely(WARN_ON(!i2c_bus_type.p)))
> >  drivers/spmi/spmi.c:if (WARN_ON(!spmi_bus_type.p))
> > 
> > And this looks somewhat suspicious too, but could very well be OK for
> > all I know (very close to nothing :)
> > 
> >  drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p) {
> >  drivers/gpio/gpiolib-sysfs.c:   if (!gpio_class.p)
> 
> I think we need a clear statement on how to proceed on this case.

Don't mess with bus->p.  I can rename it to
"do_not_touch_this_isnt_for_you" if people think that would make it more
obvious that a private data structure shouldn't be messed with in any
way.  Outside of the driver core, you have no knowledge that even if it
is a pointer, what that means with regards to anything.

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 V2 1/3] usb: add function usb_autopm_get_interface_upgrade

[Zhang, Yanmin]

Some usb driver has a specific requirement. Their critical functions
might be called under both atomic environment and non-atomic environment.

If it's under atomic environment, the driver can wake up the device
by calling pm_runtime_get_sync directly.

If it's under non-atomic environment, the function's caller need wake
up the device before the function accesses the device.

The patch adds usb_autopm_get_interface_upgrade, a new function to
support above capability.

Signed-off-by: Zhang Yanmin 

---

 drivers/usb/core/driver.c | 54 +++
 include/linux/usb.h   |  3 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 818369a..5d6f9ee 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1684,6 +1684,60 @@ int usb_autopm_get_interface(struct usb_interface *intf)
 EXPORT_SYMBOL_GPL(usb_autopm_get_interface);
 
 /**
+ * usb_autopm_get_interface_upgrade - increment a USB interface's PM-usage
+ * counter
+ * @intf: the usb_interface whose counter should be incremented
+ *
+ * This routine should be called by an interface driver when it wants to
+ * use @intf and needs to guarantee that it is not suspended.  In addition,
+ * the routine prevents @intf from being autosuspended subsequently.  (Note
+ * that this will not prevent suspend events originating in the PM core.)
+ * This prevention will persist until usb_autopm_put_interface() is called
+ * or @intf is unbound.  A typical example would be a character-device
+ * driver when its device file is opened.
+ *
+ * Comparing with usb_autopm_get_interface, usb_autopm_get_interface_upgrade
+ * is more careful when resuming the device.
+ * 1) The caller's caller already resumes resume the device and hold spinlocks.
+ * usb_autopm_get_interface_upgrade couldn't call pm_runtime_get_sync;
+ * 2) The caller's caller doesn't resume the device.
+ * usb_autopm_get_interface_upgrade has to resume the device before going 
ahead.
+ *
+ * @intf's usage counter is incremented to prevent subsequent autosuspends.
+ * However if the autoresume fails then the counter is re-decremented.
+ *
+ * This routine can run only in process context.
+ *
+ * Return: 0 on success.
+ */
+int usb_autopm_get_interface_upgrade(struct usb_interface *intf)
+{
+intstatus = 0;
+
+pm_runtime_get(&intf->dev);
+if (!pm_runtime_active(&intf->dev)) {
+/* If not active, next _get_sync wakes device up*/
+status = pm_runtime_get_sync(&intf->dev);
+/*
+ * If it's active, next _put_sync wouldn't
+ * really put it to sleep as the 1st _get
+ * keeps the device active.
+ */
+pm_runtime_put_sync(&intf->dev);
+if (status < 0)
+pm_runtime_put(&intf->dev);
+} else
+atomic_inc(&intf->pm_usage_cnt);
+dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+__func__, atomic_read(&intf->dev.power.usage_count),
+status);
+if (status > 0)
+status = 0;
+return status;
+}
+EXPORT_SYMBOL_GPL(usb_autopm_get_interface_upgrade);
+
+/**
  * usb_autopm_get_interface_async - increment a USB interface's PM-usage 
counter
  * @intf: the usb_interface whose counter should be incremented
  *
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 447fe29..0a8a44a 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -663,6 +663,7 @@ extern void usb_enable_autosuspend(struct usb_device *udev);
 extern void usb_disable_autosuspend(struct usb_device *udev);
 
 extern int usb_autopm_get_interface(struct usb_interface *intf);
+extern int usb_autopm_get_interface_upgrade(struct usb_interface *intf);
 extern void usb_autopm_put_interface(struct usb_interface *intf);
 extern int usb_autopm_get_interface_async(struct usb_interface *intf);
 extern void usb_autopm_put_interface_async(struct usb_interface *intf);
@@ -683,6 +684,8 @@ static inline int usb_disable_autosuspend(struct usb_device 
*udev)
 
 static inline int usb_autopm_get_interface(struct usb_interface *intf)
 { return 0; }
+static inline int usb_autopm_get_interface_upgrade(struct usb_interface *intf)
+{ return 0; }
 static inline int usb_autopm_get_interface_async(struct usb_interface *intf)
 { return 0; }
 
-- 
1.9.1


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

[PATCH V2 0/3] cdc-acm: fix incorrect runtime wakeup in acm_tty_write

[Zhang, Yanmin]

Resend as V1 has email format issue. Sorry for bothering.

---

There is a scenario about cdc-acm utilization.Application opens
n_gsm tty and cdc-acm tty. cdc-acm tty connects to xhci device.
The application configures cdc-adm tty to n_gsm tty as ldisc tty.

n_gsm=>cdc-acm=>xhci driver

acm_tty_write can be called from n_gsm driver by ldisc connection,
and from application when application opens cdc-acm tty directly.
acm_tty_write wakes up the device by calling usb_autopm_get_interface_async,
which calls pm_runtime_get. However, pm_runtime_get can't wake up
the device before returning as it's an async wake up. Then, acm_tty_write
might access the device when it is off.

The patchset fixes it by:
1) add a new function usb_autopm_get_interface_upgrade to deal with
above 2 requirements;
2) wake up device in n_gsm driver if n_gsm drivers calls cdc-acm driver;


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

[PATCH V2 2/3] cdc-acm: call usb_autopm_get_interface_upgrade in acm_tty_write

[Zhang, Yanmin]

acm device might be used as ldisc device by n_gsm driver.
gsmtty_write and other gsm functions calls acm_tty_write
indirectly while they holds spinlocks.

Meanwhile, application might access ACM tty device directly.

Here we choose to call usb_autopm_get_interface_upgrade instead of
usb_autopm_get_interface_async to make sure above 2 scenarios can
work well.

Signed-off-by: Zhang Yanmin 

---

 drivers/usb/class/cdc-acm.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 5c8f581..6ad85a3 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -689,10 +689,15 @@ static int acm_tty_write(struct tty_struct *tty,
 
 dev_vdbg(&acm->data->dev, "%s - count %d\n", __func__, count);
 
+stat = usb_autopm_get_interface_upgrade(acm->control);
+if (stat)
+return stat;
+
 spin_lock_irqsave(&acm->write_lock, flags);
 wbn = acm_wb_alloc(acm);
 if (wbn < 0) {
 spin_unlock_irqrestore(&acm->write_lock, flags);
+usb_autopm_put_interface(acm->control);
 return 0;
 }
 wb = &acm->wb[wbn];
@@ -700,6 +705,7 @@ static int acm_tty_write(struct tty_struct *tty,
 if (!acm->dev) {
 wb->use = 0;
 spin_unlock_irqrestore(&acm->write_lock, flags);
+usb_autopm_put_interface(acm->control);
 return -ENODEV;
 }
 
@@ -708,13 +714,6 @@ static int acm_tty_write(struct tty_struct *tty,
 memcpy(wb->buf, buf, count);
 wb->len = count;
 
-stat = usb_autopm_get_interface_async(acm->control);
-if (stat) {
-wb->use = 0;
-spin_unlock_irqrestore(&acm->write_lock, flags);
-return stat;
-}
-
 if (acm->susp_count) {
 usb_anchor_urb(wb->urb, &acm->delayed);
 spin_unlock_irqrestore(&acm->write_lock, flags);
-- 
1.9.1

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

[PATCH V2 3/3] n_gsm: wake up ldisc tty before using it

[Zhang, Yanmin]

Wake up ldisc device before calling its driver to access the device.

Signed-off-by: Zhang Yanmin 

---

 drivers/tty/n_gsm.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 2c34c32..40671fa 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int debug;
 module_param(debug, int, 0600);
@@ -555,6 +556,27 @@ static int gsm_stuff_frame(const u8 *input, u8 *output, 
int len)
 return olen;
 }
 
+static int pm_runtime_get_sync_tty(struct tty_struct *tty)
+{
+int ret = 0;
+
+/*Wakeup parent as tty itself doesn't enable runtime*/
+if (tty->dev->parent)
+ret = pm_runtime_get_sync(tty->dev->parent);
+
+return ret;
+}
+
+static int pm_runtime_put_tty(struct tty_struct *tty)
+{
+int ret = 0;
+
+if (tty->dev->parent)
+ret = pm_runtime_put(tty->dev->parent);
+
+return ret;
+}
+
 /**
  *gsm_send-send a control frame
  *@gsm: our GSM mux
@@ -1511,7 +1533,9 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
 return;
 dlci->retries = gsm->n2;
 dlci->state = DLCI_OPENING;
+pm_runtime_get_sync_tty(gsm->tty);
 gsm_command(dlci->gsm, dlci->addr, SABM|PF);
+pm_runtime_put_tty(gsm->tty);
 mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
 }
 
@@ -1533,7 +1557,9 @@ static void gsm_dlci_begin_close(struct gsm_dlci *dlci)
 return;
 dlci->retries = gsm->n2;
 dlci->state = DLCI_CLOSING;
+pm_runtime_get_sync_tty(gsm->tty);
 gsm_command(dlci->gsm, dlci->addr, DISC|PF);
+pm_runtime_put_tty(gsm->tty);
 mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
 }
 
@@ -2286,7 +2312,9 @@ static void gsmld_receive_buf(struct tty_struct *tty, 
const unsigned char *cp,
 flags = *f++;
 switch (flags) {
 case TTY_NORMAL:
+pm_runtime_get_sync_tty(gsm->tty);
 gsm->receive(gsm, *dp);
+pm_runtime_put_tty(gsm->tty);
 break;
 case TTY_OVERRUN:
 case TTY_BREAK:
@@ -2957,6 +2985,7 @@ static int gsmtty_open(struct tty_struct *tty, struct 
file *filp)
 {
 struct gsm_dlci *dlci = tty->driver_data;
 struct tty_port *port = &dlci->port;
+int ret;
 
 port->count++;
 tty_port_tty_set(port, tty);
@@ -2968,7 +2997,11 @@ static int gsmtty_open(struct tty_struct *tty, struct 
file *filp)
 /* Start sending off SABM messages */
 gsm_dlci_begin_open(dlci);
 /* And wait for virtual carrier */
-return tty_port_block_til_ready(port, tty, filp);
+pm_runtime_get_sync_tty(dlci->gsm->tty);
+ret = tty_port_block_til_ready(port, tty, filp);
+pm_runtime_put_tty(dlci->gsm->tty);
+
+return ret;
 }
 
 static void gsmtty_close(struct tty_struct *tty, struct file *filp)
@@ -2986,11 +3019,14 @@ static void gsmtty_close(struct tty_struct *tty, struct 
file *filp)
 gsm = dlci->gsm;
 if (tty_port_close_start(&dlci->port, tty, filp) == 0)
 return;
+pm_runtime_get_sync_tty(gsm->tty);
 gsm_dlci_begin_close(dlci);
 if (test_bit(ASYNCB_INITIALIZED, &dlci->port.flags)) {
 if (C_HUPCL(tty))
 tty_port_lower_dtr_rts(&dlci->port);
 }
+pm_runtime_put_tty(gsm->tty);
+
 tty_port_close_end(&dlci->port, tty);
 tty_port_tty_set(&dlci->port, NULL);
 return;
@@ -3012,10 +3048,12 @@ static int gsmtty_write(struct tty_struct *tty, const 
unsigned char *buf,
 struct gsm_dlci *dlci = tty->driver_data;
 if (dlci->state == DLCI_CLOSED)
 return -EINVAL;
+pm_runtime_get_sync_tty(dlci->gsm->tty);
 /* Stuff the bytes into the fifo queue */
 sent = kfifo_in_locked(dlci->fifo, buf, len, &dlci->lock);
 /* Need to kick the channel */
 gsm_dlci_data_kick(dlci);
+pm_runtime_put_tty(dlci->gsm->tty);
 return sent;
 }
 
-- 
1.9.1

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

[PATCH net-next v6 0/2] Adding support for Cavium ThunderX network controller

[Aleksey Makarov]

This patchset adds support for the Cavium ThunderX network controller.

changes in v6:
 * unused preprocessor symbols were removed
 * reduce no of atomic operations in SQ maintenance
 * support for TCP segmentation at driver level
 * reset RBDR if fifo state is FAIL
 * fixed an issue with link state mailbox message

changes in v5:
 * __packed were removed.  now we rely on C language ABI
 * nic_dbg() -> netdev_dbg()
 * fixes for a typo, constant spelling and using BIT_ULL
 * use print_hex_dump()
 * unnecessary conditions in a long if() chain were removed

changes in v4:
 * the patch "pci: Add Cavium PCI vendor id" was attributed correctly
 * a note that Cavium id is used in many drivers was added
 * the license comments now match MODULE_LICENSE
 * a comment explaining usage of writeq_relaxed()/readq_relaxed() was added

changes in v3:
 * code cleanup
 * issues discovered by reviewers were addressed

changes in v2:
 * non-generic module parameters removed
 * ethtool support added (nicvf_set_rxnfc())

v5: 
https://lkml.kernel.org/g/<1432344498-17131-1-git-send-email-aleksey.maka...@caviumnetworks.com>
v4: 
https://lkml.kernel.org/g/<1432000757-28700-1-git-send-email-aleksey.maka...@auriga.com>
v3: 
https://lkml.kernel.org/g/<1431747401-20847-1-git-send-email-aleksey.maka...@auriga.com>
v2: 
https://lkml.kernel.org/g/<1415596445-10061-1-git-send-email-r...@kernel.org>
v1: https://lkml.kernel.org/g/<20141030165434.GW20170@rric.localhost>

Sunil Goutham (2):
  pci: Add Cavium PCI vendor id
  net: Adding support for Cavium ThunderX network controller

 MAINTAINERS|7 +
 drivers/net/ethernet/Kconfig   |1 +
 drivers/net/ethernet/Makefile  |1 +
 drivers/net/ethernet/cavium/Kconfig|   40 +
 drivers/net/ethernet/cavium/Makefile   |5 +
 drivers/net/ethernet/cavium/thunder/Makefile   |   11 +
 drivers/net/ethernet/cavium/thunder/nic.h  |  414 ++
 drivers/net/ethernet/cavium/thunder/nic_main.c |  940 
 drivers/net/ethernet/cavium/thunder/nic_reg.h  |  213 +++
 .../net/ethernet/cavium/thunder/nicvf_ethtool.c|  601 
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   | 1332 +
 drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 1544 
 drivers/net/ethernet/cavium/thunder/nicvf_queues.h |  381 +
 drivers/net/ethernet/cavium/thunder/q_struct.h |  701 +
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c  |  966 
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h  |  223 +++
 include/linux/pci_ids.h|2 +
 17 files changed, 7382 insertions(+)
 create mode 100644 drivers/net/ethernet/cavium/Kconfig
 create mode 100644 drivers/net/ethernet/cavium/Makefile
 create mode 100644 drivers/net/ethernet/cavium/thunder/Makefile
 create mode 100644 drivers/net/ethernet/cavium/thunder/nic.h
 create mode 100644 drivers/net/ethernet/cavium/thunder/nic_main.c
 create mode 100644 drivers/net/ethernet/cavium/thunder/nic_reg.h
 create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_ethtool.c
 create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_main.c
 create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_queues.c
 create mode 100644 drivers/net/ethernet/cavium/thunder/nicvf_queues.h
 create mode 100644 drivers/net/ethernet/cavium/thunder/q_struct.h
 create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_bgx.c
 create mode 100644 drivers/net/ethernet/cavium/thunder/thunder_bgx.h

-- 
2.4.1

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

Re: [PATCH 1/2] KVM: MMU: fix SMAP virtualization

[Xiao Guangrong]

On 05/26/2015 10:48 PM, Paolo Bonzini wrote:



On 26/05/2015 16:45, Edward Cree wrote:

This breaks older compilers that can't initialize anon structures.

How old ? Even gcc 3.1 says you can use unnamed struct/union fields and
3.2 is the minimum version required to compile the kernel as mentioned
in the README.

We could simply just name the structure, but I doubt this is the
only place in the kernel code where it's being used this way :)

This appears to be GCC bug #10676, see 

Says it was fixed in 4.6, but I believe the kernel supports GCCs much older
than that (back to 3.2).  I personally hit it on 4.4.7, the version shipped
with RHEL6.6.


Yes, it will be fixed soon(ish).  Probably before you can get rid of the
obnoxious disclaimer... :)


It has been fixed by Andrew:

From: Andrew Morton 
Subject: arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug

arch/x86/kvm/mmu.c: In function 'kvm_mmu_pte_write':
arch/x86/kvm/mmu.c:4256: error: unknown field 'cr0_wp' specified in initializer
arch/x86/kvm/mmu.c:4257: error: unknown field 'cr4_pae' specified in initializer
arch/x86/kvm/mmu.c:4257: warning: excess elements in union initializer
...

gcc-4.4.4 (at least) has issues when using anonymous unions in
initializers.

Fixes: edc90b7dc4ceef6 ("KVM: MMU: fix SMAP virtualization")
Cc: Xiao Guangrong 
Cc: Paolo Bonzini 
Signed-off-by: Andrew Morton 

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

Re: [PATCH] atm:he - Change 0 to false for bool type variable initialization.

[David Miller]

From: Shailendra Verma 
Date: Wed, 27 May 2015 06:50:18 +0530

> The variable sdh is bool type so initializing it with false value
> instead of 0.
> 
> Signed-off-by: Shailendra Verma 
> ---
>  drivers/atm/he.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/atm/he.c b/drivers/atm/he.c
> index 93dca2e..eb5bebc 100644
> --- a/drivers/atm/he.c
> +++ b/drivers/atm/he.c
> @@ -116,8 +116,8 @@ static bool disable64;
>  static short nvpibits = -1;
>  static short nvcibits = -1;
>  static short rx_skb_reserve = 16;
> -static bool irq_coalesce = 1;
> -static bool sdh = 0;
> +static bool irq_coalesce = true;
> +static bool sdh = false;

You didn't understand my feedback.

I already applied your patch that handled the irq_coalesce issue,
so you have to submit a patch relative to that.

In fact, you should always test that your patch applied to my tree
before submitting it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

[Hanjun Guo]

On 2015年05月27日 00:35, Timur Tabi wrote:

On 05/26/2015 03:28 AM, Hanjun Guo wrote:


  early_acpi_os_unmap_memory((char *)table, tbl_size);
  }


please add

#ifdef CONFIG_ARM_SBSA_WATCHDOG
(acpi gtdt code)
#endif


I don't agree with this.  The GTDT should be parsed even if there's no
watchdog driver compiled for this kernel.  There are no other #ifdefs in
this file.


So what's the point of parse GTDT and alloc memories for it if there
is no watchdog driver compiled for the kernel? will the module insmod
later even if the CONFIG_ARM_SBSA_WATCHDOG=n?




+ * Add a platform device named "sbsa-gwdt" to match the platform
driver.
+ * "sbsa-gwdt": SBSA(Server Base System Architecture) Generic
Watchdog
+ * The platform driver can get device info below by matching this
name.


* The platform driver (drivers/watchdog/sbsa_gwdt.c) can get device info
below by matching this name.

Adding the file name which will help for review and maintain in my
opinion.


Except it will cause problems if the driver is renamed or moved.  I
don't think this is a good idea, either (sorry!)


OK, that's good point. but what I proposed is some hint to which driver
will use the data prepared in this file, we can easily understand it
in this patchset, but if just review the code in this fiel, I think
people will be confused without detail comments.

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

Re: [PATCH V2 3/3] n_gsm: wake up ldisc tty before using it

[Greg KH]

On Wed, May 27, 2015 at 10:50:01AM +0800, Zhang, Yanmin wrote:
> Wake up ldisc device before calling its driver to access the device.
> 
> Signed-off-by: Zhang Yanmin 
> 
> ---
> 
>  drivers/tty/n_gsm.c | 40 +++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index 2c34c32..40671fa 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -62,6 +62,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static int debug;
>  module_param(debug, int, 0600);
> @@ -555,6 +556,27 @@ static int gsm_stuff_frame(const u8 *input, u8 *output, 
> int len)
>  return olen;
>  }
>  
> +static int pm_runtime_get_sync_tty(struct tty_struct *tty)
> +{
> +int ret = 0;
> +
> +/*Wakeup parent as tty itself doesn't enable runtime*/

No spaces in your comment?

Anyway, this is corrupted and can't be applied, please fix up your email
client and try it again...

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: [PATCHv6 05/10] ARM: mxs: fix in tree users of ssd1306

[Shawn Guo]

On Tue, May 26, 2015 at 10:08:23AM +0300, Tomi Valkeinen wrote:
> So should I take this via fbdev tree with the rest of the patches? If
> so, I want an ack from a relevant dts maintainer. get_maintainers.pl
> gives Shawn as the first contact for imx28-cfa10036.dts.

Acked-by: Shawn Guo 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/6] ACPI: import watchdog info of GTDT into platform device

[Timur Tabi]

Hanjun Guo wrote:

I don't agree with this.  The GTDT should be parsed even if there's no
watchdog driver compiled for this kernel.  There are no other #ifdefs in
this file.


So what's the point of parse GTDT and alloc memories for it if there
is no watchdog driver compiled for the kernel?


I don't think it's normal policy to generate a platform only if one 
specific driver is enabled.


> will the module insmod

later even if the CONFIG_ARM_SBSA_WATCHDOG=n?


I think that actually can work, but it's not a good reason by itself.


OK, that's good point. but what I proposed is some hint to which driver
will use the data prepared in this file, we can easily understand it
in this patchset, but if just review the code in this fiel, I think
people will be confused without detail comments.


All anyone needs to is

git grep "sbsa-gwdt"

And you'll find the driver.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
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/

linux-next: build failure after merge of the backlight tree

[Stephen Rothwell]

Hi Lee,

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

drivers/video/backlight/backlight.c: In function 'of_find_backlight_by_node':
drivers/video/backlight/backlight.c:563:2: error: implicit declaration of 
function 'of_platform_device_ensure' [-Werror=implicit-function-declaration]
  of_platform_device_ensure(node);
  ^

Caused by commit 67a6b10546ea ("backlight: Probe backlight devices on
demand").

I have used the backlight tree from next-20150526 for today.

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


pgpfw9K9SyEv8.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 v3.18-rc4 1/4] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Damian Hobson-Garcia]

Hello,
>On Wed, Nov 12, 2014 at 6:38 AM, Daniel Thompson  
>wrote:
>> Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
>> (DRM|O)_CLOEXEC making it hard for the userspace to generate a file
>> descriptor that can be used by mmap().
>>
>> It is easy to relax the restriction and allow read/write permissions.
>> This should be safe because the flags are seldom touched by drm; mostly
>> they are passed verbatim to dma_buf calls.
>>
>> Signed-off-by: Daniel Thompson 
>
> Reviewed-by: Rob Clark 

It's a little bit old by now, but I'm wondering if someone call tell me
whether this patch is likely to be merged sometime, or has it been
(should it be?) abandoned.

Thank you,
Damian

>
>> ---
>>  drivers/gpu/drm/drm_prime.c | 9 +++--
>>  include/uapi/drm/drm.h  | 1 +
>>  2 files changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index 78ca30808422..8467b17c8053 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>> @@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
>> =  {
>>   * drm_gem_prime_export - helper library implemention of the export callback
>>   * @dev: drm_device to export from
>>   * @obj: GEM object to export
>> - * @flags: flags like DRM_CLOEXEC
>> + * @flags: flags like DRM_CLOEXEC and DRM_RDWR
>>   *
>>   * This is the implementation of the gem_prime_export functions for GEM 
>> drivers
>>   * using the PRIME helpers.
>> @@ -635,14 +635,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device 
>> *dev, void *data,
>> return -ENOSYS;
>>
>> /* check flags are valid */
>> -   if (args->flags & ~DRM_CLOEXEC)
>> +   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
>> return -EINVAL;
>>
>> -   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
>> -   flags = args->flags & DRM_CLOEXEC;
>> -
>> return dev->driver->prime_handle_to_fd(dev, file_priv,
>> -   args->handle, flags, &args->fd);
>> +   args->handle, args->flags, &args->fd);
>>  }
>>
>>  int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>> index b0b855613641..89c2b68ddc51 100644
>> --- a/include/uapi/drm/drm.h
>> +++ b/include/uapi/drm/drm.h
>> @@ -660,6 +660,7 @@ struct drm_set_client_cap {
>> __u64 value;
>>  };
>>
>> +#define DRM_RDWR O_RDWR
>>  #define DRM_CLOEXEC O_CLOEXEC
>>  struct drm_prime_handle {
>> __u32 handle;
>> --
>> 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 net-next v6 0/2] Adding support for Cavium ThunderX network controller

[David Miller]

From: Aleksey Makarov 
Date: Tue, 26 May 2015 19:20:13 -0700

> This patchset adds support for the Cavium ThunderX network controller.

I don't see patch #1 (yet).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/7] Smack namespace

[Eric W. Biederman]

Lukasz Pawelczyk  writes:

> Hello,
>
> Some time ago I sent a Smack namespace documentation and a preliminary
> LSM namespace for RFC. I've been suggested that there shouldn't be a
> separate LSM namespace and that it should live within user namespace.
> And this version does. This is a complete set of patches required for
> Smack namespace.
>
> This was designed with a collaboration of Smack maintainer Casey
> Schaufler.
>
> Smack namespace have been implemented using user namespace hooks added
> by one of the patches. To put some context to it I paste here a
> documentation on what Smack namespace wants to achieve.
>
> LSM hooks themselves are documented in the security.h file inside the
> patch.
>
> The patches are based on:
> https://github.com/cschaufler/smack-next/tree/smack-for-4.2-stacked
>
> The tree with them is avaiable here:
> https://github.com/Havner/smack-namespace/tree/smack-namespace-for-4.2-stacked-v2
>
> Changes from v1:
>  - "kernel/exit.c: make sure current's nsproxy != NULL while checking
>caps" patch has been dropped
>  - fixed the title of the user_ns operations patch

A have not completed a review I don't understand smack well enough to
answer some questions but I don't think I like the approach this patch
takes to get things done.

I am flattered that you are using a mapping as I did with uid map and
gid map.  Unfortunately I do not believe your mapping achieves what my
mapping of uids and gids achieved.

A technical goal is to give people the tools so that a sysadmin can set
up a system, can grant people subids and subgids, and then the user can
proceed to do what they need to do.  In particular there should be
little to no need to keep pestering the system administrator for more
identifiers.

The flip side of that was that the mapping would ensure all of the
existing permissions checks would work as expected, and the checks in
the kernel could be converted without much trouble.

Ranges of ids were choosen because they allow for a lot of possible ways
of using uids and gids in containers, are comparitively easy to
administer, are very fast to use, and don't need large data structures.

With a discreet mapping of labels I have the premonition that we now
have a large data structure that, is not as flexible in to use,
is comparatively slow and appears to require an interaction with the
system administrator for every label you use in a container.

As part of that there is added a void *security pointer in the user
namespace to apparently hang off anything anyone would like to use.
Connected to that are hooks that have failure codes (presumably memory
allocation failures), but the semantics are not clear.  My gut feel is
that I would rather extend struct user_namespace to hold the smack label
mapping table and remove all of the error codes because they would then
be unnecessary.

I am also concerned that several of the operations assume that setns
and the like are normally privileged operations and so require the
ability to perform other privileged operations.  Given that in the right
circumstances setns is not privileged that seems like a semantics
mismatch.

Or in short my gut feel says the semantics of this change are close to
something that would be very useful, but the details make this patchset
far less useful, usable and comprehensible than it should be.

Eric


> ===
>
> --- What is a Smack namespace ---
>
> Smack namespace was developed to make it possible for Smack to work
> nicely with Linux containers where there is a full operating system
> with its own init inside the namespace. Such a system working with
> Smack expects to have at least partially working SMACK_MAC_ADMIN to be
> able to change labels of processes and files. This is required to be
> able to securely start applications under the control of Smack and
> manage their access rights.
>
> It was implemented using new LSM hooks added to the user namespace
> that were developed together with Smack namespace.
>
>
> --- Design ideas ---
>
> "Smack namespace" is rather "Smack labels namespace" as not the whole
> MAC is namespaced, only the labels. There is a great analogy between
> Smack labels namespace and the user namespace part that remaps UIDs.
>
> The idea is to create a map of labels for a namespace so the namespace
> is only allowed to use those labels. Smack rules are always the same
> as in the init namespace (limited only by what labels are mapped) and
> cannot be manipulated from the child namespace. The map is actually
> only for labels' names. The underlying structures for labels remain
> the same. The filesystem also stores the "unmapped" labels from the
> init namespace.
>
> Let's say we have those labels in the init namespace:
> label1
> label2
> label3
>
> and those rules:
> label1 label2 rwx
> label1 label3 rwx
> label2 label3 rwx
>
> We create a map for a namespace:
> label1 -> mapped1
> label2 -> mapped2
>
> This means that 'la

Re: [PATCH v3] net/unix: sk_socket can disappear when state is unlocked

[David Miller]

From: Hannes Frederic Sowa 
Date: Tue, 26 May 2015 23:24:59 +0200

> On Tue, May 26, 2015, at 17:22, Mark Salyzyn wrote:
>> got a rare NULL pointer dereference in clear_bit
>> 
>> Signed-off-by: Mark Salyzyn 
> 
> IMHO, this is the right approach, I didn't came up with something
> easier, thanks!
> 
> Acked-by: Hannes Frederic Sowa 

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

[PATCH] regulator: s2mps11: Fix GPIO suspend enable shift wrapping bug

[Krzysztof Kozlowski]

Status of enabling suspend mode for regulator was stored in bitmap-like
long integer.

However since adding support for S2MPU02 the number of regulators
exceeded 32 so on devices with more than 32 regulators (S2MPU02 and
S2MPS13) overflow happens when shifting the bit. This could lead to
enabling suspend mode for completely different regulator than intended
or to switching different regulator to other mode (e.g. from always
enabled to controlled by PWRHOLD pin). Both cases could result in larger
energy usage and issues when suspending to RAM.

Signed-off-by: Krzysztof Kozlowski 
Cc: 
Reported-by: Dan Carpenter 
Fixes: 00e2573d2c10 ("regulator: s2mps11: Add support S2MPU02 regulator device")
---
 drivers/regulator/s2mps11.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 326ffb553371..72fc3c32db49 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -34,6 +34,8 @@
 #include 
 #include 
 
+/* The highest number of possible regulators for supported devices. */
+#define S2MPS_REGULATOR_MAXS2MPS13_REGULATOR_MAX
 struct s2mps11_info {
unsigned int rdev_num;
int ramp_delay2;
@@ -49,7 +51,7 @@ struct s2mps11_info {
 * One bit for each S2MPS13/S2MPS14/S2MPU02 regulator whether
 * the suspend mode was enabled.
 */
-   unsigned long long s2mps14_suspend_state:50;
+   DECLARE_BITMAP(suspend_state, S2MPS_REGULATOR_MAX);
 
/* Array of size rdev_num with GPIO-s for external sleep control */
int *ext_control_gpio;
@@ -500,7 +502,7 @@ static int s2mps14_regulator_enable(struct regulator_dev 
*rdev)
switch (s2mps11->dev_type) {
case S2MPS13X:
case S2MPS14X:
-   if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
+   if (test_bit(rdev_get_id(rdev), s2mps11->suspend_state))
val = S2MPS14_ENABLE_SUSPEND;
else if 
(gpio_is_valid(s2mps11->ext_control_gpio[rdev_get_id(rdev)]))
val = S2MPS14_ENABLE_EXT_CONTROL;
@@ -508,7 +510,7 @@ static int s2mps14_regulator_enable(struct regulator_dev 
*rdev)
val = rdev->desc->enable_mask;
break;
case S2MPU02:
-   if (s2mps11->s2mps14_suspend_state & (1 << rdev_get_id(rdev)))
+   if (test_bit(rdev_get_id(rdev), s2mps11->suspend_state))
val = S2MPU02_ENABLE_SUSPEND;
else
val = rdev->desc->enable_mask;
@@ -562,7 +564,7 @@ static int s2mps14_regulator_set_suspend_disable(struct 
regulator_dev *rdev)
if (ret < 0)
return ret;
 
-   s2mps11->s2mps14_suspend_state |= (1 << rdev_get_id(rdev));
+   set_bit(rdev_get_id(rdev), s2mps11->suspend_state);
/*
 * Don't enable suspend mode if regulator is already disabled because
 * this would effectively for a short time turn on the regulator after
@@ -960,18 +962,22 @@ static int s2mps11_pmic_probe(struct platform_device 
*pdev)
case S2MPS11X:
s2mps11->rdev_num = ARRAY_SIZE(s2mps11_regulators);
regulators = s2mps11_regulators;
+   BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num);
break;
case S2MPS13X:
s2mps11->rdev_num = ARRAY_SIZE(s2mps13_regulators);
regulators = s2mps13_regulators;
+   BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num);
break;
case S2MPS14X:
s2mps11->rdev_num = ARRAY_SIZE(s2mps14_regulators);
regulators = s2mps14_regulators;
+   BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num);
break;
case S2MPU02:
s2mps11->rdev_num = ARRAY_SIZE(s2mpu02_regulators);
regulators = s2mpu02_regulators;
+   BUILD_BUG_ON(S2MPS_REGULATOR_MAX < s2mps11->rdev_num);
break;
default:
dev_err(&pdev->dev, "Invalid device type: %u\n",
-- 
1.9.1

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

Re: [PATCH] scripts:checkpatch - Do not give error if static bool or global bool variables are assigned to false value.

[Joe Perches]

On Wed, 2015-05-27 at 08:43 +0530, Shailendra Verma wrote:
> Hello Joe,
> 
> Thanks for the clarification. So I will change the error message as
> suggested by you and will send the patch to you.

Hello Shailendra.

My humble apologies to you.

I totally misunderstood what you were writing.
I guess the first sentence threw me for a loop.

It makes sense to avoid emitting a warning message with

bool foo = false;

cheers, Joe

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

Re: [PATCH 0/3] GPIO support for BRCMSTB

[Gregory Fong]

Hi Linus,

On Wed, May 13, 2015 at 1:59 AM, Linus Walleij  wrote:
> On Tue, May 12, 2015 at 9:38 PM, Gregory Fong  wrote:
>> On Tue, May 12, 2015 at 3:59 AM, Linus Walleij  
>> wrote:
>>> On Wed, May 6, 2015 at 10:37 AM, Gregory Fong  
>>> wrote:
>>>
 There is only one IRQ for each GIO IP block (i.e. several register banks 
 share
 an IRQ).  After briefly looking into the generic IRQ chip implementation, 
 it
 seemed like in this case that using it would result in the driver being 
 more
 complex than necessary because AFAICT it expects a 1:1 mapping of
 irq_chip_generic to gpio_chip.  It seemed like less of a pain to have a 
 single
 irq_chip since we have a single IRQ for all register banks (multiple
 gpio_chips).  I might be missing something, maybe using a shared IRQ across
 multiple irq_chips is easier than I think?  Suggestions welcome.
>>>
>>> What is needed is a 1:1 mapping between GPIO offsets and IRQ
>>> offsets.
>>>
>>> If you just number your GPIOs 0...n and your IRQs 0...n
>>> it should work just fine with one irqchip for all banks.
>>>
>>> What screws things up is likely that the hardware supports
>>> 32 lines per bank and not all are used.
>>>
>>> I suggest you enable 32 line and 32 IRQs per bank,
>>> so that hwirq maps nicely 1:1 on the GPIO offsets,
>>> then just use the width thing to NACK operations on
>>> GPIO lines you are not using. This way you can also
>>> decode and warn on spurious IRQs on the unused lines.
>>
>> For having 32 lines per bank, the big problem here is the upper limit
>> of 256 GPIOs.
>
> Which arch is this?
> Usually this limit comes from
> arch/*/include/asm/gpio.h
>
> For ARM that was bumped to 512 a while back. It is also possible
> to define a custom value for your system by defining
> ARCH_NR_GPIOS
>
>> Anyway, I don't think I understand IRQ domains and irq_chip_generic
>> very well.  One possibility _might_ be to use multiple irq_chips.
>
> That is probably not possible if there is just one IRQ for all
> banks.
>
> The task of the irqdomain is a 1-to-1 translation from one
> hardware numberspace to the Linux IRQ number space.
>
> In your case the hardware IRQ (hwirq) numberspace
> should be:
>
> bank0: 0..31
> bank1: 32..63
> 
> bankn: 32*n..32*n+31
>
> I think the gpiolib irqchip code can translate that properly
> as it is just a simple 0...x mapping, the irq handler need
> some magic to loop over all banks from 0..n though.

I've now actually attempted to use the gpiolib irqchip code.  This
driver can't directly use gpiochip_irqchip_add() because of the
multiple gpiochip : one irqchip map.  At first, I thought it might be
possible to simply add a new argument (or break things into a helper
function) to allow setting the associated IRQ domain, but then I can't
use the generic map and unmap functions which expect the irq_domain
host_data member to be struct gpiochip *, which makes no sense in this
case.  That puts me right back to implementing a special version of
the map and unmap function.

Since there doesn't appear to be any benefit to using the gpiolib
irqchip code for this case, I'm going to stick with my implementation
from patch 3 of this patchset.  I've also added to it to allow for
using the GPIOs as a wakeup source, and will submit that as well with
V2.

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

Re: [PATCH 0/6] support "dataplane" mode for nohz_full

[Mike Galbraith]

On Tue, 2015-05-26 at 15:51 -0400, Chris Metcalf wrote:

> On balance I suspect it's still better to make command line arguments
> handle the common cases most succinctly.

I prefer user specifies precisely, but yeah, that entails more typing.  

Idle curiosity: can SGI monster from hell boot a NO_HZ_FULL_ALL kernel,
w/wo it implying isolcpus?  Readers having same and a reactor to power
it in their basement, please test.

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/hugetlb: document the reserve map/region tracking routines

[Mike Kravetz]

On 05/26/2015 04:09 PM, Andrew Morton wrote:

On Tue, 26 May 2015 14:27:10 -0700 Mike Kravetz  wrote:


This is a documentation only patch and does not modify any code.
Descriptions of the routines used for reserve map/region tracking
are added.


Confused.  This adds comments which are similar to the ones which were
added by
mm-hugetlb-compute-return-the-number-of-regions-added-by-region_add-v2.patch
and
mm-hugetlb-handle-races-in-alloc_huge_page-and-hugetlb_reserve_pages-v2.patch.
But the comments are a bit different.  And this patch madly conflicts
with the two abovementioned patches.

Maybe the thing to do is to start again, with a three-patch series:

mm-hugetlb-document-the-reserve-map-region-tracking-routines.patch
mm-hugetlb-compute-return-the-number-of-regions-added-by-region_add-v3.patch
mm-hugetlb-handle-races-in-alloc_huge_page-and-hugetlb_reserve_pages-v3.patch

while resolving the differences in the new code comments?



Sorry for the confusion.  Naoya and Davidlohr suggested changes to
the documentation and code.  One suggestion was to create a separate
documentation only patch.


I will create a new series as you suggest above.

--
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [fuse-devel] fuse_get_context() and namespaces

[Eric W. Biederman]

Seth Forshee  writes:

> On Tue, May 26, 2015 at 05:21:38PM +0200, Miklos Szeredi wrote:
>> On Fri, May 22, 2015 at 01:59:32PM -0500, Seth Forshee wrote:
>> > On Fri, May 22, 2015 at 12:44:35PM -0500, Eric W. Biederman wrote:
>> > > Seth Forshee  writes:
>> > > 
>> > > > On Fri, May 22, 2015 at 04:23:55PM +0200, Miklos Szeredi wrote:
>> > > >> On Sat, May 2, 2015 at 5:56 PM,   wrote:
>> > > >> >
>> > > >> > 3.10.0-229 form Scientific Linux and native 4.0.1-1 (from elrepo).
>> > > >> > SL 7.1 on the host and SL 6.6 on the LXC guest. At least in 3.10
>> > > >> > the 499dcf2024092e5cce41d05599a5b51d1f92031a is present.
>> > > >> > Steps to reproduce:
>> > > >> >
>> > > >> > On first console:
>> > > >> > [root@sl7test ~]# lxc-start  -n test-2 /bin/su -
>> > > >> > [root@test-2 ~]# diff -u  hello.py 
>> > > >> > /usr/share/doc/fuse-python-0.2.1/example/hello.py
>> > > >> > --- hello.py2015-05-02 11:12:13.963093580 -0400
>> > > >> > +++ /usr/share/doc/fuse-python-0.2.1/example/hello.py   2010-04-14 
>> > > >> > 18:29:21.0 -0400
>> > > >> > @@ -41,8 +41,6 @@
>> > > >> >  class HelloFS(Fuse):
>> > > >> >
>> > > >> >  def getattr(self, path):
>> > > >> > -dic = Fuse.GetContext(self)
>> > > >> > -print dic
>> > > >> >  st = MyStat()
>> > > >> >  if path == '/':
>> > > >> >  st.st_mode = stat.S_IFDIR | 0755
>> > > >> > [root@test-2 ~]# python hello.py -f  /mnt/
>> > > >> >
>> > > >> > On second console:
>> > > >> > [root@test-2 ~]# echo $$
>> > > >> > 41
>> > > >> > [root@test-2 ~]# ls /mnt/
>> > > >> > hello
>> > > >> >
>> > > >> > Output of first console:
>> > > >> > {'gid': 0, 'pid': 12083, 'uid': 0}
>> > > >> 
>> > > >> Thanks.
>> > > >> 
>> > > >> Digging in mailbox...  There was a thread last year about adding
>> > > >> support for running fuse daemon in a container:
>> > > >> 
>> > > >>   http://thread.gmane.org/gmane.linux.kernel/1811658
>> > > >> 
>> > > >> Not sure what happened, but no updated patches have been posted or
>> > > >> maybe I just missed them.
>> > > >
>> > > > I haven't sent updated patches in a while. I still intend to, but I
>> > > > shifted focus to first getting general support for mounts from user
>> > > > namespaces into the vfs (which will give a clearer direction for some 
>> > > > of
>> > > > the concerns raised about the fuse patches).
>> > > >
>> > > > All of this code is available in the userns-mounts branch of
>> > > > git://kernel.ubuntu.com/sforshee/linux.git, and I don't think the fuse
>> > > > patches actually depend on any of the stuff that precedes them. I'm
>> > > > planning to start submitting some of the earlier patches from that
>> > > > branch soon, and eventually get back to resubmitting the fuse patches.
>> > > >
>> > > > This is about pid namespaces though, and the fuse pid namespace patch
>> > > > from that series (see below) should be more or less independent of the
>> > > > rest of the patches. Potentially that could be merged separately from
>> > > > the user namespae stuff.
>> > > 
>> > > [snip]
>> > > 
>> > > > @@ -2076,7 +2077,15 @@ static int convert_fuse_file_lock(const struct 
>> > > > fuse_file_lock *ffl,
>> > > >  
>> > > >fl->fl_start = ffl->start;
>> > > >fl->fl_end = ffl->end;
>> > > > -  fl->fl_pid = ffl->pid;
>> > > > +
>> > > > +  /*
>> > > > +   * Convert pid into the connection's pid namespace. If 
>> > > > the
>> > > > +   * pid does not map into the namespace fl_pid will get 
>> > > > set
>> > > > +   * to 0.
>> > > > +   */
>> > > > +  rcu_read_lock();
>> > > > +  fl->fl_pid = pid_vnr(find_pid_ns(ffl->pid, fc->pid_ns));
>> > > > +  rcu_read_unlock();
>> > > 
>> > > Scratches my head.  This looks wrong.
>> > > 
>> > > I would have expected pid_nr_ns.  Am I missing something reading this
>> > > patch quickly?
>> > 
>> > Here we're in the context of a F_GETLK operation. We've requested the
>> > lock information from the fuse process, and ffl->pid is the pid number
>> > in that process's pid namespace so it needs to be translated into
>> > current's namespace. First we have to look up the struct pid, then
>> > pid_vnr is just a wrapper for pid_nr_ns in the current pid namespace:
>> > 
>> >   pid_t pid_vnr(struct pid *pid)
>> >   {
>> >   return pid_nr_ns(pid, task_active_pid_ns(current));
>> >   }
>> > 
>> > Oh, but the comment is wrong, so maybe that's what confused you.
>> > s/connection/caller/ there and it should make more sense.
>> 
>> Attaching updated patch against fuse.git for-next.  Check namespace in both
>> device read and write.  Check them at the start (doesn't matter if requests 
>> are
>> stuck in the queue, if server isn't playing by the rules, then all is lost
>> anyway).
>> 
>> One thing: we return error if current tgid isn't valid in server's namespace.
>> That's looks good.  However we silently succeed and set in.h.pid to z

[PATCH] Intel, Dell, Ubuntu - i915/intel_dp.c

[Dragan Stancevic]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

this is not a patch for mainline. It affects Dell Precision M3800
Laptop running Ubuntu with Intel Graphics. Problem manifests in a way
where laptop after some use will not suspend anymore. It will attempt
to suspend, blank out the screen and come back up. It's rather finicky
as it doesn't happen consistently, but often enough that it started
being mildly annoying. I tracked it down to a race condition between
scheduled work and another thread. Essentially the driver would do a
double put on a structure if the race condition was hit. This patch
fixes the problem and my laptop has been suspending flawlessly for
about a month and a half.

- From my memory going back 1.5 months the race condition is between
_edp_panel_vdd_on, intel_edp_panel_off, edp_panel_vdd_off_sync.

Kernel and Distro info:
:~/src/Dell-M4800-Hardware/kernel$ uname -r
3.16.7-ckt8
:~/src/Dell-M4800-Hardware/kernel$ cat /etc/issue
Ubuntu 14.10 \n \l

Hope someone else finds the attached patch useful.

Thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJVZT1AAAoJEFvcFPjWWnki3NAP/Aq+o6HRWgJzjDPoHUnqoeuZ
xU/N4/aSjEMS2qBdOz++86B1nloT4ztKTRlaOJ45BCvCW2SeyHtMfHwyvIVw29hc
bo5+T4nOx0wHtX/iaULowM3++enEARH76SAFUcMsUJEX36nSJywyWSIM19h59L4z
JxjrPUVnbFn5K4FTBJ1GhG/3QDfDoD/i7bH/v+MIJCXSYWeV9S273nG9onMz5NhW
OxRx2avmat23zqwGDDTkLfOLCFVzByxPqbXU/muyo8yM9teHapfrMTOwYtWgIMDb
vFkfLJmDpa2NhPefSacNIi/L23oK4poGK4nw8w/U+VUaGwmConOtJq7tR517sewh
R481WfaZeJzCVt5IJtC076j+1YmtZQri7jdJJlxS1RW/2ZVGDNEWWFCMNo1g+ixl
kht0o2FSqjKjtSpzNuXjoKldpCH+v91ix8JqJSdfkjj4VOljKJh+xnPxOelbdU5a
aKnk6+hg8fc9CL37LHzV/nvIGaOht5VKPGSBZQQ0p7G+Oe169kPpE1gUfgsvzdw7
y0fkEaGV0iyuHMCrcY32dgEf0QrZyCqgmsts/u7q3bWoMSyWyYyE3gu8wQ1VT2Bb
+4sHgIXYjQZpVoEMs2i4gezPHL6oDhuOk6enJYah0dKpp9uefCRXbEiwitbZdnLE
P+l2M/QpOWM+qwvuV7Te
=HAXT
-END PGP SIGNATURE-
--- linux-3.16.0.ubt/drivers/gpu/drm/i915/intel_dp.c	2015-04-16 20:17:21.0 -0700
+++ linux-3.16.0/drivers/gpu/drm/i915/intel_dp.c	2015-04-16 20:29:45.040894002 -0700
@@ -1175,6 +1175,7 @@
 	if (!is_edp(intel_dp))
 		return false;
 
+	cancel_delayed_work(&intel_dp->panel_vdd_work);
 	intel_dp->want_panel_vdd = true;
 
 	if (edp_have_panel_vdd(intel_dp))

Re: [PATCH V2 3/3] n_gsm: wake up ldisc tty before using it

[Zhang, Yanmin]

On 2015/5/27 11:02, Greg KH wrote:
> On Wed, May 27, 2015 at 10:50:01AM +0800, Zhang, Yanmin wrote:
>> Wake up ldisc device before calling its driver to access the device.
>>
>> Signed-off-by: Zhang Yanmin 
>>
>> ---
>>
>>  drivers/tty/n_gsm.c | 40 +++-
>>  1 file changed, 39 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
>> index 2c34c32..40671fa 100644
>> --- a/drivers/tty/n_gsm.c
>> +++ b/drivers/tty/n_gsm.c
>> @@ -62,6 +62,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  static int debug;
>>  module_param(debug, int, 0600);
>> @@ -555,6 +556,27 @@ static int gsm_stuff_frame(const u8 *input, u8 *output, 
>> int len)
>>  return olen;
>>  }
>>  
>> +static int pm_runtime_get_sync_tty(struct tty_struct *tty)
>> +{
>> +int ret = 0;
>> +
>> +/*Wakeup parent as tty itself doesn't enable runtime*/
> No spaces in your comment?
I will add it.

>
> Anyway, this is corrupted and can't be applied, please fix up your email
> client and try it again...
I check the patch by scripts/checkpatch.pl and everything seems good.

I use Thunderbird 31.7.0, the latest. It auto updates to the latest version. 
Perhaps some new
config options changed something.

It seems email client converts some tab to space automatically.

Yanmin

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

Re: [RFC PATCH 1/2] kernel/fork.c: add a function to calculate page address from thread_info

[KOSAKI Motohiro]

On Sun, May 24, 2015 at 12:01 PM, Jungseok Lee  wrote:
> A current implementation assumes thread_info address is always correctly
> calculated via virt_to_page. It restricts a different approach, such as
> thread_info allocation from vmalloc space.
>
> This patch, thus, introduces an independent function to calculate page
> address from thread_info one.
>
> Suggested-by: Sungjinn Chung 
> Signed-off-by: Jungseok Lee 
> Cc: KOSAKI Motohiro 
> Cc: linux-arm-ker...@lists.infradead.org
> ---
>  kernel/fork.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

I haven't receive a path [2/2] and haven't review whole patches. But
this patch itself is OK to me.
Acked-by: KOSAKI Motohiro 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] zram: check comp algorithm availability earlier

[Minchan Kim]

Hello Sergey,

On Tue, May 26, 2015 at 10:13:37PM +0900, Sergey Senozhatsky wrote:
> Improvement idea by Marcin Jabrzyk.
> 
> comp_algorithm_store() silently accepts any supplied algorithm
> name, because zram performs algorithm availability check later,
> during the device configuration phase in disksize_store() and
> prints
>   "zram: Cannot initialise %s compressing backend"
> to syslog. this error line is somewhat generic and, besides,
> can indicate a failed attempt to allocate compression backend's
> working buffers.
> 
> make algorithm availability check earlier, in comp_algorithm_store(),
> and be move verbose:
> 
>   echo lzz > /sys/block/zram0/comp_algorithm
>   -bash: echo: write error: Invalid argument
> 
> dmesg:
>   zram: Error: unavailable compression algorithm: lzz
> 
> Signed-off-by: Sergey Senozhatsky 
> Reported-by: Marcin Jabrzyk 
> ---
>  drivers/block/zram/zcomp.c| 5 +
>  drivers/block/zram/zcomp.h| 1 +
>  drivers/block/zram/zram_drv.c | 6 ++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index a1a8b8e..e10e2b4 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -320,6 +320,11 @@ void zcomp_destroy(struct zcomp *comp)
>   kfree(comp);
>  }
>  
> +bool zcomp_available_algorithm(const char *comp)
> +{
> + return find_backend(comp) != NULL;
> +}
> +
>  /*
>   * search available compressors for requested algorithm.
>   * allocate new zcomp and initialize it. return compressing
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index c59d1fc..46e2b9f 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -51,6 +51,7 @@ struct zcomp {
>  };
>  
>  ssize_t zcomp_available_show(const char *comp, char *buf);
> +bool zcomp_available_algorithm(const char *comp);
>  
>  struct zcomp *zcomp_create(const char *comp, int max_strm);
>  void zcomp_destroy(struct zcomp *comp);
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 28f6e46..e17b73e 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -378,6 +378,12 @@ static ssize_t comp_algorithm_store(struct device *dev,
>   if (sz > 0 && zram->compressor[sz - 1] == '\n')
>   zram->compressor[sz - 1] = 0x00;
>  
> + if (!zcomp_available_algorithm(zram->compressor)) {
> + pr_err("Error: unavailable compression algorithm: %s\n",
> + zram->compressor);
> + len = -EINVAL;
> + }
> +

I'm not against this patch because it's better than old.
But let's think more about the pr_err part.

If user try to set wrong algo name, he can see EINVAL.
Isn't it enough?

I think every sane admin can think he passed wrong argument
if he sees -EINVAL.
So, I don't think we need to emit pr_err in here.

The reason I am paranoid about that is that I really don't want
to argue with syslog info which is part of ABI or not in future.
If possible, I don't want to depend on pr_xxx.


>   up_write(&zram->init_lock);
>   return len;
>  }
> -- 
> 2.4.1.314.g9532ead
> 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next v6 1/2] pci: Add Cavium PCI vendor id

[Aleksey Makarov]

From: Sunil Goutham 

This vendor id will be used by network (vNIC), USB (xHCI),
SATA (AHCI), GPIO, I2C, MMC and maybe other drivers
for ThunderX SoC.

Acked-by: Bjorn Helgaas 
Signed-off-by: Sunil Goutham 
Signed-off-by: Aleksey Makarov 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 1fa99a3..80bd333 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2324,6 +2324,8 @@
 #define PCI_DEVICE_ID_ALTIMA_AC91000x03ea
 #define PCI_DEVICE_ID_ALTIMA_AC10030x03eb
 
+#define PCI_VENDOR_ID_CAVIUM   0x177d
+
 #define PCI_VENDOR_ID_BELKIN   0x1799
 #define PCI_DEVICE_ID_BELKIN_F5D7010V7 0x701f
 
-- 
2.4.1

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

Re: [PATCH 10/11] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y

[Hanjun Guo]

On 2015年05月26日 23:44, Boris Ostrovsky wrote:

On 05/26/2015 10:54 AM, Tomasz Nowicki wrote:

On 26.05.2015 16:00, Boris Ostrovsky wrote:

On 05/26/2015 09:54 AM, Boris Ostrovsky wrote:

On 05/26/2015 08:49 AM, Hanjun Guo wrote:

In drivers/xen/pci.c, there are arch x86 dependent codes when
CONFIG_PCI_MMCONFIG is enabled, since CONFIG_PCI_MMCONFIG
depends on ACPI, so this will prevent XEN PCI running on other
architectures using ACPI with PCI_MMCONFIG enabled (such as ARM64).

Fortunatly, it can be sloved in a simple way. In drivers/xen/pci.c,
the only x86 dependent code is if ((pci_probe & PCI_PROBE_MMCONF) ==
0),
and it's defined in asm/pci_x86.h, the code means that
if the PCI resource is not probed in PCI_PROBE_MMCONF way, just
ingnore the xen mcfg init. Actually this is duplicate, because
if PCI resource is not probed in PCI_PROBE_MMCONF way, the
pci_mmconfig_list will be empty, and the if (list_empty())
after it will do the same job.

So just remove the arch related code and the head file, this
will be no functional change for x86, and also makes xen/pci.c
usable for other architectures.

Signed-off-by: Hanjun Guo 
CC: Konrad Rzeszutek Wilk 
CC: Boris Ostrovsky 
---
  drivers/xen/pci.c | 6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 6785ebb..9a8dbe3 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -28,9 +28,6 @@
  #include 
  #include 
  #include "../pci/pci.h"
-#ifdef CONFIG_PCI_MMCONFIG
-#include 
-#endif

  static bool __read_mostly pci_seg_supported = true;

@@ -222,9 +219,6 @@ static int __init xen_mcfg_late(void)
  if (!xen_initial_domain())
  return 0;

-if ((pci_probe & PCI_PROBE_MMCONF) == 0)
-return 0;
-
  if (list_empty(&pci_mmcfg_list))
  return 0;



(+Stefano who is Xen ARM maintainer)

This will not build on x86 since pci_mmcfg_list since, for example,
pci_mmcfg_list is declared in pci_x86.h.



And now really with Stefano and with parsable first sentence, sorry:


This will not build on x86 since pci_mmcfg_list, for example, is
declared in pci_x86.h.


With this patch set, not any more. Please see preceding patches.



OK, I didn't notice this was part of a series.


Sorry, I didn't cc you all of those patches.



Then if not having PCI_PROBE_MMCONF bit set is indeed equivalent to
list_empty(&pci_mmcfg_list), is there any reason for this flag to
(continue to) exist? (and also for pci_mmcfg_arch_init_failed.)


I think PCI_PROBE_MMCONF bit is needed for early init of pci mmconfig in
the x86 arch related code, but for xen_mcfg_late(), it's called after
acpi_init() which the mmconfig is ready for use if it's available (the
pci_mmcfg_list is empty or not), so not having PCI_PROBE_MMCONF bit set
is equivalent list_empty(&pci_mmcfg_list) is not suitable for all cases,
but I think it will be ok after mmconfig is initialized.

I think my change log is misleading and needs updating :)

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

Re: [PATCH 00/11] ARM64 PCI hostbridge init based on ACPI

[Hanjun Guo]

On 2015年05月27日 08:30, Rafael J. Wysocki wrote:

On Tuesday, May 26, 2015 08:49:13 PM Hanjun Guo wrote:

This patch set is introducing ARM64 PCI hostbridge init based on ACPI,
which based on Jiang Liu's patch set "Consolidate ACPI PCI root common
code into ACPI core":

https://lkml.org/lkml/2015/5/14/98


I'll be regarding this patchset as an RFC until the one from Jiang Liu goes in.


Yes, please, Jiang Liu's patch set should go in first.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dell_rbtn - kernel panic at boot...

[Darren Hart]

On Mon, May 25, 2015 at 04:40:14PM +0200, Pali Rohár wrote:
> On Sunday 24 May 2015 21:44:32 Darren Hart wrote:
> > On Sat, May 23, 2015 at 03:05:36AM +0200, Pali Rohár wrote:
> > > On Saturday 23 May 2015 00:53:16 Dmitry Torokhov wrote:
> > > > On Thu, May 21, 2015 at 7:06 PM, Valdis Kletnieks
> > > > 
> > > >  wrote:
> > > > > So after I made both config variables =y, the resulting kernel
> > > > > built, but died a glorious death at boot.
> > > > 
> > > > I guess if both are built-in then, according to link order,
> > > > dell-laptop starts first, before dell-rbtn, and dies in
> > > > dell_rbtn_notifier_register() in call to
> > > > driver_for_each_device(&rbtn_driver.drv, ...) because rbtn_driver has
> > > > not been registered yet and thus half-initlalized.
> > > > 
> > > > Thanks.
> > > 
> > > pr_debug() messages could be useful... but no idea if we can get them.
> > > 
> > > Is there any way to fix that dependency race condition? Could 
> > > driver_attach() function call help?
> > 
> > I believe you can avoid this by moving dell-rbtn earlier in the Makefile 
> > than
> > dell-laptop - but this is fragile and a hack to resolve a dependency 
> > problem.
> > 
> 
> And what about that late_initcall() instead module_init() in dell-laptop?
> Will it fix this problem?
> 

No, because late_initcall() for modules is module_init(). See
include/linux/init.h.

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

Re: [RFC PATCH 2/2] arm64: Implement vmalloc based thread_info allocator

[Minchan Kim]

Hello Jungseok,

On Tue, May 26, 2015 at 08:29:59PM +0900, Jungseok Lee wrote:
> On May 25, 2015, at 11:40 PM, Minchan Kim wrote:
> > Hello Jungseok,
> 
> Hi, Minchan,
> 
> > On Mon, May 25, 2015 at 01:02:20AM +0900, Jungseok Lee wrote:
> >> Fork-routine sometimes fails to get a physically contiguous region for
> >> thread_info on 4KB page system although free memory is enough. That is,
> >> a physically contiguous region, which is currently 16KB, is not available
> >> since system memory is fragmented.
> > 
> > Order less than PAGE_ALLOC_COSTLY_ORDER should not fail in current
> > mm implementation. If you saw the order-2,3 high-order allocation fail
> > maybe your application received SIGKILL by someone. LMK?
> 
> Exactly right. The allocation is failed via the following path.
> 
> if (test_thread_flag(TIF_MEMDIE) && !(gfp_mask & __GFP_NOFAIL))
>   goto nopage;
> 
> IMHO, a reclaim operation would be not needed in this context if memory is
> allocated from vmalloc space. It means there is no need to traverse shrinker 
> list. 

For making fork successful with using vmalloc, it's bandaid.

> 
> >> This patch tries to solve the problem as allocating thread_info memory
> >> from vmalloc space, not 1:1 mapping one. The downside is one additional
> >> page allocation in case of vmalloc. However, vmalloc space is large enough,
> > 
> > The size you want to allocate is 16KB in here but additional 4K?
> > It increases 25% memory footprint, which is huge downside.
> 
> I agree with the point, and most people who try to use vmalloc might know the 
> number.
> However, an interoperation on the number depends on a point of view.
> 
> Vmalloc is large enough and not fully utilized in case of ARM64.
> With the considerations, there is a room to do math as follows.
> 
> 4KB / 240GB = 1.5e-8 (4KB page + 3 level combo)
> 
> It would be not a huge downside if fork-routine is not damaged due to 
> fragmentation.

Okay, address size point of view, it wouldn't be significant problem.
Then, let's see it performance as point of view.

If we use vmalloc, it needs additional data structure for vmalloc
management, several additional allocation request, page table hanlding
and TLB flush.

Normally, forking is very frequent operation so we shouldn't do
make it slow and memory consumption bigger if there isn't big reason.

> 
> However, this is one of reasons to add "RFC" prefix in the patch set. How is 
> the
> additional 4KB interpreted and considered?
> 
> Best Regards
> Jungseok Lee

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] cdc-acm: call usb_autopm_get_interface_upgrade in acm_tty_write

[Zhang, Yanmin]

From: Zhang Yanmin 

acm device might be used as ldisc device by n_gsm driver.
gsmtty_write and other gsm functions calls acm_tty_write
indirectly while they holds spinlocks.

Meanwhile, application might access ACM tty device directly.

Here we choose to call usb_autopm_get_interface_upgrade instead of
usb_autopm_get_interface_async to make sure above 2 scenarios can
work well.

Signed-off-by: Zhang Yanmin 
---
 drivers/usb/class/cdc-acm.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 5c8f581..6ad85a3 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -689,10 +689,15 @@ static int acm_tty_write(struct tty_struct *tty,
 
dev_vdbg(&acm->data->dev, "%s - count %d\n", __func__, count);
 
+   stat = usb_autopm_get_interface_upgrade(acm->control);
+   if (stat)
+   return stat;
+
spin_lock_irqsave(&acm->write_lock, flags);
wbn = acm_wb_alloc(acm);
if (wbn < 0) {
spin_unlock_irqrestore(&acm->write_lock, flags);
+   usb_autopm_put_interface(acm->control);
return 0;
}
wb = &acm->wb[wbn];
@@ -700,6 +705,7 @@ static int acm_tty_write(struct tty_struct *tty,
if (!acm->dev) {
wb->use = 0;
spin_unlock_irqrestore(&acm->write_lock, flags);
+   usb_autopm_put_interface(acm->control);
return -ENODEV;
}
 
@@ -708,13 +714,6 @@ static int acm_tty_write(struct tty_struct *tty,
memcpy(wb->buf, buf, count);
wb->len = count;
 
-   stat = usb_autopm_get_interface_async(acm->control);
-   if (stat) {
-   wb->use = 0;
-   spin_unlock_irqrestore(&acm->write_lock, flags);
-   return stat;
-   }
-
if (acm->susp_count) {
usb_anchor_urb(wb->urb, &acm->delayed);
spin_unlock_irqrestore(&acm->write_lock, flags);
-- 
1.9.1


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

[PATCH V3 0/3] cdc-acm: fix incorrect runtime wakeup in acm_tty_write

[Zhang, Yanmin]

Resend as V1/V2 have email format issue. Sorry for bothering.

I use Thunderbird. It has no a button to enable LKML email simply. :)

V3: Change email config to resend.
Add a space in comment.

 ---

There is a scenario about cdc-acm utilization.Application opens
n_gsm tty and cdc-acm tty. cdc-acm tty connects to xhci device.
The application configures cdc-adm tty to n_gsm tty as ldisc tty.

n_gsm=>cdc-acm=>xhci driver

acm_tty_write can be called from n_gsm driver by ldisc connection,
and from application when application opens cdc-acm tty directly.
acm_tty_write wakes up the device by calling usb_autopm_get_interface_async,
which calls pm_runtime_get. However, pm_runtime_get can't wake up
the device before returning as it's an async wake up. Then, acm_tty_write
might access the device when it is off.

The patchset fixes it by:
1) add a new function usb_autopm_get_interface_upgrade to deal with
above 2 requirements;
2) wake up device in n_gsm driver if n_gsm drivers calls cdc-acm driver;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] usb: add function usb_autopm_get_interface_upgrade

[Zhang, Yanmin]

From: Zhang Yanmin 

Some usb driver has a specific requirement. Their critical functions
might be called under both atomic environment and non-atomic environment.

If it's under atomic environment, the driver can wake up the device
by calling pm_runtime_get_sync directly.

If it's under non-atomic environment, the function's caller need wake
up the device before the function accesses the device.

The patch adds usb_autopm_get_interface_upgrade, a new function to
support above capability.

Signed-off-by: Zhang Yanmin 
---
 drivers/usb/core/driver.c | 54 +++
 include/linux/usb.h   |  3 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 818369a..5d6f9ee 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1684,6 +1684,60 @@ int usb_autopm_get_interface(struct usb_interface *intf)
 EXPORT_SYMBOL_GPL(usb_autopm_get_interface);
 
 /**
+ * usb_autopm_get_interface_upgrade - increment a USB interface's PM-usage
+ * counter
+ * @intf: the usb_interface whose counter should be incremented
+ *
+ * This routine should be called by an interface driver when it wants to
+ * use @intf and needs to guarantee that it is not suspended.  In addition,
+ * the routine prevents @intf from being autosuspended subsequently.  (Note
+ * that this will not prevent suspend events originating in the PM core.)
+ * This prevention will persist until usb_autopm_put_interface() is called
+ * or @intf is unbound.  A typical example would be a character-device
+ * driver when its device file is opened.
+ *
+ * Comparing with usb_autopm_get_interface, usb_autopm_get_interface_upgrade
+ * is more careful when resuming the device.
+ * 1) The caller's caller already resumes resume the device and hold spinlocks.
+ * usb_autopm_get_interface_upgrade couldn't call pm_runtime_get_sync;
+ * 2) The caller's caller doesn't resume the device.
+ * usb_autopm_get_interface_upgrade has to resume the device before going 
ahead.
+ *
+ * @intf's usage counter is incremented to prevent subsequent autosuspends.
+ * However if the autoresume fails then the counter is re-decremented.
+ *
+ * This routine can run only in process context.
+ *
+ * Return: 0 on success.
+ */
+int usb_autopm_get_interface_upgrade(struct usb_interface *intf)
+{
+   int status = 0;
+
+   pm_runtime_get(&intf->dev);
+   if (!pm_runtime_active(&intf->dev)) {
+   /* If not active, next _get_sync wakes device up*/
+   status = pm_runtime_get_sync(&intf->dev);
+   /*
+* If it's active, next _put_sync wouldn't
+* really put it to sleep as the 1st _get
+* keeps the device active.
+*/
+   pm_runtime_put_sync(&intf->dev);
+   if (status < 0)
+   pm_runtime_put(&intf->dev);
+   } else
+   atomic_inc(&intf->pm_usage_cnt);
+   dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n",
+   __func__, atomic_read(&intf->dev.power.usage_count),
+   status);
+   if (status > 0)
+   status = 0;
+   return status;
+}
+EXPORT_SYMBOL_GPL(usb_autopm_get_interface_upgrade);
+
+/**
  * usb_autopm_get_interface_async - increment a USB interface's PM-usage 
counter
  * @intf: the usb_interface whose counter should be incremented
  *
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 447fe29..0a8a44a 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -663,6 +663,7 @@ extern void usb_enable_autosuspend(struct usb_device *udev);
 extern void usb_disable_autosuspend(struct usb_device *udev);
 
 extern int usb_autopm_get_interface(struct usb_interface *intf);
+extern int usb_autopm_get_interface_upgrade(struct usb_interface *intf);
 extern void usb_autopm_put_interface(struct usb_interface *intf);
 extern int usb_autopm_get_interface_async(struct usb_interface *intf);
 extern void usb_autopm_put_interface_async(struct usb_interface *intf);
@@ -683,6 +684,8 @@ static inline int usb_disable_autosuspend(struct usb_device 
*udev)
 
 static inline int usb_autopm_get_interface(struct usb_interface *intf)
 { return 0; }
+static inline int usb_autopm_get_interface_upgrade(struct usb_interface *intf)
+{ return 0; }
 static inline int usb_autopm_get_interface_async(struct usb_interface *intf)
 { return 0; }
 
-- 
1.9.1


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

[PATCH V3 3/3] n_gsm: wake up ldisc tty before using it

[Zhang, Yanmin]

From: Zhang Yanmin 

Wake up ldisc device before calling its driver to access the device.

Signed-off-by: Zhang Yanmin 
---
 drivers/tty/n_gsm.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 2c34c32..f887df6 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int debug;
 module_param(debug, int, 0600);
@@ -555,6 +556,27 @@ static int gsm_stuff_frame(const u8 *input, u8 *output, 
int len)
return olen;
 }
 
+static int pm_runtime_get_sync_tty(struct tty_struct *tty)
+{
+   int ret = 0;
+
+   /* Wakeup parent as tty itself doesn't enable runtime */
+   if (tty->dev->parent)
+   ret = pm_runtime_get_sync(tty->dev->parent);
+
+   return ret;
+}
+
+static int pm_runtime_put_tty(struct tty_struct *tty)
+{
+   int ret = 0;
+
+   if (tty->dev->parent)
+   ret = pm_runtime_put(tty->dev->parent);
+
+   return ret;
+}
+
 /**
  * gsm_send-   send a control frame
  * @gsm: our GSM mux
@@ -1511,7 +1533,9 @@ static void gsm_dlci_begin_open(struct gsm_dlci *dlci)
return;
dlci->retries = gsm->n2;
dlci->state = DLCI_OPENING;
+   pm_runtime_get_sync_tty(gsm->tty);
gsm_command(dlci->gsm, dlci->addr, SABM|PF);
+   pm_runtime_put_tty(gsm->tty);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
 }
 
@@ -1533,7 +1557,9 @@ static void gsm_dlci_begin_close(struct gsm_dlci *dlci)
return;
dlci->retries = gsm->n2;
dlci->state = DLCI_CLOSING;
+   pm_runtime_get_sync_tty(gsm->tty);
gsm_command(dlci->gsm, dlci->addr, DISC|PF);
+   pm_runtime_put_tty(gsm->tty);
mod_timer(&dlci->t1, jiffies + gsm->t1 * HZ / 100);
 }
 
@@ -2286,7 +2312,9 @@ static void gsmld_receive_buf(struct tty_struct *tty, 
const unsigned char *cp,
flags = *f++;
switch (flags) {
case TTY_NORMAL:
+   pm_runtime_get_sync_tty(gsm->tty);
gsm->receive(gsm, *dp);
+   pm_runtime_put_tty(gsm->tty);
break;
case TTY_OVERRUN:
case TTY_BREAK:
@@ -2957,6 +2985,7 @@ static int gsmtty_open(struct tty_struct *tty, struct 
file *filp)
 {
struct gsm_dlci *dlci = tty->driver_data;
struct tty_port *port = &dlci->port;
+   int ret;
 
port->count++;
tty_port_tty_set(port, tty);
@@ -2968,7 +2997,11 @@ static int gsmtty_open(struct tty_struct *tty, struct 
file *filp)
/* Start sending off SABM messages */
gsm_dlci_begin_open(dlci);
/* And wait for virtual carrier */
-   return tty_port_block_til_ready(port, tty, filp);
+   pm_runtime_get_sync_tty(dlci->gsm->tty);
+   ret = tty_port_block_til_ready(port, tty, filp);
+   pm_runtime_put_tty(dlci->gsm->tty);
+
+   return ret;
 }
 
 static void gsmtty_close(struct tty_struct *tty, struct file *filp)
@@ -2986,11 +3019,14 @@ static void gsmtty_close(struct tty_struct *tty, struct 
file *filp)
gsm = dlci->gsm;
if (tty_port_close_start(&dlci->port, tty, filp) == 0)
return;
+   pm_runtime_get_sync_tty(gsm->tty);
gsm_dlci_begin_close(dlci);
if (test_bit(ASYNCB_INITIALIZED, &dlci->port.flags)) {
if (C_HUPCL(tty))
tty_port_lower_dtr_rts(&dlci->port);
}
+   pm_runtime_put_tty(gsm->tty);
+
tty_port_close_end(&dlci->port, tty);
tty_port_tty_set(&dlci->port, NULL);
return;
@@ -3012,10 +3048,12 @@ static int gsmtty_write(struct tty_struct *tty, const 
unsigned char *buf,
struct gsm_dlci *dlci = tty->driver_data;
if (dlci->state == DLCI_CLOSED)
return -EINVAL;
+   pm_runtime_get_sync_tty(dlci->gsm->tty);
/* Stuff the bytes into the fifo queue */
sent = kfifo_in_locked(dlci->fifo, buf, len, &dlci->lock);
/* Need to kick the channel */
gsm_dlci_data_kick(dlci);
+   pm_runtime_put_tty(dlci->gsm->tty);
return sent;
 }
 
-- 
1.9.1


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

[v8 8/9] iommu, x86: define irq_remapping_cap()

[Feng Wu]

This patch adds a new interface irq_remapping_cap() to detect
whether irq remapping supports new features, such as VT-d
Posted-Interrupts. We export this function out, so that KVM
code can check this and use this mechanism properly.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h | 2 ++
 drivers/iommu/irq_remapping.c| 9 +
 2 files changed, 11 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 202e040..61aa8ad 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -35,6 +35,7 @@ enum irq_remap_cap {
IRQ_POSTING_CAP = 0,
 };
 
+extern bool irq_remapping_cap(enum irq_remap_cap cap);
 extern void set_irq_remapping_broken(void);
 extern int irq_remapping_prepare(void);
 extern int irq_remapping_enable(void);
@@ -64,6 +65,7 @@ struct vcpu_data {
 
 #else  /* CONFIG_IRQ_REMAP */
 
+static bool irq_remapping_cap(enum irq_remap_cap cap) { return 0; }
 static inline void set_irq_remapping_broken(void) { }
 static inline int irq_remapping_prepare(void) { return -ENODEV; }
 static inline int irq_remapping_enable(void) { return -ENODEV; }
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index ed605a9..2d99930 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -81,6 +81,15 @@ void set_irq_remapping_broken(void)
irq_remap_broken = 1;
 }
 
+bool irq_remapping_cap(enum irq_remap_cap cap)
+{
+   if (!remap_ops || disable_irq_post)
+   return 0;
+
+   return (remap_ops->capability & (1 << cap));
+}
+EXPORT_SYMBOL_GPL(irq_remapping_cap);
+
 int __init irq_remapping_prepare(void)
 {
if (disable_irq_remap)
-- 
2.1.0

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

[v8 1/9] iommu: Add new member capability to struct irq_remap_ops

[Feng Wu]

This patch adds a new member capability to struct irq_remap_ops,
this new function ops can be used to check whether some
features are supported, such as VT-d Posted-Interrupts.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h | 4 
 drivers/iommu/irq_remapping.h| 3 +++
 2 files changed, 7 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 78974fb..0953723 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -31,6 +31,10 @@ struct irq_alloc_info;
 
 #ifdef CONFIG_IRQ_REMAP
 
+enum irq_remap_cap {
+   IRQ_POSTING_CAP = 0,
+};
+
 extern void set_irq_remapping_broken(void);
 extern int irq_remapping_prepare(void);
 extern int irq_remapping_enable(void);
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index 91d5a11..b6ca30d 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -35,6 +35,9 @@ extern int no_x2apic_optout;
 extern int irq_remapping_enabled;
 
 struct irq_remap_ops {
+   /* The supported capabilities */
+   int capability;
+
/* Initializes hardware and makes it ready for remapping interrupts */
int  (*prepare)(void);
 
-- 
2.1.0

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

[v8 2/9] iommu: dmar: Extend struct irte for VT-d Posted-Interrupts

[Feng Wu]

From: Thomas Gleixner 

The IRTE (Interrupt Remapping Table Entry) is either an entry for
remapped or for posted interrupts. The hardware distiguishes between
remapped and posted entries by bit 15 in the low 64 bit of the
IRTE. If cleared the entry is remapped, if set it's posted.

The entries have common fields and dependent on the posted bit fields
with different meanings.

Extend struct irte to handle the differences between remap and posted
mode by having three structs in the unions:

- Shared
- Remapped
- Posted

Signed-off-by: Thomas Gleixner 
Signed-off-by: Feng Wu 
---
 include/linux/dmar.h | 70 +---
 1 file changed, 55 insertions(+), 15 deletions(-)

diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 8473756..0dbcabc 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -185,33 +185,73 @@ static inline int dmar_device_remove(void *handle)
 
 struct irte {
union {
+   /* Shared between remapped and posted mode*/
struct {
-   __u64   present : 1,
-   fpd : 1,
-   dst_mode: 1,
-   redir_hint  : 1,
-   trigger_mode: 1,
-   dlvry_mode  : 3,
-   avail   : 4,
-   __reserved_1: 4,
-   vector  : 8,
-   __reserved_2: 8,
-   dest_id : 32;
+   __u64   present : 1,  /*  0  */
+   fpd : 1,  /*  1  */
+   __res0  : 6,  /*  2 -  6 */
+   avail   : 4,  /*  8 - 11 */
+   __res1  : 3,  /* 12 - 14 */
+   pst : 1,  /* 15  */
+   vector  : 8,  /* 16 - 23 */
+   __res2  : 40; /* 24 - 63 */
+   };
+
+   /* Remapped mode */
+   struct {
+   __u64   r_present   : 1,  /*  0  */
+   r_fpd   : 1,  /*  1  */
+   dst_mode: 1,  /*  2  */
+   redir_hint  : 1,  /*  3  */
+   trigger_mode: 1,  /*  4  */
+   dlvry_mode  : 3,  /*  5 -  7 */
+   r_avail : 4,  /*  8 - 11 */
+   r_res0  : 4,  /* 12 - 15 */
+   r_vector: 8,  /* 16 - 23 */
+   r_res1  : 8,  /* 24 - 31 */
+   dest_id : 32; /* 32 - 63 */
+   };
+
+   /* Posted mode */
+   struct {
+   __u64   p_present   : 1,  /*  0  */
+   p_fpd   : 1,  /*  1  */
+   p_res0  : 6,  /*  2 -  7 */
+   p_avail : 4,  /*  8 - 11 */
+   p_res1  : 2,  /* 12 - 13 */
+   p_urgent: 1,  /* 14  */
+   p_pst   : 1,  /* 15  */
+   p_vector: 8,  /* 16 - 23 */
+   p_res2  : 14, /* 24 - 37 */
+   pda_l   : 26; /* 38 - 63 */
};
__u64 low;
};
 
union {
+   /* Shared between remapped and posted mode*/
struct {
-   __u64   sid : 16,
-   sq  : 2,
-   svt : 2,
-   __reserved_3: 44;
+   __u64   sid : 16,  /* 64 - 79  */
+   sq  : 2,   /* 80 - 81  */
+   svt : 2,   /* 82 - 83  */
+   __res3  : 44;  /* 84 - 127 */
+   };
+
+   /* Posted mode*/
+   struct {
+   __u64   p_sid   : 16,  /* 64 - 79  */
+   p_sq: 2,   /* 80 - 81  */
+   p_svt   : 2,   /* 82 - 83  */
+   p_res3  : 12,  /* 84 - 95  */
+   pda_h   : 32;  /* 96 - 127 */
};
__u64 high;
};
 };
 
+#define PDA_LOW_BIT26
+#define PDA_HIGH_BIT   32
+
 enu

[v8 9/9] iommu, x86: Properly handler PI for IOMMU hotplug

[Feng Wu]

Return error when inserting a new IOMMU which doesn't support PI
if PI is currently in use.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index c21a2a9..1f35d0b 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1363,6 +1363,9 @@ int dmar_ir_hotplug(struct dmar_drhd_unit *dmaru, bool 
insert)
return -EINVAL;
if (!ecap_ir_support(iommu->ecap))
return 0;
+   if (irq_remapping_cap(IRQ_POSTING_CAP) &&
+   !cap_pi_support(iommu->cap))
+   return -EBUSY;
 
if (insert) {
if (!iommu->ir_table)
-- 
2.1.0

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

[v8 6/9] iommu, x86: Add cap_pi_support() to detect VT-d PI capability

[Feng Wu]

Add helper function to detect VT-d Posted-Interrupts capability.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 include/linux/intel-iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 0af9b03..0c251be 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -87,6 +87,7 @@ static inline void dmar_writeq(void __iomem *addr, u64 val)
 /*
  * Decoding Capability Register
  */
+#define cap_pi_support(c)  (((c) >> 59) & 1)
 #define cap_read_drain(c)  (((c) >> 55) & 1)
 #define cap_write_drain(c) (((c) >> 54) & 1)
 #define cap_max_amask_val(c)   (((c) >> 48) & 0x3f)
-- 
2.1.0

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

[v8 7/9] iommu, x86: Setup Posted-Interrupts capability for Intel iommu

[Feng Wu]

Set Posted-Interrupts capability for Intel iommu when IR is enabled,
clear it when IR is disabled.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c | 30 ++
 drivers/iommu/irq_remapping.c   |  2 ++
 drivers/iommu/irq_remapping.h   |  3 +++
 3 files changed, 35 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index d230edc..c21a2a9 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -581,6 +581,26 @@ error:
return -ENODEV;
 }
 
+/*
+ * Set Posted-Interrupts capability.
+ */
+static inline void set_irq_posting_cap(void)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+
+   if (!disable_irq_post) {
+   intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
+
+   for_each_iommu(iommu, drhd)
+   if (!cap_pi_support(iommu->cap)) {
+   intel_irq_remap_ops.capability &=
+   ~(1 << IRQ_POSTING_CAP);
+   break;
+   }
+   }
+}
+
 static int __init intel_enable_irq_remapping(void)
 {
struct dmar_drhd_unit *drhd;
@@ -656,6 +676,8 @@ static int __init intel_enable_irq_remapping(void)
 
irq_remapping_enabled = 1;
 
+   set_irq_posting_cap();
+
pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
 
return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
@@ -856,6 +878,12 @@ static void disable_irq_remapping(void)
 
iommu_disable_irq_remapping(iommu);
}
+
+   /*
+* Clear Posted-Interrupts capability.
+*/
+   if (!disable_irq_post)
+   intel_irq_remap_ops.capability &= ~(1 << IRQ_POSTING_CAP);
 }
 
 static int reenable_irq_remapping(int eim)
@@ -883,6 +911,8 @@ static int reenable_irq_remapping(int eim)
if (!setup)
goto error;
 
+   set_irq_posting_cap();
+
return 0;
 
 error:
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index fc78b0d..ed605a9 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -22,6 +22,8 @@ int irq_remap_broken;
 int disable_sourceid_checking;
 int no_x2apic_optout;
 
+int disable_irq_post = 1;
+
 static int disable_irq_remap;
 static struct irq_remap_ops *remap_ops;
 
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index b6ca30d..039c7af 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -34,6 +34,8 @@ extern int disable_sourceid_checking;
 extern int no_x2apic_optout;
 extern int irq_remapping_enabled;
 
+extern int disable_irq_post;
+
 struct irq_remap_ops {
/* The supported capabilities */
int capability;
@@ -69,6 +71,7 @@ extern void ir_ack_apic_edge(struct irq_data *data);
 
 #define irq_remapping_enabled 0
 #define irq_remap_broken  0
+#define disable_irq_post  1
 
 #endif /* CONFIG_IRQ_REMAP */
 
-- 
2.1.0

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

[v8 4/9] iommu, x86: Save the mode (posted or remapped) of an IRTE

[Feng Wu]

This patch adds a new field in struct irq_2_iommu, which can
capture whether the entry is in posted mode or remapped mode.

Signed-off-by: Feng Wu 
Suggested-by: Thomas Gleixner 
---
 drivers/iommu/intel_irq_remapping.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 1955b09..70a1b79 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -18,6 +18,11 @@
 
 #include "irq_remapping.h"
 
+enum irq_mode {
+   IRQ_REMAPPING,
+   IRQ_POSTING,
+};
+
 struct ioapic_scope {
struct intel_iommu *iommu;
unsigned int id;
@@ -37,6 +42,7 @@ struct irq_2_iommu {
u16 irte_index;
u16 sub_handle;
u8  irte_mask;
+   enum irq_mode mode;
 };
 
 struct intel_ir_data {
@@ -105,6 +111,7 @@ static int alloc_irte(struct intel_iommu *iommu, int irq,
irq_iommu->irte_index =  index;
irq_iommu->sub_handle = 0;
irq_iommu->irte_mask = mask;
+   irq_iommu->mode = IRQ_REMAPPING;
}
raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
 
@@ -145,6 +152,8 @@ static int modify_irte(struct irq_2_iommu *irq_iommu,
__iommu_flush_cache(iommu, irte, sizeof(*irte));
 
rc = qi_flush_iec(iommu, index, 0);
+
+   irq_iommu->mode = irte->pst ? IRQ_POSTING : IRQ_REMAPPING;
raw_spin_unlock_irqrestore(&irq_2_ir_lock, flags);
 
return rc;
-- 
2.1.0

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

Re: dell_rbtn - kernel panic at boot...

[Darren Hart]

On Mon, May 25, 2015 at 08:03:42AM +0200, Pali Rohár wrote:
> On Monday 25 May 2015 07:01:21 Matthew Garrett wrote:
> > On Sun, May 24, 2015 at 09:44:32PM -0700, Darren Hart wrote:
> > > Greg, Matthew, I'm tempted to recommend this 434 line driver be
> > > rolled into dell-laptop.c. Any strong opinions?
> > 
> > Mrm. It's slightly conceptually nasty in that one's an ACPI driver
> > and one's calling a Dell custom interface, but I think merging them
> > is probably the last bad answer.
> 
> I think merging does not fix our problem. dell laptop rfkill driver 
> needs to be initialized after dell-rbtn acpi driver register itself.

If they were the same driver, you could control this ordering.

> 
> And dell-laptop and dell-rbtn are two different devices (one dell smbios 
> and one acpi) and it for me it sounds like bad idea too...

We all agree it's a bad idea - the point Mathew and I made was it may be the
"least bad" idea (all the others may be worse).

I'm looking into this, but I don't have an easy answer for you. This one is
going to take some research on your part to get to the right answer.

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

[v8 5/9] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts

[Feng Wu]

We don't need to migrate the irqs for VT-d Posted-Interrupts here.
When 'pst' is set in IRTE, the associated irq will be posted to
guests instead of interrupt remapping. The destination of the
interrupt is set in Posted-Interrupts Descriptor, and the migration
happens during vCPU scheduling.

However, we still update the cached irte here, which can be used
when changing back to remapping mode.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 drivers/iommu/intel_irq_remapping.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 70a1b79..d230edc 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1003,7 +1003,10 @@ intel_ir_set_affinity(struct irq_data *data, const 
struct cpumask *mask,
 */
irte->vector = cfg->vector;
irte->dest_id = IRTE_DEST(cfg->dest_apicid);
-   modify_irte(&ir_data->irq_2_iommu, irte);
+
+   /* Update the hardware only if the interrupt is in remapped mode. */
+   if (ir_data->irq_2_iommu.mode == IRQ_REMAPPING)
+   modify_irte(&ir_data->irq_2_iommu, irte);
 
/*
 * After this point, all the interrupts will start arriving
-- 
2.1.0

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

[v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

[Feng Wu]

Implement irq_set_vcpu_affinity for intel_ir_chip.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 arch/x86/include/asm/irq_remapping.h |  5 
 drivers/iommu/intel_irq_remapping.c  | 46 
 2 files changed, 51 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 0953723..202e040 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -57,6 +57,11 @@ static inline struct irq_domain 
*arch_get_ir_parent_domain(void)
return x86_vector_domain;
 }
 
+struct vcpu_data {
+   u64 pi_desc_addr;   /* Physical address of PI Descriptor */
+   u32 vector; /* Guest vector of the interrupt */
+};
+
 #else  /* CONFIG_IRQ_REMAP */
 
 static inline void set_irq_remapping_broken(void) { }
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 8fad71c..1955b09 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -42,6 +42,7 @@ struct irq_2_iommu {
 struct intel_ir_data {
struct irq_2_iommu  irq_2_iommu;
struct irte irte_entry;
+   struct irte irte_pi_entry;
union {
struct msi_msg  msi_entry;
};
@@ -1013,10 +1014,55 @@ static void intel_ir_compose_msi_msg(struct irq_data 
*irq_data,
*msg = ir_data->msi_entry;
 }
 
+static int intel_ir_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
+{
+   struct intel_ir_data *ir_data = data->chip_data;
+   struct irte *irte_pi = &ir_data->irte_pi_entry;
+   struct vcpu_data *vcpu_pi_info;
+
+   /* stop posting interrupts, back to remapping mode */
+   if (!vcpu_info) {
+   modify_irte(&ir_data->irq_2_iommu, &ir_data->irte_entry);
+   } else {
+   vcpu_pi_info = (struct vcpu_data *)vcpu_info;
+
+   /*
+* "ir_data->irte_entry" saves the remapped format of IRTE,
+* which being a cached irte is still updated when setting
+* the affinity even when we are in posted mode. So this make
+* it possible to switch back to remapped mode from posted mode,
+* we can just set "ir_data->irte_entry" to hardware for that
+* purpose. Here we store the posted format of IRTE in another
+* new member "ir_data->irte_pi_entry" to not corrupt
+* "ir_data->irte_entry".
+*/
+   memcpy(irte_pi, &ir_data->irte_entry, sizeof(struct irte));
+
+   irte_pi->p_urgent = 0;
+   irte_pi->p_vector = vcpu_pi_info->vector;
+   irte_pi->pda_l = (vcpu_pi_info->pi_desc_addr >>
+(32 - PDA_LOW_BIT)) & ~(-1UL << PDA_LOW_BIT);
+   irte_pi->pda_h = (vcpu_pi_info->pi_desc_addr >> 32) &
+~(-1UL << PDA_HIGH_BIT);
+
+   irte_pi->p_res0 = 0;
+   irte_pi->p_res1 = 0;
+   irte_pi->p_res2 = 0;
+   irte_pi->p_res3 = 0;
+
+   irte_pi->p_pst = 1;
+
+   modify_irte(&ir_data->irq_2_iommu, irte_pi);
+   }
+
+   return 0;
+}
+
 static struct irq_chip intel_ir_chip = {
.irq_ack = ir_ack_apic_edge,
.irq_set_affinity = intel_ir_set_affinity,
.irq_compose_msi_msg = intel_ir_compose_msi_msg,
+   .irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity,
 };
 
 static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
-- 
2.1.0

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

[v8 0/9] Add VT-d Posted-Interrupts support - IOMMU part

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

This series was part of http://thread.gmane.org/gmane.linux.kernel.iommu/7708. 
To make things clear, send out IOMMU part here.

This patch-set is based on the lastest x86/apic branch of tip tree.

Divide the whole series which contain multiple components into three parts:
- Prerequisite changes to irq subsystem (already merged in tip tree x86/apic 
branch)
- IOMMU part (in this series)
- KVM and VFIO parts (will send out this part once the first two parts are 
accepted)

v7->v8:
* Save the irq mode (posted or remapped) of an IRTE in struct irq_2_iommu.
* Use this new mode to decide whether update the hardware when
modifying irte in intel_ir_set_affinity().

v6->v7:
* Add an static inline helper function set_irq_posting_cap() to set
the PI capability.
* Add some comments for the new member "ir_data->irte_pi_entry".

v5->v6:
* Extend 'struct irte' for VT-d Posted-Interrupts, combine remapped
and posted mode into one irte structure.

v4->v5:
* Abstract modify_irte() to accept two format of irte.

v3->v4:
* Change capability to a int variant flags instead of a function call.
* Add hotplug case for VT-d PI.

Feng Wu (8):
  iommu: Add new member capability to struct irq_remap_ops
  iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip
  iommu, x86: Save the mode (posted or remapped) of an IRTE
  iommu, x86: No need to migrating irq for VT-d Posted-Interrupts
  iommu, x86: Add cap_pi_support() to detect VT-d PI capability
  iommu, x86: Setup Posted-Interrupts capability for Intel iommu
  iommu, x86: define irq_remapping_cap()
  iommu, x86: Properly handler PI for IOMMU hotplug

Thomas Gleixner (1):
  iommu: dmar: Extend struct irte for VT-d Posted-Interrupts

 arch/x86/include/asm/irq_remapping.h | 11 +
 drivers/iommu/intel_irq_remapping.c  | 93 +++-
 drivers/iommu/irq_remapping.c| 11 +
 drivers/iommu/irq_remapping.h|  6 +++
 include/linux/dmar.h | 70 +--
 include/linux/intel-iommu.h  |  1 +
 6 files changed, 176 insertions(+), 16 deletions(-)

-- 
2.1.0

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

Re: [RFC PATCH 2/2] arm64: Implement vmalloc based thread_info allocator

[Minchan Kim]

On Tue, May 26, 2015 at 09:10:11PM +0900, Jungseok Lee wrote:
> On May 25, 2015, at 11:58 PM, Minchan Kim wrote:
> > On Mon, May 25, 2015 at 07:01:33PM +0900, Jungseok Lee wrote:
> >> On May 25, 2015, at 2:49 AM, Arnd Bergmann wrote:
> >>> On Monday 25 May 2015 01:02:20 Jungseok Lee wrote:
>  Fork-routine sometimes fails to get a physically contiguous region for
>  thread_info on 4KB page system although free memory is enough. That is,
>  a physically contiguous region, which is currently 16KB, is not available
>  since system memory is fragmented.
>  
>  This patch tries to solve the problem as allocating thread_info memory
>  from vmalloc space, not 1:1 mapping one. The downside is one additional
>  page allocation in case of vmalloc. However, vmalloc space is large 
>  enough,
>  around 240GB, under a combination of 39-bit VA and 4KB page. Thus, it is
>  not a big tradeoff for fork-routine service.
> >>> 
> >>> vmalloc has a rather large runtime cost. I'd argue that failing to 
> >>> allocate
> >>> thread_info structures means something has gone very wrong.
> >> 
> >> That is why the feature is marked "N" by default.
> >> I focused on fork-routine stability rather than performance.
> > 
> > If VM has trouble with order-2 allocation, your system would be
> > trouble soon although fork at the moment manages to be successful
> > because such small high-order(ex, order <= PAGE_ALLOC_COSTLY_ORDER)
> > allocation is common in the kernel so VM should handle it smoothly.
> > If VM didn't, it means we should fix VM itself, not a specific
> > allocation site. Fork is one of victim by that.
> 
> A problem I observed is an user space, not a kernel side. As user applications
> fail to create threads in order to distribute their jobs properly, they are 
> getting
> in trouble slowly and then gone.
> 
> Yes, fork is one of victim, but damages user applications seriously.
> At this snapshot, free memory is enough.

Yes, it's the one you found.

*Free memory is enough but why forking was failed*

You should find the exact reason for it rather than papering over by
hiding forking fail.

1. Investigate how many of movable/unmovable page ratio at the moment
2. Investigate why compaction doesn't work
3. Investigate why reclaim couldn't make order-2 page


> 
> >> Could you give me an idea how to evaluate performance degradation?
> >> Running some benchmarks would be helpful, but I would like to try to
> >> gather data based on meaningful methodology.
> >> 
> >>> Can you describe the scenario that leads to fragmentation this bad?
> >> 
> >> Android, but I could not describe an exact reproduction procedure step
> >> by step since it's behaved and reproduced randomly. As reading the 
> >> following
> >> thread from mm mailing list, a similar symptom is observed on other 
> >> systems. 
> >> 
> >> https://lkml.org/lkml/2015/4/28/59
> >> 
> >> Although I do not know the details of a system mentioned in the thread,
> >> even order-2 page allocation is not smoothly operated due to fragmentation 
> >> on
> >> low memory system.
> > 
> > What Joonsoo have tackle is generic fragmentation problem, not *a* fork 
> > fail,
> > which is more right approach to handle small high-order allocation problem.
> 
> I totally agree with that point. One of the best ways is to figure out a 
> generic
> anti-fragmentation with VM system improvement. Reducing the stack size to 8KB 
> is also
> a really great approach. My intention is not to overlook them or figure out a 
> workaround.
> 
> IMHO, vmalloc would be a different option in case of ARM64 on low memory 
> systems since
> *fork failure from fragmentation* is a nontrivial issue.
> 
> Do you think the patch set doesn't need to be considered?

I don't know because the changelog doesn't have full description
about your problem. You just wrote "forking was failed so we want
to avoid that by vmalloc because forking is important".
It seems to me it is just bandaid.

What you should provide for description is

" Forking was failed although there were lots of free pages
  so I investigated it and found root causes in somewhere
  so this patch fixes the problem"

Thanks.


> 
> Best Regards
> Jungseok Lee

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dell_rbtn - kernel panic at boot...

[Darren Hart]

On Tue, May 26, 2015 at 09:09:30PM -0700, Darren Hart wrote:
> On Mon, May 25, 2015 at 04:40:14PM +0200, Pali Rohár wrote:
> > On Sunday 24 May 2015 21:44:32 Darren Hart wrote:
> > > On Sat, May 23, 2015 at 03:05:36AM +0200, Pali Rohár wrote:
> > > > On Saturday 23 May 2015 00:53:16 Dmitry Torokhov wrote:
> > > > > On Thu, May 21, 2015 at 7:06 PM, Valdis Kletnieks
> > > > > 
> > > > >  wrote:
> > > > > > So after I made both config variables =y, the resulting kernel
> > > > > > built, but died a glorious death at boot.
> > > > > 
> > > > > I guess if both are built-in then, according to link order,
> > > > > dell-laptop starts first, before dell-rbtn, and dies in
> > > > > dell_rbtn_notifier_register() in call to
> > > > > driver_for_each_device(&rbtn_driver.drv, ...) because rbtn_driver has
> > > > > not been registered yet and thus half-initlalized.
> > > > > 
> > > > > Thanks.
> > > > 
> > > > pr_debug() messages could be useful... but no idea if we can get them.
> > > > 
> > > > Is there any way to fix that dependency race condition? Could 
> > > > driver_attach() function call help?
> > > 
> > > I believe you can avoid this by moving dell-rbtn earlier in the Makefile 
> > > than
> > > dell-laptop - but this is fragile and a hack to resolve a dependency 
> > > problem.
> > > 
> > 
> > And what about that late_initcall() instead module_init() in dell-laptop?
> > Will it fix this problem?
> > 
> 
> No, because late_initcall() for modules is module_init(). See
> include/linux/init.h.

Apologies, in this context we're concerned about built-in, not module.

This might function as desired.

module_init() is defined as device_initcall (level 6) for built-in
late_initcall() is level 7

There is precedent for this under drivers/ - although not in anything that stood
out to me as a good exemplar. See:

b233020 Input: gpio_keys - move to late_initcall

for an example with a similar purpose.

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

Re: [PATCH] usb: ulpi: don't register drivers if bus doesn't exist

[Sudip Mukherjee]

On Tue, May 26, 2015 at 07:41:18PM -0700, Greg KH wrote:
> On Tue, May 26, 2015 at 10:54:01AM -0700, David Cohen wrote:
> > Hi,
> > 
> > On Mon, May 25, 2015 at 07:00:13PM +0200, Bjørn Mork wrote:
> > > Greg KH  writes:
> > > 
> Don't mess with bus->p.  I can rename it to
> "do_not_touch_this_isnt_for_you" if people think that would make it more
> obvious that a private data structure shouldn't be messed with in any
> way.  Outside of the driver core, you have no knowledge that even if it
> is a pointer, what that means with regards to anything.
Being a newbie I had a newbie kind of doubt that if a module is builtin
and the init fails then what happens to the functions exported by it.
And to test that I created a module:
int abcd(void)
{
pr_err("test: in abcd\n");
return 0;
}
EXPORT_SYMBOL(abcd);

static int __init test_init(void)
{
return -ENOMEM;
}
module_init(test_init);

static void __exit test_exit(void)
{
}
module_exit(test_exit);

Compiled it as builtin, and created another module which calls abcd();
and as expected abcd() executed.

So same thing can happen here also:
if bus_register() in ulpi_init() fails then also ulpi_unregister_driver()
can be executed as the symbol has been exported. you are saying bus->p is
private and not to use that but you are also saying that if we use another
variable to keep the status of bus registration then the design is wrong.
Then what should be the correct way?

regards
sudip

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

Re: [Patch v3] apple-gmux: lock iGP IO to protect from vgaarb changes

[Darren Hart]

On Tue, May 26, 2015 at 12:10:48PM -0700, Michael Marineau wrote:
> FYI, this actually broke backlight controls on my MBP11,3 because the
> assumption the patch makes that gmux is always loaded before graphics
> drivers didn't hold true. At least for me dracut included the nouveau
> module in the initrd but not gmux, ensuring the ordering was wrong. No
> errors were reporting, and gmux still offered the backlight device, it
> just became inoperable. I worked around this for my kernel by building
> gmux into vmlinuz instead of as a module but that isn't going to in
> more general configs because there is an apple backlight driver which
> cannot be built at all in that configuration.
> 

Thank you for reporting this Michael,

That is tough as nouveau doesn't have an explicit dependency on gmux, so we
could do something like a passive request_module(), but if it isn't in the
initrd image, it would still fail as you describe.

> Is there a way to make the ordering between nouveau and gmux more
> explicit/reliable? Can gmux complain loudly if the ordering is ever
> wrong?

It should print an error if the probe fails due to the IO already being in use
or if it can't be allocated. The disabled IO case is only info level though,
perhaps that should be higher priority. Printing something when failing to probe
seems like a reasonable thing to do.

Michael, which message do you get if you boot with "debug" or "loglevel=6" when
apple-gmux is not built-in?

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

Re: [PATCH] ACPI / property: Define a symbol for PRP0001

[Darren Hart]

On Fri, May 22, 2015 at 04:24:34AM +0200, Rafael Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Use a #defined symbol ACPI_DT_NAMESPACE_HID instead of the PRP0001
> string.
> 
> Signed-off-by: Rafael J. Wysocki 

That's a worthy improvement for both legibility as well as maintenance.

Reviewed-by: Darren Hart 

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

Re: [PATCH v2 2/2] ALSA: set no sound proc fs for reduced memory footprint

[Sudip Mukherjee]

On Tue, May 26, 2015 at 09:13:57PM +0800, Jie Yang wrote:
> Disable sound proc fs, when CONFIG_SND_NO_PROC_FS is selected,
> which can save about 9KB memory size for reducing memory
> footprint purpose.
> ---
missing Signed-off-by.

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

Re: [PATCH 02/36] mmu_notifier: keep track of active invalidation ranges v3

[Aneesh Kumar K.V]

j.gli...@gmail.com writes:

> From: Jérôme Glisse 
>
> The mmu_notifier_invalidate_range_start() and 
> mmu_notifier_invalidate_range_end()
> can be considered as forming an "atomic" section for the cpu page table update
> point of view. Between this two function the cpu page table content is 
> unreliable
> for the address range being invalidated.
>
> Current user such as kvm need to know when they can trust the content of the 
> cpu
> page table. This becomes even more important to new users of the mmu_notifier
> api (such as HMM or ODP).

I don't see kvm using the new APIs in this patch. Also what is that HMM use this
for, to protect walking of mirror page table ?. I am sure you are
covering that in the later patches. May be you may want to mention
the details here too. 

>
> This patch use a structure define at all call site to invalidate_range_start()
> that is added to a list for the duration of the invalidation. It adds two new
> helpers to allow querying if a range is being invalidated or to wait for a 
> range
> to become valid.
>
> For proper synchronization, user must block new range invalidation from inside
> there invalidate_range_start() callback, before calling the helper functions.
> Otherwise there is no garanty that a new range invalidation will not be added
> after the call to the helper function to query for existing range.
>
> Changed since v1:
>   - Fix a possible deadlock in mmu_notifier_range_wait_valid()
>
> Changed since v2:
>   - Add the range to invalid range list before calling ->range_start().
>   - Del the range from invalid range list after calling ->range_end().
>   - Remove useless list initialization.
>

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MAINTAINERS: update Emulex ocrdma email addresses

[Devesh Sharma]

Thanks Laurent,

My earlier mail bounced back from Linux-kernel mailing list, thus
resending.

CC'ing Doug.

Acked-By: Devesh Sharma 


> -Original Message-
> From: Laurent Navet [mailto:laurent.na...@gmail.com]
> Sent: Wednesday, May 27, 2015 12:46 AM
> To: a...@linux-foundation.org; gre...@linuxfoundation.org;
> da...@davemloft.net; mche...@osg.samsung.com; a...@arndb.de;
> j...@perches.com; jingooh...@gmail.com; selvin.xav...@avagotech.com;
> devesh.sha...@avagotech.com; mitesh.ah...@avagotech.com
> Cc: linux-kernel@vger.kernel.org; Laurent Navet
> Subject: [PATCH] MAINTAINERS: update Emulex ocrdma email addresses
>
> @emulex.com addresses respond to use @avagotech.com.
>
> Signed-off-by: Laurent Navet 
> ---
>  MAINTAINERS | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f8e0afb..05766f7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8846,9 +8846,9 @@ S:  Supported
>  F:   drivers/net/ethernet/emulex/benet/
>
>  EMULEX ONECONNECT ROCE DRIVER
> -M:   Selvin Xavier 
> -M:   Devesh Sharma 
> -M:   Mitesh Ahuja 
> +M:   Selvin Xavier 
> +M:   Devesh Sharma 
> +M:   Mitesh Ahuja 
>  L:   linux-r...@vger.kernel.org
>  W:   http://www.emulex.com
>  S:   Supported
> --
> 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH-v2 0/4] target: Eliminate se_port + t10_alua_tg_pt_gp_member

[Nicholas A. Bellinger]

On Tue, 2015-05-26 at 14:44 +0200, Bart Van Assche wrote:
> On 05/26/15 08:57, Nicholas A. Bellinger wrote:
> >- Add various rcu_dereference and lockless_dereference RCU notation
> 
> Hello Nic,
> 
> Feedback from an RCU expert (which I'm not) would be appreciated here. 
> But my understanding is that lockless_dereference(p) should be used for 
> a pointer p that has *not* been annotated as an RCU pointer. I think in 
> the for-next branch of the target repository that this macro is used to 
> access RCU-annotated pointers. Is that why sparse complains about how 
> lockless_dereference() is used in the target tree ?
> 

Was curious about this myself..  Thanks for raising the question!

The intention of lockless_dereference() in both this and preceding
series is for __rcu protected pointers that are accessed outside of
rcu_read_lock() protection, and who's lifetime is controlled by a:

  - struct kref
  - struct percpu_ref
  - struct config_group symlink
  - RCU updater path with some manner of mutex or spinlock held

This is supposed to be following Paul's comment in rcupdate.h:

 * Similar to rcu_dereference(), but for situations where the pointed-to
 * object's lifetime is managed by something other than RCU.  That
 * "something other" might be reference counting or simple immortality.

Paul, would you be to kind to clarify the intention for us..?

Thank you,

--nab

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

RE: [PATCH 1/1] dw_mmc: insmod followed by rmmod will hung for eMMC

[Prabu Thangamuthu]

Hi Ulf, Jaehoon,

Thanks for your comments, I will update and send a new Patch.

> On  05/27/2015 7:20 AM, Jaehoon Chung Wrote:
>
> Hi, Pradu.
> 
> Sorry for late.
No Problem.
> I will wait for your next version than i will check yours.
> To Ulf.
> 
> Thanks for review!
> 
> Best Regards,
> Jaehoon Chung
> 
> On 05/22/2015 10:21 PM, Ulf Hansson wrote:
> > On 18 May 2015 at 16:23, Prabu Thangamuthu 
> wrote:
> >> Removing dw_mmc driver immediately after inserting the dw_mmc driver
> >> is
> >
> > I guess it hangs even if you remove it after a couple of days? :-)
> >
> > Perhaps makes this a bit more clear?
> >
> >> getting hung for eMMC device. Root cause for this issue is,
> >> dw_mci_remove will disable all the interrupts then it will call
> dw_mci_cleanup_slot.
> >> dw_mci_cleanup_slot is issuing CMD6 to disable boot partition access
> >> and it's waiting for command complete interrupt. Since INTMASK was
> >> already cleared by dw_mci_remove, command complete interrupt is not
> >> reaching the system. This leads to process hung.
> >
> > /s dw_mci_remove / dw_mci_remove()
> >
> >>
> >> Signed-off-by: Prabu Thangamuthu 
> >
> > This patch looks good overall, but please send a new version with
> > updated changelog. Moreover, please use "mmc: dw_mmc:" as prefix for
> > the commit message header.
> >
> > Kind regards
> > Uffe
> >
> >> ---
> >>  drivers/mmc/host/dw_mmc.c |6 +++---
> >>  1 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> >> index 5f5adaf..f0a0aff 100644
> >> --- a/drivers/mmc/host/dw_mmc.c
> >> +++ b/drivers/mmc/host/dw_mmc.c
> >> @@ -2941,15 +2941,15 @@ void dw_mci_remove(struct dw_mci *host)  {
> >> int i;
> >>
> >> -   mci_writel(host, RINTSTS, 0x);
> >> -   mci_writel(host, INTMASK, 0); /* disable all mmc interrupt first */
> >> -
> >> for (i = 0; i < host->num_slots; i++) {
> >> dev_dbg(host->dev, "remove slot %d\n", i);
> >> if (host->slot[i])
> >> dw_mci_cleanup_slot(host->slot[i], i);
> >> }
> >>
> >> +   mci_writel(host, RINTSTS, 0x);
> >> +   mci_writel(host, INTMASK, 0); /* disable all mmc interrupt
> >> + first */
> >> +
> >> /* disable clock to CIU */
> >> mci_writel(host, CLKENA, 0);
> >> mci_writel(host, CLKSRC, 0);
> >> --
> >> 1.7.6.5
> >

Thanks & Regards,
Prabu Thangamuthu.

Re: [PATCH 03/36] mmu_notifier: pass page pointer to mmu_notifier_invalidate_page()

[Aneesh Kumar K.V]

j.gli...@gmail.com writes:

> From: Jérôme Glisse 
>
> Listener of mm event might not have easy way to get the struct page
> behind and address invalidated with mmu_notifier_invalidate_page()
> function as this happens after the cpu page table have been clear/
> updated. This happens for instance if the listener is storing a dma
> mapping inside its secondary page table. To avoid complex reverse
> dma mapping lookup just pass along a pointer to the page being
> invalidated.

.

> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index ada3ed1..283ad26 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -172,6 +172,7 @@ struct mmu_notifier_ops {
>   void (*invalidate_page)(struct mmu_notifier *mn,
>   struct mm_struct *mm,
>   unsigned long address,
> + struct page *page,
>   enum mmu_event event);
>  

How do we handle this w.r.t invalidate_range ? 

-aneesh

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

[RFC PATCH v4 05/29] bpf tools: Allow caller to set printing function

[Wang Nan]

By libbpf_set_print(), users of libbpf are allowed to register he/she
own debug, info and warning printing functions. Libbpf will use those
functions to print messages. If not provided, default info and warning
printing functions are fprintf(stderr, ...); defailt debug printing
is NULL.

This API is designed to be used by perf, enables it to register its own
logging functions to make all logs uniform, instead of separated
logging level control.

Acked-by: Alexei Starovoitov 
Signed-off-by: Wang Nan 
---
 tools/lib/bpf/libbpf.c | 43 +++
 tools/lib/bpf/libbpf.h |  4 
 2 files changed, 47 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index c08d6bc..49091c3 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -7,8 +7,51 @@
  */
 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
 #include "libbpf.h"
+
+#define __printf(a, b) __attribute__((format(printf, a, b)))
+
+__printf(1, 2)
+static int __base_pr(const char *format, ...)
+{
+   va_list args;
+   int err;
+
+   va_start(args, format);
+   err = vfprintf(stderr, format, args);
+   va_end(args);
+   return err;
+}
+
+static __printf(1, 2) int (*__pr_warning)(const char *format, ...) =
+   __base_pr;
+static __printf(1, 2) int (*__pr_info)(const char *format, ...) =
+   __base_pr;
+static __printf(1, 2) int (*__pr_debug)(const char *format, ...) =
+   NULL;
+
+#define __pr(func, fmt, ...)   \
+do {   \
+   if ((func)) \
+   (func)("libbpf: " fmt, ##__VA_ARGS__); \
+} while(0)
+
+#define pr_warning(fmt, ...)   __pr(__pr_warning, fmt, ##__VA_ARGS__)
+#define pr_info(fmt, ...)  __pr(__pr_info, fmt, ##__VA_ARGS__)
+#define pr_debug(fmt, ...) __pr(__pr_debug, fmt, ##__VA_ARGS__)
+
+void libbpf_set_print(int (*warn)(const char *format, ...),
+ int (*info)(const char *format, ...),
+ int (*debug)(const char *format, ...))
+{
+   __pr_warning = warn;
+   __pr_info = info;
+   __pr_debug = debug;
+}
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a6f46d9..430b122 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -8,4 +8,8 @@
 #ifndef __BPF_LIBBPF_H
 #define __BPF_LIBBPF_H
 
+void libbpf_set_print(int (*warn)(const char *format, ...),
+ int (*info)(const char *format, ...),
+ int (*debug)(const char *format, ...));
+
 #endif
-- 
1.8.3.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/

[RFC PATCH v4 09/29] bpf tools: Collect version and license from ELF sections

[Wang Nan]

Expand bpf_obj_elf_collect() to collect license and kernel version
information in eBPF object file. eBPF object file should have a section
named 'license', which contains a string. It should also have a section
named 'version', contains a u32 LINUX_VERSION_CODE.

bpf_obj_validate() is introduced to validate object file after loaded.
Currently it only check existance of 'version' section.

Signed-off-by: Wang Nan 
---
 tools/lib/bpf/libbpf.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 16e47a3..15525ad 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -81,6 +82,8 @@ void libbpf_set_print(int (*warn)(const char *format, ...),
 #endif
 
 struct bpf_object {
+   char license[64];
+   u32 kern_version;
/*
 * Information when doing elf related work. Only valid if fd
 * is valid.
@@ -197,6 +200,32 @@ mismatch:
return -EINVAL;
 }
 
+static int
+bpf_object__init_license(struct bpf_object *obj,
+void *data, size_t size)
+{
+   memcpy(obj->license, data,
+  min(size, sizeof(obj->license) - 1));
+   pr_debug("license of %s is %s\n", obj->path, obj->license);
+   return 0;
+}
+
+static int
+bpf_object__init_kversion(struct bpf_object *obj,
+ void *data, size_t size)
+{
+   u32 kver;
+   if (size < sizeof(kver)) {
+   pr_warning("invalid kver section in %s\n", obj->path);
+   return -EINVAL;
+   }
+   memcpy(&kver, data, sizeof(kver));
+   obj->kern_version = kver;
+   pr_debug("kernel version of %s is %x\n", obj->path,
+obj->kern_version);
+   return 0;
+}
+
 static int bpf_object__elf_collect(struct bpf_object *obj)
 {
Elf *elf = obj->efile.elf;
@@ -243,11 +272,32 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
 name, (unsigned long)data->d_size,
 (int)sh.sh_link, (unsigned long)sh.sh_flags,
 (int)sh.sh_type);
+
+   if (strcmp(name, "license") == 0)
+   err = bpf_object__init_license(obj,
+  data->d_buf,
+  data->d_size);
+   else if (strcmp(name, "version") == 0)
+   err = bpf_object__init_kversion(obj,
+   data->d_buf,
+   data->d_size);
+   if (err)
+   goto out;
}
 out:
return err;
 }
 
+static int bpf_object__validate(struct bpf_object *obj)
+{
+   if (obj->kern_version == 0) {
+   pr_warning("%s doesn't provide kernel version\n",
+  obj->path);
+   return -EINVAL;
+   }
+   return 0;
+}
+
 struct bpf_object *bpf_object__open(const char *path)
 {
struct bpf_object *obj;
@@ -273,6 +323,8 @@ struct bpf_object *bpf_object__open(const char *path)
goto out;
if (bpf_object__elf_collect(obj))
goto out;
+   if (bpf_object__validate(obj))
+   goto out;
 
bpf_object__elf_finish(obj);
return obj;
-- 
1.8.3.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/

[RFC PATCH v4 27/29] perf record: Load all eBPF object into kernel

[Wang Nan]

This patch utilizes bpf_load_object() provided by libbpf to load all
objects into kernel.

Signed-off-by: Wang Nan 
---
 tools/perf/builtin-record.c  | 12 
 tools/perf/util/bpf-loader.c | 19 +++
 tools/perf/util/bpf-loader.h |  1 +
 3 files changed, 32 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 9297800..4b52399 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -970,6 +970,18 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
return err;
}
 
+   /*
+* bpf__probe() also calls symbol__init() if there are probe
+* events in bpf objects, so calling symbol_exit when failuer
+* is safe. If there is no probe event, bpf__load() always
+* success.
+*/
+   err = bpf__load();
+   if (err) {
+   pr_err("Loading BPF programs failed\n");
+   goto out_symbol_exit;
+   }
+
symbol__init(NULL);
 
if (symbol_conf.kptr_restrict)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index f5d5f3e..f9a1ab9 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -224,3 +224,22 @@ int bpf__probe(void)
 
return err < 0 ? err : 0;
 }
+
+int bpf__load(void)
+{
+   struct bpf_object *obj, *tmp;
+   int err = 0;
+
+   bpf_object__for_each(obj, tmp) {
+   err = bpf_object__load(obj);
+   if (err) {
+   pr_err("bpf: load objects failed\n");
+   goto errout;
+   }
+   }
+   return 0;
+errout:
+   bpf_object__for_each(obj, tmp)
+   bpf_object__unload(obj);
+   return err;
+}
diff --git a/tools/perf/util/bpf-loader.h b/tools/perf/util/bpf-loader.h
index 1127880..fcc775d 100644
--- a/tools/perf/util/bpf-loader.h
+++ b/tools/perf/util/bpf-loader.h
@@ -10,6 +10,7 @@
 int bpf__prepare_load(const char *filename);
 int bpf__probe(void);
 int bpf__unprobe(void);
+int bpf__load(void);
 
 void bpf__clear(void);
 #endif
-- 
1.8.3.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: [v4 1/4] arm64: kvm: add a cpu tear-down function

[AKASHI Takahiro]

Marc,

Thank you for your reviews:

On 05/26/2015 06:26 PM, Marc Zyngier wrote:

Hi Takahiro,

On 08/05/15 02:18, AKASHI Takahiro wrote:

Cpu must be put back into its initial state, at least, in the
following cases in order to shutdown the system and/or re-initialize cpus
later on:
1) kexec/kdump
2) cpu hotplug (offline)
3) removing kvm as a module

To address those issues in later patches, this patch adds a tear-down
function, kvm_cpu_reset(), that disables D-cache & MMU and restore a vector
table to the initial stub at EL2.

Signed-off-by: AKASHI Takahiro 
---
  arch/arm/kvm/arm.c|   15 +++
  arch/arm/kvm/mmu.c|5 +
  arch/arm64/include/asm/kvm_asm.h  |1 +
  arch/arm64/include/asm/kvm_host.h |   11 +++
  arch/arm64/include/asm/kvm_mmu.h  |7 +++
  arch/arm64/include/asm/virt.h |   11 +++
  arch/arm64/kvm/hyp-init.S |   32 
  arch/arm64/kvm/hyp.S  |   16 +---
  8 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 07e7eb1..251ab9e 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -897,6 +897,21 @@ static void cpu_init_hyp_mode(void *dummy)
__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
  }

+static void kvm_cpu_reset(void *dummy)


It looks like you can entirely loose the "dummy" parameter. The only
reason some function have this is when they are used from an IPI call.


OK. I will remove all of them.


+{
+   phys_addr_t boot_pgd_ptr;
+   phys_addr_t phys_idmap_start;
+
+   if (__hyp_get_vectors() == hyp_default_vectors)
+   return;
+
+   boot_pgd_ptr = kvm_mmu_get_boot_httbr();
+   phys_idmap_start = kvm_get_idmap_start();
+   __cpu_reset_hyp_mode(boot_pgd_ptr, phys_idmap_start,
+hyp_default_vectors,
+kvm_virt_to_trampoline(__kvm_hyp_reset));
+}
+
  static int hyp_init_cpu_notify(struct notifier_block *self,
   unsigned long action, void *cpu)
  {
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 3e6859b..3631a37 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1490,6 +1490,11 @@ phys_addr_t kvm_get_idmap_vector(void)
return hyp_idmap_vector;
  }

+phys_addr_t kvm_get_idmap_start(void)
+{
+   return hyp_idmap_start;
+}
+
  int kvm_mmu_init(void)
  {
int err;
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 4f7310f..f1c16e2 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -118,6 +118,7 @@ struct kvm_vcpu;

  extern char __kvm_hyp_init[];
  extern char __kvm_hyp_init_end[];
+extern char __kvm_hyp_reset[];

  extern char __kvm_hyp_vector[];

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index 8ac3c70..6a8da9c 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -199,6 +199,8 @@ struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
  struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void);

  u64 kvm_call_hyp(void *hypfn, ...);
+void kvm_call_reset(phys_addr_t boot_pgd_ptr, phys_addr_t phys_idmap_start,
+   unsigned long stub_vector_ptr, unsigned long reset_func);
  void force_vm_exit(const cpumask_t *mask);
  void kvm_mmu_wp_memory_region(struct kvm *kvm, int slot);

@@ -223,6 +225,15 @@ static inline void __cpu_init_hyp_mode(phys_addr_t 
boot_pgd_ptr,
 hyp_stack_ptr, vector_ptr);
  }

+static inline void __cpu_reset_hyp_mode(phys_addr_t boot_pgd_ptr,
+   phys_addr_t phys_idmap_start,
+   unsigned long stub_vector_ptr,
+   unsigned long reset_func)
+{
+   kvm_call_reset(boot_pgd_ptr, phys_idmap_start, stub_vector_ptr,
+  reset_func);
+}
+
  struct vgic_sr_vectors {
void*save_vgic;
void*restore_vgic;
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 6458b53..facfd6d 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -96,6 +96,7 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);
  phys_addr_t kvm_mmu_get_httbr(void);
  phys_addr_t kvm_mmu_get_boot_httbr(void);
  phys_addr_t kvm_get_idmap_vector(void);
+phys_addr_t kvm_get_idmap_start(void);
  int kvm_mmu_init(void);
  void kvm_clear_hyp_idmap(void);

@@ -305,5 +306,11 @@ static inline void __kvm_flush_dcache_pud(pud_t pud)
  void kvm_set_way_flush(struct kvm_vcpu *vcpu);
  void kvm_toggle_cache(struct kvm_vcpu *vcpu, bool was_enabled);

+extern char __hyp_idmap_text_start[];


If you're defining it here, then it worth considering removing the
similar declaration from mmu.c.


Yes. I will remove them from mmu.c.


+#define kvm_virt_to_trampoline(x

[RFC PATCH v4 28/29] perf tools: Add bpf_fd field to evsel and config it

[Wang Nan]

This patch adds a bpf_fd field to 'struct evsel' then introduces method
to config it. In bpf-loader, a bpf__for_each_program() function is added.
Which calls the callback function for each eBPF program with their names
and file descriptors. In evlist.c, perf_evlist__add_bpf()
is added to add all bpf events into evlist. 'perf record' calls
perf_evlist__add_bpf().

Since bpf-loader.c will not built if libelf not found, an empty
bpf__for_each_program() is defined in bpf-loader.h to avoid compiling
error.
---
 tools/perf/builtin-record.c  |  6 ++
 tools/perf/util/bpf-loader.c | 39 +++
 tools/perf/util/bpf-loader.h | 16 
 tools/perf/util/evlist.c | 32 
 tools/perf/util/evlist.h |  1 +
 tools/perf/util/evsel.c  |  1 +
 tools/perf/util/evsel.h  |  1 +
 7 files changed, 96 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 4b52399..692cfe5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -982,6 +982,12 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
goto out_symbol_exit;
}
 
+   err = perf_evlist__add_bpf(rec->evlist);
+   if (err < 0) {
+   pr_err("Failed to add events from BPF object(s)\n");
+   goto out_symbol_exit;
+   }
+
symbol__init(NULL);
 
if (symbol_conf.kptr_restrict)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index f9a1ab9..5d23346 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -243,3 +243,42 @@ errout:
bpf_object__unload(obj);
return err;
 }
+
+int
+bpf__for_each_program(bpf_prog_iter_callback_t func,
+ void *arg)
+{
+   struct bpf_object *obj, *tmp;
+   struct bpf_program *prog;
+   int err;
+
+   bpf_object__for_each(obj, tmp) {
+   bpf_object__for_each_program(prog, obj) {
+   struct bpf_prog_priv *priv;
+   char *group, *event;
+   int fd;
+
+   err = bpf_program__get_private(prog,
+  (void **)&priv);
+   if (err || !priv) {
+   pr_err("bpf: failed to get private field\n");
+   return -EINVAL;
+   }
+   err = bpf_program__get_fd(prog, &fd);
+   if (err || fd < 0) {
+   pr_err("bpf: failed to get file descriptor\n");
+   return -EINVAL;
+   }
+
+   group = priv->pev->group;
+   event = priv->pev->event;
+   err = func(group, event, fd, arg);
+   if (err) {
+   pr_err("bpf: call back failed, stop iterate\n");
+   return err;
+   }
+   }
+   }
+
+   return 0;
+}
diff --git a/tools/perf/util/bpf-loader.h b/tools/perf/util/bpf-loader.h
index fcc775d..4d5eec2 100644
--- a/tools/perf/util/bpf-loader.h
+++ b/tools/perf/util/bpf-loader.h
@@ -5,6 +5,8 @@
 #ifndef __BPF_LOADER_H
 #define __BPF_LOADER_H
 
+#include  // for __maybe_unused
+
 #define PERF_BPF_PROBE_GROUP "perf_bpf_probe"
 
 int bpf__prepare_load(const char *filename);
@@ -13,4 +15,18 @@ int bpf__unprobe(void);
 int bpf__load(void);
 
 void bpf__clear(void);
+
+typedef int (*bpf_prog_iter_callback_t)(char *group, char *event,
+   int fd, void *arg);
+
+#ifdef HAVE_LIBELF_SUPPORT
+int bpf__for_each_program(bpf_prog_iter_callback_t func, void *arg);
+#else
+static inline int
+bpf__for_each_program(bpf_prog_iter_callback_t func __maybe_unused,
+ void *arg __maybe_unused)
+{
+   return 0;
+}
+#endif
 #endif
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 080be93..2b997d1 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -14,6 +14,7 @@
 #include "target.h"
 #include "evlist.h"
 #include "evsel.h"
+#include "bpf-loader.h"
 #include "debug.h"
 #include 
 
@@ -194,6 +195,37 @@ error:
return -ENOMEM;
 }
 
+static int add_bpf_event(char *group, char *event, int fd,
+void *arg)
+{
+   struct perf_evlist *evlist = arg;
+   struct perf_evsel *pos;
+   struct list_head list;
+   int err, idx, entries;
+
+   pr_debug("add bpf event %s:%s and attach bpf program %d\n",
+group, event, fd);
+   INIT_LIST_HEAD(&list);
+   idx = evlist->nr_entries;
+   err = parse_events_add_tracepoint(&list, &idx, group, event);
+   
+   if (err) {
+   pr_err("Failed to add BPF event %s:%s\n",
+  group, event);
+   return err;

[RFC PATCH v4 18/29] bpf tools: Introduce bpf_load_program() to bpf.c

[Wang Nan]

bpf_load_program() can be used to load bpf program into kernel. To make
loading faster, first try to load without logbuf. Try again with logbuf
if the first try failed.

Signed-off-by: Wang Nan 
---
 tools/lib/bpf/bpf.c | 34 ++
 tools/lib/bpf/bpf.h |  7 +++
 2 files changed, 41 insertions(+)

diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 7481923..d2002da 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -36,6 +36,11 @@
 # error __NR_bpf not defined. libbpf does not support your arch.
 #endif
 
+static __u64 ptr_to_u64(void *ptr)
+{
+   return (__u64) (unsigned long) ptr;
+}
+
 static int sys_bpf(enum bpf_cmd cmd, union bpf_attr *attr, unsigned int size)
 {
return syscall(__NR_bpf, cmd, attr, size);
@@ -54,3 +59,32 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size, 
int value_size,
 
return sys_bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
 }
+
+int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
+size_t insns_cnt, char *license,
+u32 kern_version, char *log_buf, size_t log_buf_sz)
+{
+   int fd;
+   union bpf_attr attr;
+
+   bzero(&attr, sizeof(attr));
+   attr.prog_type = type;
+   attr.insn_cnt = (__u32)insns_cnt;
+   attr.insns = ptr_to_u64(insns);
+   attr.license = ptr_to_u64(license);
+   attr.log_buf = ptr_to_u64(NULL);
+   attr.log_size = 0;
+   attr.log_level = 0;
+   attr.kern_version = kern_version;
+
+   fd = sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
+   if (fd >= 0 || !log_buf || !log_buf_sz)
+   return fd;
+
+   /* Try again with log */
+   attr.log_buf = ptr_to_u64(log_buf);
+   attr.log_size = log_buf_sz;
+   attr.log_level = 1;
+   log_buf[0] = 0;
+   return sys_bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 28f7942..854b736 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -13,4 +13,11 @@
 int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
   int max_entries);
 
+/* Recommend log buffer size */
+#define BPF_LOG_BUF_SIZE 65536
+int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
+size_t insns_cnt, char *license,
+u32 kern_version, char *log_buf,
+size_t log_buf_sz);
+
 #endif
-- 
1.8.3.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/

[RFC PATCH v4 26/29] perf record: Probe at kprobe points

[Wang Nan]

In this patch, kprobe points are created using add_perf_probe_events.
Since all events are already grouped together in an array, calling
add_perf_probe_events() once creates all of them.

Signed-off-by: Wang Nan 
---
 tools/perf/builtin-record.c  | 14 ++
 tools/perf/util/bpf-loader.c | 45 
 tools/perf/util/bpf-loader.h |  2 ++
 3 files changed, 61 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c3efdfb..9297800 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -27,6 +27,7 @@
 #include "util/cpumap.h"
 #include "util/thread_map.h"
 #include "util/data.h"
+#include "util/bpf-loader.h"
 
 #include 
 #include 
@@ -957,6 +958,18 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(record_usage, record_options);
}
 
+   /*
+* bpf__probe must be called before symbol__init() because we
+* need init_symbol_maps. If called after symbol__init,
+* symbol_conf.sort_by_name won't take effect.
+*/
+   err = bpf__probe();
+   if (err) {
+   pr_err("Probing at events in BPF object failed.\n");
+   pr_err("Try perf probe -d '*' to remove existing probe 
events.\n");
+   return err;
+   }
+
symbol__init(NULL);
 
if (symbol_conf.kptr_restrict)
@@ -1011,5 +1024,6 @@ int cmd_record(int argc, const char **argv, const char 
*prefix __maybe_unused)
 out_symbol_exit:
perf_evlist__delete(rec->evlist);
symbol__exit();
+   bpf__unprobe();
return err;
 }
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index 1022729..f5d5f3e 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -179,3 +179,48 @@ void bpf__clear(void)
bpf_object__for_each(obj, tmp)
bpf_object__close(obj);
 }
+
+static bool is_probing = false;
+
+int bpf__unprobe(void)
+{
+   struct strlist *dellist;
+   int ret;
+
+   if (!is_probing)
+   return 0;
+
+   dellist = strlist__new(true, PERF_BPF_PROBE_GROUP ":*");
+   if (!dellist) {
+   pr_err("Failed to create dellist when unprobing\n");
+   return -ENOMEM;
+   }
+
+   ret = del_perf_probe_events(dellist);
+   strlist__delete(dellist);
+   if (ret < 0 && is_probing)
+   pr_err("  Error: failed to delete events: %s\n",
+   strerror(-ret));
+   else
+   is_probing = false;
+   return ret < 0 ? ret : 0;
+}
+
+int bpf__probe(void)
+{
+   int err;
+
+   if (nr_probe_events <= 0)
+   return 0;
+
+   err = add_perf_probe_events(probe_event_array,
+   nr_probe_events,
+   MAX_PROBES, 0);
+   /* add_perf_probe_events return negative when fail */
+   if (err < 0)
+   pr_err("bpf probe: failed to probe events\n");
+   else
+   is_probing = true;
+
+   return err < 0 ? err : 0;
+}
diff --git a/tools/perf/util/bpf-loader.h b/tools/perf/util/bpf-loader.h
index 43d7b99..1127880 100644
--- a/tools/perf/util/bpf-loader.h
+++ b/tools/perf/util/bpf-loader.h
@@ -8,6 +8,8 @@
 #define PERF_BPF_PROBE_GROUP "perf_bpf_probe"
 
 int bpf__prepare_load(const char *filename);
+int bpf__probe(void);
+int bpf__unprobe(void);
 
 void bpf__clear(void);
 #endif
-- 
1.8.3.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/

[RFC PATCH v4 23/29] perf tools: Make perf depend on libbpf

[Wang Nan]

By adding libbpf into perf's Makefile, this patch enable perf to
build libbpf during building if libelf is found and NO_LIBELF is not
set. The newly introduced code is similar to libapi and libtraceevent
building in Makefile.perf.

Signed-off-by: Wang Nan 
---
 tools/perf/Makefile.perf | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index c43a205..45f10da 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -123,6 +123,7 @@ STRIP   = strip
 
 LIB_DIR  = $(srctree)/tools/lib/api/
 TRACE_EVENT_DIR = $(srctree)/tools/lib/traceevent/
+BPF_DIR = $(srctree)/tools/lib/bpf/
 
 # include config/Makefile by default and rule out
 # non-config cases
@@ -158,6 +159,7 @@ strip-libs = $(filter-out -l%,$(1))
 
 ifneq ($(OUTPUT),)
   TE_PATH=$(OUTPUT)
+  BPF_PATH=$(OUTPUT)
 ifneq ($(subdir),)
   LIB_PATH=$(OUTPUT)/../lib/api/
 else
@@ -166,6 +168,7 @@ endif
 else
   TE_PATH=$(TRACE_EVENT_DIR)
   LIB_PATH=$(LIB_DIR)
+  BPF_PATH=$(BPF_DIR)
 endif
 
 LIBTRACEEVENT = $(TE_PATH)libtraceevent.a
@@ -174,6 +177,8 @@ export LIBTRACEEVENT
 LIBAPI = $(LIB_PATH)libapi.a
 export LIBAPI
 
+LIBBPF = $(BPF_PATH)libbpf.a
+
 # python extension build directories
 PYTHON_EXTBUILD := $(OUTPUT)python_ext_build/
 PYTHON_EXTBUILD_LIB := $(PYTHON_EXTBUILD)lib/
@@ -225,6 +230,11 @@ export PERL_PATH
 LIB_FILE=$(OUTPUT)libperf.a
 
 PERFLIBS = $(LIB_FILE) $(LIBAPI) $(LIBTRACEEVENT)
+ifndef NO_LIBELF
+  ifeq ($(feature-libelf), 1)
+PERFLIBS += $(LIBBPF)
+  endif
+endif
 
 # We choose to avoid "if .. else if .. else .. endif endif"
 # because maintaining the nesting to match is a pain.  If
@@ -387,6 +397,13 @@ $(LIBAPI)-clean:
$(call QUIET_CLEAN, libapi)
$(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
 
+$(LIBBPF): FORCE
+   $(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) $(OUTPUT)libbpf.a
+
+$(LIBBPF)-clean:
+   $(call QUIET_CLEAN, libbpf)
+   $(Q)$(MAKE) -C $(BPF_DIR) O=$(OUTPUT) clean >/dev/null
+
 help:
@echo 'Perf make targets:'
@echo '  doc- make *all* documentation (see below)'
@@ -525,7 +542,7 @@ config-clean:
$(call QUIET_CLEAN, config)
$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
 
-clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean config-clean
+clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean config-clean
$(call QUIET_CLEAN, core-objs)  $(RM) $(LIB_FILE) $(OUTPUT)perf-archive 
$(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
$(Q)find . -name '*.o' -delete -o -name '\.*.cmd' -delete -o -name 
'\.*.d' -delete
$(Q)$(RM) .config-detected
-- 
1.8.3.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/

[RFC PATCH v4 11/29] bpf tools: Collect symbol table from SHT_SYMTAB section

[Wang Nan]

This patch collects symbols section. This section is useful when
linking ELF maps.

Signed-off-by: Wang Nan 
---
 tools/lib/bpf/libbpf.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index da83766..d89fd42 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -95,6 +95,7 @@ struct bpf_object {
int fd;
Elf *elf;
GElf_Ehdr ehdr;
+   Elf_Data *symbols;
} efile;
char path[];
 };
@@ -124,6 +125,7 @@ static void bpf_object__elf_finish(struct bpf_object *obj)
elf_end(obj->efile.elf);
obj->efile.elf = NULL;
}
+   obj->efile.symbols = NULL;
zclose(obj->efile.fd);
 }
 
@@ -309,6 +311,14 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
else if (strcmp(name, "maps") == 0)
err = bpf_object__init_maps(obj, data->d_buf,
data->d_size);
+   else if (sh.sh_type == SHT_SYMTAB) {
+   if (obj->efile.symbols) {
+   pr_warning("bpf: multiple SYMTAB in %s\n",
+  obj->path);
+   err = -EEXIST;
+   } else
+   obj->efile.symbols = data;
+   }
if (err)
goto out;
}
-- 
1.8.3.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/

[RFC PATCH v4 04/29] bpf tools: Introduce 'bpf' library to tools

[Wang Nan]

This is the first patch of libbpf. The goal of libbpf is to create a
standard way for accessing eBPF object files. This patch creates
Makefile and Build for it, allows 'make' to build libbpf.a and
libbpf.so, 'make install' to put them into proper directories.
Most part of Makefile is borrowed from traceevent. Before building,
it checks the existance of libelf in Makefile, and deny to build if
not found. Instead of throwing an error if libelf not found, the error
raises in a phony target "elfdep". This design is to ensure
'make clean' still workable even if libelf is not found.

Signed-off-by: Wang Nan 
---
 tools/lib/bpf/.gitignore |   2 +
 tools/lib/bpf/Build  |   1 +
 tools/lib/bpf/Makefile   | 190 +++
 tools/lib/bpf/libbpf.c   |  14 
 tools/lib/bpf/libbpf.h   |  11 +++
 5 files changed, 218 insertions(+)
 create mode 100644 tools/lib/bpf/.gitignore
 create mode 100644 tools/lib/bpf/Build
 create mode 100644 tools/lib/bpf/Makefile
 create mode 100644 tools/lib/bpf/libbpf.c
 create mode 100644 tools/lib/bpf/libbpf.h

diff --git a/tools/lib/bpf/.gitignore b/tools/lib/bpf/.gitignore
new file mode 100644
index 000..812aeed
--- /dev/null
+++ b/tools/lib/bpf/.gitignore
@@ -0,0 +1,2 @@
+libbpf_version.h
+FEATURE-DUMP
diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
new file mode 100644
index 000..a316484
--- /dev/null
+++ b/tools/lib/bpf/Build
@@ -0,0 +1 @@
+libbpf-y := libbpf.o
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
new file mode 100644
index 000..0715aaa
--- /dev/null
+++ b/tools/lib/bpf/Makefile
@@ -0,0 +1,190 @@
+# Most of this file is copied from tools/lib/traceevent/Makefile
+
+BPF_VERSION = 0
+BPF_PATCHLEVEL = 0
+BPF_EXTRAVERSION = 1
+
+MAKEFLAGS += --no-print-directory
+
+
+# Makefiles suck: This macro sets a default value of $(2) for the
+# variable named by $(1), unless the variable has been set by
+# environment or command line. This is necessary for CC and AR
+# because make sets default values, so the simpler ?= approach
+# won't work as expected.
+define allow-override
+  $(if $(or $(findstring environment,$(origin $(1))),\
+$(findstring command line,$(origin $(1,,\
+$(eval $(1) = $(2)))
+endef
+
+# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix.
+$(call allow-override,CC,$(CROSS_COMPILE)gcc)
+$(call allow-override,AR,$(CROSS_COMPILE)ar)
+
+INSTALL = install
+
+# Use DESTDIR for installing into a different root directory.
+# This is useful for building a package. The program will be
+# installed in this directory as if it was the root directory.
+# Then the build tool can move it later.
+DESTDIR ?=
+DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))'
+
+LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
+ifeq ($(LP64), 1)
+  libdir_relative = lib64
+else
+  libdir_relative = lib
+endif
+
+prefix ?= /usr/local
+libdir = $(prefix)/$(libdir_relative)
+man_dir = $(prefix)/share/man
+man_dir_SQ = '$(subst ','\'',$(man_dir))'
+
+export man_dir man_dir_SQ INSTALL
+export DESTDIR DESTDIR_SQ
+
+include ../../scripts/Makefile.include
+
+# copy a bit from Linux kbuild
+
+ifeq ("$(origin V)", "command line")
+  VERBOSE = $(V)
+endif
+ifndef VERBOSE
+  VERBOSE = 0
+endif
+
+ifeq ($(srctree),)
+srctree := $(patsubst %/,%,$(dir $(shell pwd)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+srctree := $(patsubst %/,%,$(dir $(srctree)))
+#$(info Determined 'srctree' to be $(srctree))
+endif
+
+FEATURE_DISPLAY = libelf libelf-getphdrnum libelf-mmap
+FEATURE_TESTS = libelf
+include $(srctree)/tools/build/Makefile.feature
+
+export prefix libdir src obj
+
+# Shell quotes
+libdir_SQ = $(subst ','\'',$(libdir))
+libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
+plugin_dir_SQ = $(subst ','\'',$(plugin_dir))
+
+LIB_FILE = libbpf.a libbpf.so
+
+VERSION= $(BPF_VERSION)
+PATCHLEVEL = $(BPF_PATCHLEVEL)
+EXTRAVERSION   = $(BPF_EXTRAVERSION)
+
+OBJ= $@
+N  =
+
+LIBBPF_VERSION = $(BPF_VERSION).$(BPF_PATCHLEVEL).$(BPF_EXTRAVERSION)
+
+INCLUDES = -I. -I$(srctree)/tools/include 
-I$(srctree)/arch/$(ARCH)/include/uapi -I$(srctree)/include/uapi
+
+# Set compile option CFLAGS
+ifdef EXTRA_CFLAGS
+  CFLAGS := $(EXTRA_CFLAGS)
+else
+  CFLAGS := -g -Wall
+endif
+
+ifeq ($(feature-libelf-mmap), 1)
+  override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+endif
+
+ifeq ($(feature-libelf-getphdrnum), 1)
+  override CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+endif
+
+# Append required CFLAGS
+override CFLAGS += $(EXTRA_WARNINGS)
+override CFLAGS += -Werror -Wall
+override CFLAGS += -fPIC
+override CFLAGS += $(INCLUDES)
+
+ifeq ($(VERBOSE),1)
+  Q =
+else
+  Q = @
+endif
+
+# Disable command line variables (CFLAGS) overide from top
+# level Makefile (perf), otherwise build Makefile will get
+# the same command line setup.
+MAKEOVERRIDES=
+
+export srctree OUTPUT CC LD CFLAGS V
+build := -f $(srctree)/tools/build/Makefile.build dir=. obj
+
+BPF_IN:= $(OUTPUT)libbp

[RFC PATCH v4 29/29] perf tools: Attach eBPF program to perf event

[Wang Nan]

In this patch PERF_EVENT_IOC_SET_BPF ioctl is used to attach eBPF
program to a newly created perf event. The file descriptor of the
eBPF program is passed to perf record using previous patches, and
stored into evsel->bpf_fd.

It is possible that different perf event are created for one kprobe
events for different CPUs. In this case, when trying to call the
ioctl, EEXIST will be return. This patch doesn't treat it as an error.

Signed-off-by: Wang Nan 
---
 tools/perf/util/evsel.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 04d60a7..3b94c66 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1201,6 +1201,22 @@ retry_open:
  err);
goto try_fallback;
}
+
+   if (evsel->bpf_fd >= 0) {
+   int evt_fd = FD(evsel, cpu, thread);
+   int bpf_fd = evsel->bpf_fd;
+
+   err = ioctl(evt_fd,
+   PERF_EVENT_IOC_SET_BPF,
+   bpf_fd);
+   if (err && errno != EEXIST) {
+   pr_err("failed to attach bpf fd %d: 
%s\n",
+  bpf_fd, strerror(errno));
+   err = -EINVAL;
+   goto out_close;
+   }
+   }
+
set_rlimit = NO_CHANGE;
 
/*
-- 
1.8.3.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/