Received: by 10.223.176.46 with SMTP id f43csp302321wra; Thu, 25 Jan 2018 22:27:07 -0800 (PST) X-Google-Smtp-Source: AH8x22793uiditsZEDzSvJTKCE9WYZBztryP9xZ/Wj7XkoQmnSnJQIikAYOKhvc14N+agKCCn5yp X-Received: by 10.98.106.10 with SMTP id f10mr5220662pfc.42.1516948027507; Thu, 25 Jan 2018 22:27:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516948027; cv=none; d=google.com; s=arc-20160816; b=bVmSG/N4snebsSo9eWj75QbRjOddrrKMdLjlyHsNclEzXLiMdUGcJFUjEW078Mt4ZT mBbIk8LzpuwAwHSjicWbkZQzGUHzxbpUGqLrQfprT5JJcKSdT4HKnMK35AtcZRgWLJiQ pkJe6/vmfiTyIVuEeyOWc3a78prP8Oun7xE/NIOBIYDB6U3b5lIJQHzgUAus5axNtClS n1Ygv6fjLpl9Z477nctBEm+qgQRCdrG+vpeG4axxxagtjqzXwI/8h4G3EwgECYCiJiwu JKdqUNu9cDMMBe1QfXUS5UI18Er1exgbT6TYW+mL44V+GgFJE0lYl2zIrmk7ocN5zyvn 3ytQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=sLePplFfTkYs9KTAge89r+cQaasZ4ayH9kIelbKbMIc=; b=0NzQe9JS/cvdWdiJeZ6yc31f9cy6ug7pfnCMX7Y2CwbL/yLuWx2+8Lw9Iqj0Xcb3aJ 4Vzn4cSfiEW3SBM3mjm6Gcg2HMNOfIRQEAhHTz8o9zGB4lZ+JqZqyFPODukL9JyCscCi cu3jeVAakLbOB6WXNVxcDSCzOcn8+rTT/81Y0b5D10qFYYGTM4Y48O5mKJnXRHfDSaqB o++o1OkxqhyfaPDv4WvYo4Tms2kU/1vvOEQ/ViyCfSG2MXRyYoxJS8Y0hEO1Q48hxN5W JbeAv0zjgFgpIN6xJywMTDnZxE9l9OvY36wsRRvIjj7qI9se8iMx0LBoo0loUz0x0mWy vkVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o184si2586868pga.818.2018.01.25.22.26.42; Thu, 25 Jan 2018 22:27:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751706AbeAZG0I (ORCPT + 99 others); Fri, 26 Jan 2018 01:26:08 -0500 Received: from mga11.intel.com ([192.55.52.93]:31990 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbeAZG0H (ORCPT ); Fri, 26 Jan 2018 01:26:07 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2018 22:26:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,415,1511856000"; d="scan'208";a="22681746" Received: from fengzhou-mobl.ccr.corp.intel.com (HELO [10.255.27.109]) ([10.255.27.109]) by FMSMGA003.fm.intel.com with ESMTP; 25 Jan 2018 22:26:05 -0800 Subject: Re: [PATCH arm/aspeed/ast2500 v2] ipmi: add an Aspeed KCS IPMI BMC driver To: minyard@acm.org, joel@jms.id.au, avifishman70@gmail.com, openbmc@lists.ozlabs.org, openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Cc: andriy.shevchenko@intel.com References: <1516810009-16353-1-git-send-email-haiyue.wang@linux.intel.com> From: "Wang, Haiyue" Message-ID: <9b194ad6-d277-44e5-54b0-c7e453a6fb0c@linux.intel.com> Date: Fri, 26 Jan 2018 14:26:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-01-25 01:48, Corey Minyard wrote: > On 01/24/2018 10:06 AM, Haiyue Wang wrote: >> The KCS (Keyboard Controller Style) interface is used to perform in-band >> IPMI communication between a server host and its BMC (BaseBoard >> Management >> Controllers). >> >> This driver exposes the KCS interface on ASpeed SOCs (AST2400 and >> AST2500) >> as a character device. Such SOCs are commonly used as BMCs and this >> driver >> implements the BMC side of the KCS interface. >> >> Signed-off-by: Haiyue Wang >> >> --- > >> + >> +static ssize_t kcs_bmc_read(struct file *filp, char *buf, >> +                size_t count, loff_t *offset) >> +{ >> +    struct kcs_bmc *kcs_bmc = file_kcs_bmc(filp); >> +    ssize_t ret = -EAGAIN; >> + > > This function still has some issues. > > You can't call copy_to_user() with a spinlock held or interrupts > disabled. > To handle readers, you probably need a separate mutex. > > Also, this function can return -EAGAIN even if O_NONBLOCK is not set if > kcs_bmc->data_in_avail changes between when you wait on the event > and when you check it under the lock. > > You also clear data_in_avail even if the copy_to_user() fails, which is > wrong. > > I believe the best way to handle this would be to have the spinlock > protect the inner workings of the state machine and a mutex handle > copying data out, setting/clearing the running flag (thus a mutex > instead of spinlock in open and release) and the ioctl settings (except > for abort where you will need to grab the spinlock). > > After the wait event below, grab the mutex.  If data is not available > and O_NONBLOCK is not set, drop the mutex and retry.  Otherwise > this is the only place (besides release) that sets data_in_avail to > false. > Do the copy_to_user(), grab the spinlock, clear data_in_avail and > data_in_idx, then release the lock and mutex.  If you are really > adventurous you can do this without grabbing the lock using > barriers, but it's probably not necessary here. > The main race is data_in and data_out memory copy from & to between one user-land (ipmid) and the irq handler. If separates the copy_to_user into two parts: check the 'access_ok(VERIFY_WRITE, to, n)', if no errors, then grap the spinlock and irq disabled, then 'memcpy((void __force *)to, from, n);' It it right calling ? I will add a mutex to avoid spinlcok using as possible. >> +    if (!(filp->f_flags & O_NONBLOCK)) >> +        wait_event_interruptible(kcs_bmc->queue, >> +                     kcs_bmc->data_in_avail); >> + >> +    spin_lock_irq(&kcs_bmc->lock); >> + >> +    if (kcs_bmc->data_in_avail) { >> +        kcs_bmc->data_in_avail = false; >> + >> +        if (count > kcs_bmc->data_in_idx) >> +            count = kcs_bmc->data_in_idx; >> + >> +        if (!copy_to_user(buf, kcs_bmc->data_in, count)) >> +            ret = count; >> +        else >> +            ret = -EFAULT; >> +    } >> + >> +    spin_unlock_irq(&kcs_bmc->lock); >> + >> +    return ret; >> +} >> + > >> +    } >> + >> +    spin_unlock_irq(&kcs_bmc->lock); >> + >> +    return ret; >> +} >