Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751380AbeAEHpv (ORCPT + 1 other); Fri, 5 Jan 2018 02:45:51 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:57112 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751268AbeAEHpu (ORCPT ); Fri, 5 Jan 2018 02:45:50 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 886F560272 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=gkohli@codeaurora.org Subject: Re: [PATCH] tty: fix data race in n_tty_receive_buf_common From: "Kohli, Gaurav" To: Alan Cox Cc: jslaby@suse.com, gregkh@linuxfoundation.org, mikey@neuling.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <1514987332-14122-1-git-send-email-gkohli@codeaurora.org> <20180103193807.465e054e@alans-desktop> <0a456419-c836-08cf-070b-a254fb702b75@codeaurora.org> <20180104110920.169a1fe5@alans-desktop> <0dbd1f05-4c94-d1cc-3858-7bd4d38b9212@codeaurora.org> <20180104143716.5b09b1c7@alans-desktop> <93a7bd73-1123-90a7-b22d-02964ba29fb0@codeaurora.org> Message-ID: <999c5499-05c7-4702-77a7-dfb56ba577d2@codeaurora.org> Date: Fri, 5 Jan 2018 13:15:45 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <93a7bd73-1123-90a7-b22d-02964ba29fb0@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Alan, >>> >>> Can you make that code available otherwise it's impossible to see >>> what the problem might be. > >  https://source.codeaurora.org/quic/la/kernel/msm-4.9/tree/drivers/tty/serial?h=msm-4.9  As discussed , there not seems a problem as we are getting print request even when port seems to closed. tty_ldisc_lock(tty, 5 * HZ);  tty_ldisc_setup(tty);  tty_ldisc_unlock(tty) But in above lock,  there is a chance when flush_to_ldisc will occur first and acquired a lock in tty_ldisc_ref itself. So this may fail, I am not much sure here, Please correct me, If i am missing something here. > So can not we simply return from flush_to_ldisc ,when we know > disc_data is not valid like > we are doing for tty and ldisc already? > > if (tty->disc_data == NULL) { >                 tty_ldisc_deref(disc); >                 return; >         } > > > > Regards Gaurav -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.