From nobody Fri Dec 30 19:47:54 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 4NkG5Q0GdQz2lRbf for ; Fri, 30 Dec 2022 19:48:10 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 4NkG5P5K09z3R36 for ; Fri, 30 Dec 2022 19:48:09 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x534.google.com with SMTP id z11so15748775ede.1 for ; Fri, 30 Dec 2022 11:48:09 -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=V0UcoQlzaWhXOzuJXgjcrBKDIe6KJMRokzKTqNKa4Ts=; b=m3A5jzOruRAUpxWrO7u09K5HOSWGqtb17ZBNqb4jHavBtIzvJcFBg5ev7SoaZ0Gq15 8KhBSTVqyp+eVLq35HPD4YrkSAO1rHZ3p0cc9Jl1SS1owQMJgsLa75+N5yJ8Mb97gho8 oOopvrBZnRwkmk8SBU7FMGgdmfd2qQPAO2zS5fVWHuRpBIjpgcFel82a3JKv76RWUE8k QrAESibChuJibFV3gP01Y3k2O8FMs815SgMzqMTy5KI6hc5e0jcdP90TEbbT+lzmxkN1 L+nPO0s8gkBl6aA43nd+pMxxJ+d7kah4oMgc5yhys++L6umNLwxDbEqDZUERe6LL2qBV 7mdA== 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=V0UcoQlzaWhXOzuJXgjcrBKDIe6KJMRokzKTqNKa4Ts=; b=rWa2qrpc89AFDKYZrbPni5AnAvMU6w+eaTinl8ZgQ0igr0otev1kL9uin1p38aUK2y wH0ZkmlARkP5tSNfx/HjAUtyXOf0QBXX+oJg3pJVp/K98DUdHUNj+OgovOyvz6cnDd5r RCmnQrwDWJxlHzWgdyaA5D/Mv7rt8XFgrg48EmKjXOYtkXnb8yxuLjfHw6oXdWitUAZS ieC0P772ckNdYG65MI01nc7/KPwsDPser1FnTB9LXsUrK4M3JYgqvJP6TLXgyI0CvpZC BkMsMSKvLM2OdyzalS3QjGZ2pR3gte7hUabQhxTYBX/vai+TDenaRR7TkoH4M4/bB8Jx hGxw== X-Gm-Message-State: AFqh2kouhIwn9g7IVD48fC+NRunWKSFXYCttxq7jcBNTTE3swaQR2/hf /gyVDsb5m5T0zSOfPyFI3OI6h+uD+ZqgIttqGZ8= X-Google-Smtp-Source: AMrXdXshb0cIDZ4ubnn/0MWitR+TKWF2sd6jd2uvm+m8gdujzrG6K5dokmYobi7e6K0WkAwelgZP6+hHDPh8l3zVbns= X-Received: by 2002:a05:6402:2a04:b0:46c:6707:1036 with SMTP id ey4-20020a0564022a0400b0046c67071036mr3185945edb.308.1672429686257; Fri, 30 Dec 2022 11:48:06 -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: <23A1E4DF-320A-4BCB-ADB8-83FEFC3D7649@mit.edu> From: Rob Wing Date: Fri, 30 Dec 2022 10:47:54 -0900 Message-ID: Subject: Re: Trying to implement BFS, page fault at vfs_domount_first, how to debug? To: John F Carr Cc: Hikmat Jafarli , "freebsd-fs@freebsd.org" Content-Type: multipart/alternative; boundary="0000000000005c7ce405f110e1db" X-Rspamd-Queue-Id: 4NkG5P5K09z3R36 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000005c7ce405f110e1db Content-Type: text/plain; charset="UTF-8" you might try `addr2line -e $path_to_kernel 0xffffffff80cf0651` 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. > > > > --0000000000005c7ce405f110e1db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
you might try `addr2line -e $path_to_kernel 0xfffffff= f80cf0651`

Aside from that, it looks like errors a= ren't being handled correctly after failing to find the BFS superblock = in bfs_mountfs(). Since no error is returned after failing to find the supe= rblock..I'm guessing that the NULL pointer `bfsmp` is being de-referenc= ed in bfs_statfs().

On Fri, Dec 30, 2022 at 10:35 AM John F Carr <<= a href=3D"mailto:jfc@mit.edu">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.



--0000000000005c7ce405f110e1db--