- 15 Jul, 2015 20 commits
-
-
Axel Lin authored
commit ebb6ad73 upstream. VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Axel Lin authored
commit 14ba3ec1 upstream. According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by:
-
Axel Lin authored
commit 63781394 upstream. request_any_context_irq() returns a negative value on failure. It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success. So fix testing return value of request_any_context_irq(). Also fixup the return value of devm_request_any_context_irq() to make it consistent with request_any_context_irq(). Fixes: 0668d306 ("genirq: Add devm_request_any_context_irq()") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Horia Geant? authored
commit 69d9cd8c upstream. This reverts commit 7291a932. The conversion to be16_add_cpu() is incorrect in case cryptlen is negative due to premature (i.e. before addition / subtraction) implicit conversion of cryptlen (int -> u16) leading to sign loss. Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Horia Geanta <horia.geanta@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Horia Geant? authored
commit 5fa7dadc upstream. Fixes: 1d11911a ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function") Signed-off-by:
-
Grygorii Strashko authored
commit 084609bf upstream. Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41 (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Acked-by:
Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Joe Konno authored
commit 0dd23f94 upstream. Commit 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) introduced byt_set_pstate() with the assumption that it would always be run by the CPU whose MSR is to be written by it. It turns out, however, that is not always the case in practice, so modify byt_set_pstate() to enforce the MSR write done by it to always happen on the right CPU. Fixes: 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) Signed-off-by:
Joe Konno <joe.konno@intel.com> Acked-by:
Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by:
-
David Härdeman authored
commit 4d298b85 upstream. commit af3a4a9b ("[media] dib0700: NEC scancode cleanup") cleaned up the NEC scancode logic but overlooked the RC5 case. This patch brings the RC5 case in line with the NEC code and makes the struct self-documenting. Signed-off-by:
David Härdeman <david@hardeman.nu> Reported-by:
David Cimbůrek <david.cimburek@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Brian Norris authored
commit 073db4a5 upstream. On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50 kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8 kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200 kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30 kernel: [<ffffffff8022006c>] __fput+0xac/0x250 kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120 kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Reported-by:
Zhang Xingcai <zhangxingcai@huawei.com> Reported-by:
Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com> Tested-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Martin Sperl authored
commit 8e76ef88 upstream. Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by:
Noralf Trønnes <noralf@tronnes.org> Suggested-by:
Martin Sperl <kernel@martin.sperl.org> Signed-off-by:
-
Liu Ying authored
commit 2fa3b4c4 upstream. The LCDIF engines embedded in i.MX6sl and i.MX6sx SoCs need the axi clock as the engine's system clock. The clock should be enabled when accessing LCDIF registers, otherwise the kernel would hang up. We should also keep the clock enabled when the engine is being active to scan out frames from memory. This patch makes sure the axi clock is enabled when accessing registers so that the kernel hang up issue can be fixed. Reported-by:
Peter Chen <peter.chen@freescale.com> Tested-by:
Liu Ying <Ying.Liu@freescale.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Antonio Ospite authored
commit 61e2c70d upstream. This id has been seen in the DSDT of the Teclast X98 Air 3G tablet based on Intel Bay Trail. Signed-off-by:
Antonio Ospite <ao2@ao2.it> Cc: Bastien Nocera <hadess@hadess.net> Reviewed-by:
Daniel Baluta <daniel.baluta@intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Dmitry Osipenko authored
commit 4d48edb3 upstream. Commit 7232398a ("ARM: tegra: Convert PMC to a driver") changed tegra_resume() location storing from late to early and, as a result, broke suspend on Tegra20. PMC scratch register 41 is used by tegra LP1 resume code for retrieving stored physical memory address of common resume function and in the same time used by tegra20_cpu_shutdown() (shared by Tegra20 cpuidle driver and platform SMP code), which is storing CPU1 "resettable" status. It implies strict order of scratch register usage, otherwise resume function address is lost on Tegra20 after disabling non-boot CPU's on suspend. Fix it by storing "resettable" status in IRAM instead of PMC scratch register. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Fixes: 7232398a (ARM: tegra: Convert PMC to a driver) Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Pawel Moll authored
commit a18f8e97 upstream. Events defined as watchpoints on nodes must have their config values converted so that they apply to the respective node's XP. The function setting new values was using wrong mask for the "port" field, resulting in corrupted value. Fixed now. Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
-
Hans Verkuil authored
commit 2b4fd3ed upstream. The cx18 PCM video device didn't have any capabilities set, which caused a warnings in the v4l2 core: [ 6.229393] ------------[ cut here ]------------ [ 6.229414] WARNING: CPU: 1 PID: 593 at drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70 [videodev]() [ 6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper [ 6.229444] drm ptp pps_core video [ 6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted 3.19.3-200.fc21.x86_64 #1 [ 6.229447] Hardware name: Gigabyte Technology Co., Ltd. Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014 [ 6.229448] 0000000000000000 00000000d12b1131 ffff88042dacfc28 ffffffff8176e215 [ 6.229449] 0000000000000000 0000000000000000 ffff88042dacfc68 ffffffff8109bc1a [ 6.229451] ffffffffa0594000 ffff88042dacfd90 0000000000000000 ffffffffa04e2140 [ 6.229452] Call Trace: [ 6.229466] [<ffffffff8176e215>] dump_stack+0x45/0x57 [ 6.229469] [<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0 [ 6.229472] [<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20 [ 6.229474] [<ffffffffa04ca401>] v4l_querycap+0x41/0x70 [videodev] [ 6.229477] [<ffffffffa04ca6cc>] __video_do_ioctl+0x29c/0x320 [videodev] [ 6.229479] [<ffffffff81227131>] ? do_last+0x2f1/0x1210 [ 6.229491] [<ffffffffa04cc776>] video_usercopy+0x366/0x5d0 [videodev] [ 6.229494] [<ffffffffa04ca430>] ? v4l_querycap+0x70/0x70 [videodev] [ 6.229497] [<ffffffffa04cc9f5>] video_ioctl2+0x15/0x20 [videodev] [ 6.229499] [<ffffffffa04c6794>] v4l2_ioctl+0x164/0x180 [videodev] [ 6.229501] [<ffffffff8122e298>] do_vfs_ioctl+0x2f8/0x500 [ 6.229502] [<ffffffff8122e521>] SyS_ioctl+0x81/0xa0 [ 6.229505] [<ffffffff81774a09>] system_call_fastpath+0x12/0x17 [ 6.229506] ---[ end trace dacd80d4b19277ea ]--- Added the necessary capabilities to stop this warning. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Reported-by:
Laura Abbott <labbott@redhat.com> Signed-off-by:
-
Hans Verkuil authored
commit 534bc3e2 upstream. Fix the VIDIOC_QUERYCAP warning due to the missing device_caps. Don't fill in the version field, the V4L2 core will do that for you. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 82e3b88b upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Signed-off-by:
-
Mauro Carvalho Chehab authored
commit d7b76c91 upstream. If userspace sends an invalid bandwidth, it should either return EINVAL or switch to auto mode. This driver will go past an array and program the hardware on a wrong way if this happens. Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 1fa2337a upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 12f4543f upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Signed-off-by:
-
- 14 Jul, 2015 1 commit
-
-
Sowmini Varadhan authored
[ Upstream commit 0edfad59 ] Since it is possible for vnet_event_napi to end up doing vnet_control_pkt_engine -> ... -> vnet_send_attr -> vnet_port_alloc_tx_ring -> ldc_alloc_exp_dring -> kzalloc() (i.e., in softirq context), kzalloc() should be called with GFP_ATOMIC from ldc_alloc_exp_dring. Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> [ kamal: corrected upstream commit SHA ] Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
- 13 Jul, 2015 17 commits
-
-
Simon Guinot authored
[ Upstream commit b65657fc ] The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't support TCP/IP checksumming with frame sizes larger than 1600 bytes. This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set to a value greater than 1600 bytes. Signed-off-by:
Simon Guinot <simon.guinot@sequanux.org> Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Acked-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Simon Guinot authored
[ Upstream commit ea3b55fe ] This patch updates the Ethernet DT nodes for Armada XP SoCs with the compatible string "marvell,armada-xp-neta". Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by:
-
Simon Guinot authored
[ Upstream commit f522a975 ] The mvneta driver supports the Ethernet IP found in the Armada 370, XP, 380 and 385 SoCs. Since at least one more hardware feature is available for the Armada XP SoCs then a way to identify them is needed. This patch introduces a new compatible string "marvell,armada-xp-neta". Signed-off-by:
-
Tom Lendacky authored
[ Upstream commit 472cfe71 ] When allocating Rx related buffers, alloc_pages is called using an order number that is decreased until successful. A system under stress can experience failures during this allocation process resulting in a warning being issued. This message can be of concern to end users even though the failure is not fatal. Since the failure is not fatal and can occur multiple times, the driver should include the __GFP_NOWARN flag to suppress the warning message from being issued. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Alexander Sverdlin authored
[ Upstream commit 29c4afc4 ] There is NULL pointer dereference possible during statistics update if the route used for OOTB responce is removed at unfortunate time. If the route exists when we receive OOTB packet and we finally jump into sctp_packet_transmit() to send ABORT, but in the meantime route is removed under our feet, we take "no_route" path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...). But sctp_ootb_pkt_new() used to prepare responce packet doesn't call sctp_transport_set_owner() and therefore there is no asoc associated with this packet. Probably temporary asoc just for OOTB responces is overkill, so just introduce a check like in all other places in sctp_packet_transmit(), where "asoc" is dereferenced. To reproduce this, one needs to 0. ensure that sctp module is loaded (otherwise ABORT is not generated) 1. remove default route on the machine 2. while true; do ip route del [interface-specific route] ip route add [interface-specific route] done 3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT responce On x86_64 the crash looks like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp] PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: ... CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.5-1-ARCH #1 Hardware name: ... task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000 RIP: 0010:[<ffffffffa05ec9ac>] [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp] RSP: 0018:ffff880127c037b8 EFLAGS: 00010296 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480 RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700 RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28 R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0 FS: 0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0 Stack: ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400 ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520 0000000000000000 0000000000000001 0000000000000000 0000000000000000 Call Trace: <IRQ> [<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp] [<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp] [<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp] [<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210 [<ffffffff810e0329>] ? update_process_times+0x59/0x60 [<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0 [<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0 [<ffffffff8101f599>] ? read_tsc+0x9/0x10 [<ffffffff8116d4b5>] ? put_page+0x55/0x60 [<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100 [<ffffffff81462b68>] ? skb_free_head+0x58/0x80 [<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic] [<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0 [<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp] [<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp] [<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp] [<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp] [<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp] [<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30 [<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150 [<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210 [<ffffffff814b2e15>] ip_local_deliver+0x35/0x90 [<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370 [<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0 [<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50 [<ffffffff81476c28>] __netif_receive_skb+0x18/0x60 [<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0 [<ffffffff814776c8>] napi_gro_receive+0xe8/0x120 [<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169] [<ffffffff8147896a>] net_rx_action+0x21a/0x360 [<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0 [<ffffffff8107912d>] irq_exit+0xad/0xb0 [<ffffffff8157d158>] do_IRQ+0x58/0xf0 [<ffffffff8157b06d>] common_interrupt+0x6d/0x6d <EOI> [<ffffffff810e1218>] ? hrtimer_start+0x18/0x20 [<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp] [<ffffffff81020c50>] ? mwait_idle+0x60/0xa0 [<ffffffff810216ef>] arch_cpu_idle+0xf/0x20 [<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480 [<ffffffff8156b365>] rest_init+0x85/0x90 [<ffffffff818eb035>] start_kernel+0x48b/0x4ac [<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120 [<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c [<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184 Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9 RIP [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp] RSP <ffff880127c037b8> CR2: 0000000000000020 ---[ end trace 5aec7fd2dc983574 ]--- Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff) drm_kms_helper: panic occurred, switching back to text console ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d53c66a5 ] Michel reported following lockdep splat [ 44.718117] INFO: trying to register non-static key. [ 44.723081] the code is fine but needs lockdep annotation. [ 44.728559] turning off the locking correctness validator. [ 44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0 [ 44.770289] Call Trace: [ 44.772741] [<ffffffff816eb1cd>] dump_stack+0x4c/0x65 [ 44.777879] [<ffffffff8111d921>] ? console_unlock+0x1f1/0x510 [ 44.783708] [<ffffffff811121f5>] __lock_acquire+0x1d05/0x1f10 [ 44.789538] [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90 [ 44.795276] [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0 [ 44.801967] [<ffffffff8111390d>] ? trace_hardirqs_on+0xd/0x10 [ 44.807793] [<ffffffff811330fa>] ? hrtimer_try_to_cancel+0x4a/0x250 [ 44.814142] [<ffffffff81112ba6>] lock_acquire+0xb6/0x290 [ 44.819537] [<ffffffff810d6675>] ? flush_work+0x5/0x280 [ 44.824844] [<ffffffff810d66ad>] flush_work+0x3d/0x280 [ 44.830061] [<ffffffff810d6675>] ? flush_work+0x5/0x280 [ 44.835366] [<ffffffff816f3c43>] ? schedule_hrtimeout_range+0x13/0x20 [ 44.841889] [<ffffffff8112ec9b>] ? usleep_range+0x4b/0x50 [ 44.847365] [<ffffffff8111370a>] ? mark_held_locks+0x6a/0x90 [ 44.853102] [<ffffffff810d8585>] ? __cancel_work_timer+0x105/0x1c0 [ 44.859359] [<ffffffff81113835>] ? trace_hardirqs_on_caller+0x105/0x1d0 [ 44.866045] [<ffffffff810d851f>] __cancel_work_timer+0x9f/0x1c0 [ 44.872048] [<ffffffffa0010982>] ? bnx2x_func_stop+0x42/0x90 [bnx2x] [ 44.878481] [<ffffffff810d8670>] cancel_work_sync+0x10/0x20 [ 44.884134] [<ffffffffa00259e5>] bnx2x_chip_cleanup+0x245/0x730 [bnx2x] [ 44.890829] [<ffffffff8110ce02>] ? up+0x32/0x50 [ 44.895439] [<ffffffff811306b5>] ? del_timer_sync+0x5/0xd0 [ 44.901005] [<ffffffffa005596d>] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x] [ 44.907527] [<ffffffff811f1aef>] ? might_fault+0x5f/0xb0 [ 44.912921] [<ffffffffa005851c>] bnx2x_reload_if_running+0x2c/0x50 [bnx2x] [ 44.919879] [<ffffffffa005a3c5>] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x] [ 44.926664] [<ffffffff815d498b>] dev_ethtool+0x55b/0x1c40 [ 44.932148] [<ffffffff815dfdc7>] ? rtnl_lock+0x17/0x20 [ 44.937364] [<ffffffff815e7f8b>] dev_ioctl+0x17b/0x630 [ 44.942582] [<ffffffff815abf8d>] sock_do_ioctl+0x5d/0x70 [ 44.947972] [<ffffffff815ac013>] sock_ioctl+0x73/0x280 [ 44.953192] [<ffffffff8124c1c8>] do_vfs_ioctl+0x88/0x5b0 [ 44.958587] [<ffffffff8110d0b3>] ? up_read+0x23/0x40 [ 44.963631] [<ffffffff812584cc>] ? __fget_light+0x6c/0xa0 [ 44.969105] [<ffffffff8124c781>] SyS_ioctl+0x91/0xb0 [ 44.974149] [<ffffffff816f4dd7>] system_call_fastpath+0x12/0x6f As bnx2x_init_ptp() is only called if bp->flags contains PTP_SUPPORTED, we also need to guard bnx2x_stop_ptp() with same condition, otherwise ptp_task workqueue is not initialized and kernel barfs on cancel_work_sync() Fixes: eeed018c ("bnx2x: Add timestamping and PTP hardware clock support") Reported-by:
Michel Lespinasse <walken@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Michal Kalderon <Michal.Kalderon@qlogic.com> Cc: Ariel Elior <Ariel.Elior@qlogic.com> Cc: Yuval Mintz <Yuval.Mintz@qlogic.com> Cc: David Decotigny <decot@google.com> Acked-by:
Sony Chacko <sony.chacko@qlogic.com> Signed-off-by:
-
Mugunthan V N authored
[ Upstream commit eb686231 ] When limiting phy link speed using "max-speed" to 100mbps or less on a giga bit phy, phy never completes auto negotiation and phy state machine is held in PHY_AN. Fixing this issue by comparing the giga bit advertise though phydev->supported doesn't have it but phy has BMSR_ESTATEN set. So that auto negotiation is restarted as old and new advertise are different and link comes up fine. Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Ido Shamay authored
[ Upstream commit 79a25852 ] The check_csum() function relied on hwtstamp_rx_filter to know if rxvlan offload is disabled. This is wrong since rxvlan offload can be switched on/off regardless of hwtstamp_rx_filter. Also moved check_csum to query CQE information to identify VLAN packets and removed the check of IP packets, since it has been validated before. Fixes: f8c6455b ('net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE') Signed-off-by:
Ido Shamay <idos@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Ido Shamay authored
[ Upstream commit 488a9b48 ] Indication of a single completed packet, marked by txbbs_skipped being bigger then zero, in not enough in order to wake up a stopped TX queue. The completed packet may contain a single TXBB, while next packet to be sent (after the wake up) may have multiple TXBBs (LSO/TSO packets for example), causing overflow in queue followed by WQE corruption and TX queue timeout. Instead, wake the stopped queue only when there's enough room for the worst case (maximum sized WQE) packet that we should need to handle after the queue is opened again. Also created an helper routine - mlx4_en_is_tx_ring_full, which checks if the current TX ring is full or not. It provides better code readability and removes code duplication. Signed-off-by:
-
Eran Ben Elisha authored
[ Upstream commit 0eb08514 ] TX ring QP wasn't released at mlx4_en_destroy_tx_ring. Instead, the code used the deprecated base_tx_qpn field. Move TX QP release to mlx4_en_destroy_tx_ring and remove the base_tx_qpn field. Fixes: ddae0349 ('net/mlx4: Change QP allocation scheme') Signed-off-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
-
Christoph Paasch authored
[ Upstream commit dfea2aa6 ] tcp_fastopen_reset_cipher really cannot be called from interrupt context. It allocates the tcp_fastopen_context with GFP_KERNEL and calls crypto_alloc_cipher, which allocates all kind of stuff with GFP_KERNEL. Thus, we might sleep when the key-generation is triggered by an incoming TFO cookie-request which would then happen in interrupt- context, as shown by enabling CONFIG_DEBUG_ATOMIC_SLEEP: [ 36.001813] BUG: sleeping function called from invalid context at mm/slub.c:1266 [ 36.003624] in_atomic(): 1, irqs_disabled(): 0, pid: 1016, name: packetdrill [ 36.004859] CPU: 1 PID: 1016 Comm: packetdrill Not tainted 4.1.0-rc7 #14 [ 36.006085] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 [ 36.008250] 00000000000004f2 ffff88007f8838a8 ffffffff8171d53a ffff880075a084a8 [ 36.009630] ffff880075a08000 ffff88007f8838c8 ffffffff810967d3 ffff88007f883928 [ 36.011076] 0000000000000000 ffff88007f8838f8 ffffffff81096892 ffff88007f89be00 [ 36.012494] Call Trace: [ 36.012953] <IRQ> [<ffffffff8171d53a>] dump_stack+0x4f/0x6d [ 36.014085] [<ffffffff810967d3>] ___might_sleep+0x103/0x170 [ 36.015117] [<ffffffff81096892>] __might_sleep+0x52/0x90 [ 36.016117] [<ffffffff8118e887>] kmem_cache_alloc_trace+0x47/0x190 [ 36.017266] [<ffffffff81680d82>] ? tcp_fastopen_reset_cipher+0x42/0x130 [ 36.018485] [<ffffffff81680d82>] tcp_fastopen_reset_cipher+0x42/0x130 [ 36.019679] [<ffffffff81680f01>] tcp_fastopen_init_key_once+0x61/0x70 [ 36.020884] [<ffffffff81680f2c>] __tcp_fastopen_cookie_gen+0x1c/0x60 [ 36.022058] [<ffffffff816814ff>] tcp_try_fastopen+0x58f/0x730 [ 36.023118] [<ffffffff81671788>] tcp_conn_request+0x3e8/0x7b0 [ 36.024185] [<ffffffff810e3872>] ? __module_text_address+0x12/0x60 [ 36.025327] [<ffffffff8167b2e1>] tcp_v4_conn_request+0x51/0x60 [ 36.026410] [<ffffffff816727e0>] tcp_rcv_state_process+0x190/0xda0 [ 36.027556] [<ffffffff81661f97>] ? __inet_lookup_established+0x47/0x170 [ 36.028784] [<ffffffff8167c2ad>] tcp_v4_do_rcv+0x16d/0x3d0 [ 36.029832] [<ffffffff812e6806>] ? security_sock_rcv_skb+0x16/0x20 [ 36.030936] [<ffffffff8167cc8a>] tcp_v4_rcv+0x77a/0x7b0 [ 36.031875] [<ffffffff816af8c3>] ? iptable_filter_hook+0x33/0x70 [ 36.032953] [<ffffffff81657d22>] ip_local_deliver_finish+0x92/0x1f0 [ 36.034065] [<ffffffff81657f1a>] ip_local_deliver+0x9a/0xb0 [ 36.035069] [<ffffffff81657c90>] ? ip_rcv+0x3d0/0x3d0 [ 36.035963] [<ffffffff81657569>] ip_rcv_finish+0x119/0x330 [ 36.036950] [<ffffffff81657ba7>] ip_rcv+0x2e7/0x3d0 [ 36.037847] [<ffffffff81610652>] __netif_receive_skb_core+0x552/0x930 [ 36.038994] [<ffffffff81610a57>] __netif_receive_skb+0x27/0x70 [ 36.040033] [<ffffffff81610b72>] process_backlog+0xd2/0x1f0 [ 36.041025] [<ffffffff81611482>] net_rx_action+0x122/0x310 [ 36.042007] [<ffffffff81076743>] __do_softirq+0x103/0x2f0 [ 36.042978] [<ffffffff81723e3c>] do_softirq_own_stack+0x1c/0x30 This patch moves the call to tcp_fastopen_init_key_once to the places where a listener socket creates its TFO-state, which always happens in user-context (either from the setsockopt, or implicitly during the listen()-call) Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Fixes: 222e83d2 ("tcp: switch tcp_fastopen key generation to net_get_random_once") Signed-off-by:
Christoph Paasch <cpaasch@apple.com> Acked-by:
-
Julian Anastasov authored
[ Upstream commit 2c51a97f ] The lockless lookups can return entry that is unlinked. Sometimes they get reference before last neigh_cleanup_and_release, sometimes they do not need reference. Later, any modification attempts may result in the following problems: 1. entry is not destroyed immediately because neigh_update can start the timer for dead entry, eg. on change to NUD_REACHABLE state. As result, entry lives for some time but is invisible and out of control. 2. __neigh_event_send can run in parallel with neigh_destroy while refcnt=0 but if timer is started and expired refcnt can reach 0 for second time leading to second neigh_destroy and possible crash. Thanks to Eric Dumazet and Ying Xue for their work and analyze on the __neigh_event_send change. Fixes: 767e97e1 ("neigh: RCU conversion of struct neighbour") Fixes: a263b309 ("ipv4: Make neigh lookups directly in output packet path.") Fixes: 6fd6ce20 ("ipv6: Do not depend on rt->n in ip6_finish_output2().") Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Ying Xue <ying.xue@windriver.com> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Acked-by:
-
Willem de Bruijn authored
[ Upstream commit 468479e6 ] PACKET_FANOUT_LB computes f->rr_cur such that it is modulo f->num_members. It returns the old value unconditionally, but f->num_members may have changed since the last store. Ensure that the return value is always < num. When modifying the logic, simplify it further by replacing the loop with an unconditional atomic increment. Fixes: dc99f600 ("packet: Add fanout support.") Suggested-by:
Willem de Bruijn <willemb@google.com> Acked-by:
-
Eric Dumazet authored
[ Upstream commit f98f4514 ] We need to tell compiler it must not read f->num_members multiple times. Otherwise testing if num is not zero is flaky, and we could attempt an invalid divide by 0 in fanout_demux_cpu() Note bug was present in packet_rcv_fanout_hash() and packet_rcv_fanout_lb() but final 3.1 had a simple location after commit 95ec3eb4 ("packet: Add 'cpu' fanout policy.") Fixes: dc99f600 ("packet: Add fanout support.") Signed-off-by:
-
Nikolay Aleksandrov authored
[ Upstream commit 2dab80a8 ] After the ->set() spinlocks were removed br_stp_set_bridge_priority was left running without any protection when used via sysfs. It can race with port add/del and could result in use-after-free cases and corrupted lists. Tested by running port add/del in a loop with stp enabled while setting priority in a loop, crashes are easily reproducible. The spinlocks around sysfs ->set() were removed in commit: 14f98f25 ("bridge: range check STP parameters") There's also a race condition in the netlink priority support that is fixed by this change, but it was introduced recently and the fixes tag covers it, just in case it's needed the commit is: af615762 ("bridge: add ageing_time, stp_state, priority over netlink") Signed-off-by:
Nikolay Aleksandrov <razor@blackwall.org> Fixes: 14f98f25 ("bridge: range check STP parameters") Signed-off-by:
-
Marcelo Ricardo Leitner authored
[ Upstream commit 2d45a02d ] ->auto_asconf_splist is per namespace and mangled by functions like sctp_setsockopt_auto_asconf() which doesn't guarantee any serialization. Also, the call to inet_sk_copy_descendant() was backuping ->auto_asconf_list through the copy but was not honoring ->do_auto_asconf, which could lead to list corruption if it was different between both sockets. This commit thus fixes the list handling by using ->addr_wq_lock spinlock to protect the list. A special handling is done upon socket creation and destruction for that. Error handlig on sctp_init_sock() will never return an error after having initialized asconf, so sctp_destroy_sock() can be called without addrq_wq_lock. The lock now will be take on sctp_close_sock(), before locking the socket, so we don't do it in inverse order compared to sctp_addr_wq_timeout_handler(). Instead of taking the lock on sctp_sock_migrate() for copying and restoring the list values, it's preferred to avoid rewritting it by implementing sctp_copy_descendant(). Issue was found with a test application that kept flipping sysctl default_auto_asconf on and off, but one could trigger it by issuing simultaneous setsockopt() calls on multiple sockets or by creating/destroying sockets fast enough. This is only triggerable locally. Fixes: 9f7d653b ("sctp: Add Auto-ASCONF support (core).") Reported-by:
Ji Jianwen <jiji@redhat.com> Suggested-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
-
Shaohua Li authored
[ Upstream commit fb05e7a8 ] We saw excessive direct memory compaction triggered by skb_page_frag_refill. This causes performance issues and add latency. Commit 5640f768 introduces the order-3 allocation. According to the changelog, the order-3 allocation isn't a must-have but to improve performance. But direct memory compaction has high overhead. The benefit of order-3 allocation can't compensate the overhead of direct memory compaction. This patch makes the order-3 page allocation atomic. If there is no memory pressure and memory isn't fragmented, the alloction will still success, so we don't sacrifice the order-3 benefit here. If the atomic allocation fails, direct memory compaction will not be triggered, skb_page_frag_refill will fallback to order-0 immediately, hence the direct memory compaction overhead is avoided. In the allocation failure case, kswapd is waken up and doing compaction, so chances are allocation could success next time. alloc_skb_with_frags is the same. The mellanox driver does similar thing, if this is accepted, we must fix the driver too. V3: fix the same issue in alloc_skb_with_frags as pointed out by Eric V2: make the changelog clearer Cc: Eric Dumazet <edumazet@google.com> Cc: Chris Mason <clm@fb.com> Cc: Debabrata Banerjee <dbavatar@gmail.com> Signed-off-by:
Shaohua Li <shli@fb.com> Acked-by:
-
- 10 Jul, 2015 1 commit
-
-
Kamal Mostafa authored
Signed-off-by:
-
- 07 Jul, 2015 1 commit
-
-
Brian Foster authored
commit f66bf042 upstream. The xfs_attr3_root_inactive() call from xfs_attr_inactive() assumes that attribute blocks exist to invalidate. It is possible to have an attribute fork without extents, however. Consider the case where the attribute fork is created towards the beginning of xfs_attr_set() but some part of the subsequent attribute set fails. If an inode in such a state hits xfs_attr_inactive(), it eventually calls xfs_dabuf_map() and possibly xfs_bmapi_read(). The former emits a filesystem corruption warning, returns an error that bubbles back up to xfs_attr_inactive(), and leads to destruction of the in-core attribute fork without an on-disk reset. If the inode happens to make it back through xfs_inactive() in this state (e.g., via a concurrent bulkstat that cycles the inode from the reclaim state and releases it), i_afp might not exist when xfs_bmapi_read() is called and causes a NULL dereference panic. A '-p 2' fsstress run to ENOSPC on a relatively small fs (1GB) reproduces these problems. The behavior is a regression caused by: 6dfe5a04 xfs: xfs_attr_inactive leaves inconsistent attr fork state behind ... which removed logic that avoided the attribute extent truncate when no extents exist. Restore this logic to ensure the attribute fork is destroyed and reset correctly if it exists without any allocated extents. Signed-off-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
