NightStrike wrote: > I don't quite understand your animosity here. Gnulib is supposed to help > porting to systems, and I'm highlighting a situation where it doesn't work. > Why such antagonism vs trying to understand why it doesn't work? Surely a > configure test that causes the RCU to spin for 12 hours and hang a whole > system isn't a great way to have portability.
OK, since you ask so explicitly, I will answer explicitly. * I am a bit annoyed that instead of explaining _your_ problem in the first place, you start with "See https://bugs.gentoo.org/447970 for extra details" and thus send me to a 10-minutes read of a ticket that is 95% disjoint from your problem. It would have been better if you omit this intro, and instead concentrate on _your_ problem on _your_ hardware. * I am a bit annoyed that you see a problem on the Gnulib side, when I see a major problem in your system. Namely, what the getcwd-path-max.m4 test program does, is to create a directory hierarchy conftest3/conftest3/conftest3/... with a depth of ca. 500 directories, and runs mkdir() and getwcd() in each. I think any reasonable system should support this, regardless of file system, regardless of container, regardless of Linux version. I have been running this configure test as part of many packages that I test on ca. 100 different platforms, with 10 different operating systems, and have not observed it bringing the system to its knees. When you report "it hung for at least 12 hours" and "the RCU kernel thread spins its core at 100%", it is pretty evident to me that a kernel bug is being hit. Since you mention btrfs and since btrfs does not have the stability of, say, ext4 or xfs, my primary suspicion would be on the btrfs file system. * I am also a bit annoyed that you don't realize the implications of the problem that you are hitting. If any user programs can bring the system into coma mode, just by 500 mkdir() and 500 getcwd() calls, then what will it help if Gnulib stops doing this in its configure tests? Your system will still be vulnerable to DoS attacks by any program. * Finally, I am annoyed to get a bug report about a NAS system. Knowing that some NAS vendors ship buggy Linux kernels and never offer the user the option to upgrade to a reliable one. Unlike most distros, which are shipped when they have undergone beta-testing, some NAS vendors just do some minimal testing and ship the (unreliable) result to all their customers. Bruno
