Signed-off-by: Al Viro <[email protected]>
---
fs/internal.h | 1 +
include/linux/dcache.h | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/internal.h b/fs/internal.h
index 9e9fc629f935..d9a920e2636e 100644
--- a/fs/internal.h
+++ b/fs/internal.h
@@ -219,6 +219,7 @@ extern void shrink_dcache_for_umount(struct super_block *);
extern struct dentry *__d_lookup(const struct dentry *, const struct qstr *);
extern struct dentry *__d_lookup_rcu(const struct dentry *parent,
const struct qstr *name, unsigned *seq);
+extern void d_genocide(struct dentry *);
/*
* pipe.c
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index 8c5e3bdf1147..b4324d47f249 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -243,9 +243,6 @@ extern void d_invalidate(struct dentry *);
/* only used at mount-time */
extern struct dentry * d_make_root(struct inode *);
-/* <clickety>-<click> the ramfs-type tree */
-extern void d_genocide(struct dentry *);
-
extern void d_mark_tmpfile(struct file *, struct inode *);
extern void d_tmpfile(struct file *, struct inode *);
--
2.39.2
On Fri, 24 Nov 2023 at 07:08, Al Viro <[email protected]> wrote:
>
> Signed-off-by: Al Viro <[email protected]>
> ---
> fs/internal.h | 1 +
> include/linux/dcache.h | 3 ---
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/internal.h b/fs/internal.h
> index 9e9fc629f935..d9a920e2636e 100644
> --- a/fs/internal.h
> +++ b/fs/internal.h
> @@ -219,6 +219,7 @@ extern void shrink_dcache_for_umount(struct super_block *);
> extern struct dentry *__d_lookup(const struct dentry *, const struct qstr *);
> extern struct dentry *__d_lookup_rcu(const struct dentry *parent,
> const struct qstr *name, unsigned *seq);
> +extern void d_genocide(struct dentry *);
Seriously, who came up with THAT name? "Genocide" is not a nice term,
not even if you ignore political correctness.
Or what will be next? d_holodomor()? d_massmurder()? d_execute_warcrimes()?
Ced
>
> /*
> * pipe.c
> diff --git a/include/linux/dcache.h b/include/linux/dcache.h
> index 8c5e3bdf1147..b4324d47f249 100644
> --- a/include/linux/dcache.h
> +++ b/include/linux/dcache.h
> @@ -243,9 +243,6 @@ extern void d_invalidate(struct dentry *);
> /* only used at mount-time */
> extern struct dentry * d_make_root(struct inode *);
>
> -/* <clickety>-<click> the ramfs-type tree */
> -extern void d_genocide(struct dentry *);
> -
> extern void d_mark_tmpfile(struct file *, struct inode *);
> extern void d_tmpfile(struct file *, struct inode *);
>
> --
> 2.39.2
>
>
--
Cedric Blancher <[email protected]>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
On Fri, Nov 24, 2023 at 07:35:34AM +0100, Cedric Blancher wrote:
> On Fri, 24 Nov 2023 at 07:08, Al Viro <[email protected]> wrote:
> >
> > Signed-off-by: Al Viro <[email protected]>
> > ---
> > fs/internal.h | 1 +
> > include/linux/dcache.h | 3 ---
> > 2 files changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/fs/internal.h b/fs/internal.h
> > index 9e9fc629f935..d9a920e2636e 100644
> > --- a/fs/internal.h
> > +++ b/fs/internal.h
> > @@ -219,6 +219,7 @@ extern void shrink_dcache_for_umount(struct super_block *);
> > extern struct dentry *__d_lookup(const struct dentry *, const struct qstr *);
> > extern struct dentry *__d_lookup_rcu(const struct dentry *parent,
> > const struct qstr *name, unsigned *seq);
> > +extern void d_genocide(struct dentry *);
>
> Seriously, who came up with THAT name? "Genocide" is not a nice term,
> not even if you ignore political correctness.
> Or what will be next? d_holodomor()? d_massmurder()? d_execute_warcrimes()?
kill_them_all(), on the account of that being what it's doing?
I can explain the problems with each of your suggested identifiers,
if you really wish that, but I would stronly suggest taking that off-list.
As for the bad words... google "jesux" someday. Yes, we do have
identifiers like "kill", "abort", etc. and those are really not going
anywhere; live with it.
On Fri, Nov 24, 2023 at 06:57:59AM +0000, Al Viro wrote:
> > > +extern void d_genocide(struct dentry *);
> >
> > Seriously, who came up with THAT name? "Genocide" is not a nice term,
> > not even if you ignore political correctness.
> > Or what will be next? d_holodomor()? d_massmurder()? d_execute_warcrimes()?
>
> kill_them_all(), on the account of that being what it's doing?
To elaborate a bit: what that function does (well, tries to do - it has
serious limitations, which is why there is only one caller remaining and
that one is used only when nothing else can access the filesystem anymore)
is "kill given dentry, along with all its children, all their children,
etc."
I sincerely doubt that you will be able to come up with _any_ word
describing such action in any real-world context that would not come
with very nasty associations.
Context: a bunch of filesystems have directory tree entirely in dcache;
creating a file or directory bumps the reference count of dentry in
question, so instead of going back to 0 after e.g. mkdir(2) returns
it is left with refcount 1, which prevents its eviction. In effect,
all positive dentries in there are artificially kept busy. On
rmdir(2) or unlink(2) that extra reference is dropped and they
get evicted.
For filesystems like e.g. tmpfs that's a fairly obvious approach -
they don't *have* any backing store, so dcache is not just caching
the underlying objects - it's all there is.
For such filesystems there is a quick way to do an equivalent of
rm -rf - simply go over the subtree you want to remove and decrement
refcounts of everything positive. That's fine on filesystem shutdown,
but for anything in use it is *too* quick - you'd better not do that
if there are mountpoints in the subtree you are removing, etc.
At the moment we have 3 callers in the kernel; one in selinuxfs, removing
stale directories on policy reload (not quite safe, but if attacker can
do selinux policy reload, you are beyond lost), another in
simple_fill_super() failure handling (safe, since filesystem is not
mounted at the time, but actually pointless - normal cleanup after
failure will take them out just fine) and the last one in
kill_litter_super(). That one is actually fine - we are shutting the
filesystem down and nobody can access it at that point unless the
kernel is deeply broken.
By the end of this series only that one caller remains, which is
reason for taking the declaration from include/linux/dcache.h to
fs/internal.h - making sure no new callers get added. Not because
of the identifier having nasty connotations, but because it's
pretty hard to use correctly.
Al Viro - 24.11.23, 08:48:57 CET:
> On Fri, Nov 24, 2023 at 06:57:59AM +0000, Al Viro wrote:
> > > > +extern void d_genocide(struct dentry *);
> > >
> > > Seriously, who came up with THAT name? "Genocide" is not a nice
> > > term,
> > > not even if you ignore political correctness.
> > > Or what will be next? d_holodomor()? d_massmurder()?
> > > d_execute_warcrimes()?>
> > kill_them_all(), on the account of that being what it's doing?
>
> To elaborate a bit: what that function does (well, tries to do - it has
> serious limitations, which is why there is only one caller remaining and
> that one is used only when nothing else can access the filesystem
> anymore) is "kill given dentry, along with all its children, all their
> children, etc."
I never got why in the context of computers anything is ever being killed.
It does not live to begin with.
You can stop something, remove it, delete it, destroy it, pause it, resume
it, overwrite it and you can do it really quickly or (almost) instantly or
slowly or recursively or some combination of those, but kill? You cannot
kill what does not live.
d_delete/destroy/remove_recursively() could be a suitable function name.
Pick one.
Similar it is with the term children or parent. There are no children in
computer software. Period. But here it may be more difficult to find
alternative wording. Would still be good to find something, cause I was
quite taken aback by the wording of the OOM killer. (Actually I was taken
aback that an operating system could even have something that forcefully
quits a process without saving data. It never matched my expectations of
reliability and stability.)
So how about stopping to put meaning into computer software source code
that simply is not there to begin with? How about starting to use terms
that describe what is actually being done and what is actually there?
--
Martin
[search bait removed from subject]
On Fri, Nov 24, 2023 at 10:36:05AM +0100, Martin Steigerwald wrote:
> Al Viro - 24.11.23, 08:48:57 CET:
> > To elaborate a bit: what that function does (well, tries to do - it has
> > serious limitations, which is why there is only one caller remaining and
> > that one is used only when nothing else can access the filesystem
> > anymore) is "kill given dentry, along with all its children, all their
> > children, etc."
>
> I never got why in the context of computers anything is ever being killed.
> It does not live to begin with.
Simple - one deals with objects that have complex lifecycle, with very
different possible behaviour at various stages. And about the only
example of such that would be well-covered in natural languages is
just that - both in adjectives for states and verbs for transitions between
those.
Note that the word "lifecycle" itself is rather commonly used outside
of biological context.
> You can stop something, remove it, delete it, destroy it, pause it, resume
> it, overwrite it and you can do it really quickly or (almost) instantly or
> slowly or recursively or some combination of those, but kill? You cannot
> kill what does not live.
Why? "Do something that changes the state of target into one in which
the target gradually becomes incapable of normal activity until it goes
completely inert and eventually disappears, with its parts recycled for
unrelated objects" vs. "kill the target", with associated transitional
state being refered to as "dying"?
Your suggestions all refer to operation rather than state transition.
> d_delete/destroy/remove_recursively() could be a suitable function name.
> Pick one.
Thanks, but no thanks. d_delete() already exists and refers to rather
different operation; "destroy" in such contexts would be loaded with
an existing technical meaning, and that would be actively confusing;
"remove_recursively"? Guess what the better-behaving replacement (far
too heavy-weight for the only remaining use) is called? "simple_recursive_removal".
It does more than this one, though.
> Similar it is with the term children or parent. There are no children in
> computer software. Period.
Well-asserted. Unfortunately, the statement is wrong - "parents" and
"children" have specific meanings when applied to nodes of directed graphs.
And there's a plenty of those dealt with by software. Directory tree, in
particular.