On Thu, Mar 19, 2026 at 07:46:04PM -0700, Andrew Morton wrote:
> On Fri, 20 Mar 2026 00:06:51 +0800 Chunyu Hu <[email protected]> wrote:
>
> > There are several tests requires transprarent hugepages, when run on thp
> > disabled kernel such as realtime kernel, there will be false negative.
> > Mark those tests as skip when thp is not available.
>
> A couple of questions from Sashiko:
>
> https://sashiko.dev/#/patchset/20260319160656.1480279-1-chuhu%40redhat.com
>
AI question one:
```
> +void write_file(const char *path, const char *buf, size_t buflen)
> +{
> + int fd;
> + ssize_t numwritten;
> +
> + fd = open(path, O_WRONLY);
> + if (fd == -1)
> + ksft_exit_fail_msg("%s open failed: %s\n", path,
> strerror(errno));
> +
> + numwritten = write(fd, buf, buflen - 1);
Is it safe to keep the buflen - 1 behavior in a shared generic utility?
Since this is now a generic API in vm_util, callers passing the exact buffer
size (like sizeof(buf) or strlen(buf)) will suffer a 1-byte data truncation.
Additionally, if a caller passes buflen = 0, buflen - 1 will underflow,
causing write() to attempt writing an invalid size.
```
Here I think there's no single anwser. We can use buflen, but if user don't
provide a '\0' in the end of buffer, out of boundary access could happen
when such as printf(). We called it buflen, then we expect it's a '\0'
ended buffer as I undersand. So maye we can just leave as it is and user
should be awared of the requiremnt of the helper here.
AI question two:
```
> + close(fd);
> + if (numwritten < 1)
> + ksft_exit_fail_msg("Write failed\n");
Does this drop useful debugging context compared to the previous version
in thp_settings.c?
The old implementation printed the buffer contents on failure. With this
generic message, if a test fails to write, it will only print "Write failed"
without indicating which file path failed, what data was being written, or
the underlying errno.
```
That makes sense, indeed we dropped the printing of the buffer content
compared with the version in the thp_settings.c. I can append a new
patch in v5 to improve this, together with other safety checks.
