From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD18815F32E for ; Mon, 29 Jul 2024 18:35:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722278143; cv=none; b=rlBE7AFrLMlXWsaE30rC5IVeDUE6XW/HnwP5rhPPjSOrAZn3BRa5fDRFG6Y/lhWA0xmgOsIBil4t9quQYCQKSkKFty7jVQRQEC4uoDtojpHzcO06H9P9D3kZOeCY+FxnjmOvfScOzK1MUqylDX+QIURV021lFgJgC2EEi+51LCw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722278143; c=relaxed/simple; bh=OWLMlW9nI4AoeJRIu2xE7z91rwpxUdo9FtEkVf832u4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UbbVR98y+SBko+9vhyADaSa861Ff/B2PS0slT519JeRJg+3GBUtnEALZKC7YDJv2vNWrGWtKn7tI1NaqTY6qydozD2cJ92qGohp60WAdCAJYo8pCWsP43aNmUp0SD2mJXL5+GtsQI6u2RLyqZaamlTyZm6IGbn2MtET71wSNTXI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=kjPnXLRN; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="kjPnXLRN" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1fc4aff530dso28235ad.0 for ; Mon, 29 Jul 2024 11:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1722278141; x=1722882941; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GekW6Drxgu1csmMta62dgFi3qy5FXE8VqaYgFnRbcnM=; b=kjPnXLRNaNCcVy/OkfYIC1cPnmoKf9W/paQpMjZJoQfSfc5CrTbAp1Msh5HmU09HA0 iN3iMxm39ujwMiSYR8jadqeQtvyHZ/sIWp7HAWv8iZUTRr3cChPeWiLOb2JhDMF7gXxQ 7JcKkHgnXEy8i7Tg8dmzcFH0d7a1ahk5aWbrxBYPWdf2TI0ebHe9C1IyGPGMm46L6Ieh JUWeEKJ/JnfOV/EkJn7HejwabzE4ofQ8R+uQ5WTXZSCoHiD/BRLjCA3JvLE0fpmMXCnR Cia1bIYzwxDSjFtGtEf/AVLngt8C7keTRB738e5stFnDbtuH1CK6ZpuInnhfHN2Wuodl mz7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722278141; x=1722882941; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GekW6Drxgu1csmMta62dgFi3qy5FXE8VqaYgFnRbcnM=; b=M0kUquhEo8WWiWvajud+uwMF1T/4BZ/7qO0WYxAH3qbHcgqw+FaRMUZj39dveLBdM9 yzJSjUQOiiDI7JYwMA/B3qwHXCsBgeQOCbeYZ/yY4R9kf+4Ew1iSpjkW/N12XugEp3OD yuoAWN6NVEILOEIO/5cBKrPJaN0+hXP6+giLTho35nPwCW3gFzk/areLRYbMbbYqCSa7 2rBXH+78DMKMJraidL8t0X/Io/CUJJmXIQDufp4oLYxCxzsr6rwgTXQiLhSsMrQF944d v+e03eLbAENvdmQUdtJURdlhP7Y097ll3ZrqYwZ9rWvnc7XLKYFbehsiLc4Pz9/nKtU1 PQUg== X-Forwarded-Encrypted: i=1; AJvYcCUtT1VkElihwkRV60Gjbjgxc4hGqkbEr5ePSKdpd1pXzAwEFH7qjoouyxWAFLrBE+jRYytO6Own7hqyO8rlGrov36m29zr8YDQ= X-Gm-Message-State: AOJu0Yw1ZyYI8F009rD0qk2gNF8DzOekBVyPiYlI5Bq0XNGX7XXi4mwd 9bEGfFhghjvWlAjfaekMIBqPoIu9J2k7nb88drzbyLDeWjjyU1c+EB9xp+5wLg== X-Google-Smtp-Source: AGHT+IFDW6XvLjcuBeaeEfqTb5/MYUs4HDyKi6Wro5NOVXcPidfha5m2d484zipsCXeKMFOtOjpatw== X-Received: by 2002:a17:902:fc8d:b0:1fd:d0c0:1a69 with SMTP id d9443c01a7336-1ff34d8afefmr907325ad.9.1722278133866; Mon, 29 Jul 2024 11:35:33 -0700 (PDT) Received: from google.com ([2620:15c:2d:3:c685:61bd:100e:aec7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fed7f1b80asm85755135ad.184.2024.07.29.11.35.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 11:35:33 -0700 (PDT) Date: Mon, 29 Jul 2024 11:35:28 -0700 From: Isaac Manjarres To: Christian Brauner Cc: tglx@linutronix.de, jstultz@google.com, "Rafael J. Wysocki" , Pavel Machek , Len Brown , Greg Kroah-Hartman , Alexander Viro , Jan Kara , saravanak@google.com, mjguzik@gmail.com, Manish Varma , Kelly Rossmoyer , kernel-team@android.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v6] fs: Improve eventpoll logging to stop indicting timerfd Message-ID: References: <20240703214315.454407-1-isaacmanjarres@google.com> <20240704-umsatz-drollig-38db6b84da7b@brauner> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Jul 09, 2024 at 02:04:43PM -0700, Isaac Manjarres wrote: > On Thu, Jul 04, 2024 at 04:03:59PM +0200, Christian Brauner wrote: > > On Wed, Jul 03, 2024 at 02:43:14PM GMT, Isaac J. Manjarres wrote: > > > From: Manish Varma > > > > > > We'll often see aborted suspend operations that look like: > > > > > > PM: suspend entry 2024-07-03 15:55:15.372419634 UTC > > > PM: PM: Pending Wakeup Sources: [timerfd] > > > Abort: Pending Wakeup Sources: [timerfd] > > > PM: suspend exit 2024-07-03 15:55:15.445281857 UTC > > > > > > From this, it seems a timerfd caused the abort, but that can be > > > confusing, as timerfds don't create wakeup sources. However, > > > eventpoll can, and when it does, it names them after the underlying > > > file descriptor. Unfortunately, all the file descriptors are called > > > "[timerfd]", and a system may have many timerfds, so this isn't very > > > useful to debug what's going on to cause the suspend to abort. > > > > > > To improve this, change the way eventpoll wakeup sources are named: > > > > > > 1) The top-level per-process eventpoll wakeup source is now named > > > "epollN:P" (instead of just "eventpoll"), where N is a unique ID token, > > > and P is the PID of the creating process. > > > > > > 2) Individual eventpoll item wakeup sources are now named > > > "epollitemN:P.F", where N is a unique ID token, P is PID of the creating > > > process, and F is the name of the underlying file descriptor. > > > > Fyi, that PID is meaningless or even actively misleading in the face of > > pid namespaces. And since such wakeups seem to be registered in sysfs > > globally they are visible to all containers. That means a container will > > now see some timerfd wakeup source with a PID that might just accidently > > correspond to a process inside the container. Which in turn also means > Thanks for your feedback on this, Christian. With regards to this > scenario: would it be useful to use a namespace ID, along with the PID, > to uniquely identify the process? If not, do you have a suggestion for > this? > > I understand that the proposed naming scheme has a chance of causing > collisions, however, it is still an improvement over the existing > naming scheme in terms of being able to attribute wakeups to a > particular application. > > > you're leaking the info about the creating process into the container. > > IOW, if PID 1 ends up registering some wakeup source the container gets > > to know about it. > Is there a general security concern about this? If not, can you please > elaborate why this is a problem? > Hey Christian, I just wanted to follow-up to see if you had a chance to go through my questions above? Thanks, Isaac