On 2022/11/21 12:28, Kang-Che Sung wrote:
On Mon, Nov 21, 2022 at 9:31 AM Xiaoming Ni <nixiaom...@huawei.com> wrote:
Also, it is unclear why there is the need to clone the loopinfo buffer.
> /* Old kernel, does not support LO_FLAGS_AUTOCLEAR? */
> /* (this code path is not tested) */
> - loopinfo.lo_flags -= BB_LO_FLAGS_AUTOCLEAR;
> - rc = ioctl(lfd, BB_LOOP_SET_STATUS, &loopinfo);
> + loopinfo2.lo_flags -= BB_LO_FLAGS_AUTOCLEAR;
> + rc = ioctl(lfd, BB_LOOP_SET_STATUS, &loopinfo2);
> }
> if (rc == 0) {
> return lfd;
...
Pardon for my ignorance, but does the LOOP_SET_STATUS64 ioctl modify
the `loopinfo` object internally?
in linux kernel, drivers/block/loop.c:
static int
loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
static int
loop_set_status64(struct loop_device *lo, const struct loop_info64
__user *arg)
If the answer is yes, then it might not be a good idea to pass the
`loopinfo` structure to set_loop_configure().
I think it might be better to create the object on the fly (i.e. drop
this patch).
Otherwise, let set_loop_configure pass in a `const bb_loop_info *`
object, when we are sure it would never be modified internally.
thanks
I'll add const modifiers in the next version.
Thanks
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
