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] 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

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 -

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

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Sun, Apr 22, 2018 at 3:00 AM, Pavel Machek <pa...@ucw.cz> 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 pr

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.

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

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

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

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

Re: git pull

On Tue, Nov 14, 2017 at 1:46 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > And then people can do this: > > [url "ssh://g...@gitolite.kernel.org"] > insteadOf = https://git.kernel.org > insteadOf = http://git.kernel.org > insteadO

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

Re: git pull

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 .gitcon

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

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 <torva...@linux-foundation.org> 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.

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 <torva...@linux-foundation.org> 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 fo

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 <torva...@linux-foundation.org> 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,

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

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 <torva...@linux-foundation.org> 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 depe

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 <torva...@linux-foundation.org> 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

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.

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

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:

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

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

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

Re: [Ksummit-discuss] Including images on Sphinx documents

On Thu, Nov 17, 2016 at 8:02 AM, Linus Torvalds <torva...@linux-foundation.org> 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. Sid

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

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

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

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Sep 6, 2016 at 2:11 PM, Bjorn Andersson <bjorn.anders...@linaro.org> 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 >

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

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

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