Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1741926pxb; Wed, 9 Feb 2022 03:36:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJxLWgcdayY7SG8d+jtqO+EuEyrZa1UQyywUgurXatcTNpEByksdUd4DZhF5UO2xUhJdkmGy X-Received: by 2002:a17:90b:1647:: with SMTP id il7mr2907610pjb.119.1644406602624; Wed, 09 Feb 2022 03:36:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644406602; cv=none; d=google.com; s=arc-20160816; b=dNTa8ARE0Q9YRd0dgLNvrTdALrDmYhoYy/MB+42mJVdKtW1P7Qbu3w8TOBVmC49TPw w7/RvvyO/EWMse0rAYZQAMi0RNz1Z0YzklbXNu9gepI6+kbrBCGnQJmZRCdLF/BJbzvU dFlA0N/fV2t5AP8MO/jXbDOAaOMOPo3lzDs9DPzRyII2Agk1Ca7YZY+wZHxczbQjhcBl Kqh3fLfoa7EPnoHRAs+NnVjRAWiLaf3Q9etXpfGxh60tVdMS1lQ3YWRDBSXdOIcpDmEg L2EkbtamJjwWrniqDiQ683K8lgUPvop0NgUrKFgfCPkG3G8RjWPv0V0PK1p6BsSOXF4K DWUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=81EhCrIS85r447vT38r3+hOQsy/Ae4x5VMVVwLgPxDU=; b=uBrbvPSWkLj9q9emkyzjP9G1R3NXrtdDEKPvJCTxN72KdO1XoAG5so+kgkaPdtAFXn hBfUneXcp6ghEJQqqVNfe6UoM2eT/oOEbe49VAtaIrZUZCYVxPzp53yqZnmXK8wr/yvE PebCU1FUoz+iNKq7vvzKQvd+mb/FLY3NcmNGYaEi1vFOILRONpx3TcsgzeSkbzIqMgf2 Azjzb6zTfLN76qXtNvfBXGLVY72ymlAsNXwbC6jQXk5TambnmZd2K0p4Gh5yHQR12cGC NdnL07rfF/MvJk5NAlqBgppxw6oXZhdO2vBko7arBBOplxk3IV3+xBQx9E8q80Dr+OjV mWqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=eIJaJveW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q1si788738plx.465.2022.02.09.03.36.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 03:36:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=eIJaJveW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 59670E078226; Wed, 9 Feb 2022 01:54:32 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1387838AbiBHW3R (ORCPT + 99 others); Tue, 8 Feb 2022 17:29:17 -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) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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