* [PATCH net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" @ 2017-12-02 7:41 Johannes Berg 2017-12-05 16:27 ` David Miller 2017-12-19 12:28 ` [net] " Michael Ellerman 0 siblings, 2 replies; 11+ messages in thread From: Johannes Berg @ 2017-12-02 7:41 UTC (permalink / raw) To: netdev; +Cc: Jouni Malinen, Rasmus Villemoes, Johannes Berg From: Johannes Berg <johannes.berg@intel.com> This reverts commit d6f295e9def0; some userspace (in the case we noticed it's wpa_supplicant), is relying on the current error code to determine that a fixed name interface already exists. Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Johannes Berg <johannes.berg@intel.com> --- net/core/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 07ed21d64f92..f47e96b62308 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1106,7 +1106,7 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf) * when the name is long and there isn't enough space left * for the digits, or if all bits are used. */ - return p ? -ENFILE : -EEXIST; + return -ENFILE; } static int dev_alloc_name_ns(struct net *net, -- 2.14.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-02 7:41 [PATCH net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" Johannes Berg @ 2017-12-05 16:27 ` David Miller 2017-12-19 12:28 ` [net] " Michael Ellerman 1 sibling, 0 replies; 11+ messages in thread From: David Miller @ 2017-12-05 16:27 UTC (permalink / raw) To: johannes; +Cc: netdev, j, linux, johannes.berg From: Johannes Berg <johannes@sipsolutions.net> Date: Sat, 2 Dec 2017 08:41:55 +0100 > From: Johannes Berg <johannes.berg@intel.com> > > This reverts commit d6f295e9def0; some userspace (in the case > we noticed it's wpa_supplicant), is relying on the current > error code to determine that a fixed name interface already > exists. > > Reported-by: Jouni Malinen <j@w1.fi> > Signed-off-by: Johannes Berg <johannes.berg@intel.com> Applied. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-02 7:41 [PATCH net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" Johannes Berg 2017-12-05 16:27 ` David Miller @ 2017-12-19 12:28 ` Michael Ellerman 2017-12-19 16:15 ` Johannes Berg 2017-12-20 23:37 ` Rasmus Villemoes 1 sibling, 2 replies; 11+ messages in thread From: Michael Ellerman @ 2017-12-19 12:28 UTC (permalink / raw) To: Johannes Berg Cc: netdev, Jouni Malinen, Rasmus Villemoes, Johannes Berg, linuxppc-dev Hi Johannes, > From: Johannes Berg <johannes.berg@intel.com> > > This reverts commit d6f295e9def0; some userspace (in the case > we noticed it's wpa_supplicant), is relying on the current > error code to determine that a fixed name interface already > exists. > > Reported-by: Jouni Malinen <j@w1.fi> > Signed-off-by: Johannes Berg <johannes.berg@intel.com> > --- > net/core/dev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This revert seems to have broken networking on one of my powerpc machines, according to git bisect. The symptom is DHCP fails and I don't get a link, I didn't dig any further than that. I can if it's helpful. I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name is now the same as dev_alloc_name_ns") only makes sense while d6f295e9def0 remains in the tree. ie. before the entire series, dev_get_valid_name() would return EEXIST, and that was retained when 87c320e51519 was merged, but now that d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. I can get the network up again if I also revert 87c320e51519 ("net: core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with the gross patch below. cheers diff --git a/net/core/dev.c b/net/core/dev.c index f47e96b62308..d0304461ad32 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1146,7 +1146,11 @@ EXPORT_SYMBOL(dev_alloc_name); int dev_get_valid_name(struct net *net, struct net_device *dev, const char *name) { - return dev_alloc_name_ns(net, dev, name); + int rc = dev_alloc_name_ns(net, dev, name); + if (rc == -ENFILE) + rc = -EEXIST; + + return rc; } EXPORT_SYMBOL(dev_get_valid_name); ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-19 12:28 ` [net] " Michael Ellerman @ 2017-12-19 16:15 ` Johannes Berg 2017-12-20 23:37 ` Rasmus Villemoes 1 sibling, 0 replies; 11+ messages in thread From: Johannes Berg @ 2017-12-19 16:15 UTC (permalink / raw) To: Michael Ellerman; +Cc: netdev, Jouni Malinen, Rasmus Villemoes, linuxppc-dev Hi, > This revert seems to have broken networking on one of my powerpc > machines, according to git bisect. Fun! TBH, I only looked at the immediate problem we ran into, and reverted what was causing it. I don't think we saw the follow-up problem you're seeing. > The symptom is DHCP fails and I don't get a link, I didn't dig any > further than that. I can if it's helpful. > > I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name > is now the same as dev_alloc_name_ns") only makes sense while > d6f295e9def0 remains in the tree. > > ie. before the entire series, dev_get_valid_name() would return EEXIST, > and that was retained when 87c320e51519 was merged, but now that > d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. > > I can get the network up again if I also revert 87c320e51519 ("net: > core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with > the gross patch below. Makes sense. I guess that should be reverted too then, or even your "gross" patch applied. johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" @ 2017-12-19 16:15 ` Johannes Berg 0 siblings, 0 replies; 11+ messages in thread From: Johannes Berg @ 2017-12-19 16:15 UTC (permalink / raw) To: Michael Ellerman; +Cc: netdev, Jouni Malinen, Rasmus Villemoes, linuxppc-dev Hi, > This revert seems to have broken networking on one of my powerpc > machines, according to git bisect. Fun! TBH, I only looked at the immediate problem we ran into, and reverted what was causing it. I don't think we saw the follow-up problem you're seeing. > The symptom is DHCP fails and I don't get a link, I didn't dig any > further than that. I can if it's helpful. > > I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name > is now the same as dev_alloc_name_ns") only makes sense while > d6f295e9def0 remains in the tree. > > ie. before the entire series, dev_get_valid_name() would return EEXIST, > and that was retained when 87c320e51519 was merged, but now that > d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. > > I can get the network up again if I also revert 87c320e51519 ("net: > core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with > the gross patch below. Makes sense. I guess that should be reverted too then, or even your "gross" patch applied. johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-19 12:28 ` [net] " Michael Ellerman 2017-12-19 16:15 ` Johannes Berg @ 2017-12-20 23:37 ` Rasmus Villemoes 2017-12-22 4:22 ` Michael Ellerman 1 sibling, 1 reply; 11+ messages in thread From: Rasmus Villemoes @ 2017-12-20 23:37 UTC (permalink / raw) To: Michael Ellerman Cc: Johannes Berg, netdev, Jouni Malinen, Johannes Berg, linuxppc-dev On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote: > Hi Johannes, > >> From: Johannes Berg <johannes.berg@intel.com> >> >> This reverts commit d6f295e9def0; some userspace (in the case > > This revert seems to have broken networking on one of my powerpc > machines, according to git bisect. > > The symptom is DHCP fails and I don't get a link, I didn't dig any > further than that. I can if it's helpful. > > I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name > is now the same as dev_alloc_name_ns") only makes sense while > d6f295e9def0 remains in the tree. I'm sorry about all of this, I really didn't think there would be such consequences of changing an errno return. Indeed, d6f29 was preparation for unifying the two functions that do the exact same thing (and how we ever got into that situation is somewhat unclear), except for their behaviour in the case the requested name already exists. So one of the two interfaces had to change its return value, and as I wrote, I thought EEXIST was the saner choice when an explicit name (no %d) had been requested. > ie. before the entire series, dev_get_valid_name() would return EEXIST, > and that was retained when 87c320e51519 was merged, but now that > d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. > > I can get the network up again if I also revert 87c320e51519 ("net: > core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with > the gross patch below. I don't think changing -ENFILE to -EEXIST would be right either, since dev_get_valid_name() used to be able to return both (-EEXIST in the case where there's no %d, -ENFILE in the case where we end up calling dev_alloc_name_ns()). If anything, we could do the check for the old -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also fine with reverting. Again, sorry :( Rasmus ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-20 23:37 ` Rasmus Villemoes @ 2017-12-22 4:22 ` Michael Ellerman 2018-01-02 16:50 ` David Miller 0 siblings, 1 reply; 11+ messages in thread From: Michael Ellerman @ 2017-12-22 4:22 UTC (permalink / raw) To: Rasmus Villemoes, Michael Ellerman Cc: Jouni Malinen, netdev, Johannes Berg, linuxppc-dev, Johannes Berg Rasmus Villemoes <linux@rasmusvillemoes.dk> writes: > On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote: >>> From: Johannes Berg <johannes.berg@intel.com> >>> >>> This reverts commit d6f295e9def0; some userspace (in the case >> >> This revert seems to have broken networking on one of my powerpc >> machines, according to git bisect. >> >> The symptom is DHCP fails and I don't get a link, I didn't dig any >> further than that. I can if it's helpful. >> >> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name >> is now the same as dev_alloc_name_ns") only makes sense while >> d6f295e9def0 remains in the tree. > > I'm sorry about all of this, I really didn't think there would be such > consequences of changing an errno return. Indeed, d6f29 was preparation > for unifying the two functions that do the exact same thing (and how we > ever got into that situation is somewhat unclear), except for > their behaviour in the case the requested name already exists. So one of > the two interfaces had to change its return value, and as I wrote, I > thought EEXIST was the saner choice when an explicit name (no %d) had > been requested. No worries. >> ie. before the entire series, dev_get_valid_name() would return EEXIST, >> and that was retained when 87c320e51519 was merged, but now that >> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. >> >> I can get the network up again if I also revert 87c320e51519 ("net: >> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with >> the gross patch below. > > I don't think changing -ENFILE to -EEXIST would be right either, since > dev_get_valid_name() used to be able to return both (-EEXIST in the case > where there's no %d, -ENFILE in the case where we end up calling > dev_alloc_name_ns()). If anything, we could do the check for the old > -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also > fine with reverting. Yeah I think a revert would be best, given it's nearly rc5. My userspace is not exotic AFAIK, just debian something, so presumably this will affect other people too. cheers ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2017-12-22 4:22 ` Michael Ellerman @ 2018-01-02 16:50 ` David Miller 2018-01-02 16:52 ` Johannes Berg 2018-01-08 3:26 ` Michael Ellerman 0 siblings, 2 replies; 11+ messages in thread From: David Miller @ 2018-01-02 16:50 UTC (permalink / raw) To: mpe; +Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg From: Michael Ellerman <mpe@ellerman.id.au> Date: Fri, 22 Dec 2017 15:22:22 +1100 >> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote: >>> This revert seems to have broken networking on one of my powerpc >>> machines, according to git bisect. >>> >>> The symptom is DHCP fails and I don't get a link, I didn't dig any >>> further than that. I can if it's helpful. >>> >>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name >>> is now the same as dev_alloc_name_ns") only makes sense while >>> d6f295e9def0 remains in the tree. >> >> I'm sorry about all of this, I really didn't think there would be such >> consequences of changing an errno return. Indeed, d6f29 was preparation >> for unifying the two functions that do the exact same thing (and how we >> ever got into that situation is somewhat unclear), except for >> their behaviour in the case the requested name already exists. So one of >> the two interfaces had to change its return value, and as I wrote, I >> thought EEXIST was the saner choice when an explicit name (no %d) had >> been requested. > > No worries. > >>> ie. before the entire series, dev_get_valid_name() would return EEXIST, >>> and that was retained when 87c320e51519 was merged, but now that >>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. >>> >>> I can get the network up again if I also revert 87c320e51519 ("net: >>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with >>> the gross patch below. >> >> I don't think changing -ENFILE to -EEXIST would be right either, since >> dev_get_valid_name() used to be able to return both (-EEXIST in the case >> where there's no %d, -ENFILE in the case where we end up calling >> dev_alloc_name_ns()). If anything, we could do the check for the old >> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also >> fine with reverting. > > Yeah I think a revert would be best, given it's nearly rc5. > > My userspace is not exotic AFAIK, just debian something, so presumably > this will affect other people too. I've just queued up the following revert, thanks! ==================== >From 5047543928139184f060c8f3bccb788b3df4c1ea Mon Sep 17 00:00:00 2001 From: "David S. Miller" <davem@davemloft.net> Date: Tue, 2 Jan 2018 11:45:07 -0500 Subject: [PATCH] Revert "net: core: dev_get_valid_name is now the same as dev_alloc_name_ns" This reverts commit 87c320e51519a83c496ab7bfb4e96c8f9c001e89. Changing the error return code in some situations turns out to be harmful in practice. In particular Michael Ellerman reports that DHCP fails on his powerpc machines, and this revert gets things working again. Johannes Berg agrees that this revert is the best course of action for now. Fixes: 029b6d140550 ("Revert "net: core: maybe return -EEXIST in __dev_alloc_name"") Reported-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- net/core/dev.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/net/core/dev.c b/net/core/dev.c index 01ee854454a8..0e0ba36eeac9 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1146,7 +1146,19 @@ EXPORT_SYMBOL(dev_alloc_name); int dev_get_valid_name(struct net *net, struct net_device *dev, const char *name) { - return dev_alloc_name_ns(net, dev, name); + BUG_ON(!net); + + if (!dev_valid_name(name)) + return -EINVAL; + + if (strchr(name, '%')) + return dev_alloc_name_ns(net, dev, name); + else if (__dev_get_by_name(net, name)) + return -EEXIST; + else if (dev->name != name) + strlcpy(dev->name, name, IFNAMSIZ); + + return 0; } EXPORT_SYMBOL(dev_get_valid_name); -- 2.14.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2018-01-02 16:50 ` David Miller @ 2018-01-02 16:52 ` Johannes Berg 2018-01-08 3:26 ` Michael Ellerman 1 sibling, 0 replies; 11+ messages in thread From: Johannes Berg @ 2018-01-02 16:52 UTC (permalink / raw) To: David Miller, mpe; +Cc: linux, michael, j, netdev, linuxppc-dev On Tue, 2018-01-02 at 11:50 -0500, David Miller wrote: > From: Michael Ellerman <mpe@ellerman.id.au> > Date: Fri, 22 Dec 2017 15:22:22 +1100 > > >> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote: > >>> This revert seems to have broken networking on one of my powerpc > >>> machines, according to git bisect. > >>> > >>> The symptom is DHCP fails and I don't get a link, I didn't dig any > >>> further than that. I can if it's helpful. > >>> > >>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name > >>> is now the same as dev_alloc_name_ns") only makes sense while > >>> d6f295e9def0 remains in the tree. > >> > >> I'm sorry about all of this, I really didn't think there would be such > >> consequences of changing an errno return. Indeed, d6f29 was preparation > >> for unifying the two functions that do the exact same thing (and how we > >> ever got into that situation is somewhat unclear), except for > >> their behaviour in the case the requested name already exists. So one of > >> the two interfaces had to change its return value, and as I wrote, I > >> thought EEXIST was the saner choice when an explicit name (no %d) had > >> been requested. > > > > No worries. > > > >>> ie. before the entire series, dev_get_valid_name() would return EEXIST, > >>> and that was retained when 87c320e51519 was merged, but now that > >>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. > >>> > >>> I can get the network up again if I also revert 87c320e51519 ("net: > >>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with > >>> the gross patch below. > >> > >> I don't think changing -ENFILE to -EEXIST would be right either, since > >> dev_get_valid_name() used to be able to return both (-EEXIST in the case > >> where there's no %d, -ENFILE in the case where we end up calling > >> dev_alloc_name_ns()). If anything, we could do the check for the old > >> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also > >> fine with reverting. > > > > Yeah I think a revert would be best, given it's nearly rc5. > > > > My userspace is not exotic AFAIK, just debian something, so presumably > > this will affect other people too. > > I've just queued up the following revert, thanks! > > ==================== > From 5047543928139184f060c8f3bccb788b3df4c1ea Mon Sep 17 00:00:00 2001 > From: "David S. Miller" <davem@davemloft.net> > Date: Tue, 2 Jan 2018 11:45:07 -0500 > Subject: [PATCH] Revert "net: core: dev_get_valid_name is now the same as > dev_alloc_name_ns" > > This reverts commit 87c320e51519a83c496ab7bfb4e96c8f9c001e89. > > Changing the error return code in some situations turns out to > be harmful in practice. In particular Michael Ellerman reports > that DHCP fails on his powerpc machines, and this revert gets > things working again. > > Johannes Berg agrees that this revert is the best course of > action for now. I'm not sure my voice matters much, I merely did the first revert of these two patches ... :) But I agree with Michael that you can't really salvage this without the other patch, and that one caused problems in wifi ... Thanks :) johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2018-01-02 16:50 ` David Miller 2018-01-02 16:52 ` Johannes Berg @ 2018-01-08 3:26 ` Michael Ellerman 2018-01-08 17:36 ` David Miller 1 sibling, 1 reply; 11+ messages in thread From: Michael Ellerman @ 2018-01-08 3:26 UTC (permalink / raw) To: David Miller Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg David Miller <davem@davemloft.net> writes: > From: Michael Ellerman <mpe@ellerman.id.au> > Date: Fri, 22 Dec 2017 15:22:22 +1100 > >>> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote: >>>> This revert seems to have broken networking on one of my powerpc >>>> machines, according to git bisect. >>>> >>>> The symptom is DHCP fails and I don't get a link, I didn't dig any >>>> further than that. I can if it's helpful. >>>> >>>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name >>>> is now the same as dev_alloc_name_ns") only makes sense while >>>> d6f295e9def0 remains in the tree. >>> >>> I'm sorry about all of this, I really didn't think there would be such >>> consequences of changing an errno return. Indeed, d6f29 was preparation >>> for unifying the two functions that do the exact same thing (and how we >>> ever got into that situation is somewhat unclear), except for >>> their behaviour in the case the requested name already exists. So one of >>> the two interfaces had to change its return value, and as I wrote, I >>> thought EEXIST was the saner choice when an explicit name (no %d) had >>> been requested. >> >> No worries. >> >>>> ie. before the entire series, dev_get_valid_name() would return EEXIST, >>>> and that was retained when 87c320e51519 was merged, but now that >>>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE. >>>> >>>> I can get the network up again if I also revert 87c320e51519 ("net: >>>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with >>>> the gross patch below. >>> >>> I don't think changing -ENFILE to -EEXIST would be right either, since >>> dev_get_valid_name() used to be able to return both (-EEXIST in the case >>> where there's no %d, -ENFILE in the case where we end up calling >>> dev_alloc_name_ns()). If anything, we could do the check for the old >>> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also >>> fine with reverting. >> >> Yeah I think a revert would be best, given it's nearly rc5. >> >> My userspace is not exotic AFAIK, just debian something, so presumably >> this will affect other people too. > > I've just queued up the following revert, thanks! Thanks. I don't see it in rc7, will it get to Linus sometime before the release? cheers ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" 2018-01-08 3:26 ` Michael Ellerman @ 2018-01-08 17:36 ` David Miller 0 siblings, 0 replies; 11+ messages in thread From: David Miller @ 2018-01-08 17:36 UTC (permalink / raw) To: mpe; +Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg From: Michael Ellerman <mpe@ellerman.id.au> Date: Mon, 08 Jan 2018 14:26:12 +1100 > I don't see it in rc7, will it get to Linus sometime before the > release? I will do what I can to make sure it does, it is in my GIT tree. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-01-08 17:36 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-02 7:41 [PATCH net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name" Johannes Berg 2017-12-05 16:27 ` David Miller 2017-12-19 12:28 ` [net] " Michael Ellerman 2017-12-19 16:15 ` Johannes Berg 2017-12-19 16:15 ` Johannes Berg 2017-12-20 23:37 ` Rasmus Villemoes 2017-12-22 4:22 ` Michael Ellerman 2018-01-02 16:50 ` David Miller 2018-01-02 16:52 ` Johannes Berg 2018-01-08 3:26 ` Michael Ellerman 2018-01-08 17:36 ` David Miller
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.