(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
