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 S1752471AbdLNDN1 (ORCPT <rfc822;w@1wt.eu>);
        Wed, 13 Dec 2017 22:13:27 -0500
Received: from mail-pf0-f196.google.com ([209.85.192.196]:38817 "EHLO
        mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751803AbdLNDNZ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 13 Dec 2017 22:13:25 -0500
X-Google-Smtp-Source: ACJfBoshswpqZpvaWDid0My/0njROQMC4FQrN3c3+jjWhdIDzMmdhY7QEScbtegWP6vfnyZhhHe+OQ==
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>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
Message-ID: <18472c42-4eaf-7189-a16f-489a706cba3e@gmail.com>
Date: Thu, 14 Dec 2017 11:13:15 +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.162032.129766742729458957.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

Thanks for reply :)
I think I should use "udelay(100000/HZ)" instead, do you think it is right?


Thanks,
Jia-Ju Bai


On 2017/12/14 5:20, David Miller wrote:
> I want you to review all of your patches and resend them after you
> have checked them carefully.
>
> The first patch I even looked at, this one, is buggy.
>
> You changed a schedule_timeout_interruptible(1) into a udelay(10)
>
> That's not right.
>
> schedule_timeout_interruptible() takes a "jiffies" argument, which
> is a completely different unit than udelay() takes.  You would have
> to scale the argument to udelay() in some way using HZ.
>
> Furthermore, the udelay argument you would come up with would
> be way too long to be appropirate in this atomic context.
>
> That's why the code tries to use a sleeping timeout, a long wait is
> necessary here.