Re: m4/getcwd-path-max.m4 hangs with busybox + btrfs

[Bruno Haible]

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