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.r...@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.an...@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


_______________________________________________


_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Reply via email to