From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752425AbdLND5M (ORCPT <rfc822;w@1wt.eu>);
        Wed, 13 Dec 2017 22:57:12 -0500
Received: from mail-pg0-f68.google.com ([74.125.83.68]:37926 "EHLO
        mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752141AbdLND5L (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 13 Dec 2017 22:57:11 -0500
X-Google-Smtp-Source: ACJfBov3mcVz2wRVe8OGs6dVgC2cxbg+qEPZXI1QUoJHB3BN7f7fWaSvA2w1pYNg0EcsyYCt18/pqQ==
Subject: Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in
 hp100_login_to_vg_hub
To: David Miller <davem@davemloft.net>
Cc: perex@perex.cz, floeff@mathematik.uni-stuttgart.de,
        acme@conectiva.com.br, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <1513158468-14382-1-git-send-email-baijiaju1990@gmail.com>
 <20171213.162032.129766742729458957.davem@davemloft.net>
 <18472c42-4eaf-7189-a16f-489a706cba3e@gmail.com>
 <20171213.223432.393103915049464102.davem@davemloft.net>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <dda22831-e9de-e9f0-ce4e-986b3a3219dc@gmail.com>
Date: Thu, 14 Dec 2017 11:56:59 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <20171213.223432.393103915049464102.davem@davemloft.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Sorry,

I think I know your meaning now.

Maybe we can unlock the spinlock before "schedule_timeout_interruptible" 
and then lock again?
Like:
     spin_unlock(...);
     schedule_timeout_interruptible(1);
     spin_lock(...);


Best wishes,
Jia-Ju Bai


On 2017/12/14 11:34, David Miller wrote:
> From: Jia-Ju Bai <baijiaju1990@gmail.com>
> Date: Thu, 14 Dec 2017 11:13:15 +0800
>
>> Thanks for reply :)
>> I think I should use "udelay(100000/HZ)" instead, do you think it is
>> right?
> The delay is too long, please do not ignore that part of my critique
> of your change.
>
> You cannot delay so long under a lock, that's why the code is trying
> to use a sleeping delay.
>
> I'm not going to explain this problem another time.