Received: by 2002:a05:7412:6592:b0:d7:7d3a:4fe2 with SMTP id m18csp1446396rdg; Sat, 12 Aug 2023 01:18:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGO1DSlhyOu07libXr/M3OFh1Lr+a4kO79RmJdj2zJ7M+sADOTtcZ09WrCuxKFsTfyHPRCa X-Received: by 2002:a05:6402:5177:b0:523:1f4d:4029 with SMTP id d23-20020a056402517700b005231f4d4029mr3284151ede.21.1691828282679; Sat, 12 Aug 2023 01:18:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691828282; cv=none; d=google.com; s=arc-20160816; b=CicYksWFzwm9bvr4IX7GTuj0MgfdytMpjT/EIfeB5dqnyN1Qrv1ltXn+J+cZ0TJaum 7Lw/E4R93eiGxQV5CuIJkBl3oYpt0ISa6n3U8ll63fXRwNyjom0Sj4n+LyauOS7f5MdT +/XAYRjgb36jmG23Jq9G6TkkJWudUfICCNefl7PYAYfARMZpXUJ+jHLhJCodPI1BmfcB HpsjzdnNAEvU8pcSs++5D5POn+Yn5ua+QCc1ojPdODEYSaxyob+iUx3JvsLb0WZac8uC 8v8geYeOzuyIBzmAthHVDDSmow9WZlSDt1pAsswxWvXtyuM/o27PDii0G/cglcJKI8RI K57g== 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; bh=fJnR+cYvX285Us4nvOKuDVUTUO+hU71FgtuMi++e85g=; fh=4QO5XJh861Rqv4qVOuH1LKENj2zF+C/tTAJTAsEomEU=; b=BwPwIEG1fgRDhl4yV06Bppzrm5lyOiuUuyyTazoWWuqGRyHTAJFJjY8+/iexmw47OF U9bN33TJyaBXZC+8kMkAXBDjZ2zUktdehMn5skw4WJgxo1xxn2/TGU6bIeLYffHovJjH 3C39Jzn/NQIhpi3posAqGZQqapjl1tlspShtuUZuTfucYfhoeCaPg+aC7sMgNtAEYVlT palv9BdMI6EjfrojcTV9tzKsuCiCPcstbaIImzUiPY++xO+sRHi5GZMF+WYrevuGDJDD Menk0U5RzLFEOa0jiXbWIgJUQSXJ57P0sDtOwVnzbfzYX3wafF8yGW8WIUGNXHPjelYC kVzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v19-20020a056402185300b0052370772262si4960051edy.131.2023.08.12.01.17.36; Sat, 12 Aug 2023 01:18:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234144AbjHLHiO (ORCPT + 99 others); Sat, 12 Aug 2023 03:38:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44140 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229959AbjHLHiN (ORCPT ); Sat, 12 Aug 2023 03:38:13 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF84419A4; Sat, 12 Aug 2023 00:38:14 -0700 (PDT) Received: from dggpeml500012.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RNCC12HpMzTmNK; Sat, 12 Aug 2023 15:36:13 +0800 (CST) Received: from [10.67.110.218] (10.67.110.218) by dggpeml500012.china.huawei.com (7.185.36.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Sat, 12 Aug 2023 15:38:12 +0800 Message-ID: Date: Sat, 12 Aug 2023 15:38:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH] tracing: Fix race when concurrently splice_read trace_pipe Content-Language: en-US To: Steven Rostedt CC: , , , References: <20230810123905.1531061-1-zhengyejian1@huawei.com> <20230811152525.2511f8f0@gandalf.local.home> From: Zheng Yejian In-Reply-To: <20230811152525.2511f8f0@gandalf.local.home> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.110.218] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml500012.china.huawei.com (7.185.36.15) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 On 2023/8/12 03:25, Steven Rostedt wrote: > On Thu, 10 Aug 2023 20:39:05 +0800 > Zheng Yejian wrote: > >> When concurrently splice_read file trace_pipe and per_cpu/cpu*/trace_pipe, >> there are more data being read out than expected. > > Honestly the real fix is to prevent that use case. We should probably have > access to trace_pipe lock all the per_cpu trace_pipes too. > > -- Steve > Hi~ Reproduction testcase is show as below, it can always reproduce the issue in v5.10, and after this patch, the testcase passed. In v5.10, when run `cat trace_pipe > /tmp/myfile &`, it call sendfile() to transmit data from trace_pipe into /tmp/myfile. And in kernel, .splice_read() of trace_pipe is called then the issue is reproduced. However in the newest v6.5, this reproduction case didn't run into the .splice_read() of trace_pipe, because after commit 97ef77c52b78 ("fs: check FMODE_LSEEK to control internal pipe splicing"), non-seekable trace_pipe cannot be sendfile-ed. ``` repro.sh #!/bin/bash do_test() { local trace_dir=/sys/kernel/tracing local trace=${trace_dir}/trace local old_trace_lines local new_trace_lines local tempfiles local testlog="trace pipe concurrency issue" local pipe_pids local i local write_cnt=1000 local read_cnt=0 local nr_cpu=`nproc` # 1. At first, clear all ring buffer echo > ${trace} # 2. Count how many lines in trace file now old_trace_lines=`cat ${trace} | wc -l` # 3. Close water mark so that reader can read as event comes echo 0 > ${trace_dir}/buffer_percent # 4. Read percpu trace_pipes into local file on background. # Splice read must be used under command 'cat' so that the racy # issue can be reproduced !!! i=0 while [ ${i} -lt ${nr_cpu} ]; do tempfiles[${i}]=/tmp/percpu_trace_pipe_${i} cat ${trace_dir}/per_cpu/cpu${i}/trace_pipe > ${tempfiles[${i}]} & pipe_pids[${i}]=$! let i=i+1 done # 5. Read main trace_pipe into local file on background. # The same, splice read must be used to reproduce the issue !!! tempfiles[${i}]=/tmp/main_trace_pipe cat ${trace_dir}/trace_pipe > ${tempfiles[${i}]} & pipe_pids[${i}]=$! echo "Take a break, let readers run." sleep 3 # 6. Write events into ring buffer through trace_marker, so that # hungry readers start racing these events. i=0 while [ ${i} -lt ${write_cnt} ]; do echo "${testlog} <${i}>" > ${trace_dir}/trace_marker let i=i+1 done # 7. Wait until all events being consumed new_trace_lines=`cat ${trace} | wc -l` while [ "${new_trace_lines}" != "${old_trace_lines}" ]; do new_trace_lines=`cat ${trace} | wc -l` sleep 1 done echo "All written events have been consumed." # 8. Kill all readers and count the events readed i=0 while [ ${i} -lt ${#pipe_pids[*]} ]; do local num kill -9 ${pipe_pids[${i}]} wait ${pipe_pids[${i}]} num=`cat ${tempfiles[${i}]} | grep "${testlog}" | wc -l` let read_cnt=read_cnt+num let i=i+1 done # 9. Expect to read events as much as write if [ "${read_cnt}" != "${write_cnt}" ]; then echo "Test fail: write ${write_cnt} but read ${read_cnt} !!!" return 1 fi # 10. Clean temp files if test success i=0 while [ ${i} -lt ${#tempfiles[*]} ]; do rm ${tempfiles[${i}]} let i=i+1 done return 0 } do_test ``` -- Zheng Yejian