On Wed, 23 Jul 2025 11:04:02 +0200 Corinna Vinschen wrote: > On Jul 22 21:32, Takashi Yano wrote: > > Previously, process_fd did not handle fhandler using archetype > > correctly. Due to lack of PC_OPEN flag for path_conv, build_fh_pc() > > could not initialize archetype. Because of this bug, accessing pty > > or console via process_fd fails. > > > > With this patch, use build_fh_name() with PC_OPEN flag instead of > > build_fh_pc() to set PC_OPEN flag to path_conv. > > Your patch fixes the issue, ok, but I don't understand why this occurs. > > If the process opens /proc/PID/fd/N with PID != MYPID, it uses the > PICOM_FILE_PATHCONV commune request. It copies the path_conv member > of the fd from the target process and this pc is used in the > build_fh_pc() call. > > And here's what I don't get: If the pc has been fetched from a valid, > open file descriptor in the target process, why is the PATH_OPEN > flag not set?
Thanks for reviewing. I looked into open process, and noticed that this is because fh_alloc() called from build_fh_name() does not copy argument pc.path_flags to fh->pc.path_flags. -- Takashi Yano <takashi.y...@nifty.ne.jp>
