LKML.ORG[B!]新着記事・評価 - はてなブックマーク (original) (raw)

6 users
lkml.org
Rust support This is the patch series (v2) to add support for Rust as a second language to the Linux kernel. If you are interested in following this effort, please join us in the mailing list at: rust-for-linux@vger.kernel.org and take a look at the project itself at: https://github.com/Rust-for-Linux As usual, special thanks go to ISRG (Internet Security Research Group) and Google for their finan

28 users
lkml.org
On Thu, Jun 10, 2021 at 11:08 AM Enrico Weigelt, metux IT consult lkml@metux.net wrote: > > And I know *a lot* of people who will never take part in this generic > human experiment that basically creates a new humanoid race (people > who generate and exhaust the toxic spike proteine, whose gene sequence > doesn't look quote natural). I'm one of them, as my whole family. Please keep your insane a

15 users
lkml.org
On Wed, Apr 14, 2021 at 11:46 AM ojeda@kernel.org wrote: > > Some of you have noticed the past few weeks and months that > a serious attempt to bring a second language to the kernel was > being forged. We are finally here, with an RFC that adds support > for Rust to the Linux kernel. So I replied with my reactions to a couple of the individual patches, but on the whole I don't hate it. HOWEVER.

5 users
lkml.org
From: Miguel Ojeda ojeda@kernel.org Some of you have noticed the past few weeks and months that a serious attempt to bring a second language to the kernel was being forged. We are finally here, with an RFC that adds support for Rust to the Linux kernel. This cover letter is fairly long, since there are quite a few topics to describe, but I hope it answers as many questions as possible before the

5 users
lkml.org
On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett josh@joshtriplett.org wrote: > > As I recall, Greg's biggest condition for initial introduction of this > was to do the same kind of "turn this Kconfig option on and turn an > option under it off" trick that LTO uses, so that neither "make > allnoconfig" nor "make allyesconfig" would require Rust until we've had > plenty of time to experiment with it

4 users
lkml.org
Recent events have prompted a Linux position statement on inclusive terminology. Given that Linux maintains a coding-style and its own idiomatic set of terminology here is a proposal to answer the call to replace non-inclusive terminology. Cc: Jonathan Corbet corbet@lwn.net Cc: Kees Cook keescook@chromium.org Signed-off-by: Chris Mason clm@fb.clm Signed-off-by: Greg Kroah-Hartman <gregkh@lin

32 users
lkml.org
On Fri, May 29, 2020 at 6:08 AM David Laight David.Laight@aculab.com wrote: > > A wide monitor is for looking at lots of files. Not necessarily. Excessive line breaks are BAD. They cause real and every-day problems. They cause problems for things like "grep" both in the patterns and in the output, since grep (and a lot of other very basic unix utilities) is fundamentally line-based. So the fact

3 users
lkml.org
There is a blog post that goes into more detail about the bigger picture, and walks through all the required pieces to make this work. It is available here: https://devblogs.microsoft.com/directx/directx-heart-linux . The rest of this cover letter will focus on the Linux Kernel bits. Overview ======== This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The driver exposes a paravirt

5 users
lkml.org
On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers ndesaulniers@google.com wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use "-fno-delete-null-pointer-checks" because we do *not* want NULL pointer check removal even in the case of a bug. See commit a3ca86ae

3 users
lkml.org
On Thu, Jun 13, 2019 at 9:31 PM Dave Chinner david@fromorbit.com wrote: > > Yes, they do, I see plenty of cases where the page cache works just > fine because it is still faster than most storage. But that's _not > what I said_. I only quoted one small part of your email, because I wanted to point out how you again dismissed caches. And yes, that literally _is_ what you said. In other parts of t

3 users
lkml.org
Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() On Thu, Jan 10, 2019 at 07:07:52PM +0100, Sebastian Andrzej Siewior wrote: > On 2019-01-10 17:32:58 [+0000], Hutter, Tony wrote: > > > But since when did out-of-tree modules use __kernel_fpu_begin? It's an > > > x86-only thing, and shouldn't really be used by anyone, right? > > > > ZFS on Linux uses it for checksums. Its removal is currently bre

3 users
lkml.org
[BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn Hi, first off, allow me to express that this is my first time ever writing on such a mailing list, and that if something is unclear or you would need more information, just let me know. I write to this list in hoping to see this change reverted. The linux kernel always said it would avoid breaking us

6 users
lkml.org
Re: [BREAKAGE] Since 4.18, kernel sets SB_I_NODEV implicitly on userns mounts, breaking systemd-nspawn Eric, this is entirely unacceptable. On Sat, Dec 22, 2018 at 12:58 PM Gabriel C nix.or.die@gmail.com wrote: > > Added some people to CC that might want to see this.. Thanks. > > Here's an email that was sent to lkml about the subject: > > > > https://lkml.org/lkml/2018/7/5/742 > > > > I link al

10 users
lkml.org
Hi everyone! It's been a long strange journey for this kernel release... While it was not the largest kernel release every by number of commits, it was larger than the last 3 releases, which is a non-trivial thing to do. After the original -rc1 bumps, things settled down on the code side and it looks like stuff came nicely together to make a solid kernel for everyone to use for a while. And given

4 users
lkml.org
This series introduces a new namespace for binfmt_misc. This allows to define a new interpreter for each new container. But the main goal is to be able to chroot to a directory using a binfmt_misc interpreter without being root. I have a modified version of unshare at: git@github.com:vivier/util-linux.git branch unshare-chroot with some new options to unshare binfmt_misc namespace and to chroot to

29 users
lkml.org
Linux 4.19-rc4 released, an apology, and a maintainership note [ So this email got a lot longer than I initially thought it would get, but let's start out with the "regular Sunday release" part ] Another week, another rc. Nothing particularly odd stands out on the technical side in the kernel updates for last week - rc4 looks fairly average in size for this stage in the release cycle, and all the

3 users
lkml.org
[patch v3 -mm 0/6] rewrite cgroup aware oom killer for general use There are three significant concerns about the cgroup aware oom killer as it is implemented in -mm: (1) allows users to evade the oom killer by creating subcontainers or using other controllers since scoring is done per cgroup and not hierarchically, (2) unfairly compares the root mem cgroup using completely different criteria than

3 users
lkml.org
Any known soft lockup issue with vfs_write()->fsnotify()? Hi, Recently people are getting a soft lock issue with vfs_write()->fsnotify(). The detailed calltrace is available at: https://github.com/coreos/bugs/issues/2356 https://github.com/coreos/bugs/issues/2364 The kernel versions showing up the issue are: 4.14.11-coreos 4.14.19-coreos 4.13.0-1009 -- this is the kernel with which I'm personally

3 users
lkml.org
[PATCH 4.16 64/81] fsnotify: Fix fsnotify_mark_connector race 4.16-stable review patch. If anyone has any objections, please let me know. ------------------ From: Robert Kolchmeyer rkolchmeyer@google.com commit d90a10e2444ba5a351fa695917258ff4c5709fa5 upstream. fsnotify() acquires a reference to a fsnotify_mark_connector through the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it a

3 users
lkml.org
Hi all, Network storage these days entails not only storing files and serving them via NFS or Samba, but maintaining continuous live backups, user accessible volume snapshots and remote replicas. The ddsnap snapshotting, replicating block device is the secret sauce of the Zumastor open source NAS project that does these things, and as far as we know, is the only way to do these things on Linux. ht

3 users
lkml.org
Yesterday MIPS Tech announced the latest generation of the MIPS family of architectures called nanoMIPS [1]. As part of the development we have been designing all the open source tools necessary to support the architecture and, thanks to the speed with which we were able to prototype, we have also been using these tools to shape the architecture along the way. This has led to some really interesti

3 users
lkml.org
An IOPS based I/O scheduler Flash based storage has some different characteristics against rotate disk. 1. no I/O seek. 2. read and write I/O cost usually is much different. 3. Time which a request takes depends on request size. 4. High throughput and IOPS, low latency. CFQ iosched does well for rotate disk, for example fair dispatching, idle for sequential read. It also has optimization for flash

3 users
lkml.org
Signed-off-by: David Woodhouse dwmw@amazon.co.uk --- arch/x86/include/asm/cpufeatures.h | 2 ++ arch/x86/kernel/cpu/common.c | 3 +++ 2 files changed, 5 insertions(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index 21ac898..1641c2f 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -342,5 +342,7 @@ #define X86_BUG_

5 users
lkml.org
Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation On Sun, 2018-01-21 at 14:27 -0800, Linus Torvalds wrote: > On Sun, Jan 21, 2018 at 2:00 PM, David Woodhouse dwmw2@infradead.org wrote: > >> > >> The patches do things like add the garbage MSR writes to the kernel > >> entry/exit points. That's insane. That says "we're trying to protect > >> the kernel".

10 users
lkml.org
Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation On Sun, Jan 21, 2018 at 12:28 PM, David Woodhouse dwmw2@infradead.org wrote: > On Sun, 2018-01-21 at 11:34 -0800, Linus Torvalds wrote: >> All of this is pure garbage. >> >> Is Intel really planning on making this shit architectural? Has >> anybody talked to them and told them they are f*cking insane? >>

3 users
lkml.org
This patch series enables the basic detection and usage of x86 indirect branch speculation feature. It enables the indirect branch restricted speculation (IBRS) on kernel entry and disables it on exit. It enumerates the indirect branch prediction barrier (IBPB). The x86 IBRS feature requires corresponding microcode support. It mitigates the variant 2 vulnerability described in https://googleprojec

3 users
lkml.org
[PATCH 17/23] x86, kaiser: use PCID feature to make user and kernel switches faster From: Dave Hansen dave.hansen@linux.intel.com Short summary: Use x86 PCID feature to avoid flushing the TLB at all interrupts and syscalls. Speed them up. Makes context switches and TLB flushing slower. Background: KAISER keeps two copies of the page tables. Switches between the copies are performed by writing to

3 users
lkml.org
[tip:x86/pti] x86/cpu, x86/pti: Do not enable PTI on AMD processors Commit-ID: 694d99d40972f12e59a3696effee8a376b79d7c8 Gitweb: https://git.kernel.org/tip/694d99d40972f12e59a3696effee8a376b79d7c8 Author: Tom Lendacky thomas.lendacky@amd.com AuthorDate: Tue, 26 Dec 2017 23:43:54 -0600 Committer: Thomas Gleixner tglx@linutronix.de CommitDate: Wed, 3 Jan 2018 15:57:59 +0100 x86/cpu, x86/pti: Do n

5 users
lkml.org
On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen andi@firstfloor.org wrote: > This is a fix for Variant 2 in > https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html > > Any speculative indirect calls in the kernel can be tricked > to execute any kernel code, which may allow side channel > attacks that can leak arbitrary kernel data. Why is this all done without any co

次のページ