Re: [systemd-devel] Scan all USB devices from Linux service

[Greg KH]

On Thu, Feb 15, 2024 at 12:04:27PM +, Andy Pieters wrote:
> On Thu, 15 Feb 2024 at 09:12, Greg KH  wrote:
> 
> >
> > provenance matters HUGELY when it comes to code, as you need a license
> > and other things as well (copyright law is strict.)  "AI generated" code
> > has none of that and as such, can NOT be used for almost any use until
> > that is sorted out.
> >
> > Just go talk to your lawyer about the issues involved please if you have
> > any questions, it's not trivial.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> I think you're moving the goalpost here by now invoking copyright law.

Nope!

> All I'm saying is, don't blanket ban code just because it is AI
> 'generated'. The guy disclosed it even.

And as such, you can not trust it nor use it for anything at all as
again, the copyright and license of it is unknown and probably violates
everyone's policies.

So it shouldn't even be posted as an example.

thanks,

greg k-h

Re: [systemd-devel] Scan all USB devices from Linux service

[Greg KH]

On Thu, Feb 15, 2024 at 08:45:41AM +, Andy Pieters wrote:
> On Thu, 15 Feb 2024 at 08:32, Reto  wrote:
> 
> > On Wed, Feb 14, 2024 at 05:56:31PM +0100, Vadim Lebedev wrote:
> > > This is what ChatGPT proposes:
> >
> > Can we like not...
> > If people want to ask a generative AI they do so on their own.
> >
> > Let's keep responses based on human interaction shall we, rather than
> > parroting
> > math models.
> >
> 
> 
> Respectfully, I disagree.
> 
> 
> Comment on the code itself, or suggest ways to improve it, but don't diss
> on it just because it was 'generated by AI'
> 
> What does the provenance matter? He's got a problem, he's doing some work
> towards solving it, why bar the submission just because you don't agree
> with its origins? (sounds familiar...)

provenance matters HUGELY when it comes to code, as you need a license
and other things as well (copyright law is strict.)  "AI generated" code
has none of that and as such, can NOT be used for almost any use until
that is sorted out.

Just go talk to your lawyer about the issues involved please if you have
any questions, it's not trivial.

thanks,

greg k-h

Re: [systemd-devel] Scan all USB devices from Linux service

[Greg KH]

On Wed, Feb 14, 2024 at 08:24:25PM +0530, Muni Sekhar wrote:
> HI all,
> 
> USB devices can have multiple interfaces (functional units) that serve
> different purposes (e.g., data transfer, control, audio, etc.).
> 
> Each interface can have an associated string descriptor (referred to
> as iInterface). The string descriptor provides a human-readable name
> or description for the interface.
> 
> >From user space service utility, How to scan all the USB devices
> connected to the system and read each interface string
> descriptor(iInterface)  and check whether it matches "Particular
> String" or not.

Just write some code to do so using either libusb, or your own sysfs
scanning logic or talk directly to all of the usb devices using usbfs.

> The service program should trigger scanning all the USB devices on any
> USB device detection or removal. Can libusb be used for it?

For detection/removal, no, libusb isn't for that.  udev can provide you
the needed callbacks to your code for that situation.

But what problem are you trying to solve that isn't already handled by
the kernel and userspace usb handling logic already?

good luck!

greg k-h

Re: Query on dynamic update of Kernel comandline

[Greg KH]

On Thu, Dec 21, 2023 at 08:13:15AM +, HARSHAL PATIL (QUIC) wrote:
> Hello Everyone,
> 
> Can someone please reply to our query?
> 
> We are really blocked due to this and unable to process in our project. It 
> will be really great.

If you need paid support for a project that you depend on, I suggest
contacting one of the many companies that provide such support.
Otherwise, just asking the community to do your work for you again,
isn't usually the best way to run a company project :)

Why not work with the other developers in your company that have
experience with the kernel and these things?  Ignoring them feels very
odd to me.

good luck!

greg k-h

Re: [systemd-devel] Error during SCC_DAEMON installation

[Greg KH]

On Thu, Aug 24, 2023 at 01:28:57PM +, Maber, Paul wrote:
> Classification: Confidential

