From patchwork Fri Aug 27 21:29:59 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Stultz X-Patchwork-Id: 503403 Delivered-To: patches@linaro.org Received: by 2002:a17:906:f46:0:0:0:0 with SMTP id h6csp1573471ejj; Fri, 27 Aug 2021 14:30:04 -0700 (PDT) X-Received: by 2002:a17:90a:fa01:: with SMTP id cm1mr12816305pjb.10.1630099804549; Fri, 27 Aug 2021 14:30:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630099804; cv=none; d=google.com; s=arc-20160816; b=dSrSrDz+XTWLjkF0LytyEld0XzVsHV2cS+J0WpwLQR4Vk0aTG6cXX36tNzIlfgbF/e C+tD3ZYNbEkFtzyhj+iEpjAfJh/iGn99yU5Wl4+hyN0IJQWMkroHV7UB937sUW+sf7Cl VCwLBXjMO859TGHDqFuWPzyCA0Sy5jTDxRkiTqoxRcSE09o4a2JwWZvj1SFkxCzvpxeC ES/xjzVZVcLX/Ir5XZRaR9rRmQmecAOQaeJXxAozmVS1d1msRe3l6VVT0Lja5wwihxS2 7NiNG0CHz6mYnDB7NHnOujwJSy4Pfor1RQU3zKpntsXzCJ7TXu07sD9wCM6betsStnNl beRw== 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=KvR0cFjmaEwCTvDjSRBS97kq4es6eQEEooSk8h9VrwQ=; b=bgXjP6vzXqtIVyNj3fnD0I+sBxsakUlL2HOpt1Kvp2wVcoknpzah1Voj/fsk3CnJx0 7gd/QqPnyHDLkjdxZYDYK9CquaLlhTjbSVGZLx4AWnYrwngRz8TlIbYF5aQrrkQAoH5h 1EI1L9GoeYQyXCRs7lE3Eb6km6I5yHwioRaidUuqTr8oGLQfHtdExoFmnKwqkVsbUENf DDctYVRTM6nMxugsvCn7EIRaQOOwCkDH/hh/HBSW0aR3hEr5WLgKHYCTe6C5fSc97Q3N /buzbM+wUN5mG3qLY++N3bPBwmaNPHSXolCUn3zK5RdhdVAPY/BeDElFubbxr9yaQgY+ QHTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=z09sILYS; 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 h11sor4864911plk.48.2021.08.27.14.30.04 for (Google Transport Security); Fri, 27 Aug 2021 14:30:04 -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=z09sILYS; 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=KvR0cFjmaEwCTvDjSRBS97kq4es6eQEEooSk8h9VrwQ=; b=z09sILYSUgR2jbRQUNHUlXXlP8e5aJ5eybSY8N/2+jPXjK3ZOkt8eU9O4ionKHszbw WXryyrThfE4qe34HYqiQjQfHemlcoMzmGzIRMPC6rUyt048rSe7g80oEyiTkNngyaoSH mFEpL/0P22Lk15ttHkLT8kEgomv0Q6/j+H/uNN9tF24vgsPfrJs5T9+kfK/PLPGvoe/N F9yNVsHfsW10hItnN0bUQ7Ent4tsX1OQqsTrtJuX3GGMn+mGoqxadaAyeRBW2AUJMjJw TMTuxUFma38xCXb6+YkwvdfuULzZvVeZm1s7AhTRr9iBGeVbi1mo4SwlbJcQLc86B9Wc F8Aw== 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=KvR0cFjmaEwCTvDjSRBS97kq4es6eQEEooSk8h9VrwQ=; b=JAGqZhAA/rc8CIW5N2lpcTY/e9GCV8Z7SoDglpo5ducl9zCPm0EyY8C1foOddkMxnR RBwtTZ2D4A4q8iveH8KYJ2PZALr7IyMGrk/N+0IcJckAu6uHlFkr6egbcFKbPg7yX/yM hF3Lj7j2DlyH6td1NouI0COX81sCnRMTMnOmqVvrHXvYOAw5b77y/I14L/LaqpBuqAZF sWWZLfvyAU443bMxKsu3e92yfhpkTl3mojHRhv1/utNE/JboDzyTRonPrXXBGa1YfWZl jieWEiFb2JRIRiIv+oqc+8LNX34Qx6o9gYxY6JdgkoDiPXwQNwnCearmKO23qSerKb0Y 4vsw== X-Gm-Message-State: AOAM533scDqw8x9eUxxL5h3xrYAXCBBRHnICQNTQuRtO2uz+dnZCjXR5 LUx1znZ8IZC1bm8FeAve5iUoxL+5 X-Google-Smtp-Source: ABdhPJz6cTBtiOMp7VKk2+JNGYJ0jE01saVjdJm3fFm8z7YECNsOhlJeMv15s9TuuQl1gpgvDjvlWw== X-Received: by 2002:a17:902:c3c6:b0:138:80f2:f642 with SMTP id j6-20020a170902c3c600b0013880f2f642mr9509811plj.42.1630099804077; Fri, 27 Aug 2021 14:30:04 -0700 (PDT) Return-Path: Received: from localhost.localdomain ([2601:1c2:680:1319:692:26ff:feda:3a81]) by smtp.gmail.com with ESMTPSA id u22sm6645211pfi.143.2021.08.27.14.30.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Aug 2021 14:30:03 -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 21:29:59 +0000 Message-Id: <20210827212959.1633818-1-john.stultz@linaro.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 (Sorry for the resend, had to subscribe to the list) 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;