Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v3 2/2] Bluetooth: fix inconsistent lock state in
 rfcomm_connect_ind
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Matthieu Baerts <matthieu.baerts@tessares.net>,
        Stefan Schmidt <stefan@datenfreihafen.org>,
        linux-bluetooth <linux-bluetooth@vger.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>,
        skhan@linuxfoundation.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel-mentees@lists.linuxfoundation.org
References: <20210721093832.78081-1-desmondcheongzx@gmail.com>
 <20210721093832.78081-3-desmondcheongzx@gmail.com>
 <06E57598-5723-459D-9CE3-4DD8D3145D86@holtmann.org>
From:   Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Message-ID: <40f38642-faa9-8c63-4306-6477e272cfbe@gmail.com>
Date:   Fri, 30 Jul 2021 17:06:09 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <06E57598-5723-459D-9CE3-4DD8D3145D86@holtmann.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Marcel,

On 30/7/21 3:53 am, Marcel Holtmann wrote:
> Hi Desmond,
> 
>> Commit fad003b6c8e3d ("Bluetooth: Fix inconsistent lock state with
>> RFCOMM") fixed a lockdep warning due to sk->sk_lock.slock being
>> acquired without disabling softirq while the lock is also used in
>> softirq context. This was done by disabling interrupts before calling
>> bh_lock_sock in rfcomm_sk_state_change.
>>
>> Later, this was changed in commit e6da0edc24ee ("Bluetooth: Acquire
>> sk_lock.slock without disabling interrupts") to disable softirqs
>> only.
>>
>> However, there is another instance of sk->sk_lock.slock being acquired
>> without disabling softirq in rfcomm_connect_ind. This patch fixes this
>> by disabling local bh before the call to bh_lock_sock.
> 
> back in the days, the packet processing was done in a tasklet, but these days it is done in a workqueue. So shouldn’t this be just converted into a lock_sock(). Am I missing something?
> 

Thanks for the info. I think you're right, I just didn't understand very 
much when I wrote this patch.

If I'm understanding correctly, it seems that both the bh_lock_sock in 
rfcomm_connect_ind, and spin_lock_bh in rfcomm_sk_state_change need to 
be changed to lock_sock, otherwise they don't provide any 
synchronization with other functions in RFCOMM that use lock_sock.

If that sounds correct I can prepare the patch for that.

Best wishes,
Desmond