Really?  You sent this to a public mailing list :(

> CONFIDENTIALITY NOTICE: Proprietary/Confidential Information belonging to CGI 
> Group Inc. and its affiliates may be contained in this message. If you are 
> not a recipient indicated or intended in this message (or responsible for 
> delivery of this message to such person), or you think for any reason that 
> this message may have been addressed to you in error, you may not use or copy 
> or deliver this message to anyone else. In such case, you should destroy this 
> message and are asked to notify the sender by reply e-mail

Now deleted.

Re: [systemd-devel] how to let systemd hibernate start/stop the swap area?

[Greg KH]

On Thu, Mar 30, 2023 at 09:09:19PM +1100, Michael Chapman wrote:
> On Thu, 30 Mar 2023, Luca Boccassi wrote:
> > On Thu, 30 Mar 2023 at 10:15, Michael Chapman  
> > wrote:
> > >
> > > On Thu, 30 Mar 2023, Lennart Poettering wrote:
> > > > On Mi, 29.03.23 13:53, Christoph Anton Mitterer (cales...@scientia.org) 
> > > > wrote:
> > > >
> > > > > > > That's a bad idea btw. I'd advise you not to do that: on modern
> > > > > > > systems you want swap, since it makes anonymous memory 
> > > > > > > reclaimable.
> > > > > > > I
> > > > > > > am not sure where you are getting this idea from that swap was
> > > > > > > bad.
> > > > >
> > > > > Well I haven't said it's bad, but I guess it depends on the use case
> > > > > any available RAM.
> > > >
> > > > In almost all scenarios you want swap, regardless if little RAM or a
> > > > lot. For specialist cases where you run everything from memory, and
> > > > not even programs are backed by disk there might be exceptions. But
> > > > that#s almost never the case.
> > >
> > > One specific case where I deliberately chose _not_ to use swap: large
> > > hypervisors with local storage.
> > >
> > > With swap on the host enabled, all that ended up happening was that local
> > > IO activity caused idle guest memory to be gradually swapped out.
> > > Eventually all of the swap space filled up, and the system was exactly
> > > where it would have been had it not had any swap space configured in the
> > > first place -- except that it was now _a lot_ slower to migrate those
> > > swapped-out guests to other hypervisors.
> > >
> > > - Michael
> > 
> > The solution there is to ensure the cgroup configuration for the
> > slices where the guests run have memory.swap.max=0, rather than
> > disabling it for the whole system.
> 
> Perhaps, but given the rest of processes on the system need just a few 
> hundred MB max, and the server has hundreds of GB of RAM, it really makes 
> little difference. Turning off swap altogether is plain _simpler_.

So you penalize the runtime performance of guests for the infrequent
migration delay?  Sounds like a bad trade-off for any real workload
those guests are doing.  Shouldn't the goal of the system be to solve
the problem the guests are trying to solve instead of being optimized
for the infrequent administration tasks?

good luck!

greg k-h

Re: [systemd-devel] BUG: kworker + systemd-udevd memory leaks found in 6.1.0-rc4

[Greg KH]

On Tue, Nov 29, 2022 at 04:35:10AM +0100, Mirsad Goran Todorovac wrote:
> On 10. 11. 2022. 10:20, Greg KH wrote:
> > On Thu, Nov 10, 2022 at 05:57:57AM +0100, Mirsad Goran Todorovac wrote:
> > > On 04. 11. 2022. 11:40, Mirsad Goran Todorovac wrote:
> > > 
> > > > Dear Sirs,
> > > > 
> > > > When building a RPM 6.1.0-rc3 for AlmaLinux 8.6, I have enabled
> > > > CONFIG_DEBUG_KMEMLEAK=y
> > > > and the result showed an unreferenced object in kworker process:
> > > > 
> > > > # cat /sys/kernel/debug/kmemleak
> > > > unreferenced object 0xa01dabff6100 (size 16):
> > > >    comm "kworker/u12:4", pid 400, jiffies 4294894771 (age 5284.956s)
> > > >    hex dump (first 16 bytes):
> > > >      6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> > > >    backtrace:
> > > >      [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> > > >      [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> > > >      [<05472512>] kstrdup+0x36/0x70
> > > >      [<2f797ac4>] kstrdup_const+0x28/0x30
> > > >      [<e3f86581>] kvasprintf_const+0x78/0xa0
> > > >      [<e15920f7>] kobject_set_name_vargs+0x23/0xa0
> > > >      [<4158a6c0>] dev_set_name+0x53/0x70
> > > >      [<1a120541>] memstick_check+0xff/0x384 [memstick]
> > > >      [<122bb894>] process_one_work+0x214/0x3f0
> > > >      [<fcf282cc>] worker_thread+0x34/0x3d0
> > > >      [<02409855>] kthread+0xed/0x120
> > > >      [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > > > unreferenced object 0xa01dabff6ec0 (size 16):
> > > >    comm "kworker/u12:4", pid 400, jiffies 4294894774 (age 5284.944s)
> > > >    hex dump (first 16 bytes):
> > > >      6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> > > >    backtrace:
> > > >      [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> > > >      [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> > > >      [<05472512>] kstrdup+0x36/0x70
> > > >      [<2f797ac4>] kstrdup_const+0x28/0x30
> > > >      [<e3f86581>] kvasprintf_const+0x78/0xa0
> > > >      [<e15920f7>] kobject_set_name_vargs+0x23/0xa0
> > > >      [<4158a6c0>] dev_set_name+0x53/0x70
> > > >      [<1a120541>] memstick_check+0xff/0x384 [memstick]
> > > >      [<122bb894>] process_one_work+0x214/0x3f0
> > > >      [<fcf282cc>] worker_thread+0x34/0x3d0
> > > >      [<02409855>] kthread+0xed/0x120
> > > >      [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > > > #
> > > > 
> > > > Please fing the build config and lshw output attached.
> > > > 
> > > > dmesg is useless, as it is filled with events like:
> > > > 
> > > > [ 6068.996120] evbug: Event. Dev: input4, Type: 1, Code: 31, Value: 0
> > > > [ 6068.996121] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > > > [ 6069.124145] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 
> > > > 458762
> > > > [ 6069.124149] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 1
> > > > [ 6069.124150] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > > > [ 6069.196003] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 
> > > > 458762
> > > > [ 6069.196007] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 0
> > > > [ 6069.196009] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > > > [ 6069.788129] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 
> > > > 458792
> > > > [ 6069.788133] evbug: Event. Dev: input4, Type: 1, Code: 28, Value: 1
> > > > [ 6069.788135] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > > 
> > > This bug is confirmed in 6.1-rc4, among the "thermald" and "systemd-dev"
> > > kernel memory leaks, potentially exposing race conditions or other more
> > > serious bug.
> > 
> > How is a memory leak a race condition?
> > 
> > > The bug is now also confirmed and now manifested also in the Ubuntu 22.04
> > > LTS jammy 6.1-rc4 build.
> > > 
> > > Here is 

Re: [systemd-devel] systemd-repart with multiple block devices

[Greg KH]

On Wed, Nov 16, 2022 at 05:00:04PM -0500, Mehmet Akbulut wrote:
> This email contains information belonging to Motional AD LLC or its 
> affiliates and may contain confidential, proprietary, copyrighted and/or 
> privileged information. Any unauthorized review, use, reliance, disclosure, 
> distribution or copying is prohibited. If you are not the intended 
> recipient, immediately destroy all copies of the original email and any 
> attachments and contact the sender by reply email.

Now deleted.

Re: [systemd-devel] BUG: kworker + systemd-udevd memory leaks found in 6.1.0-rc4

[Greg KH]

On Thu, Nov 10, 2022 at 05:57:57AM +0100, Mirsad Goran Todorovac wrote:
> On 04. 11. 2022. 11:40, Mirsad Goran Todorovac wrote:
> 
> > Dear Sirs,
> > 
> > When building a RPM 6.1.0-rc3 for AlmaLinux 8.6, I have enabled
> > CONFIG_DEBUG_KMEMLEAK=y
> > and the result showed an unreferenced object in kworker process:
> > 
> > # cat /sys/kernel/debug/kmemleak
> > unreferenced object 0xa01dabff6100 (size 16):
> >   comm "kworker/u12:4", pid 400, jiffies 4294894771 (age 5284.956s)
> >   hex dump (first 16 bytes):
> >     6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> >   backtrace:
> >     [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> >     [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> >     [<05472512>] kstrdup+0x36/0x70
> >     [<2f797ac4>] kstrdup_const+0x28/0x30
> >     [] kvasprintf_const+0x78/0xa0
> >     [] kobject_set_name_vargs+0x23/0xa0
> >     [<4158a6c0>] dev_set_name+0x53/0x70
> >     [<1a120541>] memstick_check+0xff/0x384 [memstick]
> >     [<122bb894>] process_one_work+0x214/0x3f0
> >     [] worker_thread+0x34/0x3d0
> >     [<02409855>] kthread+0xed/0x120
> >     [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > unreferenced object 0xa01dabff6ec0 (size 16):
> >   comm "kworker/u12:4", pid 400, jiffies 4294894774 (age 5284.944s)
> >   hex dump (first 16 bytes):
> >     6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> >   backtrace:
> >     [<9ff951f6>] __kmem_cache_alloc_node+0x380/0x4e0
> >     [<451f4268>] __kmalloc_node_track_caller+0x55/0x150
> >     [<05472512>] kstrdup+0x36/0x70
> >     [<2f797ac4>] kstrdup_const+0x28/0x30
> >     [] kvasprintf_const+0x78/0xa0
> >     [] kobject_set_name_vargs+0x23/0xa0
> >     [<4158a6c0>] dev_set_name+0x53/0x70
> >     [<1a120541>] memstick_check+0xff/0x384 [memstick]
> >     [<122bb894>] process_one_work+0x214/0x3f0
> >     [] worker_thread+0x34/0x3d0
> >     [<02409855>] kthread+0xed/0x120
> >     [<7b02b4a3>] ret_from_fork+0x1f/0x30
> > #
> > 
> > Please fing the build config and lshw output attached.
> > 
> > dmesg is useless, as it is filled with events like:
> > 
> > [ 6068.996120] evbug: Event. Dev: input4, Type: 1, Code: 31, Value: 0
> > [ 6068.996121] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.124145] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458762
> > [ 6069.124149] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 1
> > [ 6069.124150] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.196003] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458762
> > [ 6069.196007] evbug: Event. Dev: input4, Type: 1, Code: 34, Value: 0
> > [ 6069.196009] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> > [ 6069.788129] evbug: Event. Dev: input4, Type: 4, Code: 4, Value: 458792
> > [ 6069.788133] evbug: Event. Dev: input4, Type: 1, Code: 28, Value: 1
> > [ 6069.788135] evbug: Event. Dev: input4, Type: 0, Code: 0, Value: 0
> 
> This bug is confirmed in 6.1-rc4, among the "thermald" and "systemd-dev"
> kernel memory leaks, potentially exposing race conditions or other more
> serious bug.

How is a memory leak a race condition?

> The bug is now also confirmed and now manifested also in the Ubuntu 22.04
> LTS jammy 6.1-rc4 build.
> 
> Here is the kmemleak output:
> 
> unreferenced object 0x9242b13b3980 (size 64):
>   comm "kworker/5:3", pid 43106, jiffies 4305052439 (age 71828.792s)
>   hex dump (first 32 bytes):
>     80 8b a0 f0 42 92 ff ff 00 00 00 00 00 00 00 00 B...
>     20 86 a0 f0 42 92 ff ff 00 00 00 00 00 00 00 00 ...B...
>   backtrace:
>     [] __kmem_cache_alloc_node+0x380/0x4e0
>     [<2b17af47>] kmalloc_node_trace+0x27/0xa0
>     [<4c09eee5>] xhci_alloc_command+0x6e/0x180

This is a totally different backtrace from above, how are they related?

This looks like a potential xhci issue.  Can you use 'git bisect' to
track down the offending change that caused this?

thanks,

greg k-h

Re: [systemd-devel] systemd-udevd -any way to list triggered rules with their files etc ?

[Greg KH]

On Mon, Oct 03, 2022 at 02:17:04AM +, Branko wrote:
> 
> cat /etc/udev/rules.d/99-zz-network.rules:
> ACTION=="add", DRIVERS=="?*", ATTR{address}=="11:22:33:44:55:66",
> NAME="wlan17", OWNER="chosen_user", GROUP="chosen_group", MODE="0666"

Network devices do not have a group/owner/mode at all.

> I know it does get triggered, since after replugging the WIFi stick I
> do get "wlan17" interface.But resulting created device in
> /dev/bus/usb/00x/00y gets created with MODE=0640 and root:usb

That is the usbfs device node, not the network device.  If this is a
network device, why do you care about the usbfs connection to the device
and not the normal network device name?

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Thu, Mar 24, 2022 at 02:05:09PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 24, 2022 at 10:28:39AM +, Luca Boccassi wrote:
> > On Thu, 2022-03-24 at 09:38 +0100, Lennart Poettering wrote:
> > > On Mi, 23.03.22 11:28, Luca Boccassi (bl...@debian.org) wrote:
> > >
> > > > At least according to our documentation it wouldn't save us much
> > > > anyway, as the biggest leap is taking cgroupv2 for granted, which
> > > > requires 4.1, so it's included regardless. Unless there's something
> > > > undocumented that would make a big difference, in practical terms of
> > > > maintainability?
> > >
> > > Note that "cgroupv2 exists" and "cgroupv2 works well" are two distinct
> > > things. Initially too few controllers supported cgroupv2 for cgroupv2
> > > to be actually useful.
> > >
> > > What I am trying to say is that it would actually help us a lot if
> > > we'd not just be able to take croupv2 for granted but to take a
> > > reasonably complete cgroupv2 for granted.
> >
> > Yes, that does sound like worth exploring - our README doesn't document
> > it though, do we have a list of required controllers and when they were
> > introduced?
> 
> In the README:
>   Linux kernel >= 4.2 for unified cgroup hierarchy support
>   Linux kernel >= 4.10 for cgroup-bpf egress and ingress hooks
>   Linux kernel >= 4.15 for cgroup-bpf device hook
>   Linux kernel >= 4.17 for cgroup-bpf socket address hooks
> 
> In this light, 4.19 is better than 4.4 or 4.9 ;)

Then move to 4.19.  I strongly doubt that any distro that is using older
kernels would ever be willing to update systemd.

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Wed, Mar 23, 2022 at 10:34:00PM +, Dave Howorth wrote:
> FWIW, I think Greg was a bit too outspoken calling long maintenance
> attempts 'crazy'; that may have intimidated some. I'm thinking of
> moving distro to one that provides longer term maintenance than my
> present one. Although CIP is a completely different ball game; I hope
> they succeed.

It is not "crazy" it is "well documented".  As someone who has been
doing this work for 20+ years now and sees all of the stable kernel
patches flow by, it's obvious that a distro that does not keep up with
them is insecure by design.

To not think otherwise is crazy and negligent.  I'm serious, and have
the numbers and research to back it up.  I would love for someone to be
able to prove me wrong as I wish this wasn't the case.

So please push back on any distro that goes outside of the kernel.org
support window with requests and contract assurances on how they can
ensure that they keep up with all of the needed security fixes over
time.  If you are paying for this, you deserve that information.  If you
are not paying for it, you get what you pay for :(

Sorry this is getting off-topic here for systemd-devel, but it's
something that I have been trying to get across to the Linux community
for a very long time now.

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Wed, Mar 23, 2022 at 10:11:36PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> 
> CIP 4.4 is supposed to be maintained until 2027, which is awfully
> long. The question is: is anyone putting new systemd on those
> systems?  If no, then they're not relevant.

Why not email them and ask?

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Wed, Mar 23, 2022 at 03:58:22PM +, Luca Boccassi wrote:
> On Wed, 2022-03-23 at 12:38 +0100, Greg KH wrote:
> > On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote:
> > > On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote:
> > > > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek 
> > > > > wrote:
> > > > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote:
> > > > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew 
> > > > > > > Jędrzejewski-Szmek wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > we are considering dropping upstream support for kernel 
> > > > > > > > versions < 4.4.
> > > > > > > > Would this be a problem for anyone? (*).
> > > > > > > 
> > > > > > > Given that upstream (i.e. kernel.org) has dropped support for 
> > > > > > > kernel
> > > > > > > 4.4, why not just move to not supporting kernels older than 4.9?
> > > > > > 
> > > > > > It seems Civil Infrastructure Platform (a project under the Linux
> > > > > > Foundation) still uses 4.4 [1].
> > > > > 
> > > > > Yes, but they are not going to be updating to a newer version of
> > > > > systemd, right?
> > > > > 
> > > > > And they are going to be "supporting" that for 20+ years.  If they 
> > > > > want
> > > > > to do something crazy like this, make them handle supporting code that
> > > > > is older than 6+ years to start with.  That's not the community's 
> > > > > issue,
> > > > > that's the companies that demand such crazy requirement's issue.
> > > > 
> > > > That's why I (we) asked the question on the list. If people are compling
> > > > systemd on such old systems, or even older, we want to know about it.
> > > > 
> > > > > > In the Debian world, Stretch which has EOL scheduled for June 2022 
> > > > > > has 4.9,
> > > > > > and after that Buster has 4.19.
> > > > > 
> > > > > 4.9 is fine, and is supported by kernel.org until next year as seen
> > > > > here:
> > > > >   https://kernel.org/category/releases.html
> > > > > 
> > > > > I wrote "4.9" above, not "4.19" :)
> > > > 
> > > > Yep. I'd vote for bumping to 4.9, unless some other voices pop up.
> > > > 
> > > > Zbyszek
> > > 
> > > Let's do 4.4 at most please - what's on kernel.org is not really that
> > > important, as real usage is downstream from there anyway.
> > 
> > And I will publically state that anyone still using 4.4.y today has an
> > insecure and unsupported system.  Please let's not encourage _ANYONE_ to
> > do this.
> > 
> > CIP is "special" in that they know what they are doing, and are using
> > 4.4.y in a very limited set of use cases and configurations.  And even
> > they are going to have big problems keeping that kernel alive and
> > secure.  I would never expect anyone else to be able to do it, and I
> > have doubts that they will either.
> > 
> > So any "real usage" of 4.4 after today, should not matter.  And if
> > someone complains, send them to me please.
> > 
> > thanks,
> > 
> > greg k-h
> 
> You can publically state that all day long, but you know perfectly well
> that's not how the world works.

I am trying to _change_ how the world works, because the way it
currently works for some companies/distros is totally broken and
insecure.

To just ignore it is to give up.

> In the grand scheme of things few
> production scenarios build their kernel from kernel.org, most will be
> getting it from a distro (best case) or a vendor (worst case), and they
> couldn't care less about what kernel.org tells them to do, they use
> what they get.

But if kernel.org tells them that what they are using is insecure, they
should push back on their distro and vendor to have them prove that this
is not true.  So far I have never seen a distro or vendor that uses
older kernels without an insecure kernel.  And I've audited hundreds of
them.

> I fully expect at some point to hear complaints from
> some poor soul stuck on 3.x because of $crappy_arm_vendor with no way
> to move on from there.

Those people are not using new versions of systemd, are they?  And if
they are, they need to get $crappy_arm_vendor to do the work for them as
they PAID for that support and work already.

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Wed, Mar 23, 2022 at 11:28:29AM +, Luca Boccassi wrote:
> On Wed, 2022-03-23 at 11:59 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 23, 2022 at 09:26:05AM +0100, Greg KH wrote:
> > > On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek 
> > > wrote:
> > > > On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote:
> > > > > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek 
> > > > > wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > we are considering dropping upstream support for kernel versions < 
> > > > > > 4.4.
> > > > > > Would this be a problem for anyone? (*).
> > > > > 
> > > > > Given that upstream (i.e. kernel.org) has dropped support for kernel
> > > > > 4.4, why not just move to not supporting kernels older than 4.9?
> > > > 
> > > > It seems Civil Infrastructure Platform (a project under the Linux
> > > > Foundation) still uses 4.4 [1].
> > > 
> > > Yes, but they are not going to be updating to a newer version of
> > > systemd, right?
> > > 
> > > And they are going to be "supporting" that for 20+ years.  If they want
> > > to do something crazy like this, make them handle supporting code that
> > > is older than 6+ years to start with.  That's not the community's issue,
> > > that's the companies that demand such crazy requirement's issue.
> > 
> > That's why I (we) asked the question on the list. If people are compling
> > systemd on such old systems, or even older, we want to know about it.
> > 
> > > > In the Debian world, Stretch which has EOL scheduled for June 2022 has 
> > > > 4.9,
> > > > and after that Buster has 4.19.
> > > 
> > > 4.9 is fine, and is supported by kernel.org until next year as seen
> > > here:
> > >   https://kernel.org/category/releases.html
> > > 
> > > I wrote "4.9" above, not "4.19" :)
> > 
> > Yep. I'd vote for bumping to 4.9, unless some other voices pop up.
> > 
> > Zbyszek
> 
> Let's do 4.4 at most please - what's on kernel.org is not really that
> important, as real usage is downstream from there anyway.

And I will publically state that anyone still using 4.4.y today has an
insecure and unsupported system.  Please let's not encourage _ANYONE_ to
do this.

CIP is "special" in that they know what they are doing, and are using
4.4.y in a very limited set of use cases and configurations.  And even
they are going to have big problems keeping that kernel alive and
secure.  I would never expect anyone else to be able to do it, and I
have doubts that they will either.

So any "real usage" of 4.4 after today, should not matter.  And if
someone complains, send them to me please.

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Wed, Mar 23, 2022 at 09:17:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Mar 23, 2022 at 08:07:48AM +0100, Greg KH wrote:
> > On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > Hi all,
> > > 
> > > we are considering dropping upstream support for kernel versions < 4.4.
> > > Would this be a problem for anyone? (*).
> > 
> > Given that upstream (i.e. kernel.org) has dropped support for kernel
> > 4.4, why not just move to not supporting kernels older than 4.9?
> 
> It seems Civil Infrastructure Platform (a project under the Linux
> Foundation) still uses 4.4 [1].

Yes, but they are not going to be updating to a newer version of
systemd, right?

And they are going to be "supporting" that for 20+ years.  If they want
to do something crazy like this, make them handle supporting code that
is older than 6+ years to start with.  That's not the community's issue,
that's the companies that demand such crazy requirement's issue.

> In the Debian world, Stretch which has EOL scheduled for June 2022 has 4.9,
> and after that Buster has 4.19.

4.9 is fine, and is supported by kernel.org until next year as seen
here:
https://kernel.org/category/releases.html

I wrote "4.9" above, not "4.19" :)

thanks,

greg k-h

Re: [systemd-devel] version bump of minimal kernel version supported by systemd?

[Greg KH]

On Tue, Mar 22, 2022 at 05:27:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> Hi all,
> 
> we are considering dropping upstream support for kernel versions < 4.4.
> Would this be a problem for anyone? (*).

Given that upstream (i.e. kernel.org) has dropped support for kernel
4.4, why not just move to not supporting kernels older than 4.9?

thanks,

greg k-h

Re: [systemd-devel] How to grant systemd-nspawn access to USB device?

[Greg KH]

On Wed, Mar 09, 2022 at 03:04:00PM +0100, Kevin P wrote:
> Good evening everyone.
> I would like a nspawn container on my Raspberry Pi (Raspbian, systemd 247)
> to access a RTL2838 DVB-T USB stick.
> Inside the container, dump1090 will run and feed aircraft data (piaware and
> adsbexchange projects).
> 
> lsusb gives:
> Bus 001 Device 005: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
> 
> file /dev/bus/usb/001/005 returns:
> /dev/bus/usb/001/005: character special (189/4)
> 
> And finally grep 189 /proc/devices shows:
> 189 usb_device
> 
> I edited both the .nspawn file and the .service file, of which I'm
> reporting the relevant parts below.
> /etc/systemd/nspawn/ads-b.nspawn
> [Files]
> Bind=/dev/bus/usb/001/005
> 
> systemd-nspawn@ads-b.service
> [Service]
> DeviceAllow=/dev/bus/usb/001/005 rwm
> DeviceAllow=usb_device rwm
> 
> However I feel like I am doing something wrong, as starting dump1090 from
> within the container returns permission denied.
> I'll gladly take any advice :)

Odds are the program wants to access the device node for the driver, not
the "raw" USB device /dev/bus/usb/*, right?

What does strace show is failing exactly when you run the program?

thanks,

greg k-h

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Sun, Feb 06, 2022 at 01:43:08PM +0530, Nishant Nayan wrote:
> While reading the code I came across :-
> struct Manager
> struct Worker
> Can you please provide an overview on these, I did not get a clear cut
> explanation on these structs, the code only has its member variables.

Those are the "workers" that handle the uevents that are sent by the
kernel.  Put the program in a debugger to see how they work if you have
questions.

> Also what is the variable 'arg_children_max'
> Why is it specifically set to 8 + no_of_cpus*2 ?

Because based on tuning, that's the "best" number that was come up with.
If in your testing you think it should be different, please submit a
patch.

But note that the current number has been tested to work well on both
single CPU machines, as well as machines with thousands of cpus that
bring hundreds of thousands of devices online all at once when booting.

thanks,

greg k-h

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Tue, Feb 01, 2022 at 04:04:01PM +0530, Nishant Nayan wrote:
> One thought
> Is it advisable to turn off systemd-udevd if I am sure that I won't be
> adding /removing any devices to my server.

Why would you want to do that?

> Or udev also does some work while rebooting?

When booting, yes.

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Tue, Feb 01, 2022 at 10:08:04AM +0530, Nishant Nayan wrote:
> Thanks, I will check that out.
> Is there any site where I can gain in depth code level knowledge of
> systemd-udevd?

The code is all there for you to read and understand directly.  What
specific questions did you have that you did not understand after
reading it?

thanks,

greg k-h

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Sun, Jan 30, 2022 at 05:14:49PM +0530, Nishant Nayan wrote:
> I have started reading about udevd.
> I was trying to find out if there is a way to play with udev without
> plugging in/out any devices.
> Is there a way to trigger a uevent without plugging in devices?

Yes, look at the man page for udevadm.  It lets you trigger any uevent
for the devices in your system that you want.

But again, remember for almost everything, udev does not create /dev/
nodes, that is done by the kernel itself.

good luck!

greg k-h

Re: [systemd-devel] Udevd and dev file creation

[Greg KH]

On Sun, Jan 30, 2022 at 09:15:14AM +0530, Nishant Nayan wrote:
> Hi,
>  Does creating a dev file in /dev creates a uevent?

The kernel creates /dev files directly in devtmpfs.  When that happens,
yes the kernel sends a uevent.

If a user creates a /dev file on their own, no, no ueven happens.

> Does a dev file creation considered as a "device attached" to the
> machine?

Not at all, it is totally independent and does not mean that.

What problem are you having with the current kernel and /dev files?

thanks,

greg k-h

Re: [systemd-devel] Additional Information for Ethernet

[Greg KH]

On Thu, Dec 09, 2021 at 03:13:42AM +, Spencer Ku (古世瑜) wrote:
> Hi All,
> We are developing the redfish of openbmc, and want to expose some Ethernet 
> information through the redfish interface, like packet count, drop count. My 
> goal is to calculate the bandwidth / drop package rate of the Ethernet. We 
> can get those counts from Ethernet driver 
> (/sys/class/net/{Ethernet_Name}/statistics), but as far as I know, there is 
> no suitable d-bus to read those metrics.
> 
> 
> 
> My question is that: is it possible to create the new D-bus properties ( like 
> under the /org/freedesktop/{network}/network/{Ethernet_Name}), then sync the 
> counts to that D-Bus?

Why not just use netlink for this?  I think it provides this information
already as part of networking stats.  Have you looked into that?

thanks,

greg k-h

Re: [systemd-devel] hardware conditional OS boot/load

[Greg KH]

On Thu, Nov 18, 2021 at 07:16:55PM +, lejeczek wrote:
> Hi guys.
> 
> I hope an expert(or two) could shed some light - I ain't a kernel nor
> hardware expert so go easy on me please - on whether it is possible to boot
> system only under certain conditions, meaning: as early as possible (grub?)
> and similarly securely, Linux checks for certain hardware, eg. CPU serial
> no. and continue to load only when such conditions are met?
> 
> I realize that perhaps kernel devel be the place for such questions but seen
> I'm subscriber here, knowing people here are experts of same caliber, I
> decided to ask.

Try asking on the kernelnewbies mailing list.

Re: [systemd-devel] [systemd]: sd-sync lead to kernel panic

[Greg KH]

On Wed, Jun 30, 2021 at 02:54:24PM +0800, www wrote:
> Dear all,
> 
> 
> systemd version: v234
> kernel version: 5.1.5

That is a very old and obsolete and insecure and known-buggy kernel
version.  Please work with the vendor who is forcing you to use this
kernel version as you are paying them for support for this.  If you are
not paying for support, please move to the latest kernel release (5.13)
and see if the problem is there as well.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ordering of systemd-tmpfiles-setup.service and systemd-modules-load.service

[Greg KH]

On Wed, Jun 23, 2021 at 12:27:53PM -0500, Ian Pilcher wrote:
> I would like to add a udev rule that creates a symlink to a sysfs
> directory, and a subdirectory of /run seem like the right place to put
> it.  Of course this means that the subdirectory needs to exist.

sysfs should be "self-contained", trying to add symlinks to it from
external places is racy and guaranteed to not work over time.

What problem are you trying to solve here that links into sysfs is an
attempted solution?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

[Greg KH]

On Wed, Jun 02, 2021 at 03:48:41PM +0200, Reindl Harald wrote:
> 
> 
> Am 02.06.21 um 07:04 schrieb Greg KH:
> > On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:
> > > Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH 
> > > :
> > > > Works for me!  Make sure you are not trying to connect to 'https'.
> > > 
> > > No https? Why?
> > 
> > Because why would serving up text files about this topic requires https?
> 
> sorry, but we have 2021
> 
> * non-https is a warning in most browsers
> * certifictes are free and automated these days
> * https is not only about encryption
> 
> the point of https is
> 
> a) you are connected to the host you think
> b) no manipulation on the wire
> 
> the encryption is not really the point

Then don't connect to the site if you don't want the data there.  Trying
to tell others what to do with their spare time in maintaining a
resource for all operating systems to use is a bit, well, you know...

greg "i am a horrible sysadmin" k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

[Greg KH]

On Tue, Jun 01, 2021 at 09:38:37PM +0200, Michael Biebl wrote:
> Am Di., 1. Juni 2021 um 20:44 Uhr schrieb Greg KH 
> :
> > Works for me!  Make sure you are not trying to connect to 'https'.
> 
> No https? Why?

Because why would serving up text files about this topic requires https?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

[Greg KH]

On Tue, Jun 01, 2021 at 08:28:23PM +0200, Daniele Nicolodi wrote:
> On 01/06/2021 16:16, Greg KH wrote:
> > linux-usb.org does not look broken to me, what needs to be fixed on it?
> 
> I get a "503 Service Unavailable" error trying to access
> http://www.linux-usb.org/

Works for me!  Make sure you are not trying to connect to 'https'.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Adding USB ID to hwdb/usb.ids

[Greg KH]

On Tue, Jun 01, 2021 at 03:04:47PM +0200, Lennart Poettering wrote:
> On Do, 13.05.21 11:54, Thomas A (thomas...@gmail.com) wrote:
> 
> > Hi,
> >
> > I'm trying to add the info for Thrustmaster T150 Racing Wheel to the hwdb. I
> > have found that the USB values are stored hwdb.d/20-usb-vendor-model.hwdb.
> > However, it seems that this file is never edited manually, but just pulled
> > from linux-usb.org usb.ids.
> >
> > www.linux-usb.org seems mostly broken and various Google results indicate
> > that there is no response to e-mails. I have, just now, tried to submit a
> > patch by following the guide for the PCI IDs, from which the USB IDs site
> > was copied. I could not register in any way, so I suspect my e-mail will be
> > dropped.
> >
> > Is there any better way to get my ID into the USB ID list in hwdb?
> >
> > Patch on systemd hwdb:
> > https://github.com/thomasa88/systemd/commit/7af622d9d2335f9fc0e94b3b8a5139ef959bef9c
> 
> If this is indeed the case I guess we could start maintaining a
> database for this kind of stuff in hwdb.d/ and ship it with
> systemd. Maybe called 20-usb-vendor-model-extra.hwdb or so?
> 
> Kinda sucks though. Any reference where this is discussed? i.e. the
> google results you mentioned? A quick google i did myself din't reveal
> anything?
> 
> Anyway, please consider submitting the addition as a PR if it's indeed
> unlikely linux-usb.org comes back as a maintainer for this.

usb.ids is still maintained and supported on linux-usb.org, if you need
new device ids, add them here:
http://www.linux-usb.org/usb-ids.html

It gets a constant stream of updates submitted to it all the time, and
the latest version of the file can always be found at:
http://www.linux-usb.org/usb.ids
showing it was last updated on 2021-05-18.

linux-usb.org does not look broken to me, what needs to be fixed on it?

So what specifically is the problem here?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?

[Greg KH]

On Mon, May 17, 2021 at 07:08:55PM +0200, Marc Weber wrote:
> > devtmpfs
> 
> thanks. So I can modprobe (-r) the modules from both host/container,
> 
> eg dahdi_transcode makes /dev/dahdi/transcode appear.
> 
> But when mounting from container I can write / read from it (getting errors
> 
> about channels not setup which is probably expected), but I when trying same 
> from the container I
> 
> just get operation not permitted. chmod 777 or such doesn't help.
> 
> I am not using UID/-U id rewriting in any way. I run the container with 
> --capability=all.
> 
> Is there something else I am missing ?

Sounds like you need to ask about this with whatever framework your
"containers" are being created with.  It's not a systemd issue here, and
as the kernel is working properly, doesn't seem to be a kernel issue
either.

Your "containers" are probably set to not allow access to these device
nodes, and rightly so, as that's not normally a good thing to allow.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?

[Greg KH]

On Mon, May 17, 2021 at 10:20:50AM +0200, Marc Weber wrote:
> Man says:
> 
> "
> 
> The host system cannot be rebooted and kernel modules may not be
>loaded from within the container.
> "
> 
> https://lists.freedesktop.org/archives/systemd-devel/2015-February/027805.html
> said:
> 
> "
> We nowadays explicitly disallow non-auto loading of kernel modules
> from containers, for security reasons. If you want to allow kernel
> modules, then you can do so by adding the CAP_SYS_MODULE capability
> set to the set of caps to retain in nspawn, by using its --capability=
> switch.
> "
> 
> insmod .ko module works, the problem is that /dev/dahdi appears on host, not 
> within the container.

That is up to your container, if it wants to mount devtmpfs within it or
not.

> Is there something simple I missed or do I need to switch to vkvm or such to 
> run maybe 8y old opensuse
> on current kernel ?

What does vkvm or obsolete opensuse releases have to do with any of
this?

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Greg KH]

On Mon, Feb 22, 2021 at 06:22:44AM -0500, Robert P. J. Day wrote:
> On Thu, 18 Feb 2021, Lennart Poettering wrote:
> 
> > On Do, 18.02.21 11:48, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > >   A colleague has reported the following apparent issue in a fairly
> > > old (v230) version of systemd -- this is in a Yocto Project Wind River
> > > Linux 9 build, hence the age of the package.
> > >
> > >   As reported to me (and I'm gathering more info), the system was
> > > being put through some "longevity testing" by repeatedly adding,
> > > removing, activating and de-activating network interfaces. According
> > > to the report, the result was heap space slowly but inexorably being
> > > consumed.
> > >
> > >   While waiting for more info, I'm going to examine the commit log for
> > > systemd from v230 moving forward to collect any commits that address
> > > memory leaks, then peruse them more carefully to see if they might
> > > resolve the problem.
> > >
> > >   I realize it's asking a bit for folks here to remember that far
> > > back, but does this issue sound at all familiar? Any pointers that
> > > might save me some time? Thanks.
> >
> > Note that our hash tables operate with an allocation cache: when
> > adding entries to them and then removing them again the memory
> > required for that is not returned to the OS but added to a local
> > cache. When the next entry is then added again, we recycle the
> > cached entry instead of asking for new memory again. This allocation
> > cache is a bit quicker then going to malloc() all the time, but
> > means if you just watch the heap you'll assume there's a leak even
> > though there isn't really, the memory is not lost after all, and
> > will be reused eventually if we need it.
> >
> > You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off,
> > but not sure v230 already knew that env var.
> 
>   well, we seem to have isolated the issue, here it is in a nutshell
> based on a condensed note i got from someone who tracked it down this
> weekend. the memory leak is triggered by:
> 
>   $ ssh root@ -p 830 -s netconf   [830 = netconf over SSH]
> 
> long story short, according to jemalloc profiling, there is a massive
> memory leak in DBUS code, to the tune of about 500M/day on a running
> system. i'm perusing the profiling output now, but does any of this
> sound even remotely familiar to anyone? i realize that's just a
> summary, but does anyone remember seeing something related to this
> once upon a time? [heavily-patched systemd_230 from wind river linux
> 9].

Given that this is a heavily patched system, please get support from the
vendor that provided this as you are paying for this.  Don't ask the
community to try to remember what happened with an old obsolete version
of software, that's crazy...

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Greg KH]

On Fri, Feb 19, 2021 at 06:09:16PM +0200, Mantas Mikulėnas wrote:
> On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering 
> wrote:
> 
> > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > > i guess i expected that the CVE identifier would be in the commit
> > > message. anyway, time to examine ...
> >
> > CVEs are assigned/published long after the commits to fix the issues
> > are made. We cannot retroactively change git commits, that's just not
> > how this works.
> >
> 
> This *could* work with git notes, it seems --grep searches them as well.

Git notes do not work for anything but a local repo, sorry.

if people really care about CVEs, they know how to use them.  But
really, they are mostly useless:

https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and btrfs multiple devices

[Greg KH]

On Thu, Jan 28, 2021 at 01:32:03AM -0700, Chris Murphy wrote:
> On Thu, Jan 28, 2021 at 1:03 AM Greg KH  wrote:
> >
> > On Wed, Jan 27, 2021 at 05:19:38PM -0700, Chris Murphy wrote:
> > >
> > > Next, is it possible to enhance udev so that it can report the number
> > > of devices expected for a Btrfs file system? This information is
> > > currently in the Btrfs superblock found on each device in the
> > > num_devices field.
> > > https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627
> >
> > It's not up to udev to report that, but rather have either the kernel
> > export that, or have the tool that udev calls determine that.
> 
> I mean expose in udevadm info, e.g.
> 
> E: ID_BTRFS_NUM_DEVICES=4

Again, that is up to either the kernel, or a tool that udev calls to do
that, udev itself doesn't know device-specific things, that's not what
it is designed to do.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev and btrfs multiple devices

[Greg KH]

On Wed, Jan 27, 2021 at 05:19:38PM -0700, Chris Murphy wrote:
> 
> Next, is it possible to enhance udev so that it can report the number
> of devices expected for a Btrfs file system? This information is
> currently in the Btrfs superblock found on each device in the
> num_devices field.
> https://github.com/storaged-project/udisks/pull/838#issuecomment-768372627

It's not up to udev to report that, but rather have either the kernel
export that, or have the tool that udev calls determine that.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why systemd-nspawn is slower than docker, podman and qemu?! how to Improve nspawn performance?

[Greg KH]

On Mon, Jan 25, 2021 at 11:56:09AM +0100, Badr Elmers wrote:
> Hi,
> Why nspawn is slow compared to docker podman and even qemu?!
> CPU tasks take twice of the time it takes in docker, podman or qemu
> 
> here I filled a request to improve nspawn performance which contain the
> steps and the full test result:
> https://github.com/systemd/systemd/issues/18370
> 
> Do you know why systemd-nspawn is slower? how can I improve it?

As I pointed out in the above "issue", the benchmark isn't measuring
what anyone thinks it is measuring and should not be treated as a
reliable indication of anything.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev rules for interfaces

[Greg KH]

On Fri, Dec 25, 2020 at 11:01:47AM +0200, Adi Ml wrote:
> Hi,
> 
> I am trying to generate rules in udev to block mass storage. It seems like
> it only checks the device itself (its class is 00), but not its interface
> classes (one of those is 08, a mass storage). It seems like there is only
> attr{bDeviceClass} but there is attr{bInterfaceClass} only when I specify
> the interface number.
> 
> 
> How is it possible to set the rules against its interfaces too?

Yes, interfaces are "devices" according to the kernel, that is what
drivers are bound to.

But, again, please just use USBGuard, it handles all of this for you
automatically.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

On Mon, Dec 14, 2020 at 06:18:24PM +0200, Adi Ml wrote:
> I guess that udev can block devices from userspace only, so from there.
> 
> Of course, you are right-whitelist is better.
> 
> As for usbguard, I thought about using seccomp and filterring system calls
> in my udev service based on their code - I have seen that they list a group
> of system calls and restrict the usage to them only.

That restriction is for the usbguard daemon, has nothing to do with what
a USB device can or can not do.

I recommend using that program for what you want to accomplish, as that
is exactly what it is designed to do.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

On Mon, Dec 14, 2020 at 05:31:17PM +0200, Adi Ml wrote:
> I am using udev in order to create a kiosk mode. I want to block devices
> which fit a certain vid pid.

Block devices from where?  The kernel or userspace?

udev runs _after_ the kernel has seen the device and bound to it.

And usb vid/pids can be made to be whatever they want to be, be careful
about triggering off of them to prevent specific things from happening,
that way is tough.  It's easier to whitelist valid devices that you know
are correct, and then only allow specific actions to happen on them.

You might want to look into using https://usbguard.github.io/ for how to
do this "properly".

> I want to filter system calls anyway because I
> dont know which devices are entered and I want to avoid devices which will
> do unusual things like rubber ducky.

devices do not make system calls directly, and if you plug a rubber
ducky in that acts like a keyboard, that is not going to create things
in udev's process context.

> What do you mean by filtering system calls in   scripts- is it needed when
> the user can influence actions commited in the script ?

Look at the programs / scripts that udev calls out to in the udev
configuration files for examples of these.  A user does not directly
influence them, except if they are allowed to create/remove hardware.

Hope this helps,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

On Mon, Dec 14, 2020 at 04:30:58PM +0200, Adi Ml wrote:
> Hi,
> Is there some way to detect which system calls, I am using in udev (in
> order to filter it)?

I don't understand, if you don't know what system calls you are needing,
why do you need to filter anything?  Do you not trust udev to work
properly?

> I do not use any script, I just echo 0 to the authorized file in the device
> connected in order to disable it when it is not the wanted device (the
> match is based on serial number, vid, pid)

Udev calls loads of helper tools in order to generate persistent names.
If you don't have any udev rules that call anything, then what do you
need udev for?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Udev hardening

[Greg KH]

On Mon, Dec 14, 2020 at 02:54:31PM +0200, Adi Ml wrote:
> Hi,
> 
> I would like to harden my udev service with the
> SystemCallFilter option. What systemcalls should be permitted/allowed in
> order to secure it and avoid irrelevant system calls?

It all depends on what type of scripts/programs you want udev to be able
to call.  That's up to your and your specific hardware configuration.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Creating executable device nodes in /dev?

[Greg KH]

On Fri, Dec 11, 2020 at 12:46:35PM +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 10:35:21AM +0200, Topi Miettinen wrote:
> > On 9.12.2020 2.15, Jarkko Sakkinen wrote:
> > > On Wed, Dec 09, 2020 at 01:15:27AM +0200, Topi Miettinen wrote:
> > > > > > > As  a further argument, I just did this on a Fedora system:
> > > > > > > $ find /dev -perm /ugo+x -a \! -type d -a \! -type l
> > > > > > > No results.  So making /dev noexec doesn't seem to have any 
> > > > > > > benefit.
> > > > > > 
> > > > > > It's no surprise that there aren't any executables in /dev since
> > > > > > removing MAKEDEV ages ago. That's not the issue, which is that
> > > > > > /dev is a writable directory (for UID=0 but no capabilities are
> > > > > > needed) and thus a potential location for constructing unapproved
> > > > > > executables if it is also mounted exec (W^X).
> > > > > 
> > > > > UID 0 can just change mount options, though, unless SELinux or 
> > > > > similar is used. And SELinux can protect /dev just fine without 
> > > > > noexec.
> > > > 
> > > > Well, mounting would need CAP_SYS_ADMIN in addition to UID 0. Also 
> > > > SELinux
> > > > is not universal and the policies might not contain all users or 
> > > > services.
> > > > 
> > > > -Topi
> > > 
> > > What's the data that supports having noexec /dev anyway? With root
> > > access I can then just use something else like /dev/shm mount.
> > > 
> > > Has there been out in the wild real world cases that noexec mount
> > > of would have prevented?
> > > 
> > > For me this sounds a lot just something that "feels more secure"
> > > without any measurable benefit. Can you prove me wrong?
> > 
> > I don't think security works that way. An attacker has various methods to
> > choose from, some are more interesting than others. The case where rw,exec
> > /dev would be interesting would imply that easier or more common avenues
> > would be blocked, for example rw,exec /dev/shm, /tmp, /var/tmp, or
> > /run/user/$UID/ for user. Also fileless malware with pure ROP/JOP approach
> > with no need for any file system access is getting more common. It does not
> > mean that it would not be prudent to block the relatively easy approaches
> > too, including /dev.
> 
> What if we add a new mount option "chrexec", which allows exec
> for character devices (S_IFCHR).

Oh please no.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Memory in systemctl status

[Greg KH]

On Mon, Sep 28, 2020 at 02:22:17PM +0200, Reindl Harald wrote:
> honestly: do you realize that i know very well how the memory management
> of Linux works and that it's pretty fine but not part of the topic at all?

*plonk*
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Memory in systemctl status

[Greg KH]

On Mon, Sep 28, 2020 at 11:37:20AM +0200, Reindl Harald wrote:
> 
> 
> Am 28.09.20 um 11:19 schrieb Benjamin Berg:
> >> if i would set "MemoryMax" to 4G "Memory: 8.6G" would kill it when the
> >> caches are accounted in that context
> > 
> > No, the kernel kicks in and reclaims memory at that point. Which can
> > mean either swapping or just dropping caches.
> 
> caches have *nothing* to do with the service itself

How do you know this?  And why wouldn't they be "charged" to the task
that caused the cache to fill up?  What "should" they do?

If you don't like the current way that Linux manages memory resources
like this, please discuss it with the kernel developers, there's not
much that systemd can do about it, right?

> > It really sounds to me like ulimit fits better what you are trying to
> > do. That is available through Limit*=, see systemd.exec.
> 
> hell first i want a output in "systemctl status whatever" which is true
> and don't contain a ISO image downloaded by someone two days ago
> 
> not more and not less
> 
> httpd don't use 8.7 GB RAM - period

Why shouldn't httpd use all the ram it was allowed to, if possible?
What's wrong with that happening if the kernel is still caching those
resources?

If you want to tell httpd to "flush the data from the kernel" after it
is done downloading that ISO image, please modify httpd to do so,
otherwise how is the kernel to know that it isn't to be asked for again
within the next minute or so?

memory management is hard :)

> the only interesting memory is RES of all the processes

Interesting to whom?

> my Firefox on the desktop don't use 32 GB RAM even when VIRT shows that
> and even if the latest download of a 10 GB file is somewhere in the OS
> caches in case it's opened later - it's *free* memory

How do you know that Firefox does not tell the kernel to release that
memory after the download finishes?

Best of luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Memory in systemctl status

[Greg KH]

On Sun, Sep 27, 2020 at 01:41:33PM +0200, Reindl Harald wrote:
> Memory: 8.6G
> 
> looks like there is a large part of os-caching included where i wonmder
> how that's done because a file can be read by muliple processes /
> services and is hopfefully only once cached
> 
> however, that value makes little to no sense and if that's the same
> value as accounted for "MemoryMax" it's plain wrong
> 
> [root@arrakis:~]$ free
>   totalusedfree  shared  buff/cache
> available
> Mem:   15Gi   2.2Gi   585Mi   309Mi12Gi
>12Gi
> Swap:0B  0B  0B

The kernel does this, it's nothing to do with systemd or anything else.

You can get "back" that memory for a short while if you really want it
by doing:
echo 3 > /proc/sys/vm/drop_caches

For more details, see https://www.linuxatemyram.com/

good luck!

greg k-h-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] device enumeration by systemd user instances

[Greg KH]

On Thu, Jul 25, 2019 at 05:29:33PM +0200, Pawel Szewczyk wrote:
> On 7/17/19 23:14, Greg KH wrote:
> > 
> > 100ms seems like a really long time, what exactly is it doing during
> > that time?  Is the kernel spending too much time regenerating the
> > uevents?
> > 
> > How many devices are you talking about?  Any chance to see what really
> > is happening here by running perf to see where the hot-spots are?
> 
> There are ~80 devices being enumerated and 1ms per device still seem a 
> little too long. Note, that we are running this on arm architecture.
> 
> Maybe using perf or other tools to find out what exactly is taking this 
> time is a good idea (never used perf to be honest). For now just by 
> adding some verbose logs it seems that processing of each device 
> actually takes around 1ms.

Run perf and see what is going on, that seems like way too long per
device.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] device enumeration by systemd user instances

[Greg KH]

On Wed, Jul 17, 2019 at 05:46:58PM +0200, Pawel Szewczyk wrote:
> Dear all
> 
> I was recently working on reducing booting time and I see one issue that 
> I think is worth discussing.
> 
> The problem is the device units enumeration seems to take a long time 
> (>100ms in our case) before any units are beginning to start.

100ms seems like a really long time, what exactly is it doing during
that time?  Is the kernel spending too much time regenerating the
uevents?

How many devices are you talking about?  Any chance to see what really
is happening here by running perf to see where the hot-spots are?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev_device_get_driver implementation

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Wed, Apr 24, 2019 at 11:58:08AM -0700, Sayeed hyder wrote:
>  ll
> /sys/devices/LNXSYSTM:00/device:00/ACPI0012:00/ndbus0/region1/pfn1.1/block/pmem1/
> total 0
> -r--r--r-- 1 root root 4096 Apr 19 09:38 alignment_offset
> -rw-r--r-- 1 root root 4096 Apr 19 09:38 badblocks
> lrwxrwxrwx 1 root root0 Apr 19 09:38 bdi ->
> ../../../../../../../../virtual/bdi/259:3
> -r--r--r-- 1 root root 4096 Apr 19 09:38 capability
> drwxr-xr-x 2 root root0 Apr 19 09:38 dax
> -r--r--r-- 1 root root 4096 Apr 19 09:38 dev
> lrwxrwxrwx 1 root root0 Apr 19 09:38 device -> ../../../pfn1.1
> -r--r--r-- 1 root root 4096 Apr 19 09:38 discard_alignment
> -r--r--r-- 1 root root 4096 Apr 19 09:38 ext_range
> drwxr-xr-x 2 root root0 Apr 19 09:38 holders
> -r--r--r-- 1 root root 4096 Apr 19 09:38 inflight
> drwxr-xr-x 2 root root0 Apr 19 09:38 power
> drwxr-xr-x 2 root root0 Apr 19 09:38 queue
> -r--r--r-- 1 root root 4096 Apr 19 09:38 range
> -r--r--r-- 1 root root 4096 Apr 19 09:38 removable
> -r--r--r-- 1 root root 4096 Apr 19 09:38 ro
> -r--r--r-- 1 root root 4096 Apr 19 09:38 size
> drwxr-xr-x 2 root root0 Apr 19 09:38 slaves
> -r--r--r-- 1 root root 4096 Apr 19 09:38 stat
> lrwxrwxrwx 1 root root0 Apr 19 09:38 subsystem ->
> ../../../../../../../../../class/block
> drwxr-xr-x 2 root root0 Apr 19 09:38 trace
> -rw-r--r-- 1 root root 4096 Apr 19 09:38 uevent

As suspected, that is a class device (it is a block device), and a class
device does not have a direct "driver" bound to it.  If you want to find
the "real" driver for the device, go to 'device' and find it, right?

Ah, but this might be a mess, with a child device.  DAX stuff is odd, I
would recommend going and asking those kernel developers what they were
thinking when they added a sub-device here :(

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev_device_get_driver implementation

[Greg KH]

On Wed, Apr 24, 2019 at 10:10:08AM -0700, Sayeed hyder wrote:
> Forgot to hit "reply all"
> 
> On Wed, Apr 24, 2019 at 9:52 AM Sayeed hyder  wrote:
> 
> > Hi Greg,
> >
> > Sure, this is what I get if I use the syspath from
> > udev_device_get_syspath. As you can see, it is showing a symlink to a
> > device, and there is no driver. If it helps, it is a DAX mounted persistent
> > memory device.
> >
> > [image: image.png]

Sorry, can't see images from a text email client :(

Anyway, if this is a DAX device, are you _SURE_ you are dealing with a
real device that is controlled by a driver, and not just a class device?
Class devices do not have drivers.  How is the DAX device being exposed
to userspace?

Can you provide a text version of your image?  It's just sysfs, which is
text...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev_device_get_driver implementation

[Greg KH]

On Wed, Apr 24, 2019 at 08:38:02AM -0700, Sayeed hyder wrote:
> Hi,
> 
> I was looking at the udev_device_get_driver implementation. It first gets
> the sys path and then appends "driver", and calls readlink to get the
> driver information. Does it work for all cases? While working on a project,
> I found that following the sys path, there is no "driver", but it should be
> "device/driver" i.e. if I append "device/driver" instead of "driver" only,
> I can use readlink to get the driver information.

What in-kernel driver causes an odd sysfs tree like this?  Can you show
me the full path of it?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fail to load network modules properly

[Greg KH]

On Sun, Jan 27, 2019 at 09:14:37PM +0100, Łukasz Słaboń wrote:
> Hello everyone,
> 
> Since starting using linux last year (xubuntu 18.04) I am experiencing
> occasional problems with wifi interface (broadcom BCM43224 rev 01
> 14e4:4353). From time to time (every 3 - 4 starts) my wifi card is not
> recognized and I do not see wifi interface after boot. After comparing
> dmesg listings from successful and failed boots I have discovered one
> difference. My main partition is mounted twice and in successful boot it is
> done before  before cfg80211 module. In failed boot second mount is done
> after cfg80211 module. Can this be a cause of network interface problems?
> If yes is there any possibility to solve this within systemd? Just to
> clarify such situations happen with proprietary and open-source drivers as
> well.
> 
> Here is the fragment of dmesg listing after successful boot:
> [4.452703] [drm] Initialized radeon 2.50.0 20080528 for :02:00.0 on
> minor 0
> [4.601495] EXT4-fs (sda5): mounted filesystem with ordered data mode.
> Opts: (null)
> [4.669690] clocksource: Switched to clocksource tsc
> [5.068753] input: SynPS/2 Synaptics TouchPad as
> /devices/platform/i8042/serio1/input/input5
> [5.774502] random: crng init done
> [5.774503] random: 7 urandom warning(s) missed due to ratelimiting
> [6.151902] ip_tables: (C) 2000-2006 Netfilter Core Team
> [9.336683] lp: driver loaded but no devices found
> [9.366325] ppdev: user-space parallel port driver
> [9.405084] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
> [   12.325130] Adding 2097148k swap on /swapfile.  Priority:-2 extents:6
> across:2260988k FS
> [   20.381638] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [   20.385106] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [   20.863926] wl: loading out-of-tree module taints kernel.
> [   20.863932] wl: module license 'MIXED/Proprietary' taints kernel.
> [   20.863932] Disabling lock debugging due to kernel taint
> [   20.866504] wl: module verification failed: signature and/or required
> key missing - tainting kernel
> [   20.941673] wlan0: Broadcom BCM4353 802.11 Hybrid Wireless Controller
> 6.30.223.271 (r587334)
> 
> Here is the fragment of dmesg listing after failed boot:
> [5.194759] EXT4-fs (sda5): mounted filesystem with ordered data mode.
> Opts: (null)
> [6.249451] random: crng init done
> [6.249454] random: 7 urandom warning(s) missed due to ratelimiting
> [6.728424] ip_tables: (C) 2000-2006 Netfilter Core Team
> [9.888353] lp: driver loaded but no devices found
> [9.913126] ppdev: user-space parallel port driver
> [   10.152833] cfg80211: Loading compiled-in X.509 certificates for
> regulatory database
> [   10.156199] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
> [   10.174030] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
> [   21.275568] Adding 2097148k swap on /swapfile.  Priority:-2 extents:6
> across:2260988k FS
> [   21.472260] wl: loading out-of-tree module taints kernel.
> [   21.472264] wl: module license 'MIXED/Proprietary' taints kernel.
> [   21.472265] Disabling lock debugging due to kernel taint
> [   21.474938] wl: module verification failed: signature and/or required
> key missing - tainting kernel
> [   21.477657] wl :08:00.0: enabling device ( -> 0002)
> [   21.477881] wl driver 6.30.223.271 (r587334) failed with code 1
> [   21.477882] ERROR @wl_cfg80211_detach :
> [   21.477883] NULL ndev->ieee80211ptr, unable to deref wl

Looks like a bug in the closed-source wl kernel driver.  Please contact
the authors of that code and ask them for help as there's really nothing
we can do about this.

sorry,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev

[Greg KH]

On Wed, Nov 01, 2017 at 10:04:19AM -0400, David Henderson wrote:
> Good morning Lennart, thanks for the follow-up!  At this point I am
> only interested in building a particular program (udev) from the
> systemD collection, not help building a distribution.  And I think if
> I tried to contact LFS about this, they would direct me to this
> communication channel since this is where the people who build and
> support the programs are located.  As a side question, is there a
> place to just acquire the udev portion without all the other parts or
> did that get merged into this suite only?

Again, I would look at how Gentoo does it in their build scripts.
That's your best bet, and if that doesn't work, you really are on your
own as the source code is not set up to only extract one program from
the whole system, for obvious reasons.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] About stable network interface names

[Greg KH]

On Sat, Jun 10, 2017 at 09:08:17AM +0300, Andrei Borzenkov wrote:
> 09.06.2017 23:42, Martin Wilck пишет:
> > On Tue, 2017-06-06 at 21:40 +0300, Andrei Borzenkov wrote:
> >>
> >> Can device and function really change? My understanding is that
> >> device
> >> part is determined by bus physical wiring and function by PCI card
> >> design; this leaves bus as volatile run-time enumeration value.
> > 
> > For PCIe, that's only true for the "function" part.
> > https://superuser.com/questions/1060808/how-is-the-device-determined-in
> > -pci-enumeration-bus-device-function
> > 
> 
> I do not see anything there that would imply device designation is
> random. You have PCIe switch port instead of IDSEL wiring but port is
> most likely hardwired and does not change. Actually this article says
> the same
> 
> --><--
> Since each device has its own independent set of wires, the device IDs
> are essentially all hard-coded
> --><--

"essentially" does not mean "will never change".  Some BIOSes will
renumber them, some will not, as it's not a PCI requirement it can, and
will, happen.

Yes, for lots of people this will be fine and nothing will ever change,
but you can not guarantee it will never happen for all types of
machines, sorry.

That's just the nature of dynamic busses :)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd license vs. libcryptsetup license

[Greg KH]

On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote:
> Thanks, for explanation.
>  
> > - a collection of rpms, like a linux distro, including systemd.rpm,
> >   libcryptsetup.rpm, and thousands of other loosely coupled rpms
> >   → that's a mere aggregation, each of the thousands of components carries
> >   it's own license, each has to be satisfied separately
> 
> It is mere aggregation as long as binary from systemd.rpm does not
> link to a library from libcryptsetup.rpm. If it does then it's a
> combination or a derivative work in terms of GPL and as such the
> systemd.rpm should include a GPL license (and of course comply with
> other GPL terms and conditions). Is that correct?

You need to consult a lawyer to get a definitive answer for this, please
don't ask developers for legal advice :)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] About stable network interface names

[Greg KH]

On Mon, May 29, 2017 at 11:34:13AM +0200, Cesare Leonardi wrote:
> On 29/05/2017 07:10, Greg KH wrote:
> > Anyway, PCI can, and will sometimes, renumber it's devices on booting
> > again, that's a known issue.  It is rare, but as you have found out,
> > will happen.  So anything depending on PCI numbers will change.  Nothing
> > we can really do about that.
> 
> Do you mean that it could rarely happen on boot also without doing any
> change to the hardware?

Yes it can, I used to have a machine that renumbered the PCI buses every
5th boot or something, was fun for testing PCI changes on :)

> So, to avoid surprises, in case of multiple NICs it's highly recommendable
> anyway to hook interface naming to MAC address, isn't it?

Yes, or something else that you know will be stable in the system.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] About stable network interface names

[Greg KH]

On Mon, May 29, 2017 at 02:35:12AM +0200, Cesare Leonardi wrote:
> I ask because I've done several tests, with different motherboards, adding
> and removing PCI-express cards and that expectation was not satisfied in
> many cases.
> 
> For example, in one of those tests I initially had this setup:
> Integrated NIC: enp9s0
> PCIE1 (x1): dual port ethernet card [enp3s0, enp4s0]
> PCIE2 (x16): empty
> PCIE3 (x1): dual port ethernet card [enp7s0, enp8s0]
> 
> Then i inserted a SATA controller in the PCIE2 slot and three NICs got
> renamed:
> Integrated NIC: enp10s0
> PCIE1 (x1): dual port ethernet card [enp3s0, enp4s0]
> PCIE2 (x16): empty
> PCIE3 (x1): dual port ethernet card [enp8s0, enp9s0]

Do you mean to show that PCIE2 is still empty here?

Anyway, PCI can, and will sometimes, renumber it's devices on booting
again, that's a known issue.  It is rare, but as you have found out,
will happen.  So anything depending on PCI numbers will change.  Nothing
we can really do about that.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Wed, Jan 25, 2017 at 02:38:06PM +0100, Lars Knudsen wrote:
> 1. someone plugs in hardware with an unknown VID/PID but CDC capabilities
> 2. modemmanager does it's magic probing and finds "this is not a modem"
> 3. the VID/PID(& more if needed) + findings is sent to a cloud db ...

Do you want a list of all devices you have plugged into your machine to
be sent to some random "cloud db"?

If so, great, please work on that and try to get the various distros to
pick it up :)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 01:18:12PM +0100, Lars Knudsen wrote:
> > The full device should be fine if it has a WebUSB interface (even in a
> > composite scenario)
> 
> Really?  You want to allow someone "raw" access to a composite device
> just because of one specific interface?
> 
>  
> Ideally, I would only allow the browsers running in user space and only the
> WebUSB interface.
> - but would that even be possible on Linux? (now/future).

I don't know how the browser ends up talking to the USB device in the
first place.  Does it use libusb?  usbfs directly?  Something else?
It all depends on how it is accessing the device for what is needed to
properly set the permissions on it.

> We should remember that devices with a WebUSB interface included were *made*
> for user access (what else would be the point?).

I agree, but you never know what type of crazy composite device people
will create with this interface type.

> Also: We *do* need a 'blanket' solution for these as manufactures can't always
> wait for the next time all planets align
> and e.g. Ubuntu chooses to upgrade the rules.  Just fyi, last time I was in
> similar discussions in the smae lists, it took
> some years for it to land in Ubuntu:  https://medium.com/@larsgk/
> web-enabling-legacy-devices-dc3ecb9400ed#.7l1hztlmi

Nothing I can do about crazy/stupid distros that never want to update
anything, all we can do is provide the solution and hope they wake up
and take it.  Or users will end up moving to a distro that does provide
the correct continuous update model (i.e. Fedora, openSUSE, Arch, etc.)

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 12:55:20PM +0100, Lars Knudsen wrote:
> On Fri, Jan 20, 2017 at 12:05 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> >  - so if we can make a rule that consistently detects USB devices with a
> WebUSB
> > interface defined, we should get this in as a standard rule.
> 
> Sure, feel free to write the helper binary that will do this.
> 
> Cool, I am still wondering if we could do it with a script.  Do you have an
> example of a binary for udev?
> (I am assuming it's a source for a plugin to be shipped with and callable by
> udev?)

Yes, you could do it with a script, just look at the interface
information in sysfs, it all should be exported there properly.  If not,
please let me know.

> > Is it possible to give access on an interface level - or would it always
> have
> > to be the full device?
> 
> How would you provide userspace access to only one USB interface on
> Linux?
> 
> The full device should be fine if it has a WebUSB interface (even in a
> composite scenario)

Really?  You want to allow someone "raw" access to a composite device
just because of one specific interface?

Yeah, it's a pain, and a side affect of the libusb api :(

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Fri, Jan 20, 2017 at 11:43:24AM +0100, Lars Knudsen wrote:
> 
> 
> On Mon, Jan 16, 2017 at 3:23 PM, Simon McVittie 
>  > wrote:
> 
> On Mon, 09 Jan 2017 at 10:20:33 +0100, Lars Knudsen wrote:
> > 2. make sure that webusb devices will be somehow accessible to be used 
> by
> a
> > browser running with user permissions (current temp solution listed 
> here:
> > adding user to plugdev, adding 0664 permissions to device: https://
> > developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web 
> )
>  
> > (udev/systemd task).
> 
> Since I didn't see a response to this: this sounds like a job for uaccess.
> Most things that happened via the plugdev group (on Debian/derivatives)
> 5 or 10 years ago should happen via uaccess now.
> 
> TAG+="uaccess" in a udev rule results in an ACL being set so that
> a currently-active logind session on the same seat can read and write
> the device node.
> 
> 
> OK thanks!
> 
>  - so if we can make a rule that consistently detects USB devices with a 
> WebUSB
> interface defined, we should get this in as a standard rule.

Sure, feel free to write the helper binary that will do this.

> Is it possible to give access on an interface level - or would it always have
> to be the full device?

How would you provide userspace access to only one USB interface on
Linux?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 06:23:13PM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 18:19, "Greg KH" <g...@kroah.com> wrote:
> 
> On Tue, Jan 10, 2017 at 06:04:46PM +0100, Lars Knudsen wrote:
> > I figured that made most sense :)
> >
> > Still, it would be good if we could have a rule to not grab the CDC
> interface
> > part if the device includes WebUSB functionality.
> 
> What exactly do you mean by "grab"?
> 
> MM probing :)

Probe should be fine, right?  Are you really thinking that MM needs to
go "oh look, a cdc device, let's go look at all of the raw interfaces to
ensure it really isn't a webusb device as well before I touch it!"

That way lies madness...

What's wrong with touching it?  The kernel already did, why would
userspace care?

> > The likelihood of a modem+WebUSB combo is so small that it must fall
> > in the category where potential rare exotic devices combining it must
> > be whitelisted and the rest be left alone.
> 
> I think you misunderstand just how crazy firmware authors can be.  I'm
> sure we will see those types of devices in the wild.
> 
> ...But realistically how many? Bothering 99.9% to support the special case
> seems less logical than just finding the 0.1% and whitelisting it (if needed)

That's the joy of writing an operating system for all devices on the
planet, those 0.1% can be a lot of devices :)

Anyway, I don't think there's much to do here just yet, let's wait and
see just how bad these webusb devices end up looking like...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Tue, Jan 10, 2017 at 08:39:28AM +0100, Lars Knudsen wrote:
> 
> 
> On Jan 10, 2017 07:51, "Greg KH" <g...@kroah.com> wrote:
> 
> On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
>     > On 2017-01-09 9:55 am, Greg KH wrote:
> > > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > > Greg KH <g...@kroah.com> writes:
> > > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde
> Christiansen wrote:
> > > > >> Web USB can only grab devices which has special Web USB headers.
> It can not
> > > > >> grab any USB device.
> > > > >>
> > > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > > >
> > > > > Ah, fun :(
> > > > >
> > > > > So, we can add a quirk into the kernel cdc-acm driver to never 
> bind
> to a
> > > > > device that has the wusb platform capability descriptor,
> > > >
> > > > I fail to see why a quirk should be necessary. New device classes 
> are
> > > > expected to use new class/subclass codes distintly different from
> > > > anything handled by existing class drivers.
> > >
> > > One would hope, but it seems like they want to piggy-back on the
> cdc-acm
> > > spec.  But I could be totally wrong here, does anyone have the actual
> > > descriptor dump of a device anywhere?
> >
> > We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> > always have its interfaces marked vendor-specific. Below is an example 
> of
> a
> > device which implements both a CDC-ACM interface and a WebUSB interface.
> 
> Ick, why would you want both interfaces on a device?  Are you going to
> allow firmware to talk to both endpoints at the same time?  Why?
> 
> Why not just make it a "one interface" type of device?
> 
> I work for a medical company, where we are using long lived software and
> hardware. Having the option of supporting both WebUSB and USB serial will 
> allow
> us to move to pure web and still support legacy platforms.
> 
> If we - in stead - were to only have WebUSB or standard CDC, we would force an
> impossible break.

Ok, yes, different interfaces will work, and as long as the kernel isn't
going to bind to the interface, you should be fine.  Hopefully your
firmware can handle userspace talking to both interfaces at the same
time :)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:32:40PM -0800, Reilly Grant wrote:
> On 2017-01-09 9:55 am, Greg KH wrote:
> > On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> > > Greg KH <g...@kroah.com> writes:
> > > > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen 
> > > > wrote:
> > > >> Web USB can only grab devices which has special Web USB headers. It 
> > > >> can not
> > > >> grab any USB device.
> > > >>
> > > >> https://wicg.github.io/webusb/#webusb-descriptors
> > > >
> > > > Ah, fun :(
> > > >
> > > > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > > > device that has the wusb platform capability descriptor,
> > > 
> > > I fail to see why a quirk should be necessary. New device classes are
> > > expected to use new class/subclass codes distintly different from
> > > anything handled by existing class drivers.
> > 
> > One would hope, but it seems like they want to piggy-back on the cdc-acm
> > spec.  But I could be totally wrong here, does anyone have the actual
> > descriptor dump of a device anywhere?
> 
> We don't want to piggy-back on the CDC-ACM spec. A WebUSB device should
> always have its interfaces marked vendor-specific. Below is an example of a
> device which implements both a CDC-ACM interface and a WebUSB interface.

Ick, why would you want both interfaces on a device?  Are you going to
allow firmware to talk to both endpoints at the same time?  Why?

Why not just make it a "one interface" type of device?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 06:13:04PM +0100, Bjørn Mork wrote:
> Greg KH <g...@kroah.com> writes:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can not
> >> grab any USB device.
> >> 
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor,
> 
> I fail to see why a quirk should be necessary. New device classes are
> expected to use new class/subclass codes distintly different from
> anything handled by existing class drivers.

One would hope, but it seems like they want to piggy-back on the cdc-acm
spec.  But I could be totally wrong here, does anyone have the actual
descriptor dump of a device anywhere?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 01:12:11PM +0200, Felipe Balbi wrote:
> 
> I don't think we need to change anything in the kernel. What we need is
> generic udev rule that fixes up permissions for the WebUSB Interface.
> 
> IIRC, WebUSB is implemented much like CDC ACM, however bInterfaceClass
> is set to Vendor Specific. That should be enough to prevent CDC-ACM
> driver from binding to WebUSB Interface.

Yeah, someone drug you into this thread a bit late, I already suggested
that a simple kernel patch would resolve all of this  :)

Now all we do is wait for someone to make that patch...

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] WebUSB

[Greg KH]

On Mon, Jan 09, 2017 at 11:29:24AM +0100, Aleksander Morgado wrote:
> On Mon, Jan 9, 2017 at 11:07 AM, Greg KH <g...@kroah.com> wrote:
> > On Mon, Jan 09, 2017 at 09:40:59AM +, Kenneth Rohde Christiansen wrote:
> >> Web USB can only grab devices which has special Web USB headers. It can not
> >> grab any USB device.
> >>
> >> https://wicg.github.io/webusb/#webusb-descriptors
> >
> > Ah, fun :(
> >
> > So, we can add a quirk into the kernel cdc-acm driver to never bind to a
> > device that has the wusb platform capability descriptor, which will
> > prevent you from having to disconnect the driver from the device (and
> > the permissions issues involved in that.)
> >
> > Would that help out?
> >
> > And just do the same thing in modem manager, never grab a device with
> > this descriptor, and let the browser/webusb handle the control of the
> > device if it so desires.
> 
> Not sure anything would be required in ModemManager if the kernel
> already skips the binding to cdc-acm; i.e. ModemManager won't do
> anything unless the TTY is exposed.

Great, that was easy then!

So, who is going to send in the kernel patch for this? :)

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Greg KH]

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
> On 'Predictable Network Interface Names' it states as a benefit of the new
> policy:
> 
>   Stable interface names even when hardware is added or removed, i.e.
>   no re-enumeration takes place
> 
> Unfortunately this is not true.
> 
> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
> Replaced it with new one (newer model). Booted the system.
> 
> All seemed to be fine, network seemed to work. But after some time got angry
> cries: 'can't read the mail !!!'. A big headache.
> 
> Although the new card was in the same slot as the old one kernel had changed
> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
> policy was used as default). Since enp6s0 was not found our server instead
> of fixed ip address used our dhcp-server to get a random temp address. Thus
> network worked, but not in the mail-servers correct address.
> 
> To figure this out took some nervous time.
> 
> Now, I don't know why kernel driver got a different name for this network
> interface (ethernet hardware is on the motherboard, and it is the only net
> hardware on the system). But obviously it can happen.

That is because your PCI devices renumbered themselves, which is quite
common when changing PCI devices around (or adding/removing them).  Not
much systemd can do about this, sorry.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] TTL for systemd -> EL7

[Greg KH]

On Wed, Oct 12, 2016 at 09:08:27AM -0400, Chris Bell wrote:
> Hey everyone,
> 
> Not sure if this is the right place to ask, but I figured someone here or at
> RH would know. What's the TTL for systemd updates on EL7? My Arch box runs
> 231, but our EL7 (RHEL7.2) boxes are only at 219, where it has been (if I'm
> not mistaken) since the 7.0 release. Any idea on when they may port an
> update?

Why not ask Red Hat?  You are paying for support, why wouldn't you be
able information like this directly from them?

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 01:55:34PM +, Jóhann B. Guðmundsson wrote:
> On 08/16/2016 12:53 PM, Greg KH wrote:
> 
> On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote:
> 
> > On 08/16/2016 12:34 PM, Greg KH wrote:
> > 
> 
> > > But agreement is usually the best way to work things out, 
> don't you
> > > think?  Isn't it better than the traditional way a company 
> works (a
> > > project manager says "this has to be merged!")?
> 
> > 
> > Agreed mutual agreement is the best course of action always but 
> sometimes
> > drastic measures will need to be taken to break status quo.
> 
> Which is what happens when needed.  We've been doing this for a long
> time now, you would think that people would trust us by now...
> 
> 
> Less to do with trust more to do with the fact If that process was working, 
> Tejun Heo changes would have been merged ( or some mutual agreement reached on
> the way forward ) and we would not be having this discussion here in the first
> place.

One might argue that the process _is_ working as planned, the review
comments are valid ones and need to be addressed.

Anyway, this whole argument is totally pointless, just let the upstream
development process work its way through the issues, and see what
happens.  In the meantime, to object to other developers doing work on
systemd to test out these changes seems very odd, who are you, or me, to
tell someone else what they can or can not do with their project?

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 12:47:16PM +, Jóhann B. Guðmundsson wrote:
> 
> 
> On 08/16/2016 12:31 PM, Greg KH wrote:
> > On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote:
> > > 
> > > On 08/16/2016 11:28 AM, Greg KH wrote:
> > > > On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:
> > > > 
> > Such as what specifically?
> 
> Are you pretending you are going to be reviewing this now?

I'm saying I care about wireguard and want to see it succeed.

> >   Do other VPNs require changes to systemd in
> > some way?
> 
> Irrelevant.

No, not at all, I'm just really confused as to what systemd changes are
required to get wireguard working properly with it?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 12:51:12PM +, Jóhann B. Guðmundsson wrote:
> On 08/16/2016 12:34 PM, Greg KH wrote:
> 
> > But agreement is usually the best way to work things out, don't you
> > think?  Isn't it better than the traditional way a company works (a
> > project manager says "this has to be merged!")?
> 
> Agreed mutual agreement is the best course of action always but sometimes
> drastic measures will need to be taken to break status quo.

Which is what happens when needed.  We've been doing this for a long
time now, you would think that people would trust us by now...

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 12:35:13PM +, Jóhann B. Guðmundsson wrote:
> 
> 
> On 08/16/2016 12:13 PM, Greg KH wrote:
> > On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote:
> > > Why cant the kernel community figure this out and solve this upstream 
> > > first
> > > since it's quite obvious from the threads that Tejun Heo linked to in 
> > > that pull
> > > request that this is a political issue not a technical one.
> > > 
> > > Surely Linus and his so called lieutenants can step in and break political
> > > status quo like that.
> > That makes no sense at all, sorry.  Work with the upstream developers to
> > get this resolved, that's all that anyone can do here.
> 
> So each maintainer can prevent changeset from being merged if affect the
> area he ( currently ) maintains the kernel.

No one has "absolute" control, sorry, that's not how we work.

But agreement is usually the best way to work things out, don't you
think?  Isn't it better than the traditional way a company works (a
project manager says "this has to be merged!")?

> That's interesting and begs the question how much time and energy the kernel
> community spend in resolving matters that stem from "opinions" and people
> stubbornness?

Please feel free to show how this is true, I don't see this at all.

And you do realize that the kernel is the largest (by number of
contributors and different companies), and fastest moving, software
project ever in the history of computing?  Perhaps the model that we
have does work pretty well :)

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 12:25:47PM +, Jóhann B. Guðmundsson wrote:
> 
> 
> On 08/16/2016 11:28 AM, Greg KH wrote:
> > On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:
> > > 
> > > On 08/16/2016 10:44 AM, Greg KH wrote:
> > > > On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
> > > > > Recent case in point is the that the wireguard maintainer was/is 
> > > > > interested
> > > > > seeing it property integrated into systemd. Anywork related to that 
> > > > > could not
> > > > > be started *until* he had his stuff merged in the upstream kernel 
> > > > > however now
> > > > > anyone can have anything not upstreamed implemented in systemd.
> > > > Wait, what needs to be added to systemd to get wireguard "working"
> > > > properly?  It's just like any other network VPN service, what makes it
> > > > special (well, becides the very coolness of it of course...)
> > > > 
> > > > Were there patches that were rejected?  Any pointers to them?
> > > The patches have not been written yet because the systemd developer
> > > mentioned he would not accept it until this was merged upstream.
> > Again, what type of patches to systemd are needed for wireguard?
> > 
> 
> For example changes to networkd configuration files.

Such as what specifically?  Do other VPNs require changes to systemd in
some way?

> Why are you so fixated on this since his stance is arguably the correct one
> on refusing this in the first place *until* this has been implemented in the
> upstream kernel which arguably and should have been done in relation with
> cgroup v2 until that got sorted out.

Who is "his"?

> Are you against the policy of upstreaming first?

The world is not black and white :)

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 11:23:03AM +, Jóhann B. Guðmundsson wrote:
> On 08/16/2016 10:42 AM, Greg KH wrote:
> 
> As long as this new code doesn't break things for users without those
> kernel patches, why would you object?  Are you having to maintain these
> new features for some reason?
> 
> 
> No but I eventually might have to deal with the fallout from such approach.

Really?  How?

> Why cant the kernel community figure this out and solve this upstream first
> since it's quite obvious from the threads that Tejun Heo linked to in that 
> pull
> request that this is a political issue not a technical one.
> 
> Surely Linus and his so called lieutenants can step in and break political
> status quo like that.

That makes no sense at all, sorry.  Work with the upstream developers to
get this resolved, that's all that anyone can do here.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 11:15:03AM +, Jóhann B. Guðmundsson wrote:
> 
> 
> On 08/16/2016 10:44 AM, Greg KH wrote:
> > On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
> > > Recent case in point is the that the wireguard maintainer was/is 
> > > interested
> > > seeing it property integrated into systemd. Anywork related to that could 
> > > not
> > > be started *until* he had his stuff merged in the upstream kernel however 
> > > now
> > > anyone can have anything not upstreamed implemented in systemd.
> > Wait, what needs to be added to systemd to get wireguard "working"
> > properly?  It's just like any other network VPN service, what makes it
> > special (well, becides the very coolness of it of course...)
> > 
> > Were there patches that were rejected?  Any pointers to them?
> 
> The patches have not been written yet because the systemd developer
> mentioned he would not accept it until this was merged upstream.

Again, what type of patches to systemd are needed for wireguard?

confused,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
> Recent case in point is the that the wireguard maintainer was/is interested
> seeing it property integrated into systemd. Anywork related to that could not
> be started *until* he had his stuff merged in the upstream kernel however now
> anyone can have anything not upstreamed implemented in systemd.

Wait, what needs to be added to systemd to get wireguard "working"
properly?  It's just like any other network VPN service, what makes it
special (well, becides the very coolness of it of course...)

Were there patches that were rejected?  Any pointers to them?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Head ups - upstream first no longer applies to the kernel.

[Greg KH]

On Tue, Aug 16, 2016 at 10:11:27AM +, Jóhann B. Guðmundsson wrote:
> On 08/16/2016 09:04 AM, Lennart Poettering wrote:
> 
> On Mon, 15.08.16 10:53, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
> 
> Johann, what you are posting here is really not helpful in any
> way.
> 
> 
> It's helpful in that way of letting people know that you have chosen to
> deviating from upstream first is policy so people can submit work which has 
> not
> been accepted in other upstreams.

There is code in the udev binary that works for kernel patches that have
remained out-of-tree for 8+ years.  Are you going to rip that out now?  :)

Sometimes you have to add code to projects in order to be able to
properly test the kernel code.  And to make it easier for people to
upgrade their kernels in the future and have things work properly on
their existing, older, system tools.  This happens all the time, I don't
know why you are suddenly surprised about this.

As long as this new code doesn't break things for users without those
kernel patches, why would you object?  Are you having to maintain these
new features for some reason?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question on special configuration case

[Greg KH]

On Wed, Jun 08, 2016 at 06:43:04AM +, Hebenstreit, Michael wrote:
> > Really?  No journal messages are getting created at all?  No users logging 
> > in/out?  What does strace show on those processes?
> 
> Yes, messages are created - but I'm not interested in them. Maybe a
> user logs in for a 6h job - that's already tracked by the cluster
> software. There are virtually no demons running, no changes to the
> hardware - so all those demons are doing are looking out for
> themselves. Not really productive

If messages are created, they have to go somewhere, to think that they
would be "free" is crazy :)

> > So you are hurting all 253 cores because you can't spare 1?
> 
> Situation is a bit more complex. I have 64 physical cores, with 4
> units each for integer operations and 2 floating point units. So
> essentially if I reserve one integer unit for the OS, due to cache
> hierarchies and other oddities, I essentially take down 4 cores. The
> applications typically scale best if they run on a power of 2 number
> of cores. 

You can still run the applications on the "non-reserved" core, it's just
that the kernel can't get access to any of the others.  So you only take
the hit of any potential wakeups and other kernel housekeeping on that
one core.

Again, try it, you might be pleasantly surprised as your workload is
_exactly_ what that feature was created for.  To ignore it without
testing seems bizarre to me.  If it doesn't work for you, then either
that kernel feature needs to be fixed, or maybe we can just rip it out,
so you need to tell the kernel developers about it.

> > Again, that's not the issue, you can't see the time the kernel is using to 
> > do its work, but it is there (interrupts, scheduling, housekeeping,
> etc.)
> 
> shouldn't that show up in the time for worker threads?

How do you account for interrupts, I/O, scheduler processing time, etc?
:)

> And I'm not arguing you are wrong. We should minimize that and if
> possible keep all OS on an extra core. That does not make my argument
> invalid those demons are doing nothing more than housekeeping
> themselves in a very complicated fashion and they are wasting
> resources. 

Again, I think you are wasting more resources than you realize just
because you can't see it :)

And as others have pointed out, turn off watchdogs and you should be
fine from a systemd point of view.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question on special configuration case

[Greg KH]

On Wed, Jun 08, 2016 at 02:04:48AM +, Hebenstreit, Michael wrote:
> > What processes are showing up in your count?  Perhaps it's just a
> > bug that needs to be fixed.
> /bin/dbus-daemon
> /usr/lib/systemd/systemd-journald
> /usr/lib/systemd/systemd-logind
> 
> I understand from the previous mails those are necessary to make
> systemd work - but here they are doing nothing more than talking to
> each other!

Really?  No journal messages are getting created at all?  No users
logging in/out?  What does strace show on those processes?

> > That what "most" other system designers in your situation do :)
> Unfortunately I cannot reserve a CPU for OS - I'd like to, but the app
> developers insist to use all 254 cores available

So you are hurting all 253 cores because you can't spare 1?  If you do
the math I think you will find you will get increased throughput.  But
what do I know... :)

> > Your kernel is eating more CPU time than those 1s numbers, why you
> > aren't complaining about that seems strange to me :)
> I also check kernel - last time I look on RH6 all kernel threads
> taking up clock ticks were actually doing work ^^ No time yet to do
> the same on RH7 kernel

Again, that's not the issue, you can't see the time the kernel is using
to do its work, but it is there (interrupts, scheduling, housekeeping,
etc.)  So get it out of the way entirely and see how much faster your
application runs without it even present on those cpus, if you really
have cpu bound processes.  That's what the feature was made for, people
in your situation, to ignore it and try to go after something else seems
very strange to me.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] question on special configuration case

[Greg KH]

On Tue, Jun 07, 2016 at 11:50:36PM +, Hebenstreit, Michael wrote:
> The base system is actually pretty large (currently 1200 packages) - I
> hate that myself. Still performance wise the packages are not the
> issue. The SSDs used can easily handle that, and library loads are
> only happening once at startup (where the difference van be measured,
> but if the runtime is 24h startup time of 1s are not an issue). Kernel
> is tweaked, but those changes are relatively small.
> 
> The single problem biggest problem is OS noise. Aka every cycle that
> the CPU(s) are working on anything but the application. This is caused
> by a  combination of "large number of nodes" and "tightly coupled job
> processes". 

Then bind your applications to the cpus and don't let anything else run
on them, including the kernel.  That way you will not get any jitter or
latencies and can use the CPUs to their max, without having to worry
about anything.  Leave one CPU alone to have the kernel be able to
manage its housekeeping tasks (you seem to be ignoring that issue when
looking at systemd, which is odd to me as it's more noise than anything
else), and also let everything else run there as well.

That what "most" other system designers in your situation do :)

> Our current (RH6) based system runs with a minimal number of demons,
> none of them taking up any CPU time unless they are used. Systemd
> process are not so well behaved. After a few hours of running they are
> already at a few seconds.

What processes are showing up in your count?  Perhaps it's just a bug
that needs to be fixed.

> On a single system - or systems working independent like server farms
> - that is not an issue. On our systems each second lost is multiplied
> by the number of nodes in the jobs (let's say 200, but it could also
> be up to 1 or more on large installations) due to tight coupling.
> If 3 demons use 1s a day each (and this is realistic on Xeon Phi
> Knights Landing systems), that's slowing down the performance by
> almost 1% (3 * 200 / 86400 = 0.7% to be exact). And - we do not gain
> anything from those demons after initial startup! 

Your kernel is eating more CPU time than those 1s numbers, why you
aren't complaining about that seems strange to me :)

> My worst experience with such issues was on a cluster that lost 20%
> application performance due to a badly configured crond demon.

That's not the issue here though.

Again, what tasks are causing cpu time for "no good reason", let's see
if we can just fix them.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd network interface names - new twist

[Greg KH]

On Thu, Jun 02, 2016 at 06:29:50PM +0200, Reindl Harald wrote:
> 
> 
> Am 02.06.2016 um 18:20 schrieb Greg KH:
> > Ok, but please ask on a fedora list as this is a fedora specific issue,
> > as it is running a very old version of systemd as well as the kernel, so
> > there's not much we can do here either
> 
> you must confuse Fedora with other distributions in context of "as well as
> the kernel" because of 4.5.6-200.fc23.x86_64 #1 SMP Wed Jun 1 21:28:20 UTC
> 2016

OP stated they were using Fedora 21 and the 3.18 kernel, what does that
have to do with Fedora 23 and the 4.5.6 kernel?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd network interface names - new twist

[Greg KH]

On Thu, Jun 02, 2016 at 10:14:22AM -0600, JB wrote:
> Hi Greg,
> Thank you very much for responding!
> 
> On 6/2/2016 9:46 AM, Greg KH wrote:
> > On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote:
> > > I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd. The
> > > motherboard is an intel board with dual onboard NIC. I installed FC21
> > > initially with secondary ethernet interface disabled in the BIOS. Then 
> > > after
> > > install, I enabled it. However, while the first NIC name comes up as
> > > expected getting renamed from eth0 to eno#. The second NIC never gets
> > > renamed and instead is brought up as eth1.
> > > 
> > > What's up with that? I thought they were all supposed to get en* names. I
> > > mean after all, I've already retooled all our software to accommodate the
> > > new scheme.
> > This sounds like a Fedora bug, in noticing your "new" NIC that showed up
> > after the system was installed.  I suggest you file a bug with their
> > reporting system.
> Sorry, I probably should have been more clear. I disabled the secondary NIC
> in the BIOS intentionally prior to OS installation. Then I did the FC21
> minimal installation which excludes most of Fedora's network management
> stuff. I also disabled NetworkManager and ripped out any other fedora
> specific stuff. In looking at dmesg and journalctl I'm seeing where systemd
> renames eth0 to it's new name, but leaves eth1 untouched which is the part
> that is confusing me.
> 
> The new NIC showed up, as expected, after I enabled it in the BIOS. I think
> I could more easily see your point if NIC naming was determined at OS
> installation time but my experience has been that systemd does it as part of
> it's initialization regardless of what was there when the OS was installed.

Ok, but please ask on a fedora list as this is a fedora specific issue,
as it is running a very old version of systemd as well as the kernel, so
there's not much we can do here either.

> > Also, please note that the 3.18 kernel is very old and unsupported, you
> > might want to update to a modern kernel release :)
> 
> Yeah, I'm aware of that. Sadly, the application I'm dealing with has strong
> dependencies on RTAI and the most recent kernel supported by even the most
> recent beta of RTAI is 3.18.22 :( This is particularly challenging since
> most of the driver support we need is all in the newer kernels. I've been
> looking at some of the more recent RT processing capabilities slowly making
> their way into the stock kernel but for now, it's a circumstance I must
> contend with!

You might try the real-time kernel patches, they seem to perform just as
well, if not better, than RTAI, and you are not stuck with obsolete and
unsuportable kernel versions.

Best of luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd network interface names - new twist

[Greg KH]

On Thu, Jun 02, 2016 at 06:24:39AM -0600, JB wrote:
> I'm running kernel 3.18.22. I'm seeing some odd behavior from systemd. The
> motherboard is an intel board with dual onboard NIC. I installed FC21
> initially with secondary ethernet interface disabled in the BIOS. Then after
> install, I enabled it. However, while the first NIC name comes up as
> expected getting renamed from eth0 to eno#. The second NIC never gets
> renamed and instead is brought up as eth1.
> 
> What's up with that? I thought they were all supposed to get en* names. I
> mean after all, I've already retooled all our software to accommodate the
> new scheme.

This sounds like a Fedora bug, in noticing your "new" NIC that showed up
after the system was installed.  I suggest you file a bug with their
reporting system.

Also, please note that the 3.18 kernel is very old and unsupported, you
might want to update to a modern kernel release :)

hope this helps,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

[Greg KH]

On Fri, May 27, 2016 at 09:14:51AM -0600, Chris Friesen wrote:
> On 05/27/2016 08:36 AM, Lennart Poettering wrote:
> > On Thu, 26.05.16 12:28, Chris Friesen (cbf...@mail.usask.ca) wrote:
> > 
> > > So I've been playing with this a bit, but I've run into another snag.  It
> > > seems that on initial boot even with "net.ifnames=0" the ethernet 
> > > interface
> > > ordering isn't consistent.
> > > 
> > > This means that two systems with identical hardware can end up mapping
> > > "eth1000" to different physical slots.  This makes it very difficult to 
> > > set
> > > up multiple machines.
> > 
> > Yupp, thta's what we have been saying all along: enumerating and
> > probing devices is not stable, that's why the predictable interface
> > names have been introduced after all, so that the same name refers to
> > the same device all the time.
> > 
> > > I assume this is due to parallel network device initialization from
> > > udev?
> > 
> > Well, udev just modprobes the driver. The driver then probes all
> > devices and that happens in any order it likes.
> 
> Looking at the kernel code, the probing order for pci NICs for a given
> driver is pretty well deterministic.

That is, if your BIOS doesn't decide to renumber the devices between
boots.  And yes, this can, and will, happen at times.  Usually if you
add/remove a device, or update the BIOS, but we have reports of machines
that the BIOS reorders things when it feels like, and I had one that
would do it every 2nd _or_ 3rd boot.

So again, you are playing with fire here, and will get burned when you
least expect it, good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] when/where was support for assigning "ethX" names removed?

[Greg KH]

On Thu, May 26, 2016 at 01:49:07PM -0600, Chris Friesen wrote:
> On 05/26/2016 12:41 PM, Martin Pitt wrote:
> > Chris Friesen [2016-05-26 12:28 -0600]:
> > > So I've been playing with this a bit, but I've run into another snag.  It
> > > seems that on initial boot even with "net.ifnames=0" the ethernet 
> > > interface
> > > ordering isn't consistent.
> > 
> > "even with" → "because of" :-)
> > 
> > However, the ordering isn't really influenced by udev/systemd/ifnames,
> > that's entirely dependent on the hardware and kernel drivers.
> > 
> > > I assume this is due to parallel network device initialization from udev?
> > 
> > udev (or userspace in general) has no business in detecting physical
> > network devices, that's exclusively the kernel.
> 
> I'm looking at the kernel code now. It appears that the ordering of the
> network device discovery is influenced by the order in which the kernel
> modules are loaded as well as the physical layout of the system.  I saw some
> online notes that said that udev had a hand in loading the modules, and that
> it might load multiple modules in parallel--is that correct?
> 
> The thing that makes this all confusing/annoying is that when I was using a
> homebrew distro with a 3.10 kernel and sysV init the interface ordering was
> completely repeatable on identical hardware, but when I went to CentOS 7
> with a 3.10 kernel and systemd the interface ordering became variable.

Try making your own kernel with the needed drivers built-in and the
ordering should start to get semi-predictable, but then it might not be
because the kernel, and userspace, and your hardware, do not make any
guarantees of this AT ALL.

So you really are on your own here, good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Verify the gpg signature of the given tag

[Greg KH]

On Wed, May 11, 2016 at 09:57:05AM +0200, poma wrote:
> 
> $ git tag --verify v229
> object 95adafc428b5b4be0ddd4d43a7b96658390388bc
> type commit
> tag v229
> tagger Lennart Poettering  1455208658 +0100
> 
> systemd 229
> gpg: Signature made Thu 11 Feb 2016 05:37:38 PM CET using RSA key ID 9C3485B0
> gpg: Good signature from "Lennart Poettering "
> gpg: aka "Lennart Poettering "
> gpg: aka "Lennart Poettering (Red Hat) "
> gpg: aka "Lennart Poettering (Sourceforge.net) 
> "
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the owner.
> Primary key fingerprint: 63CD A1E5 D3FC 22B9 98D2  0DD6 327F 2695 1A01 5CC4
>  Subkey fingerprint: 16B1 C4EE C0BC 021A C777  F681 B63B 2187 9C34 85B0
> 
> 
> How to do this without "gpg: WARNING:" part?

That's on your end, not the repo's end.  I suggest reading up on gpg
trust models if you wish for this to be able to be resolved on your
system.

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] service dependency on udev

[Greg KH]

On Tue, Apr 19, 2016 at 05:25:09PM -0300, Flavio Leitner wrote:
> 
> Hello,
> 
> I have a service that needs to start after all the devices (network
> cards at least) have been properly processed by udev.  Pretty much
> like the old 'network' sysv script.
> 
> Any suggestion?

How do you define "all the devices"?  That's not very event driven,
which is the issue you are probably having here.

Why not just trigger your service after the needed network device is
found?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote:
> When you say that probing on the PCI bus never ends, and if we are
> talking not about some form of hotplugging, then I really wonder what
> you're on about ;-) because I do think the kernel has a limited set of
> probes that it can perform, and at some point it is going to quit.

Not if it is interrupt driven, the kernel only responds to devices when
they show up, it doesn't know how many devices are going to be ever
found.

> It seems clear that some things are only going to be done once.

"once"?

> So I am not sure what you are alluding to. If there is some theoretical
> tail (and it has not to do with hotplugging) I'm not sure if it is ever
> going to be relevant here. If there is a theoretical tail, the system
> cannot wait for it anyway.

The issue is that you need to create a system that allows devices to
show up whenever they decide to show up, you can't "wait around" for
anything as you never know just how long, or what will, or will not,
show up.

You have to design a system that is event driven, as that is how
hardware works, and is the only way your system can work properly due to
it possibly changing all the time (devices added / removed between
boots, etc.)

good luck!

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote:
> Greg KH schreef op 13-04-16 01:16:
> > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
> >> All you need to do is wait a few seconds before you start renaming
> > 
> > Most machines boot to login faster than a "few seconds", so:
> 
> Most machines boot to login faster than a few seconds?
> 
> What machines are you talking about?

All execpt for 4-socket and larger servers.  They take tens of minutes
in the BIOS and then less than a minute in the kernel/userspace,
depending on the amount of memory.

Doesn't your laptop/desktop boot that fast?  If not, you are using the
wrong distro :)

> Anyway the 3 seconds I mentioned is or would be a relative number.

You have to define this in a way that will properly work.

> I am sure you can provision that in your boot sequence.

How?

> >> or wait on some defined trigger.
> > 
> > Exactly what type of "defined trigger" would work for busses that you
> > never know when they are finished being probed?
> 
> What buses are you mentioning here?

PCI, USB, etc.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote:
> All you need to do is wait a few seconds before you start renaming

Most machines boot to login faster than a "few seconds", so:

> or wait on some defined trigger.

Exactly what type of "defined trigger" would work for busses that you
never know when they are finished being probed?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
> >> You can put usb devices at the end of the list.
> > 
> > Why last?  How do you know they go last when scanning?  How do you know
> > when / if they will show up?  What about 2 USB devices?  3?
> 
> To me it seems obvious that you initialize onboard devices before USB
> devices, so it would not be a "how do you know" because you do it yourself.

How you determine if a device is "onboard" or "offboard"?  Are you going
to know when all "onboard" devices are found before you do anything
else?  How?

> Also, since the current scheme puts usb devices in a slightly different
> format you can identify them from the name.
> 
> You are right in saying that that would cause a list that changes as it
> is getting populated. But onboard/builtin devices should definitely all
> be scanned before networking is initialized right?

Not true at all, drivers are loaded whenever, at pretty much random
times, when ever the hardware is found by the kernel.  It's
non-deterministic and you never know when it's done for some busses
(like USB).

Best of luck,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
> It will just not be "predictable" when you remove or add hardware,
> because that reorders the resulting lists.
> 
> Ie, if you have:
> 
> ethernet0
> ethernet1
> ethernet2
> 
> And you add a new device, it might become:
> 
> ethernet0
> ethernet1
> ethernet2  <-- new device
> ethernet3
> 
> But is that really an issue?

Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
naming scheme at all"

> You can put usb devices at the end of the list.

Why last?  How do you know they go last when scanning?  How do you know
when / if they will show up?  What about 2 USB devices?  3?

It looks like you really want the old-style naming scheme, which is
great, you have the ability to roll back to that.  Please do so.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Greg KH]

On Mon, Apr 11, 2016 at 07:59:30PM +0200, Xen wrote:
> Greg KH schreef op 11-04-16 15:42:
> > On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> >> The predictability issue seems to be due to using a MAC address.
> >>
> >> AFAIK a reinstall will not change PCI bus devices etc.
> > 
> > No, PCI device numbers change all the time, they are not guaranteed to
> > be stable at all.  Yes, lots of machines do not have them change, but a
> > non-small number do.  Most of the time they change only if you have
> > changed a PCI device (which includes thunderbolt and docking stations,
> > quite common these days), or when you update your BIOS, but my favorite
> > machine would renumber the whole bus every other boot for no good reason
> > at all.
> > 
> > So don't think of PCI bus numbers as static, they aren't, sorry.
> 
> That implies that the whole PCI addressing is not something you can
> depend on to begin with. I'm sorry, from their inclusion in the mapping
> feature, I assumed that it would be something dependable. You basically
> say that even on a single machine, that whole feature might not work
> reliably, and hence should not be used.
> 
> However, this currently confuses me because my own ethernet device is
> numbered by biosdev according to "PCI geographical location".
> 
> Maybe that is not a bus number, but:
> 
> [P]ps[f][d]
> 
> My device is enp3s0, which implies 3rd bus number, which it indeed is:
> 
> E: ID_PATH=pci-:03:00.0
> 
> Are you telling me there are systems where this is not guaranteed to be
> stable?

Yes, including your own.

> Maybe these two numbers are coincidentally the same and not
> related. It's an onboard chip (as most) and so not really geograpically
> located.

Put a new PCI device in your system, or boot it in a docking station, or
plug in some thunderbolt devices before booting and then look at this
number.

But, it's the best that the system can do, as obviously your bios does
not provide a slot name for the PCI device, otherwise the naming scheme
would have picked that.

Go file a bug for your laptop manufacturer to properly provide the
needed PCI slot number, and then your id will not change.

> In all of the examples though, this is not a coincidence and these
> numbers are identical. This PCI path is used for the biosdev name.
> 
> You are saying it is not stable?

Yes, see above.

The naming scheme starts with the most stable thing it can find and
works downward.  PCI ids are usually "good enough" for almost everyone,
like you are seeing on your system.  But they do change, which is why
most sane BIOSes provide PCI slot information, as those correspond
directly to the hardware location in the system.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] on the default for PredictableNetworkInterfaceNames

[Greg KH]

On Mon, Apr 11, 2016 at 11:56:00AM +0200, Xen wrote:
> The predictability issue seems to be due to using a MAC address.
> 
> AFAIK a reinstall will not change PCI bus devices etc.

No, PCI device numbers change all the time, they are not guaranteed to
be stable at all.  Yes, lots of machines do not have them change, but a
non-small number do.  Most of the time they change only if you have
changed a PCI device (which includes thunderbolt and docking stations,
quite common these days), or when you update your BIOS, but my favorite
machine would renumber the whole bus every other boot for no good reason
at all.

So don't think of PCI bus numbers as static, they aren't, sorry.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Network Interface Names: solution for a desktop OS

[Greg KH]

On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote:
> Michael Biebl schreef op 11-04-16 00:22:
> > So why don't you implement such a scheme? Talk is cheap
> 
> Criticising an idea by saying "do it yourself" is even cheaper.
> 
> MUCH MUCH cheaper.
> 
> Idiot.

No he isn't.  The developers here put a lot of thought and energy
working with numerous hardware requirements an user cases in order to
come up with the current situation.  It works for almost everyone, which
is vastly better than the previous scheme of "first driver loaded
wins!", which barely worked for anyone, and caused so many problems it
wasn't funny (just ask any of us who have been in support for a distro
about the problems...)

If you have an alternative proposal, great, it can be fit into the
existing system (note the heirachy of names that are picked depending on
just how well your hardware describes itself.)  Please propose that.

If you don't like the current scheme, that's also fine, there is a
trivial way to "opt-out" of it.

So I don't understand your complaints, you don't like the current
scheme, yet you don't have any proposal other than "I liked the original
way", which you still have access to.  So really, there isn't anything
to change here that I can see, unless you have a new naming scheme that
can be implemented as well?

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fwd: Random X crash on nvidia card on Gnome 3.20

[Greg KH]

On Sun, Apr 10, 2016 at 11:12:00PM +0800, Bob Peng wrote:
> Today I upgraded to 3.20 and it begins random crash, log is attached.
> and dmesg log too.

This isn't a systemd issue, it's a nvidia issue, please contact them for
support as they are the only ones that can do so because of their closed
source kernel driver that you are using.

best of luck,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Utility for persistent alternative driver binding

[Greg KH]

On Wed, Dec 09, 2015 at 08:43:05AM +0200, Panu Matilainen wrote:
> On 12/08/2015 01:47 PM, Greg KH wrote:
> >On Tue, Dec 08, 2015 at 11:34:36AM +0200, Panu Matilainen wrote:
> >>>As was mentioned recently PCI bus numbers may change between reboots, so
> >>
> >>Hmm, got a pointer? I dont think PCI slots change between reboots without
> >>physically swapping hardware, the "ethX-problem" comes from the order of
> >>device discovery being unstable across boots, which is a different issue and
> >>not relevant for this case.
> >
> >PCI can renumber the bus ids any time it wants to between reboots, it's
> >not only if you add/remove new hardware.  Now luckily most BIOSes aren't
> >that broken and do keep keep things stable if the hardware doesn't
> >change, but not all do, so be careful about this.  I had a broken BIOS
> >that would renumber things about every 10 reboots just "for fun" that
> >was very good at using for testing system assumptions about static PCI
> >device ids.
> 
> Ugh :-/ I've clearly only seen well-behaved BIOSes. But even if the news is
> bad its good to know, thanks.

See the other messages in this thread about how Qemu will also give you
semi-random PCI addresses every other boot, that's a much more common
problem and something easy to test with.

> >>>you may want to start with something more stable from the very beginning.
> >>
> >>Such as? I dont see any other data that is there for all PCI (and USB)
> >>devices that allows differentiating between two otherwise identical devices.
> >
> >Again, it all depends on the device itself, they should provide
> >something that makes them unique (MAC address, serial number, topology
> >at the moment, etc.)  There is no one-thing-fits-all, which is why udev
> >provides so many different ways to name things (look at /dev/disk/* and
> >/dev/serial/* as examples of this.)
> 
> At the time driverctl runs, things like MAC address are not available since
> the normal driver is not loaded, its just a "raw" device on a bus.

It's a PCI device on the bus, not a network device.  When you create the
network device, then you have a MAC address.  You never need to rename a
PCI device.

> So I guess it'll need to grow an alternative mode that allows override by
> PCI ID and operates on all devices by that ID, which loses a bit of control
> vs the slot number but for the cases where slot number isn't reliable...

What?  What are you trying to "rename" here?  I thought we were talking
about network devices, or something else that a user actually interacts
with.  Userspace never deals with a "raw" PCI device, you should never
care about those ids for anything "real".

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel