mount-util: do not use the official MAX_HANDLE_SZ (#7523)

If we'd use the system header's version of MAX_HANDLE_SZ then our code
would break on older kernels as soon as the value is increased, as old
kernels refuse larger buffers with EINVAL.
This commit is contained in:
Lennart Poettering 2017-12-03 12:18:33 +01:00 committed by Zbigniew Jędrzejewski-Szmek
parent 1ff8b31d9b
commit 01a7e0a14d
2 changed files with 9 additions and 5 deletions

View File

@ -543,10 +543,6 @@ struct btrfs_ioctl_quota_ctl_args {
#define PR_SET_CHILD_SUBREAPER 36
#endif
#ifndef MAX_HANDLE_SZ
#define MAX_HANDLE_SZ 128
#endif
#if ! HAVE_SECURE_GETENV
# if HAVE___SECURE_GETENV
# define secure_getenv __secure_getenv

View File

@ -40,6 +40,14 @@
#include "string-util.h"
#include "strv.h"
/* This is the original MAX_HANDLE_SZ definition from the kernel, when the API was introduced. We use that in place of
* any more currently defined value to future-proof things: if the size is increased in the API headers, and our code
* is recompiled then it would cease working on old kernels, as those refuse any sizes larger than this value with
* EINVAL right-away. Hence, let's disconnect ourselves from any such API changes, and stick to the original definition
* from when it was introduced. We use it as a start value only anyway (see below), and hence should be able to deal
* with large file handles anyway. */
#define ORIGINAL_MAX_HANDLE_SZ 128
int name_to_handle_at_loop(
int fd,
const char *path,
@ -48,7 +56,7 @@ int name_to_handle_at_loop(
int flags) {
_cleanup_free_ struct file_handle *h;
size_t n = MAX_HANDLE_SZ;
size_t n = ORIGINAL_MAX_HANDLE_SZ;
/* We need to invoke name_to_handle_at() in a loop, given that it might return EOVERFLOW when the specified
* buffer is too small. Note that in contrast to what the docs might suggest, MAX_HANDLE_SZ is only good as a