From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CA7FC433FE for ; Tue, 8 Feb 2022 22:29:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1387846AbiBHW3S (ORCPT ); Tue, 8 Feb 2022 17:29:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1387000AbiBHVkd (ORCPT ); Tue, 8 Feb 2022 16:40:33 -0500 Received: from alexa-out.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E22DC0612B8; Tue, 8 Feb 2022 13:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1644356432; x=1675892432; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=81EhCrIS85r447vT38r3+hOQsy/Ae4x5VMVVwLgPxDU=; b=eIJaJveWresab3hxkX0aQizJkKFtJuI1u2fgkj9titdZ608Yfz0Nj+wW hbgVT6YgM06GATpG13UOoj8nqbFz3507qZpasEAFq4fKHWAQXZtYpICn2 R1Wb3Ak5+RzzydO4vfJ40z9Oy0t7H/Um7qI4LbiIkhfNQFpvXp12eHKnM w=; Received: from ironmsg09-lv.qualcomm.com ([10.47.202.153]) by alexa-out.qualcomm.com with ESMTP; 08 Feb 2022 13:40:32 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg09-lv.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Feb 2022 13:40:31 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Tue, 8 Feb 2022 13:40:31 -0800 Received: from [10.111.162.111] (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Tue, 8 Feb 2022 13:40:28 -0800 Message-ID: Date: Tue, 8 Feb 2022 13:40:26 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins Content-Language: en-US To: Johannes Berg , CC: , , , , , , , , , , References: <1644349472-31077-1-git-send-email-quic_abhinavk@quicinc.com> <8d67484c7e4b9fb4560d2eca1f71c75fde8bae0d.camel@sipsolutions.net> From: Abhinav Kumar In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Johannes On 2/8/2022 1:12 PM, Johannes Berg wrote: > On Tue, 2022-02-08 at 13:04 -0800, Abhinav Kumar wrote: >> >> It opened the file rightaway but could not finish reading. >> >> The device gets deleted so the corresponding /data will disappear too ( >> as the data node is under devcd*/data) > > Yeah but even if the file disappears, the open file descriptor is still > there, no? Does sysfs somehow make those disappear? I know debugfs does > (now, to some extent, it didn't always), but I thought sysfs was > refcounting things and didn't do that? > > What did the userspace actually see? read() returned 0 so EOF? > > (I guess I could test it, but it's getting late) > > Your other questions are related - you need to consider the file in > sysfs and the open file descriptor separately. > > johannes > I am checking what usermode sees and will get back ( I didnt see an error do most likely it was EOF ). I didnt follow the second part. If the file descriptor read returns EOF, even if we consider them separate how will it resolve this issue? My earlier questions were related to fixing it in devcoredump to detect and fix it there. Are you suggesting to fix in usermode instead? How? Thanks Abhinav