[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
The userspace regression is fixed in latest available kernels for all series:
Xenial (Trusty-HWE): 4.4.0-143
Bionic (Xenial-HWE): 4.15.0-46
Cosmic (Bionic-HWE): 4.18.0-16
Disco (development series): 5.0.0-7.8
Cheers,
Guilherme
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Released
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug was fixed in the package linux - 4.19.0-12.13
---
linux (4.19.0-12.13) disco; urgency=medium
* linux: 4.19.0-12.13 -proposed tracker (LP: #1813664)
* kernel oops in bcache module (LP: #1793901)
- SAUCE: bcache: never writeback a discard operation
* Disco update: 4.19.18 upstream stable release (LP: #1813611)
- ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped
address
- mlxsw: spectrum: Disable lag port TX before removing it
- mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion
- net: dsa: mv88x6xxx: mv88e6390 errata
- net, skbuff: do not prefer skb allocation fails early
- qmi_wwan: add MTU default to qmap network interface
- ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses
- net: clear skb->tstamp in bridge forwarding path
- netfilter: ipset: Allow matching on destination MAC address for mac and
ipmac sets
- gpio: pl061: Move irq_chip definition inside struct pl061
- drm/amd/display: Guard against null stream_state in set_crc_source
- drm/amdkfd: fix interrupt spin lock
- ixgbe: allow IPsec Tx offload in VEPA mode
- platform/x86: asus-wmi: Tell the EC the OS will handle the display off
hotkey
- e1000e: allow non-monotonic SYSTIM readings
- usb: typec: tcpm: Do not disconnect link for self powered devices
- selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
- of: overlay: add missing of_node_put() after add new node to changeset
- writeback: don't decrement wb->refcnt if !wb->bdi
- serial: set suppress_bind_attrs flag only if builtin
- bpf: Allow narrow loads with offset > 0
- ALSA: oxfw: add support for APOGEE duet FireWire
- x86/mce: Fix -Wmissing-prototypes warnings
- MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
- crypto: ecc - regularize scalar for scalar multiplication
- arm64: perf: set suppress_bind_attrs flag to true
- drm/atomic-helper: Complete fake_commit->flip_done potentially earlier
- clk: meson: meson8b: fix incorrect divider mapping in cpu_scale_table
- samples: bpf: fix: error handling regarding kprobe_events
- usb: gadget: udc: renesas_usb3: add a safety connection way for
forced_b_device
- fpga: altera-cvp: fix probing for multiple FPGAs on the bus
- selinux: always allow mounting submounts
- ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined
- scsi: qedi: Check for session online before getting iSCSI TLV data.
- drm/amdgpu: Reorder uvd ring init before uvd resume
- rxe: IB_WR_REG_MR does not capture MR's iova field
- efi/libstub: Disable some warnings for x86{,_64}
- jffs2: Fix use of uninitialized delayed_work, lockdep breakage
- clk: imx: make mux parent strings const
- pstore/ram: Do not treat empty buffers as valid
- media: uvcvideo: Refactor teardown of uvc on USB disconnect
- powerpc/xmon: Fix invocation inside lock region
- powerpc/pseries/cpuidle: Fix preempt warning
- media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
- ASoC: use dma_ops of parent device for acp_audio_dma
- media: venus: core: Set dma maximum segment size
- staging: erofs: fix use-after-free of on-stack `z_erofs_vle_unzip_io'
- net: call sk_dst_reset when set SO_DONTROUTE
- scsi: target: use consistent left-aligned ASCII INQUIRY data
- scsi: target/core: Make sure that target_wait_for_sess_cmds() waits long
enough
- selftests: do not macro-expand failed assertion expressions
- arm64: kasan: Increase stack size for KASAN_EXTRA
- clk: imx6q: reset exclusive gates on init
- arm64: Fix minor issues with the dcache_by_line_op macro
- bpf: relax verifier restriction on BPF_MOV | BPF_ALU
- kconfig: fix file name and line number of warn_ignored_character()
- kconfig: fix memory leak when EOF is encountered in quotation
- mmc: atmel-mci: do not assume idle after atmci_request_end
- btrfs: volumes: Make sure there is no overlap of dev extents at mount time
- btrfs: alloc_chunk: fix more DUP stripe size handling
- btrfs: fix use-after-free due to race between replace start and cancel
- btrfs: improve error handling of btrfs_add_link
- tty/serial: do not free trasnmit buffer page under port lock
- perf intel-pt: Fix error with config term "pt=0"
- perf tests ARM: Disable breakpoint tests 32-bit
- perf svghelper: Fix unchecked usage of strncpy()
- perf parse-events: Fix unchecked usage of strncpy()
- perf vendor events intel: Fix Load_Miss_Real_Latency on SKL/SKX
- netfilter: ipt_CLUSTERIP: check MAC address when duplicate config is set
- netfilter: ipt_CLUSTERIP: remove wrong WARN_ON_ONCE in netns exit routine
- netfilter: ipt_CLUSTERIP: fix deadlock in netns exit routine
- x86/topology: Use total_cpus for max logical packages calculation
- dm crypt: use u64 instead of sector_t t
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug was fixed in the package linux - 4.18.0-14.15 --- linux (4.18.0-14.15) cosmic; urgency=medium * linux: 4.18.0-14.15 -proposed tracker (LP: #1811406) * CPU hard lockup with rigorous writes to NVMe drive (LP: #1810998) - blk-wbt: Avoid lock contention and thundering herd issue in wbt_wait - blk-wbt: move disable check into get_limit() - blk-wbt: use wq_has_sleeper() for wq active check - blk-wbt: fix has-sleeper queueing check - blk-wbt: abstract out end IO completion handler - blk-wbt: improve waking of tasks * To reduce the Realtek USB cardreader power consumption (LP: #1811337) - mmc: core: Introduce MMC_CAP_SYNC_RUNTIME_PM - mmc: rtsx_usb_sdmmc: Don't runtime resume the device while changing led - mmc: rtsx_usb_sdmmc: Re-work runtime PM support - mmc: rtsx_usb_sdmmc: Re-work card detection/removal support - memstick: rtsx_usb_ms: Add missing pm_runtime_disable() in probe function - misc: rtsx_usb: Use USB remote wakeup signaling for card insertion detection - memstick: Prevent memstick host from getting runtime suspended during card detection - memstick: rtsx_usb_ms: Use ms_dev() helper - memstick: rtsx_usb_ms: Support runtime power management * Support non-strict iommu mode on arm64 (LP: #1806488) - iommu/io-pgtable-arm: Fix race handling in split_blk_unmap() - iommu/arm-smmu-v3: Implement flush_iotlb_all hook - iommu/dma: Add support for non-strict mode - iommu: Add "iommu.strict" command line option - iommu/io-pgtable-arm: Add support for non-strict mode - iommu/arm-smmu-v3: Add support for non-strict mode - iommu/io-pgtable-arm-v7s: Add support for non-strict mode - iommu/arm-smmu: Support non-strict mode * [Regression] crashkernel fails on HiSilicon D05 (LP: #1806766) - efi: honour memory reservations passed via a linux specific config table - efi/arm: libstub: add a root memreserve config table - efi: add API to reserve memory persistently across kexec reboot - irqchip/gic-v3-its: Change initialization ordering for LPIs - irqchip/gic-v3-its: Simplify LPI_PENDBASE_SZ usage - irqchip/gic-v3-its: Split property table clearing from allocation - irqchip/gic-v3-its: Move pending table allocation to init time - irqchip/gic-v3-its: Keep track of property table's PA and VA - irqchip/gic-v3-its: Allow use of pre-programmed LPI tables - irqchip/gic-v3-its: Use pre-programmed redistributor tables with kdump kernels - irqchip/gic-v3-its: Check that all RDs have the same property table - irqchip/gic-v3-its: Register LPI tables with EFI config table - irqchip/gic-v3-its: Allow use of LPI tables in reserved memory - arm64: memblock: don't permit memblock resizing until linear mapping is up - efi/arm: Defer persistent reservations until after paging_init() - efi: Permit calling efi_mem_reserve_persistent() from atomic context - efi: Prevent GICv3 WARN() by mapping the memreserve table before first use * ELAN900C:00 04F3:2844 touchscreen doesn't work (LP: #1811335) - pinctrl: cannonlake: Fix community ordering for H variant - pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H variant * Add Cavium ThunderX2 SoC UNCORE PMU driver (LP: #1811200) - Documentation: perf: Add documentation for ThunderX2 PMU uncore driver - drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver - [Config] New config CONFIG_THUNDERX2_PMU=m * iptables connlimit allows more connections than the limit when using multiple CPUs (LP: #1811094) - netfilter: nf_conncount: don't skip eviction when age is negative * CVE-2018-16882 - KVM: Fix UAF in nested posted interrupt processing * Cannot initialize ATA disk if IDENTIFY command fails (LP: #1809046) - scsi: libsas: check the ata device status by ata_dev_enabled() * scsi: libsas: fix a race condition when smp task timeout (LP: #1808912) - scsi: libsas: fix a race condition when smp task timeout * CVE-2018-14625 - vhost/vsock: fix use-after-free in network stack callers * Fix and issue that LG I2C touchscreen stops working after reboot (LP: #1805085) - HID: i2c-hid: Disable runtime PM for LG touchscreen * Drivers: hv: vmbus: Offload the handling of channels to two workqueues (LP: #1807757) - Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl() - Drivers: hv: vmbus: Offload the handling of channels to two workqueues * Disable LPM for Raydium Touchscreens (LP: #1802248) - USB: quirks: Add no-lpm quirk for Raydium touchscreens * Power leakage at S5 with Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (LP: #1805607) - SAUCE: ath10k: provide reset function for QCA9377 chip * CVE-2018-19407 - KVM: X86: Fix scan ioapic use-before-initialization * Fix USB2 device wrongly detected as USB1 (LP: #1806534) - xhci: Add quirk to workaround the errata
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug was fixed in the package linux - 4.4.0-142.168 --- linux (4.4.0-142.168) xenial; urgency=medium * linux: 4.4.0-142.168 -proposed tracker (LP: #1811846) * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * iptables connlimit allows more connections than the limit when using multiple CPUs (LP: #1811094) - netfilter: xt_connlimit: don't store address in the conn nodes - SAUCE: netfilter: xt_connlimit: remove the 'addr' parameter in add_hlist() - netfilter: nf_conncount: expose connection list interface - netfilter: nf_conncount: Fix garbage collection with zones - netfilter: nf_conncount: fix garbage collection confirm race - netfilter: nf_conncount: don't skip eviction when age is negative * CVE-2017-5715 - SAUCE: x86/speculation: Cleanup IBPB runtime control handling - SAUCE: x86/speculation: Cleanup IBRS runtime control handling - SAUCE: x86/speculation: Use x86_spec_ctrl_base in entry/exit code - SAUCE: x86/speculation: Move RSB_CTXSW hunk * Xenial update: 4.4.167 upstream stable release (LP: #1811077) - media: em28xx: Fix use-after-free when disconnecting - Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()" - rapidio/rionet: do not free skb before reading its length - s390/qeth: fix length check in SNMP processing - usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 - kvm: mmu: Fix race in emulated page table writes - xtensa: enable coprocessors that are being flushed - xtensa: fix coprocessor context offset definitions - Btrfs: ensure path name is null terminated at btrfs_control_ioctl - ALSA: wss: Fix invalid snd_free_pages() at error path - ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write - ALSA: control: Fix race between adding and removing a user element - ALSA: sparc: Fix invalid snd_free_pages() at error path - ext2: fix potential use after free - dmaengine: at_hdmac: fix memory leak in at_dma_xlate() - dmaengine: at_hdmac: fix module unloading - btrfs: release metadata before running delayed refs - USB: usb-storage: Add new IDs to ums-realtek - usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series - misc: mic/scif: fix copy-paste error in scif_create_remote_lookup - Kbuild: suppress packed-not-aligned warning for default setting only - exec: avoid gcc-8 warning for get_task_comm - disable stringop truncation warnings for now - kobject: Replace strncpy with memcpy - unifdef: use memcpy instead of strncpy - kernfs: Replace strncpy with memcpy - ip_tunnel: Fix name string concatenate in __ip_tunnel_create() - drm: gma500: fix logic error - scsi: bfa: convert to strlcpy/strlcat - staging: rts5208: fix gcc-8 logic error warning - kdb: use memmove instead of overlapping memcpy - iser: set sector for ambiguous mr status errors - uprobes: Fix handle_swbp() vs. unregister() + register() race once more - MIPS: ralink: Fix mt7620 nd_sd pinmux - mips: fix mips_get_syscall_arg o32 check - drm/ast: Fix incorrect free on ioregs - scsi: scsi_devinfo: cleanly zero-pad devinfo strings - ALSA: trident: Suppress gcc string warning - scsi: csiostor: Avoid content leaks and casts - kgdboc: Fix restrict error - kgdboc: Fix warning with module build - leds: call led_pwm_set() in leds-pwm to enforce default LED_OFF - leds: turn off the LED and wait for completion on unregistering LED class device - leds: leds-gpio: Fix return value check in create_gpio_led() - Input: xpad - quirk all PDP Xbox One gamepads - Input: matrix_keypad - check for errors from of_get_named_gpio() - Input: elan_i2c - add ELAN0620 to the ACPI table - Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR - Input: elan_i2c - add support for ELAN0621 touchpad - btrfs: Always try all copies when reading extent buffers - Btrfs: fix use-after-free when dumping free space - ARC: change defconfig defaults to ARCv2 - arc: [devboards] Add support of NFSv3 ACL - mm: cleancache: fix corruption on missed inode invalidation - usb: gadget: dummy: fix nonsensical comparisons - iommu/vt-d: Fix NULL pointer dereference in prq_event_thread() - iommu/ipmmu-vmsa: Fix crash on early domain free - can: rcar_can: Fix erroneous registration - batman-adv: Expand merged fragment buffer for full packet - bnx2x: Assign unique DMAE channel number for FW DMAE transactions. - qed: Fix PTT leak in qed_drain() - qed: Fix reading wrong value in loop condition - net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command - net/mlx4_core: Fix uninitialized variable compilation warning - net/mlx4: Fix UBSAN warning of signed integer overflow - net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug was fixed in the package linux - 4.4.0-142.168 --- linux (4.4.0-142.168) xenial; urgency=medium * linux: 4.4.0-142.168 -proposed tracker (LP: #1811846) * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * iptables connlimit allows more connections than the limit when using multiple CPUs (LP: #1811094) - netfilter: xt_connlimit: don't store address in the conn nodes - SAUCE: netfilter: xt_connlimit: remove the 'addr' parameter in add_hlist() - netfilter: nf_conncount: expose connection list interface - netfilter: nf_conncount: Fix garbage collection with zones - netfilter: nf_conncount: fix garbage collection confirm race - netfilter: nf_conncount: don't skip eviction when age is negative * CVE-2017-5715 - SAUCE: x86/speculation: Cleanup IBPB runtime control handling - SAUCE: x86/speculation: Cleanup IBRS runtime control handling - SAUCE: x86/speculation: Use x86_spec_ctrl_base in entry/exit code - SAUCE: x86/speculation: Move RSB_CTXSW hunk * Xenial update: 4.4.167 upstream stable release (LP: #1811077) - media: em28xx: Fix use-after-free when disconnecting - Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()" - rapidio/rionet: do not free skb before reading its length - s390/qeth: fix length check in SNMP processing - usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 - kvm: mmu: Fix race in emulated page table writes - xtensa: enable coprocessors that are being flushed - xtensa: fix coprocessor context offset definitions - Btrfs: ensure path name is null terminated at btrfs_control_ioctl - ALSA: wss: Fix invalid snd_free_pages() at error path - ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write - ALSA: control: Fix race between adding and removing a user element - ALSA: sparc: Fix invalid snd_free_pages() at error path - ext2: fix potential use after free - dmaengine: at_hdmac: fix memory leak in at_dma_xlate() - dmaengine: at_hdmac: fix module unloading - btrfs: release metadata before running delayed refs - USB: usb-storage: Add new IDs to ums-realtek - usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series - misc: mic/scif: fix copy-paste error in scif_create_remote_lookup - Kbuild: suppress packed-not-aligned warning for default setting only - exec: avoid gcc-8 warning for get_task_comm - disable stringop truncation warnings for now - kobject: Replace strncpy with memcpy - unifdef: use memcpy instead of strncpy - kernfs: Replace strncpy with memcpy - ip_tunnel: Fix name string concatenate in __ip_tunnel_create() - drm: gma500: fix logic error - scsi: bfa: convert to strlcpy/strlcat - staging: rts5208: fix gcc-8 logic error warning - kdb: use memmove instead of overlapping memcpy - iser: set sector for ambiguous mr status errors - uprobes: Fix handle_swbp() vs. unregister() + register() race once more - MIPS: ralink: Fix mt7620 nd_sd pinmux - mips: fix mips_get_syscall_arg o32 check - drm/ast: Fix incorrect free on ioregs - scsi: scsi_devinfo: cleanly zero-pad devinfo strings - ALSA: trident: Suppress gcc string warning - scsi: csiostor: Avoid content leaks and casts - kgdboc: Fix restrict error - kgdboc: Fix warning with module build - leds: call led_pwm_set() in leds-pwm to enforce default LED_OFF - leds: turn off the LED and wait for completion on unregistering LED class device - leds: leds-gpio: Fix return value check in create_gpio_led() - Input: xpad - quirk all PDP Xbox One gamepads - Input: matrix_keypad - check for errors from of_get_named_gpio() - Input: elan_i2c - add ELAN0620 to the ACPI table - Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR - Input: elan_i2c - add support for ELAN0621 touchpad - btrfs: Always try all copies when reading extent buffers - Btrfs: fix use-after-free when dumping free space - ARC: change defconfig defaults to ARCv2 - arc: [devboards] Add support of NFSv3 ACL - mm: cleancache: fix corruption on missed inode invalidation - usb: gadget: dummy: fix nonsensical comparisons - iommu/vt-d: Fix NULL pointer dereference in prq_event_thread() - iommu/ipmmu-vmsa: Fix crash on early domain free - can: rcar_can: Fix erroneous registration - batman-adv: Expand merged fragment buffer for full packet - bnx2x: Assign unique DMAE channel number for FW DMAE transactions. - qed: Fix PTT leak in qed_drain() - qed: Fix reading wrong value in loop condition - net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command - net/mlx4_core: Fix uninitialized variable compilation warning - net/mlx4: Fix UBSAN warning of signed integer overflow - net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
There was an userspace regression reported after the inclusion of these
backports;
it's being handled in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813873.
The fix patch was released upstream and the SRU request was sent to kernel-team
ML (thanks smb!):
https://lists.ubuntu.com/archives/kernel-team/2019-January/098186.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug was fixed in the package linux - 4.15.0-44.47
---
linux (4.15.0-44.47) bionic; urgency=medium
* linux: 4.15.0-44.47 -proposed tracker (LP: #1811419)
* Packaging resync (LP: #1786013)
- [Packaging] update helper scripts
* CPU hard lockup with rigorous writes to NVMe drive (LP: #1810998)
- blk-wbt: pass in enum wbt_flags to get_rq_wait()
- blk-wbt: Avoid lock contention and thundering herd issue in wbt_wait
- blk-wbt: move disable check into get_limit()
- blk-wbt: use wq_has_sleeper() for wq active check
- blk-wbt: fix has-sleeper queueing check
- blk-wbt: abstract out end IO completion handler
- blk-wbt: improve waking of tasks
* To reduce the Realtek USB cardreader power consumption (LP: #1811337)
- mmc: sdhci: Disable 1.8v modes (HS200/HS400/UHS) if controller can't
support
1.8v
- mmc: core: Introduce MMC_CAP_SYNC_RUNTIME_PM
- mmc: rtsx_usb_sdmmc: Don't runtime resume the device while changing led
- mmc: rtsx_usb: Use MMC_CAP2_NO_SDIO
- mmc: rtsx_usb: Enable MMC_CAP_ERASE to allow erase/discard/trim requests
- mmc: rtsx_usb_sdmmc: Re-work runtime PM support
- mmc: rtsx_usb_sdmmc: Re-work card detection/removal support
- memstick: rtsx_usb_ms: Add missing pm_runtime_disable() in probe function
- misc: rtsx_usb: Use USB remote wakeup signaling for card insertion
detection
- memstick: Prevent memstick host from getting runtime suspended during card
detection
- memstick: rtsx_usb_ms: Use ms_dev() helper
- memstick: rtsx_usb_ms: Support runtime power management
* Support non-strict iommu mode on arm64 (LP: #1806488)
- iommu/io-pgtable-arm: Fix race handling in split_blk_unmap()
- iommu/arm-smmu-v3: Implement flush_iotlb_all hook
- iommu/dma: Add support for non-strict mode
- iommu: Add "iommu.strict" command line option
- iommu/io-pgtable-arm: Add support for non-strict mode
- iommu/arm-smmu-v3: Add support for non-strict mode
- iommu/io-pgtable-arm-v7s: Add support for non-strict mode
- iommu/arm-smmu: Support non-strict mode
* ELAN900C:00 04F3:2844 touchscreen doesn't work (LP: #1811335)
- pinctrl: cannonlake: Fix community ordering for H variant
- pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H variant
* Add Cavium ThunderX2 SoC UNCORE PMU driver (LP: #1811200)
- perf: Export perf_event_update_userpage
- Documentation: perf: Add documentation for ThunderX2 PMU uncore driver
- drivers/perf: Add Cavium ThunderX2 SoC UNCORE PMU driver
- [Config] New config CONFIG_THUNDERX2_PMU=m
* Update hisilicon SoC-specific drivers (LP: #1810457)
- SAUCE: Revert "net: hns3: Updates RX packet info fetch in case of multi
BD"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: separate roce from nic when
resetting"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: Use roce handle when calling
roce
callback function"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: Add calling roce callback
function when link status change"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: optimize the process of
notifying
roce client"
- Revert "UBUNTU: SAUCE: {topost} net: hns3: Add pf reset for hip08 RoCE"
- scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency
- ethernet: hisilicon: hns: hns_dsaf_mac: Use generic eth_broadcast_addr
- scsi: hisi_sas: consolidate command check in hisi_sas_get_ata_protocol()
- scsi: hisi_sas: remove some unneeded structure members
- scsi: hisi_sas: Introduce hisi_sas_phy_set_linkrate()
- net: hns: Fix the process of adding broadcast addresses to tcam
- net: hns3: remove redundant variable 'protocol'
- scsi: hisi_sas: Drop hisi_sas_slot_abort()
- net: hns: Make many functions static
- net: hns: make hns_dsaf_roce_reset non static
- net: hisilicon: hns: Replace mdelay() with msleep()
- net: hns3: fix return value error while hclge_cmd_csq_clean failed
- net: hns: remove redundant variables 'max_frm' and 'tmp_mac_key'
- net: hns: Mark expected switch fall-through
- net: hns3: Mark expected switch fall-through
- net: hns3: Remove tx ring BD len register in hns3_enet
- net: hns: modify variable type in hns_nic_reuse_page
- net: hns: use eth_get_headlen interface instead of hns_nic_get_headlen
- net: hns3: modify variable type in hns3_nic_reuse_page
- net: hns3: Fix for vf vlan delete failed problem
- net: hns3: Fix for multicast failure
- net: hns3: Fix error of checking used vlan id
- net: hns3: Implement shutdown ops in hns3 pci driver
- net: hns3: Fix for loopback selftest failed problem
- net: hns3: Fix ping exited problem when doing lp selftest
- net: hns3: Preserve vlan 0 in hardware table
- net: hns3: Only update mac configuation when necessary
- net: hns3: Change the dst mac addr of loopback packet
- net: hns3: Remove redundant codes of query ad
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
I was able to verify/test in both Bionic and Cosmic proposed kernels,
respectively: 4.15.0-44.47 and 4.18.0-14.15.
I don't have a reproducer, but to exercise the paths modified by the
patches, the following approach was taken:
(a) Open ssh connection to the host/test machine, and run the following
there:
DIR="/sys/kernel/debug/tracing"
echo tty_reopen > $DIR/set_ftrace_filter
echo function > $DIR/current_tracer
echo 'p:tty_name n_tty_receive_buf2 tty=+0x170(%di):string' >
$DIR/kprobe_events
echo 1 > $DIR/events/kprobes/tty_name/enable
echo > trace
Then, start running the following loop:
$ while true; do pkill -9 -t pts/1; sleep 1; done
In this point, we don't have a pts/1 there, but keep it running.
(b) In another terminal from the ssh client, run:
$ while true; do ssh ; done
Notice it's interesting to have the following in the .ssh/config of the ssh
client machine:
Host
ControlMaster auto
ControlPath ~/.ssh/%r@%h-%p
ControlPersist 600
in order to keep only one ssh connection opened.
(c) While the SSH in pts/1 is opened and killed automatically (and
reopened by the loop), user must keep typing things in the keyboard in
that terminal to force the tty flush.
(d) After running that for some seconds, one can verify in the trace
output that the functions modified by the main patch in the SRUed series
are there:
$ grep "pts1\|reopen" $DIR/trace|cut -f2- -d]|cut -f2- -d:|sort |uniq -c
66 tty_name: (n_tty_receive_buf2+0x0/0x20) tty="pts1"
60 tty_reopen <-tty_open
Also, the pattern showed in the trace file shows that the functions are called
intermixed:
[...]
kworker/u56:1-3602 [000] 881.779225: tty_name:
(n_tty_receive_buf2+0x0/0x20) tty="pts1"
kworker/u56:1-3602 [000] 881.861901: tty_name:
(n_tty_receive_buf2+0x0/0x20) tty="pts1"
sshd-3403 [023] 882.249355: tty_reopen <-tty_open
bash-4052 [008] 882.250432: tty_reopen <-tty_open
bash-4052 [008] 882.250441: tty_reopen <-tty_open
bash-4052 [008] 882.251935: tty_reopen <-tty_open
kworker/u56:1-3602 [000] 882.440866: tty_name:
(n_tty_receive_buf2+0x0/0x20) tty="pts1"
kworker/u56:1-3602 [000] 882.482994: tty_name:
(n_tty_receive_buf2+0x0/0x20) tty="pts1"
[...]
Worth to notice that I've ran the test in 4.18.0-13 before, and I've
noticed a small delay in the machine while running the test after
updating to the -proposed version, probably due to the lock mechanism
added.
** Tags removed: verification-needed-bionic verification-needed-cosmic
** Tags added: verification-done-bionic verification-done-cosmic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
We're still pending the Xenial verification; I'm waiting for the trusty-
HWE kernel to be released in -proposed, since we have a user capable of
reproducing the crash in that version, so I'm planning to ask them to
try in the trusty-HWE package.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag 'verification-needed-bionic' to 'verification-failed-
bionic'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
cosmic' to 'verification-done-cosmic'. If the problem still exists,
change the tag 'verification-needed-cosmic' to 'verification-failed-
cosmic'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-cosmic
** Tags added: verification-needed-bionic
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Xenial)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Bionic)
Status: Confirmed => Fix Committed
** Changed in: linux (Ubuntu Cosmic)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Cosmic:
Fix Committed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
SRU request was submitted to kernel team.
* For Xenial and trusty-HWE (kernel 4.4):
https://lists.ubuntu.com/archives/kernel-team/2019-January/097556.html
* For Bionic (kernel 4.15) and Cosmic (kernel 4.18):
https://lists.ubuntu.com/archives/kernel-team/2019-January/097562.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the
tty reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
keep accessing a machine through SSH (or keep killing getty when in
IPMI serial console) and in some way run commands before the terminal
is ready in that machine (like hacking some echo into ttySx or pts in
an infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU
request the problem was fixed.
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due
to a hard to reproduce issue reported in the PA-RISC architecture,
which was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Description changed:
[Impact]
* Line discipline code is racy when we have buffer being flush while the
tty is being initialized or reinitialized. For the first problem, we
have an upstream patch since January 2018: b027e2298bd5 ("tty: fix data
race between tty_init_dev and flush of buf") - although it is not in
Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened, we
have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for this
is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition between the buffer flush and the tty
reopen routine is a kernel crash with the following trace:
BUG: unable to handle kernel paging request at 2268
IP: [] n_tty_receive_buf_common+0x6a/0xae0
[...]
Call Trace:
[] ? kvm_sched_clock_read+0x1e/0x30
[] n_tty_receive_buf2+0x14/0x20
[] flush_to_ldisc+0xd5/0x120
[] process_one_work+0x156/0x400
[] worker_thread+0x11a/0x480
[...]
* A kernel crash was collected from an user, analysis is present in
comment #4 in this LP.
-
[Test Case]
* It is not trivial to trigger this fault, but the usual recipe is to
- keep accessing a machine through SSH (or IPMI serial console) and in
- some way run commands before the terminal is ready in that machine (like
- hacking some echo into ttySx or pts in an infinite loop).
+ keep accessing a machine through SSH (or keep killing getty when in IPMI
+ serial console) and in some way run commands before the terminal is
+ ready in that machine (like hacking some echo into ttySx or pts in an
+ infinite loop).
* We have reports of users that could reproduce this issue in their
production environment, and with the patches present in this SRU request
the problem was fixed.
-
[Regression Potential]
* tty subsystem is highly central and patches in that area are always
delicate. For example, the upstream series [0] is a re-spin (V6) due to
a hard to reproduce issue reported in the PA-RISC architecture, which
was found in the V5 iteration [1] but was fixed by the patch
c96cf923a98d, present in this SRU request.
* The patchset [0] is present in tty-next tree since mid-November, and
the patch b027e2298bd5 is available upstream since January/2018 (it's
available in both Ubuntu kernels 4.15 and 4.18), so the overall
likelihood of regressions is low.
* These patches were sniff-tested for the 3 versions (4.4, 4.15 and
4.18) and didn't show any issues.
-
[0] https://marc.info/?l=linux-kernel&m=154103190111795
[1] https://marc.info/?l=linux-kernel&m=153737852618183
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Trusty:
Won't Fix
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Bug description:
[Impact]
* Line discipline code is racy when we have buffer being flush while
the tty is being initialized or reinitialized. For the first problem,
we have an upstream patch since January 2018: b027e2298bd5 ("tty: fix
data race between tty_init_dev and flush of buf") - although it is not
in Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
* For the race between the buffer flush while tty is being reopened,
we have a patch that addresses this issue recently merged for 5.0-rc1:
83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
Ubuntu kernel currently contains this patch, hence we're hereby
submitting the SRU request. The upstream complete patch series for
this is in [0].
* The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
necessary to prevent correlated issues, like preventing a potential deadlock
due to bad prioritization in servicing I/O over releasing
tty_ldisc_lock() - refer to c96cf923a98d ("tty: Don't block on IO when ldisc
change is pending"). All the necessary fixes are grouped here in this SRU
request.
* The symptom of the race condition
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Description changed:
[Impact]
- The following Oops was discovered by user:
+ * Line discipline code is racy when we have buffer being flush while the
+ tty is being initialized or reinitialized. For the first problem, we
+ have an upstream patch since January 2018: b027e2298bd5 ("tty: fix data
+ race between tty_init_dev and flush of buf") - although it is not in
+ Ubuntu kernel 4.4, only in kernels 4.15 and subsequent ones.
- [684766.39] BUG: unable to handle kernel paging request at
2268
- [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0
- [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0
- [684766.669194] Oops: [#1] SMP
- [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag
inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink
nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack
iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables
target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa
ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm
crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm
aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea
glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev
- [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge
stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath
- [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE
4.4.0-124-generic #148~14.04.1-Ubuntu
- [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Bochs 01/01/2011
- [684766.686062] Workqueue: events_unbound flush_to_ldisc
- [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti:
88170dc2c000
- [684766.687670] RIP: 0010:[] []
n_tty_receive_buf_common+0x6a/0xae0
- [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202
- [684766.689521] RAX: RBX: 88162c895000 RCX:
0001
- [684766.690488] RDX: RSI: 88162c895020 RDI:
8819c2d3d4d8
- [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09:
81ec2ba0
- [684766.692480] R10: 0004 R11: R12:
8819c2d3d400
- [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15:
8819c2d3d400
- [684766.694390] FS: () GS:8819d73c()
knlGS:
- [684766.695484] CS: 0010 DS: ES: CR0: 80050033
- [684766.696182] CR2: 2268 CR3: 00195752 CR4:
00360670
- [684766.697141] DR0: DR1: DR2:
- [684766.698114] DR3: DR6: fffe0ff0 DR7:
0400
- [684766.699079] Stack:
- [684766.699412] 8819c2d3d4d8
8819c2d3d648
- [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68
8106312e
- [684766.701501] 88170dc2fd78 0001
88162c895020
- [684766.702534] Call Trace:
- [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30
- [684766.703685] [] n_tty_receive_buf2+0x14/0x20
- [684766.704505] [] flush_to_ldisc+0xd5/0x120
- [684766.705269] [] process_one_work+0x156/0x400
- [684766.706008] [] worker_thread+0x11a/0x480
- [684766.706686] [] ? rescuer_thread+0x310/0x310
- [684766.707386] [] kthread+0xd8/0xf0
- [684766.707993] [] ? kthread_park+0x60/0x60
- [684766.708664] [] ret_from_fork+0x55/0x80
- [684766.709335] [] ? kthread_park+0x60/0x60
- [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7
45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48>
8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00
- [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0
- [684766.714105] RSP
- [684766.714609] CR2: 2268
+ * For the race between the buffer flush while tty is being reopened, we
+ have a patch that addresses this issue recently merged for 5.0-rc1:
+ 83d817f41070 ("tty: Hold tty_ldisc_lock() during tty_reopen()"). No
+ Ubuntu kernel currently contains this patch, hence we're hereby
+ submitting the SRU request. The upstream complete patch series for this
+ is in [0].
- The issue happened in a VM
- KDUMP was configured, so a full Kernel crashdump was created
+ * The approach of both patches are similar - they rely in locking/semaphore
to prevent race conditions. Some additional patches are
+ necessary to prevent correlated issu
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Tags removed: xenial -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Won't Fix Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. Check comment #5 for a summary about the upstream proposals to resolve this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Xenial) Importance: High => Critical -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Won't Fix Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. Check comment #5 for a summary about the upstream proposals to resolve this issue. To manage notifications about this
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Trusty) Status: Confirmed => Won't Fix ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High ** Changed in: linux (Ubuntu Cosmic) Importance: Undecided => High -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Won't Fix Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. Check comment #5 for a summary about the upstream proposals to resolve this issue. To manage notificati
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. Check comment #5 fo
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
There's news - a V6 patchset was proposed recently, that address this issue
and there are good chances to get merged:
https://marc.info/?l=linux-kernel&m=154103190111795
("[PATCHv6 0/7] tty: Hold write ldisc sem in tty_reopen()").
Will update here with SRU request when it gets merged.
Cheers,
Guilherme
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Trusty:
Confirmed
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Status in linux source package in Cosmic:
Confirmed
Bug description:
[Impact]
The following Oops was discovered by user:
[684766.39] BUG: unable to handle kernel paging request at
2268
[684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0
[684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0
[684766.669194] Oops: [#1] SMP
[684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag
inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink
nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack
iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables
target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa
ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm
crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm
aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea
glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev
[684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge
stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6
nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq
libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath
[684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE
4.4.0-124-generic #148~14.04.1-Ubuntu
[684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Bochs 01/01/2011
[684766.686062] Workqueue: events_unbound flush_to_ldisc
[684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti:
88170dc2c000
[684766.687670] RIP: 0010:[] []
n_tty_receive_buf_common+0x6a/0xae0
[684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202
[684766.689521] RAX: RBX: 88162c895000 RCX:
0001
[684766.690488] RDX: RSI: 88162c895020 RDI:
8819c2d3d4d8
[684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09:
81ec2ba0
[684766.692480] R10: 0004 R11: R12:
8819c2d3d400
[684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15:
8819c2d3d400
[684766.694390] FS: () GS:8819d73c()
knlGS:
[684766.695484] CS: 0010 DS: ES: CR0: 80050033
[684766.696182] CR2: 2268 CR3: 00195752 CR4:
00360670
[684766.697141] DR0: DR1: DR2:
[684766.698114] DR3: DR6: fffe0ff0 DR7:
0400
[684766.699079] Stack:
[684766.699412] 8819c2d3d4d8
8819c2d3d648
[684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68
8106312e
[684766.701501] 88170dc2fd78 0001
88162c895020
[684766.702534] Call Trace:
[684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30
[684766.703685] [] n_tty_receive_buf2+0x14/0x20
[684766.704505] [] flush_to_ldisc+0xd5/0x120
[684766.705269] [] process_one_work+0x156/0x400
[684766.706008] [] worker_thread+0x11a/0x480
[684766.706686] [] ? rescuer_thread+0x310/0x310
[684766.707386] [] kthread+0xd8/0xf0
[684766.707993] [] ? kthread_park+0x60/0x60
[684766.708664] [] ret_from_fork+0x55/0x80
[684766.709335] [] ? kthread_park+0x60/0x60
[684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7
45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48>
8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00
[684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0
[684766.714105] RSP
[684766.714609] CR2: 2268
The issue happened in a VM
KDUMP was configured, so a full Kernel crashdump was created
User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM
[Test Case]
* Deploy a Trusty KVM instance with a LTS Xenial kernel (
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: In Progress Status in linux source package in Trusty: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Bug description: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. Check comment #5 for a summary about the upstream proposals to resolve thi
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
Kernel core dump analysis:
crash> set
PID: 23697
COMMAND: "kworker/u82:0"
TASK: 88370bcfaa80 [THREAD_INFO: 883708104000]
CPU: 33
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 23697 TASK: 88370bcfaa80 CPU: 33 COMMAND: "kworker/u82:0"
[...]
#3 [883708107b78] __bad_area_nosemaphore at 8106a889
#4 [883708107bc0] bad_area_nosemaphore at 8106a9a3
#5 [883708107bd0] __do_page_fault at 8106aff2
#6 [883708107c30] trace_do_page_fault at 8106b3f7
#7 [883708107c60] do_async_page_fault at 81063e19
#8 [883708107c70] async_page_fault at 81822958
#9 [883708107cf8] n_tty_receive_buf_common at 814e676a
#10 [883708107dc8] n_tty_receive_buf2 at 814e71f4
#11 [883708107dd8] flush_to_ldisc at 814e9be5
#12 [883708107e20] process_one_work at 8109b0b6
#13 [883708107e68] worker_thread at 8109ba9a
[...]
crash> bt -f
[...]
#9 [883708107cf8] n_tty_receive_buf_common at 814e676a
[...]
883708107d80: 881bc78e4c20
883708107d90: 0014 881bc78e4c00
883708107da0: 881bc78e7800 881cba173d80
883708107db0: 883706cae828 883706cae808
883708107dc0: 883708107dd0 814e71f4
#10 [883708107dc8] n_tty_receive_buf2 at 814e71f4
[...]
>From the stack frame, we can infer that "struct tty_struct" is at
0x881bc78e7800 :
crash> tty_struct -x 881bc78e7800 | grep name
name = "pts3\000...
Also, from the stack frame we see a value 0x14 there, which represents
the count value in the function:
static int n_tty_receive_buf2(struct tty_struct *tty, const unsigned char *cp,
char *fp, int count)
{
return n_tty_receive_buf_common(tty, cp, fp, count, 1);
}
Since 0x14 mean 20 in decimal, I'd expect a 20 characters string,
which turns to be true ( char *cp is at 881bc78e4c20):
crash> rd -a 881bc78e4c20
881bc78e4c20: source /root/openrc
Something is issuing the command "source /root/openrc" to PTS/3.
Checking the "files" command, we get:
crash> foreach files -R dev/pts/3
PID: 2288 TASK: 883786e2ea40 CPU: 29 COMMAND: "sshd"
ROOT: / CWD: /
FD FILE DENTRY INODE TYPE PATH
9 8839b4ce9a00 881a0ba4da40 8838f71fcf88 CHR /dev/pts/3
And checking ssh processes:
crash> ps|grep ssh
2236 7180 18 8836f9dd2a80 IN 0.0 149480 8636 sshd
2275 2274 37 883706e01540 IN 0.0 37836 4940 ssh
2288 2236 29 883786e2ea40 UN 0.0 149480 1372 sshd
7180 1 17 881cb99b6a40 IN 0.0 57204 5240 sshd
14319 7180 2 8836dfd91540 IN 0.0 149480 8460 sshd
All except 2288 are scheduled after a select() syscall.
PID 2288 looks interesting:
crash> bt 2288
PID: 2288 TASK: 883786e2ea40 CPU: 29 COMMAND: "sshd"
[...]
#4 [88373e0bfb48] down_write at 8181e42d
#5 [88373e0bfb60] tty_unthrottle at 814e75be
#6 [88373e0bfb80] n_tty_open at 814e4fb9
#7 [88373e0bfba0] tty_ldisc_open at 814e8bd5
#8 [88373e0bfbc0] tty_ldisc_reinit at 814e9112
#9 [88373e0bfbf0] tty_reopen at 814df50a
#10 [88373e0bfc08] tty_open at 814e318e
#11 [88373e0bfc70] chrdev_open at 8120d5c4
#12 [88373e0bfcb0] do_dentry_open at 81206a6a
#13 [88373e0bfcf8] vfs_open at 81207b35
#14 [88373e0bfd20] path_openat at 81215fed
[...]
This is the one that seems to be racing with the flush_work from CPU 33
that led to the crash.
Since we have the tty_reopen() in the call trace, it's clear it's re-opening
an existing tty after it was closed, but the flush work was running and
the crash happened.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1791758
Title:
ldisc crash on reopened tty
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Trusty:
Confirmed
Status in linux source package in Xenial:
Confirmed
Status in linux source package in Bionic:
Confirmed
Bug description:
[Impact]
The following Oops was discovered by user:
[684766.39] BUG: unable to handle kernel paging request at
2268
[684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0
[684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0
[684766.669194] Oops: [#1] SMP
[684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag
inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink
nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack
iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables
target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa
ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm
crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm
aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea
glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev
[684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge
stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Description changed: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM [Test Case] * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) * SSH in frequently while system is under load, send commands before the prompt has returned. - - [Regression Potential] - - Low, the patch is found upstream since 4.12 (a year ago). - I have provided a test kernel to an impacted user to confirmed it fixes the problem pre-SRU. - - - [Other Info] - - * Upstream discussion - https://lore.kernel.org/lkml/573a5996.3080...@hurleysoftware.com/ - - * Upstream patch - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05 - - $ git describe --contains 71472fa9c52b1da27663c275d416d8654b905f05 - v4.12-rc1 + ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in:
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
Quick summary about this issue upstream: The first thread I found about this dates back to 2016, an user report followed by some approaches from Peter: https://lkml.org/lkml/2016/5/16/452 After that, seems the thread died, even with a functional patch, it wasn't "upstreamed". After about an year, another instance of the issue was observed by the powerpc community: https://lore.kernel.org/patchwork/patch/777639 The approach of powerpc guys wasn't the ideal, so Peter was asked to merge a new version of his patch, which ended-up being the candidate we've already considered in this LP. Despite merged, it was reverted after the following discussion: https://lkml.org/lkml/2017/3/20/95 Finally, a new approach seems to be near acceptance, from this year; it's in version 5, and I expect to see one more respin before the merge: https://marc.info/?l=linux-kernel&m=153722838802856 The patchset contains 7 patches, but the number #3 is the one that aims to fix our issue - I've commented there today in order to request some status, since it's just waiting a "cosmetic" change to get merged: https://marc.info/?l=linux-kernel&m=153842049510424 Worth to notice a similar approach than this last one from Dmitry was accepted to fix tty_init_dev() - that may not resolve the problem in this LP, but it's a fix and necessary as a dependency of Dmitry's patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b027e2298bd5 So, in summary, for this LP we need a patch that is not upstream yet (although it's near) plus a recent patch from January 2018. ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli) ** Description changed: [Impact] The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] ff
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Changed in: linux (Ubuntu) Milestone: trusty-updates => None ** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New ** Description changed: + [Impact] + The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 - [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 - [684766.669194] Oops: [#1] SMP + [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 + [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 - [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 + [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM - The Call Trace is similar with the one that is describe in this upstream patch + [Test Case] + + * Deploy a Trusty KVM instance with a LTS Xenial kernel (v4.4 series) + * SSH in frequently while system is under load, send commands before the prompt has returned. + + [Regression Potential] + + Low, the patch is found upstream since 4.12 (a year ago). + I
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Tags added: sts -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: Confirmed Bug description: The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM The Call Trace is similar with the one that is describe in this upstream patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Attachment added: "Call Trace from dmesg" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+attachment/5187255/+files/DMESG_CALL_TRACE.log -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: Confirmed Bug description: The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM The Call Trace is similar with the one that is describe in this upstream patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : http
[Kernel-packages] [Bug 1791758] Re: ldisc crash on reopened tty
** Attachment added: ""bt" and "bt -l" from Kernel crashdump" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+attachment/5187256/+files/CRASH_BT.log ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1791758 Title: ldisc crash on reopened tty Status in linux package in Ubuntu: Confirmed Bug description: The following Oops was discovered by user: [684766.39] BUG: unable to handle kernel paging request at 2268 [684766.667642] IP: [] n_tty_receive_buf_common+0x6a/0xae0 [684766.668487] PGD 8019574fe067 PUD 19574ff067 PMD 0 [684766.669194] Oops: [#1] SMP [684766.669687] Modules linked in: xt_nat dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag xt_connmark ipt_REJECT nf_reject_ipv4 nf_conntrack_netlink nfnetlink veth ip6table_filter ip6_tables xt_tcpmss xt_multiport xt_conntrack iptable_filter xt_CHECKSUM xt_tcpudp iptable_mangle xt_CT iptable_raw ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat ip_tables x_tables target_core_mod configfs softdog scini(POE) ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi openvswitch(OE) nf_nat_ipv6 nf_nat_ipv4 nf_nat gre kvm_intel kvm irqbypass ttm crct10dif_pclmul drm_kms_helper crc32_pclmul ghash_clmulni_intel drm aesni_intel aes_x86_64 i2c_piix4 lrw gf128mul fb_sys_fops syscopyarea glue_helper sysfillrect ablk_helper cryptd sysimgblt joydev [684766.679406] input_leds mac_hid serio_raw 8250_fintek br_netfilter bridge stp llc nf_conntrack_proto_gre nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack xfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 psmouse multipath floppy pata_acpi linear dm_multipath [684766.683585] CPU: 15 PID: 7470 Comm: kworker/u40:1 Tainted: P OE 4.4.0-124-generic #148~14.04.1-Ubuntu [684766.684967] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [684766.686062] Workqueue: events_unbound flush_to_ldisc [684766.686703] task: 88165e5d8000 ti: 88170dc2c000 task.ti: 88170dc2c000 [684766.687670] RIP: 0010:[] [] n_tty_receive_buf_common+0x6a/0xae0 [684766.688870] RSP: 0018:88170dc2fd28 EFLAGS: 00010202 [684766.689521] RAX: RBX: 88162c895000 RCX: 0001 [684766.690488] RDX: RSI: 88162c895020 RDI: 8819c2d3d4d8 [684766.691518] RBP: 88170dc2fdc0 R08: 0001 R09: 81ec2ba0 [684766.692480] R10: 0004 R11: R12: 8819c2d3d400 [684766.693423] R13: 8819c45b2670 R14: 8816a358c028 R15: 8819c2d3d400 [684766.694390] FS: () GS:8819d73c() knlGS: [684766.695484] CS: 0010 DS: ES: CR0: 80050033 [684766.696182] CR2: 2268 CR3: 00195752 CR4: 00360670 [684766.697141] DR0: DR1: DR2: [684766.698114] DR3: DR6: fffe0ff0 DR7: 0400 [684766.699079] Stack: [684766.699412] 8819c2d3d4d8 8819c2d3d648 [684766.700467] 8819c2d3d620 8819c9c10400 88170dc2fd68 8106312e [684766.701501] 88170dc2fd78 0001 88162c895020 [684766.702534] Call Trace: [684766.702905] [] ? kvm_sched_clock_read+0x1e/0x30 [684766.703685] [] n_tty_receive_buf2+0x14/0x20 [684766.704505] [] flush_to_ldisc+0xd5/0x120 [684766.705269] [] process_one_work+0x156/0x400 [684766.706008] [] worker_thread+0x11a/0x480 [684766.706686] [] ? rescuer_thread+0x310/0x310 [684766.707386] [] kthread+0xd8/0xf0 [684766.707993] [] ? kthread_park+0x60/0x60 [684766.708664] [] ret_from_fork+0x55/0x80 [684766.709335] [] ? kthread_park+0x60/0x60 [684766.709998] Code: 85 70 ff ff ff e8 97 5f 33 00 49 8d 87 20 02 00 00 c7 45 b4 00 00 00 00 48 89 45 88 49 8d 87 48 02 00 00 48 89 45 80 48 8b 45 b8 <48> 8b b0 68 22 00 00 48 8b 08 89 f0 29 c8 41 f6 87 30 01 00 00 [684766.713290] RIP [] n_tty_receive_buf_common+0x6a/0xae0 [684766.714105] RSP [684766.714609] CR2: 2268 The issue happened in a VM KDUMP was configured, so a full Kernel crashdump was created User has Ubuntu Trusty, Kernel 4.4.0-124 on its VM The Call Trace is similar with the one that is describe in this upstream patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791758/+subscriptions -- Mailing list: https://launchpad.net/~kerne
