summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-06-18PCI: xgene: Allow config access to Root Port even when link is downDuc Dang
Previously, when a Root Port's link was down, we didn't allow config access to the Root Port, which meant that if the Root Port led to an empty slot, "lspci" didn't even show the Root Port. Allow config access to Root Port even when link is down. [bhelgaas: changelog, fold in unused var fix] Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Duc Dang <dhdang@apm.com> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2015-06-18netfilter: xtables: fix warnings on 32bit platformsFlorian Westphal
On 32bit archs gcc complains due to cast from void* to u64. Add intermediate casts to long to silence these warnings. include/linux/netfilter/x_tables.h:376:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] include/linux/netfilter/x_tables.h:384:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] include/linux/netfilter/x_tables.h:391:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] include/linux/netfilter/x_tables.h:400:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Fixes: 71ae0dff02d756e ("netfilter: xtables: use percpu rule counters") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2015-06-18netfilter: Remove spurios included of netfilter.hEric W Biederman
While testing my netfilter changes I noticed several files where recompiling unncessarily because they unncessarily included netfilter.h. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2015-06-18netfilter: don't pull include/linux/netfilter.h from netns headersPablo Neira Ayuso
This pulls the full hook netfilter definitions from all those that include net_namespace.h. Instead let's just include the bare minimum required in the new linux/netfilter_defs.h file, and use it from the netfilter netns header files. I also needed to include in.h and in6.h from linux/netfilter.h otherwise we hit this compilation error: In file included from include/linux/netfilter_defs.h:4:0, from include/net/netns/netfilter.h:4, from include/net/net_namespace.h:22, from include/linux/netdevice.h:43, from net/netfilter/nfnetlink_queue_core.c:23: include/uapi/linux/netfilter.h:76:17: error: field ‘in’ has incomplete type struct in_addr in; And also explicit include linux/netfilter.h in several spots. Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2015-06-18netfilter: use forward declaration instead of including linux/proc_fs.hPablo Neira Ayuso
We don't need to pull the full definitions in that file, a simple forward declaration is enough. Moreover, include linux/procfs.h from nf_synproxy_core, otherwise this hits a compilation error due to missing declarations, ie. net/netfilter/nf_synproxy_core.c: In function ‘synproxy_proc_init’: net/netfilter/nf_synproxy_core.c:326:2: error: implicit declaration of function ‘proc_create’ [-Werror=implicit-function-declaration] if (!proc_create("synproxy", S_IRUGO, net->proc_net_stat, ^ Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2015-06-18net: include missing headers in net/net_namespace.hPablo Neira Ayuso
Include linux/idr.h and linux/skbuff.h since they are required by objects that are declared in the net structure. struct net { ... struct idr netns_ids; ... struct sk_buff_head wext_nlevents; ... Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2015-06-18net: sched: Simplify em_ipset_matchEric W. Biederman
em->net is always set and always available, use it in preference to dev_net(skb->dev). Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2015-06-18netfilter: Kill unused copies of RCV_SKB_FAILEric W. Biederman
This appears to have been a dead macro in both nfnetlink_log.c and nfnetlink_queue_core.c since these pieces of code were added in 2005. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2015-06-18netfilter: bridge: split ipv6 code into separated filePablo Neira Ayuso
Resolve compilation breakage when CONFIG_IPV6 is not set by moving the IPv6 code into a separated br_netfilter_ipv6.c file. Fixes: efb6de9b4ba0 ("netfilter: bridge: forward IPv6 fragmented packets") Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2015-06-18libata: Do not blacklist Micron M500DCMartin K. Petersen
Queued TRIM got disabled on Micron M500DC drives thanks to the "Micron_M500*" pattern we had in place to accommodate the previous generation of this drive family. Tweak the blacklist entry slightly so we only disable queued TRIM for the non-DC variants of M500 drives. Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Cc: stable@vger.kernel.org Signed-off-by: Tejun Heo <tj@kernel.org>
2015-06-18drm/radeon: don't probe MST on hw we don't support it onDave Airlie
If you do radeon.mst=1 on a gpu without mst hw, and then plug some mst hw it will oops instead of falling back. So check we have DCE5 at least before proceeding. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2015-06-18drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING queryMichel Dänzer
This tells userspace that it's safe to use the RADEON_VA_UNMAP operation of the DRM_RADEON_GEM_VA ioctl. Cc: stable@vger.kernel.org (NOTE: Backporting this commit requires at least backports of commits 26d4d129b6042197b4cbc8341c0618f99231af2f, 48afbd70ac7b6aa62e8d452091023941d8085f8a and c29c0876ec05d51a93508a39b90b92c29ba6423d as well, otherwise using RADEON_VA_UNMAP runs into trouble) Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2015-06-18Bluetooth: Fix warning of potentially uninitialized adv_instance variableJohan Hedberg
Rework the logic of checking for a valid adv_instance for non-zero cp->instance values. Without this change we may get (false positive) warnings as follows: >> net/bluetooth/mgmt.c:7294:29: warning: 'adv_instance' may be used uninitialized in this function [-Wuninitialized] Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: Use zalloc when possibleJohan Hedberg
Use zallog for adv_instance allocation instead of kmalloc + memset. This also fixes the following coccinelle warning: >> net/bluetooth/hci_core.c:2693:17-24: WARNING: kzalloc should be used for adv_instance, instead of kmalloc/memset Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: ath3k: Add support of 04ca:300d AR3012 deviceDmitry Tunin
BugLink: https://bugs.launchpad.net/bugs/1394368 This device requires new firmware files AthrBT_0x11020100.dfu and ramps_0x11020100_40.dfu added to /lib/firmware/ar3k/ that are not included in linux-firmware yet. T: Bus=02 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=300d Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
2015-06-18[media] videodev2.h: fix copy-and-paste error in V4L2_MAP_XFER_FUNC_DEFAULTHans Verkuil
The colorspace argument was compared against a V4L2_XFER_FUNC define instead of against a V4L2_COLORSPACE define, returning the wrong answer. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-18[media] Revert "[media] vb2: Push mmap_sem down to memops"Hans Verkuil
This reverts commit 48b25a3a713b90988b6882d318f7c0a6bed9aabc. That commit caused two regressions. The first is a BUG: Jun 14 18:42:15 test-media kernel: [ 115.972299] BUG: unable to handle kernel NULL pointer dereference at 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972307] IP: [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972316] PGD 0 Jun 14 18:42:15 test-media kernel: [ 115.972318] Oops: 0000 [#1] PREEMPT SMP Jun 14 18:42:15 test-media kernel: [ 115.972321] Modules linked in: vivid v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media vmw_balloon vmw_vmci acpi_cpufreq processor button Jun 14 18:42:15 test-media kernel: [ 115.972333] CPU: 0 PID: 1542 Comm: v4l2-ctl Not tainted 4.1.0-rc3-test-media #1190 Jun 14 18:42:15 test-media kernel: [ 115.972336] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 Jun 14 18:42:15 test-media kernel: [ 115.972337] task: ffff880220ce4200 ti: ffff88021d16c000 task.ti: ffff88021d16c000 Jun 14 18:42:15 test-media kernel: [ 115.972339] RIP: 0010:[<ffffffff810d5cd0>] [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972342] RSP: 0018:ffff88021d16f9b8 EFLAGS: 00010002 Jun 14 18:42:15 test-media kernel: [ 115.972343] RAX: 0000000000000046 RBX: 0000000000000292 RCX: 0000000000000001 Jun 14 18:42:15 test-media kernel: [ 115.972345] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972346] RBP: ffff88021d16fa88 R08: 0000000000000001 R09: 0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972347] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001 Jun 14 18:42:15 test-media kernel: [ 115.972348] R13: ffff880220ce4200 R14: 0000000000000100 R15: 0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972350] FS: 00007f2441e7f740(0000) GS:ffff880236e00000(0000) knlGS:0000000000000000 Jun 14 18:42:15 test-media kernel: [ 115.972351] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 14 18:42:15 test-media kernel: [ 115.972353] CR2: 0000000000000100 CR3: 0000000001e0b000 CR4: 00000000001406f0 Jun 14 18:42:15 test-media kernel: [ 115.972424] Stack: Jun 14 18:42:15 test-media kernel: [ 115.972427] ffff88021d16fa98 ffffffff810d6543 0000000000000006 0000000000000246 Jun 14 18:42:15 test-media kernel: [ 115.972431] ffff88021d16fa08 ffffffff810d532d ffff880220ce4a78 ffff880200000000 Jun 14 18:42:15 test-media kernel: [ 115.972433] ffff880200000001 0000000000000000 0000000000000001 000000000093a4a0 Jun 14 18:42:15 test-media kernel: [ 115.972436] Call Trace: Jun 14 18:42:15 test-media kernel: [ 115.972440] [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972443] [<ffffffff810d532d>] ? mark_held_locks+0x6d/0xa0 Jun 14 18:42:15 test-media kernel: [ 115.972445] [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80 Jun 14 18:42:15 test-media kernel: [ 115.972447] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:42:15 test-media kernel: [ 115.972452] [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972458] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972460] [<ffffffffa039f1f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972463] [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560 Jun 14 18:42:15 test-media kernel: [ 115.972467] [<ffffffffa038fdc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972469] [<ffffffffa039f1f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:42:15 test-media kernel: [ 115.972472] [<ffffffffa038b626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972475] [<ffffffffa038fdd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972478] [<ffffffffa038fe75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972481] [<ffffffffa038feb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:42:15 test-media kernel: [ 115.972485] [<ffffffffa03ad372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:42:15 test-media kernel: [ 115.972491] [<ffffffffa0358460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:42:15 test-media kernel: [ 115.972496] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:42:15 test-media kernel: [ 115.972498] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:42:15 test-media kernel: [ 115.972501] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:42:15 test-media kernel: [ 115.972504] [<ffffffff8108c670>] do_exit+0x3a0/0xaf0 Jun 14 18:42:15 test-media kernel: [ 115.972507] [<ffffffff819b3a9b>] ? _raw_spin_unlock_irq+0x2b/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972509] [<ffffffff8108e0ff>] do_group_exit+0x4f/0xe0 Jun 14 18:42:15 test-media kernel: [ 115.972511] [<ffffffff8109a170>] get_signal+0x200/0x8c0 Jun 14 18:42:15 test-media kernel: [ 115.972514] [<ffffffff819b14b5>] ? __mutex_unlock_slowpath+0xf5/0x240 Jun 14 18:42:15 test-media kernel: [ 115.972518] [<ffffffff81002593>] do_signal+0x23/0x820 Jun 14 18:42:15 test-media kernel: [ 115.972521] [<ffffffff819b1609>] ? mutex_unlock+0x9/0x10 Jun 14 18:42:15 test-media kernel: [ 115.972524] [<ffffffffa0358648>] ? v4l2_ioctl+0x78/0xf0 [videodev] Jun 14 18:42:15 test-media kernel: [ 115.972526] [<ffffffff819b4653>] ? int_very_careful+0x5/0x46 Jun 14 18:42:15 test-media kernel: [ 115.972529] [<ffffffff810d54bd>] ? trace_hardirqs_on_caller+0x15d/0x200 Jun 14 18:42:15 test-media kernel: [ 115.972531] [<ffffffff81002de0>] do_notify_resume+0x50/0x60 Jun 14 18:42:15 test-media kernel: [ 115.972533] [<ffffffff819b46a6>] int_signal+0x12/0x17 Jun 14 18:42:15 test-media kernel: [ 115.972534] Code: ca 81 31 c0 e8 7a e2 8c 00 e8 aa 1d 8d 00 0f 1f 44 00 00 31 db 48 81 c4 a8 00 00 00 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 66 90 <49> 81 3e 40 4e 02 82 b8 00 00 00 00 44 0f 44 e0 41 83 ff 01 0f Jun 14 18:42:15 test-media kernel: [ 115.972567] RIP [<ffffffff810d5cd0>] __lock_acquire+0x2f0/0x2070 Jun 14 18:42:15 test-media kernel: [ 115.972569] RSP <ffff88021d16f9b8> Jun 14 18:42:15 test-media kernel: [ 115.972570] CR2: 0000000000000100 Jun 14 18:42:15 test-media kernel: [ 115.972573] ---[ end trace 25595c2b8560cb57 ]--- Jun 14 18:42:15 test-media kernel: [ 115.972575] Fixing recursive fault but reboot is needed! This can be reproduced by loading the vivid driver and running: v4l2-ctl --stream-user and pressing Ctrl-C. You may have to try a few times, but in my experience this BUG is triggered quite quickly. The second is a possible deadlock: Jun 14 18:44:07 test-media kernel: [ 49.376650] ====================================================== Jun 14 18:44:07 test-media kernel: [ 49.376651] [ INFO: possible circular locking dependency detected ] Jun 14 18:44:07 test-media kernel: [ 49.376653] 4.1.0-rc3-test-media #1190 Not tainted Jun 14 18:44:07 test-media kernel: [ 49.376654] ------------------------------------------------------- Jun 14 18:44:07 test-media kernel: [ 49.376655] v4l2-compliance/1468 is trying to acquire lock: Jun 14 18:44:07 test-media kernel: [ 49.376657] (&mm->mmap_sem){++++++}, at: [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376665] Jun 14 18:44:07 test-media kernel: [ 49.376665] but task is already holding lock: Jun 14 18:44:07 test-media kernel: [ 49.376666] (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376670] Jun 14 18:44:07 test-media kernel: [ 49.376670] which lock already depends on the new lock. Jun 14 18:44:07 test-media kernel: [ 49.376670] Jun 14 18:44:07 test-media kernel: [ 49.376671] Jun 14 18:44:07 test-media kernel: [ 49.376671] the existing dependency chain (in reverse order) is: Jun 14 18:44:07 test-media kernel: [ 49.376672] Jun 14 18:44:07 test-media kernel: [ 49.376672] -> #1 (&q->mmap_lock){+.+...}: Jun 14 18:44:07 test-media kernel: [ 49.376675] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376682] [<ffffffff819aef5e>] mutex_lock_nested+0x5e/0x560 Jun 14 18:44:07 test-media kernel: [ 49.376689] [<ffffffffa03934a2>] vb2_mmap+0x232/0x350 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376691] [<ffffffffa0395a60>] vb2_fop_mmap+0x20/0x30 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376694] [<ffffffffa0361102>] v4l2_mmap+0x52/0x90 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376698] [<ffffffff81177e33>] mmap_region+0x3b3/0x5e0 Jun 14 18:44:07 test-media kernel: [ 49.376701] [<ffffffff81178377>] do_mmap_pgoff+0x317/0x400 Jun 14 18:44:07 test-media kernel: [ 49.376703] [<ffffffff81165320>] vm_mmap_pgoff+0x90/0xc0 Jun 14 18:44:07 test-media kernel: [ 49.376708] [<ffffffff81176867>] SyS_mmap_pgoff+0x1d7/0x280 Jun 14 18:44:07 test-media kernel: [ 49.376709] [<ffffffff81007f8d>] SyS_mmap+0x1d/0x20 Jun 14 18:44:07 test-media kernel: [ 49.376714] [<ffffffff819b44ae>] system_call_fastpath+0x12/0x76 Jun 14 18:44:07 test-media kernel: [ 49.376716] Jun 14 18:44:07 test-media kernel: [ 49.376716] -> #0 (&mm->mmap_sem){++++++}: Jun 14 18:44:07 test-media kernel: [ 49.376718] [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376720] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376721] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376723] [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376725] [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376727] [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376729] [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376731] [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376733] [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:44:07 test-media kernel: [ 49.376737] [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376739] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:44:07 test-media kernel: [ 49.376744] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:44:07 test-media kernel: [ 49.376746] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:44:07 test-media kernel: [ 49.376749] [<ffffffff81002dd1>] do_notify_resume+0x41/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376752] [<ffffffff819b46a6>] int_signal+0x12/0x17 Jun 14 18:44:07 test-media kernel: [ 49.376754] Jun 14 18:44:07 test-media kernel: [ 49.376754] other info that might help us debug this: Jun 14 18:44:07 test-media kernel: [ 49.376754] Jun 14 18:44:07 test-media kernel: [ 49.376755] Possible unsafe locking scenario: Jun 14 18:44:07 test-media kernel: [ 49.376755] Jun 14 18:44:07 test-media kernel: [ 49.376756] CPU0 CPU1 Jun 14 18:44:07 test-media kernel: [ 49.376757] ---- ---- Jun 14 18:44:07 test-media kernel: [ 49.376758] lock(&q->mmap_lock); Jun 14 18:44:07 test-media kernel: [ 49.376759] lock(&mm->mmap_sem); Jun 14 18:44:07 test-media kernel: [ 49.376760] lock(&q->mmap_lock); Jun 14 18:44:07 test-media kernel: [ 49.376761] lock(&mm->mmap_sem); Jun 14 18:44:07 test-media kernel: [ 49.376763] Jun 14 18:44:07 test-media kernel: [ 49.376763] *** DEADLOCK *** Jun 14 18:44:07 test-media kernel: [ 49.376763] Jun 14 18:44:07 test-media kernel: [ 49.376764] 2 locks held by v4l2-compliance/1468: Jun 14 18:44:07 test-media kernel: [ 49.376765] #0: (&dev->mutex#3){+.+.+.}, at: [<ffffffffa0398e0a>] _vb2_fop_release+0x2a/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376770] #1: (&q->mmap_lock){+.+...}, at: [<ffffffffa0398dc5>] vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376773] Jun 14 18:44:07 test-media kernel: [ 49.376773] stack backtrace: Jun 14 18:44:07 test-media kernel: [ 49.376776] CPU: 2 PID: 1468 Comm: v4l2-compliance Not tainted 4.1.0-rc3-test-media #1190 Jun 14 18:44:07 test-media kernel: [ 49.376777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014 Jun 14 18:44:07 test-media kernel: [ 49.376779] ffffffff8279e0b0 ffff88021d6f7ba8 ffffffff819a7aac 0000000000000011 Jun 14 18:44:07 test-media kernel: [ 49.376781] ffffffff8279e0b0 ffff88021d6f7bf8 ffffffff819a3964 ffff88021d6f7bd8 Jun 14 18:44:07 test-media kernel: [ 49.376783] ffff8800ac8aa100 0000000000000002 ffff8800ac8aa9a0 0000000000000002 Jun 14 18:44:07 test-media kernel: [ 49.376785] Call Trace: Jun 14 18:44:07 test-media kernel: [ 49.376788] [<ffffffff819a7aac>] dump_stack+0x4f/0x7b Jun 14 18:44:07 test-media kernel: [ 49.376792] [<ffffffff819a3964>] print_circular_bug+0x20f/0x251 Jun 14 18:44:07 test-media kernel: [ 49.376793] [<ffffffff810d79b3>] __lock_acquire+0x1fd3/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376795] [<ffffffff810d6543>] ? __lock_acquire+0xb63/0x2070 Jun 14 18:44:07 test-media kernel: [ 49.376797] [<ffffffff810d37a8>] ? __lock_is_held+0x58/0x80 Jun 14 18:44:07 test-media kernel: [ 49.376798] [<ffffffff810d852c>] lock_acquire+0x6c/0xa0 Jun 14 18:44:07 test-media kernel: [ 49.376800] [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376802] [<ffffffff819b1a92>] down_read+0x42/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376803] [<ffffffffa03a81f6>] ? vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376805] [<ffffffff819af1b1>] ? mutex_lock_nested+0x2b1/0x560 Jun 14 18:44:07 test-media kernel: [ 49.376807] [<ffffffffa0398dc5>] ? vb2_queue_release+0x25/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376808] [<ffffffffa03a81f6>] vb2_vmalloc_put_userptr+0x36/0x110 [videobuf2_vmalloc] Jun 14 18:44:07 test-media kernel: [ 49.376810] [<ffffffffa0398e0a>] ? _vb2_fop_release+0x2a/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376812] [<ffffffffa0394626>] __vb2_queue_free+0x146/0x5e0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376814] [<ffffffffa0398dd3>] vb2_queue_release+0x33/0x40 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376816] [<ffffffffa0398e75>] _vb2_fop_release+0x95/0xb0 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376818] [<ffffffffa0398eb9>] vb2_fop_release+0x29/0x50 [videobuf2_core] Jun 14 18:44:07 test-media kernel: [ 49.376820] [<ffffffffa03b6372>] vivid_fop_release+0x92/0x230 [vivid] Jun 14 18:44:07 test-media kernel: [ 49.376822] [<ffffffffa0361460>] v4l2_release+0x30/0x80 [videodev] Jun 14 18:44:07 test-media kernel: [ 49.376824] [<ffffffff811a51d5>] __fput+0xe5/0x200 Jun 14 18:44:07 test-media kernel: [ 49.376825] [<ffffffff819b4653>] ? int_very_careful+0x5/0x46 Jun 14 18:44:07 test-media kernel: [ 49.376827] [<ffffffff811a5339>] ____fput+0x9/0x10 Jun 14 18:44:07 test-media kernel: [ 49.376828] [<ffffffff810a9fa4>] task_work_run+0xc4/0xf0 Jun 14 18:44:07 test-media kernel: [ 49.376830] [<ffffffff81002dd1>] do_notify_resume+0x41/0x60 Jun 14 18:44:07 test-media kernel: [ 49.376832] [<ffffffff819b46a6>] int_signal+0x12/0x17 This can be triggered by loading the vivid module with the module option 'no_error_inj=1' and running 'v4l2-compliance -s5'. Again, it may take a few attempts to trigger this but for me it happens quite quickly. Without this patch I cannot reproduce these two issues. So reverting is the best solution for now. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: Jan Kara <jack@suse.cz> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-06-18[media] mantis: cleanup a warningMauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> drivers/media/pci/mantis/mantis_i2c.c: In function 'mantis_i2c_init': drivers/media/pci/mantis/mantis_i2c.c:222:15: warning: variable 'intmask' set but not used [-Wunused-but-set-variable] u32 intstat, intmask;
2015-06-18GFS2: Don't add all glocks to the lruBob Peterson
The glocks used for resource groups often come and go hundreds of thousands of times per second. Adding them to the lru list just adds unnecessary contention for the lru_lock spin_lock, especially considering we're almost certainly going to re-use the glock and take it back off the lru microseconds later. We never want the glock shrinker to cull them anyway. This patch adds a new bit in the glops that determines which glock types get put onto the lru list and which ones don't. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Acked-by: Steven Whitehouse <swhiteho@redhat.com>
2015-06-18Bluetooth: Increment management interface revisionMarcel Holtmann
This patch increments the management interface revision due to introduction of new multi-advertising feature and various bug fixes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2015-06-18PCI: xgene: Disable Configuration Request Retry Status for v1 siliconDuc Dang
When a CPU reads the Vendor and Device ID of a non-existent device, the controller should fabricate return data of 0xFFFFFFFF. Configuration Request Retry Status (CRS) is not applicable in this case because the device doesn't exist at all. The X-Gene v1 PCIe controller has a bug in the CRS logic such that when CRS is enabled, it fabricates return data of 0xFFFF0001 for this case, which means "the device exists but is not ready." That causes the PCI core to retry the read until it times out after 60 seconds. Disable CRS capability advertisement by clearing the CRS Software Visibility bit in the Root Capabilities Register. [bhelgaas: changelog and comment] Tested-by: Ian Campbell <ian.campbell@citrix.com> Tested-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com> Signed-off-by: Duc Dang <dhdang@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Tanmay Inamdar <tinamdar@apm.com>
2015-06-18ACPI / PNP: Avoid conflicting resource reservationsRafael J. Wysocki
Commit b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()" overlooked the fact that the memory and/or I/O regions reserved by acpi_reserve_resources() may conflict with those reserved by the PNP "system" driver. If that conflict actually takes place, it causes the reservations made by the "system" driver to fail while before commit b9a5e5e18fbf all reservations made by it and by acpi_reserve_resources() would be successful. In turn, that allows the resources that haven't been reserved by the "system" driver to be used by others (e.g. PCI) which sometimes leads to functional problems (up to and including boot failures). To fix that issue, introduce a common resource reservation routine, acpi_reserve_region(), to be used by both acpi_reserve_resources() and the "system" driver, that will track all resources reserved by it and avoid making conflicting requests. Link: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Link: http://marc.info/?t=143389402600001&r=1&w=2 Fixes: b9a5e5e18fbf "ACPI / init: Fix the ordering of acpi_reserve_resources()" Reported-by: Roland Dreier <roland@purestorage.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-18Bluetooth: hci_core: increase max adv instFlorian Grandel
Now that all preconditions are present for actual multi-advertising, the number of allowed advertising instances can be larger than one. This patch increases the number of allowed advertising instances to 5. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: hci_core: remove obsolete adv_instanceFlorian Grandel
Now that the obsolete adv_instance is no longer being referenced anywhere in the code it can be removed without breaking the build. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi-adv for mgmt_reenable_advertising()Florian Grandel
During service discovery, advertising will be disabled. This patch ensures that it is correctly being re-enabled, both for configuration made via set advertising and add advertising, once the scanning times out. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi-adv for trigger_le_scan()Florian Grandel
This patch ensures that instance advertising is correctly canceled before starting a le scan. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: program multi-adv on power onFlorian Grandel
Advertising instances programmed while powered off should be advertised once the device is powered. This patch ensures that all combinations of setting and/or adding advertising configuration while powered off will be correctly activated on power on. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for remove_advertising*()Florian Grandel
The remove_advertising() and remove_advertising_complete() functions had instance identifiers hard coded. Notably, when passing in 0x00 as an instance identifier to signal that all instances should be removed then the mgmt API would return a hard coded 0x01 rather than returning the expected value 0x00. This bug is being fixed by always referencing the instance identifier from the management API call instead. remove_advertising() is refactored to use the new dynamic advertising instance list. The logic is being changed to make multi-instance advertising actually work, notably the schedule_adv_instance() method is being referenced to make sure that other instances will continue to advertise even if one instance is being removed. The code is made more readable by factoring advertising instance management and initialization into the low-level hci_remove_adv_instance() and hci_adv_instances_clear() functions. The method now references the clear_adv_instance() helper method to remove duplicate logic and code. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt/hci_core: multi-adv for add_advertising*()Florian Grandel
The add_advertising() and add_advertising_complete() functions reference the now obsolete hdev->adv_instance struct. Both methods are being refactored to access the dynamic advertising instance list instead. This patch also introduces all logic necessary to actually deal with multiple instance advertising. Notably the mgmt_adv_inst_expired() and schedule_adv_inst() method are being referenced to schedule instances in a round robin fashion. This patch also introduces a "pending" flag into the adv_info struct. This is necessary to identify and remove recently added advertising instances when the HCI commands return with an error status code. Otherwise new advertising instances could be leaked without properly informing userspace about their existence. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for clear_adv_instances()Florian Grandel
The clear_adv_instance() function could not clean up multiple advertising instances previously. It is being changed to provide both, a means to clean up a single instance and cleaning up all instances at once. An additional instance parameter is being introduced to achieve this. Passing in 0x00 to this parameter signifies that all instances should be cleaned up. This semantics has been chosen similarly to the semantics of the instance parameter in the remove_advertising() function. When removing a single instance the method also ensures that another instance will be scheduled if available. When the currently advertising method is being removed, it will be canceled immediately. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for set_advertising*()Florian Grandel
The set_advertising() and set_advertising_complete() methods rely on the now obsolete hci_dev->adv_instance structure. We replace this reference by an equivalent access to the newly introduced dynamic advertising instance list. This patch introduces a helper function that schedules an advertising instance correctly calculating advertising timing based on the timeout and duration settings of the instance. Scheduling is factored into its own function for readability and code sharing. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for create_instance_adv_data()Florian Grandel
The create_instance_adv_data() function could not deal with multiple advertising instances previously. This is being fixed by retrieving advertising instances from the newly introduced dynamic advertising instance list. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for create_instance_scan_rsp_data()Florian Grandel
The create_instance_scan_rsp_data() function could not deal with multiple advertising instances previously. This is being fixed by adding an additional instance parameter. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for enable_advertising()Florian Grandel
Previously enable_advertising() would rely on get_adv_instance_scan_rsp_len() which checked for a hard coded instance identifier. This is being changed to check for the current advertising instance's scan response length instead. The function is renamed accordingly. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: improve get_adv_instance_flags() readabilityFlorian Grandel
Switch if and else conditions to replace a negative statement by a positive one which makes the condition more readable. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for get_adv_instance_flags()Florian Grandel
The get_adv_instance_flags() would not work with instance identifiers other than 0x01. This is being fixed so that arbitrary instance identifiers can be dealt with while still correctly dealing with the special case of the 0x00 identifier. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for get_current_adv_instance()Florian Grandel
Replaces the hard coded instance identifier in get_current_adv_instance() with the actual current instance identifier so that this method is prepared to work with more than one advertising instance. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: multi adv for read_adv_features()Florian Grandel
The read_adv_features() method had a single instance identifier hard coded. Refer to the advertising instance list instead to return a dynamically generated list of instance identifiers. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: rename update_*_data_for_instance()Florian Grandel
The ...for_instance function name is quite long and does not follow the ..._inst_... convention followed elsewhere in the code. This patch renames the ...for_instance functions to their shorter ..._inst_... version. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: mgmt: dry update_scan_rsp_data()Florian Grandel
update_scan_rsp_data() duplicates code from get_current_adv_instance(). This is being fixed by letting the former make use of the latter. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: hci_core/mgmt: move adv timeout to hdevFlorian Grandel
Currently the delayed work managing advertising duration and timeout is part of the advertising instance structure. This is not correct as only a single instance can be advertised at any given time. To implement round robin advertising a single delayed work structure is needed. To fix this the delayed work structure is being moved to the hci_dev structure. The instance specific variable is renamed to "remaining_time" to make it clear that this is the remaining lifetime of the instance and not the current advertising timeout. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18Bluetooth: hci_core/mgmt: Introduce multi-adv listFlorian Grandel
The current hci dev structure only supports a single advertising instance. To support multi-instance advertising it is necessary to introduce a linked list of advertising instances so that multiple advertising instances can be dynamically added and/or removed. In a first step, the existing adv_instance member of the hci_dev struct is supplemented by a linked list of advertising instances. This patch introduces the list and supporting list management infrastructure. The list is not being used yet. Signed-off-by: Florian Grandel <fgrandel@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18KVM: arm/arm64: vgic: Remove useless arm-gic.h #includeMarc Zyngier
Back in the days, vgic.c used to have an intimate knowledge of the actual GICv2. These days, this has been abstracted away into hardware-specific backends. Remove the now useless arm-gic.h #include directive, making it clear that GICv2 specific code doesn't belong here. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2015-06-18Bluetooth: bt3c_cs: Fix coding style -- clean upPrasanna Karthik
Fix for braces {} are not necessary for single statement blocks reported by checkpatch Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2015-06-18s390/pci: improve handling of hotplug event 0x301Sebastian Ott
Hypervisors may deliver event 0x301 not only for standby but also for reserved devices. Just handle event 0x301 regardless of the device's state. Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-06-18s390/setup: fix DMA_API_DEBUG warningsSebastian Ott
Addresses from the usable space in [_ehead, _stext] lead to false positives in DMA_API_DEBUG code (which will complain when an address is in [_text, _etext]). Avoid these warnings by not using that memory in case of CONFIG_DMA_API_DEBUG=y. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-06-18s390/zcrypt: remove obsolete __constantVaishali Thakkar
__constant_cpu_to_le16 converted to cpu_to_le16 Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by: Ingo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-06-18irqchip: atmel-aic5: Add sama5d2 supportNicolas Ferre
Add sama5d2 support to irq-atmel-aic5. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Boris BREZILLON <boris.brezillon@free-electrons.com> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Cc: Ludovic Desroches <ludovic.desroches@atmel.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: <linux-arm-kernel@lists.infradead.org> Link: http://lkml.kernel.org/r/1434632855-27272-1-git-send-email-nicolas.ferre@atmel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-18Merge branch 'next' of ↵James Morris
git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity into next
2015-06-18selftest: Timers: Avoid signal deadlock in leap-a-dayJohn Stultz
In 0c4a5fc95b1df (Add leap-second timer edge testing to leap-a-day.c), we added a timer to the test which checks to make sure timers near the leapsecond edge behave correctly. However, the output generated from the timer uses ctime_r, which isn't async-signal safe, and should that signal land while the main test is using ctime_r to print its output, its possible for the test to deadlock on glibc internal locks. Thus this patch reworks the output to avoid using ctime_r in the signal handler. Signed-off-by: John Stultz <john.stultz@linaro.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jan Kara <jack@suse.cz> Cc: Jiri Bohac <jbohac@suse.cz> Cc: Shuah Khan <shuahkh@osg.samsung.com> Cc: Ingo Molnar <mingo@kernel.org> Link: http://lkml.kernel.org/r/1434565003-3386-1-git-send-email-john.stultz@linaro.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
generated by cgit (git 2.34.1) at 2025-09-16 22:43:55 +0000