[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: memory increase caused by mounting failure
From:       Rob Landley <rob () landley ! net>
Date:       2023-09-17 16:09:36
Message-ID: bf5f63da-9a8d-068a-28a2-50f48939ab6f () landley ! net
[Download RAW message or body]

On 9/5/23 23:27, Leng TouTou wrote:
> Hi，
> I used the following command to mount repeatedly about 10,000 times
>   $ mount -t squashfs -o loop,thread=0 image /mnt/tmp
> This command will not mount successfully, then I found that the memory used by
> slab increased by about 10000k.

A userspace program can't persistently increase slab memory. That's a kernel
issue. If doing it 10,000 times is different from doing it 10 times, that's
probably a kernel bug.

> So is this normal? In the Busybox source code, I saw that when the mount fails,
> del_loop uses LOOP_CLR_FD for cleanup. 
> Does LOOP_CLR_FD simply disconnect the loop device from the image, leaving the
> loop device still available for reuse? 
> Or if I want to completely release a loop device and its occupied memory, do I
> need to use LOOP_CTL_REMOVE?

How many /dev/loop* devices do you see in your devtmpfs? Either ls /dev/loop* or
sudo losetup -l

There's only a half-dozen parameters you can set for each loop device: the
dev/ino of the file to map to, the offset, length, sector granularity, you can
set it read only, and rope the partitioning logic into it. (There used to be a
crypto layer you could hook in too, but I think that went away.)

Rob
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

[prev in list] [next in list] [prev in thread] [next in thread]