Re: [PATCH v2] time: Remove CONFIG_TIMER_STATS
On Wed, Feb 8, 2017 at 11:26 AM, Kees Cook wrote: > > Given that the tracer can give the same information, this patch entirely > removes CONFIG_TIMER_STATS. > > Suggested-by: Thomas Gleixner > Signed-off-by: Kees Cook > Acked-by: John Stultz Looks good to me. Let's wait for the 4.11 merge window though. I'm assuming I'll get this through the tip timer tree.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Sat, Aug 19, 2017 at 1:49 AM, Masahiro Yamada wrote: > > Here is one question. Is it acceptable to use those rules all the time? > That is, generate those C files by flex, bison, gperf during the > kernel building. Yeah, I think we probably should do that. However, when I just tested, I noticed that we have issues with re-generating those files. With gperf 3.1 installed, I get In file included from scripts/kconfig/zconf.tab.c:213:0: scripts/kconfig/zconf.gperf:147:1: error: conflicting types for ‘kconf_id_lookup’ scripts/kconfig/zconf.gperf:12:31: note: previous declaration of ‘kconf_id_lookup’ was here static const struct kconf_id *kconf_id_lookup(register const char *str, register unsigned int len); ^~~ because gperf now generates const struct kconf_id * -kconf_id_lookup (register const char *str, register unsigned int len) +kconf_id_lookup (register const char *str, register size_t len) and I'm not sure how to detect that automatically. It seems to be a gperf-3.1 change, and gperf doesn't seem to generate any version markers. Working around that, I hit: In file included from scripts/genksyms/lex.lex.c:1921:0: scripts/genksyms/keywords.gperf:54:1: error: conflicting types for ‘is_reserved_word’ static, STATIC_KEYW ^~~~ In file included from scripts/genksyms/lex.lex.c:1921:0: scripts/genksyms/keywords.gperf:6:30: note: previous declaration of ‘is_reserved_word’ was here static const struct resword *is_reserved_word(register const char *str, register unsigned int len); ^~~~ so we have at least two cases of this in the source tree. So one of the advantages of the pre-shipped files is that we can avoid that kind of crazy version issues with the tools. But if we can solve the versioning thing easily, I certainly don't mind getting rid of the pre-generated files. Having to have flex/bison/gperf isn't a huge onus on the kernel build system. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Sat, Aug 19, 2017 at 10:03 AM, Linus Torvalds wrote: > > So one of the advantages of the pre-shipped files is that we can avoid > that kind of crazy version issues with the tools. Side note: the traditional way to handle this is autoconf etc. Since I think autoconf is evil crap, I refuse to have anything what-so-ever to do with it. gperf is clearly written by clowns that don't understand about compatibility issues - it would have been trivial for them to add some kind of marker define so that you could test for this directly rather than depend on some kind of autoconf "try to build and see if it fails" crap. So I think the best option would be to jhust get rid of gperf, and use a normal hash function instead (even if it isn't "perfect" - it's not like perfect hashes are so wonderful). I wonder if those two ID lookups are even worth hashing at all - the arrays aren't so big, and the uses aren't so timing-critical, so it's entirely possible that we could just get rid of any hashing at all and just use some stupid linear search thing. I assume that flex/bison are stable enough that we don't have the same kind of annoying stupid version issues with it. Anybody want to look at just getting rid of the gperf use? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Sat, Aug 19, 2017 at 10:14 AM, Linus Torvalds
wrote:
>
> Anybody want to look at just getting rid of the gperf use?
I took a stab at it. It wasn't too bad, although I think this needs a
*lot* of testing, and I think it needs checking of Makefile
dependencies etc.
NOTE NOTE NOTE! This may be *COMPLETELY* broken. It just happens to
build for me. So when I say "it wasn't too bad", I really mean "it
wasn't too bad, but I didn't spend a lot of effort on it either".
Honestly, the code is better and more legible without gperf, imho. And
it removes more lines than it adds - and even if you ignore changes to
the shipped lines, it's only an additional 15 lines of code,
It's likely not even any slower, but who the hell knows.. Do we even
care? It's almost certainly faster if you compare to generating that
gperf code.
Linus
From bb3290d91695bb1ae78ab86f18fb4d7ad8e5ebcc Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Sat, 19 Aug 2017 10:17:02 -0700
Subject: [PATCH] Remove gperf usage from toolchain
It turns out that gperf-3.1 changed types in the generated code in ways
that aren't even trivially detectable without having to generate a test-file.
It's just not worth using tools and libraries from clowns that don't
understand or care about compatibility. So get rid of gperf.
Signed-off-by: Linus Torvalds
---
Documentation/dontdiff | 1 -
scripts/genksyms/Makefile| 4 +-
scripts/genksyms/keywords.c | 74
scripts/genksyms/keywords.gperf | 61 ---
scripts/genksyms/keywords.hash.c_shipped | 230
scripts/genksyms/lex.l | 8 +-
scripts/genksyms/lex.lex.c_shipped | 8 +-
scripts/kconfig/.gitignore | 1 -
scripts/kconfig/Makefile | 4 +-
scripts/kconfig/kconf_id.c | 54 ++
scripts/kconfig/lkc.h| 2 +-
scripts/kconfig/zconf.gperf | 50 --
scripts/kconfig/zconf.hash.c_shipped | 297 ---
scripts/kconfig/zconf.tab.c_shipped | 10 +-
scripts/kconfig/zconf.y | 10 +-
15 files changed, 151 insertions(+), 663 deletions(-)
create mode 100644 scripts/genksyms/keywords.c
delete mode 100644 scripts/genksyms/keywords.gperf
delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
create mode 100644 scripts/kconfig/kconf_id.c
delete mode 100644 scripts/kconfig/zconf.gperf
delete mode 100644 scripts/kconfig/zconf.hash.c_shipped
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 358b47c06ad4..2228fcc8e29f 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -259,5 +259,4 @@ wakeup.bin
wakeup.elf
wakeup.lds
zImage*
-zconf.hash.c
zoffset.h
diff --git a/scripts/genksyms/Makefile b/scripts/genksyms/Makefile
index aca33b98bf63..3c23bab3367b 100644
--- a/scripts/genksyms/Makefile
+++ b/scripts/genksyms/Makefile
@@ -9,6 +9,6 @@ HOSTCFLAGS_parse.tab.o := -I$(src)
HOSTCFLAGS_lex.lex.o := -I$(src)
# dependencies on generated files need to be listed explicitly
-$(obj)/lex.lex.o: $(obj)/keywords.hash.c $(obj)/parse.tab.h
+$(obj)/lex.lex.o: $(obj)/parse.tab.h
-clean-files := keywords.hash.c lex.lex.c parse.tab.c parse.tab.h
+clean-files := lex.lex.c parse.tab.c parse.tab.h
diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
new file mode 100644
index ..9f40bcd17d07
--- /dev/null
+++ b/scripts/genksyms/keywords.c
@@ -0,0 +1,74 @@
+static struct resword {
+ const char *name;
+ int token;
+} keywords[] = {
+ { "EXPORT_SYMBOL", EXPORT_SYMBOL_KEYW },
+ { "EXPORT_SYMBOL_GPL", EXPORT_SYMBOL_KEYW },
+ { "EXPORT_SYMBOL_GPL_FUTURE", EXPORT_SYMBOL_KEYW },
+ { "EXPORT_UNUSED_SYMBOL", EXPORT_SYMBOL_KEYW },
+ { "EXPORT_UNUSED_SYMBOL_GPL", EXPORT_SYMBOL_KEYW },
+ { "__asm", ASM_KEYW },
+ { "__asm__", ASM_KEYW },
+ { "__attribute", ATTRIBUTE_KEYW },
+ { "__attribute__", ATTRIBUTE_KEYW },
+ { "__const", CONST_KEYW },
+ { "__const__", CONST_KEYW },
+ { "__extension__", EXTENSION_KEYW },
+ { "__inline", INLINE_KEYW },
+ { "__inline__", INLINE_KEYW },
+ { "__signed", SIGNED_KEYW },
+ { "__signed__", SIGNED_KEYW },
+ { "__typeof", TYPEOF_KEYW },
+ { "__typeof__", TYPEOF_KEYW },
+ { "__volatile", VOLATILE_KEYW },
+ { "__volatile__", VOLATILE_KEYW },
+ { "__builtin_va_list", VA_LIST_KEYW },
+
+ // According to rth, c99 defines "_Bool", __restrict", __restrict__", "restrict". KAO
+ { "_Bool", BOOL_KEYW },
+ { "_restrict", RESTRICT_KEYW },
+ { "__restrict__", RESTRICT_KEYW },
+ { "restrict", RESTRICT_KEYW },
+ { "asm", ASM_KEYW
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Thu, Sep 7, 2017 at 11:18 PM, Masahiro Yamada wrote: > > If CONFIG_MODVERSIONS is enabled, > I notice lots of error messages. > WARNING: EXPORT symbol "finish_open" [vmlinux] version generation > failed, symbol will not be versioned > > So, I think something was broken in scripts/genksyms/. > > Of course, it was a trivial conversion, so it should not be hard to fix... Indeed, hopefully it would be trivial, but I don't even see the error here. Of course, I only did a "make allmodconfig" to test the MODVERSIONS case, I didn't actually install the modules. Is that error perhaps only detected at install time? I did build and install a kernel with that patch, but that's my actual "real" config for the machine, and it didn't have MODVERSIONS enabled. Oh, how I hate modversions. But I'll take a look if I can see what I did wrong in the "Trivial and Obvious(tm)" conversion. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Fri, Sep 8, 2017 at 10:22 AM, Linus Torvalds wrote: > > Of course, I only did a "make allmodconfig" to test the MODVERSIONS > case, I didn't actually install the modules. Is that error perhaps > only detected at install time? Oh, I take that back. I just got a ton of warnings with my allmodconfig after doing a "git clean -dqfx". So I guess there is a dependency issue - my normal build test after the merge didn't show any issues, simply because the change in ksymoops didn't actually cause the version information to be re-generated. It doesn't seem to happen for every exported symbol, though. Odd. Looking at it, but not making sense of it yet. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Fri, Sep 8, 2017 at 11:01 AM, Linus Torvalds wrote: > > It doesn't seem to happen for every exported symbol, though. Odd. Fascinating. Picking one file at random that shows this, I did net/ceph/mon_client.c. The version file that gets generated for that looks like this: __crc_ceph_monc_want_map = 0x3389a57e; __crc_ceph_monc_got_map = 0x707f45a2; __crc_ceph_monc_renew_subs = 0x9842030a; __crc_ceph_monc_wait_osdmap = 0xfe38746d; __crc_ceph_monc_open_session = 0xc9ba8a19; __crc_ceph_monc_do_statfs = 0xe878801b; __crc_ceph_monc_get_version = 0xfaac6ce0; __crc_ceph_monc_get_version_async = 0x3adefe28; __crc_ceph_monc_blacklist_add = 0xee71d0ef; __crc_ceph_monc_init = 0xfce99654; __crc_ceph_monc_stop = 0xb0d197d0; __crc_ceph_monc_validate_auth = 0xce1c6d69; and with the gperf-removal patch, it is 100% identical _except_ that the "__crc_ceph_monc_do_statfs" line is missing. Same hashes for everything else. But one missing line. WTF? What is special about that one particular function vs the other ones in that file? I have absolutely no idea. So the really odd thing here is how things clearly still _work_. The parser works fine for everything else. And looking at the gprof-removal patch it's not at all obvious how everything could work fine except for some random thing. Strange. Does anybody see what the pattern to the failure is? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Fri, Sep 8, 2017 at 11:39 AM, Linus Torvalds wrote: > > Strange. Does anybody see what the pattern to the failure is? Found it. Stupid special case for 'typeof()' that used is_reserved_word() in ways I hadn't realized. Fix committed. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
On Sun, Sep 10, 2017 at 6:58 AM, Masahiro Yamada wrote: > > "is_reserved_word()" sounds like a boolean function > that returns 1 or 0. > Maybe, the choice of the function name was not nice. Yeah, not great name. That's the old name, though - I didn't change that part, I just changed how it used to return the token structure pointer, which would be NULL when it wasn't a keyword. I actually *should* have made it just return 0 for the "not a keyword" case rather than -1, and that would have ended up being semantically closer to the old use (because you could treat the return value as a boolean, like you could with the token pointer). But it's been literally decades since I used bison/flex, and I didn't remember the rules for 'enum yytokentype', so I just thought "negative numbers for error" was safer. Zero would have been fine, no token can have that number anyway (it just means EOF). And negative wasn't safer, it caused that bug due to the bare boolean use I hadn't noticed. Oh well. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull
On Tue, Nov 14, 2017 at 3:05 AM, Greg Kroah-Hartman wrote: > > Name the tag with something useful that you can understand if you run > across it in a few weeks, and something that will be "unique". > Continuing the example of my char-misc tree, for the patches to be sent > to Linus for the 4.15-rc1 merge window, I would name the tag > 'char-misc-4.15-rc1': > git tag -u KEY_ID -s char-misc-4.15-rc1 char-misc-next Side note: since you _usually_ would use the same key for the same project, just set it once with git config user.signingkey "keyname" and if you use the same key for everything, just add "--global". Or just edit your .git/config or ~/.gitconfig file by hand, it's designed to be human-readable and writable, and not some garbage like XML: [torvalds@i7 ~]$ head -4 .gitconfig [user] name = Linus Torvalds email = torva...@linux-foundation.org signingkey = torva...@linux-foundation.org it's not really all that complicated ;) Then you don't need that "-u KEY_ID" when you sign things. Anyway, at least to me, the important part is the *message*. I want to understand what I'm pulling, and why I should pull it. I also want to use that message as the message for the merge, so it should not just make sense to me, but make sense as a historical record too. Note that if there is something odd about the pull request, that should very much be in the explanation. If you're touching files that you don't maintain, explain _why_. I will see it in the diffstat anyway, and if you didn't mention it, I'll just be extra suspicious. And when you send me new stuff after the merge window (or even bug-fixes, but ones that look scary), explain not just what they do and why they do it, but explain the _timing_. What happened that this didn't go through the merge window.. I will take both what you write in the email pull request _and_ in the signed tag, so depending on your workflow, you can either describe your work in the signed tag (which will also automatically make it into the pull request email), or you can make the signed tag just a placeholder with nothing interesting in it, and describe the work later when you actually send me the pull request. And yes, I will edit the message. Partly because I tend to do just trivial formatting (the whole indentation and quoting etc), but partly because part of the message may make sense for me at pull time (describing the conflicts and your personal issues for sending it right now), but may not make sense in the context of a merge commit message, so I will try to make it all make sense. I will also fix any speeling mistaeks and bad grammar I notice, particularly for non-native speakers (but also for native ones ;^). But I may miss some, or even add some. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull
On Tue, Nov 14, 2017 at 1:33 PM, Tobin C. Harding wrote: > > Linus do you care what protocol? I'm patching Documentation and since > the point is creating pull requests for you 'some people' don't matter. I actually tend to prefer the regular git:// protocol and signed tags. It's true that https should have the proper certificate and perhaps help with DNS spoofing, but I'm not convinced that git won't just accept self-signed random certs, and I basically don't think we should trust that. In contrast, using ssh I would actually trust, but it's not convenient and involves people sending things that aren't necessarily publicly available. So instead, I prefer just using git:// and not trying to fool people into thinking the protocol is secure - the security should come from the signed tag. And then people can do this: [url "ssh://g...@gitolite.kernel.org"] insteadOf = https://git.kernel.org insteadOf = http://git.kernel.org insteadOf = git://git.kernel.org which makes git.kernel.org addresses use ssh, and avoid the whole possible DNS spoofing problem. That said, I actually would prefer even kernel.org repositories to just send pull requests with signed tags, despite the protocol itself being secure for that (and only that). Other hosts I will simply not trust without it because I can't do the above. Side note: there's an unrelated advantage of using "git://" over "https://";. It means that people who do automation see that it's a git repo. It also means, for example, that people that highlight https:// URL's and perhaps use them for spam marking hopefully don't do that with git:// format. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull
On Tue, Nov 14, 2017 at 1:46 PM, Linus Torvalds wrote: > And then people can do this: > > [url "ssh://g...@gitolite.kernel.org"] > insteadOf = https://git.kernel.org > insteadOf = http://git.kernel.org > insteadOf = git://git.kernel.org > > which makes git.kernel.org addresses use ssh, and avoid the whole > possible DNS spoofing problem. So credit goes for Konstantin for pointing that out, and I actually used it this merge window. A few notes for other people who end up doing this: (a) ssh is slower, and the gitolite machine is not as reachable. (b) it affects your merge commit message. As to (a), yes it's noticeable, but the extra couple of seconds isn't really that big of a deal. Depending on exactly where you are, though, you might end up wanting to use https:// to the public servers instead. But (b) actually ends up being annoying, because I don't like my merge commits to contain references to repositories that aren't actually available unless you have a kernel.org account. I tried to edit things up by hand, but honestly, that just meant that I forgot about 50% of the time. Do a git log --author=Torvalds --grep=ssh://gitolite to see my shameful lack of actually fixing up the end result. Happily, once you realize that you have the attention span of a slightly retarded chipmunk, and that you keep on forgetting to fix things up, you hopefully also go "I'm a moron, but I can compensate for that automatically". Which is simple. Just create a .git/hooks/prepare-commit-msg file that contains #!/bin/sh sed -i 's|ssh://gitolite.kernel.org/|git://git.kernel.org/|g' "$1" and make it executable, and git will do that commit message editing for you. Tadaa! Now you don't look like quite the tool that I did. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Prefer kASLR over Hibernation
On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote: > > Why is kASLR incompatible with hibernation? We can hibernate have > 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I > have patches for x86). Resuming kernel with different randomization > does not look that much different... Oh, I'd absolutely prefer to just allow kaslr together with hibernation if it actually works. Could the people who piped up to say that they actually use hibernation just try passing in the "kaslr" command line option on their machine, and see if it works for them? We could just remove the "no kaslr with hibername" code - or at least limit it to 32-bit for now.. Because that would be lovely. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] exec: clarify reasoning for euid/egid reset
On Tue, May 17, 2016 at 12:14 PM, Kees Cook wrote: > This section of code initially looks redundant, but is required. This > improves the comment to explain more clearly why the reset is needed. Applied. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] Docs for 4.13
On Mon, Jul 3, 2017 at 6:20 AM, Jonathan Corbet wrote: >You'll also encounter more than the usual number of conflicts, which >is saying something. Hmm. I fixed the ones that were actual data conflicts, but I think there ends up being several things that are just stale or didn't get updated by other pulls. Eg things like Error: Cannot open file ./kernel/rcu/srcu.c Error: Cannot open file ./kernel/rcu/srcu.c happen simply because that file no longer exists, and the docs never got updated. So my merge didn't even try to fix those kinds of things at all. I literally just looked at the conflicts and moved those over to the rst files, and that was it. There's a lot of other changes that never cause conflicts for the simple reason that those changes never caused documentation changes to begin with. Now, this is obviously not new, but it does strike me that if checking for these kinds of things was easier and part of "make allmodconfig", then we might have less of it happen. At the same time, lots of people run a lot of builds, and while I'd love to see warnings about docs failures, I am *not* willing to slow down my usual build enormously. I run "male allmodconfig" builds between every single pull during the merge window, and while it's often parallel with me looking at the problems, I don't really want to slow the build down too much. And the doc building is still *slow*. Is there some fast "just basic sanity checks" that would be more reasonable? Because one thing that the switch to sphinx has done is that the doc build environment seems saner (tool-wise). So now that kind of thing would at least be _possible_ to do in ways I don't think was reasonable with docbook. And now docbook is finally gone. But sphinx isn't exactly a speed demon either. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > idea now. What Marc describes that Josh proposed with signals for > userspcae seems more aligned with what we likely need Quite frankly, I doubt you want a signal. You will want to have some way to specify where the firmware files are. Right now we have "fw_path[]" which is hardcoded except for the first entry that can be set as a module parameter. But you'd probably want to expand on that, which implies some /sys or /proc interface. And once you do that, wouldn't it make more sense to just make the "update the firmware path /proc/sys/kernel/fw_path file" make things re-search for firmware? In other words, the interface has to be something *sensible*. Not some idiotic ad-hoc "send a signal" (of which that stupid original patch was just a very odd example). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Tue, Oct 4, 2016 at 5:24 PM, Luis R. Rodriguez wrote: > > Note that the races are beyond firmware, so all > kernel_read_file_from_path() users, as such re-using such old /sys/ > interafeces for firmware will not suffice to cover all ground now for > the same race for other possible users. Blah blah blah. The reason I've hated this whole discussion is that it's full of "let's re-architect everything", and then it has these horribly warty interfaces. It's classic second-system syndrome. Just do *one* thing, and do it well. Don't change anything else. Don't force existign drivers to use new interfaces. Don't over-architect, and don't do stupid interfaces. If user-space mounts a new filesystem (or just unpacks files from a tar-file that has firmware images in it, for chissake), that is not some magical "critical mount event". The whole concept is just stupid. Is it a "mount event" when the user downloads a new firmware image from the internet? HELL NO. But what is equally stupid is to then dismiss simple models because some totally unrelated "beyond firmware" issue. Anything that is "beyond firmware" shouldn't even be discussed, for chrissake! It has nothing what-so-ever to do with firmware loading. If there ends up being some common helper functions, and shared code, that *still* doesn't make it so. Basic rules of thumb: (a) don't over-design (b) don't have stupid illogical interfaces (c) don't conflate different issues just because you think they may have shared code. (4) be consistent. Don't make up new interfaces, and most certainly do *NOT* dismiss something just because it's what we have done before. That's it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Tue, Oct 4, 2016 at 6:48 PM, Josh Triplett wrote: > >I definitely don't think it > should be a system-wide "mount event"; it should be a per-device "go > direct-load your firmware" poke from userspace. I don't disagree with that kind of interface. We already have things like "rescan" for PCI bus devices to force a bus rescan. Iit's a simple device attribute. Having a similar thing to trigger firmware reload for a driver sounds entirely sane. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Wed, Oct 5, 2016 at 11:00 AM, Luis R. Rodriguez wrote: > On Tue, Sep 13, 2016 at 09:38:17PM -0500, Rob Landley wrote: > >> I did some shuffling around of those code to make initmpfs work, does >> anybody know why initramfs extraction _before_ we initialize drivers >> would be a bad thing? > > No, but it seems sensible to me, if its done before do_initcalls() > that should resolve the race for initramfs users initramfs should already be set up before drivers are. Exactly what is it that has trouble right now? The gating issue for initramfs is that technically the filesystem setup needs to be done, which means that it currently ends up being populated _fairly_ late in the initcall series, but certainly before drivers. But since initramfs really only needs very limited filesystem functionality, I assume Rob had few problems with just moving it earlier. Still, what kind of ordering issues did people have? What is it that needs to load files even before driver init? Some crazy subsystem? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-discuss] Including images on Sphinx documents
On Thu, Nov 17, 2016 at 8:02 AM, Linus Torvalds
wrote:
>
> No. That is how I *noticed* the issue. Those stupid pdf binary files
> have been around forever, I just didn't notice until the Fedora people
> started complaining about the patches.
Side note: my release patches these days enable both "--binary" and
"-M", so they require "git apply" now. So we handle the binaries fine
in patches now, but as mentioned, that was just what made me notice,
it wasn't a fix for the deeper ("source") problem.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-discuss] Including images on Sphinx documents
On Thu, Nov 17, 2016 at 3:07 AM, Arnd Bergmann wrote:
>
> [adding Linus for clarification]
>
> I understood the concern as being about binary files that you cannot
> modify with classic 'patch', which is a separate issue.
No. That is how I *noticed* the issue. Those stupid pdf binary files
have been around forever, I just didn't notice until the Fedora people
started complaining about the patches.
My real problem is not "binary" or even "editable", but SOURCE CODE.
It's like including a "vmlinux" image in the git tree: sure, you can
technically "edit" it with a hex editor, but that doesn't change the
basic issue: it's not the original source code.
I don't want to see generated binary crap.
That goes for png, that goes for gif, that goes for pdf - and in fact
that goes for svg *too*, if the actual source of the svg was something
else, and it was generated from some other data.
We have makefiles, but more importantly, few enough people actually
*generate* the documentation, that I think if it's an option to just
fix sphinx, we should do that instead. If it means that you have to
have some development version of sphinx, so be it. Most people read
the documentation either directly in the unprocessed text-files
("source code") or on the web (by searching for pre-formatted docs)
that I really don't think we need to worry too much about the
toolchain.
But what we *should* worry about is having the kernel source tree
contain source.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-discuss] Including images on Sphinx documents
On Sat, Nov 19, 2016 at 9:55 AM, David Woodhouse wrote: > > I know it's unfashionable these days, but TeX always used to be bloody > good at that kind of thing. You must have used a different TeX than I did. TeX is a horrible example. The moment you needed to insert anything that TeX didn't know about, you were screwed. I think my go-to for TeX was LaTeX, the "epsfig" thing, and then xfig and eps files (using fig2dev). Christ, I get flashbacks just thinking about it. I thought one of the points of Sphinx was to not have to play those games. I think that graphviz and svg are the reasonable modern formats. Let's try to avoid bitmaps in today's world, except perhaps as intermediate generated things for what we can't avoid. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-discuss] Including images on Sphinx documents
On Sat, Nov 19, 2016 at 12:54 PM, Mauro Carvalho Chehab wrote: > > I did some research on Friday trying to identify where those images > came. It turns that, for the oldest images (before I took the media > maintainership), PDF were actually their "source", as far as I could track, > in the sense that the *.gif images were produced from the PDF. > > The images seem to be generated using some LaTeX tool. Their original > format were probably EPS. The original format was almost certainly xfig. Converting fig files to eps and pdf to then encapsulate them into LaTeX was a very common way to do documentation with simple figures. Iirc, xfig natively supported "export as eps". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/10] kmod: add a sanity check on module loading
On Fri, Dec 9, 2016 at 12:03 PM, Martin Wilck wrote:
> On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
>>
>> Although this does get us in the business of keeping alias maps in
>> kernel, the the work to support and maintain this is trivial.
>
> You've implemented a special treatment for request_module("fs-$X")in
> finished_kmod_load(), but there are many more aliases defined (and
> used) in the kernel. Do you plan to implement special code for "char-
> major-$X", "crypto-$X", "binfmt-$X" etc. later?
Yeah, no, that is just complete garbage.
Those module aliases already exist in the module info section. We just
don't parse the alias tags in the kernel.
So the real fix is to make find_module_all() just do that.
Doing random ad-hoc "let's prefix with 'fs-xyz'" games are completely
unacceptable. That's just pure shit. Stop this idiocy.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Documentation for 5.0
On Fri, Dec 28, 2018 at 8:06 AM Jonathan Corbet wrote: > > git://git.lwn.net/linux.git tags/docs-5.0 New signing key? And one that you forgot to push out to keyservers? Linus
Re: [PATCH 4/5] csky: fixup compile error with pte_alloc
On Tue, Jan 8, 2019 at 8:27 AM wrote: > > + for (i = 0; i < PAGE_SIZE/sizeof(pte_t); i++) > + (pte + i)->pte_low = _PAGE_GLOBAL; When I first read this, I went "hmm. pte_high is not initialized". But csky doesn't have a pte_high, and it seems that csky and SH both decided to call their (single-word) pte member 'pte_low'. Which is a bit odd, but whatever. Other than that oddity, it looks fine to me. I assume I'll get a pull request sooner or later, Linus
Re: [RESEND PATCH v4 0/3] fs/dcache: Track # of negative dentries
On Wed, Jan 30, 2019 at 8:40 AM Waiman Long wrote: > > Ping. Will this patch be picked up? Can you re-send the patch-set and I'll just apply it directly since it seems to be languishing otherwise. Linus
Re: [PATCH v2] Documentation: Fix grammatical error in sysctl/fs.txt & clarify negative dentry
On Mon, Feb 11, 2019 at 7:39 AM Jonathan Corbet wrote: > > Linus, perhaps you'd like to take this one directly? Done. Linus
Re: [PATCH RFC] Rough draft document on merging and rebasing
On Thu, May 30, 2019 at 12:53 PM Jonathan Corbet wrote: > > This is a first attempt at following through on last month's discussion > about common merging and rebasing errors. Looks good to me, Linus
Re: [GIT PULL] Compiler Attributes for v4.20-rc1
On Mon, Oct 22, 2018 at 3:59 AM Miguel Ojeda wrote: > > Here it is the Compiler Attributes series/tree, which tries to disentangle > the include/linux/compiler*.h headers and bring them up to date. I've finally emptied the "normal" pull queues, and am looking at the odd ones that I felt I needed to review more in-depth. This looked fine to me, and I already pulled, but when looking at the conflict for __no_sanitize_address_or_inline, I also noticed that you actually changed the gcc version logic. The logic for using __no_sanitize_address *used* to be #if GCC_VERSION >= 40902 but you have changed it to # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8) so now it's gcc-4.8+ rather than gcc-4.9.2+. I'm not sure how much that matters (maybe the original check for 4.9.2 was just a random pick by Andrey? Added to cc), but together with the movement to that looks like it also wouldn't want the CONFIG_KASAN tests, I wonder what the right merge resolution would be. Yes, I see the resolution in linux-next, and I think that one is odd and dubious, and now it *mixes* that old test of gcc-4.9.2 with the different test in compiler-attributes. I'm _inclined_ to just do #ifdef CONFIG_KASAN #define __no_sanitize_address_or_inline \ __no_sanitize_address __maybe_unused notrace #else #define __no_sanitize_address_or_inline inline #endif without any compiler versions at all, because I don't think it matters (maybe we won't get address sanitation, and we will not get inlining either, but do we care?). But I'm also unsure whether you meant for the "__has_attribute()" test to be usable outside the linux/compiler_attributes.h file, in which case I could just do #if defined(CONFIG_KASAN) && __has_attribute(__no_sanitize_address__) instead. End result: it's not the merge resolution itself that raises questions, it's just semantics in general. So I've dropped this for now, in the hope that you/Andrey can answer these questions. Linus
Re: [GIT PULL] Compiler Attributes for v4.20-rc1
On Thu, Nov 1, 2018 at 10:06 AM Linus Torvalds wrote: > > The logic for using __no_sanitize_address *used* to be > > #if GCC_VERSION >= 40902 Ok, looking around, I think this has less to do with the attribute being recognized, and simply just being because KASAN itself wants gcc-4.9.2. I'm actually not seeing that KASAN dependency in the Kconfig scripts (and it probably _should_ be now that we can just add compiler version dependencies there), but that explains why the gcc version check is different from "gcc supports the attribute". Anyway, I decided to do the merge by just getting rid of the GCC_VERSION check around __no_sanitize_address_or_inline entirely. If you enable KASAN, then a function with that marking just won't be marked inline. End result: pulled. I'm as confused as you are as to why __no_sanitize_address_or_inline is in the gcc header, but I guess it ends up being the same issue: KASAN depends on gcc even if that dependency doesn't seem to be spelled out in lib/Kconfig.kasan. So I _think_ the KASAN config should have a depends on CC_IS_GCC && GCC_VERSION >= 40902 on it, but maybe there is something I'm missing. But from a pull standpoint, I don't want to mess with those (unrelated) issues, so I just kept the merge resolution as simple and straightforward as possible. Miguel, please do double-check the merge (it's not pushed out yet, I'm doing the usual build tests etc first). Linus
Re: [GIT PULL] Compiler Attributes for v4.20-rc1
On Fri, Nov 2, 2018 at 2:43 AM Andrey Ryabinin wrote: > > You're right, version checks shouldn't matter here. But > __no_sanitize_address_or_inline > shouldn't have been added in the first place, because we already have almost > the same >__no_kasan_or_inline: Ahh, very good. Vasily, Martin - since __no_sanitize_address_or_inline was added just for s390, would you mind replacing it with __no_kasan_or_inline instead, and testing that in whatever failed before? Then we can just remove that unnecessary symbol #define entirely.. Thanks, Linus
Re: [GIT PULL] Compiler Attributes for v4.20-rc1
On Fri, Nov 2, 2018 at 6:16 AM Andrey Ryabinin wrote: > > On 11/02/2018 04:46 AM, Linus Torvalds wrote: > > > > So I _think_ the KASAN config should have a > > > > depends on CC_IS_GCC && GCC_VERSION >= 40902 > > > > on it, but maybe there is something I'm missing. > > I'd rather use cc-option instead of version check, since we also support > clang. That would be even better, but I thought the requirement for 4.9.2 came not from the option existing, but because of some bugs getting fixed? But if we can do it without version checks, that would be lovely. Linus
Re: [GIT PULL] Compiler Attributes for v4.20-rc1
On Mon, Nov 5, 2018 at 5:15 AM Martin Schwidefsky wrote: > > This patch would work for me: Thanks, applied, Linus
Re: [GIT PULL] Documentation for 4.20 (or whatever it's called)
On Tue, Oct 23, 2018 at 9:11 AM Jonathan Corbet wrote: > > This is a fairly typical cycle for documentation. There's some welcome > readability improvements for the formatted output, some LICENSES updates > including the addition of the ISC license, the removal of the unloved and > unmaintained 00-INDEX files, the deprecated APIs document from Kees, more > MM docs from Mike Rapoport, and the usual pile of typo fixes and > corrections. Pulled, Linus
Re: [PATCH v3] code-of-conduct: Remove explicit list of discrimination factors
On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek wrote: > > Linus, I don't think Greg is doing good job maintaining this. Can you > take the patch? (Or explain what is going on here, because I don't > think public has full story). I think Greg is doing a fine job, and I personally will not take patches to the CoC without *much* stronger reasons than just some random opinion. This is an area where everybody has opinions, and there is no inherent technical agreement (ie no "look, numbers: this makes code 5% faster"), so my policy wrt the CoC is that changes to it have to have very concrete reasons for them. IOW, actual problems caused by real issues, not "in my opinion". Honestly, the list of discrimination factors looks fine to me, and if it is shown to be insufficient or problematic, there's the documented link to the Code of Conduct Committee. That sounds to me like the right way to bring up problematic behavior - and if the review then shows that "yes, the CoC should cover this too", then at that point we have a real and present example and reason to modify the CoC. Linus
Re: [RESEND PATCH v4 0/3] fs/dcache: Track # of negative dentries
On Fri, Dec 14, 2018 at 1:53 PM Waiman Long wrote: > > This patchset addresses 2 issues found in the dentry code and adds a > new nr_dentry_negative per-cpu counter to track the total number of > negative dentries in all the LRU lists. The series looks sane to me. I'm assuming I'll get it either though -mm or from Al.. Linus
Re: [PATCH 5/8] docs: kernel-doc: Move STATE_BODY processing to a separate function
On Fri, Feb 9, 2018 at 1:32 AM, Jani Nikula wrote: >> + # miguel-style comment kludge, look for blank lines after >> + # @parameter line to signify start of description > > The "miguel-style" always intrigued me, but its origin predates git > history. Does anyone know? It came with the original script in 2.3.52-pre1, somewhere around March 2000. (Historical footnote: there was no actual 2.3.52 ever released - it was supposed turn into 2.4, but there was a long line of 2.3.99-pre kernels before that then finally happened early 2001). But no, back then we didn't track things well enough to have an actual reason. And even with git, we probably wouldn't have had a reason since it came in the initial patch. You'd have to go search emails if you really care. That "around March 2000" would at least give you a starting point for searches. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: clarify security-bugs disclosure policy
On Tue, Mar 6, 2018 at 3:31 PM, Dave Hansen wrote: > > I think we need to soften the language a bit. It might scare folks > off, especially the: > > We prefer to fully disclose the bug as soon as possible. > > which is not really the case. Ack. What we do is definitely not full disclosure. In fact, we often actively try to avoid disclosing details and leave that entirely to others. We disclose the *patches*, and the explanation of the patch, but not necessarily anything else (ie no exploit code or even any exploit discussion). We also don't explicitly disclose the discussion of the patches or the report, although part of it mayt obviously become more or less public for other reasons. So we should probably avoid using a term that means something else to a lot of people. And for similar reasons, I don't think the fixed verbiage should use "coordinated disclosure" either, like in your patch. That usually means the kind of embargoes that the security list does not honor. So I think it merits clarification, but maybe just specify the two things relevant to our disclosure: the fact that the patch and explanation for the patch gets made public (but not necessarily other effects), and that the timeframe is very limited. It's not full disclosure, it's not coordinated disclosure, and it's not "no disclosure". It's more like just "timely open fixes". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
That patch looks fine to me, avoiding any terms that might be misunderstood, and being pretty straightforward. I'm guessing this will go through Jon? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > If you want to be taken seriously then I think minimum you also need to > - Give a GPG key for messages to the list Oh, I don't want to be taken seriously by people who use gpg encrypted email. It's garbage and should be shunned as such. I keep quoting this: https://motherboard.vice.com/en_us/article/vvbw9a/even-the-inventor-of-pgp-doesnt-use-pgp and anybody who thinks pgp encrypted email is fine is a clown. > - State what security is in place (encryption etc) to protect the list > itself That could be stated, but it's worth noting the other rules. If you have some long corrupt vendor disclosure period and are worried about any good guys finding out (the bad guys probably already have it), we're not the list for you anyway. Keep your "we'll keep security problems under wraps so that they can be exploited for a long time" emails to yourself, or send them to /dev/null. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 00/12] fscache: Fixes, traces and development
On Fri, Apr 6, 2018 at 2:02 PM, Matthew Wilcox wrote: > > We have out of date information in Documentation ... My match is actually fairly lax. As long as the email has both "git" and "pull" somewhere, I should see it. It doesn't actually have to be in the subject line. And almost always the "git" is there anyway, and DavidH's email had that one at least twice, in just one line: >git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git and a lot of people end up having some boiler-plate that says "Please pull" or something, so they get the "pull" part that way too, and I'll see those emails even when they have nothing at all in the subject line. But yes: > Jon, please consider applying: > > diff --git a/Documentation/process/submitting-patches.rst > b/Documentation/process/submitting-patches.rst > index f7152ed565e5..908bb55be407 100644 > --- a/Documentation/process/submitting-patches.rst > +++ b/Documentation/process/submitting-patches.rst > -A pull request should have [GIT] or [PULL] in the subject line. The > +A pull request should have [GIT PULL] in the subject line. The That's the *safest* thing to have, in that now the subject line itself already covers everything, and doesn't depend on anything else being implicitly in the message itself. And it's what most people seem to use, based on what I see. It makes them stand out visually to humans too, not just to my usual filter. Having "PATCH" in the subject like (like DavidH _does_ have) also ends up being something I look for, but not during the first week of the merge window when I'm overwhelmed by pull requests. I usually do that at the very end of the merge window just to try to make sure (sometimes even successfully) that I didn't miss anything. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy
On Sun, Apr 22, 2018 at 3:00 AM, Pavel Machek wrote: > > On Fri 2018-03-09 13:15:31, Linus Torvalds wrote: >> >> Oh, I don't want to be taken seriously by people who use gpg >> encrypted email. > > Heh. I see that gpg has some usability problems, but we do encrypt our > http connections, and email is at least as sensitive. It's not about sensitivity. It's about the technology actually *working*. PGP does not work for email. Never has, never will. It's unusable crap. Nobody sane uses it, because the cost is just too damn high. Make it as easy to use as https, and things will change. As it is, don't even bother. Thomas helped me get S/MIME working, and even for that I had to fix an alpine bug that caused alpine to SIGSEGV. And that's _convenient_ compared to pgp email. Whee. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] treewide: Add 'fallthrough' pseudo-keyword
On Sat, Oct 5, 2019 at 9:46 AM Joe Perches wrote: > > Add 'fallthrough' pseudo-keyword to enable the removal of comments > like '/* fallthrough */'. I applied patches 1-3 to my tree just to make it easier for people to start doing this. Maybe some people want to do the conversion on their own subsystem rather than with a global script, but even if not, this looks better as a "prepare for the future" series and I feel that if we're doing the "fallthrough" thing eventually, the sooner we do the prepwork the better. I'm a tiny bit worried that the actual conversion is just going to cause lots of pain for the stable people, but I'll not worry about it _too_ much. If the stable people decide that it's too painful for them to deal with the comment vs keyword model, they may want to backport these three patches too. Linus
Re: [PATCH 0/4] treewide: Add 'fallthrough' pseudo-keyword
On Fri, Oct 11, 2019 at 10:43 AM Joe Perches wrote: > > Shouldn't a conversion script be public somewhere? I feel the ones that might want to do the conversion on their own are the ones that don't necessarily trust the script. But I don't even know if anybody does want to, I just feel it's an option. Linus
Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator
On Mon, 18 Sept 2023 at 10:39, Ingo Molnar wrote: > > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between > user-space execution and kernel-space execution? ... and equally importantly, what about DMA? Or what about the fixed-size slabs (aka kmalloc?) What's the point of "never re-use the same address for a different slab", when the *same* slab will contain different kinds of allocations anyway? I think the whole "make it one single compile-time option" model is completely and fundamentally broken. Linus
Re: [RFC PATCH 00/14] Prevent cross-cache attacks in the SLUB allocator
On Tue, 19 Sept 2023 at 08:48, Matteo Rizzo wrote: > > On Mon, 18 Sept 2023 at 20:05, Linus Torvalds > wrote: > > > > ... and equally importantly, what about DMA? > > I'm not exactly sure what you mean by this, I don't think this should > affect the performance of DMA. I was more worried about just basic correctness. We've traditionally had a lot of issues with using virtual addresses for dma, simply because we've got random drivers, and I'm not entirely convinced that your "virt_to_phys()" update will catch it all. IOW, even on x86-64 - which is hopefully better than most architectures because it already has that double mapping issue - we have things like unsigned long paddr = (unsigned long)vaddr - __PAGE_OFFSET; in other places than just the __phys_addr() code. The one place I grepped for looks to be just boot-time AMD memory encryption, so wouldn't be any slab allocation, but ... Linus
Re: [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership
On Thu, 4 Jan 2024 at 11:09, Steven Rostedt wrote: > > My mistake was thinking that the dentry was attached more to the path than > the inode. But that doesn't seem to be the case. I wasn't sure if there was > a way to get to a dentry from the inode. Yeah, so dentry->inode and path->dentry are one-way translations, because the other way can have multiple different cases. IOW, a path will specify *one* dentry, and a dentry will specily *one* inode, but one inode can be associated with multiple dentries, and there may be other undiscovered dentries that *would* point to it but aren't even cached right now. And a single dentry can be part of multiple paths, thanks to bind mounts. The "inode->i_dentry" list is *not* a way to look up all dentries, because - as mentioned - there may be potential other paths (and thus other dentries) that lead to the same inode that just haven't been looked up yet (or that have already been aged out of the cache). Of course any *particular* filesystem may not have hard links (so one inode has only one possible dentry), and you may not have bind mounts, and it might be one of the virtual filesystems where everything is always in memory, so none of the above problems are guaranteed to be the case in any *particular* situation. But it's all part of why the dcache is actually really subtle. It's not just the RCU lookup rules and the specialized locking (both reflock and the rather complicated rules about d_lock ordering), it's also that whole "yeah, the filesystem only sees a 'dentry', but because of bind mounts the vfs layer actually does things internally in terms of 'struct path' in order to be able to then show that single fiolesystem in multiple places". Etc etc. There's a reason Al Viro ends up owning the dcache. Nobody else can wrap their tiny little minds around it all. Linus
Re: [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership
On Thu, 4 Jan 2024 at 11:14, Steven Rostedt wrote: > > "file descriptor" - is just what maps to a specific inode. Nope. Technically and traditionally, file descriptor is just the integer index that is used to look up a 'struct file *'. Except in the kernel, we really just tend to use that term (well, I do) for the 'struct file *' itself, since the integer 'fd' is usually not really relevant except at the system call interface. Which is *NOT* the inode, because the 'struct file' has other things in it (the file position, the permissions that were used at open time etc, close-on-exec state etc etc). > "file description" - is how the file is accessed (position in the file and > flags associated to how it was opened) That's a horrible term that shouldn't be used at all. Apparently some people use it for what is our 'struct file *", also known as a "file table entry". Avoid it. If anything, just use "fd" for the integer representation, and "file" for the pointer to a 'struct file". But most of the time the two are conceptually interchangeable, in that an 'fd' just translates directly to a 'struct file *'. Note that while there's that conceptual direct translation, there's also very much a "time of use" issue, in that a "fd -> file" translation happens at one particular time and in one particular user context, and then it's *done* (so closing and possibly re-using the fd after it's been looked up does not actually affect an existing 'struct file *'). And while 'fd -> file' lookup is quick and common, the other way doesn't exist, because multiple 'fd's can map to one 'struct file *' thanks to dup() (and 'fork()', since a 'fd -> file' translation always happens within the context of a particular user space, an 'fd' in one process is obviously not the same as an 'fd' in another one). Linus
Re: [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership
On Thu, 4 Jan 2024 at 11:35, Linus Torvalds wrote: >> > Which is *NOT* the inode, because the 'struct file' has other things > in it (the file position, the permissions that were used at open time > etc, close-on-exec state etc etc). That close-on-exec thing was a particularly bad example of things that are in the 'struct file', because it's in fact the only thing that *isn't* in 'struct file' and is associated directly with the 'int fd'. But hopefully the intent was clear despite me picking a particularly bad example. Linus
Re: [RFC] fs: add userspace critical mounts event support
On Fri, Sep 2, 2016 at 5:20 PM, Luis R. Rodriguez wrote: > > Thoughts ? I really think this is a horrible hack. It's basically the kernel giving up, and relying on user space to give a single flag, and it's broken nasty crap. Worse, it's broken nasty crap with a user interface, so we'll be stuck with it forever. Please no. What are the drivers that need this, and why can't those drivers just be fixed to not do braindead things? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Sat, Sep 3, 2016 at 10:49 AM, Dmitry Torokhov wrote: > > Unfortunately module loading and availability of firmware is very > loosely coupled. The whole "let's add a new magical proc entry to say that all filesystems are mounted" is all about the user space coupling them. I'm just saying that if user space must know about when firmware is ready to be loaded anyway, just do it rigth. Not with some hacky "you can now do random things" flag. But by having user space actually say "put this module together with this firmware". If you just put the two pieces together, then the module "will just work". And quite frankly, that sounds like a much better maintenance practice anyway. If some module doesn't work without the firmware, then dammit, the two *should* go together. Putting them in two different places would be *INSANE*. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson wrote: > > Linus, I reversed the order of your questions/answers to fit my answer > better. Nobody has actually answered the "why don't we just tie the firmware and module together" question. Really. If the driver doesn't work without the firmware, then why the hell is it separated from it in the first place? The hack is a hack, and it just sounds *stupid*. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] fs: add userspace critical mounts event support
On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson wrote: > On Tue 06 Sep 11:32 PDT 2016, Linus Torvalds wrote: > >> On Tue, Sep 6, 2016 at 10:46 AM, Bjorn Andersson >> Nobody has actually answered the "why don't we just tie the firmware >> and module together" question. > > The answer to this depends on the details of the suggestion; but > generally there's a much stronger bond between the kernel and the driver > than between the driver and the firmware in my cases. I call BS. Let me be very clear. I'm not applying that shit-for-brains stupid patch, and will not be pulling it unless somebody tricks me into it. Because all these arguments make no sense at all. If the driver doesn't work without the firmware, then anybody who distributes the driver binary without a firmware is just *fundamentally* doing something insane. You may do it for *development* purposes, but doing so for actual *use* would be entirely pointless. See my point? If a distribution is distributing the driver without the firmware, then what the hell is the point of such a thing? But even if you decide to do that for some odd reason, the patch is still just stupid. Instead of adding some crazy infrastructure for "now I've mounted everything", you could equally well just (a) make the driver fail the module load if it cannot find a firmware binary (b) after user space has mounted everything, just do "insmod -a" again (or insmod just that driver). See? The point is, this "generic" hacky interface is just stupid. It's not adding any value. If you add user space "I'm ready now" points anyway, you might as well make those points do the right thing and just load the module that is now loadable. We could mark such "late loading" modules explicitly if people want to, so that you can automate the whole thing about delaying the loading in user space. At no point does it make sense to say "I have now mounted all the important filesystems". Maybe the firmware is extracted later by user space downloading it from the internet, and the module will then work only after that point"./ This whole "I have mounted important filesystems" is just pure and utter garbage. Stop pushing this shit. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
