From nobody Fri Dec 30 22:06:38 2022 X-Original-To: freebsd-fs@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 4NkK9Q3V38z2nV43 for ; Fri, 30 Dec 2022 22:06:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NkK9P0ssWz3qQm for ; Fri, 30 Dec 2022 22:06:49 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=kZOHwann; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pg1-x530.google.com with SMTP id w37so14918680pga.5 for ; Fri, 30 Dec 2022 14:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WfyQj0d2/UKUWgwGKb/WRUBrZfGUg0GUNlYPyR3do6g=; b=kZOHwannOlB17w3a+cXJ301jfTDycAM+EfE5TfRnkXt31CRn5EwUR+z/1k/ooZT5dG DEHaM5YmAGszEmJPiwS6v34eueLEbUJcCCvmbfRf6HLO549sQ3zNNZ1/nkOXglMXVK2X OLyk/1jcH8b2WSMajyXivIg0/HD1PvNizBu+rXFMfJAZPdsyENO55dwp5pSqhP/v55y3 +S6Oapl43DLjxCqDYzXVeTEWNf1m8RpIQTQOP/v4sF0l1BkGJfVyxrCp/s9/aSRsgUji dejFlU5d+6lNJMAu6/HcRUwiEGhSJutbnzGn31sTjqzJDkljFAhn/RJyjSW0BXYxM+QS yyfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WfyQj0d2/UKUWgwGKb/WRUBrZfGUg0GUNlYPyR3do6g=; b=YD54E6jQxHL12caYWl01nYHdRpHGFLsL1TaqgF/SoV7bXLRRfysSDVZASFcvEoyK3t 5Gc9Xji2cmbe93whAtzCrtA1H8cDgvnhrjN6N8E9UHDtlTie61Ev/zii39BIo5HPgJ9B gYtB/TNGWTUdrRwIGUQwmUQ/h1RLT8l4/cbXK/cmO/h3QgsGBPhXTOZEyWH2W+jbLASK q9E8es5Ckutv7hM05kohlqkP6N7MwiNDaHKv8ezbcmJHm7w5TckT43W4aVjg/Z7Q8z0h /oC0pNlAHMDUQG2+yVtLhbihReD5hAq/xmmhJ95BnN604nqIgffGTSfLe7h5Y2AOsFIk 0MBA== X-Gm-Message-State: AFqh2kre6Tut4Dj5gX8VfVED8fFFvVbukIC1e08/k532TkYigr/jXEfG QahofuS8KOcVdE7e6c3HMwpUVQ6gZxnNDF3jQw== X-Google-Smtp-Source: AMrXdXt5ZJR7hl+YTO5MRlukp3JB4ogIl7iPByzqo4u2f+YGaEkU3lwW5wW4ryp43xzfrCZ9k/2YNpF01ZMuVF0Tmrg= X-Received: by 2002:a05:6a00:4108:b0:581:e84d:c2b6 with SMTP id bu8-20020a056a00410800b00581e84dc2b6mr337854pfb.39.1672438007546; Fri, 30 Dec 2022 14:06:47 -0800 (PST) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: <23A1E4DF-320A-4BCB-ADB8-83FEFC3D7649@mit.edu> In-Reply-To: From: Rick Macklem Date: Fri, 30 Dec 2022 14:06:38 -0800 Message-ID: Subject: Re: Trying to implement BFS, page fault at vfs_domount_first, how to debug? To: Rob Wing Cc: John F Carr , Hikmat Jafarli , "freebsd-fs@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000059449005f112d1f8" X-Spamd-Result: default: False [-1.50 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_COUNT_TWO(0.00)[2]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; TAGGED_RCPT(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::530:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_CC(0.00)[mit.edu,gmail.com,freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_DN_EQ_ADDR_SOME(0.00)[] X-Rspamd-Queue-Id: 4NkK9P0ssWz3qQm X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N --00000000000059449005f112d1f8 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 30, 2022 at 11:48 AM Rob Wing wrote: > you might try `addr2line -e $path_to_kernel 0xffffffff80cf0651` > Just a note. I find I need the kernel called "kernel.debug" for addr2line to work. It normally lives in the kernel build directory under /usr/obj. rick > > Aside from that, it looks like errors aren't being handled correctly after > failing to find the BFS superblock in bfs_mountfs(). Since no error is > returned after failing to find the superblock..I'm guessing that the NULL > pointer `bfsmp` is being de-referenced in bfs_statfs(). > > On Fri, Dec 30, 2022 at 10:35 AM John F Carr wrote: > >> >> >> > On Dec 30, 2022, at 14:13, Hikmat Jafarli wrote: >> > >> > I'm trying to implement the BeOS filesystem (BFS) for FreeBSD. >> > The repository is here: https://github.com/jafarlihi/freebsd-bfs >> > (Please don't mind bad styling and all the copy-paste work, >> > I'll polish it later, I'm just trying to get to some PoC where it works) >> > >> > Now when I try to mount a valid BFS partition (reported as BFS by >> `fstyp`) >> > it executes all the way to printf that logs "Either not a BFS volume or >> > corrupted" and then crashes with "page fault while in kernel mode" in >> > vfs_domount_first+0x271. Here's the log: >> > ``` >> > Either not a BFS volume or corrupted >> > >> > Fatal trap 12: page fault while in kernel mode >> > cpuid = 0; apic id = 00 >> > fault virtual address = 0x18 >> > fault code = supervisor read data, page not present >> > instruction pointer = 0x20:0xffffffff82b2427b >> > stack pointer = 0x28:0xfffffe00df399ac0 >> > frame pointer = 0x28:0xfffffe00df399ac0 >> > 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 = 1208 (mount) >> > trap number = 12 >> > panic: page fault >> > cpuid = 0 >> > time = 1672414952 >> > KDB: stack backtrace: >> > #0 0xffffffff80c694a5 at kdb_backtrace+0x65 >> > #1 0xffffffff80c1bb5f at vpanic+0x17f >> > #2 0xffffffff80c1b9d3 at panic+0x43 >> > #3 0xffffffff810afdf5 at trap_fatal+0x385 >> > #4 0xffffffff810afe4f at trap_pfault+0x4f >> > #5 0xffffffff810875b8 at calltrap+0x8 >> > #6 0xffffffff80cf0651 at vfs_domount_first+0x271 >> > #7 0xffffffff80cece9d at vfs_domount+0x2ad >> > #8 0xffffffff80cec2d8 at vfs_donmount+0x8f8 >> > #9 0xffffffff80ceb9a9 at sys_nmount+0x69 >> > #10 0xffffffff810b06ec at amd64_syscall+0x10c >> > #11 0xffffffff81087ecb at fast_syscall_common+0xf8 >> > ``` >> > >> > Now I'm trying to understand what exactly goes wrong here >> > and how to map 0x271 to the exact source line. >> > >> > I'd appreciate it if someone could tell me how to debug this. >> > >> > (Sorry for noob question, I already tried IRC and was directed here) >> >> Your BFS module tried to dereference a null pointer to structure. >> >> It's a null pointer dereference because of "fault virtual address = >> 0x18". That normally means you tried to access the fourth word of a >> structure but the pointer to structure was null. It could be something >> else, but play the odds. >> >> It's in your module because the instruction pointer address is far beyond >> the other kernel functions in the stack trace. Stack traces in crash >> reports are misleading: they tend to omit the function that triggered the >> crash. The address of vfs_domount_first is 0xffffffff80cf03e0 >> (0xffffffff80cf0651 - 0x271). That's the function that called your >> module. The address of the faulting instruction is 0xffffffff82b2427b. >> That's in your module. >> >> >> >> --00000000000059449005f112d1f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 30, 2022 at 11:48 AM Rob Wing <= ;rob.fx907@gmail.com> wrote:<= br>
you might try `addr2line -e $path_to_kernel 0xffffffff80cf0651`
=
Just a note. I find I need the kernel called "kernel.debug&= quot; for
addr2line to work. It normally lives in the kernel build dire= ctory
under /usr/obj.

rick
=C2=A0

<= div>Aside from that, it looks like errors aren't being handled correctl= y after failing to find the BFS superblock in bfs_mountfs(). Since no error= is returned after failing to find the superblock..I'm guessing that th= e NULL pointer `bfsmp` is being de-referenced in bfs_statfs().
<= br>
On Fri,= Dec 30, 2022 at 10:35 AM John F Carr <jfc@mit.edu> wrote:


> On Dec 30, 2022, at 14:13, Hikmat Jafarli <jafarlihi@gmail.com> wrote:
>
> I'm trying to implement the BeOS filesystem (BFS) for FreeBSD.
> The repository is here: https://github.com/jafarlihi/fr= eebsd-bfs
> (Please don't mind bad styling and all the copy-paste work,
> I'll polish it later, I'm just trying to get to some PoC where= it works)
>
> Now when I try to mount a valid BFS partition (reported as BFS by `fst= yp`)
> it executes all the way to printf that logs "Either not a BFS vol= ume or
> corrupted" and then crashes with "page fault while in kernel= mode" in
> vfs_domount_first+0x271. Here's the log:
> ```
> Either not a BFS volume or corrupted
>
> Fatal trap 12: page fault while in kernel mode
> cpuid =3D 0; apic id =3D 00
> fault virtual address =3D 0x18
> fault code =3D supervisor read data, page not present
> instruction pointer =3D 0x20:0xffffffff82b2427b
> stack pointer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xfffffe00df399ac0 > frame pointer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xfffffe00df399ac0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b
> =3D DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags =3D interrupt enabled, resume, IOPL =3D 0
> current process =3D 1208 (mount)
> trap number =3D 12
> panic: page fault
> cpuid =3D 0
> time =3D 1672414952
> KDB: stack backtrace:
> #0 0xffffffff80c694a5 at kdb_backtrace+0x65
> #1 0xffffffff80c1bb5f at vpanic+0x17f
> #2 0xffffffff80c1b9d3 at panic+0x43
> #3 0xffffffff810afdf5 at trap_fatal+0x385
> #4 0xffffffff810afe4f at trap_pfault+0x4f
> #5 0xffffffff810875b8 at calltrap+0x8
> #6 0xffffffff80cf0651 at vfs_domount_first+0x271
> #7 0xffffffff80cece9d at vfs_domount+0x2ad
> #8 0xffffffff80cec2d8 at vfs_donmount+0x8f8
> #9 0xffffffff80ceb9a9 at sys_nmount+0x69
> #10 0xffffffff810b06ec at amd64_syscall+0x10c
> #11 0xffffffff81087ecb at fast_syscall_common+0xf8
> ```
>
> Now I'm trying to understand what exactly goes wrong here
> and how to map 0x271 to the exact source line.
>
> I'd appreciate it if someone could tell me how to debug this.
>
> (Sorry for noob question, I already tried IRC and was directed here)
Your BFS module tried to dereference a null pointer to structure.

It's a null pointer dereference because of "fault virtual address = =3D 0x18".=C2=A0 That normally means you tried to access the fourth wo= rd of a structure but the pointer to structure was null.=C2=A0 It could be = something else, but play the odds.

It's in your module because the instruction pointer address is far beyo= nd the other kernel functions in the stack trace.=C2=A0 Stack traces in cra= sh reports are misleading: they tend to omit the function that triggered th= e crash.=C2=A0 The address of vfs_domount_first is 0xffffffff80cf03e0 (0xff= ffffff80cf0651 - 0x271).=C2=A0 That's the function that called your mod= ule.=C2=A0 The address of the faulting instruction is 0xffffffff82b2427b.= =C2=A0 That's in your module.



--00000000000059449005f112d1f8--