aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-07stmmac: debugfs entry name is not be changed when udev rename device name.Jiping Ma1-0/+32
Add one notifier for udev changes net device name. Fixes: b6601323ef9e ("net: stmmac: debugfs entry name is not be changed when udev rename") Signed-off-by: Jiping Ma <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-01-07RDMA/hns: Fix coding style issuesLijun Ou2-143/+92
Fix some coding style issuses without changing logic of codes, most of the modification is unreasonable line breaks and alignments. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lijun Ou <[email protected]> Signed-off-by: Lang Cheng <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Replace custom macros HNS_ROCE_ALIGN_UPWenpeng Liang2-26/+20
HNS_ROCE_ALIGN_UP can be replaced by round_up() which is defined in kernel.h. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wenpeng Liang <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Remove redundant print informationYixing Liu1-1/+0
There are already necessary prints in outer function, prints in hns_roce_function_clear() may confuse users. So these prints is removed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Yixing Liu <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Delete unnessary parameters in hns_roce_v2_qp_modify()Lijun Ou1-3/+1
Current state and new state of qp won't be configured when modifying qp, so these two redundant parameters should be removed. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lijun Ou <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Update the value of qp typeLijun Ou1-5/+7
The values used to represent service type of RC and UD should be interchanged according to design of hardware. And it's better to define these types in enumeration than macros. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lijun Ou <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Remove unused function hns_roce_init_eq_table()Lijun Ou1-1/+0
hns_roce_init_eq_table() is an unused function that only retains its declaration in driver. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lijun Ou <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/hns: Avoid printing address of mtt pageWenpeng Liang1-2/+2
Address of a page shouldn't be printed in case of security issues. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wenpeng Liang <[email protected]> Signed-off-by: Weihang Li <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/core: Add trace points to follow MR allocationChuck Lever2-11/+151
Track the lifetime of ib_mr objects. Here's sample output from a test run with NFS/RDMA: <...>-361 [009] 79238.772782: mr_alloc: pd.id=3 mr.id=11 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772812: mr_alloc: pd.id=3 mr.id=12 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772839: mr_alloc: pd.id=3 mr.id=13 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772866: mr_alloc: pd.id=3 mr.id=14 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772893: mr_alloc: pd.id=3 mr.id=15 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772921: mr_alloc: pd.id=3 mr.id=16 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772947: mr_alloc: pd.id=3 mr.id=17 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.772974: mr_alloc: pd.id=3 mr.id=18 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.773001: mr_alloc: pd.id=3 mr.id=19 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.773028: mr_alloc: pd.id=3 mr.id=20 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79238.773055: mr_alloc: pd.id=3 mr.id=21 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.270942: mr_alloc: pd.id=3 mr.id=22 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.270975: mr_alloc: pd.id=3 mr.id=23 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271007: mr_alloc: pd.id=3 mr.id=24 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271036: mr_alloc: pd.id=3 mr.id=25 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271067: mr_alloc: pd.id=3 mr.id=26 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271095: mr_alloc: pd.id=3 mr.id=27 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271121: mr_alloc: pd.id=3 mr.id=28 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271153: mr_alloc: pd.id=3 mr.id=29 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271181: mr_alloc: pd.id=3 mr.id=30 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271208: mr_alloc: pd.id=3 mr.id=31 type=MEM_REG max_num_sg=30 rc=0 <...>-361 [009] 79240.271236: mr_alloc: pd.id=3 mr.id=32 type=MEM_REG max_num_sg=30 rc=0 <...>-4351 [001] 79242.299400: mr_dereg: mr.id=32 <...>-4351 [001] 79242.299467: mr_dereg: mr.id=31 <...>-4351 [001] 79242.299554: mr_dereg: mr.id=30 <...>-4351 [001] 79242.299615: mr_dereg: mr.id=29 <...>-4351 [001] 79242.299684: mr_dereg: mr.id=28 <...>-4351 [001] 79242.299748: mr_dereg: mr.id=27 <...>-4351 [001] 79242.299812: mr_dereg: mr.id=26 <...>-4351 [001] 79242.299874: mr_dereg: mr.id=25 <...>-4351 [001] 79242.299944: mr_dereg: mr.id=24 <...>-4351 [001] 79242.300009: mr_dereg: mr.id=23 <...>-4351 [001] 79242.300190: mr_dereg: mr.id=22 <...>-4351 [001] 79242.300263: mr_dereg: mr.id=21 <...>-4351 [001] 79242.300326: mr_dereg: mr.id=20 <...>-4351 [001] 79242.300388: mr_dereg: mr.id=19 <...>-4351 [001] 79242.300450: mr_dereg: mr.id=18 <...>-4351 [001] 79242.300516: mr_dereg: mr.id=17 <...>-4351 [001] 79242.300629: mr_dereg: mr.id=16 <...>-4351 [001] 79242.300718: mr_dereg: mr.id=15 <...>-4351 [001] 79242.300784: mr_dereg: mr.id=14 <...>-4351 [001] 79242.300879: mr_dereg: mr.id=13 <...>-4351 [001] 79242.300945: mr_dereg: mr.id=12 <...>-4351 [001] 79242.301012: mr_dereg: mr.id=11 Some features of the output: - The lifetime and owner PD of each MR is clearly visible. - The type of MR is captured, as is the SGE array size. - Failing MR allocation can be recorded. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/core: Trace points for diagnosing completion queue issuesChuck Lever6-4/+320
Sample trace events: kworker/u29:0-300 [007] 120.042217: cq_alloc: cq.id=4 nr_cqe=161 comp_vector=2 poll_ctx=WORKQUEUE <idle>-0 [002] 120.056292: cq_schedule: cq.id=4 kworker/2:1H-482 [002] 120.056402: cq_process: cq.id=4 wake-up took 109 [us] from interrupt kworker/2:1H-482 [002] 120.056407: cq_poll: cq.id=4 requested 16, returned 1 <idle>-0 [002] 120.067503: cq_schedule: cq.id=4 kworker/2:1H-482 [002] 120.067537: cq_process: cq.id=4 wake-up took 34 [us] from interrupt kworker/2:1H-482 [002] 120.067541: cq_poll: cq.id=4 requested 16, returned 1 <idle>-0 [002] 120.067657: cq_schedule: cq.id=4 kworker/2:1H-482 [002] 120.067672: cq_process: cq.id=4 wake-up took 15 [us] from interrupt kworker/2:1H-482 [002] 120.067674: cq_poll: cq.id=4 requested 16, returned 1 ... systemd-1 [002] 122.392653: cq_schedule: cq.id=4 kworker/2:1H-482 [002] 122.392688: cq_process: cq.id=4 wake-up took 35 [us] from interrupt kworker/2:1H-482 [002] 122.392693: cq_poll: cq.id=4 requested 16, returned 16 kworker/2:1H-482 [002] 122.392836: cq_poll: cq.id=4 requested 16, returned 16 kworker/2:1H-482 [002] 122.392970: cq_poll: cq.id=4 requested 16, returned 16 kworker/2:1H-482 [002] 122.393083: cq_poll: cq.id=4 requested 16, returned 16 kworker/2:1H-482 [002] 122.393195: cq_poll: cq.id=4 requested 16, returned 3 Several features to note in this output: - The WCE count and context type are reported at allocation time - The CPU and kworker for each CQ is evident - The CQ's restracker ID is tagged on each trace event - CQ poll scheduling latency is measured - Details about how often single completions occur versus multiple completions are evident - The cost of the ULP's completion handler is recorded Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chuck Lever <[email protected]> Reviewed-by: Parav Pandit <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07RDMA/cma: Add trace points in RDMA Connection ManagerChuck Lever4-23/+475
Record state transitions as each connection is established. The IP address of both peers and the Type of Service is reported. These trace points are not in performance hot paths. Also, record each cm_event_handler call to ULPs. This eliminates the need for each ULP to add its own similar trace point in its CM event handler function. These new trace points appear in a new trace subsystem called "rdma_cma". Sample events: <...>-220 [004] 121.430733: cm_id_create: cm.id=0 <...>-472 [003] 121.430991: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ADDR_RESOLVED (0/0) <...>-472 [003] 121.430995: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-472 [003] 121.431172: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ROUTE_RESOLVED (2/0) <...>-472 [003] 121.431174: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 121.433480: cm_qp_create: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 pd.id=2 qp_type=RC send_wr=4091 recv_wr=256 qp_num=521 rc=0 <...>-220 [004] 121.433577: cm_send_req: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 kworker/1:2-973 [001] 121.436190: cm_send_mra: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436340: cm_send_rtu: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/1:2-973 [001] 121.436359: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 ESTABLISHED (9/0) kworker/1:2-973 [001] 121.436365: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-1975 [005] 123.161954: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-1975 [005] 123.161974: cm_sent_dreq: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 <...>-220 [004] 123.162102: cm_disconnect: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 kworker/0:1-13 [000] 123.162391: cm_event_handler: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 DISCONNECTED (10/0) kworker/0:1-13 [000] 123.162393: cm_event_done: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 result=0 <...>-220 [004] 123.164456: cm_qp_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 qp_num=521 <...>-220 [004] 123.165290: cm_id_destroy: cm.id=0 src=192.168.2.51:35090 dst=192.168.2.55:20049 tos=0 Some features to note: - restracker ID of the rdma_cm_id is tagged on each trace event - The source and destination IP addresses and TOS are reported - CM event upcalls are shown with decoded event and status - CM state transitions are reported - rdma_cm_id lifetime events are captured - The latency of ULP CM event handlers is reported - Lifetime events of associated QPs are reported - Device removal and insertion is reported This patch is based on previous work by: Saeed Mahameed <[email protected]> Mukesh Kacker <[email protected]> Ajaykumar Hotchandani <[email protected]> Aron Silverton <[email protected]> Avinash Repaka <[email protected]> Somasundaram Krishnasamy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07io_uring: remove punt of short reads to async contextJens Axboe1-12/+0
We currently punt any short read on a regular file to async context, but this fails if the short read is due to running into EOF. This is especially problematic since we only do the single prep for commands now, as we don't reset kiocb->ki_pos. This can result in a 4k read on a 1k file returning zero, as we detect the short read and then retry from async context. At the time of retry, the position is now 1k, and we end up reading nothing, and hence return 0. Instead of trying to patch around the fact that short reads can be legitimate and won't succeed in case of retry, remove the logic to punt a short read to async context. Simply return it. Signed-off-by: Jens Axboe <[email protected]>
2020-01-07i40iw: Remove setting of VMA private data and use rdma_user_mmap_ioShiraz Saleem1-8/+6
vm_ops is now initialized in ib_uverbs_mmap() with the recent rdma mmap API changes. Earlier it was done in rdma_umap_priv_init() which would not be called unless a driver called rdma_user_mmap_io() in its mmap. i40iw does not use the rdma_user_mmap_io API but sets the vma's vm_private_data to a driver object. This now conflicts with the vm_op rdma_umap_close as priv pointer points to the i40iw driver object instead of the private data setup by core when rdma_user_mmap_io is called. This leads to a crash in rdma_umap_close with a mmap put being called when it should not have. Remove the redundant setting of the vma private_data in i40iw as it is not used. Also move i40iw over to use the rdma_user_mmap_io API. This gives the extra protection of having the mappings zapped when the context is detsroyed. BUG: unable to handle page fault for address: 0000000100000001 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP PTI CPU: 6 PID: 9528 Comm: rping Kdump: loaded Not tainted 5.5.0-rc4+ #117 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./Q87M-D2H, BIOS F7 01/17/2014 RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core] RSP: 0018:ffffb340c04c7c38 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ffff9308e7be2a00 RCX: 000000000000cec0 RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000100000001 RBP: ffff9308dc7641f0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff8d4414d8 R12: ffff93075182c780 R13: 0000000000000001 R14: ffff93075182d2a8 R15: ffff9308e2ddc840 FS: 0000000000000000(0000) GS:ffff9308fdc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000100000001 CR3: 00000002e0412004 CR4: 00000000001606e0 Call Trace: rdma_umap_close+0x40/0x90 [ib_uverbs] remove_vma+0x43/0x80 exit_mmap+0xfd/0x1b0 mmput+0x6e/0x130 do_exit+0x290/0xcc0 ? get_signal+0x152/0xc40 do_group_exit+0x46/0xc0 get_signal+0x1bd/0xc40 ? prepare_to_wait_event+0x97/0x190 do_signal+0x36/0x630 ? remove_wait_queue+0x60/0x60 ? __audit_syscall_exit+0x1d9/0x290 ? rcu_read_lock_sched_held+0x52/0x90 ? kfree+0x21c/0x2e0 exit_to_usermode_loop+0x4f/0xc3 do_syscall_64+0x1ed/0x270 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fae715a81fd Code: Bad RIP value. RSP: 002b:00007fae6e163cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: fffffffffffffe00 RBX: 00007fae6e163d30 RCX: 00007fae715a81fd RDX: 0000000000000010 RSI: 00007fae6e163cf0 RDI: 0000000000000003 RBP: 00000000013413a0 R08: 00007fae68000000 R09: 0000000000000017 R10: 0000000000000001 R11: 0000000000000293 R12: 00007fae680008c0 R13: 00007fae6e163cf0 R14: 00007fae717c9804 R15: 00007fae6e163ed0 CR2: 0000000100000001 ---[ end trace b33d58d3a06782cb ]--- RIP: 0010:rdma_user_mmap_entry_put+0xa/0x30 [ib_core] Fixes: b86deba977a9 ("RDMA/core: Move core content from ib_uverbs to ib_core") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-01-07drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpuChunming Zhou1-1/+2
Can expose it now that the khronos has exposed the vlk extension. Signed-off-by: Chunming Zhou <[email protected]> Reviewed-by: Flora Cui <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-01-07drm/amd/display: Reduce HDMI pixel encoding if max clock is exceededThomas Anderson1-22/+23
For high-res (8K) or HFR (4K120) displays, using uncompressed pixel formats like YCbCr444 would exceed the bandwidth of HDMI 2.0, so the "interesting" modes would be disabled, leaving only low-res or low framerate modes. This change lowers the pixel encoding to 4:2:2 or 4:2:0 if the max TMDS clock is exceeded. Verified that 8K30 and 4K120 are now available and working with a Samsung Q900R over an HDMI 2.0b link from a Radeon 5700. Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Thomas Anderson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-01-07Revert "drm/amdgpu: Set no-retry as default."Alex Deucher1-2/+2
This reverts commit 51bfac71cade386966791a8db87a5912781d249f. This causes stability issues on some raven boards. Revert for now until a proper fix is completed. Bug: https://gitlab.freedesktop.org/drm/amd/issues/934 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=206017 Reviewed-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-01-07iommu/dma: fix variable 'cookie' set but not usedQian Cai1-3/+0
The commit c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") introduced a compliation warning, drivers/iommu/dma-iommu.c: In function 'iommu_dma_prepare_msi': drivers/iommu/dma-iommu.c:1206:27: warning: variable 'cookie' set but not used [-Wunused-but-set-variable] struct iommu_dma_cookie *cookie; ^~~~~~ Fixes: c18647900ec8 ("iommu/dma: Relax locking in iommu_dma_prepare_msi()") Signed-off-by: Qian Cai <[email protected]> Acked-by: Robin Murphy <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu/vt-d: Unlink device if failed to add to groupJon Derrick1-3/+10
If the device fails to be added to the group, make sure to unlink the reference before returning. Signed-off-by: Jon Derrick <[email protected]> Fixes: 39ab9555c2411 ("iommu: Add sysfs bindings for struct iommu_device") Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu: Remove device link to group on failureJon Derrick1-0/+1
This adds the missing teardown step that removes the device link from the group when the device addition fails. Signed-off-by: Jon Derrick <[email protected]> Fixes: 797a8b4d768c5 ("iommu: Handle default domain attach failure") Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07iommu/vt-d: Fix adding non-PCI devices to Intel IOMMUPatrick Steinhardt1-1/+8
Starting with commit fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices"), we now probe DMA-capable ACPI name space devices. On Dell XPS 13 9343, which has an Intel LPSS platform device INTL9C60 enumerated via ACPI, this change leads to the following warning: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at pci_device_group+0x11a/0x130 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G T 5.5.0-rc3+ #22 Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A20 06/06/2019 RIP: 0010:pci_device_group+0x11a/0x130 Code: f0 ff ff 48 85 c0 49 89 c4 75 c4 48 8d 74 24 10 48 89 ef e8 48 ef ff ff 48 85 c0 49 89 c4 75 af e8 db f7 ff ff 49 89 c4 eb a5 <0f> 0b 49 c7 c4 ea ff ff ff eb 9a e8 96 1e c7 ff 66 0f 1f 44 00 00 RSP: 0000:ffffc0d6c0043cb0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffffa3d1d43dd810 RCX: 0000000000000000 RDX: ffffa3d1d4fecf80 RSI: ffffa3d12943dcc0 RDI: ffffa3d1d43dd810 RBP: ffffa3d1d43dd810 R08: 0000000000000000 R09: ffffa3d1d4c04a80 R10: ffffa3d1d4c00880 R11: ffffa3d1d44ba000 R12: 0000000000000000 R13: ffffa3d1d4383b80 R14: ffffa3d1d4c090d0 R15: ffffa3d1d4324530 FS: 0000000000000000(0000) GS:ffffa3d1d6700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000460a001 CR4: 00000000003606e0 Call Trace: ? iommu_group_get_for_dev+0x81/0x1f0 ? intel_iommu_add_device+0x61/0x170 ? iommu_probe_device+0x43/0xd0 ? intel_iommu_init+0x1fa2/0x2235 ? pci_iommu_init+0x52/0xe7 ? e820__memblock_setup+0x15c/0x15c ? do_one_initcall+0xcc/0x27e ? kernel_init_freeable+0x169/0x259 ? rest_init+0x95/0x95 ? kernel_init+0x5/0xeb ? ret_from_fork+0x35/0x40 ---[ end trace 28473e7abc25b92c ]--- DMAR: ACPI name space devices didn't probe correctly The bug results from the fact that while we now enumerate ACPI devices, we aren't able to handle any non-PCI device when generating the device group. Fix the issue by implementing an Intel-specific callback that returns `pci_device_group` only if the device is a PCI device. Otherwise, it will return a generic device group. Fixes: fa212a97f3a3 ("iommu/vt-d: Probe DMA-capable ACPI name space devices") Signed-off-by: Patrick Steinhardt <[email protected]> Cc: [email protected] # v5.3+ Acked-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2020-01-07drm/fb-helper: Round up bits_per_pixel if possibleGeert Uytterhoeven1-1/+6
When userspace requests a video mode parameter value that is not supported, frame buffer device drivers should round it up to a supported value, if possible, instead of just rejecting it. This allows applications to quickly scan for supported video modes. Currently this rule is not followed for the number of bits per pixel, causing e.g. "fbset -depth N" to fail, if N is smaller than the current number of bits per pixel. Fix this by returning an error only if bits per pixel is too large, and setting it to the current value otherwise. See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View of /dev/fb*"). Fixes: 865afb11949e5bf4 ("drm/fb-helper: reject any changes to the fbdev") Cc: [email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/sun4i: tcon: Set RGB DCLK min. divider based on hardware modelChen-Yu Tsai2-3/+13
In commit 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") it was assumed that all TCON variants support a minimum divider of 1 if only DCLK was used. However, the oldest generation of hardware only supports minimum divider of 4 if only DCLK is used. If a divider of 1 was used on this old hardware, some scrolling artifact would appear. A divider of 2 seemed OK, but a divider of 3 had artifacts as well. Set the minimum divider when outputing to parallel RGB based on the hardware model, with a minimum of 4 for the oldest (A10/A10s/A13/A20) hardware, and a minimum of 1 for the rest. A value is not set for the TCON variants lacking channel 0. This fixes the scrolling artifacts seen on my A13 tablet. Fixes: 0b8e7bbde5e7 ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") Cc: <[email protected]> # 5.4.x Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-01-07drm/i915/dp: Disable Port sync mode correctly on teardownManasi Navare1-6/+1
While clearing the Ports ync mode enable and master select bits we need to clear the register completely instead of using disable masks v3: * Remove reg variable (Matt) v2: * Just write 0 to the reg (Ville) * Rebase Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/5 Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Fixes: 51528afe7c5e ("drm/i915/display/icl: Disable transcoder port sync as part of crtc_disable() sequence") Signed-off-by: Manasi Navare <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a3d9382bd439e7be1858abc3d5f014dd55913448) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915: Add Wa_1407352427:icl,ehlMatt Roper2-0/+7
The workaround database now indicates we need to disable psdunit clock gating as well. v3: - Rebase on top of other workarounds that have landed. - Restrict cc:stable tag to 5.2+ since that's when ICL was first officially supported. Bspec: 32354 Bspec: 33450 Bspec: 33451 Suggested-by: Lionel Landwerlin <[email protected]> Cc: [email protected] # v5.2+ Cc: Lionel Landwerlin <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Matt Atwood <[email protected]> Signed-off-by: Matt Roper <[email protected]> Acked-by: Lionel Landwerlin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1cd21a7c5679015352e8a6f46813aced51d71bb8) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915: Add Wa_1408615072 and Wa_1407596294 to icl,ehlMatt Roper2-1/+11
Workaround database indicates we should disable clock gating of both the vsunit and hsunit. Bspec: 33450 Bspec: 33451 Cc: [email protected] Cc: Lucas De Marchi <[email protected]> Cc: Matt Atwood <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Lucas De Marchi <[email protected]> (cherry picked from commit b9cf9dac3dac4c1d2a47d34f30ec53c0423cecf8) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915/gt: Restore coarse power gatingChris Wilson1-2/+4
The coarse power gating was disabled as part of commit 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") as a prelude to recover from the context corruption; the power gating itself has no direct impact on the RC6 context corruption. However, that recovery scheme was never implemented due to difficult corner cases, and so we no longer need to keep the power gating disabled. Fixes: 2248a28384fe ("drm/i915/gen8+: Add RC6 CTX corruption WA") Closes: https://gitlab.freedesktop.org/drm/intel/issues/846 Signed-off-by: Chris Wilson <[email protected]> Cc: Imre Deak <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Eero Tamminen <[email protected]> Cc: Jon Bloomfield <[email protected]> Reviewed-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 32f408ac3e5d95781f52328a09e5409b01255841) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915/gt: Do not restore invalid RS stateChris Wilson1-20/+11
Only restore valid resource streamer state from the context image, i.e. avoid restoring if we know the image is invalid. Closes: https://gitlab.freedesktop.org/drm/intel/issues/446 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Cc: [email protected] (cherry picked from commit ecfcd2da335816516dc27434a65899a77886d80a) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07um: Implement copy_thread_tlsAmanieu d'Antras5-12/+10
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07clone3: ensure copy_thread_tls is implementedAmanieu d'Antras1-0/+10
copy_thread implementations handle CLONE_SETTLS by reading the TLS value from the registers containing the syscall arguments for clone. This doesn't work with clone3 since the TLS value is passed in clone_args instead. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07xtensa: Implement copy_thread_tlsAmanieu d'Antras2-4/+5
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07riscv: Implement copy_thread_tlsAmanieu d'Antras2-3/+4
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07parisc: Implement copy_thread_tlsAmanieu d'Antras2-4/+5
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07arm: Implement copy_thread_tlsAmanieu d'Antras2-3/+4
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07arm64: Implement copy_thread_tlsAmanieu d'Antras2-5/+6
This is required for clone3 which passes the TLS value through a struct rather than a register. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Acked-by: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07arm64: Move __ARCH_WANT_SYS_CLONE3 definition to uapi headersAmanieu d'Antras2-1/+1
Previously this was only defined in the internal headers which resulted in __NR_clone3 not being defined in the user headers. Signed-off-by: Amanieu d'Antras <[email protected]> Cc: [email protected] Cc: <[email protected]> # 5.3.x Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]>
2020-01-07gpiolib: acpi: Add honor_wakeup module-option + quirk mechanismHans de Goede1-1/+31
On some laptops enabling wakeup on the GPIO interrupts used for ACPI _AEI event handling causes spurious wakeups. This commit adds a new honor_wakeup option, defaulting to true (our current behavior), which can be used to disable wakeup on troublesome hardware to avoid these spurious wakeups. This is a workaround for an architectural problem with s2idle under Linux where we do not have any mechanism to immediately go back to sleep after wakeup events, other then for embedded-controller events using the standard ACPI EC interface, for details see: https://lore.kernel.org/linux-acpi/[email protected]/ One series of laptops which is not able to suspend without this workaround is the HP x2 10 Cherry Trail models, this commit adds a DMI based quirk which makes sets honor_wakeup to false on these models. Cc: [email protected] Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-01-07gpiolib: acpi: Turn dmi_system_id table into a generic quirk tableHans de Goede1-4/+15
Turn the existing run_edge_events_on_boot_blacklist dmi_system_id table into a generic quirk table, storing the quirks in the driver_data ptr. This is a preparation patch for adding other types of (DMI based) quirks. Cc: [email protected] Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-01-07powercap: intel_rapl: add NULL pointer check to rapl_mmio_cpu_online()Harry Pan1-0/+3
RAPL MMIO support depends on the RAPL common driver. During CPU initialization rapl_mmio_cpu_online() is called via CPU hotplug to initialize the MMIO RAPL for the new CPU, but if that CPU is not present in the common RAPL driver's support list, rapl_defaults is NULL and the kernel crashes on an attempt to dereference it: [ 4.188566] BUG: kernel NULL pointer dereference, address: 0000000000000020 ...snip... [ 4.189555] RIP: 0010:rapl_add_package+0x223/0x574 [ 4.189555] Code: b5 a0 31 c0 49 8b 4d 78 48 01 d9 48 8b 0c c1 49 89 4c c6 10 48 ff c0 48 83 f8 05 75 e7 49 83 ff 03 75 15 48 8b 05 09 bc 18 01 <8b> 70 20 41 89 b6 0c 05 00 00 85 f6 75 1a 49 81 c6 18 9 [ 4.189555] RSP: 0000:ffffb3adc00b3d90 EFLAGS: 00010246 [ 4.189555] RAX: 0000000000000000 RBX: 0000000000000098 RCX: 0000000000000000 [ 4.267161] usb 1-1: New USB device found, idVendor=2109, idProduct=2812, bcdDevice= b.e0 [ 4.189555] RDX: 0000000000001000 RSI: 0000000000000000 RDI: ffff9340caafd000 [ 4.189555] RBP: ffffb3adc00b3df8 R08: ffffffffa0246e28 R09: ffff9340caafc000 [ 4.189555] R10: 000000000000024a R11: ffffffff9ff1f6f2 R12: 00000000ffffffed [ 4.189555] R13: ffff9340caa94800 R14: ffff9340caafc518 R15: 0000000000000003 [ 4.189555] FS: 0000000000000000(0000) GS:ffff9340ce200000(0000) knlGS:0000000000000000 [ 4.189555] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4.189555] CR2: 0000000000000020 CR3: 0000000302c14001 CR4: 00000000003606f0 [ 4.189555] Call Trace: [ 4.189555] ? __switch_to_asm+0x40/0x70 [ 4.189555] rapl_mmio_cpu_online+0x47/0x64 [ 4.189555] ? rapl_mmio_write_raw+0x33/0x33 [ 4.281059] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 4.189555] cpuhp_invoke_callback+0x29f/0x66f [ 4.189555] ? __schedule+0x46d/0x6a0 [ 4.189555] cpuhp_thread_fun+0xb9/0x11c [ 4.189555] smpboot_thread_fn+0x17d/0x22f [ 4.297006] usb 1-1: Product: USB2.0 Hub [ 4.189555] ? cpu_report_death+0x43/0x43 [ 4.189555] kthread+0x137/0x13f [ 4.189555] ? cpu_report_death+0x43/0x43 [ 4.189555] ? kthread_blkcg+0x2e/0x2e [ 4.312951] usb 1-1: Manufacturer: VIA Labs, Inc. [ 4.189555] ret_from_fork+0x1f/0x40 [ 4.189555] Modules linked in: [ 4.189555] CR2: 0000000000000020 [ 4.189555] ---[ end trace 01bb812aabc791f4 ]--- To avoid that problem, check rapl_defaults NULL upfront and return an error code if it is NULL. [Note that it does not make sense to even try to allocate memory in that case, because it is not going to be used anyway.] Fixes: 555c45fe0d04 ("int340X/processor_thermal_device: add support for MMIO RAPL") Cc: 5.3+ <[email protected]> # 5.3+ Signed-off-by: Harry Pan <[email protected]> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <[email protected]>
2020-01-07drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK onlyKai Vehmanen1-2/+2
Revert changes done in commit f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms"). Audio drivers communicate with i915 over HDA bus multiple times during system boot-up and each of these transactions result in matching get_power/put_power calls to i915, and depending on the platform, a modeset change causing visible flicker. GLK is the only platform with minimum CDCLK significantly lower than BCLK, and thus for GLK setting a higher CDCLK is mandatory. For other platforms, minimum CDCLK is close but below 2*BCLK (e.g. on ICL, CDCLK=176.4kHz with BCLK=96kHz). Spec-wise the constraint should be set, but in practise no communication errors have been reported and the downside if set is the flicker observed at boot-time. Revert to old behaviour until better mechanism to manage probe-time clocks is available. The full CDCLK>=2*BCLK constraint is still enforced at pipe enable time in intel_crtc_compute_min_cdclk(). Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/913 Fixes: f6ec9483091f ("drm/i915: extend audio CDCLK>=2*BCLK constraint to more platforms") Signed-off-by: Kai Vehmanen <[email protected]> Reviewed-by: Matt Roper <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1ee48a61aa57dbdbc3cd2808d8b28df40d938e44) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07drm/i915/gt: Mark up virtual engine uabi_instanceChris Wilson1-0/+2
Be sure to initialise the uabi_instance on the virtual engine to the special invalid value, just in case we ever peek at it from the uAPI. Reported-by: Tvrtko Ursulin <[email protected]> Fixes: 750e76b4f9f6 ("drm/i915/gt: Move the [class][inst] lookup for engines onto the GT") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.4+ Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit f75fc37b5e70b75f21550410f88e2379648120e2) Signed-off-by: Joonas Lahtinen <[email protected]>
2020-01-07gpio: zynq: Fix for bug in zynq_gpio_restore_context APISwapna Manupati1-3/+5
This patch writes the inverse value of Interrupt Mask Status register into the Interrupt Enable register in zynq_gpio_restore_context API to fix the bug. Fixes: e11de4de28c0 ("gpio: zynq: Add support for suspend resume") Signed-off-by: Swapna Manupati <[email protected]> Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Srinivas Neeli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-01-07pinctrl: meson: Fix wrong shift value when get drive-strengthQianggui Song1-0/+1
In meson_pinconf_get_drive_strength, variable bit is calculated by meson_calc_reg_and_bit, this value is the offset from the first pin of a certain bank to current pin, while Meson SoCs use two bits for each pin to depict drive-strength. So a left shift by 1 should be done or node pinconf-pins shows wrong message. Fixes: 6ea3e3bbef37 ("pinctrl: meson: add support of drive-strength-microamp") Signed-off-by: Qianggui Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-01-07pinctrl: lochnagar: select GPIOLIBArnd Bergmann1-0/+1
In a rare randconfig build I came across one configuration that does not enable CONFIG_GPIOLIB, which is needed by lochnagar: ERROR: "devm_gpiochip_add_data" [drivers/pinctrl/cirrus/pinctrl-lochnagar.ko] undefined! ERROR: "gpiochip_generic_free" [drivers/pinctrl/cirrus/pinctrl-lochnagar.ko] undefined! ERROR: "gpiochip_generic_request" [drivers/pinctrl/cirrus/pinctrl-lochnagar.ko] undefined! ERROR: "gpiochip_get_data" [drivers/pinctrl/cirrus/pinctrl-lochnagar.ko] undefined! Add another 'select' like all other pinctrl drivers have. Fixes: 0548448b719a ("pinctrl: lochnagar: Add support for the Cirrus Logic Lochnagar") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Charles Keepax <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2020-01-07Merge branch 'cpufreq/arm/fixes' of ↵Rafael J. Wysocki1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull cpufreq driver fix for v5.5-rc6 from Viresh Kumar: "Blacklist Tegra20/30 for probing by cpufreq-dt driver." * 'cpufreq/arm/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: dt-platdev: Blacklist NVIDIA Tegra20 and Tegra30 SoCs
2020-01-07drivers: thermal: tsens: Work with old DTBsAmit Kucheria1-0/+3
In order for the old DTBs to continue working, the new interrupt code must not return an error if interrupts are not defined. Don't return an error in case of -ENXIO. Fixes: 634e11d5b450a ("drivers: thermal: tsens: Add interrupt support") Suggested-by: Stephan Gerhold <[email protected]> Signed-off-by: Amit Kucheria <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Tested-by: Bjorn Andersson <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/cea3317c5d793db312064d68b261ad420a4a81b1.1576146898.git.amit.kucheria@linaro.org
2020-01-06Merge tag 'mlx5-fixes-2020-01-06' of ↵David S. Miller10-96/+119
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== Mellanox, mlx5 fixes 2020-01-06 This series introduces some fixes to mlx5 driver. Please pull and let me know if there is any problem. For -stable v5.3 ('net/mlx5: Move devlink registration before interfaces load') For -stable v5.4 ('net/mlx5e: Fix hairpin RSS table size') ('net/mlx5: DR, Init lists that are used in rule's member') ('net/mlx5e: Always print health reporter message to dmesg') ('net/mlx5: DR, No need for atomic refcount for internal SW steering resources') ==================== Signed-off-by: David S. Miller <[email protected]>
2020-01-06Merge tag 'trace-v5.5-rc5' of ↵Linus Torvalds7-10/+31
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing fixes from Steven Rostedt: "Various tracing fixes: - kbuild found missing define of MCOUNT_INSN_SIZE for various build configs - Initialize variable to zero as gcc thinks it is used undefined (it really isn't but the code is subtle enough that this doesn't hurt) - Convert from do_div() to div64_ull() to prevent potential divide by zero - Unregister a trace point on error path in sched_wakeup tracer - Use signed offset for archs that can have stext not be first - A simple indentation fix (whitespace error)" * tag 'trace-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Fix indentation issue kernel/trace: Fix do not unregister tracepoints when register sched_migrate_task fail tracing: Change offset type to s32 in preempt/irq tracepoints ftrace: Avoid potential division by zero in function profiler tracing: Have stack tracer compile when MCOUNT_INSN_SIZE is not defined tracing: Define MCOUNT_INSN_SIZE when not defined without direct calls tracing: Initialize val to zero in parse_entry of inject code
2020-01-06net/mlx5: DR, Init lists that are used in rule's memberErez Shitrit1-0/+3
Whenever adding new member of rule object we attach it to 2 lists, These 2 lists should be initialized first. Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: Erez Shitrit <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-01-06net/mlx5e: Fix hairpin RSS table sizeEli Cohen3-17/+17
Set hairpin table size to the corret size, based on the groups that would be created in it. Groups are laid out on the table such that a group occupies a range of entries in the table. This implies that the group ranges should have correspondence to the table they are laid upon. The patch cited below made group 1's size to grow hence causing overflow of group range laid on the table. Fixes: a795d8db2a6d ("net/mlx5e: Support RSS for IP-in-IP and IPv6 tunneled packets") Signed-off-by: Eli Cohen <[email protected]> Signed-off-by: Mark Bloch <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2020-01-06net/mlx5: DR, No need for atomic refcount for internal SW steering resourcesYevgeny Kliteynik3-12/+14
No need for an atomic refcounter for the STE and hashtables. These are internal SW steering resources and they are always under domain mutex. This also fixes the following refcount error: refcount_t: addition on 0; use-after-free. WARNING: CPU: 9 PID: 3527 at lib/refcount.c:25 refcount_warn_saturate+0x81/0xe0 Call Trace: dr_table_init_nic+0x10d/0x110 [mlx5_core] mlx5dr_table_create+0xb4/0x230 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x39/0x120 [mlx5_core] __mlx5_create_flow_table+0x221/0x5f0 [mlx5_core] esw_create_offloads_fdb_tables+0x180/0x5a0 [mlx5_core] ... Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Alex Vesker <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.