[oi-dev] Panic on using fuse with todays "pkg update"

[Jean-Pierre André]

Gordon Ross wrote on 9/13/22 1:01 AM:
> Or improve its portability (does it really need to look inside proc_t?)

This is only needed to get the pid of the current process, through
"curproc->p_pidp->pid_id", with curproc defined as threadp()->t_procp
The pid is passed to user level so that it can determine the credentials
of the caller (e.g. the list of groups to which it belongs).

A reasonable way is to define a curpid() system function (not a macro
nor an inliner), similar to vn_is_opened() or vn_has_other_opens()
which are used to hide the locations of v_rdcnt and v_wrcnt located
in struct vnode beyond the immutable locations.

There would also be other fields to consider, in particular p_rctls
from struct proc.

Jean-Pierre


> 
> On Mon, Sep 12, 2022 at 7:00 PM Gordon Ross <gordon.w.ross at gmail.com> wrote:
>>
>> We could integrate fuse into illumos to avoid that kind of thing.
>>
>> On Mon, Sep 12, 2022 at 5:02 AM Jean-Pierre André
>> <jean-pierre.andre at wanadoo.fr> wrote:
>>>
>>> IMHO this is the culprit :
>>>
>>> --- ../oi-include/sys/thread.h  2020-11-19 19:37:31.170054900 +0100
>>> +++ thread.h.2  2022-09-12 10:48:43.877644300 +0200
>>> @@ -158,7 +158,6 @@
>>>           struct _kthread *t_intr; /* interrupted (pinned) thread */
>>>           uint64_t        t_intr_start;   /* timestamp when time slice
>>> began */
>>>           kt_did_t        t_did;  /* thread id for kernel debuggers */
>>> -       caddr_t t_tnf_tpdp;     /* Trace facility data pointer */
>>>           struct _kcpc_ctx *t_cpc_ctx;    /* performance counter context */
>>>           struct _kcpc_set *t_cpc_set;    /* set this thread has bound */
>>>
>>> Which changes the location of t_procp a few lines below in
>>> struct _kthread
>>>
>>> So have to recompile and set dependency for this to not occur again.
>>>
>>> Jean-Pierre
>>>
>>>
>>> Jean-Pierre André wrote on 9/12/22 8:56 AM:
>>>> This is accessing t_procp->p_pidp, so it looks very much like the
>>>> kernel has been recompiled after <sys/thread.h> or <sys/proc.h>
>>>> have been changed, without the fuse kernel module being recompiled
>>>> (or at least being downloaded).
>>>>
>>>> You probably only need to recompile with current headers and download.
>>>>
>>>> This has already occurred before. Where is the dependency preventing
>>>> this from occurring missing ?
>>>>
>>>> Jean-Pierre
>>>>
>>>> Stephan Althaus wrote on 9/11/22 10:13 PM:
>>>>> Hello!
>>>>>
>>>>> I made a pkg update today, and was surprised to get a panic on using
>>>>> my fuse file system "exfat" on USB3, which i use for 1-2 years now.
>>>>>
>>>>> Maybe some illumos patch is causing this (?)
>>>>>
>>>>> I have build the exfat bits on the new BE, to no success..
>>>>>
>>>>>
>>>>> $ fmdump -Vp -u a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>> TIME UUID                                 SUNW-MSG-ID
>>>>> Sep 11 2022 19:52:06.085966000 a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>> SUNOS-8000-KL
>>>>>
>>>>>     TIME                 CLASS                                 ENA
>>>>>     Sep 11 19:52:04.1840 ireport.os.sunos.panic.savecore_failure
>>>>> 0x0000000000000000
>>>>>     Sep 11 19:52:03.9741 ireport.os.sunos.panic.dump_pending_on_device
>>>>> 0x0000000000000000
>>>>>
>>>>> nvlist version: 0
>>>>>           version = 0x0
>>>>>           class = list.suspect
>>>>>           uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>>           code = SUNOS-8000-KL
>>>>>           diag-time = 1662918725 999156
>>>>>           de = fmd:///module/software-diagnosis
>>>>>           fault-list-sz = 0x1
>>>>>           fault-list = (array of embedded nvlists)
>>>>>           (start fault-list[0])
>>>>>           nvlist version: 0
>>>>>                   version = 0x0
>>>>>                   class = defect.sunos.kernel.panic
>>>>>                   certainty = 0x64
>>>>>                   asru =
>>>>> sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>>                   resource =
>>>>> sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>>                   savecore-succcess = 0
>>>>>                   failure-reason = pwrite: No such device or address
>>>>>                   os-instance-uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
>>>>>                   panicstr = BAD TRAP: type=e (#pf Page fault)
>>>>> rp=fffffe003d79e850 addr=4 occurred in module "fuse" due to a NULL
>>>>> pointer dereference
>>>>>                   panicstack = unix:die+c6 () | unix:trap+10f7 () |
>>>>> unix:cmntrap+e9 () | fuse:get_filehandle+52d () | fuse:fuse_open+6e ()
>>>>> | genunix:fop_open+96 () | genunix:vn_openat+20c () |
>>>>> genunix:copen+421 () | genunix:openat+29 () |
>>>>> unix:brand_sys_syscall+1fe () |
>>>>>                   crashtime = 1662918635
>>>>>                   panic-time = 11 September 2022 at 19:50:35 CEST CEST
>>>>>           (end fault-list[0])
>>>>>
>>>>>           fault-status = 0x1
>>>>>           severity = Major
>>>>>           __ttl = 0x1
>>>>>           __tod = 0x631e2046 0x51fbcb0
>>>>>
>>>>> Greetings,
>>>>>
>>>>> Stephan
>>>>>
>>>>>
>>>>> _______________________________________________