Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
1) There would be a single canonical location to track kdbus development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
2) Harald's team (systemd, etc) would commit to testing the system both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
3) kdbus would only be carried in the rawhide branch until it is merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
4) After discussing a bit with the rest of the Fedora kernel maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
On 05.05.2015 19:50, Josh Boyer wrote:
Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
CC'ing the kdbus folks...
On 05.05.2015 20:28, Harald Hoyer wrote:
On 05.05.2015 19:50, Josh Boyer wrote:
Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
CC'ing the kdbus folks...
btw, currently the kdbus module is only loaded by systemd, if you specify "kdbus" on the kernel command line.
On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer harald@redhat.com wrote:
On 05.05.2015 19:50, Josh Boyer wrote:
Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
Right, but that is actually counter-intuitive from the distro perspective. If we aren't going to ship kdbus in a release before it's merged upstream, then you want all the regular default testing that happens during that release's development to be done with what is expected to be the default. In most cases for now, that is likely to be non-kdbus.
An argument could be made that since we're dropping kdbus at the Branched point if it isn't merged, there is time to test still but I'd like to hear other's thoughts on that.
josh
On 05.05.2015 20:43, Josh Boyer wrote:
On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer harald@redhat.com wrote:
On 05.05.2015 19:50, Josh Boyer wrote:
Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
Right, but that is actually counter-intuitive from the distro perspective. If we aren't going to ship kdbus in a release before it's merged upstream, then you want all the regular default testing that happens during that release's development to be done with what is expected to be the default. In most cases for now, that is likely to be non-kdbus.
An argument could be made that since we're dropping kdbus at the Branched point if it isn't merged, there is time to test still but I'd like to hear other's thoughts on that.
josh
One possibility is to enable kdbus by default until alpha phase. (-: Or make it alternate every two weeks or every reboot :-)
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
(-: Or make it alternate every two weeks or every reboot :-)
Heh, make it a run-time setting, and alternate it every hour!
Amit
On 05/06/2015 09:57 AM, Amit Shah wrote:
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
JBG
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Only if it's being proposed as a feature of that release and to be default, this isn't part of the above proposal.
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
I think we're getting a bit ahead of ourselves, the proposal is including it in the mainline Fedora kernel to enable easier testng, and anything outside of Fedora isn't really our problem when we're looking at rawhide TBH.
Let's get patches in to enable it be more easily tested first...
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobinson@gmail.com wrote:
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Only if it's being proposed as a feature of that release and to be default, this isn't part of the above proposal.
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
I think we're getting a bit ahead of ourselves, the proposal is including it in the mainline Fedora kernel to enable easier testng, and anything outside of Fedora isn't really our problem when we're looking at rawhide TBH.
Well, rawhide and rawhide only so it does play into what happens at branch time. But yes, I think the proposal seems to cover this well enough and we can worry about it more when we come to that point.
Let's get patches in to enable it be more easily tested first...
I'm waiting on the next posting of them before we bring them in. It sounds like the proposed item 4 is already covered by the "kdbus" mechanism that systemd looks for so as long as that doesn't change, I think we're OK.
As soon as I see the refreshed patchset I'll look at getting them in.
josh
On Wed, May 6, 2015 at 8:46 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobinson@gmail.com wrote:
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Only if it's being proposed as a feature of that release and to be default, this isn't part of the above proposal.
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
I think we're getting a bit ahead of ourselves, the proposal is including it in the mainline Fedora kernel to enable easier testng, and anything outside of Fedora isn't really our problem when we're looking at rawhide TBH.
Well, rawhide and rawhide only so it does play into what happens at branch time. But yes, I think the proposal seems to cover this well enough and we can worry about it more when we come to that point.
Let's get patches in to enable it be more easily tested first...
I'm waiting on the next posting of them before we bring them in. It sounds like the proposed item 4 is already covered by the "kdbus" mechanism that systemd looks for so as long as that doesn't change, I think we're OK.
Of course, the systemd mechanism changed. Upstream now builds the kdbus code in and requires kdbus=0 on the command line to disable it. If I understand correctly, systemd should fall back to userspace dbus if that is specified or if the kdbus.ko module is missing.
Harald, given one of the conditions for carrying this was testing both kdubs and non-kdbus setups, is your team prepared to do that with the change in place in upstream systemd now?
As soon as I see the refreshed patchset I'll look at getting them in.
The kdbus developers have indicated they believe the code is ready and that there should not be any ABI breaks at this point. I'm working with them to make sure we're all set, but assuming everything holds from before we will likely look at adding the code to rawhide soon.
josh
On 24.06.2015 17:17, Josh Boyer wrote:
On Wed, May 6, 2015 at 8:46 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobinson@gmail.com wrote:
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Only if it's being proposed as a feature of that release and to be default, this isn't part of the above proposal.
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
I think we're getting a bit ahead of ourselves, the proposal is including it in the mainline Fedora kernel to enable easier testng, and anything outside of Fedora isn't really our problem when we're looking at rawhide TBH.
Well, rawhide and rawhide only so it does play into what happens at branch time. But yes, I think the proposal seems to cover this well enough and we can worry about it more when we come to that point.
Let's get patches in to enable it be more easily tested first...
I'm waiting on the next posting of them before we bring them in. It sounds like the proposed item 4 is already covered by the "kdbus" mechanism that systemd looks for so as long as that doesn't change, I think we're OK.
Of course, the systemd mechanism changed. Upstream now builds the kdbus code in and requires kdbus=0 on the command line to disable it. If I understand correctly, systemd should fall back to userspace dbus if that is specified or if the kdbus.ko module is missing.
Harald, given one of the conditions for carrying this was testing both kdubs and non-kdbus setups, is your team prepared to do that with the change in place in upstream systemd now?
systemd.spec in fedora has the configure options "--disable-kdbus", which means "do not connect to kdbus by default".
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/bus-util.c#n2031
bool is_kdbus_wanted(void) { … #ifdef ENABLE_KDBUS const bool configured = true; #else const bool configured = false; #endif … if (get_proc_cmdline_key("kdbus", NULL) > 0) return true;
r = get_proc_cmdline_key("kdbus=", &value); if (r <= 0) return configured;
return parse_boolean(value) == 1;
So, I would say we are good to go. Default is "off", and it can be enabled with "kdbus" or "kdbus=1" on the kernel command line.
As soon as I see the refreshed patchset I'll look at getting them in.
The kdbus developers have indicated they believe the code is ready and that there should not be any ABI breaks at this point. I'm working with them to make sure we're all set, but assuming everything holds from before we will likely look at adding the code to rawhide soon.
josh
On Wed, Jun 24, 2015 at 12:46 PM, Harald Hoyer harald@redhat.com wrote:
On 24.06.2015 17:17, Josh Boyer wrote:
On Wed, May 6, 2015 at 8:46 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Wed, May 6, 2015 at 8:38 AM, Peter Robinson pbrobinson@gmail.com wrote:
On (Wed) 06 May 2015 [11:45:38], Harald Hoyer wrote:
> One possibility is to enable kdbus by default until alpha phase.
The problem with that is all systemd testing is useless once we're out of Alpha. Similar things have happened in the past.
Which is precisely the point.
Alpha needs to be released with this applied and enabled to be useful to anybody. ( and this needs to be applied and enabled up to that point )
Only if it's being proposed as a feature of that release and to be default, this isn't part of the above proposal.
Around that point 4.3 should have been released ( or about to be released ) and either kdbus will be included or it should be clear that it will be included in 4.4 or never but surrounding bugs around the changes to Dracut implementing integration with kdbus will need to have started to receive wider exposure and tested and hopefully have most bugs flushed out otherwise you will be caught in spiral of delays if the intent is to include atleast Dracut with kdbus/integration changes in RHEL 8
I think we're getting a bit ahead of ourselves, the proposal is including it in the mainline Fedora kernel to enable easier testng, and anything outside of Fedora isn't really our problem when we're looking at rawhide TBH.
Well, rawhide and rawhide only so it does play into what happens at branch time. But yes, I think the proposal seems to cover this well enough and we can worry about it more when we come to that point.
Let's get patches in to enable it be more easily tested first...
I'm waiting on the next posting of them before we bring them in. It sounds like the proposed item 4 is already covered by the "kdbus" mechanism that systemd looks for so as long as that doesn't change, I think we're OK.
Of course, the systemd mechanism changed. Upstream now builds the kdbus code in and requires kdbus=0 on the command line to disable it. If I understand correctly, systemd should fall back to userspace dbus if that is specified or if the kdbus.ko module is missing.
Harald, given one of the conditions for carrying this was testing both kdubs and non-kdbus setups, is your team prepared to do that with the change in place in upstream systemd now?
systemd.spec in fedora has the configure options "--disable-kdbus", which means "do not connect to kdbus by default".
http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/bus-util.c#n2031
bool is_kdbus_wanted(void) { … #ifdef ENABLE_KDBUS const bool configured = true; #else const bool configured = false; #endif … if (get_proc_cmdline_key("kdbus", NULL) > 0) return true;
r = get_proc_cmdline_key("kdbus=", &value); if (r <= 0) return configured; return parse_boolean(value) == 1;
So, I would say we are good to go. Default is "off", and it can be enabled with "kdbus" or "kdbus=1" on the kernel command line.
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
josh
On Wed, 8 Jul 2015 10:32:53 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing something that generates audit messages and those spewing to the journal. This drives the load on my laptop up to 5-6 or so and cpu fans spinning.
- selinux isn't happy with things: Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied { connectto } for pid=1086 comm="sedispatch" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0
Where should we report bugs for this work?
Thanks,
kevin
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing something that generates audit messages and those spewing to the journal. This drives the load on my laptop up to 5-6 or so and cpu fans spinning.
I noticed this as well.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied { connectto } for pid=1086 comm="sedispatch" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0
Where should we report bugs for this work?
Hm, tough call. Perhaps against systemd unless it's a kernel oops? I would think systemd might need to set SELinux to permissive if it's booting in kdbus mode until kdbus works with SELinux upstream.
Harald?
josh
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing something that generates audit messages and those spewing to the journal. This drives the load on my laptop up to 5-6 or so and
cpu fans spinning.
I noticed this as well.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied { connectto } for pid=1086 comm="sedispatch" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0
Where should we report bugs for this work?
Hm, tough call. Perhaps against systemd unless it's a kernel oops? I would think systemd might need to set SELinux to permissive if it's booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we should just get labeled correctly in policy?
Hi
On Wed, Jul 8, 2015 at 8:39 PM, Eric Paris eparis@redhat.com wrote:
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing something that generates audit messages and those spewing to the journal. This drives the load on my laptop up to 5-6 or so and
cpu fans spinning.
I noticed this as well.
I assume this happens only with kdbus=1 (and is unrelated to other 4.2-rc1 changes)? Any details on this are highly welcome.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied { connectto } for pid=1086 comm="sedispatch" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0
Where should we report bugs for this work?
(kdbus related bugs should be reported against systemd for now. If it's a kernel oops, you might wanna prefer LKML and put us on CC).
Hm, tough call. Perhaps against systemd unless it's a kernel oops? I would think systemd might need to set SELinux to permissive if it's booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we should just get labeled correctly in policy?
This is the system bus socket of dbus-daemon. If kdbus is enabled, it's not used by any systemd binary (they use kdbus directly). The only exception is systemd-bus-proxyd which provides this socket (replaces dbus-daemon) for backwards compatibility (proxy between dbus1 and kdbus). This socket, though, is created by pid1 via a .socket unit and bus-proxyd is socket activated.
As I cannot parse this selinux error, I hope someone with selinux background can shed some light on this.
Thanks David
On Wed, 2015-07-08 at 20:58 +0200, David Herrmann wrote:
Hi
On Wed, Jul 8, 2015 at 8:39 PM, Eric Paris eparis@redhat.com wrote:
On Wed, 2015-07-08 at 13:02 -0400, Josh Boyer wrote:
On Wed, Jul 8, 2015 at 12:50 PM, Kevin Fenzi kevin@scrye.com wrote:
On Wed, 8 Jul 2015 10:32:53 -0400 Josh Boyer jwboyer@fedoraproject.org wrote:
I just pushed this to git and started a build. It will be in rawhide tomorrow with the 4.2.0-0.rc1.git2.1 kernel. (I was waiting for rc1 before adding it.)
I did test both with and without kdbus=1 and both worked at least from a boot standpoint. The initramfs on an install lacks the kdbus module, so it needs to be rebuilt if one wishes to use kdbus.
Seems to work here with the following issues/bugs/whatever:
- cpu usage is really high, seems to mostly be firewalld doing something that generates audit messages and those spewing to
the journal. This drives the load on my laptop up to 5-6 or so and cpu fans spinning.
I noticed this as well.
I assume this happens only with kdbus=1 (and is unrelated to other 4.2-rc1 changes)? Any details on this are highly welcome.
- selinux isn't happy with things:
Jul 08 10:32:08 voldemort.scrye.com audit[1086]: AVC avc: denied { connectto } for pid=1086 comm="sedispatch" path="/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket permissive=0
Where should we report bugs for this work?
(kdbus related bugs should be reported against systemd for now. If it's a kernel oops, you might wanna prefer LKML and put us on CC).
Hm, tough call. Perhaps against systemd unless it's a kernel oops? I would think systemd might need to set SELinux to permissive if it's booting in kdbus mode until kdbus works with SELinux upstream.
File a bug with selinux-policy. Current policy allows:
allow audisp_t system_dbusd_t : unix_stream_socket connectto ;
But the thing on the other side of /run/dbus/system_bus_socket is no longer system_dbus_t it is init_t...
Is that actually pid=1 on the other side, or something else that we should just get labeled correctly in policy?
This is the system bus socket of dbus-daemon. If kdbus is enabled, it's not used by any systemd binary (they use kdbus directly). The only exception is systemd-bus-proxyd which provides this socket (replaces dbus-daemon) for backwards compatibility (proxy between dbus1 and kdbus). This socket, though, is created by pid1 via a .socket unit and bus-proxyd is socket activated.
As I cannot parse this selinux error, I hope someone with selinux background can shed some light on this.
I thought I did explain what the AVC meant. In any case, looks like /usr/bin/dbus-daemon is labeled system_u:object_r:dbusd_exec_t:s0
So can someone try: chcon system_u:object_r:dbusd_exec_t:s0 /path/to/systemd-bus-proxyd
you'll then need to get systemd-bus-proxyd to re-exec. (either by root or kill and have systemd restart, i dunno)
That will hopefully take care of this avc, at least...
On Wed, May 6, 2015 at 11:45 AM, Harald Hoyer harald@redhat.com wrote:
On 05.05.2015 20:43, Josh Boyer wrote:
On Tue, May 5, 2015 at 2:28 PM, Harald Hoyer harald@redhat.com wrote:
On 05.05.2015 19:50, Josh Boyer wrote:
Hi All,
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
Right, but that is actually counter-intuitive from the distro perspective. If we aren't going to ship kdbus in a release before it's merged upstream, then you want all the regular default testing that happens during that release's development to be done with what is expected to be the default. In most cases for now, that is likely to be non-kdbus.
An argument could be made that since we're dropping kdbus at the Branched point if it isn't merged, there is time to test still but I'd like to hear other's thoughts on that.
One possibility is to enable kdbus by default until alpha phase. (-: Or make it alternate every two weeks or every reboot :-)
The userspace part requires "kdbus" to be given on the kernel command line since the beginning of kdbus development. Without this specified, the module will not be loaded, kdbus not activated by userspace, and the dbus-1 daemon be used.
If the module is manually loaded later, it will not influence the running system, but the kdbus kernel interface it is still usable for the kdbus test programs, and for development it can also be used inside a container. That's why we need to carry the enable switch in userspace and not in the kernel module itself.
We should keep the explicit enabling in rawhide at least for a couple of weeks, while we ask people to manually enable and run it on their systems. If that works out well, we will discuss with the Fedora kernel maintainers, if it might be reasonable to switch the default. Does that make sense?
Anyway, thanks for your support. It will help us a lot if kdbus is in rawhide and that way easy to enable by people to get better testing.
Thanks, Kay
Harald and I were recently talking about kdbus and how it plays into Fedora. Right now, the kernel-playground COPR is carrying the kdbus patches, but that isn't widely used and isn't included in a broad test base. Obviously our distribution is heavily entwined with D-Bus and we were looking to see if it was possible to help kdbus testing and development by doing some kind of integration within Fedora itself. I promised Harald I would talk it over with the other Fedora kernel maintainers and after a brief discussion we came up with the following possible proposal.
If Fedora were to carry kdbus in any form, the following things would be required:
- There would be a single canonical location to track kdbus
development. After talking with Harald, that should be the upstream tree that gregkh is using to submit patches.
- Harald's team (systemd, etc) would commit to testing the system
both with and without kdbus active. Obviously we do not want to enforce reliance on something as core critical as kdbus while it is still being actively developed upstream. That could cause a lot of deviation down the road and it isn't the aim here.
- kdbus would only be carried in the rawhide branch until it is
merged upstream. As a concrete example, if kdbus was not merged in the upstream kernel at the time rel-eng creates the F23 branches, then Fedora 23 will never get kdbus. It will be carried in rawhide and rawhide only until it's accepted upstream. The maintainers actually hope this does get merged but we want to make sure we are prepared to drop this without causing too much trouble if needed.
- After discussing a bit with the rest of the Fedora kernel
maintainers, we would carry an additional patch that would require 'kdbus-enabled' to be specified before the kernel would allow kdbus to be loaded (or similar mechanism). This would focus the main testing effort for all the default images to remain as they are today, while easily allowing the plumbing layer developers access to kdbus for their enablement testing.
These conditions would hopefully help the Fedora kernel maintainers avoid some of the pitfalls of carrying a large chunk of out of tree code and if they're all met we feel fairly comfortable with doing this. We wanted to send this out for a bit wider discussion and review before proceeding with it, and I agreed to start this thread so here we are.
Harald, does the above look like what you were envisioning when we talked earlier?
josh
Looks very good except for point 4, where we wanted to enable kdbus by default and have a "kdbus=0" command line option.
Right, but that is actually counter-intuitive from the distro perspective. If we aren't going to ship kdbus in a release before it's merged upstream, then you want all the regular default testing that happens during that release's development to be done with what is expected to be the default. In most cases for now, that is likely to be non-kdbus.
An argument could be made that since we're dropping kdbus at the Branched point if it isn't merged, there is time to test still but I'd like to hear other's thoughts on that.
josh
One possibility is to enable kdbus by default until alpha phase. (-: Or make it alternate every two weeks or every reboot :-)
Well the enable until alpha is basically what Josh was suggesting with the in rawhide until branching bit because we branch just before we freeze for Alpha.
On the alternate weeks/reboot proposal... rawhide contains a fast moving kernel already I'm really not sure a revolving door approach would be good for user or kernel team's sanity or kdbus as a proposal.
The proposal here was to make it easier to be tested so getting it in the default installed kernel is clearly the biggest obstacle in this regard. I think maybe do the rest in two phases: 1) get it landed but leave it disabled by default 2) based on feedback of users then review whether enabling it by default is worthwhile.
It's then easy to review and move forward.
Ultimately I think we need the default to be what is going to be the default for the release it's being built for because otherwise the testing is useless for the distribution as a whole.
Peter
On Wed, 6 May 2015 11:27:01 +0100 Peter Robinson pbrobinson@gmail.com wrote:
Well the enable until alpha is basically what Josh was suggesting with the in rawhide until branching bit because we branch just before we freeze for Alpha.
On the alternate weeks/reboot proposal... rawhide contains a fast moving kernel already I'm really not sure a revolving door approach would be good for user or kernel team's sanity or kdbus as a proposal.
The proposal here was to make it easier to be tested so getting it in the default installed kernel is clearly the biggest obstacle in this regard. I think maybe do the rest in two phases:
- get it landed but leave it disabled by default
- based on feedback of users then review whether enabling it by
default is worthwhile.
It's then easy to review and move forward.
Ultimately I think we need the default to be what is going to be the default for the release it's being built for because otherwise the testing is useless for the distribution as a whole.
I agree.
I'm personally fine with having it be 'opt in' in rawhide (at least at first) if the kernel maintainers are ok carrying the patch.
I'd also like to suggest a wiki page or something explaining how to enable it, and what to test. Then switching that if it becomes opt out to explain how to do that.
kevin
kernel@lists.fedoraproject.org