On Fri, Apr 16, 2021 at 12:27:39PM +0800, Boqun Feng wrote:
> Josh, I think it's good if we can connect to the people working on Rust
> memoryg model, I think the right person is Ralf Jung and the right place
> is https://github.com/rust-lang/unsafe-code-guidelines, but you
> cerntainly know better
On Wed, Apr 14, 2021 at 01:21:52PM -0700, Linus Torvalds wrote:
> On Wed, Apr 14, 2021 at 1:10 PM Matthew Wilcox wrote:
> >
> > There's a philosophical point to be discussed here which you're skating
> > right over! Should rust-in-the-linux-kernel provide the same memory
> > allocation APIs as th
On Fri, Mar 05, 2021 at 10:10:05AM -0800, Junio C Hamano wrote:
> Christian Couder writes:
>
> >> (git notes would be nice for this, but they're hard to share reliably;
> >> the above mechanism to accumulate entries from a file in the repo seems
> >> simpler. I can imagine other possibilities.)
>
uld be nice for this, but they're hard to share reliably;
the above mechanism to accumulate entries from a file in the repo seems
simpler. I can imagine other possibilities.)
Does something like this seem potentially reasonable, and worth doing to
help people avoid future catastrophic data loss?
- Josh Triplett
The creation path of the NBD device respects max_part and only scans for
partitions if max_part is not 0. However, some other code paths ignore
max_part, and unconditionally scan for partitions. Add a check for
max_part on each partition scan.
Signed-off-by: Josh Triplett
---
Caught this when
On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote:
> > 3. Find a way to allow setgroups() in a user namespace while keeping
> >in mind the case of groups used for negative access control.
> >This was suggested by Josh Triplett and Geoffrey Thomas. Thei
scussed later, but the point is that
> this is why it's good to discuss format changes from a requirements
> perspective, so that if we do need to make an incompat change, we can
> kill multiple birds with a single stone.
I would be quite interested in that.
> On Thu, Oct 08, 2
On Thu, Oct 08, 2020 at 07:54:09PM -0700, Darrick J. Wong wrote:
> On Thu, Oct 08, 2020 at 03:38:58PM -0700, Josh Triplett wrote:
> > On Thu, Oct 08, 2020 at 10:54:48AM -0700, Darrick J. Wong wrote:
> > > > > the head", and continued with the notion that anything o
COW version of
SHARED_BLOCKS would need a different flag). It'd make more sense to key
this logic off of RO_COMPAT_READONLY or similar. But even better:
> "noblock_validity" in the superblock mount options field of the images
> you create.
Yeah, I can do that. That's a much better solution, thank you. It would
have been problematic to have to change the userspace that mounts the
filesystem to pass new mount options ("noblock_validity") for the new
kernel. But if I can embed it in the filesystem, that'll work.
I'll do that, and please feel free to drop the original proposed patch
as it's no longer needed. Thanks, Darrick.
- Josh Triplett
On Thu, Oct 08, 2020 at 01:25:57PM -0600, Andreas Dilger wrote:
> On Oct 8, 2020, at 1:12 PM, Josh Triplett wrote:
> > On Wed, Oct 07, 2020 at 08:57:12PM -0600, Andreas Dilger wrote:
> >> I *do* think that inline_data is an under-appreciated feature that I
> >>
On Wed, Oct 07, 2020 at 10:10:17PM -0400, Theodore Y. Ts'o wrote:
> On Wed, Oct 07, 2020 at 01:14:24PM -0700, Josh Triplett wrote:
> > That sounds like a conversation that would have been a lot more
> > interesting and enjoyable if it hadn't started with "can we
On Wed, Oct 07, 2020 at 08:57:12PM -0600, Andreas Dilger wrote:
> On Oct 7, 2020, at 2:14 PM, Josh Triplett wrote:
> > If those aren't the right way to express that, I could potentially
> > adapt. I had a similar such conversation on linux-ext4 already (about
> > inlin
On Wed, Oct 07, 2020 at 10:32:11AM -0400, Theodore Y. Ts'o wrote:
> On Wed, Oct 07, 2020 at 01:03:04AM -0700, Josh Triplett wrote:
> > > But can we *please* take your custom tool out back and shoot it in the
> > > head?
> >
> > Nope. As mentioned, this isn&#
On Tue, Oct 06, 2020 at 09:35:33AM -0400, Theodore Y. Ts'o wrote:
> On Mon, Oct 05, 2020 at 10:03:06PM -0700, Josh Triplett wrote:
> > I'm not trying to create a problem here; I'm trying to address a whole
> > family of problems. I was generally under the impression t
On Mon, Oct 05, 2020 at 10:03:13PM -0700, Josh Triplett wrote:
> On Mon, Oct 05, 2020 at 11:18:34PM -0400, Theodore Y. Ts'o wrote:
> > What Josh is proposing I'm pretty sure would also break "e2fsck -E
> > unshare_blocks", so that's another reason not to
I'm trying to figure out what solution you'd like to see here, as long
as it isn't "any userspace that isn't e2fsdroid can be broken at will".
I'd be willing to work to adapt the userspace bits I have to work around
the regression, but I'd like to get this on the radar so this doesn't
happen again.
- Josh Triplett
On Mon, Oct 05, 2020 at 10:36:39AM -0700, Darrick J. Wong wrote:
> On Mon, Oct 05, 2020 at 01:14:54AM -0700, Josh Triplett wrote:
> > Ran into an ext4 regression when testing upgrades to 5.9-rc kernels:
> >
> > Commit e7bfb5c9bb3d ("ext4: handle ad
On Mon, Oct 05, 2020 at 11:46:01AM +0200, Jan Kara wrote:
> On Mon 05-10-20 01:14:54, Josh Triplett wrote:
> > Ran into an ext4 regression when testing upgrades to 5.9-rc kernels:
> >
> > Commit e7bfb5c9bb3d ("ext4: handle add_system_zone() failure in
> > e
-117)".
This causes systems that previously worked correctly to fail when
upgrading to v5.9-rc2 or later.
Fix this by defaulting block_validity to off when
EXT4_FEATURE_RO_COMPAT_SHARED_BLOCKS is set.
Signed-off-by: Josh Triplett
Fixes: e7bfb5c9bb3d ("ext4: handle add_system_zone() fail
lly. When a
> function is called that returns EAGAIN the function isn't called again
> until the event loop indicates the the file descriptor is ready.
> Supporting EAGAIN when waiting on pidfds makes such libraries just work
> with little effort.
Thanks for the patch series, Christian!
This will make it much easier to use pidfd in non-blocking event loops.
Reviewed-by: Josh Triplett
- Josh Triplett
ch libraries just work with little effort.
>
> Link: https://lore.kernel.org/lkml/20200811181236.GA18763@localhost/
> Link: https://github.com/joshtriplett/async-pidfd
> Cc: Kees Cook
> Cc: Sargun Dhillon
> Cc: Jann Horn
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Oleg
On Thu, Sep 03, 2020 at 05:38:47PM +0200, Christian Brauner wrote:
> On Thu, Sep 03, 2020 at 04:22:42PM +0200, Oleg Nesterov wrote:
> > On 09/02, Christian Brauner wrote:
> > >
> > > It also makes the API more consistent and uniform. In essence, waitid() is
> > > treated like a read on a non-blocki
; close-on-exec flags.
>
> Link: https://lore.kernel.org/lkml/20200811181236.GA18763@localhost/
> Link: https://github.com/joshtriplett/async-pidfd
> Cc: Kees Cook
> Cc: Sargun Dhillon
> Cc: Oleg Nesterov
> Suggested-by: Josh Triplett
> Signed-off-by: Christian Brauner
Reviewed-by: Josh Triplett
On Tue, Aug 11, 2020 at 10:10:45PM +0200, Christian Brauner wrote:
> On Tue, Aug 11, 2020 at 11:12:36AM -0700, Josh Triplett wrote:
> > As far as I can tell, O_NONBLOCK has no effect on a pidfd. When calling
> > waitid on a pidfd for a running process, it always blocks unless
ss to return
EWOULDBLOCK?
This would make it easier to use pidfd in some non-blocking event loops.
- Josh Triplett
On July 31, 2020 11:53:08 PM PDT, Christoph Hellwig wrote:
>[note: private reply now to start a flame fest with the usual suspects]
[You still CCed LKML.]
>On Fri, Jul 31, 2020 at 01:11:46PM -0700, j...@joshtriplett.org wrote:
>> Christoph Hellwig wrote:
>> > we've had a bug in our resolution of
On Tue, Jul 28, 2020 at 10:40:38PM +0200, Pavel Machek wrote:
> > We just need to make sure that any kernel CI infrastructure tests that
> > right away, then, so that failures don't get introduced by a patch from
> > someone without a Rust toolchain and not noticed until someone with a
> > Rust too
On Thu, Jul 16, 2020 at 03:06:01PM +0200, Arnd Bergmann wrote:
> On Sun, Jul 12, 2020 at 9:39 PM Josh Triplett wrote:
> > On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> > >
> > > As an example:
> > > Ubuntu LTS releases upgrade to a new Rust ve
he kernel has a variety of higher-level interfaces and data
structures that make working in the kernel sometimes *easier* than the
average C program, I'd expect that we'll end up with common Rust
structures that do what people need, rather than people reimplementing
their own.
- Josh Triplett
On Sun, Jul 12, 2020 at 03:31:51PM +0300, Adrian Bunk wrote:
> On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> >...
> > but also a larger question of "should we do
> > this?" or "how might we place limits on where this can be used?"
> >...
>
> I won't attend, but I do have a to
On Fri, Jul 10, 2020 at 04:54:11PM -0700, Linus Torvalds wrote:
> On Fri, Jul 10, 2020 at 3:59 PM Josh Triplett 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
>
On Fri, Jul 10, 2020 at 02:50:22PM +0200, Christian Brauner wrote:
> On Fri, Jul 10, 2020 at 08:28:03AM +0200, Greg KH wrote:
> > On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> > > Hello folks,
> > > I'm working on putting together an LLVM "Micro Conference" for the
> > > upcom
On Thu, Jul 09, 2020 at 11:41:47AM -0700, Nick Desaulniers wrote:
> Hello folks,
> I'm working on putting together an LLVM "Micro Conference" for the
> upcoming Linux Plumbers Conf
> (https://www.linuxplumbersconf.org/event/7/page/47-attend). It's not
> solidified yet, but I would really like to r
On Tue, Jun 30, 2020 at 06:37:16PM +0100, Will Deacon wrote:
> The patches allow architectures to provide their own implementation of
> __READ_ONCE(). This serves two main purposes:
>
> 1. It finally allows us to remove [smp_]read_barrier_depends() from the
> Linux memory model and make it
: 8250: Support disabling mdelay-filled probes of
16550A variants")
Signed-off-by: Josh Triplett
---
v2: Add Reported-by lines.
drivers/tty/serial/8250/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index af0688
On Tue, May 26, 2020 at 11:47:44AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 26, 2020 at 01:40:06AM -0700, Josh Triplett wrote:
> > Some embedded devices still use these serial ports; make sure they're
> > still enabled by default on architectures more likely to hav
ts")
Signed-off-by: Josh Triplett
---
Based on user reports from embedded devices that need these variants.
drivers/tty/serial/8250/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index af0688156dd0..8195a31519ea
tag so it should
end up on any kernel that has the original patch.
- Josh Triplett
On Mon, May 25, 2020 at 09:52:54PM +0300, Vladimir Oltean wrote:
> Hi Josh,
>
> On Mon, 25 May 2020 at 20:28, Josh Triplett wrote:
> >
> > On Mon, May 25, 2020 at 04:02:38PM +0300, Vladimir Oltean wrote:
> > > On NXP T1040, the UART is typically detected as 16550A
On Mon, May 25, 2020 at 04:02:38PM +0300, Vladimir Oltean wrote:
> On NXP T1040, the UART is typically detected as 16550A_FSL64. After said
> patch, it gets detected as plain 16550A and the Linux console is
> completely garbled and missing characters.
Interesting that there's *new* powerpc hardwar
On Wed, May 20, 2020 at 02:26:38PM -0400, Daniel Jordan wrote:
> Please review and test, and thanks to Alex, Andrew, Josh, and Pavel for
> their feedback in the last version.
I re-tested v2:
Tested-by: Josh Triplett
[0.231435] node 1 initialised, 24189223 pages in 32ms
[0.236718
On Wed, May 13, 2020 at 04:16:22PM +, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> > Luis Chamberlain writes:
> >
> > > Certain symbols are not meant to be used by everybody, the security
> > > helpers for reading files directly is one such ca
On May 4, 2020 3:33:58 PM PDT, Alexander Duyck
wrote:
>On Thu, Apr 30, 2020 at 1:12 PM Daniel Jordan
> wrote:
>> /*
>> -* Initialize and free pages in MAX_ORDER sized increments so
>> -* that we can avoid introducing any issues with the buddy
>> -* allocator.
>> +
git padata-mt-definit-v1
>
> https://oss.oracle.com/git/gitweb.cgi?p=linux-dmjordan.git;a=shortlog;h=refs/heads/padata-mt-definit-v1
For the series (and the three prerequisite patches):
Tested-by: Josh Triplett
Thank you for writing this, and thank you for working towards
upstreaming it!
other virtual machines may have a huge amount of
memory but not necessarily run for a long time; on such systems, boot
time becomes critically important. Reducing boot time on cloud systems
and VMs makes the difference between "leave running to reduce latency"
and "just boot up when needed".
- Josh Triplett
On Thu, Apr 11, 2019 at 11:13:42PM -0400, Sinan Kaya wrote:
> On 4/11/2019 11:02 PM, Josh Triplett wrote:
> > I noticed one minor typo in patch 1/5, with that fixed, for the whole
> > series:
>
> Can you point to the typo?
I did, in my response to the patch itself:
s/Miscel
UG_KERNEL with CONFIG_DEBUG_MISC
> net: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
I noticed one minor typo in patch 1/5, with that fixed, for the whole
series:
Reviewed-by: Josh Triplett
urned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> "#ifdef CONFIG_DEBUG_MISC".
>
> Signed-off-by: Sinan Kaya
Minor typo below; with that:
Reviewed-by: Josh Triplett
And thank you!
> ---
> lib/Kconfig.debu
On Thu, Apr 11, 2019 at 06:27:04PM -0400, Sinan Kaya wrote:
> On 4/11/2019 6:21 PM, Kees Cook wrote:
> > > Proposed alternative plan: let's add a new symbol, something like
> > > DEBUG_MISC ("Miscellaneous debug code that should be under a more
> > > specific debug option but isn't"), make it depen
On Thu, Apr 11, 2019 at 10:00:24AM -0700, Kees Cook wrote:
> On Wed, Apr 10, 2019 at 10:34 PM Masahiro Yamada
> wrote:
> >
> > On Thu, Apr 11, 2019 at 11:47 AM Kees Cook wrote:
> > >
> > > On Wed, Apr 10, 2019 at 5:56 PM Sinan Kaya wrote:
> > > >
> > > > We can't seem to have a kernel with CONFI
On Wed, Apr 10, 2019 at 11:13:52PM -0400, Sinan Kaya wrote:
> On 4/10/2019 11:02 PM, Josh Triplett wrote:
> > Then let's fix*that*, and get checkpatch to help enforce it in the future.
> > EXPERT doesn't affect code generation, and neither should this.
>
> I think
On April 10, 2019 4:24:18 PM PDT, Kees Cook wrote:
>On Wed, Apr 10, 2019 at 4:22 PM Josh Triplett
>wrote:
>>
>> On April 10, 2019 3:58:55 PM PDT, Kees Cook
>wrote:
>> >On Wed, Apr 10, 2019 at 3:42 PM Sinan Kaya wrote:
>> >>
>> >> We
On April 10, 2019 3:58:55 PM PDT, Kees Cook wrote:
>On Wed, Apr 10, 2019 at 3:42 PM Sinan Kaya wrote:
>>
>> We can't seem to have a kernel with CONFIG_EXPERT set but
>> CONFIG_DEBUG_KERNEL unset these days.
>>
>> While some of the features under the CONFIG_EXPERT require
>> CONFIG_DEBUG_KERNEL, i
On Fri, Dec 14, 2018 at 09:03:11AM -0800, Sean Christopherson wrote:
> On Fri, Dec 14, 2018 at 07:38:30AM -0800, Sean Christopherson wrote:
> > On Fri, Dec 14, 2018 at 07:12:04AM -0800, Sean Christopherson wrote:
> > > On Fri, Dec 14, 2018 at 09:55:49AM +, Jethro Beekman wrote:
> > > > On 2018-
On Mon, Dec 10, 2018 at 03:21:37PM -0800, Sean Christopherson wrote:
> At that point I realized it's a hell of a lot easier to simply provide
> an IOCTL via /dev/sgx that allows userspace to register a per-process
> ENCLU exception handler. At a high level, the basic idea is the same
> as the vDSO
On Mon, Dec 10, 2018 at 09:27:04AM +0100, Pavel Machek wrote:
> On Sun 2018-12-09 23:47:17, Josh Triplett wrote:
> > On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote:
> > ...
> > > > > > The default permissions for the device are 600.
> > > &g
On Sun, Dec 09, 2018 at 09:06:00PM +0100, Pavel Machek wrote:
...
> > > > The default permissions for the device are 600.
> > >
> > > Good. This does not belong to non-root.
> >
> > There are entirely legitimate use cases for using this as an
> > unprivileged user. However, that'll be up to syste
to make it
> > easy to see how many instances there are, replacing the earlier wall of
> > 'a' characters.
> >
> > Reported-by: Josh Triplett
> > Signed-off-by: Paul E. McKenney
> >
> > diff --git a/tools/testing/selftests/rc
On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> >
On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney
> > wrote:
> > > --- a/tools/testing/selftests/rcutorture/bin/mkini
On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney wrote:
> --- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> +++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
> @@ -39,9 +39,22 @@ mkdir $T
>
> cat > $T/init << '__EOF___'
> #!/bin/sh
> +# Run in userspace a f
On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> > Not when that document started out effectively saying, in an elaborate
> > way, "code > people".
>
> Interesting.
>
> I
On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> On Wed, Oct 24 2018, Josh Triplett wrote:
>
> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >>
> >> > On Mon, Oct 22, 2018 at 08
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> On Sun, Oct 21 2018, Josh Triplett wrote:
>
> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> I call on you, Greg:
> >> - to abandon this divisive attempt to impose a "
On Mon, Oct 22, 2018 at 09:16:20PM -0700, Joe Perches wrote:
> On Mon, 2018-10-22 at 22:10 +0100, Greg Kroah-Hartman wrote:
> > On Sat, Oct 20, 2018 at 01:15:14PM -0700, James Bottomley wrote:
> > > This is the series of patches which has been discussed on both ksummit-
> > > discuss and linux-kern
On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
> - to return to your core competence of building a great team around
>a great kernel
>
> #Isupportreversion
>
On Wed, Oct 17, 2018 at 08:49:15AM -0700, James Bottomley wrote:
> On Wed, 2018-10-17 at 08:21 -0700, Josh Triplett wrote:
> > People in underrepresented and commonly marginalized groups,
> > especially those more commonly overlooked, don't always know if a
> > g
On Wed, Oct 17, 2018 at 06:32:36AM -0700, Guenter Roeck wrote:
> One could consider adding something like "discrimination factors such as",
> or maybe "or any other discrimination factors not listed here" to the
> original text. Or a simple "regardless of, for example, ...".
These sound like perfe
On Wed, Oct 17, 2018 at 11:31:35AM +0200, Geert Uytterhoeven wrote:
> Hi Josh,
>
> Thanks for your comments!
>
> On Wed, Oct 17, 2018 at 11:13 AM Josh Triplett wrote:
> > On Wed, Oct 17, 2018 at 09:19:01AM +0200, Geert Uytterhoeven wrote:
> > > Providing an e
On Wed, Oct 17, 2018 at 09:19:01AM +0200, Geert Uytterhoeven wrote:
> Providing an explicit list of discrimination factors may give the false
> impression that discrimination based on other unlisted factors would be
> allowed.
This impression is, in fact, false, as has already been discussed
elsew
On Wed, Oct 10, 2018 at 01:55:04PM -0700, Frank Rowand wrote:
> On 10/07/18 01:51, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allowed.
> >
> > Avoid any ambigu
On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> > > The current code of conduct has an ambiguity in the it considers
> > &g
On Mon, Oct 08, 2018 at 04:23:57PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Oct 2018 08:30:20 -0700
> James Bottomley escreveu:
>
> > On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
On Mon, Oct 08, 2018 at 02:15:25PM -0400, Chris Mason wrote:
> On 6 Oct 2018, at 17:37, James Bottomley wrote:
> > Significant concern has been expressed about the responsibilities
> > outlined in
> > the enforcement clause of the new code of conduct. Since there is
> > concern
> > that this becom
On Mon, Oct 08, 2018 at 04:42:47PM +0100, Alan Cox wrote:
> > In any case, this is not the appropriate place for such patches, any
> > more than it's the place for patches to the GPL.
>
> I disagree. We had the GPLv2 or GPLv3 discussion on the kernel mailing
> list. The syscall clarification was d
On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> The current code of conduct has an ambiguity in the it considers publishing
> private information such as email addresses unacceptable behaviour. Since
> the Linux kernel collects and publishes email addresses as part of the patch
On Sun, Oct 07, 2018 at 08:18:26PM +0300, Laurent Pinchart wrote:
> Hi Josh,
>
> On Sunday, 7 October 2018 14:35:14 EEST Josh Triplett wrote:
> > On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> > > Providing an explicit list of discrimination fa
On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> Providing an explicit list of discrimination factors may give the false
> impression that discrimination based on other unlisted factors would be
> allowed.
>
> Avoid any ambiguity by removing the list, to ensure "a harassment-f
On Thu, Oct 04, 2018 at 01:39:50PM -0700, Luis Chamberlain wrote:
> On Thu, Oct 04, 2018 at 01:09:00PM -0700, Josh Triplett wrote:
> > On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> > > Every now and then a project is born, and they decide to use Linux&
On Thu, Oct 04, 2018 at 01:02:49PM -0700, Luis Chamberlain wrote:
> Every now and then a project is born, and they decide to use Linux's
> kconfig to enable configuration of their project. As it stands we *know*
> kconfig is now used in at least over 12 different projects [0]. I myself
> added kcon
On Wed, Sep 05, 2018 at 08:20:39PM +0200, Luc Van Oostenryck wrote:
> On Mon, Sep 03, 2018 at 10:33:11PM +0200, Miguel Ojeda wrote:
> > Sparse knows about a few more attributes now, so we can remove
> > the __CHECKER__ conditions from them (which, in turn, allow us
> > to move some of them later on
On Wed, Aug 29, 2018 at 09:10:17PM -0700, Paul E. McKenney wrote:
> On Wed, Aug 29, 2018 at 08:22:16PM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 29, 2018 at 10:00:26PM -0400, Steven Rostedt wrote:
> > > On Wed, 29 Aug 2018 15:38:30 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > Hello!
>
On Thu, Aug 23, 2018 at 10:43:59AM -0700, Paul E. McKenney wrote:
> Hello!
>
> Does anyone do kernel-only deployments, for example, setting up an
> embedded device having a Linux kernel and absolutely no userspace
> whatsoever?
I would very much *like* to do this. One day I'd like to have a
CONFI
_start
>
>
> as sl.s -o sl.o
> ld sl.o -o init
>
> 'Ere you go, no libc needed. If your arch is not amd64, just say so.
"pause" ($34) would also suffice, and would not require an argument or a
.data section.
- Josh Triplett
On August 17, 2018 1:39:35 PM PDT, Andrew Morton
wrote:
>On Fri, 17 Aug 2018 12:10:35 +0200 Rasmus Villemoes
> wrote:
>
>> Appararently, it's possible to have a non-trivial TU include a few
>headers,
>> including linux/build_bug.h, without ending up with linux/types.h. So
>> the 0day bot sent me
On Wed, Aug 08, 2018 at 04:02:29PM -0700, Shakeel Butt wrote:
> On Wed, Aug 8, 2018 at 11:02 AM Josh Triplett wrote:
> >
> > On Wed, Aug 08, 2018 at 07:30:13PM +0300, Kirill Tkhai wrote:
> > > On 08.08.2018 19:23, Kirill Tkhai wrote:
> > > > On 08.08.2018 19:
On Wed, Aug 08, 2018 at 07:30:13PM +0300, Kirill Tkhai wrote:
> On 08.08.2018 19:23, Kirill Tkhai wrote:
> > On 08.08.2018 19:13, Josh Triplett wrote:
> >> On Wed, Aug 08, 2018 at 01:17:44PM +0300, Kirill Tkhai wrote:
> >>> On 08.08.2018 10:20, Michal Hocko wrote:
&
On Wed, Aug 08, 2018 at 01:17:44PM +0300, Kirill Tkhai wrote:
> On 08.08.2018 10:20, Michal Hocko wrote:
> > On Tue 07-08-18 18:37:36, Kirill Tkhai wrote:
> >> This patch kills all CONFIG_SRCU defines and
> >> the code under !CONFIG_SRCU.
> >
> > The last time somebody tried to do this there was a
On Sat, Jul 14, 2018 at 02:39:24PM -0500, Eric W. Biederman wrote:
> Josh Triplett writes:
>
> > On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
> >> For a config option that no one has come forward with an actual real
> >> world use case for d
On Sat, Jul 14, 2018 at 02:04:46PM -0500, Eric W. Biederman wrote:
> For a config option that no one has come forward with an actual real
> world use case for disabling, that cost seems much too high.
The real-world use case is precisely as stated: code size, both storage
and RAM.
I regularly enc
s it.
>
> Right, and I would bet the minification folks would like to keep it
> out of their builds too. I think we should keep the config.
Thank you, Kees. Yes, please.
- Josh Triplett
On Tue, May 15, 2018 at 02:53:52PM -0700, Nadav Amit wrote:
> Josh Triplett wrote:
>
> > On Tue, May 15, 2018 at 07:11:08AM -0700, Nadav Amit wrote:
> >> GCC considers the number of statements in inlined assembly blocks,
> >> according to new-lines and semicolons, a
On Tue, May 15, 2018 at 07:11:08AM -0700, Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts informatio
On Mon, Apr 30, 2018 at 02:31:30PM +1000, NeilBrown wrote:
> list_for_each_entry_from_rcu() is an RCU version of
> list_for_each_entry_from(). It walks a linked list under rcu
> protection, from a given start point.
>
> It is similar to list_for_each_entry_continue_rcu() but starts *at*
> the giv
On Thu, Mar 01, 2018 at 12:38:16AM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be f
On Wed, Feb 28, 2018 at 06:26:03PM +, Luis R. Rodriguez wrote:
> On Wed, Feb 28, 2018 at 01:07:23AM -0800, Josh Triplett wrote:
> > On Wed, Feb 28, 2018 at 01:32:37AM +, Luis R. Rodriguez wrote:
> > > On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> >
On Wed, Feb 28, 2018 at 01:32:37AM +, Luis R. Rodriguez wrote:
> On Tue, Feb 27, 2018 at 03:18:15PM -0800, Kees Cook wrote:
> > On Fri, Feb 23, 2018 at 6:46 PM, Luis R. Rodriguez
> > wrote:
> > > Since we now have knobs to twiddle what used to be set on kernel
> > > configurations we can buil
On Tue, Feb 06, 2018 at 09:02:00PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 06, 2018 at 08:23:34PM -0800, Matthew Wilcox wrote:
> > On Tue, Feb 06, 2018 at 06:17:03PM -0800, Paul E. McKenney wrote:
> > > So it is OK to kvmalloc() something and pass it to either kfree() or
> > > kvfree(), and it
se disabled.
I wonder how easily we could make a kconfig option for an "all except"
or "none except" config? Such an option would read a minimal config
snippet containing only specific options, and then act like
allyesconfig/allmodconfig/allnoconfig as long as doing so doesn't
change anything from the minimal config snippet.
- Josh Triplett
+linux-sparse
On Fri, Dec 22, 2017 at 05:36:34AM -0800, Matthew Wilcox wrote:
> On Fri, Dec 22, 2017 at 04:31:12AM -0800, Matthew Wilcox wrote:
> > On Thu, Dec 21, 2017 at 08:21:20PM -0800, Josh Triplett wrote:
> > > On Thu, Dec 21, 2017 at 05:10:00PM -0800, Matthew Wilcox wrote
1 - 100 of 1338 matches
Mail list logo
