Hi,
On Thu, Apr 19, 2018 at 12:56 PM, Kirill Tkhai wrote:
> On 19.04.2018 19:44, Al Viro wrote:
>> On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
>>
>>> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
>>> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
>>>
On 19.04.2018 19:44, Al Viro wrote:
> On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
>
>> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
>> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
>> ->mnt_pins of some other mount. Which, AFAICS, means that
>> it
On Thu, Apr 19, 2018 at 04:34:48PM +0100, Al Viro wrote:
> IOW, we only get there if our vfsmount was an MNT_INTERNAL one.
> So we have mnt->mnt_umount of some MNT_INTERNAL mount found in
> ->mnt_pins of some other mount. Which, AFAICS, means that
> it used to be mounted on that other mount. How
On Thu, Apr 19, 2018 at 03:50:25PM +0300, Kirill Tkhai wrote:
> Hi, Al,
>
> commit 87b95ce0964c016ede92763be9c164e49f1019e9 is the first after which the
> below test crashes the kernel:
>
> Author: Al Viro
> Date: Sat Jan 10 19:01:08 2015 -0500
>
> switch the IO-triggering parts
Hi, Al,
commit 87b95ce0964c016ede92763be9c164e49f1019e9 is the first after which the
below test crashes the kernel:
Author: Al Viro
Date: Sat Jan 10 19:01:08 2015 -0500
switch the IO-triggering parts of umount to fs_pin
Signed-off-by: Al Viro
$modprobe dummy
$while tr
5 matches
Mail list logo