Re: [REGRESSION] ETXTBSY when running Yarn (Node) since af5d68f

[Jens Axboe <axboe@kernel.dk>]

(removing stable as this isn't a stable regression, and the commit
itself isn't marked for stable to begin with).

On 5/21/24 10:02 AM, Andrew Udvare wrote:
> #regzbot introduced: v6.8..v6.9-rc1
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af5d68f8892f8ee8f137648b79ceb2abc153a19b
> 
> Since the above commit present in 6.9+, Node running a Yarn installation that executes a subprocess always shows the following:
> 
> /test # yarn --offline install
> yarn install v1.22.22
> warning package.json: "test" is also the name of a node core module
> warning test@1.0.0: "test" is also the name of a node core module
> [1/4] Resolving packages...
> [2/4] Fetching packages...
> [3/4] Linking dependencies...
> [4/4] Building fresh packages...
> error /test/node_modules/snyk: Command failed.
> Exit code: 126
> Command: node wrapper_dist/bootstrap.js exec
> Arguments:
> Directory: /test/node_modules/snyk
> Output:
> /bin/sh: node: Text file busy
> 
> The commit was found by bisection with a simple initramfs that just runs 'yarn --offline install' with a test project and cached Yarn packages.
> 
> To reproduce:
> 
> npm install -g yarn
> mkdir test
> cd test
> cat > package.json <<EOF
> {
>    "name": "test",
>    "version": "1.0.0",
>    "main": "index.js",
>    "license": "MIT",
>    "dependencies": {
>      "snyk": "^1.1291.0"
>    }
> }
> EOF
> yarn install
> 
> Modern Yarn will give the same result but with slightly different output.
> 
> This also appears to affect node-gyp: https://github.com/nodejs/node/issues/53051
> 
> See also: https://bugs.gentoo.org/931942

This looks like a timing alteration due to task_work being done
differently, from a quick look and guess. For some reason SQPOLL is
being used. I tried running it here, but it doesn't reproduce for me.
Tried both current -git and 6.9 as released. I'll try on x86 as well to
see if I can hit it.

Maybe someone can describe what is happening here? I'm assuming that
something is racing with an io_uring operation done by SQPOLL, which is
keeping the file open until done.

This may or may not be a kernel issue, depending on what assumptions are
being made on when operations are begun and completed. Maybe those
assumptions are correct and there is indeed a kernel regression here, or
maybe the user side is just buggy in its assumptions.

-- 
Jens Axboe