From nobody Tue May 07 08:50:40 2024 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VYX6v2B7Rz5KP3N for ; Tue, 07 May 2024 08:50:47 +0000 (UTC) (envelope-from fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com) Received: from mta-65-227.siemens.flowmailer.net (mta-65-227.siemens.flowmailer.net [185.136.65.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VYX6s5MZwz4YQ6 for ; Tue, 7 May 2024 08:50:45 +0000 (UTC) (envelope-from fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=siemens.com header.s=fm1 header.b=LpI1EbZG; dmarc=pass (policy=reject) header.from=siemens.com; spf=pass (mx1.freebsd.org: domain of fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com designates 185.136.65.227 as permitted sender) smtp.mailfrom=fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com Received: by mta-65-227.siemens.flowmailer.net with ESMTPSA id 20240507085041870aa12ab8a268ea44 for ; Tue, 07 May 2024 10:50:41 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=Andre.Albsmeier@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Cc:References:In-Reply-To; bh=294Jl75DksMqCWvRQ4cnd7eiKxkxhyNeKtFa1xtB778=; b=LpI1EbZGpGuqXr71/cgFS5TagTRibblA+EKzebR3HRiOs7L/3YWw1LxAx4ZVgKVdjq8Fqq mTU1RxswQBL9nXrvR0Tkz0c10gZsAdUo/Qs5+Cz9OIgN+kTNIT9GwOCcdOS79/FUJZ0/JAG+ gAAo54x0GRNuAbYr49DoaDYFoDTKw=; Date: Tue, 7 May 2024 10:50:40 +0200 From: Andre Albsmeier To: stable@freebsd.org Cc: Andre.Albsmeier@siemens.com Subject: Re: 14-STABLE crashes when using geli from automountd executable maps Message-ID: References: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: document_confidentiality: Restricted X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-134872:519-21489:flowmailer X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.90 / 15.00]; DWL_DNSWL_MED(-2.00)[siemens.com:dkim]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[siemens.com,reject]; FORGED_SENDER(0.30)[Andre.Albsmeier@siemens.com,fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com]; R_DKIM_ALLOW(-0.20)[siemens.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:185.136.65.224/29]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.136.65.227:from]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:50018, ipnet:185.136.65.0/24, country:NL]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; MISSING_XM_UA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[stable@freebsd.org]; FROM_NEQ_ENVFROM(0.00)[Andre.Albsmeier@siemens.com,fm-134872-20240507085041870aa12ab8a268ea44-P51eKT@rts-flowmailer.siemens.com]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[siemens.com:+] X-Rspamd-Queue-Id: 4VYX6s5MZwz4YQ6 Replying to myself (just for the records)... I have digged further into this: It has nothing to do with autofs -- autofs only reveals the problem since g_eli_ctl_attach() is called (again!) during the ls (which does the mount actually). The problem appears if we call g_eli_ctl_attach() twice. For details see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278828 On Sun, 05-May-2024 at 19:10:58 +0200, Andre Albsmeier wrote: > Before opening a PR, let's see if I'm doing something bad here (shouldn't > be that bad as it worked on FreeBSD-12 :-)). > > I can reliably crash 14-STABLE by running "geli attach" from an automountd > executable map if > > a) there is no other geli device in use > b) the mount is done r/w. > > To reproduce: > > 0. Prerequisite: > ---------------- > > We assume there is a working autofs environment and /etc/auto_master is the > master map. The must be no geli device in use. > > > 1. Do this once: > ---------------- > > cat << EOF > /etc/autocrash > #!/bin/sh > > case "x\$1" in > > xno_geli) > exec echo "-fstype=ufs,noatime,async :/dev/md0.eli" > ;; > > xgeli_ro) > geli attach -k /bin/ls -p /dev/md0 > exec echo "-fstype=ufs,noatime,async,ro :/dev/md0.eli" > ;; > > xgeli_rw) > geli attach -k /bin/ls -p /dev/md0 > exec echo "-fstype=ufs,noatime,async :/dev/md0.eli" > ;; > > esac > EOF > > chmod 755 /etc/autocrash > > echo "/autocrash autocrash" >> /etc/auto_master > > automount > > > 2. Do this each time you want to crash the box: > ----------------------------------------------- > > kldload geom_eli.ko > > dd if=/dev/zero of=/tmp/testcrash bs=64k count=160 > mdconfig -a -t vnode -f /tmp/testcrash > geli init -P -K /bin/ls /dev/md0 > geli attach -k /bin/ls -p /dev/md0 > newfs /dev/md0.eli > > # this works w/o crashing (as md0.eli is still attached) > cd /autocrash/no_geli ; ls -la > cd / && umount /autocrash/no_geli > geli detach /dev/md0 > > # crash it: > cd /autocrash/geli_rw > ls -la > > # this also works w/o crashing (as we mount it readonly) > cd /autocrash/geli_ro ; ls -la > cd / && umount /autocrash/geli_ro > geli detach /dev/md0 > > > > For some reasons, the box crashes when "geli attach" is executed from within > the /etc/autocrash script. It does not crash when we attach it before and do > only the mount from /etc/autocrash. It also does not crash if there is at > least one more geli device in use. > > Debugging the crash gives us this: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x218 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8071a20a > stack pointer = 0x28:0xfffffe00743d5da0 > frame pointer = 0x28:0xfffffe00743d5dd0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1246 (g_eli[1] md0) > rdi: 0000000000000000 rsi: 0000000000000200 rdx: 0000000000000001 > rcx: 0000000000000080 r8: 0000000000000001 r9: 0000000000010000 > rax: fffff80006da5000 rbx: fffff800063904b0 rbp: fffffe00743d5dd0 > r10: 0000000000000001 r11: 0000000000010000 r12: 0000000000000200 > r13: 0000000000000008 r14: 0000000000000000 r15: 0000000000000000 > trap number = 12 > panic: page fault > cpuid = 1 > time = 1714666291 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00743d5b80 > vpanic() at vpanic+0xfa/frame 0xfffffe00743d5bb0 > panic() at panic+0x43/frame 0xfffffe00743d5c10 > trap_fatal() at trap_fatal+0x40c/frame 0xfffffe00743d5c70 > trap_pfault() at trap_pfault+0xab/frame 0xfffffe00743d5cd0 > calltrap() at calltrap+0x8/frame 0xfffffe00743d5cd0 > --- trap 0xc, rip = 0xffffffff8071a20a, rsp = 0xfffffe00743d5da0, rbp = 0xfffffe00743d5dd0 --- > uma_zalloc_arg() at uma_zalloc_arg+0x3a/frame 0xfffffe00743d5dd0 > g_eli_alloc_data() at g_eli_alloc_data+0x49/frame 0xfffffe00743d5df0 > g_eli_crypto_run() at g_eli_crypto_run+0x97/frame 0xfffffe00743d5e90 > g_eli_worker() at g_eli_worker+0x369/frame 0xfffffe00743d5ef0 > fork_exit() at fork_exit+0x82/frame 0xfffffe00743d5f30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00743d5f30 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > Uptime: 31s > Dumping 212 out of 3438 MB:..8%..16%..23%..31%..46%..53%..61%..76%..83%..91 > __curthread () at /src/src-14/sys/amd64/include/pcpu_aux.h:57 > 57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, > (kgdb) where > #0 __curthread () at /src/src-14/sys/amd64/include/pcpu_aux.h:57 > #1 doadump (textdump=textdump@entry=1) at /src/src-14/sys/kern/kern_shutdown.c:405 > #2 0xffffffff804f4e40 in kern_reboot (howto=260) at /src/src-14/sys/kern/kern_shutdown.c:523 > #3 0xffffffff804f5307 in vpanic (fmt=0xffffffff8081968d "%s", ap=ap@entry=0xfffffe00743d5bf0) at /src/src-14/sys/kern/kern_shutdown.c:967 > #4 0xffffffff804f50e3 in panic (fmt=) at /src/src-14/sys/kern/kern_shutdown.c:891 > #5 0xffffffff807b0d7c in trap_fatal (frame=0xfffffe00743d5ce0, eva=536) at /src/src-14/sys/amd64/amd64/trap.c:952 > #6 0xffffffff807b0e2b in trap_pfault (frame=0xfffffe00743d5ce0, usermode=false, signo=, ucode=0x0) > at /src/src-14/sys/amd64/amd64/trap.c:760 > #7 > #8 uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0, flags=1) at /src/src-14/sys/vm/uma_core.c:3738 > #9 0xffffffff8045a7b9 in uma_zalloc (zone=0x0, zone@entry=0xfffff800063904b0, flags=1) at /src/src-14/sys/vm/uma.h:367 > #10 g_eli_alloc_data (bp=bp@entry=0xfffff800063904b0, sz=4096) at /src/src-14/sys/geom/eli/g_eli.c:958 > #11 0xffffffff80463c27 in g_eli_crypto_run (wr=wr@entry=0xfffff800068c4880, bp=bp@entry=0xfffff800063904b0) > at /src/src-14/sys/geom/eli/g_eli_privacy.c:282 > #12 0xffffffff8045c6a9 in g_eli_worker (arg=arg@entry=0xfffff800068c4880) at /src/src-14/sys/geom/eli/g_eli.c:752 > #13 0xffffffff804b6b02 in fork_exit (callout=0xffffffff8045c340 , arg=0xfffff800068c4880, frame=0xfffffe00743d5f40) > at /src/src-14/sys/kern/kern_fork.c:1159 > #14 > (kgdb) up 10 > #10 g_eli_alloc_data (bp=bp@entry=0xfffff800063904b0, sz=4096) at /src/src-14/sys/geom/eli/g_eli.c:958 > 958 bp->bio_driver2 = uma_zalloc(g_eli_uma, M_NOWAIT | > (kgdb) p g_eli_uma > $1 = (uma_zone_t) 0x0 > (kgdb) > > g_eli_uma being NULL is probably wrong. Probably it got free'ed but shouldn't > or some initialisation is missing. But why is it NULL when called from > /etc/autocrash and not when run manually or if another geli device already > exists?