From: Hugh Dickins <email@example.com> To: Al Viro <firstname.lastname@example.org> Cc: Hugh Dickins <email@example.com>, Andrew Morton <firstname.lastname@example.org>, "Darrick J. Wong" <email@example.com>, Matej Kupljen <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH] tmpfs: fix link accounting when a tmpfile is linked in Date: Mon, 18 Feb 2019 23:23:14 -0800 (PST) [thread overview] Message-ID: <alpine.LSU.firstname.lastname@example.org> (raw) In-Reply-To: <20190219054807.GX2217@ZenIV.linux.org.uk> On Tue, 19 Feb 2019, Al Viro wrote: > On Mon, Feb 18, 2019 at 09:37:52PM -0800, Hugh Dickins wrote: > > From: "Darrick J. Wong" <email@example.com> > > > > tmpfs has a peculiarity of accounting hard links as if they were separate > > inodes: so that when the number of inodes is limited, as it is by default, > > a user cannot soak up an unlimited amount of unreclaimable dcache memory > > just by repeatedly linking a file. > > > > But when v3.11 added O_TMPFILE, and the ability to use linkat() on the fd, > > we missed accommodating this new case in tmpfs: "df -i" shows that an > > extra "inode" remains accounted after the file is unlinked and the fd > > closed and the actual inode evicted. If a user repeatedly links tmpfiles > > into a tmpfs, the limit will be hit (ENOSPC) even after they are deleted. > > > > Just skip the extra reservation from shmem_link() in this case: there's > > a sense in which this first link of a tmpfile is then cheaper than a > > hard link of another file, but the accounting works out, and there's > > still good limiting, so no need to do anything more complicated. > > > > Fixes: f4e0c30c191 ("allow the temp files created by open() to be linked to") > > Reported-by: Matej Kupljen <firstname.lastname@example.org> > > Signed-off-by: Darrick J. Wong <email@example.com> > > Signed-off-by: Hugh Dickins <firstname.lastname@example.org> > > FWIW, Acked-by: Al Viro <email@example.com> It's Worth A Lot, thanks Al. And I apologize for the cheeky "Fixes" line, when a fair view would blame me for earlier adding the weirdness fixed. > > Or I can drop it into vfs.git - up to you. Andrew usually gathers the mm/shmem.c mods (unless it's you doing an fs-wide sweep), so I was pointing it towards him; and I don't think it's in dire need of a last minute rush to 5.0, though no harm in there either. I'll say leave it to Andrew - and leave it to him to say the reverse :) Thanks, Hugh
next prev parent reply other threads:[~2019-02-19 7:23 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-02-19 5:37 Hugh Dickins 2019-02-19 5:37 ` Hugh Dickins 2019-02-19 5:48 ` Al Viro 2019-02-19 7:23 ` Hugh Dickins [this message] 2019-02-19 7:23 ` Hugh Dickins
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LSU.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] tmpfs: fix link accounting when a tmpfile is linked in' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.