From patchwork Fri Aug 27 05:31:15 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 503371 Delivered-To: patches@linaro.org Received: by 2002:a02:6f15:0:0:0:0:0 with SMTP id x21csp936285jab; Thu, 26 Aug 2021 22:31:21 -0700 (PDT) X-Received: by 2002:a63:1542:: with SMTP id 2mr6404976pgv.102.1630042281265; Thu, 26 Aug 2021 22:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630042281; cv=none; d=google.com; s=arc-20160816; b=1J+MC/R+EuMdnD/zvXSRg3vQh65MSC4fm/SlGKQhAF82+Dhc0DjWbuOjM2eyd8UPw7 qwJTxg4Bcobgb8oasBQrIm35XKbXfhbhM+f0uWwvNE0JT3BzxsgCBW4biiT7IRmcVRON o/WOzX40fDWcXWlxgAiYCP+nwvT7bmqpwhURFRqvd0E/oue0Y8YPkXukJtat43SZKxD4 P7Rn3cw2e1ipS8giXASHX0QU7wauf0APMAMQhvfQAF4nWsEo4V4NhCNpilolSfKWLX/+ E984h7uNAs/k0AU4m4nPElgzK6hu0h2v9bpoKq7WD8wbf+ZOUUqJrYRO8IACoYPkc7QC +vug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=7rguHQdhzWH3Jm+CRHn9LM/eXejFRG/spkX6Lor7tTE=; b=R0iS+krnYWrNw3OBFxxNXuwFDnQ55bzKdKqZyA6pBfWzBGQKSj7bgLlelF2CONOYqt DCwB/6MhYHZIr7xO/IpmzyoWU+qPke/XnKVc5pXF2ugOVd7zeyksi0cdkA2dufgQzYWS 3nqaqxuwrHVUKKRwGyFHDyPD6gCFhzsIqYuw2NfeTERm2DauXJRHG2s+iqB8yY9GN4o8 l5zW3NOw87OobDo8KJxMBs0oltdIS2LIR1eHCtjScUgk1dwZlvIMKhYbNpA20AUGfoUH 5QnfoQL4YiGnOIUUOyDDY7RZPNZ4ds6p7lC9Oav5sL8Edx4MPadbALJNLH3M/hRScLGZ sxqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=L+rIBdAh; spf=pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=john.stultz@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id t3sor2745265pgv.27.2021.08.26.22.31.21 for (Google Transport Security); Thu, 26 Aug 2021 22:31:21 -0700 (PDT) Received-SPF: pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=L+rIBdAh; spf=pass (google.com: domain of john.stultz@linaro.org designates 209.85.220.41 as permitted sender) smtp.mailfrom=john.stultz@linaro.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=7rguHQdhzWH3Jm+CRHn9LM/eXejFRG/spkX6Lor7tTE=; b=L+rIBdAhBeH6uxLD8KfbQC1Od2siVq/25SS+T4OgMRutYjVR+Si/rQUIGhd5tTCdr7 t8mElWMnOM/Jfy7jPBRpScJUk2zX2HW2b5TXy8gBs8qK8MGbb4NQeHmUSoKqo1ragCO5 zOY3qzzPJO/GNsNCccbCldn5qf540poBEv7L//9iQu3d8RKg2MV50mDN3Pm0t4u7nsud DsgGjvk2aY2cRILwyAXgZIBBe9Wxg/v8A4RMTbiZ7f7Fi2+gGjQ6c9GUDArS2oEnM1jh dspvM/utfq2sUkahQI3wQo4qLnegGJYkDDSVdCdjQG643nwut+rgcuOB55tv/LaJWXB3 DhCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=7rguHQdhzWH3Jm+CRHn9LM/eXejFRG/spkX6Lor7tTE=; b=J8qy8dALWke2VFde6qxQaeZl8FGJTC8pViZ49wASeZ4FMrJvtifGW0Duy4247YyNNa zzjXEie8v+TQMHrjfWhmq1ZpPZoiK8h6B/F8QGXOCb1zvJ2/eZihxW7fk6oHtZYT8KJ5 jM0Nr94xlfkb4GuqBo2MPjaianc9BQ/Lv13lurUrX+sLTWutvlHqKP0TO3hFnkkfsvKr BUZd/KSuFnoBwda31MCTdQumQLwQbkVFJ2OXx7slBL1MzJSoQIvtRy0rw+/W3nuM5eV3 dRYyPWWMJkNewKZKkOHoT59HWWiiL5rcMuSaVENqORngrafPg8l3c+3/zE7SdZHNiJg8 zsIA== X-Gm-Message-State: AOAM5312hC+dK6ZOEAtqLUdDOGMsPs22sRE+qNU08a8yRGzUhkZVQKTb zlK6bFAVtmCtaZ+m9sut4kfBBMYF X-Google-Smtp-Source: ABdhPJzm+OmbSKUougSHFNtVM8VDxp5qmFAJWpeEBPbaC87SoCLdxLy2jI6f7WCPj9jI5IPUiw9voA== X-Received: by 2002:a63:4b53:: with SMTP id k19mr6463439pgl.3.1630042280845; Thu, 26 Aug 2021 22:31:20 -0700 (PDT) Return-Path: Received: from localhost.localdomain ([2601:1c2:680:1319:692:26ff:feda:3a81]) by smtp.gmail.com with ESMTPSA id n185sm5051554pfn.171.2021.08.26.22.31.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 22:31:20 -0700 (PDT) From: John Stultz To: ltp@lists.linux.it Cc: John Stultz , Stanislav Kholmanskikh , Jan Stancek , Suren Baghdasaryan , Todd Kjos , Sumit Semwal , YongQin Liu Subject: [RFC][PATCH] memcg/control: Fix dropped messages from fifo to avoid leaving mem_process running Date: Fri, 27 Aug 2021 05:31:15 +0000 Message-Id: <20210827053115.3172009-1-john.stultz@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 In testing with AOSP, I ran across some odd behavior where the memcg_control_test.sh would get stuck in zombie state, and the mem_process process would be stuck running. After some debugging, I found mem_process was not getting the quit message ("x") over the status_pipe fifo, and would keep running after the test was finished. In the memcg_control_test.sh script, there is some curious behavior, as after it sends the allocate message ("m") and then checks to see if the mem_process has been killed, if it was not killed, it again sends the allocate ("m") message, which I don't quite understand the reason for: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/controllers/memcg/control/memcg_control_test.sh#L72 The memcg_control_test.sh then immediately sends the quit message ("x"): https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/controllers/memcg/control/memcg_control_test.sh#L73 Which is what the mem_process was not receiving. Removing the second allocate ("m") message seemed to avoid the problem. And digging further this seems to be due to the fact that the mem_process is open/read/closing the fifo each loop iteration: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/controllers/memcg/control/mem_process.c#L109 My understanding is fifos only function when both sides are open, having two commands sent quickly in succession, the first will be read but as the fifo is then closed, the second message may get dropped before the fifo is re-opened and read from. Thus to avoid this, this patch reworks the fifo handling so the mem_process will create the fifo, open it, and then do its main loop processing keeping the fifo open. Once it receieves a quit message, it will then close and remove the fifo. So far this has resolved the issue for me. I don't pretend to be a fifo expert, so feedback or suggestions for other approaches would be welcome! Cc: Stanislav Kholmanskikh Cc: Jan Stancek Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: Sumit Semwal Cc: YongQin Liu Signed-off-by: John Stultz --- .../controllers/memcg/control/mem_process.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) -- 2.25.1 diff --git a/testcases/kernel/controllers/memcg/control/mem_process.c b/testcases/kernel/controllers/memcg/control/mem_process.c index efe2fb3e3..6c1b36ca6 100644 --- a/testcases/kernel/controllers/memcg/control/mem_process.c +++ b/testcases/kernel/controllers/memcg/control/mem_process.c @@ -101,25 +101,20 @@ void mem_map(void) /* * done: retrieve instructions from the named pipe */ -char action(void) +char action(int fd) { char ch; - int fd; - - if ((fd = open(STATUS_PIPE, O_RDONLY)) == -1) - err(6, "Error opening named pipe"); if (read(fd, &ch, 1) == -1) err(7, "Error reading named pipe"); - close(fd); - return ch; } int main(int argc, char **argv) { int ret; + int fd; char ch; process_options(argc, argv); @@ -129,13 +124,18 @@ int main(int argc, char **argv) if (ret == -1 && errno != EEXIST) errx(1, "Error creating named pipe"); + if ((fd = open(STATUS_PIPE, O_RDONLY)) == -1) + err(6, "Error opening named pipe"); + do { - ch = action(); + ch = action(fd); if (ch == 'm') mem_map(); } while (ch != 'x'); + close(fd); + remove(STATUS_PIPE); return 0;