1 #2
Merged
1 #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The fixup code to rewind the source pointer in
__asm_copy_from_user_{32,64}bit_rapf_loop() always rewound the source by
a single unit (4 or 8 bytes), however this is insufficient if the fault
didn't occur on the first load in the loop, as the source pointer will
have been incremented but nothing will have been stored until all 4
register [pairs] are loaded.
Read the LSM_STEP field of TXSTATUS (which is already loaded into a
register), a bit like the copy_to_user versions, to determine how many
iterations of MGET[DL] have taken place, all of which need rewinding.
Fixes: 373cd78 ("metag: Memory handling")
Signed-off-by: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
The rapf copy loops in the Meta usercopy code is missing some extable entries for HTP cores with unaligned access checking enabled, where faults occur on the instruction immediately after the faulting access. Add the fixup labels and extable entries for these cases so that corner case user copy failures don't cause kernel crashes. Fixes: 373cd78 ("metag: Memory handling") Signed-off-by: James Hogan <[email protected]> Cc: [email protected] Cc: [email protected]
…ux/kernel/git/kvmarm/kvmarm From: Christoffer Dall <[email protected]> KVM/ARM Fixes for v4.11-rc6 Fixes include: - Fix a problem with GICv3 userspace save/restore - Clarify GICv2 userspace save/restore ABI - Be more careful in clearing GIC LRs - Add missing synchronization primitive to our MMU handling code
…kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - hand-off primary maintainership of Kbuild - fix build warnings - fix build error when GCOV is enabled with old compiler - fix HAVE_ASM_GOTO check when GCC plugin is enabled * tag 'kbuild-fixes-v4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: gconfig: remove misleading parentheses around a condition jump label: fix passing kbuild_cflags when checking for asm goto support Kbuild: use cc-disable-warning consistently for maybe-uninitialized kbuild: external module build warnings when KBUILD_OUTPUT set and W=1 MAINTAINERS: add Masahiro Yamada as a Kbuild maintainer
…el/git/lee/mfd Pull MFD bug fix from Lee Jones: "Increase buffer size om cros-ec to allow for SPI messages" * tag 'mfd-fixes-4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: mfd: cros-ec: Fix host command buffer size
The lost retransmit SNMP stat is under-counting retransmission that uses segment offloading. This patch fixes that so all retransmission related SNMP counters are consistent. Fixes: 10d3be5 ("tcp-tso: do not split TSO packets at retransmit time") Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Currently the reordering SNMP counters only increase if a connection sees a higher degree then it has previously seen. It ignores if the reordering degree is not greater than the default system threshold. This significantly under-counts the number of reordering events and falsely convey that reordering is rare on the network. This patch properly and faithfully records the number of reordering events detected by the TCP stack, just like the comment says "this exciting event is worth to be remembered". Note that even so TCP still under-estimate the actual reordering events because TCP requires TS options or certain packet sequences to detect reordering (i.e. ACKing never-retransmitted sequence in recovery or disordered state). Signed-off-by: Yuchung Cheng <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Neal Cardwell <[email protected]> Signed-off-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: David S. Miller <[email protected]>
We should unregister the net_device first, before we give back our reference on xdp_prog. Otherwise xdp_prog may be freed before .ndo_stop() disabled the datapath. Found by code inspection. Fixes: ecd63a0 ("nfp: add XDP support in the driver") Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Fix wrong initial csb read pointer value. This fixes the random engine timeout issue in guest when guest boots up. Fixes: 8453d67 ("drm/i915/gvt: vGPU execlist virtualization") Cc: [email protected] # v4.10+ Signed-off-by: Min He <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]>
Pull networking fixes from David Miller:
1) Reject invalid updates to netfilter expectation policies, from Pablo
Neira Ayuso.
2) Fix memory leak in nfnl_cthelper, from Jeffy Chen.
3) Don't do stupid things if we get a neigh_probe() on a neigh entry
whose ops lack a solicit method. From Eric Dumazet.
4) Don't transmit packets in r8152 driver when the carrier is off, from
Hayes Wang.
5) Fix ipv6 packet type detection in aquantia driver, from Pavel
Belous.
6) Don't write uninitialized data into hw registers in bna driver, from
Arnd Bergmann.
7) Fix locking in ping_unhash(), from Eric Dumazet.
8) Make BPF verifier range checks able to understand certain sequences
emitted by LLVM, from Alexei Starovoitov.
9) Fix use after free in ipconfig, from Mark Rutland.
10) Fix refcount leak on force commit in openvswitch, from Jarno
Rajahalme.
11) Fix various overflow checks in AF_PACKET, from Andrey Konovalov.
12) Fix endianness bug in be2net driver, from Suresh Reddy.
13) Don't forget to wake TX queues when processing a timeout, from
Grygorii Strashko.
14) ARP header on-stack storage is wrong in flow dissector, from Simon
Horman.
15) Lost retransmit and reordering SNMP stats in TCP can be
underreported. From Yuchung Cheng.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (82 commits)
nfp: fix potential use after free on xdp prog
tcp: fix reordering SNMP under-counting
tcp: fix lost retransmit SNMP under-counting
sctp: get sock from transport in sctp_transport_update_pmtu
net: ethernet: ti: cpsw: fix race condition during open()
l2tp: fix PPP pseudo-wire auto-loading
bnx2x: fix spelling mistake in macros HW_INTERRUT_ASSERT_SET_*
l2tp: take reference on sessions being dumped
tcp: minimize false-positives on TCP/GRO check
sctp: check for dst and pathmtu update in sctp_packet_config
flow dissector: correct size of storage for ARP
net: ethernet: ti: cpsw: wake tx queues on ndo_tx_timeout
l2tp: take a reference on sessions used in genetlink handlers
l2tp: hold session while sending creation notifications
l2tp: fix duplicate session creation
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()
l2tp: fix race in l2tp_recv_common()
sctp: use right in and out stream cnt
bpf: add various verifier test cases for self-tests
bpf, verifier: fix rejection of unaligned access checks for map_value_adj
...
Signed-off-by: Ilia Mirkin <[email protected]> Fixes: 590801c ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: [email protected] # v4.3+ Signed-off-by: Ben Skeggs <[email protected]>
The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP and PCI varieties, rather than a core PCIE chip with a bridge for AGP/PCI as necessary. As a result, it appears that the MMU is also non-functional. For AGP cards, the vast majority of the NV4A lineup, this worked out since we force AGP cards to use the nv04 mmu. However for PCI variants, this did not work. Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for the suggestion. This should be a no-op for NV4A AGP boards, as they were using it already. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388 Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected] Signed-off-by: Ben Skeggs <[email protected]>
Cc: [email protected] [4.10+] Signed-off-by: Ben Skeggs <[email protected]>
…e state When the atomic support was added to nouveau, the DRM core did not do this. However, later in the same merge window, a commit (drm/fence: add in-fences support) was merged that added it, leading to use-after-frees of the fence object. Cc: [email protected] [4.10+] Signed-off-by: Ben Skeggs <[email protected]>
Forked from GP106 implementation. Split out from commit enabling secboot/gr support so that it can be added to earlier kernels. Cc: [email protected] [4.10+] Signed-off-by: Ben Skeggs <[email protected]>
kzalloc() won't actually fail because sizeof(*resize) is small, but static checkers complain. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: David Gibson <[email protected]> Signed-off-by: Paul Mackerras <[email protected]>
The USB PHY in A64 has a "pmu0" region, which controls the EHCI/OHCI controller pair that can be connected to the PHY0. Add the MMIO region for PHY node. Signed-off-by: Icenowy Zheng <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
…rnel/git/paulus/powerpc From: Paul Mackerras <[email protected]> A check for a NULL return from kzalloc in recently-added code.
As a preparation for special treatment for Broxton we split Tangier configuration. Fixes: b89b4b7 ("pwm: lpss: pci: Enable PWM module on Intel Edison") Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
At least on cherrytrail, the update bit will never go low when the enabled bit is not set. This causes the backlight on my cube iwork8 air tablet to never turn on again after being turned off because in the pwm_lpss_apply enable path pwm_lpss_update will fail causing an error exit and the enable-bit to never get set. Any following pwm_lpss_apply calls will fail the pwm_lpss_is_updating check. Since the docs say that the update bit should be set before the enable-bit, split pwm_lpss_update into setting the update-bit and pwm_lpss_wait_for_update, and move the pwm_lpss_wait_for_update call in the enable path to after setting the enable-bit. Fixes: 10d56a4 ("pwm: lpss: Avoid reconfiguring while UPDATE bit...") Cc: Ilkka Koskinen <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Tested-by: Hans de Goede <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
This device has a different vendor id but responds to initialization. Signed-off-by: Xiaolei Yu <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
… state If the PWM was not enabled at U-Boot loader, PWM could not work for clock always disabled at PWM driver. The PWM clock is enabled at beginning of pwm_apply(), but disabled at end of pwm_apply(). If the PWM was enabled at U-Boot loader, PWM clock is always enabled unless closed by ATF. The pwm-backlight might turn off the power at early suspend, should disable PWM clock for saving power consume. It is important to provide opportunity to enable/disable clock at PWM driver, the PWM consumer should ensure correct order to call PWM enable and disable, and PWM driver ensure state of PWM clock synchronized with PWM enabled state. Fixes: 2bf1c98 ("pwm: rockchip: Add support for atomic update") Cc: [email protected] Signed-off-by: David Wu <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
…te() This commit moves sparc64's prototype of pmd_write() outside of the CONFIG_TRANSPARENT_HUGEPAGE ifdef. In 2013, commit a7b9403 ("sparc64: Encode huge PMDs using PTE encoding.") exposed a path where pmd_write() could be called without CONFIG_TRANSPARENT_HUGEPAGE defined. This can result in the panic below. The diff is awkward to read, but the changes are straightforward. pmd_write() was moved outside of #ifdef CONFIG_TRANSPARENT_HUGEPAGE. Also, __HAVE_ARCH_PMD_WRITE was defined. kernel BUG at include/asm-generic/pgtable.h:576! \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ oracle_8114_cdb(8114): Kernel bad sw trap 5 [#1] CPU: 120 PID: 8114 Comm: oracle_8114_cdb Not tainted 4.1.12-61.7.1.el6uek.rc1.sparc64 #1 task: fff8400700a24d60 ti: fff8400700bc4000 task.ti: fff8400700bc4000 TSTATE: 0000004411e01607 TPC: 00000000004609f8 TNPC: 00000000004609fc Y: 00000005 Not tainted TPC: <gup_huge_pmd+0x198/0x1e0> g0: 000000000001c000 g1: 0000000000ef3954 g2: 0000000000000000 g3: 0000000000000001 g4: fff8400700a24d60 g5: fff8001fa5c10000 g6: fff8400700bc4000 g7: 0000000000000720 o0: 0000000000bc5058 o1: 0000000000000240 o2: 0000000000006000 o3: 0000000000001c00 o4: 0000000000000000 o5: 0000048000080000 sp: fff8400700bc6ab1 ret_pc: 00000000004609f0 RPC: <gup_huge_pmd+0x190/0x1e0> l0: fff8400700bc74fc l1: 0000000000020000 l2: 0000000000002000 l3: 0000000000000000 l4: fff8001f93250950 l5: 000000000113f800 l6: 0000000000000004 l7: 0000000000000000 i0: fff8400700ca46a0 i1: bd0000085e800453 i2: 000000026a0c4000 i3: 000000026a0c6000 i4: 0000000000000001 i5: fff800070c958de8 i6: fff8400700bc6b61 i7: 0000000000460dd0 I7: <gup_pud_range+0x170/0x1a0> Call Trace: [0000000000460dd0] gup_pud_range+0x170/0x1a0 [0000000000460e84] get_user_pages_fast+0x84/0x120 [00000000006f5a18] iov_iter_get_pages+0x98/0x240 [00000000005fa744] do_direct_IO+0xf64/0x1e00 [00000000005fbbc0] __blockdev_direct_IO+0x360/0x15a0 [00000000101f74fc] ext4_ind_direct_IO+0xdc/0x400 [ext4] [00000000101af690] ext4_ext_direct_IO+0x1d0/0x2c0 [ext4] [00000000101af86c] ext4_direct_IO+0xec/0x220 [ext4] [0000000000553bd4] generic_file_read_iter+0x114/0x140 [00000000005bdc2c] __vfs_read+0xac/0x100 [00000000005bf254] vfs_read+0x54/0x100 [00000000005bf368] SyS_pread64+0x68/0x80 Signed-off-by: Tom Hromatka <[email protected]> Signed-off-by: David S. Miller <[email protected]>
The memory corruption was happening due to incorrect TLB/TSB flushing of hugepages. Reported-by: David S. Miller <[email protected]> Signed-off-by: Nitin Gupta <[email protected]> Signed-off-by: David S. Miller <[email protected]>
sparc32:allmodconfig fails to build with the following error. ERROR: "vac_cache_size" [drivers/infiniband/sw/rxe/rdma_rxe.ko] undefined! Fixes: cb88645 ("infiniband: Fix alignment of mmap cookies ...") Cc: Jason Gunthorpe <[email protected]> Cc: Doug Ledford <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: David S. Miller <[email protected]>
It's unused for ages, used to be required for ksyms.c back in the v1.1 times. Signed-off-by: Mathias Krause <[email protected]> Acked-by: David S. Miller <[email protected]> Signed-off-by: David S. Miller <[email protected]>
inet_rtm_getroute synthesizes a skeletal ICMP skb, which is passed to ip_route_input when iif is given. If a multipath route is present for the designated destination, ip_multipath_icmp_hash ends up being called, which uses the source/destination addresses within the skb to calculate a hash. However, those are not set in the synthetic skb, causing it to return an arbitrary and incorrect result. Instead, use UDP, which gets no such special treatment. Signed-off-by: Florian Larysch <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Dmitry reported a crash when injecting faults in attach_one_default_qdisc() and dev->qdisc is still a noop_disc, the check before qdisc_hash_add() fails to catch it because it tests NULL. We should test against noop_qdisc since it is the default qdisc at this point. Fixes: 59cc1f6 ("net: sched: convert qdisc linked list to hashtable") Reported-by: Dmitry Vyukov <[email protected]> Cc: Jiri Kosina <[email protected]> Signed-off-by: Cong Wang <[email protected]> Acked-by: Jiri Kosina <[email protected]> Signed-off-by: David S. Miller <[email protected]>
…/git/dtor/input Pull input fixes from Dmitry Torokhov: "Just a small update to xpad driver to recognize yet another gamepad, and another change making sure userio.h is exported" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: xpad - add support for Razer Wildcat gamepad uapi: add missing install of userio.h
The patch 554bfec ("parisc: Fix access fault handling in pa_memcpy()") reimplements the pa_memcpy function. Unfortunatelly, it makes the kernel unbootable. The crash happens in the function ide_complete_cmd where memcpy is called with the same source and destination address. This patch fixes a few bugs in pa_memcpy: * When jumping to .Lcopy_loop_16 for the first time, don't skip the instruction "ldi 31,t0" (this bug made the kernel unbootable) * Use the COND macro when comparing length, so that the comparison is 64-bit (a theoretical issue, in case the length is greater than 0xffffffff) * Don't use the COND macro after the "extru" instruction (the PA-RISC specification says that the upper 32-bits of extru result are undefined, although they are set to zero in practice) * Fix exception addresses in .Lcopy16_fault and .Lcopy8_fault * Rename .Lcopy_loop_4 to .Lcopy_loop_8 (so that it is consistent with .Lcopy8_fault) Cc: <[email protected]> # v4.9+ Fixes: 554bfec ("parisc: Fix access fault handling in pa_memcpy()") Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Helge Deller <[email protected]>
Normal pathname lookup doesn't allow empty pathnames, but using AT_EMPTY_PATH (with name_to_handle_at() or fstatat(), for example) you can trigger an empty pathname lookup. And not only is the RCU lookup in that case entirely unnecessary (because we'll obviously immediately finalize the end result), it is actively wrong. Why? An empth path is a special case that will return the original 'dirfd' dentry - and that dentry may not actually be RCU-free'd, resulting in a potential use-after-free if we were to initialize the path lazily under the RCU read lock and depend on complete_walk() finalizing the dentry. Found by syzkaller and KASAN. Reported-by: Dmitry Vyukov <[email protected]> Reported-by: Vegard Nossum <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Otherwise lockdep says: [ 1337.483798] ================================================ [ 1337.483999] [ BUG: lock held when returning to user space! ] [ 1337.484252] 4.11.0-rc6 #19 Not tainted [ 1337.484423] ------------------------------------------------ [ 1337.484626] mount/14766 is leaving the kernel with locks still held! [ 1337.484841] 1 lock held by mount/14766: [ 1337.485017] #0: (&type->s_umount_key#33/1){+.+.+.}, at: [<ffffffff8124171f>] sget_userns+0x2af/0x520 Caught by xfstests generic/413 which tried to mount with the unsupported mount option dax. Then xfstests generic/422 ran sync which deadlocks. Signed-off-by: Martin Brandenburg <[email protected]> Acked-by: Mike Marshall <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
…rnel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "Mikulas Patocka fixed a few bugs in our new pa_memcpy() assembler function, e.g. one bug made the kernel unbootable if source and destination address are the same" * 'parisc-4.11-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: fix bugs in pa_memcpy
…it/jejb/scsi Pull SCSI fixes from James Bottomley: "This is seven small fixes which are all for user visible issues that fortunately only occur in rare circumstances. The most serious is the sr one in which QEMU can cause us to read beyond the end of a buffer (I don't think it's exploitable, but just in case). The next is the sd capacity fix which means all non 512 byte sector drives greater than 2TB fail to be correctly sized. The rest are either in new drivers (qedf) or on error legs" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ipr: do not set DID_PASSTHROUGH on CHECK CONDITION scsi: aacraid: fix PCI error recovery path scsi: sd: Fix capacity calculation with 32-bit sector_t scsi: qla2xxx: Add fix to read correct register value for ISP82xx. scsi: qedf: Fix crash due to unsolicited FIP VLAN response. scsi: sr: Sanity check returned mode data scsi: sd: Consider max_xfer_blocks if opt_xfer_blocks is unusable
…kernel/git/nvdimm/nvdimm
Pull nvdimm fixes from Dan Williams:
"A small crop of lockdep, sleeping while atomic, and other fixes /
band-aids in advance of the full-blown reworks targeting the next
merge window. The largest change here is "libnvdimm: fix blk free
space accounting" which deletes a pile of buggy code that better
testing would have caught before merging. The next change that is
borderline too big for a late rc is switching the device-dax locking
from rcu to srcu, I couldn't think of a smaller way to make that fix.
The __copy_user_nocache fix will have a full replacement in 4.12 to
move those pmem special case considerations into the pmem driver. The
"libnvdimm: band aid btt vs clear poison locking" commit admits that
our error clearing support for btt went in broken, so we just disable
it in 4.11 and -stable. A replacement / full fix is in the pipeline
for 4.12
Some of these would have been caught earlier had DEBUG_ATOMIC_SLEEP
been enabled on my development station. I wonder if we should have:
config DEBUG_ATOMIC_SLEEP
default PROVE_LOCKING
...since I mistakenly thought I got both with PROVE_LOCKING=y.
These have received a build success notification from the 0day robot,
and some have appeared in a -next release with no reported issues"
* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions
device-dax: switch to srcu, fix rcu_read_lock() vs pte allocation
libnvdimm: band aid btt vs clear poison locking
libnvdimm: fix reconfig_mutex, mmap_sem, and jbd2_handle lockdep splat
libnvdimm: fix blk free space accounting
acpi, nfit, libnvdimm: fix interleave set cookie calculation (64-bit comparison)
…locks" This reverts commit bfb0b80. Andrei reports CRIU test hangs with the patch applied. The bug fixed by the patch isn't too likely to trigger in actual uses. Revert the patch for now. Signed-off-by: Tejun Heo <[email protected]> Reported-by: Andrei Vagin <[email protected]> Link: http://lkml.kernel.org/r/[email protected]
…ernel/git/rostedt/linux-trace
Pull ftrace fix from Steven Rostedt:
"While rewriting the function probe code, I stumbled over a long
standing bug. This bug has been there sinc function tracing was added
way back when. But my new development depends on this bug being fixed,
and it should be fixed regardless as it causes ftrace to disable
itself when triggered, and a reboot is required to enable it again.
The bug is that the function probe does not disable itself properly if
there's another probe of its type still enabled. For example:
# cd /sys/kernel/debug/tracing
# echo schedule:traceoff > set_ftrace_filter
# echo do_IRQ:traceoff > set_ftrace_filter
# echo \!do_IRQ:traceoff > /debug/tracing/set_ftrace_filter
# echo do_IRQ:traceoff > set_ftrace_filter
The above registers two traceoff probes (one for schedule and one for
do_IRQ, and then removes do_IRQ.
But since there still exists one for schedule, it is not done
properly. When adding do_IRQ back, the breakage in the accounting is
noticed by the ftrace self tests, and it causes a warning and disables
ftrace"
* tag 'trace-v4.11-rc5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Fix removing of second function probe
…/git/gregkh/tty Pull tty fix from Greg KH: "Here is a single tty core revert for a patch that was reported to cause problems. The original issue is one that we have lived with for decades, so trying to scramble to fix the fix in time for 4.11-final does not make sense due to the fragility of the tty ldisc layer. Just reverting it makes sense for now" * tag 'tty-4.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "tty: don't panic on OOM in tty_set_ldisc()"
…ernel/git/tj/cgroup Pull cgroup fix from Tejun Heo: "Unfortunately, the commit to fix the cgroup mount race in the previous pull request can lead to hangs. The original bug has been around for a while and isn't too likely to be triggered in usual use cases. Revert the commit for now" * 'for-4.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: Revert "cgroup: avoid attaching a cgroup root to two different superblocks"
…ub/scm/linux/kernel/git/tmlind/linux-omap into fixes Regression fix for omap interconnect code for deferred probe. Without this fix we can get PM related warnings for devices that use deferred probe. If necessary, this fix can wait for the v4.12 merge window no problem. * tag 'omap-for-v4.11/fixes-rc6-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend ARM: dts: ti: fix PCI bus dtc warnings ARM: dts: am335x-baltos: disable EEE for Atheros 8035 PHY ARM: dts: OMAP3: Fix MFG ID EEPROM Signed-off-by: Olof Johansson <[email protected]>
Pull block fixes from Jens Axboe: "Four small fixes. Three of them fix the same error in NVMe, in loop, fc, and rdma respectively. The last fix from Ming fixes a regression in this series, where our bvec gap logic was wrong and causes an oops on NVMe for certain conditions" * 'for-linus' of git://git.kernel.dk/linux-block: block: fix bio_will_gap() for first bvec with offset nvme-fc: Fix sqsize wrong assignment based on ctrl MQES capability nvme-rdma: Fix sqsize wrong assignment based on ctrl MQES capability nvme-loop: Fix sqsize wrong assignment based on ctrl MQES capability
…/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Again, a batch that's been sitting a couple of weeks, mostly because I anticipated a bit more material but it didn't show up -- which is good. These are all your garden variety fixes for ARM platforms. The most visible issue fixed here is probably the SMP reset issue on OMAP, the rest are minor stuff" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: arm64: allwinner: a64: add pmu0 regs for USB PHY ARM: OMAP2+: omap_device: Sync omap_device and pm_runtime after probe defer reset: add exported __reset_control_get, return NULL if optional ARM: orion5x: only call into phylib when available ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend ARM: dts: ti: fix PCI bus dtc warnings ARM: dts: am335x-baltos: disable EEE for Atheros 8035 PHY ARM: dts: OMAP3: Fix MFG ID EEPROM ARM: sun8i: a33: add operating-points-v2 property to all nodes ARM: sun8i: a33: remove highest OPP to fix CPU crashes
wzyy2
pushed a commit
that referenced
this pull request
May 2, 2017
We WRONGLY supposed both REGULATOR_EVENT_PRE_VOLTAGE_CHANGE and REGULATOR_EVENT_VOLTAGE_CHANGE were used in pairs. If volts are not changed in volts setting process, REGULATOR_EVENT_PRE_VOLTAGE_CHANGE is NOT sent,but REGULATOR_EVENT_VOLTAGE_CHANGE is sent. So we check the lock status before we release the lock. [ 3.535657] ===================================== [ 3.535703] [ BUG: bad unlock balance detected! ] [ 3.535757] 4.4.55 #2 Not tainted [ 3.535800] ------------------------------------- [ 3.535847] cfinteractive/65 is trying to release lock (thermal_reg_mutex) at: [ 3.535969] [<ffffff8008c23ca4>] mutex_unlock+0xc/0x14 [ 3.536015] but there are no more locks to release! [ 3.536058] wifi_platform_bus_enumerate device present 1 [ 3.536076] [ 3.536076] other info that might help us debug this: [ 3.536088] ======== Card detection to detect SDIO card! ======== [ 3.536104] 4 locks held by cfinteractive/65: [ 3.536115] mmc2:mmc host rescan start! [ 3.536123] #0: (&policy->rwsem){+.+.+.}, at: [<ffffff8008829734>] cpufreq_interactive_speedchange_task+0x138/0x48c [ 3.536323] #1: (&pcpu->enable_sem){++++..}, at: [<ffffff8008829740>] cpufreq_interactive_speedchange_task+0x144/0x48c [ 3.536510] #2: (&rdev->mutex){+.+.+.}, at: [<ffffff8008472948>] regulator_set_voltage+0x34/0x90 [ 3.536700] #3: (&(&rdev->notifier)->rwsem){.+.+..}, at: [<ffffff80080c0558>] __blocking_notifier_call_chain+0x30/0x64 [ 3.536892] [ 3.536892] stack backtrace: [ 3.536962] CPU: 2 PID: 65 Comm: cfinteractive Not tainted 4.4.55 #2 [ 3.537011] Hardware name: Rockchip rk3368 p9 board (DT) [ 3.537056] Call trace: [ 3.537118] [<ffffff8008088a4c>] dump_backtrace+0x0/0x1c4 [ 3.537182] [<ffffff8008088c24>] show_stack+0x14/0x1c [ 3.537249] [<ffffff80083ada90>] dump_stack+0xa8/0xe0 [ 3.537317] [<ffffff8008186c04>] print_unlock_imbalance_bug.part.25+0xbc/0xcc [ 3.537386] [<ffffff80080f8210>] lock_release+0x218/0x464 [ 3.537448] [<ffffff8008c23c1c>] __mutex_unlock_slowpath+0xf4/0x170 [ 3.537507] [<ffffff8008c23ca4>] mutex_unlock+0xc/0x14 [ 3.537573] [<ffffff800880510c>] rk3368_thermal_notify+0x5c/0x68 [ 3.537637] [<ffffff80080c0248>] notifier_call_chain+0x54/0x88 [ 3.537702] [<ffffff80080c0570>] __blocking_notifier_call_chain+0x48/0x64 [ 3.537768] [<ffffff80080c05a0>] blocking_notifier_call_chain+0x14/0x1c [ 3.537837] [<ffffff80084701d0>] _regulator_do_set_voltage+0x3dc/0x61c [ 3.537904] [<ffffff80084705b8>] regulator_set_voltage_unlocked+0x1a8/0x208 [ 3.537971] [<ffffff8008472970>] regulator_set_voltage+0x5c/0x90 [ 3.538039] [<ffffff800850708c>] _set_opp_voltage+0x44/0xa4 [ 3.538104] [<ffffff8008508400>] dev_pm_opp_set_rate+0x47c/0x540 [ 3.538168] [<ffffff800882be30>] set_target+0x30/0x38 [ 3.538234] [<ffffff80088222e0>] __cpufreq_driver_target+0x1d8/0x298 [ 3.538298] [<ffffff800882986c>] cpufreq_interactive_speedchange_task+0x270/0x48c [ 3.538360] [<ffffff80080bee1c>] kthread+0xf4/0xfc [ 3.538419] [<ffffff80080826d0>] ret_from_fork+0x10/0x40 Change-Id: I8a89bde9ff6ec83255b8a4c017e6ff792535ebb8 Signed-off-by: Rocky Hao <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Jun 19, 2017
[ Upstream commit d5afb6f ] The code where sk_clone() came from created a new socket and locked it, but then, on the error path didn't unlock it. This problem stayed there for a long while, till b0691c8 ("net: Unlock sock before calling sk_free()") fixed it, but unfortunately the callers of sk_clone() (now sk_clone_locked()) were not audited and the one in dccp_create_openreq_child() remained. Now in the age of the syskaller fuzzer, this was finally uncovered, as reported by Dmitry: ---- 8< ---- I've got the following report while running syzkaller fuzzer on 86292b3 ("Merge branch 'akpm' (patches from Andrew)") [ BUG: held lock freed! ] 4.10.0+ torvalds#234 Not tainted ------------------------- syz-executor6/6898 is freeing memory ffff88006286cac0-ffff88006286d3b7, with a lock still held there! (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock include/linux/spinlock.h:299 [inline] (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504 5 locks held by syz-executor6/6898: #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] lock_sock include/net/sock.h:1460 [inline] #0: (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff839a34b4>] inet_stream_connect+0x44/0xa0 net/ipv4/af_inet.c:681 #1: (rcu_read_lock){......}, at: [<ffffffff83bc1c2a>] inet6_csk_xmit+0x12a/0x5d0 net/ipv6/inet6_connection_sock.c:126 #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_unlink include/linux/skbuff.h:1767 [inline] #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] __skb_dequeue include/linux/skbuff.h:1783 [inline] #2: (rcu_read_lock){......}, at: [<ffffffff8369b424>] process_backlog+0x264/0x730 net/core/dev.c:4835 #3: (rcu_read_lock){......}, at: [<ffffffff83aeb5c0>] ip6_input_finish+0x0/0x1700 net/ipv6/ip6_input.c:59 #4: (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] spin_lock include/linux/spinlock.h:299 [inline] #4: (slock-AF_INET6){+.-...}, at: [<ffffffff8362c2c9>] sk_clone_lock+0x3d9/0x12c0 net/core/sock.c:1504 Fix it just like was done by b0691c8 ("net: Unlock sock before calling sk_free()"). Reported-by: Dmitry Vyukov <[email protected]> Cc: Cong Wang <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Gerrit Renker <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Jun 19, 2017
commit ab2a4bf upstream. The USB core contains a bug that can show up when a USB-3 host controller is removed. If the primary (USB-2) hcd structure is released before the shared (USB-3) hcd, the core will try to do a double-free of the common bandwidth_mutex. The problem was described in graphical form by Chung-Geol Kim, who first reported it: ================================================= At *remove USB(3.0) Storage sequence <1> --> <5> ((Problem Case)) ================================================= VOLD ------------------------------------|------------ (uevent) ________|_________ |<1> | |dwc3_otg_sm_work | |usb_put_hcd | |peer_hcd(kref=2)| |__________________| ________|_________ |<2> | |New USB BUS #2 | | | |peer_hcd(kref=1) | | | --(Link)-bandXX_mutex| | |__________________| | ___________________ | |<3> | | |dwc3_otg_sm_work | | |usb_put_hcd | | |primary_hcd(kref=1)| | |___________________| | _________|_________ | |<4> | | |New USB BUS #1 | | |hcd_release | | |primary_hcd(kref=0)| | | | | |bandXX_mutex(free) |<- |___________________| (( VOLD )) ______|___________ |<5> | | SCSI | |usb_put_hcd | |peer_hcd(kref=0) | |*hcd_release | |bandXX_mutex(free*)|<- double free |__________________| ================================================= This happens because hcd_release() frees the bandwidth_mutex whenever it sees a primary hcd being released (which is not a very good idea in any case), but in the course of releasing the primary hcd, it changes the pointers in the shared hcd in such a way that the shared hcd will appear to be primary when it gets released. This patch fixes the problem by changing hcd_release() so that it deallocates the bandwidth_mutex only when the _last_ hcd structure referencing it is released. The patch also removes an unnecessary test, so that when an hcd is released, both the shared_hcd and primary_hcd pointers in the hcd's peer will be cleared. Signed-off-by: Alan Stern <[email protected]> Reported-by: Chung-Geol Kim <[email protected]> Tested-by: Chung-Geol Kim <[email protected]> Cc: Sumit Semwal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Jun 19, 2017
…e_pmd() commit c9d398f upstream. I found the race condition which triggers the following bug when move_pages() and soft offline are called on a single hugetlb page concurrently. Soft offlining page 0x119400 at 0x700000000000 BUG: unable to handle kernel paging request at ffffea0011943820 IP: follow_huge_pmd+0x143/0x190 PGD 7ffd2067 PUD 7ffd1067 PMD 0 [61163.582052] Oops: 0000 [#1] SMP Modules linked in: binfmt_misc ppdev virtio_balloon parport_pc pcspkr i2c_piix4 parport i2c_core acpi_cpufreq ip_tables xfs libcrc32c ata_generic pata_acpi virtio_blk 8139too crc32c_intel ata_piix serio_raw libata virtio_pci 8139cp virtio_ring virtio mii floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: cap_check] CPU: 0 PID: 22573 Comm: iterate_numa_mo Tainted: P OE 4.11.0-rc2-mm1+ #2 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:follow_huge_pmd+0x143/0x190 RSP: 0018:ffffc90004bdbcd0 EFLAGS: 00010202 RAX: 0000000465003e80 RBX: ffffea0004e34d30 RCX: 00003ffffffff000 RDX: 0000000011943800 RSI: 0000000000080001 RDI: 0000000465003e80 RBP: ffffc90004bdbd18 R08: 0000000000000000 R09: ffff880138d34000 R10: ffffea0004650000 R11: 0000000000c363b0 R12: ffffea0011943800 R13: ffff8801b8d34000 R14: ffffea0000000000 R15: 000077ff80000000 FS: 00007fc977710740(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffea0011943820 CR3: 000000007a746000 CR4: 00000000001406f0 Call Trace: follow_page_mask+0x270/0x550 SYSC_move_pages+0x4ea/0x8f0 SyS_move_pages+0xe/0x10 do_syscall_64+0x67/0x180 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7fc976e03949 RSP: 002b:00007ffe72221d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000117 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc976e03949 RDX: 0000000000c22390 RSI: 0000000000001400 RDI: 0000000000005827 RBP: 00007ffe72221e00 R08: 0000000000c2c3a0 R09: 0000000000000004 R10: 0000000000c363b0 R11: 0000000000000246 R12: 0000000000400650 R13: 00007ffe72221ee0 R14: 0000000000000000 R15: 0000000000000000 Code: 81 e4 ff ff 1f 00 48 21 c2 49 c1 ec 0c 48 c1 ea 0c 4c 01 e2 49 bc 00 00 00 00 00 ea ff ff 48 c1 e2 06 49 01 d4 f6 45 bc 04 74 90 <49> 8b 7c 24 20 40 f6 c7 01 75 2b 4c 89 e7 8b 47 1c 85 c0 7e 2a RIP: follow_huge_pmd+0x143/0x190 RSP: ffffc90004bdbcd0 CR2: ffffea0011943820 ---[ end trace e4f81353a2d23232 ]--- Kernel panic - not syncing: Fatal exception Kernel Offset: disabled This bug is triggered when pmd_present() returns true for non-present hugetlb, so fixing the present check in follow_huge_pmd() prevents it. Using pmd_present() to determine present/non-present for hugetlb is not correct, because pmd_present() checks multiple bits (not only _PAGE_PRESENT) for historical reason and it can misjudge hugetlb state. Fixes: e66f17f ("mm/hugetlb: take page table lock in follow_huge_pmd()") Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Naoya Horiguchi <[email protected]> Acked-by: Hillf Danton <[email protected]> Cc: Hugh Dickins <[email protected]> Cc: Michal Hocko <[email protected]> Cc: "Kirill A. Shutemov" <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Christian Borntraeger <[email protected]> Cc: Gerald Schaefer <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Jun 19, 2017
commit 0beb201 upstream. Holding the reconfig_mutex over a potential userspace fault sets up a lockdep dependency chain between filesystem-DAX and the libnvdimm ioctl path. Move the user access outside of the lock. [ INFO: possible circular locking dependency detected ] 4.11.0-rc3+ torvalds#13 Tainted: G W O ------------------------------------------------------- fallocate/16656 is trying to acquire lock: (&nvdimm_bus->reconfig_mutex){+.+.+.}, at: [<ffffffffa00080b1>] nvdimm_bus_lock+0x21/0x30 [libnvdimm] but task is already holding lock: (jbd2_handle){++++..}, at: [<ffffffff813b4944>] start_this_handle+0x104/0x460 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (jbd2_handle){++++..}: lock_acquire+0xbd/0x200 start_this_handle+0x16a/0x460 jbd2__journal_start+0xe9/0x2d0 __ext4_journal_start_sb+0x89/0x1c0 ext4_dirty_inode+0x32/0x70 __mark_inode_dirty+0x235/0x670 generic_update_time+0x87/0xd0 touch_atime+0xa9/0xd0 ext4_file_mmap+0x90/0xb0 mmap_region+0x370/0x5b0 do_mmap+0x415/0x4f0 vm_mmap_pgoff+0xd7/0x120 SyS_mmap_pgoff+0x1c5/0x290 SyS_mmap+0x22/0x30 entry_SYSCALL_64_fastpath+0x1f/0xc2 -> #1 (&mm->mmap_sem){++++++}: lock_acquire+0xbd/0x200 __might_fault+0x70/0xa0 __nd_ioctl+0x683/0x720 [libnvdimm] nvdimm_ioctl+0x8b/0xe0 [libnvdimm] do_vfs_ioctl+0xa8/0x740 SyS_ioctl+0x79/0x90 do_syscall_64+0x6c/0x200 return_from_SYSCALL_64+0x0/0x7a -> #0 (&nvdimm_bus->reconfig_mutex){+.+.+.}: __lock_acquire+0x16b6/0x1730 lock_acquire+0xbd/0x200 __mutex_lock+0x88/0x9b0 mutex_lock_nested+0x1b/0x20 nvdimm_bus_lock+0x21/0x30 [libnvdimm] nvdimm_forget_poison+0x25/0x50 [libnvdimm] nvdimm_clear_poison+0x106/0x140 [libnvdimm] pmem_do_bvec+0x1c2/0x2b0 [nd_pmem] pmem_make_request+0xf9/0x270 [nd_pmem] generic_make_request+0x118/0x3b0 submit_bio+0x75/0x150 Fixes: 62232e4 ("libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices") Cc: Dave Jiang <[email protected]> Reported-by: Vishal Verma <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Jun 19, 2017
[ Upstream commit ddc665a ] When the instruction right before the branch destination is a 64 bit load immediate, we currently calculate the wrong jump offset in the ctx->offset[] array as we only account one instruction slot for the 64 bit load immediate although it uses two BPF instructions. Fix it up by setting the offset into the right slot after we incremented the index. Before (ldimm64 test 1): [...] 00000020: 52800007 mov w7, #0x0 // #0 00000024: d2800060 mov x0, #0x3 // #3 00000028: d2800041 mov x1, #0x2 // #2 0000002c: eb01001f cmp x0, x1 00000030: 54ffff82 b.cs 0x00000020 00000034: d29fffe7 mov x7, #0xffff // #65535 00000038: f2bfffe7 movk x7, #0xffff, lsl torvalds#16 0000003c: f2dfffe7 movk x7, #0xffff, lsl torvalds#32 00000040: f2ffffe7 movk x7, #0xffff, lsl torvalds#48 00000044: d29dddc7 mov x7, #0xeeee // #61166 00000048: f2bdddc7 movk x7, #0xeeee, lsl torvalds#16 0000004c: f2ddddc7 movk x7, #0xeeee, lsl torvalds#32 00000050: f2fdddc7 movk x7, #0xeeee, lsl torvalds#48 [...] After (ldimm64 test 1): [...] 00000020: 52800007 mov w7, #0x0 // #0 00000024: d2800060 mov x0, #0x3 // #3 00000028: d2800041 mov x1, #0x2 // #2 0000002c: eb01001f cmp x0, x1 00000030: 540000a2 b.cs 0x00000044 00000034: d29fffe7 mov x7, #0xffff // #65535 00000038: f2bfffe7 movk x7, #0xffff, lsl torvalds#16 0000003c: f2dfffe7 movk x7, #0xffff, lsl torvalds#32 00000040: f2ffffe7 movk x7, #0xffff, lsl torvalds#48 00000044: d29dddc7 mov x7, #0xeeee // #61166 00000048: f2bdddc7 movk x7, #0xeeee, lsl torvalds#16 0000004c: f2ddddc7 movk x7, #0xeeee, lsl torvalds#32 00000050: f2fdddc7 movk x7, #0xeeee, lsl torvalds#48 [...] Also, add a couple of test cases to make sure JITs pass this test. Tested on Cavium ThunderX ARMv8. The added test cases all pass after the fix. Fixes: 8eee539 ("arm64: bpf: fix out-of-bounds read in bpf2a64_offset()") Reported-by: David S. Miller <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Alexei Starovoitov <[email protected]> Cc: Xi Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Aug 2, 2017
this bug happened when amdgpu load failed. [ 75.740951] BUG: unable to handle kernel paging request at 00000000000031c0 [ 75.748167] IP: [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] [ 75.755774] PGD 0 [ 75.759185] Oops: 0000 [#1] SMP [ 75.762408] Modules linked in: amdgpu(OE-) ttm(OE) drm_kms_helper(OE) drm(OE) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) eeepc_wmi(E) asus_wmi(E) sparse_keymap(E) intel_rapl(E) snd_hda_codec_hdmi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) snd_hwdep(E) snd_pcm(E) snd_seq_midi(E) coretemp(E) kvm_intel(E) snd_seq_midi_event(E) snd_rawmidi(E) kvm(E) snd_seq(E) joydev(E) snd_seq_device(E) snd_timer(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) mei_me(E) ghash_clmulni_intel(E) snd(E) aesni_intel(E) mei(E) soundcore(E) aes_x86_64(E) shpchp(E) serio_raw(E) lrw(E) acpi_pad(E) gf128mul(E) glue_helper(E) ablk_helper(E) mac_hid(E) [ 75.835574] cryptd(E) parport_pc(E) ppdev(E) lp(E) nfsd(E) parport(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) usbhid(E) mxm_wmi(E) psmouse(E) e1000e(E) ptp(E) pps_core(E) ahci(E) libahci(E) wmi(E) video(E) i2c_hid(E) hid(E) [ 75.858489] CPU: 5 PID: 1603 Comm: rmmod Tainted: G OE 4.9.0-custom #2 [ 75.866183] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 0901 08/31/2015 [ 75.875050] task: ffff88045d1bbb80 task.stack: ffffc90002de4000 [ 75.881094] RIP: 0010:[<ffffffffa064a0e0>] [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] [ 75.891238] RSP: 0018:ffffc90002de7d48 EFLAGS: 00010286 [ 75.896648] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 75.903933] RDX: 0000000000000000 RSI: ffff88045d1bbb80 RDI: 0000000000000286 [ 75.911183] RBP: ffffc90002de7d50 R08: 0000000000000502 R09: 0000000000000004 [ 75.918449] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880464bf0000 [ 75.925675] R13: ffffffffa0853000 R14: 0000000000000000 R15: 0000564e44f88210 [ 75.932980] FS: 00007f13d5400700(0000) GS:ffff880476540000(0000) knlGS:0000000000000000 [ 75.941238] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.947088] CR2: 00000000000031c0 CR3: 000000045fd0b000 CR4: 00000000003406e0 [ 75.954332] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 75.961566] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 75.968834] Stack: [ 75.970881] ffff880464bf0000 ffffc90002de7d60 ffffffffa0636592 ffffc90002de7d80 [ 75.978454] ffffffffa059015f ffff880464bf0000 ffff880464bf0000 ffffc90002de7da8 [ 75.986076] ffffffffa0595216 ffff880464bf0000 ffff880460f4d000 ffffffffa0853000 [ 75.993692] Call Trace: [ 75.996177] [<ffffffffa0636592>] amdgpu_driver_lastclose_kms+0x12/0x20 [amdgpu] [ 76.003700] [<ffffffffa059015f>] drm_lastclose+0x2f/0xd0 [drm] [ 76.009777] [<ffffffffa0595216>] drm_dev_unregister+0x16/0xd0 [drm] [ 76.016255] [<ffffffffa0595944>] drm_put_dev+0x34/0x70 [drm] [ 76.022139] [<ffffffffa062f365>] amdgpu_pci_remove+0x15/0x20 [amdgpu] [ 76.028800] [<ffffffff81416499>] pci_device_remove+0x39/0xc0 [ 76.034661] [<ffffffff81531caa>] __device_release_driver+0x9a/0x140 [ 76.041121] [<ffffffff81531e58>] driver_detach+0xb8/0xc0 [ 76.046575] [<ffffffff81530c95>] bus_remove_driver+0x55/0xd0 [ 76.052401] [<ffffffff815325fc>] driver_unregister+0x2c/0x50 [ 76.058244] [<ffffffff81416289>] pci_unregister_driver+0x29/0x90 [ 76.064466] [<ffffffffa0596c5e>] drm_pci_exit+0x9e/0xb0 [drm] [ 76.070507] [<ffffffffa0796d71>] amdgpu_exit+0x1c/0x32 [amdgpu] [ 76.076609] [<ffffffff81104810>] SyS_delete_module+0x1a0/0x200 [ 76.082627] [<ffffffff810e2b1a>] ? rcu_eqs_enter.isra.36+0x4a/0x50 [ 76.089001] [<ffffffff8100392e>] do_syscall_64+0x6e/0x180 [ 76.094583] [<ffffffff817e1d2f>] entry_SYSCALL64_slow_path+0x25/0x25 [ 76.101114] Code: 94 c0 c3 31 c0 5d c3 0f 1f 40 00 0f 1f 44 00 00 55 31 c0 48 89 e5 53 48 89 fb 48 c7 c7 1d 21 84 a0 e8 ab 77 b3 e0 e8 fc 8b d7 e0 <48> 8b bb c0 31 00 00 48 85 ff 74 09 e8 ff eb fc ff 85 c0 75 03 [ 76.121432] RIP [<ffffffffa064a0e0>] amdgpu_fbdev_restore_mode+0x20/0x60 [amdgpu] Signed-off-by: Rex Zhu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Aug 2, 2017
Pass crtc_state to the enable callback, and connector_state to all callbacks. This will eliminate the need to guess for the correct pipe in these callbacks. The crtc state is required for pch_enable_backlight to obtain the correct cpu_transcoder. intel_dp_aux_backlight's setup function is called before hw readout, so crtc_state and connector_state->best_encoder are NULL in the enable() and set() callbacks. This fixes the following series of warns from intel_get_pipe_from_connector: [ 219.968428] ------------[ cut here ]------------ [ 219.968481] WARNING: CPU: 3 PID: 2457 at drivers/gpu/drm/i915/intel_display.c:13881 intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968483] WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex)) [ 219.968485] Modules linked in: nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm intel_rapl x86_pkg_temp_thermal coretemp kvm_intel snd_seq_midi snd_seq_midi_event kvm snd_rawmidi irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_seq snd_seq_device serio_raw snd_timer aesni_intel aes_x86_64 crypto_simd glue_helper cryptd lpc_ich snd mei_me shpchp soundcore mei rfkill_gpio mac_hid intel_pmc_ipc parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid igb ahci i915 xhci_pci dca xhci_hcd ptp sdhci_pci sdhci libahci pps_core i2c_hid hid video [ 219.968573] CPU: 3 PID: 2457 Comm: kworker/u8:3 Tainted: G W 4.10.0-tip-201703010159+ #2 [ 219.968575] Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0144.B10.1606270006 06/27/2016 [ 219.968627] Workqueue: events_unbound intel_atomic_commit_work [i915] [ 219.968629] Call Trace: [ 219.968640] dump_stack+0x63/0x87 [ 219.968646] __warn+0xd1/0xf0 [ 219.968651] warn_slowpath_fmt+0x4f/0x60 [ 219.968657] ? drm_printk+0x97/0xa0 [ 219.968708] intel_get_pipe_from_connector+0x62/0x90 [i915] [ 219.968756] intel_panel_enable_backlight+0x19/0xf0 [i915] [ 219.968804] intel_edp_backlight_on.part.22+0x33/0x40 [i915] [ 219.968852] intel_edp_backlight_on+0x18/0x20 [i915] [ 219.968900] intel_enable_ddi+0x94/0xc0 [i915] [ 219.968950] intel_encoders_enable.isra.93+0x77/0x90 [i915] [ 219.969000] haswell_crtc_enable+0x310/0x7f0 [i915] [ 219.969051] intel_update_crtc+0x58/0x100 [i915] [ 219.969101] skl_update_crtcs+0x218/0x240 [i915] [ 219.969153] intel_atomic_commit_tail+0x350/0x1000 [i915] [ 219.969159] ? vtime_account_idle+0xe/0x50 [ 219.969164] ? finish_task_switch+0x107/0x250 [ 219.969214] intel_atomic_commit_work+0x12/0x20 [i915] [ 219.969219] process_one_work+0x153/0x3f0 [ 219.969223] worker_thread+0x12b/0x4b0 [ 219.969227] kthread+0x101/0x140 [ 219.969230] ? rescuer_thread+0x340/0x340 [ 219.969233] ? kthread_park+0x90/0x90 [ 219.969237] ? do_syscall_64+0x6e/0x180 [ 219.969243] ret_from_fork+0x2c/0x40 [ 219.969246] ---[ end trace 0a8fa19387b9ad6d ]--- Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100022 Signed-off-by: Maarten Lankhorst <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Aug 11, 2017
There's no need to take the rcu read lock when rounding rate.
This patch fixes the following BUG:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:620
in_atomic(): 0, irqs_disabled(): 0, pid: 153, name: kworker/u16:2
5 locks held by kworker/u16:2/153:
#0: ("%s"("devfreq_wq")){......}, at: [<ffffff80080b8cf4>] process_one_work+0x1c4/0x58c
#1: ((&(&devfreq->work)->work)){......}, at: [<ffffff80080b8cf4>] process_one_work+0x1c4/0x58c
#2: (&devfreq->lock){......}, at: [<ffffff80089534c8>] devfreq_monitor+0x28/0x8c
#3: (&vop->vop_lock){......}, at: [<ffffff80084c826c>] dmc_notifier_call+0x14/0x34
#4: (rcu_read_lock){......}, at: [<ffffff80089557f0>] rockchip_dmcfreq_target+0x0/0x2e0
CPU: 3 PID: 153 Comm: kworker/u16:2 Not tainted 4.4.77 #2573
Hardware name: Rockchip Sheep board (DT)
Workqueue: devfreq_wq devfreq_monitor
Call trace:
[<ffffff8008089930>] dump_backtrace+0x0/0x1c8
[<ffffff8008089b0c>] show_stack+0x14/0x1c
[<ffffff800839718c>] dump_stack+0x8c/0xac
[<ffffff80080c8d5c>] ___might_sleep+0x11c/0x128
[<ffffff80080c8ddc>] __might_sleep+0x74/0x84
[<ffffff8008c371a4>] mutex_lock_nested+0x4c/0x39c
[<ffffff80089458d8>] clk_prepare_lock+0x58/0xc8
[<ffffff8008946ec8>] clk_round_rate+0x34/0x94
[<ffffff800895589c>] rockchip_dmcfreq_target+0xac/0x2e0
[<ffffff80089533f4>] update_devfreq+0x100/0x1ac
[<ffffff80089534d0>] devfreq_monitor+0x30/0x8c
[<ffffff80080b8e1c>] process_one_work+0x2ec/0x58c
[<ffffff80080ba16c>] worker_thread+0x300/0x428
[<ffffff80080bf3e0>] kthread+0x104/0x10c
[<ffffff8008082840>] ret_from_fork+0x10/0x50
Change-Id: I31f75a55da72cab597796edd5c339222094fff97
Signed-off-by: Finley Xiao <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Nov 14, 2017
intel_mid_soc_stepping() is not used anywhere. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Nov 14, 2017
Guillaume Nault says: ==================== l2tp: fix some races in session deletion L2TP provides several interfaces for deleting sessions. Using two of them concurrently can lead to use-after-free bugs. Patch #2 uses a flag to prevent double removal of L2TP sessions. Patch #1 fixes a bug found in the way. Fixing this bug is also necessary for patch #2 to handle all cases. This issue is similar to the tunnel deletion bug being worked on by Sabrina: https://patchwork.ozlabs.org/patch/814173/ ==================== Signed-off-by: David S. Miller <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Nov 14, 2017
The following lockdep splat has been noticed during LTP testing ====================================================== WARNING: possible circular locking dependency detected 4.13.0-rc3-next-20170807 torvalds#12 Not tainted ------------------------------------------------------ a.out/4771 is trying to acquire lock: (cpu_hotplug_lock.rw_sem){++++++}, at: [<ffffffff812b4668>] drain_all_stock.part.35+0x18/0x140 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [<ffffffff8106eb35>] __do_page_fault+0x175/0x530 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){++++++}: lock_acquire+0xc9/0x230 __might_fault+0x70/0xa0 _copy_to_user+0x23/0x70 filldir+0xa7/0x110 xfs_dir2_sf_getdents.isra.10+0x20c/0x2c0 [xfs] xfs_readdir+0x1fa/0x2c0 [xfs] xfs_file_readdir+0x30/0x40 [xfs] iterate_dir+0x17a/0x1a0 SyS_getdents+0xb0/0x160 entry_SYSCALL_64_fastpath+0x1f/0xbe -> #2 (&type->i_mutex_dir_key#3){++++++}: lock_acquire+0xc9/0x230 down_read+0x51/0xb0 lookup_slow+0xde/0x210 walk_component+0x160/0x250 link_path_walk+0x1a6/0x610 path_openat+0xe4/0xd50 do_filp_open+0x91/0x100 file_open_name+0xf5/0x130 filp_open+0x33/0x50 kernel_read_file_from_path+0x39/0x80 _request_firmware+0x39f/0x880 request_firmware_direct+0x37/0x50 request_microcode_fw+0x64/0xe0 reload_store+0xf7/0x180 dev_attr_store+0x18/0x30 sysfs_kf_write+0x44/0x60 kernfs_fop_write+0x113/0x1a0 __vfs_write+0x37/0x170 vfs_write+0xc7/0x1c0 SyS_write+0x58/0xc0 do_syscall_64+0x6c/0x1f0 return_from_SYSCALL_64+0x0/0x7a -> #1 (microcode_mutex){+.+.+.}: lock_acquire+0xc9/0x230 __mutex_lock+0x88/0x960 mutex_lock_nested+0x1b/0x20 microcode_init+0xbb/0x208 do_one_initcall+0x51/0x1a9 kernel_init_freeable+0x208/0x2a7 kernel_init+0xe/0x104 ret_from_fork+0x2a/0x40 -> #0 (cpu_hotplug_lock.rw_sem){++++++}: __lock_acquire+0x153c/0x1550 lock_acquire+0xc9/0x230 cpus_read_lock+0x4b/0x90 drain_all_stock.part.35+0x18/0x140 try_charge+0x3ab/0x6e0 mem_cgroup_try_charge+0x7f/0x2c0 shmem_getpage_gfp+0x25f/0x1050 shmem_fault+0x96/0x200 __do_fault+0x1e/0xa0 __handle_mm_fault+0x9c3/0xe00 handle_mm_fault+0x16e/0x380 __do_page_fault+0x24a/0x530 do_page_fault+0x30/0x80 page_fault+0x28/0x30 other info that might help us debug this: Chain exists of: cpu_hotplug_lock.rw_sem --> &type->i_mutex_dir_key#3 --> &mm->mmap_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&type->i_mutex_dir_key#3); lock(&mm->mmap_sem); lock(cpu_hotplug_lock.rw_sem); *** DEADLOCK *** 2 locks held by a.out/4771: #0: (&mm->mmap_sem){++++++}, at: [<ffffffff8106eb35>] __do_page_fault+0x175/0x530 #1: (percpu_charge_mutex){+.+...}, at: [<ffffffff812b4c97>] try_charge+0x397/0x6e0 The problem is very similar to the one fixed by commit a459eeb ("mm, page_alloc: do not depend on cpu hotplug locks inside the allocator"). We are taking hotplug locks while we can be sitting on top of basically arbitrary locks. This just calls for problems. We can get rid of {get,put}_online_cpus, fortunately. We do not have to be worried about races with memory hotplug because drain_local_stock, which is called from both the WQ draining and the memory hotplug contexts, is always operating on the local cpu stock with IRQs disabled. The only thing to be careful about is that the target memcg doesn't vanish while we are still in drain_all_stock so take a reference on it. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Michal Hocko <[email protected]> Reported-by: Artem Savkov <[email protected]> Tested-by: Artem Savkov <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Nov 14, 2017
printk_ratelimit() invokes ___ratelimit() which may invoke a normal printk() (pr_warn() in this particular case) to warn about suppressed output. Given that printk_ratelimit() may be called from anywhere, that pr_warn() is dangerous - it may end up deadlocking the system. Fix ___ratelimit() by using deferred printk(). Sasha reported the following lockdep error: : Unregister pv shared memory for cpu 8 : select_fallback_rq: 3 callbacks suppressed : process 8583 (trinity-c78) no longer affine to cpu8 : : ====================================================== : WARNING: possible circular locking dependency detected : 4.14.0-rc2-next-20170927+ torvalds#252 Not tainted : ------------------------------------------------------ : migration/8/62 is trying to acquire lock: : (&port_lock_key){-.-.}, at: serial8250_console_write() : : but task is already holding lock: : (&rq->lock){-.-.}, at: sched_cpu_dying() : : which lock already depends on the new lock. : : : the existing dependency chain (in reverse order) is: : : -> #3 (&rq->lock){-.-.}: : __lock_acquire() : lock_acquire() : _raw_spin_lock() : task_fork_fair() : sched_fork() : copy_process.part.31() : _do_fork() : kernel_thread() : rest_init() : start_kernel() : x86_64_start_reservations() : x86_64_start_kernel() : verify_cpu() : : -> #2 (&p->pi_lock){-.-.}: : __lock_acquire() : lock_acquire() : _raw_spin_lock_irqsave() : try_to_wake_up() : default_wake_function() : woken_wake_function() : __wake_up_common() : __wake_up_common_lock() : __wake_up() : tty_wakeup() : tty_port_default_wakeup() : tty_port_tty_wakeup() : uart_write_wakeup() : serial8250_tx_chars() : serial8250_handle_irq.part.25() : serial8250_default_handle_irq() : serial8250_interrupt() : __handle_irq_event_percpu() : handle_irq_event_percpu() : handle_irq_event() : handle_level_irq() : handle_irq() : do_IRQ() : ret_from_intr() : native_safe_halt() : default_idle() : arch_cpu_idle() : default_idle_call() : do_idle() : cpu_startup_entry() : rest_init() : start_kernel() : x86_64_start_reservations() : x86_64_start_kernel() : verify_cpu() : : -> #1 (&tty->write_wait){-.-.}: : __lock_acquire() : lock_acquire() : _raw_spin_lock_irqsave() : __wake_up_common_lock() : __wake_up() : tty_wakeup() : tty_port_default_wakeup() : tty_port_tty_wakeup() : uart_write_wakeup() : serial8250_tx_chars() : serial8250_handle_irq.part.25() : serial8250_default_handle_irq() : serial8250_interrupt() : __handle_irq_event_percpu() : handle_irq_event_percpu() : handle_irq_event() : handle_level_irq() : handle_irq() : do_IRQ() : ret_from_intr() : native_safe_halt() : default_idle() : arch_cpu_idle() : default_idle_call() : do_idle() : cpu_startup_entry() : rest_init() : start_kernel() : x86_64_start_reservations() : x86_64_start_kernel() : verify_cpu() : : -> #0 (&port_lock_key){-.-.}: : check_prev_add() : __lock_acquire() : lock_acquire() : _raw_spin_lock_irqsave() : serial8250_console_write() : univ8250_console_write() : console_unlock() : vprintk_emit() : vprintk_default() : vprintk_func() : printk() : ___ratelimit() : __printk_ratelimit() : select_fallback_rq() : sched_cpu_dying() : cpuhp_invoke_callback() : take_cpu_down() : multi_cpu_stop() : cpu_stopper_thread() : smpboot_thread_fn() : kthread() : ret_from_fork() : : other info that might help us debug this: : : Chain exists of: : &port_lock_key --> &p->pi_lock --> &rq->lock : : Possible unsafe locking scenario: : : CPU0 CPU1 : ---- ---- : lock(&rq->lock); : lock(&p->pi_lock); : lock(&rq->lock); : lock(&port_lock_key); : : *** DEADLOCK *** : : 4 locks held by migration/8/62: : #0: (&p->pi_lock){-.-.}, at: sched_cpu_dying() : #1: (&rq->lock){-.-.}, at: sched_cpu_dying() : #2: (printk_ratelimit_state.lock){....}, at: ___ratelimit() : #3: (console_lock){+.+.}, at: vprintk_emit() : : stack backtrace: : CPU: 8 PID: 62 Comm: migration/8 Not tainted 4.14.0-rc2-next-20170927+ torvalds#252 : Call Trace: : dump_stack() : print_circular_bug() : check_prev_add() : ? add_lock_to_list.isra.26() : ? check_usage() : ? kvm_clock_read() : ? kvm_sched_clock_read() : ? sched_clock() : ? check_preemption_disabled() : __lock_acquire() : ? __lock_acquire() : ? add_lock_to_list.isra.26() : ? debug_check_no_locks_freed() : ? memcpy() : lock_acquire() : ? serial8250_console_write() : _raw_spin_lock_irqsave() : ? serial8250_console_write() : serial8250_console_write() : ? serial8250_start_tx() : ? lock_acquire() : ? memcpy() : univ8250_console_write() : console_unlock() : ? __down_trylock_console_sem() : vprintk_emit() : vprintk_default() : vprintk_func() : printk() : ? show_regs_print_info() : ? lock_acquire() : ___ratelimit() : __printk_ratelimit() : select_fallback_rq() : sched_cpu_dying() : ? sched_cpu_starting() : ? rcutree_dying_cpu() : ? sched_cpu_starting() : cpuhp_invoke_callback() : ? cpu_disable_common() : take_cpu_down() : ? trace_hardirqs_off_caller() : ? cpuhp_invoke_callback() : multi_cpu_stop() : ? __this_cpu_preempt_check() : ? cpu_stop_queue_work() : cpu_stopper_thread() : ? cpu_stop_create() : smpboot_thread_fn() : ? sort_range() : ? schedule() : ? __kthread_parkme() : kthread() : ? sort_range() : ? kthread_create_on_node() : ret_from_fork() : process 9121 (trinity-c78) no longer affine to cpu8 : smpboot: CPU 8 is now offline Link: http://lkml.kernel.org/r/[email protected] Fixes: 6b1d174 ("ratelimit: extend to print suppressed messages on release") Signed-off-by: Sergey Senozhatsky <[email protected]> Reported-by: Sasha Levin <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
wzyy2
pushed a commit
that referenced
this pull request
Nov 14, 2017
media/lm3642.h is not used anywhere. Moreover, there is a driver under LEDs framework for very same IP which would be used anyway. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.