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
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 perfo
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 on
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 (
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 pa
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 sub
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 op
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
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 wind
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 ge
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 or
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 disclosu
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
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 ke
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 "
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
patche
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
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
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
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
On Mon, Feb 11, 2019 at 7:39 AM Jonathan Corbet wrote:
>
> Linus, perhaps you'd like to take this one directly?
Done.
Linus
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 noti
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
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!
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/.
>
>
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 go
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 look
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
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 t
quot;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]
n
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
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
>
> wh
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
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
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 P
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?
>
> N
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
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 b
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
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
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 fo
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
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
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
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 -
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
On Mon, Nov 5, 2018 at 5:15 AM Martin Schwidefsky
wrote:
>
> This patch would work for me:
Thanks, applied,
Linus
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 0
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.
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 b
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 stuc
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
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
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
On Thu, 5 Dec 2024 at 10:16, Geert Uytterhoeven wrote:
>
> Hence according to the Birthday Paradox, collisions of 12-chararacter
> git commit IDs are imminent, or already happening.
Note that ambiguous commit IDs are not even remotely as scary as this implies.
Yes, the current kernel tree has ov
On Thu, 26 Dec 2024 at 14:33, Sasha Levin wrote:
>
> Which means that folks should be able to use a fairly short abbreviated
> commit IDs in messages, specially for commits with a long subject line.
So I don't think we should take this as a way to make *shorter* IDs,
just as a way to accept histo
On Thu, 26 Dec 2024 at 16:55, Sasha Levin wrote:
>
> What got me worried originally is the example Kees provided which
> creates a collision of a 12-character abbreviated commit ID:
Note that you can always create short ambiguous cases.
And in fact, since the way you create them is to just put n
On Sat, 14 Dec 2024 at 08:03, Matthew Wilcox wrote:
>
> I have wondered about using a different encoding for the sha1.
> Classic Ascii85 encoding is no good; it uses characters like '"\<
> which interact poorly with every shell. RFC1924 is somewhat better,
> but still uses characters that interac
On Fri, 14 Mar 2025 at 17:15, Kees Cook wrote:
>
> Introduce type-aware kmalloc-family helpers to replace the common
> idioms for single, array, and flexible object allocations:
>
> kmalloc_obj(ptr, gfp);
> [ ... ]
Honestly, I absolutely hate this.
Don't do this. It's a huge mistake.
Ye
59 matches
Mail list logo
