Re: procfs files vs symlink
On Wed, 12 Jan 2022, Robert Elz wrote: | > What causes that EINVAL? | | | I'm not sure (somneone suggested that the file descriptor has been closed | when ls tries to fstat() it, but I can't confirm this). That should generate EBADF not EINVAL. Attempting readlink() on something that is not a symlink, and various other possibilities like that would be more probable. EINVAL isn't listed as a possible error return from [f]stat ... not that that guarantees that it cannot happen, particularly from within emulation code. That someone is me. But, your're right about this. The EINVAL is caused by using readlink() on what was a symlink, but, is not anymore because the fd now points to a regular file. ktrace ls -l /proc/self/fd 1954 1954 ls CALL open(0x7d9270fdc000,0x64,3) 1954 1954 ls NAMI "/proc/self/fd" 1954 1954 ls RET open 4 1954 1954 ls CALL fchdir(4) 1954 1954 ls CALL __getdents30(4,0x7d9270fa6000,0x1000) 1954 1954 ls CALL __lstat50(0x7d9270fd12f0,0x7d9270fd12f8) 1954 1954 ls NAMI "0" 1954 1954 ls RET __lstat50 0 1954 1954 ls CALL __lstat50(0x7d9270fd1430,0x7d9270fd1438) 1954 1954 ls NAMI "1" 1954 1954 ls RET __lstat50 0 1954 1954 ls CALL __lstat50(0x7d9270fd1570,0x7d9270fd1578) 1954 1954 ls NAMI "2" 1954 1954 ls RET __lstat50 0 1954 1954 ls CALL __lstat50(0x7d9270fd16b0,0x7d9270fd16b8) 1954 1954 ls NAMI "3" 1954 1954 ls RET __lstat50 0 1954 1954 ls CALL __lstat50(0x7d9270fd17f0,0x7d9270fd17f8) 1954 1954 ls NAMI "4" Up to this point fd 4 is a symlink which is, presumably, being cached by ls(1). 1954 1954 ls CALL close(4) passwd db now opened at 4 which now is a regular file. 1954 1954 ls CALL open(0x7d92705b0006,0x40,0) 1954 1954 ls NAMI "/etc/pwd.db" 1954 1954 ls RET open 4 Now ls(1) does the listing: 1954 1954 ls GIO fd 1 wrote 44 bytes "crw--w 1 rvp tty 5, 2 Jan 13 04:05 0\n" 1954 1954 ls RET write 44/0x2c 1954 1954 ls CALL write(1,0x7d9270fa2000,0x2c) 1954 1954 ls GIO fd 1 wrote 44 bytes "crw--w 1 rvp tty 5, 2 Jan 13 04:05 1\n" 1954 1954 ls RET write 44/0x2c 1954 1954 ls CALL write(1,0x7d9270fa2000,0x2c) 1954 1954 ls GIO fd 1 wrote 44 bytes "crw--w 1 rvp tty 5, 2 Jan 13 04:05 2\n" 1954 1954 ls CALL readlink(0x7f7fff425a30,0x7f7fff425e40,0x400) 1954 1954 ls NAMI "/proc/self/fd/3" 1954 1954 ls RET readlink 4 1954 1954 ls CALL write(1,0x7d9270fa2000,0x34) 1954 1954 ls GIO fd 1 wrote 52 bytes "lr-xr-xr-x 1 rvp rvp 240 Jan 13 04:05 3 -> /tmp\n" The readlink on 4 will fail because it is no longer the symlink it originally was: 1954 1954 ls CALL readlink(0x7f7fff425a30,0x7f7fff425e40,0x400) 1954 1954 ls NAMI "/proc/self/fd/4" 1954 1954 ls RET readlink -1 errno 22 Invalid argument Anyway, here's one more patch: ---START PATCH--- --- sys/miscfs/procfs/procfs_vnops.c.orig 2022-01-12 20:57:25.944841288 + +++ sys/miscfs/procfs/procfs_vnops.c2022-01-12 23:07:44.736070587 + @@ -1410,7 +1410,7 @@ d.d_fileno = PROCFS_FILENO(pfs->pfs_pid, PFSfd, i - 2); d.d_namlen = snprintf(d.d_name, sizeof(d.d_name), "%lld", (long long)(i - 2)); - d.d_type = VREG; + d.d_type = DT_UNKNOWN; /* convert vtype -> DT_XXX ? */ if ((error = uiomove(, UIO_MX, uio)) != 0) break; if (cookies) ---END PATCH--- DT_UNKNOWN is not quite right either, but that's better than VREG which corresponds to DT_FIFO. -RVP
Re: Regulator
On Wed, Jan 12, 2022 at 07:59:27PM +, Taylor R Campbell wrote:
> Can you say more about the platform this is on? How do you discover
> the touchscreen device -- via what kind of firmware or bus/device
> enumeration? If this is acpi, can you share acpidump -dt? Do you
> have documentation for the hardware you can share?
This is a One Netbook A1. An amd64 platform with ACPI.
According to this post, the touchscreen is powered by a Goodix GXTP7386
https://handheld.computer/?page_id=1131
That device is in ACPI DSDT (see below). Taking insights from
linux/drivers/input/touchscreen/goodix.c I match it using
static const struct device_compatible_entry compat_data[] = {
{ .compat = "GDIX1001" },
{ .compat = "GDIX1002" },
DEVICE_COMPAT_EOL
};
Oddly, that brings me two devices, GXTP7386 and BOSC0200.
Here is acpidrump -dt: https://ftp.espci.fr/shadow/manu/acpidump
Here is GXTP7386 from DSDT:
Device (TPL1)
{Name (HID2, One)
Name (_HID, "GXTP7386") // _HID: Hardware ID
Name (_CID, "PNP0C50" /* HID Protocol Device (I2C bus) */) // _CID:
Compatible ID
Name (_S0W, Zero) // _S0W: S0 Device Wake State
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
If ((Arg0 == HIDG))
{
Return (HIDD (Arg0, Arg1, Arg2, Arg3, HID2))
}
Return (Buffer (One)
{
0x00 // .
})
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x005D, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C2",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveLow, Shared, PullDefault, 0x,
"\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x007F
}
})
Return (RBUF) /* \_SB_.PCI0.I2C2.TPL1._CRS.RBUF */
}
}
--
Emmanuel Dreyfus
m...@netbsd.org
Re: Regulator
> Date: Wed, 12 Jan 2022 14:34:24 +
> From: Emmanuel Dreyfus
>
> There is another readblock. The Linux driver for Goodix touchpanel
> uses a beast called regulator, which seems to control the chip
> power supply:
> ts->avdd28 = devm_regulator_get(dev, "AVDD28");
> (...)
> ts->vddio = devm_regulator_get(dev, "VDDIO");
> (...)
> /* power up the controller */
> error = regulator_enable(ts->avdd28);
> (...)
> error = regulator_enable(ts->vddio);
This is something that will be provided by the fdt, when you are
running it on a platform with fdt. For example, quoting from
sys/external/gpl2/dist/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi:
touchscreen@5d {
compatible = "goodix,gt917s";
reg = <0x5d>;
interrupt-parent = <>;
interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
irq-gpios = < 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
reset-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
AVDD28-supply = <_ldo_io0>;
VDDIO-supply = <_ldo_io0>;
touchscreen-size-x = <720>;
touchscreen-size-y = <1440>;
};
This is part of the fdt bus attachment. But if the platform isn't
described by fdt, e.g. you're on an acpi system instead, the driver
might not need to mess with regulators at all (or, it might be acpi
with embedded device tree data).
Can you say more about the platform this is on? How do you discover
the touchscreen device -- via what kind of firmware or bus/device
enumeration? If this is acpi, can you share acpidump -dt? Do you
have documentation for the hardware you can share?
Re: Regulator
> On Jan 12, 2022, at 9:08 AM, Jason Thorpe wrote: > >> On Jan 12, 2022, at 8:02 AM, Taylor R Campbell >> wrote: >> >>> Date: Wed, 12 Jan 2022 15:42:17 + >>> From: Robert Swindells >>> >>> I'm guessing this is a platform that doesn't use FDT. >>> >>> Maybe we need a more general API for regulators. >> >> What other instances would a more general API cover? Is there some >> ACPI interface for regulators? > > The ACPI interface for regulators is usually "put device into power state X", > but of course that depends on the right ASL being present in the node for the > device. I guess I forgot to mention, it's not necessarily about setting the device into a specific power state (like "soft-suspend" vs "deep-sleep" vs "off"). In addition to "on" and "off", the regulator API can be used to step voltages. This is useful when you want to consume as little power as possible for a given performance requirement... like if you're running an interface at a slower clock rate (for whatever reason), you can sometimes step down the voltage because you don't need as much drive strength to defeat the capacitances of the physical device, for example. I don't know that ACPI really encapsulates that (unless there are DSMs or whatever defined for the device type that know how to do such stepping). In general, the philosophy between ACPI and Device Tree are different in this regard. ACPI aims to encapsulate the knowledge in methods that the firmware provides, and Device Tree aims to describe the connections between the elements and then provides generic interfaces to interact with those elements. -- thorpej
Re: Regulator
> On Jan 12, 2022, at 9:17 AM, Jason Thorpe wrote: > >> Both lima and panfrost need to make calls to the regulator API, as well >> as clock, reset and interrupt ones. > > Lima will probably be fine because the platforms that need it will use FDT. > Except for if you're using that board with ACPI, I guess. Same situation > with resets. Interrupts are another story and a bit more complicated. "Resets" is also a little more complicated, because there are two kinds on the Device Tree bindings universe: - Reset Controllers (which use the "Reset" bindings) - Reset GPIOs (which use the "GPIO" bindings) Our FDT GPIO and generic GPIO interfaces are in need of harmonizing, and I've been thinking about that lately, so hopefully will have some bandwidth to make progress on that front in the coming months. -- thorpej
Re: Regulator
> Date: Wed, 12 Jan 2022 09:08:57 -0800 > From: Jason Thorpe > > Any place where there's an "#ifdef FDT" is a failure to create a > proper abstraction. I tend to agree that #if is bad, but just deleting #if without a better replacement isn't the right thing. What's the pattern that the fdt regulators are an instance of, which this should be replaced by? The only reason #if occurs in linux/regulator/consumer.h is that that gets included by a header file (nvif/os.h) that is also used on non-fdt platforms. The API itself is only used by tegra drm, as far as I know. (Could have put the #if in that header file instead, but that would have made it a local patch which is more trouble for merging.)
Re: Regulator
> On Jan 12, 2022, at 9:12 AM, Robert Swindells wrote: > > > Taylor R Campbell wrote: >> Date: Wed, 12 Jan 2022 15:42:17 + >>> From: Robert Swindells >>> >>> I'm guessing this is a platform that doesn't use FDT. >>> >>> Maybe we need a more general API for regulators. >> >> What other instances would a more general API cover? Is there some >> ACPI interface for regulators? > > Don't know, somebody could look at what the Linux API covers. > > Could also look at doing clocks, resets and interrupts. We have one for clocks, but the only way to acquire a clock handle is via FDT at the moment. > Both lima and panfrost need to make calls to the regulator API, as well > as clock, reset and interrupt ones. Lima will probably be fine because the platforms that need it will use FDT. Except for if you're using that board with ACPI, I guess. Same situation with resets. Interrupts are another story and a bit more complicated. -- thorpej
Re: Regulator
Taylor R Campbell wrote: > Date: Wed, 12 Jan 2022 15:42:17 + >> From: Robert Swindells >> >> I'm guessing this is a platform that doesn't use FDT. >> >> Maybe we need a more general API for regulators. > >What other instances would a more general API cover? Is there some >ACPI interface for regulators? Don't know, somebody could look at what the Linux API covers. Could also look at doing clocks, resets and interrupts. >> The current situation causes a fair bit of "#ifdef FDT" in the drm >> compat code. > >I count 1: > >Am I missing some? sys/external/bsd/drm2/include/linux/clk.h I didn't say they were all in the tree right now, I also have them in interrupt.h and reset.h in my local working copy. If you want this kind of thing done in a different way then say what it should be. >There's also one in linux/clk.h, for clocks, and two in nouveau_pci.c >and radeon_pci.c, for kicking out the FBT framebuffer; these don't >appear to be relevant to regulators. Both lima and panfrost need to make calls to the regulator API, as well as clock, reset and interrupt ones.
Re: Regulator
> On Jan 12, 2022, at 9:08 AM, Jason Thorpe wrote: > > > >> On Jan 12, 2022, at 8:02 AM, Taylor R Campbell >> wrote: >> >>> Date: Wed, 12 Jan 2022 15:42:17 + >>> From: Robert Swindells >>> >>> I'm guessing this is a platform that doesn't use FDT. >>> >>> Maybe we need a more general API for regulators. >> >> What other instances would a more general API cover? Is there some >> ACPI interface for regulators? > > The ACPI interface for regulators is usually "put device into power state X", > but of course that depends on the right ASL being present in the node for the > device. (Of course I mean AML here, but of course it's all initially written in ASL, so...) > >>> The current situation causes a fair bit of "#ifdef FDT" in the drm >>> compat code. >> >> I count 1: >> >> https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/include/linux/regulator/consumer.h?r=1.5#39 >> >> Am I missing some? >> >> There's also one in linux/clk.h, for clocks, and two in nouveau_pci.c >> and radeon_pci.c, for kicking out the FBT framebuffer; these don't >> appear to be relevant to regulators. > > Any place where there's an "#ifdef FDT" is a failure to create a proper > abstraction. > > -- thorpej -- thorpej
Re: Regulator
> On Jan 12, 2022, at 8:02 AM, Taylor R Campbell > wrote: > >> Date: Wed, 12 Jan 2022 15:42:17 + >> From: Robert Swindells >> >> I'm guessing this is a platform that doesn't use FDT. >> >> Maybe we need a more general API for regulators. > > What other instances would a more general API cover? Is there some > ACPI interface for regulators? The ACPI interface for regulators is usually "put device into power state X", but of course that depends on the right ASL being present in the node for the device. >> The current situation causes a fair bit of "#ifdef FDT" in the drm >> compat code. > > I count 1: > > https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/include/linux/regulator/consumer.h?r=1.5#39 > > Am I missing some? > > There's also one in linux/clk.h, for clocks, and two in nouveau_pci.c > and radeon_pci.c, for kicking out the FBT framebuffer; these don't > appear to be relevant to regulators. Any place where there's an "#ifdef FDT" is a failure to create a proper abstraction. -- thorpej
Re: Regulator
> Date: Wed, 12 Jan 2022 15:42:17 + > From: Robert Swindells > > I'm guessing this is a platform that doesn't use FDT. > > Maybe we need a more general API for regulators. What other instances would a more general API cover? Is there some ACPI interface for regulators? > The current situation causes a fair bit of "#ifdef FDT" in the drm > compat code. I count 1: https://nxr.netbsd.org/xref/src/sys/external/bsd/drm2/include/linux/regulator/consumer.h?r=1.5#39 Am I missing some? There's also one in linux/clk.h, for clocks, and two in nouveau_pci.c and radeon_pci.c, for kicking out the FBT framebuffer; these don't appear to be relevant to regulators.
Re: Regulator
Jason Thorpe wrote: > On Jan 12, 2022, at 6:34 AM, Emmanuel Dreyfus wrote: >> >> Hello >> >> I am still working on Goodix touchpanel as told in [1] and [2]. I >> wrote a driver for the Intel GPIO chip that interfaces with Goodix >> chipreset and interrupt pins. I have not committed yet, because it >> remains untested. >> >> There is another readblock. The Linux driver for Goodix touchpanel >> uses a beast called regulator, which seems to control the chip >> power supply: >>ts->avdd28 = devm_regulator_get(dev, "AVDD28"); >> (...) >>ts->vddio = devm_regulator_get(dev, "VDDIO"); >> (...) >>/* power up the controller */ >>error = regulator_enable(ts->avdd28); >> (...) >>error = regulator_enable(ts->vddio); >> >> Is it another chip that neds another driver? Or a feature of the >> Goodix chip? What support do we have for thins kind of thing? >> grep -r regulator returns manu hits in src/sys/dev/i2c and >> src/sys/dev/fdt but we do not have any generic API for that, right? >We support regulators using FDT. I'm guessing this is a platform that doesn't use FDT. Maybe we need a more general API for regulators. The current situation causes a fair bit of "#ifdef FDT" in the drm compat code.
Re: Regulator
> On Jan 12, 2022, at 6:34 AM, Emmanuel Dreyfus wrote: > > Hello > > I am still working on Goodix touchpanel as told in [1] and [2]. I > wrote a driver for the Intel GPIO chip that interfaces with Goodix > chipreset and interrupt pins. I have not committed yet, because it > remains untested. > > There is another readblock. The Linux driver for Goodix touchpanel > uses a beast called regulator, which seems to control the chip > power supply: >ts->avdd28 = devm_regulator_get(dev, "AVDD28"); > (...) >ts->vddio = devm_regulator_get(dev, "VDDIO"); > (...) >/* power up the controller */ >error = regulator_enable(ts->avdd28); > (...) >error = regulator_enable(ts->vddio); > > Is it another chip that neds another driver? Or a feature of the > Goodix chip? What support do we have for thins kind of thing? > grep -r regulator returns manu hits in src/sys/dev/i2c and > src/sys/dev/fdt but we do not have any generic API for that, right? We support regulators using FDT. -- thorpej
Regulator
Hello I am still working on Goodix touchpanel as told in [1] and [2]. I wrote a driver for the Intel GPIO chip that interfaces with Goodix chipreset and interrupt pins. I have not committed yet, because it remains untested. There is another readblock. The Linux driver for Goodix touchpanel uses a beast called regulator, which seems to control the chip power supply: ts->avdd28 = devm_regulator_get(dev, "AVDD28"); (...) ts->vddio = devm_regulator_get(dev, "VDDIO"); (...) /* power up the controller */ error = regulator_enable(ts->avdd28); (...) error = regulator_enable(ts->vddio); Is it another chip that neds another driver? Or a feature of the Goodix chip? What support do we have for thins kind of thing? grep -r regulator returns manu hits in src/sys/dev/i2c and src/sys/dev/fdt but we do not have any generic API for that, right? [1] http://mail-index.netbsd.org/tech-kern/2021/12/11/msg027852.html [2] http://mail-index.netbsd.org/tech-kern/2021/12/18/msg027861.html -- Emmanuel Dreyfus m...@netbsd.org
Re: procfs files vs symlink
On Wed, Jan 12, 2022 at 08:10:44AM -0500, Christos Zoulas wrote: > > > > On Jan 12, 2022, at 8:08 AM, Manuel Bouyer wrote > >> > >> Where do you get the reference to the original inode? Try it... > > > > I don't understand. My patch doesn't change the procfs behavior for > > non-linux > > binaries so I can't see the problem. > > Ah I did not understand that, sorry. Anyway it is fine then, although I would > like to understand first why linux binaries break... Do they do readlink(2) > unconditionally and then they don't handle the error condition? Yes, I guess that's it, but I don't have the sources. I suspect they do this to find the absolute path of the binary. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: procfs files vs symlink
> On Jan 12, 2022, at 8:08 AM, Manuel Bouyer wrote >> >> Where do you get the reference to the original inode? Try it... > > I don't understand. My patch doesn't change the procfs behavior for non-linux > binaries so I can't see the problem. Ah I did not understand that, sorry. Anyway it is fine then, although I would like to understand first why linux binaries break... Do they do readlink(2) unconditionally and then they don't handle the error condition? christos signature.asc Description: Message signed with OpenPGP
Re: procfs files vs symlink
On Wed, Jan 12, 2022 at 07:56:09AM -0500, Christos Zoulas wrote: > > > > On Jan 12, 2022, at 7:54 AM, Manuel Bouyer wrote: > > > > you can still do this, as long as you're not using a linux ln(1) binary. > > Where do you get the reference to the original inode? Try it... I don't understand. My patch doesn't change the procfs behavior for non-linux binaries so I can't see the problem. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: procfs files vs symlink
> On Jan 12, 2022, at 7:54 AM, Manuel Bouyer wrote: > > you can still do this, as long as you're not using a linux ln(1) binary. Where do you get the reference to the original inode? Try it... christos signature.asc Description: Message signed with OpenPGP
Re: procfs files vs symlink
On Wed, Jan 12, 2022 at 12:44:57PM -, Christos Zoulas wrote: > In article , > Manuel Bouyer wrote: > >-=-=-=-=-=- > > > >On Fri, Jan 07, 2022 at 03:20:04PM +0100, Manuel Bouyer wrote: > >> Hello > >> I'm trying to get a linux binary to run on NetBSD, as stated in this thread > >> http://mail-index.netbsd.org/current-users/2022/01/06/msg041891.html > >> > >> Now I hit an issue where the linux process does a readlink() on a procfs > >> file and gets EINVAL. > >> It seems that this is because, on linux all files in /proc//fd/ are > >> symlinks, while on NetBSD they are some kind of hard links. > >> E.g. on linux: > >> bip:/dsk/l1/misc/bouyer/HEAD/clean/src>ls -l /proc/$$/fd/ > >> total 0 > >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 0 -> /dev/null > >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 1 -> /dev/null > >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 15 -> /dev/pts/11 > >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 14:13 16 -> /dev/pts/11 > >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 17 -> /dev/pts/11 > >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 18 -> /dev/pts/11 > >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 19 -> /dev/pts/11 > >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 2 -> /dev/null > >> > >> On NetBSD: > >> armandeche:/local/armandeche1/bouyer>/emul/linux/bin/ls -l /proc/$$/fd/ > >> total 0 > >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 15 > >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 16 > >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 17 > >> > >> Any idea on how to properly fix it ? > > > >The attached diff changes the procfs behavior to match the linux one, for > >linux processes: > >comore:/home/bouyer>ls -l /proc/self/fd/ > >total 1 > >crw--w 1 bouyer tty5, 0 Jan 11 11:08 0 > >crw--w 1 bouyer tty5, 0 Jan 11 11:08 1 > >crw--w 1 bouyer tty5, 0 Jan 11 11:08 2 > >lr-xr-xr-x 1 bouyer staff 512 Jan 11 11:08 3 -> /home/bouyer > > > >ls: /proc/self/fd//4: Invalid argument > >lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 4 > >comore:/home/bouyer>/emul/linux/bin/ls -l /proc/self/fd/ > >total 0 > >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 0 -> /dev/ttyp0 > >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 1 -> /dev/ttyp0 > >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 2 -> /dev/ttyp0 > >lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 3 -> / > > > >and my linux binaries seems to work properly now > > > >would it be OK to commit ? > > Err, no :-) The previous behavior uses the original inode from the filesystem. > This means that you can undelete files: you can still do this, as long as you're not using a linux ln(1) binary. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: procfs files vs symlink
On Wed, Jan 12, 2022 at 07:19:14PM +0700, Robert Elz wrote: > Date:Tue, 11 Jan 2022 22:20:15 +0100 > From:Manuel Bouyer > Message-ID: > > | > What causes that EINVAL? > | > | > | I'm not sure (somneone suggested that the file descriptor has been closed > | when ls tries to fstat() it, but I can't confirm this). > > That should generate EBADF not EINVAL. Attempting readlink() > on something that is not a symlink, and various other possibilities > like that would be more probable. EINVAL isn't listed as a possible > error return from [f]stat ... not that that guarantees that it cannot > happen, particularly from within emulation code. Acutally it's not fstat() but readlink(), as shown by ktrace. To me it's not clear why readlink() fails on this file descriptor. But it's not caused by my patch -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: procfs files vs symlink
In article , Manuel Bouyer wrote: >-=-=-=-=-=- > >On Fri, Jan 07, 2022 at 03:20:04PM +0100, Manuel Bouyer wrote: >> Hello >> I'm trying to get a linux binary to run on NetBSD, as stated in this thread >> http://mail-index.netbsd.org/current-users/2022/01/06/msg041891.html >> >> Now I hit an issue where the linux process does a readlink() on a procfs >> file and gets EINVAL. >> It seems that this is because, on linux all files in /proc//fd/ are >> symlinks, while on NetBSD they are some kind of hard links. >> E.g. on linux: >> bip:/dsk/l1/misc/bouyer/HEAD/clean/src>ls -l /proc/$$/fd/ >> total 0 >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 0 -> /dev/null >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 1 -> /dev/null >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 15 -> /dev/pts/11 >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 14:13 16 -> /dev/pts/11 >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 17 -> /dev/pts/11 >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 18 -> /dev/pts/11 >> lrwx-- 1 bouyer ita-iatos 64 Jan 7 15:16 19 -> /dev/pts/11 >> lr-x-- 1 bouyer ita-iatos 64 Jan 7 14:13 2 -> /dev/null >> >> On NetBSD: >> armandeche:/local/armandeche1/bouyer>/emul/linux/bin/ls -l /proc/$$/fd/ >> total 0 >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 15 >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 16 >> crw--w 1 bouyer tty 3, 13 Jan 7 15:19 17 >> >> Any idea on how to properly fix it ? > >The attached diff changes the procfs behavior to match the linux one, for >linux processes: >comore:/home/bouyer>ls -l /proc/self/fd/ >total 1 >crw--w 1 bouyer tty5, 0 Jan 11 11:08 0 >crw--w 1 bouyer tty5, 0 Jan 11 11:08 1 >crw--w 1 bouyer tty5, 0 Jan 11 11:08 2 >lr-xr-xr-x 1 bouyer staff 512 Jan 11 11:08 3 -> /home/bouyer > >ls: /proc/self/fd//4: Invalid argument >lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 4 >comore:/home/bouyer>/emul/linux/bin/ls -l /proc/self/fd/ >total 0 >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 0 -> /dev/ttyp0 >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 1 -> /dev/ttyp0 >lr-xr-xr-x 1 root wheel 0 Jan 11 11:08 2 -> /dev/ttyp0 >lr-xr-xr-x 1 bouyer staff 0 Jan 11 11:08 3 -> / > >and my linux binaries seems to work properly now > >would it be OK to commit ? Err, no :-) The previous behavior uses the original inode from the filesystem. This means that you can undelete files: [7:39am] 1978>cat > removeme 23423234234324 ^Z [1] + 21532 Suspended cat > removeme [7:39am] 1979>bg [1]cat > removeme & [2] + Suspended (tty input) cat > removeme [7:39am] 1980>rm removeme [7:39am] 1981>cd /proc/21532/fd [7:39am] 1982>ls -l total 2 crw--w 1 christos tty 5, 2 Jan 12 07:39 0 -rw-rw-r-- 0 christos christos15 Jan 12 07:39 1 crw--w 1 christos tty 5, 2 Jan 12 07:39 2 [7:39am] 1983>ln 1 ~christos/unremove [7:40am] 1984>fg cat > removeme (wd: ~) (wd now: /proc/21532/fd) [7:40am] 1985>cat ~christos/unremove 23423234234324 Yes, this is a stupid example, but consider doing the same to recover the log from a long running daemon that was accidentally removed. christos
Re: procfs files vs symlink
Date:Tue, 11 Jan 2022 22:20:15 +0100 From:Manuel Bouyer Message-ID: | > What causes that EINVAL? | | | I'm not sure (somneone suggested that the file descriptor has been closed | when ls tries to fstat() it, but I can't confirm this). That should generate EBADF not EINVAL. Attempting readlink() on something that is not a symlink, and various other possibilities like that would be more probable. EINVAL isn't listed as a possible error return from [f]stat ... not that that guarantees that it cannot happen, particularly from within emulation code. kre
