Re: [PATCH 5/8] loop: only take lo_mutex for the first reference in lo_open

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ping?

I sent https://lkml.kernel.org/r/20220129071500.3566-1-penguin-kernel@xxxxxxxxxxxxxxxxxxx
based on ideas from your series.

Since automated kernel tests are failing, can't we apply
[PATCH 1/7] loop: revert "make autoclear operation asynchronous"
for now if we can't come to a conclusion?

On 2022/01/28 22:13, Tetsuo Handa wrote:
> On 2022/01/28 22:00, Christoph Hellwig wrote:
>> +	if (atomic_inc_return(&lo->lo_refcnt) > 1)
>> +		return 0;
>> +
>>  	err = mutex_lock_killable(&lo->lo_mutex);
>>  	if (err)
> 
> You did not notice my diff here...

You need to drop lo->lo_refcnt before return.

But my latest series no longer uses task work context and no longer
holds lo->lo_mutex from lo_open()/lo_release().

> 
>>  		return err;
>> -	if (lo->lo_state == Lo_deleting)
>> +	if (lo->lo_state == Lo_deleting) {
>> +		atomic_dec(&lo->lo_refcnt);
>>  		err = -ENXIO;
>> -	else
>> -		atomic_inc(&lo->lo_refcnt);
>> +	}
> 
> Why do we need [PATCH 1/8] [PATCH 2/8] [PATCH 3/8] in this series?
> Shouldn't we first make a clean revert, and keep the changes for
> this release cycle as small as possible?



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux