On Di, 16.03.21 14:13, Christoph Hellwig (h...@infradead.org) wrote:
> On Mon, Mar 15, 2021 at 08:18:24PM +, Matthew Wilcox wrote:
> > On Mon, Mar 15, 2021 at 09:02:38PM +0100, Matteo Croce wrote:
> > > From: Matteo Croce
> > >
> > > Add a sequence number to the disk devices. This number is p
opback device with their seqnos, as
mentioned in that other mail.
But beggars can't be choosers. If we could propagate some uuid from
the loopback setup ioctl into the device so that that appears via
sysfs that would work too for me, but not as robustly, since we lack
the ordering to detec
media.
(That said, I think it would make sense to bump the IDs not only on
explicit user-induced reattachments, but also when media is replaced,
i.e. bump it more often than not)
Lennart
--
Lennart Poettering, Berlin
ere the kernel assigns these
seqnos strictly monotonically is not in the cards, then I'd be OK with
an approach where userspace can pick the ids, too. I'll take what I
can get. My primary concern is that we get something to match up
uevents, partition devices and the main block device with, and all of
the suggested approaches could deliver that.
Lennart
--
Lennart Poettering, Berlin
On Sa, 06.02.21 01:08, Matteo Croce (mcr...@linux.microsoft.com) wrote:
> From: Matteo Croce
>
> With this series a monotonically increasing number is added to disks,
> precisely in the genhd struct, and it's exported in sysfs and uevent.
>
> This helps the userspace correlate events for devices
; unprotected?
>
> i thought mprotect(PROT_EXEC) would get filtered
> with or without bti, is that not the case?
We can adjust the filter in systemd to match any combination of
flags to allow and to deny.
Lennart
--
Lennart Poettering, Berlin
I ave no horse in the race. Just let me know.
[An acceptable compromise might be to allow
mprotect(PROT_EXEC|PROT_BTI) if MDWE is on, but prohibit
mprotect(PROT_EXEC) without PROT_BTI. Then at least you get one of the
two protections, but not both. I mean, MDWE is not perfect anyway on
non-x86-6
gree with this: it's a bit weird to alter the bits after
the fact. Can't glibc set up everything right from the begining? That
would keep both concepts working.
Lennart
--
Lennart Poettering, Berlin
Hi!
Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE
ioctl doesn't work correctly. It gets confused if the
lo_offset/lo_sizelimit fields are set to non-zero.
In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with
.lo_offset=3221204992 and .lo_sizelimit=50331648 and
anularity, max file size, features, …),
because the kernel doesn't expose that at all right now.
OTOH I'd already be quite happy if struct statfs64 would expose
f_features, f_max_fsize, f_time_granularity, f_charset_case_handling
fields or so.
Lennart
--
Lennart Poettering, Berlin
y be
determined in a congruent way. I much prefer APIs where we provide a
struct to fill in and do a single syscall, and at least for some
fields we'd know afterwards that the fields were filled in together
and are congruent with each other.
I am a fan of the statx() system call I must say. If we had something
like this for the file system itself I'd be quite happy, it could tick
off many of the requests I list above.
Hope this is useful,
Lennart
--
Lennart Poettering, Berlin
oncatenation of
"/sys/fs/cgroup/" (because that's where cgroupfs is mounted), of "/"
(i.e. for the root cgroup) and of "/cgroup.controllers" (as that's the
file the attribute is exposed under).
And there you go:
"/sys/fs/cgroup/" + "/" + "/cgroup.controllers" →
"/sys/fs/cgroup///cgroup.controllers"
This is a real-life thing. Don't break this please.
Lennart
--
Lennart Poettering, Berlin
though it works fine with LOOP_SETSTATUS.
Let's correct that and propagate the flag in LOOP_CONFIGURE too.
Fixes: 3448914e8cc5("loop: Add LOOP_CONFIGURE ioctl")
Signed-off-by: Lennart Poettering
Acked-by: Martijn Coenen
---
drivers/block/loop.c | 2 ++
1 file changed, 2 in
On Fr, 07.08.20 10:53, Martijn Coenen (m...@android.com) wrote:
> Hi Lennart,
>
> Thanks again for the patch, I tested it and it looks good to me. I'll
> also add a test case to LTP for this. Two minor nits on the patch:
>
> On Thu, Aug 6, 2020 at 9:32 AM Lennart Poetteri
though it works fine with LOOP_SETSTATUS.
Let's correct that and propagate the flag in LOOP_SETSTATUS too.
Signed-off-by: Lennart Poettering
---
drivers/block/loop.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index d18160146226..2f13
On Fr, 27.09.19 08:58, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Fri, Sep 27, 2019 at 6:57 AM Lennart Poettering
> wrote:
> >
> > Doing the random seed in the boot loader is nice for two reasons:
> >
> > 1. It runs very very early, so that
uot;ok, if we trust the platform
> AT ALL, we can trust that". Since you can't reasonably do things like
> add EFI variables to your distro image by mistake.
NVRAM backing EFI vars sucks. Nothing you want to update on every
cycle. It's OK to update during OS installation, but during every
single boot? I'd rather not.
Lennart
--
Lennart Poettering, Berlin
27;t see it on any recent Intel machines.
Or to say this all differently: the hash table seeding and the uuid
case are two distinct cases in systemd, and I am sure they should be.
Lennart
--
Lennart Poettering, Berlin
l
> (even without trusting it completely)?)
Neither RDRAND nor /dev/urandom know a concept of "depleting
entropy". That concept does not exist for them. It does exist for
/dev/random, but only crazy people use that. systemd does not.
Lennart
--
Lennart Poettering, Berlin
y
rng_core.default_quality=1000 on the kernel cmdline to make them
credit entropy. I am pretty sure this should be the default now, in a
world where CONFIG_RANDOM_TRUST_CPU=y is set anyway. i.e. why say
RDRAND is fine but those chipsets are not? That makes no sense to me.
I am very sure that crediti
On Di, 17.09.19 09:23, Linus Torvalds (torva...@linux-foundation.org) wrote:
> On Tue, Sep 17, 2019 at 9:08 AM Lennart Poettering
> wrote:
> >
> > Here's what I'd propose:
>
> So I think this is ok, but I have another proposal. Before I post that
> on
the pool is initialized it's
initialized. This means any pending getrandom() on the whole system
will unblock at the same time, and from the on all getrandom()s will
be non-blocking.
systemd-random-seed.service is nowadays a synchronization point for
exactly the moment where the pool is con
icion crypto folks would argue that 128…256 is the only
sane range for cryptographic keys...
Lennart
--
Lennart Poettering, Berlin
On Di, 17.09.19 18:21, Willy Tarreau (w...@1wt.eu) wrote:
> On Tue, Sep 17, 2019 at 05:57:43PM +0200, Lennart Poettering wrote:
> > Note that calling getrandom(0) "too early" is not something people do
> > on purpose. It happens by accident, i.e. because we live in a wor
On Di, 17.09.19 12:30, Ahmed S. Darwish (darwish...@gmail.com) wrote:
> Ideally, systems would be configured with hardware random
> number generators, and/or configured to trust the CPU-provided
> RNG's (CONFIG_RANDOM_TRUST_CPU) or boot-loader provided ones
> (CONFI
On Di, 17.09.19 08:11, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote:
> > Willy Tarreau - 17.09.19, 07:24:38 CEST:
> > > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote:
> > > > >Well, the patch actually made getrandom(
On Mo, 16.09.19 13:21, Theodore Y. Ts'o (ty...@mit.edu) wrote:
> We could create a new flag, GRND_INSECURE, which never blocks. And
> that that allows us to solve the problem for silly applications that
> are using getrandom(2) for non-cryptographic use cases. Use cases
> might include Python di
but I
> claimed it as the "big red button" time).
As mentioned, in systemd's case, updating the random seed on disk
is entirely fine to take 5h or so. I don't really think we really need
to bound this in kernel space.
Lennart
--
Lennart Poettering, Berlin
o fail loudly in that case, I am sure.
Quite frankly, I don't think this is something to fix in the
kernel. Let the people putting together systems deal with this. Let
them provide a creditable hw rng, and let them pay the price if they
don't.
Lennart
--
Lennart Poettering, Berlin
On So, 15.09.19 09:27, Ahmed S. Darwish (darwish...@gmail.com) wrote:
> On Sun, Sep 15, 2019 at 08:51:42AM +0200, Lennart Poettering wrote:
> > On Sa, 14.09.19 09:30, Linus Torvalds (torva...@linux-foundation.org) wrote:
> [...]
> >
> > And please don't break /dev/ura
of hw rng, too. Otherwise the boot will block, yes.
Basically, just add "nofail" to a line in /etc/crypttab, and the entry
will be activated at boot, but we won't delay boot for it. It's going
to be activated as soon as the deps are fulfilled (and thus the pool
initialized), but
On So, 15.09.19 09:01, Willy Tarreau (w...@1wt.eu) wrote:
> On Sun, Sep 15, 2019 at 08:56:55AM +0200, Lennart Poettering wrote:
> > There's benefit in being able to wait until the pool is initialized
> > before we update the random seed stored on disk with a new one,
>
&
d
there's benefit in being able to wait until the pool is initialized
before we let cryptsetup read a fresh, one-time key for dm-crypt from
/dev/urandom. I fully understand that any such reporting for
initialization is "best-effort", i.e. to the point where we don't know
anything to the contrary, but at least give userspace that.
Lennart
--
Lennart Poettering, Berlin
On Sa, 14.09.19 09:30, Linus Torvalds (torva...@linux-foundation.org) wrote:
> > => src/random-seed/random-seed.c:
> > /*
> > * Let's make this whole job asynchronous, i.e. let's make
> > * ourselves a barrier for proper initialization of the
> > * random pool.
> > */
>
On Mi, 14.08.19 11:32, Alexandre Belloni (alexandre.bell...@bootlin.com) wrote:
> On 14/08/2019 11:09:36+0200, Lennart Poettering wrote:
> > On Mi, 14.08.19 10:31, Arnd Bergmann (a...@arndb.de) wrote:
> >
> > > - glibc stops passing the caller timezone argument to the k
his on its own without
involving userspace in that.
Lennart
--
Lennart Poettering, Berlin
s second best option for systemd and it's only one
> system call.
That doesn't really work for us as readlink() on that requires
CAP_SYS_PTRACE, and we need something that works unprivileged, which
PF_KTHREAD does.
Lennart
--
Lennart Poettering, Red Hat
On Wed, 28.06.17 09:06, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> On Wed, Jun 28, 2017 at 12:06 AM, Lennart Poettering
> wrote:
> > On Wed, 28.06.17 00:24, Luis R. Rodriguez (mcg...@kernel.org) wrote:
> >
> >> > Do you know how systemd developers feel
hose who want it external.
Certainly not. I'd sure know about that. ;-)
Lennart
--
Lennart Poettering, Red Hat
the lid. It's not supposed to be a work-around around broken
input drivers.
I am very sure that input drivers shouldn't lie to userspace. If you
don't know the state of the switch, then you don#t know it, and should
clarify that to userspace somehow.
Lennart
--
Lennart Poettering, Red Hat
md bug, and it should not be handled by the kernel
> community.
Uh if this is borked, we should indeed fix this in systemd. Is there
already a systemd github bug about this? If not, please create one,
and we'll look into it!
Thanks for working on this,
Lennart
--
Lennart Poettering, Red Hat
On Mon, 01.12.14 14:54, Dave Chinner (da...@fromorbit.com) wrote:
> On Mon, Dec 01, 2014 at 02:03:43AM +0100, Lennart Poettering wrote:
> > On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
> >
> > > CC'ing systemd folks.
> > >
> > &g
On Mon, 01.12.14 01:41, Richard Weinberger (rich...@nod.at) wrote:
> CC'ing systemd folks.
>
> Lennart, can you please explain why you need CONFIG_FHANDLE for systemd?
> Maybe I'm reading the source horrible wrong.
For two usecases:
a) Being able to detect if something is a mount point. The tra
outside, so that userspace
daemons can subscribe to that and then refresh the DHCP leases on their
own.
Lennart
--
Lennart Poettering, Red Hat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
ried both just running it and also running exec foo; both presented
> the same issue given that shell exec does not really execve.
Hmmm? You shell's "exec" command doesn't actually execve()? What are you
using? This doesn't sound very accurate...
Lennart
--
Lennart Poett
On Thu, 05.06.14 02:31, Luis R. Rodriguez (mcg...@suse.com) wrote:
> On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
> > On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
> >
> > > I'm cc'ing a few security folks as
you need to parse shell configuraiton fragments and just
want to execute on ot another program...
That said, I'd certainly make a clean cut and drop support for
/etc/sysconfig from any project I see, earlier rather than later, since
it's just cruft, a bad idea and should really jus
and is particularly messy if you intend to share devices
between containers.
> > logind can do this for you between sessions. But such a container setup
> > will never work without proper device namespacing.
>
> So how can it do it when there is no kernel support? You mean it coul
o a specific device at a specific moment
Well, there's no point in inventing any "mechanisms" like this, as long
as devices are not namespaced in the kernel, so that userspace in
containers can enumerate/probe/identify/... things correctly...
Lennart
--
Lennart Poettering, Red Hat
-
in the inadequate changelog he had.
>
> He also fails to explain why he needs the timestamp twice, as do you for
> that matter.
Well, I am mostly interesting int the monotonic timestamp. But given
that the kernel keeps the boottime clock value as well, and already
exposes it in a skewed
On Wed, 22.01.14 16:53, Peter Zijlstra (pet...@infradead.org) wrote:
>
> On Tue, Jan 21, 2014 at 07:10:04AM -0800, Dan Ballard wrote:
> > starttime in /proc/$PID/stat is inaccurate by "clock tick" granularity.
> > The kernel keeps better track os this exposes that in /prod/$PID/status
> > as Star
On Mon, 14.10.13 15:48, Matthew Garrett (matthew.garr...@nebula.com) wrote:
> On Mon, 2013-10-14 at 17:36 +0200, Lennart Poettering wrote:
>
> > Sorry, still not getting this. How should this ever work if the intel
> > video driver is compiled as kmod? That means that it
on of the ACPI backlight if the intel
driver is compiled will be an entirely pointless excercise on all
distros?
What am I missing?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
skip the registration
of the acpi backlight device if the "raw" device is supported? I mean,
the intel driver could be compiled as a module (and generally is on the
popular distros), so at the time the ACPI subsystem wants to register
the backlight device and know if a raw backlight device i
7;ll soon send another patch which also blacklists the thing in the
ideapad driver, so that only the intel backlight driver is enabled on
Yoga 13 systems, at which point everything will work fine.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "
ithout
acpi_osi="!Windows 2012" on the kernel command line. It appears that
backlight control via the EC simply is not available at all, regardless
whether done via ACPI or via the vendor driver.
Signed-off-by: Lennart Poettering
---
drivers/acpi/video_detect.c | 8
1 file changed, 8
e TTYs that UML uses, just not
/dev/tty[1..63] and everything is fine. That's what the virtualization
folks did with their hypervisor consoles, and is what we required from
the container folks too.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line
consoles makes no sense.
> (Same like on s390)
You are aware that turning off the tty subsystem in the kernel is
something different than turning off the virtual console? Note that the
whole stuff is really confusingly named, as /dev/tty1 is genericly named
"tty", even if it actually
gt;> something). Can we do something about the situation? Can we remove
> >> /dev/tty*, and provide /dev/hvc*? Will we be breaking existing users?
> >>
> >> Thanks.
> >>
> >> Lennart Poettering wrote:
> >>> UML shouldn't be pe
Heya,
On 29.06.2013 05:05, Tim Hockin wrote:
Come on, now, Lennart. You put a lot of words in my mouth.
I for sure am not going to make the PID 1 a client of another daemon. That's
just wrong. If you have a daemon that is both conceptually the manager of
another service and the client of tha
On 28.06.2013 20:53, Tim Hockin wrote:
a single-agent, we should make a kick-ass implementation that is
flexible and scalable, and full-featured enough to not require
divergence at the lowest layer of the stack. Then build systemd on
top of that. Let systemd offer more features and policies and
d preference? I'd
still call this "Boot and Core OS MC" as this has the slightler broader
topic, I guess...
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
>
> Can someone clue me in to the microconference format as regards LPC?
BTW, there's also this MC we proposed:
http://wiki.linuxplumbersconf.org/2013:boot_and_core_os
which sounds pretty close to fastboot?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: se
s into one string and then
split it up again. It sounds much more sensible to instead just pass the
string array around all the time. What's the reason to make this one
string first?
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
To unsubscribe from this list: send the line "unsubscribe
Heya,
On 08.04.2013 15:46, Glauber Costa wrote:
On 04/06/2013 05:21 AM, Tejun Heo wrote:
Hello, guys.
Hello Tejun, how are you?
Status-quo
==
tl;did read;
This is mostly sensible. There is still one problem that we hadn't yet
had the bandwidth to tackle that should be added t
Heya,
(sorry for the late reply)
On 16.08.2012 22:00, Tejun Heo wrote:
On Thu, Aug 16, 2012 at 01:44:56PM -0400, a...@redhat.com wrote:
Attaching meta information to services, in an easily discoverable
way. For example, in systemd we create one cgroup for each service, and
could then store d
e sure it
is paged in before I pass it on to the RT thread. So, there's a
mmap() during startup only, and then, during the whole runtime of my
program I want to page in the memory again and again, with long
intervals in between, but with no call to mmap()/munmap().
Lennart
--
Lennart Poe
ingle
difference that RLIMIT_CPU sends out a signal depending on the total
CPU time used for the process and the new RLIMIT based on the time the
process spent without sleeping. That would be a very reasonable
extension to the current RLIMIT_CPU model.
Thank you very much for doing this patch!
Lennart
-
From: Lennart Poettering <[EMAIL PROTECTED]>
This is the second version of the patch I sent yesterday which adds
DMI-based module autoloading to the Linux kernel. I fixed all the
issues Björn Steinbrink pointed out. (Thanks, btw!)
Again, the explanation:
The patch below adds DMI/SMBIOS
On Mon, 07.05.07 18:27, Greg KH ([EMAIL PROTECTED]) wrote:
Hi!
> On Tue, May 08, 2007 at 02:54:29AM +0200, Lennart Poettering wrote:
> > To take advantage of DMI based module autoloading, a driver should
> > export one or more MODULE_ALIAS fields similar to these:
> >
From: Lennart Poettering <[EMAIL PROTECTED]>
Hi!
The patch below adds DMI/SMBIOS based module autoloading to the Linux
kernel. The idea is to load laptop drivers automatically (and other
drivers which cannot be autoloaded otherwise), based on the DMI system
identification information of th
From: Lennart Poettering <[EMAIL PROTECTED]>
The ACPI EC that is used in MSI laptops knows some non-standard
commands for changing the screen brighntess and a few other things,
which are used by the msi-laptop.c driver. Unfortunately for these
commands no GPE events for IBF and OBF are tri
72 matches
Mail list logo
