Re: r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink
On Wed, Nov 28, 2018 at 12:54:21AM +0300, Vladimir Kondratyev wrote:
> Following test case triggers assertion after r340343:
>
>
> #include
>
> int
> main(int argc, char **argv)
> {
> openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
> }
>
> It results in:
>
> panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
> /usr/src/sys/kern/vfs_lookup.c:182
>
The following should fix it. Problem was that the topping directory was
only latched when the initial path was absolute. Since your example
switched from the relative argument to the absolute symlink, the BENEATH
tracker rightfully complained that there were no recorded top.
I also added some asserts I used during the debugging.
diff --git a/sys/kern/vfs_lookup.c b/sys/kern/vfs_lookup.c
index 78893c4f2bd..7a80775d91d 100644
--- a/sys/kern/vfs_lookup.c
+++ b/sys/kern/vfs_lookup.c
@@ -202,8 +202,10 @@ nameicap_cleanup(struct nameidata *ndp, bool clean_latch)
vdrop(nt->dp);
uma_zfree(nt_zone, nt);
}
- if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0)
+ if (clean_latch && (ndp->ni_lcf & NI_LCF_LATCH) != 0) {
+ ndp->ni_lcf &= ~NI_LCF_LATCH;
vrele(ndp->ni_beneath_latch);
+ }
}
/*
@@ -264,6 +266,7 @@ namei_handle_root(struct nameidata *ndp, struct vnode **dpp)
return (ENOTCAPABLE);
}
if ((cnp->cn_flags & BENEATH) != 0) {
+ MPASS((ndp->ni_lcf & NI_LCF_LATCH) != 0);
ndp->ni_lcf |= NI_LCF_BENEATH_ABS;
ndp->ni_lcf &= ~NI_LCF_BENEATH_LATCHED;
nameicap_cleanup(ndp, false);
@@ -446,7 +449,7 @@ namei(struct nameidata *ndp)
if (error == 0 && dp->v_type != VDIR)
error = ENOTDIR;
}
- if (error == 0 && (ndp->ni_lcf & NI_LCF_BENEATH_ABS) != 0) {
+ if (error == 0 && (cnp->cn_flags & BENEATH) != 0) {
if (ndp->ni_dirfd == AT_FDCWD) {
ndp->ni_beneath_latch = fdp->fd_cdir;
vrefact(ndp->ni_beneath_latch);
@@ -471,6 +474,8 @@ namei(struct nameidata *ndp)
vrele(dp);
goto out;
}
+ MPASS((ndp->ni_lcf & (NI_LCF_BENEATH_ABS | NI_LCF_LATCH)) !=
+ NI_LCF_BENEATH_ABS);
if (((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) != 0 &&
lookup_cap_dotdot != 0) ||
((ndp->ni_lcf & NI_LCF_STRICTRELATIVE) == 0 &&
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink
Following test case triggers assertion after r340343:
#include
int
main(int argc, char **argv)
{
openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
}
It results in:
panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
/usr/src/sys/kern/vfs_lookup.c:182
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm kmod kernel panic
On 11/27/18 1:36 PM, Ruslan Makhmatkhanov wrote: swap_pager_getswapspace(19): failed swap_pager_getswapspace(12): failed Is the system running low on memory? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
drm kmod kernel panic
Hello, I'm getting this panic every time trying to build rust in poudriere. Until the recent time I was able to build rust successfully on 13-CURRENT, but now I'm getting out of space and the panic. My system is 13.0-CURRENT r340723 amd64. It's on laptop with i5 GPU (2nd Generation) and 12GB RAM. Any suggestions what I can do with that? smsh-zfs% pkg info | grep drm drm-devel-kmod-4.16.g20181119 DRM modules for the linuxkpi-based KMS components (development version) drm-kmod-g20180930 Metaport of DRM modules for the linuxkpi-based KMS components from dmesg: swap_pager_getswapspace(19): failed swap_pager_getswapspace(12): failed WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:577 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:577 WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:622 WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:622 WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex)) WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-devel-kmod/work/kms-drm-5f3b167/drivers/gpu/drm/drm_atomic_helper.c:821 WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex))WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex))WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex))WARN_ON(!drm_modeset_is_locked(>dev->mode_config.connection_mutex))WARN_ON(!mutex_is_locked(>struct_mutex))WARN_ON(!mutex_is_locked(>struct_mutex)) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor write data, page not present instruction pointer = 0x20:0x80bad254 stack pointer = 0x28:0xfe59ccd0 frame pointer = 0x28:0xfe59cd00 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= resume, IOPL = 0 current process = 24 (laundry: dom0) trap number = 12 panic: page fault cpuid = 0 time = 1543321280 KDB: stack backtrace: #0 0x80ba05f7 at kdb_backtrace+0x67 #1 0x80b5ab83 at vpanic+0x1a3 #2 0x80b5a9d3 at panic+0x43 #3 0x80ff66ff at trap_fatal+0x35f #4 0x80ff6759 at trap_pfault+0x49 #5 0x80ff5e13 at trap+0x2a3 #6 0x80fd1f67 at calltrap+0x8 #7 0x829e1905 at linux_add_to_sleepqueue+0x35 #8 0x829e1779 at linux_wait_event_common+0x109 #9 0x8299f9cf at drm_wait_one_vblank+0x22f #10 0x82891f97 at ironlake_crtc_enable+0xe17 #11 0x8289d294 at intel_update_crtc+0x94 #12 0x82896615 at intel_update_crtcs+0x55 #13 0x828a17c4 at intel_atomic_commit_tail+0x724 #14 0x8289ecfc at intel_atomic_commit+0x2cc #15 0x82980566 at restore_fbdev_mode_atomic+0x1b6 #16 0x8297c83e at drm_fb_helper_restore_fbdev_mode_unlocked+0x7e #17 0x829a2205 at vt_kms_postswitch+0x125 Uptime: 4h43m45s I also have this in dmesg. It may be related to my experiments with suspend/resume in recent past: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19). __pm_runtime_resume not implemented -- see your local kernel hacker Failed to add WC MTRR for [0xb000-0xbfff]: -22; performance may suffer [drm] Got stolen memory base 0xada0, size 0x200 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] Connector LVDS-1: get mode from tunables: [drm] - kern.vt.fb.modes.LVDS-1 [drm] - kern.vt.fb.default_mode pm_runtime_mark_last_busy not implemented -- see your local kernel hacker __pm_runtime_suspend not implemented --
Re: ACPI Error: No handler for Region [ECOR]
In message <10399.1543270...@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >>I'm seeing it on my ThinkPad x230 as well > >and on T480 running 13.0-CURRENT r340932M as well: And seems to be gone with this kernel: 13.0-CURRENT r341006M Havn't tried the ones in between. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
