2011-02-22 13:58:44 +03:00
|
|
|
/*
|
|
|
|
* CDDL HEADER START
|
|
|
|
*
|
|
|
|
* The contents of this file are subject to the terms of the
|
|
|
|
* Common Development and Distribution License (the "License").
|
|
|
|
* You may not use this file except in compliance with the License.
|
|
|
|
*
|
|
|
|
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
2022-07-12 00:16:13 +03:00
|
|
|
* or https://opensource.org/licenses/CDDL-1.0.
|
2011-02-22 13:58:44 +03:00
|
|
|
* See the License for the specific language governing permissions
|
|
|
|
* and limitations under the License.
|
|
|
|
*
|
|
|
|
* When distributing Covered Code, include this CDDL HEADER in each
|
|
|
|
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
|
|
|
* If applicable, add the following below this CDDL HEADER, with the
|
|
|
|
* fields enclosed by brackets "[]" replaced with your own identifying
|
|
|
|
* information: Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
*
|
|
|
|
* CDDL HEADER END
|
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* Copyright (c) 2011, Fajar A. Nugraha. All rights reserved.
|
|
|
|
* Use is subject to license terms.
|
|
|
|
*/
|
|
|
|
|
2014-10-29 04:29:53 +03:00
|
|
|
#include <ctype.h>
|
2022-05-11 20:58:19 +03:00
|
|
|
#include <errno.h>
|
2011-02-22 13:58:44 +03:00
|
|
|
#include <fcntl.h>
|
2022-05-11 20:58:19 +03:00
|
|
|
#include <stdio.h>
|
|
|
|
#include <string.h>
|
2011-02-22 13:58:44 +03:00
|
|
|
#include <unistd.h>
|
|
|
|
#include <sys/fs/zfs.h>
|
2022-05-11 20:58:19 +03:00
|
|
|
#include <sys/ioctl.h>
|
|
|
|
#include <sys/stat.h>
|
2011-02-22 13:58:44 +03:00
|
|
|
|
2022-02-04 01:35:38 +03:00
|
|
|
#if defined(ZFS_ASAN_ENABLED)
|
|
|
|
/*
|
|
|
|
* zvol_id is invoked by udev with the help of ptrace()
|
|
|
|
* making sanitized binary with leak detection croak
|
|
|
|
* because of tracing mechanisms collision
|
|
|
|
*/
|
|
|
|
extern const char *__asan_default_options(void);
|
|
|
|
|
|
|
|
const char *__asan_default_options(void) {
|
|
|
|
return ("abort_on_error=true:halt_on_error=true:"
|
|
|
|
"allocator_may_return_null=true:disable_coredump=false:"
|
|
|
|
"detect_stack_use_after_return=true:detect_leaks=false");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-11-01 23:26:11 +04:00
|
|
|
int
|
2022-05-11 20:58:19 +03:00
|
|
|
main(int argc, const char *const *argv)
|
2011-02-22 13:58:44 +03:00
|
|
|
{
|
2024-03-22 02:38:24 +03:00
|
|
|
if (argc != 2 || strncmp(argv[1], "/dev/zd", 7) != 0) {
|
2022-05-11 20:58:19 +03:00
|
|
|
fprintf(stderr, "usage: %s /dev/zdX\n", argv[0]);
|
|
|
|
return (1);
|
2011-02-22 13:58:44 +03:00
|
|
|
}
|
2022-05-11 20:58:19 +03:00
|
|
|
const char *dev_name = argv[1];
|
2024-10-02 19:10:06 +03:00
|
|
|
size_t i, len;
|
2022-05-11 20:58:19 +03:00
|
|
|
|
|
|
|
int fd;
|
|
|
|
struct stat sb;
|
|
|
|
if ((fd = open(dev_name, O_RDONLY|O_CLOEXEC)) == -1 ||
|
|
|
|
fstat(fd, &sb) != 0) {
|
|
|
|
fprintf(stderr, "%s: %s\n", dev_name, strerror(errno));
|
|
|
|
return (1);
|
2011-02-22 13:58:44 +03:00
|
|
|
}
|
|
|
|
|
2022-05-11 20:58:19 +03:00
|
|
|
char zvol_name[MAXNAMELEN + strlen("-part") + 10];
|
|
|
|
if (ioctl(fd, BLKZNAME, zvol_name) == -1) {
|
|
|
|
fprintf(stderr, "%s: BLKZNAME: %s\n",
|
|
|
|
dev_name, strerror(errno));
|
|
|
|
return (1);
|
2011-03-24 11:22:52 +03:00
|
|
|
}
|
2018-04-04 20:16:47 +03:00
|
|
|
|
2024-03-22 02:38:24 +03:00
|
|
|
const char *dev_part = strrchr(dev_name, 'p');
|
2024-10-02 19:10:06 +03:00
|
|
|
len = strlen(zvol_name);
|
2024-03-22 02:38:24 +03:00
|
|
|
if (dev_part != NULL) {
|
2024-10-02 19:10:06 +03:00
|
|
|
sprintf(zvol_name + len, "-part%s", dev_part + 1);
|
|
|
|
len = strlen(zvol_name);
|
2024-03-22 02:38:24 +03:00
|
|
|
}
|
2014-10-29 04:29:53 +03:00
|
|
|
|
2024-10-02 19:10:06 +03:00
|
|
|
for (i = 0; i < len; ++i)
|
2022-05-11 20:58:19 +03:00
|
|
|
if (isblank(zvol_name[i]))
|
|
|
|
zvol_name[i] = '+';
|
Use substantially more robust program exit status logic in zvol_id
Currently, there are several places in zvol_id where the program logic
returns particular errno values, or even particular ioctl return values,
as the program exit status, rather than a straightforward system of
explicit zero on success and explicit nonzero value(s) on failure.
This is problematic for multiple reasons. One particularly interesting
problem that can arise, is that if any of these values happens to have
all 8 least significant bits unset (i.e., it is a positive or negative
multiple of 256), then although the C program sees a nonzero int value
(presumed to be a failure exit status), the actual exit status as seen
by the system is only the bottom 8 bits of that integer: zero.
This can happen in practice, and I have encountered it myself. In a
particularly weird situation, the zvol_open code in the zfs kernel
module was behaving in such a manner that it caused the open() syscall
to fail and for errno to be set to a kernel-private value (ERESTARTSYS,
which happens to be defined as 512). It turns out that 512 is evenly
divisible by 256; or, in other words, its least significant 8 bits are
all-zero. So even though zvol_id believed it was returning a nonzero
(failure) exit status of 512, the system modulo'd that value by 256,
resulting in the actual exit status visible by other programs being 0!
This actually-zero (non-failure) exit status caused problems: udev
believed that the program was operating successfully, when in fact it
was attempting to indicate failure via a nonzero exit status integer.
Combined with another problem, this led to the creation of nonsense
symlinks for zvol dev nodes by udev.
Let's get rid of all this problematic logic, and simply return
EXIT_SUCCESS (0) is everything went fine, and EXIT_FAILURE (1) if
anything went wrong.
Additionally, let's clarify some of the variable names (error is similar
to errno, etc) and clean up the overall program flow a bit.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Signed-off-by: Justin Gottula <justin@jgottula.com>
Closes #12302
2021-06-30 07:29:09 +03:00
|
|
|
|
2022-05-11 20:58:19 +03:00
|
|
|
puts(zvol_name);
|
Use substantially more robust program exit status logic in zvol_id
Currently, there are several places in zvol_id where the program logic
returns particular errno values, or even particular ioctl return values,
as the program exit status, rather than a straightforward system of
explicit zero on success and explicit nonzero value(s) on failure.
This is problematic for multiple reasons. One particularly interesting
problem that can arise, is that if any of these values happens to have
all 8 least significant bits unset (i.e., it is a positive or negative
multiple of 256), then although the C program sees a nonzero int value
(presumed to be a failure exit status), the actual exit status as seen
by the system is only the bottom 8 bits of that integer: zero.
This can happen in practice, and I have encountered it myself. In a
particularly weird situation, the zvol_open code in the zfs kernel
module was behaving in such a manner that it caused the open() syscall
to fail and for errno to be set to a kernel-private value (ERESTARTSYS,
which happens to be defined as 512). It turns out that 512 is evenly
divisible by 256; or, in other words, its least significant 8 bits are
all-zero. So even though zvol_id believed it was returning a nonzero
(failure) exit status of 512, the system modulo'd that value by 256,
resulting in the actual exit status visible by other programs being 0!
This actually-zero (non-failure) exit status caused problems: udev
believed that the program was operating successfully, when in fact it
was attempting to indicate failure via a nonzero exit status integer.
Combined with another problem, this led to the creation of nonsense
symlinks for zvol dev nodes by udev.
Let's get rid of all this problematic logic, and simply return
EXIT_SUCCESS (0) is everything went fine, and EXIT_FAILURE (1) if
anything went wrong.
Additionally, let's clarify some of the variable names (error is similar
to errno, etc) and clean up the overall program flow a bit.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Pavel Zakharov <pavel.zakharov@delphix.com>
Signed-off-by: Justin Gottula <justin@jgottula.com>
Closes #12302
2021-06-30 07:29:09 +03:00
|
|
|
|
2022-05-11 20:58:19 +03:00
|
|
|
return (0);
|
2011-02-22 13:58:44 +03:00
|
|
|
}
|