* Re: [PATCH net-next] vhost: switch to use new message format
From: David Miller @ 2018-08-04 20:21 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, kvm, mst
In-Reply-To: <1533279891-12249-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Fri, 3 Aug 2018 15:04:51 +0800
> So fixing this by introducing a new message type with an explicit
> 32bit reserved field after type like:
>
> struct vhost_msg_v2 {
> int type;
> __u32 reserved;
Please use fixed sized types consistently. Use 's32' instead of 'int'
here.
Thanks!
^ permalink raw reply
* Re: for newbies, it would be useful to document values of netdev_state_t
From: Florian Fainelli @ 2018-08-04 18:10 UTC (permalink / raw)
To: Robert P. J. Day, Linux kernel ntedev mailing list
In-Reply-To: <alpine.LFD.2.21.1808041128280.23447@localhost.localdomain>
On 08/04/2018 08:30 AM, Robert P. J. Day wrote:
>
> i'm sure this is second nature for the experts here, but in
> netdevice.h:
>
> /* These flag bits are private to the generic network queueing
> * layer; they may not be explicitly referenced by any other
> * code.
> */
>
> enum netdev_state_t {
> __LINK_STATE_START,
> __LINK_STATE_PRESENT,
> __LINK_STATE_NOCARRIER,
> __LINK_STATE_LINKWATCH_PENDING,
> __LINK_STATE_DORMANT,
> };
>
> it would be handy to have a short explanation of what each state
> represents, perhaps what combinations are possible and how one moves
> from one state to another.
This has been like that for some time, and with the exception of the
problem you reported in your email before that one, people generally
don't muck with that enum, or the state machine consuming it. There
might be other places that could deserve better documentation ;)
--
Florian
^ permalink raw reply
* Re: [PATCH net 1/1] net/smc: no cursor update send in state SMC_INIT
From: David Miller @ 2018-08-04 20:10 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180803083833.51029-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Fri, 3 Aug 2018 10:38:33 +0200
> If a writer blocked condition is received without data, the current
> consumer cursor is immediately sent. Servers could already receive this
> condition in state SMC_INIT without finished tx-setup. This patch
> avoids sending a consumer cursor update in this case.
>
> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: Remove some unneeded semicolon
From: Sergei Shtylyov @ 2018-08-04 18:08 UTC (permalink / raw)
To: zhong jiang, davem, wensong, horms, ja; +Cc: netdev, linux-kernel
In-Reply-To: <1533382901-17922-1-git-send-email-zhongjiang@huawei.com>
On 08/04/2018 02:41 PM, zhong jiang wrote:
> That semicolon is not unneeded , Just remove them.
s/un//, right? ;-)
That and you suddenly switch from singular to plural.
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 4.4 106/124] netlink: Do not subscribe to non-existent groups
From: Nathan Chancellor @ 2018-08-04 18:07 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, Dmitry Safonov
In-Reply-To: <20180804082706.427556290@linuxfoundation.org>
On Sat, Aug 04, 2018 at 11:01:35AM +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Dmitry Safonov <dima@arista.com>
>
> [ Upstream commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ]
>
> Make ABI more strict about subscribing to group > ngroups.
> Code doesn't check for that and it looks bogus.
> (one can subscribe to non-existing group)
> Still, it's possible to bind() to all possible groups with (-1)
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Steffen Klassert <steffen.klassert@secunet.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/netlink/af_netlink.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -983,6 +983,7 @@ static int netlink_bind(struct socket *s
> if (err)
> return err;
> }
> + groups &= (1UL << nlk->ngroups) - 1;
>
> bound = nlk->bound;
> if (bound) {
>
>
Hi Greg,
I am so sorry I didn't catch this in my initial report but this commit
along with ba7aaf93ef2f ("netlink: Don't shift with UB on nlk->ngroups")
breaks mobile data on both the Pixel 2 XL and OnePlus 6. There is signal
but it just never connects to 3G/LTE. Reverting those two commits fixes
the issue.
Nothing stands out to me in dmesg unfortunately and iven neither device
is running a vanilla kernel, I cannot say if this is a problem in mainline
or not but I just wanted to make you aware of it.
Thanks!
Nathan
^ permalink raw reply
* Re: [PATCH] net: cisco: enic: Replace GFP_ATOMIC with GFP_KERNEL
From: David Miller @ 2018-08-04 20:08 UTC (permalink / raw)
To: baijiaju1990; +Cc: benve, _govind, pkaustub, netdev, linux-kernel
In-Reply-To: <20180804004009.18928-1-baijiaju1990@gmail.com>
From: Jia-Ju Bai <baijiaju1990@gmail.com>
Date: Sat, 4 Aug 2018 08:40:09 +0800
> vnic_dev_register(), vnic_rq_alloc_bufs() and vnic_wq_alloc_bufs()
> are never called in atomic context.
> They call kzalloc() with GFP_ATOMIC, which is not necessary.
> GFP_ATOMIC can be replaced with GFP_KERNEL.
>
> This is found by a static analysis tool named DCNS written by myself.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Robert P. J. Day @ 2018-08-04 17:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jiri Pirko, Linux kernel ntedev mailing list
In-Reply-To: <20180804102627.09259ca6@xeon-e3>
On Sat, 4 Aug 2018, Stephen Hemminger wrote:
... big snip ...
> ndo_change_carrier is not the droid your looking for.
>
> The purpose of ndo_change_carrier was for testing network devices
> (ie dummy), and also for cases like network tunnels where the
> sofrware carrier state may be controlled by a userspace daemon.
>
> Real network devices call netif_carrier_on and netif_carrier_off
> when they notice change in carrier state in hardware. Typically,
> this is when an interrupt happens.
i had actually come to just that conclusion, as i was digging
through the code, and couldn't immediately see why setting
ndo_change_carrier() would cause a problem. in fact, to help my
admittedly painful newbie-level debugging, i started a wiki page to
track this (i document *everything* on wiki pages):
http://crashcourse.ca/dokuwiki/doku.php?id=ndo_change_carrier
so i am reduced to concluding that the drivers in question are simply
not calling correctly the very routines you mention.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Stephen Hemminger @ 2018-08-04 17:26 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Jiri Pirko, Linux kernel ntedev mailing list
In-Reply-To: <alpine.LFD.2.21.1808040751170.704@localhost.localdomain>
On Sat, 4 Aug 2018 07:57:56 -0400 (EDT)
"Robert P. J. Day" <rpjday@crashcourse.ca> wrote:
> On Sat, 4 Aug 2018, Jiri Pirko wrote:
>
> > Sat, Aug 04, 2018 at 01:06:58PM CEST, rpjday@crashcourse.ca wrote:
> > >
> > > i'll try to keep this (relatively) short as there may be a simple
> > >answer to this, or it could just be a stupid question -- sort of
> > >related to previous question (thank you, florian).
> > >
> > > currently messing with networking device involving FPGA and some
> > >quad-port transceivers, and noticed that, when one unplugs or plugs
> > >a device into one of the ports, there is no change in the contents
> > >of the corresponding sysfs files /sys/class/net/<ifname>/carrier
> > >(or operstate, for that matter, which might be related to this as
> > >well). doing this with a "regular" port on my linux laptop
> > >certainly confirmed that the carrier file would switch between 0
> > >and 1, and operstate would switch between up and down, so i know
> > >what behaviour i was *expecting* if things were ostensibly working
> > >properly.
> > >
> > > long story short, i pawed through the driver code only to stumble
> >
> > What driver? Has to be out of tree as I don't see any in the
> > existing kernel using .ndo_change_carrier (aside of team and dummy)
>
> yes, currently proprietary and in-house under development, so i have
> to be a little vague about certain details.
>
> > >over this in the ethernet driver for the device:
> > >
> > > static const struct net_device_ops netdev_netdev_ops = {
> > > ... snip ...
> > > .ndo_change_carrier = netdev_change_carrier,
> > > ... snip ...
> > > };
> > >
> > >and
> > >
> > > static int
> > > netdev_change_carrier(struct net_device *dev, bool new_carrier)
> > > {
> > > if (new_carrier)
> > > netif_carrier_on(dev);
> > > else
> > > netif_carrier_off(dev);
> > > return 0;
> > > }
> > >
> > >as i mentioned before, i am really new to kernel networking code,
> > >so i did a quick search and found this in netdevice.h:
> > >
> > >* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
> > > * Called to change device carrier. Soft-devices (like dummy, team, etc)
> > > * which do not represent real hardware may define this to allow their
> > > * userspace components to manage their virtual carrier state. Devices
> > > * that determine carrier state from physical hardware properties (eg
> > > * network cables) or protocol-dependent mechanisms (eg
> > > * USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
> > > *
> > >
> > >although i still don't fully understand the purpose of that field,
> > >it makes me *very* nervous to read that that routine is for "soft"
> > >devices, and ***not*** for devices that attempt to determine
> > >carrier state from physical hardware properties. i searched the
> > >kernel code base for other drivers that set that field, and found
> > >only what is mentioned in that comment -- dummy.c, of_dummy_mac.c
> > >and team.c.
> > >
> > > the testers for this unit are complaining that they are somehow
> > >not being notified when they plug and unplug devices from the ports
> > >-- is this why? what would be the purpose of assigning a routine to
> > >that field? as i read it (and i could be wrong), my impression is
> > >that you can have the driver *either* determine the carrier state
> > >from physical properties, *or* allow userspace control, but not
> > >both, is that correct?
> >
> > Correct. Your device is physical device, it knows how to get the
> > state of the carrier itself.
>
> that's what i *thought*, good to have confirmation.
>
> > >
> > > i'm about to ask the original authors why they did the above, but
> >
> > I guess that the reason is that they had no clue what they are doing
> > :)
>
> given that i've been immersed in networking code for only a few
> days, i was not about to draw any conclusion like that. :-) i'm going
> to continue perusing the code just to feel more confident about my
> eventual conclusion, but it would seem that there is no compelling
> reason for setting ndo_change_carrier() for actual physical devices,
> and that is quite possibly the cause of the weird behaviour the
> testers are seeing. thanks muchly.
>
> rday
ndo_change_carrier is not the droid your looking for.
The purpose of ndo_change_carrier was for testing network devices
(ie dummy), and also for cases like network tunnels where the
sofrware carrier state may be controlled by a userspace daemon.
Real network devices call netif_carrier_on and netif_carrier_off
when they notice change in carrier state in hardware. Typically,
this is when an interrupt happens.
^ permalink raw reply
* for newbies, it would be useful to document values of netdev_state_t
From: Robert P. J. Day @ 2018-08-04 15:30 UTC (permalink / raw)
To: Linux kernel ntedev mailing list
i'm sure this is second nature for the experts here, but in
netdevice.h:
/* These flag bits are private to the generic network queueing
* layer; they may not be explicitly referenced by any other
* code.
*/
enum netdev_state_t {
__LINK_STATE_START,
__LINK_STATE_PRESENT,
__LINK_STATE_NOCARRIER,
__LINK_STATE_LINKWATCH_PENDING,
__LINK_STATE_DORMANT,
};
it would be handy to have a short explanation of what each state
represents, perhaps what combinations are possible and how one moves
from one state to another.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH 3.18.y] Fix compilation error backporting upstream commit 9fc12023d6f5
From: Lorenzo Bianconi @ 2018-08-04 12:59 UTC (permalink / raw)
To: gregkh; +Cc: stable, netdev
In-Reply-To: <20180804124034.GA4920@kroah.com>
> On Sat, Aug 04, 2018 at 02:27:41PM +0200, Lorenzo Bianconi wrote:
> > Fix following compilation error backporting upstream commit
> > 9fc12023d6f5 ("ipv4: remove BUG_ON() from fib_compute_spec_dst)
> >
> > net/ipv4/fib_frontend.c: In function 'fib_compute_spec_dst':
> > net/ipv4/fib_frontend.c:225:3: error: expected expression before 'if'
> > if (!fib_lookup(net, &fl4, &res))
> >
> > net/ipv4/fib_frontend.c:200:20: warning: unused variable 'res'
> > struct fib_result res;
> >
> > Fixes: 0e46da6c6fac ("ipv4: remove BUG_ON() from fib_compute_spec_dst")
> > Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> > ---
> > net/ipv4/fib_frontend.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> > index 924db4bedd88..0b29649627a7 100644
> > --- a/net/ipv4/fib_frontend.c
> > +++ b/net/ipv4/fib_frontend.c
> > @@ -221,7 +221,7 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
> > fl4.saddr = 0;
> > fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
> > fl4.flowi4_scope = scope;
> > - fl4.flowi4_mark = vmark ? skb->mark : 0,
> > + fl4.flowi4_mark = vmark ? skb->mark : 0;
> > if (!fib_lookup(net, &fl4, &res))
> > return FIB_RES_PREFSRC(net, res);
> > } else {
>
> Thanks, but I fixed this about 6 hours ago, right?
>
Ops, right. Sorry for the noise :)
Regards,
Lorenzo
> greg k-h
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Robert P. J. Day @ 2018-08-04 11:57 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Linux kernel ntedev mailing list
In-Reply-To: <20180804114720.GC2015@nanopsycho>
On Sat, 4 Aug 2018, Jiri Pirko wrote:
> Sat, Aug 04, 2018 at 01:06:58PM CEST, rpjday@crashcourse.ca wrote:
> >
> > i'll try to keep this (relatively) short as there may be a simple
> >answer to this, or it could just be a stupid question -- sort of
> >related to previous question (thank you, florian).
> >
> > currently messing with networking device involving FPGA and some
> >quad-port transceivers, and noticed that, when one unplugs or plugs
> >a device into one of the ports, there is no change in the contents
> >of the corresponding sysfs files /sys/class/net/<ifname>/carrier
> >(or operstate, for that matter, which might be related to this as
> >well). doing this with a "regular" port on my linux laptop
> >certainly confirmed that the carrier file would switch between 0
> >and 1, and operstate would switch between up and down, so i know
> >what behaviour i was *expecting* if things were ostensibly working
> >properly.
> >
> > long story short, i pawed through the driver code only to stumble
>
> What driver? Has to be out of tree as I don't see any in the
> existing kernel using .ndo_change_carrier (aside of team and dummy)
yes, currently proprietary and in-house under development, so i have
to be a little vague about certain details.
> >over this in the ethernet driver for the device:
> >
> > static const struct net_device_ops netdev_netdev_ops = {
> > ... snip ...
> > .ndo_change_carrier = netdev_change_carrier,
> > ... snip ...
> > };
> >
> >and
> >
> > static int
> > netdev_change_carrier(struct net_device *dev, bool new_carrier)
> > {
> > if (new_carrier)
> > netif_carrier_on(dev);
> > else
> > netif_carrier_off(dev);
> > return 0;
> > }
> >
> >as i mentioned before, i am really new to kernel networking code,
> >so i did a quick search and found this in netdevice.h:
> >
> >* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
> > * Called to change device carrier. Soft-devices (like dummy, team, etc)
> > * which do not represent real hardware may define this to allow their
> > * userspace components to manage their virtual carrier state. Devices
> > * that determine carrier state from physical hardware properties (eg
> > * network cables) or protocol-dependent mechanisms (eg
> > * USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
> > *
> >
> >although i still don't fully understand the purpose of that field,
> >it makes me *very* nervous to read that that routine is for "soft"
> >devices, and ***not*** for devices that attempt to determine
> >carrier state from physical hardware properties. i searched the
> >kernel code base for other drivers that set that field, and found
> >only what is mentioned in that comment -- dummy.c, of_dummy_mac.c
> >and team.c.
> >
> > the testers for this unit are complaining that they are somehow
> >not being notified when they plug and unplug devices from the ports
> >-- is this why? what would be the purpose of assigning a routine to
> >that field? as i read it (and i could be wrong), my impression is
> >that you can have the driver *either* determine the carrier state
> >from physical properties, *or* allow userspace control, but not
> >both, is that correct?
>
> Correct. Your device is physical device, it knows how to get the
> state of the carrier itself.
that's what i *thought*, good to have confirmation.
> >
> > i'm about to ask the original authors why they did the above, but
>
> I guess that the reason is that they had no clue what they are doing
> :)
given that i've been immersed in networking code for only a few
days, i was not about to draw any conclusion like that. :-) i'm going
to continue perusing the code just to feel more confident about my
eventual conclusion, but it would seem that there is no compelling
reason for setting ndo_change_carrier() for actual physical devices,
and that is quite possibly the cause of the weird behaviour the
testers are seeing. thanks muchly.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Jiri Pirko @ 2018-08-04 11:47 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux kernel ntedev mailing list
In-Reply-To: <alpine.LFD.2.21.1808040646290.25800@localhost.localdomain>
Sat, Aug 04, 2018 at 01:06:58PM CEST, rpjday@crashcourse.ca wrote:
>
> i'll try to keep this (relatively) short as there may be a simple
>answer to this, or it could just be a stupid question -- sort of
>related to previous question (thank you, florian).
>
> currently messing with networking device involving FPGA and some
>quad-port transceivers, and noticed that, when one unplugs or plugs a
>device into one of the ports, there is no change in the contents of
>the corresponding sysfs files /sys/class/net/<ifname>/carrier (or
>operstate, for that matter, which might be related to this as well).
>doing this with a "regular" port on my linux laptop certainly
>confirmed that the carrier file would switch between 0 and 1, and
>operstate would switch between up and down, so i know what behaviour i
>was *expecting* if things were ostensibly working properly.
>
> long story short, i pawed through the driver code only to stumble
What driver? Has to be out of tree as I don't see any in the existing
kernel using .ndo_change_carrier (aside of team and dummy)
>over this in the ethernet driver for the device:
>
> static const struct net_device_ops netdev_netdev_ops = {
> ... snip ...
> .ndo_change_carrier = netdev_change_carrier,
> ... snip ...
> };
>
>and
>
> static int
> netdev_change_carrier(struct net_device *dev, bool new_carrier)
> {
> if (new_carrier)
> netif_carrier_on(dev);
> else
> netif_carrier_off(dev);
> return 0;
> }
>
>as i mentioned before, i am really new to kernel networking code, so i
>did a quick search and found this in netdevice.h:
>
>* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
> * Called to change device carrier. Soft-devices (like dummy, team, etc)
> * which do not represent real hardware may define this to allow their
> * userspace components to manage their virtual carrier state. Devices
> * that determine carrier state from physical hardware properties (eg
> * network cables) or protocol-dependent mechanisms (eg
> * USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
> *
>
>although i still don't fully understand the purpose of that field, it
>makes me *very* nervous to read that that routine is for "soft"
>devices, and ***not*** for devices that attempt to determine carrier
>state from physical hardware properties. i searched the kernel code
>base for other drivers that set that field, and found only what is
>mentioned in that comment -- dummy.c, of_dummy_mac.c and team.c.
>
> the testers for this unit are complaining that they are somehow not
>being notified when they plug and unplug devices from the ports -- is
>this why? what would be the purpose of assigning a routine to that
>field? as i read it (and i could be wrong), my impression is that you
>can have the driver *either* determine the carrier state from physical
>properties, *or* allow userspace control, but not both, is that
>correct?
Correct. Your device is physical device, it knows how to get the state
of the carrier itself.
>
> i'm about to ask the original authors why they did the above, but
I guess that the reason is that they had no clue what they are doing :)
>i'd like to feel that it's not a stupid question if there's something
>really clever going on here. is this just a development debugging
>feature that would normally be removed at production? or what?
>
>rday
>
>--
>
>========================================================================
>Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca/dokuwiki
>
>Twitter: http://twitter.com/rpjday
>LinkedIn: http://ca.linkedin.com/in/rpjday
>========================================================================
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Antonio Quartulli @ 2018-08-04 11:19 UTC (permalink / raw)
To: Jiri Pirko
Cc: The list for a Better Approach To Mobile Ad-hoc Networking,
Linus Lüssing, netdev, davem
In-Reply-To: <20180804093632.GB2015@nanopsycho>
[-- Attachment #1.1: Type: text/plain, Size: 1835 bytes --]
On 04/08/18 17:36, Jiri Pirko wrote:
>>
>> Do you have any pointer about where this discussion took place? I
>> imagine it happened in conjunction with some patches intended to other
>> drivers/netdev changes.
>>
>> Reading that could give us a sense of how strict/important/severe this
>> decision was and how to prioritize future work.
>>
>> I am asking because we have been working on a new feature since several
>> months and this feature introduces a new sysfs knob.
>>
>> Now, although I understand the recommendation of switching to netlink, I
>> find it a bit impractical to delay a new (and fairly big) feature,
>> simply because it uses a potentially obsolete, but current, API.
>>
>> Any opinion about this?
>
> I agree, that does not make sense.
Thanks for your reply, Jiri.
>
> I just wanted you to consider introducing netlink iface and migrate to
> it as it is generally the preffered way to comunicate with userspace in
> networking area (I don't have pointer any specific discussion though -
> it is just a common knowledge :)).
That's ok. I was asking because in the past batman-adv was using debugfs
for dealing with settings and we were (properly) redirected to sysfs by
David.
Now it seems we need to migrate to the next thing :-) So I just wanted
to be sure we have to do it, but this seems to be the case..
> I will be more then happy to help you
> with that. You should look at net/core/devlink.c and net/wireless/nl80211.c
> to get some inspiration.
Actually we have already implemented a basic netlink API to be used when
sending information to userspace (i.e. routing tables, neighbour tables,
etc..), therefore I think we might be able to leverage on that.
But of course, any help will be appreciated :)
Thanks!
Cheers,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* consequences of setting net_device_ops ndo_change_carrier()?
From: Robert P. J. Day @ 2018-08-04 11:06 UTC (permalink / raw)
To: Linux kernel ntedev mailing list
i'll try to keep this (relatively) short as there may be a simple
answer to this, or it could just be a stupid question -- sort of
related to previous question (thank you, florian).
currently messing with networking device involving FPGA and some
quad-port transceivers, and noticed that, when one unplugs or plugs a
device into one of the ports, there is no change in the contents of
the corresponding sysfs files /sys/class/net/<ifname>/carrier (or
operstate, for that matter, which might be related to this as well).
doing this with a "regular" port on my linux laptop certainly
confirmed that the carrier file would switch between 0 and 1, and
operstate would switch between up and down, so i know what behaviour i
was *expecting* if things were ostensibly working properly.
long story short, i pawed through the driver code only to stumble
over this in the ethernet driver for the device:
static const struct net_device_ops netdev_netdev_ops = {
... snip ...
.ndo_change_carrier = netdev_change_carrier,
... snip ...
};
and
static int
netdev_change_carrier(struct net_device *dev, bool new_carrier)
{
if (new_carrier)
netif_carrier_on(dev);
else
netif_carrier_off(dev);
return 0;
}
as i mentioned before, i am really new to kernel networking code, so i
did a quick search and found this in netdevice.h:
* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
* Called to change device carrier. Soft-devices (like dummy, team, etc)
* which do not represent real hardware may define this to allow their
* userspace components to manage their virtual carrier state. Devices
* that determine carrier state from physical hardware properties (eg
* network cables) or protocol-dependent mechanisms (eg
* USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
*
although i still don't fully understand the purpose of that field, it
makes me *very* nervous to read that that routine is for "soft"
devices, and ***not*** for devices that attempt to determine carrier
state from physical hardware properties. i searched the kernel code
base for other drivers that set that field, and found only what is
mentioned in that comment -- dummy.c, of_dummy_mac.c and team.c.
the testers for this unit are complaining that they are somehow not
being notified when they plug and unplug devices from the ports -- is
this why? what would be the purpose of assigning a routine to that
field? as i read it (and i could be wrong), my impression is that you
can have the driver *either* determine the carrier state from physical
properties, *or* allow userspace control, but not both, is that
correct?
i'm about to ask the original authors why they did the above, but
i'd like to feel that it's not a stupid question if there's something
really clever going on here. is this just a development debugging
feature that would normally be removed at production? or what?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
^ permalink raw reply
* Re: [PATCH 3.18.y] Fix compilation error backporting upstream commit 9fc12023d6f5
From: Greg KH @ 2018-08-04 12:40 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: stable, netdev
In-Reply-To: <20180804122741.7178-1-lorenzo.bianconi@redhat.com>
On Sat, Aug 04, 2018 at 02:27:41PM +0200, Lorenzo Bianconi wrote:
> Fix following compilation error backporting upstream commit
> 9fc12023d6f5 ("ipv4: remove BUG_ON() from fib_compute_spec_dst)
>
> net/ipv4/fib_frontend.c: In function 'fib_compute_spec_dst':
> net/ipv4/fib_frontend.c:225:3: error: expected expression before 'if'
> if (!fib_lookup(net, &fl4, &res))
>
> net/ipv4/fib_frontend.c:200:20: warning: unused variable 'res'
> struct fib_result res;
>
> Fixes: 0e46da6c6fac ("ipv4: remove BUG_ON() from fib_compute_spec_dst")
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
> ---
> net/ipv4/fib_frontend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
> index 924db4bedd88..0b29649627a7 100644
> --- a/net/ipv4/fib_frontend.c
> +++ b/net/ipv4/fib_frontend.c
> @@ -221,7 +221,7 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
> fl4.saddr = 0;
> fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
> fl4.flowi4_scope = scope;
> - fl4.flowi4_mark = vmark ? skb->mark : 0,
> + fl4.flowi4_mark = vmark ? skb->mark : 0;
> if (!fib_lookup(net, &fl4, &res))
> return FIB_RES_PREFSRC(net, res);
> } else {
Thanks, but I fixed this about 6 hours ago, right?
greg k-h
^ permalink raw reply
* [PATCH 3.18.y] Fix compilation error backporting upstream commit 9fc12023d6f5
From: Lorenzo Bianconi @ 2018-08-04 12:27 UTC (permalink / raw)
To: gregkh; +Cc: stable, netdev
Fix following compilation error backporting upstream commit
9fc12023d6f5 ("ipv4: remove BUG_ON() from fib_compute_spec_dst)
net/ipv4/fib_frontend.c: In function 'fib_compute_spec_dst':
net/ipv4/fib_frontend.c:225:3: error: expected expression before 'if'
if (!fib_lookup(net, &fl4, &res))
net/ipv4/fib_frontend.c:200:20: warning: unused variable 'res'
struct fib_result res;
Fixes: 0e46da6c6fac ("ipv4: remove BUG_ON() from fib_compute_spec_dst")
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
---
net/ipv4/fib_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 924db4bedd88..0b29649627a7 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -221,7 +221,7 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
fl4.saddr = 0;
fl4.flowi4_tos = RT_TOS(ip_hdr(skb)->tos);
fl4.flowi4_scope = scope;
- fl4.flowi4_mark = vmark ? skb->mark : 0,
+ fl4.flowi4_mark = vmark ? skb->mark : 0;
if (!fib_lookup(net, &fl4, &res))
return FIB_RES_PREFSRC(net, res);
} else {
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Jiri Pirko @ 2018-08-04 11:52 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
The list for a Better Approach To Mobile Ad-hoc Networking,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <f2964fca-072e-2a6c-4ce9-aa7963465195-2CpIooy/SPIKlTDg6p0iyA@public.gmane.org>
Sat, Aug 04, 2018 at 01:19:39PM CEST, a@unstable.cc wrote:
>On 04/08/18 17:36, Jiri Pirko wrote:
>>>
>>> Do you have any pointer about where this discussion took place? I
>>> imagine it happened in conjunction with some patches intended to other
>>> drivers/netdev changes.
>>>
>>> Reading that could give us a sense of how strict/important/severe this
>>> decision was and how to prioritize future work.
>>>
>>> I am asking because we have been working on a new feature since several
>>> months and this feature introduces a new sysfs knob.
>>>
>>> Now, although I understand the recommendation of switching to netlink, I
>>> find it a bit impractical to delay a new (and fairly big) feature,
>>> simply because it uses a potentially obsolete, but current, API.
>>>
>>> Any opinion about this?
>>
>> I agree, that does not make sense.
>
>Thanks for your reply, Jiri.
>
>>
>> I just wanted you to consider introducing netlink iface and migrate to
>> it as it is generally the preffered way to comunicate with userspace in
>> networking area (I don't have pointer any specific discussion though -
>> it is just a common knowledge :)).
>
>That's ok. I was asking because in the past batman-adv was using debugfs
>for dealing with settings and we were (properly) redirected to sysfs by
>David.
>Now it seems we need to migrate to the next thing :-) So I just wanted
>to be sure we have to do it, but this seems to be the case..
>
>> I will be more then happy to help you
>> with that. You should look at net/core/devlink.c and net/wireless/nl80211.c
>> to get some inspiration.
>
>Actually we have already implemented a basic netlink API to be used when
>sending information to userspace (i.e. routing tables, neighbour tables,
>etc..), therefore I think we might be able to leverage on that.
>But of course, any help will be appreciated :)
Yes, I see net/batman-adv/netlink.c. That looks fine. Shouldn't be hard
to migrate the existing sysfs things there and add new features.
Please don't forget to echo the configured options via netlink
notifications from the very beginning. Feel free to send me patches to
look at.
Thanks!
>
>Thanks!
>
>Cheers,
>
>
>
>--
>Antonio Quartulli
>
^ permalink raw reply
* [PATCH] net: Remove some unneeded semicolon
From: zhong jiang @ 2018-08-04 11:41 UTC (permalink / raw)
To: davem, wensong, horms, ja; +Cc: netdev, linux-kernel
That semicolon is not unneeded , Just remove them.
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
net/core/utils.c | 2 +-
net/netfilter/ipvs/ip_vs_ctl.c | 2 +-
net/packet/af_packet.c | 4 ++--
net/sunrpc/auth_gss/auth_gss.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/utils.c b/net/core/utils.c
index d47863b..2a597ac 100644
--- a/net/core/utils.c
+++ b/net/core/utils.c
@@ -397,7 +397,7 @@ int inet_pton_with_scope(struct net *net, __kernel_sa_family_t af,
break;
default:
pr_err("unexpected address family %d\n", af);
- };
+ }
return ret;
}
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index dd21782..62eefea 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -134,7 +134,7 @@ static void update_defense_level(struct netns_ipvs *ipvs)
} else {
atomic_set(&ipvs->dropentry, 0);
ipvs->sysctl_drop_entry = 1;
- };
+ }
break;
case 3:
atomic_set(&ipvs->dropentry, 1);
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e3e00d3..345e380 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1582,7 +1582,7 @@ static int fanout_set_data(struct packet_sock *po, char __user *data,
return fanout_set_data_ebpf(po, data, len);
default:
return -EINVAL;
- };
+ }
}
static void fanout_release_data(struct packet_fanout *f)
@@ -1591,7 +1591,7 @@ static void fanout_release_data(struct packet_fanout *f)
case PACKET_FANOUT_CBPF:
case PACKET_FANOUT_EBPF:
__fanout_set_data_bpf(f, NULL);
- };
+ }
}
static bool __fanout_id_is_free(struct sock *sk, u16 candidate_id)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 3e192e2..846ea65 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -517,7 +517,7 @@ static int gss_encode_v1_msg(struct gss_upcall_msg *gss_msg,
err = gss_encode_v1_msg(gss_msg, service_name, gss_auth->target_name);
if (err)
goto err_put_pipe_version;
- };
+ }
kref_get(&gss_auth->kref);
return gss_msg;
err_put_pipe_version:
--
1.7.12.4
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Antonio Quartulli @ 2018-08-04 9:24 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking,
Jiri Pirko, Linus Lüssing
Cc: netdev, davem
In-Reply-To: <20180520061954.GA2255@nanopsycho.orion>
[-- Attachment #1.1: Type: text/plain, Size: 2259 bytes --]
Hi Jiri,
On 20/05/18 14:19, Jiri Pirko wrote:
> Tue, Mar 27, 2018 at 05:43:08PM CEST, linus.luessing@c0d3.blue wrote:
>> On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote:
>>>>> I strongly believe it is a huge mistake to use sysfs for things like
>>>>> this. This should be done via generic netlink api.
>>>>
>>>> This doesn't change the problem that it is already that way. This patch
>>>> only adds the list of available files to the README.
>>>
>>> Sure. Just found out you did it like that. Therefore I commented. I
>>> suggest to rework the api to use genl entirely.
>>
>> Hi Jiri,
>>
>> Thanks for sharing your thoughts!
>>
>> Could you explain a bit more on which disadvantages you see in
>> the usage of sysfs here?
>
> There are 2 major disadvantages.
> 1) You don't have any events on a change. An app has to poll in order to
> know what changed in kernel. Netlink handles this by sending
> multicast messages on a specific socket while whoever is interested
> gets the messages.
> 2) In sysfs, everything is string. There are even mixed values like
> "1 (means something)". There are no well defined values. Every driver
> can expose same things differently. In Netlink, you have well-defined
> attributes, with typed values. You can pass multiple attributes for
> the same value if needed.
>
> In general, usage of sysfs in netdev subsystem is frowned upon. I would
> suggest to convert your iface to Generic Netlink API and let the
> existing sysfs API to rot.
Do you have any pointer about where this discussion took place? I
imagine it happened in conjunction with some patches intended to other
drivers/netdev changes.
Reading that could give us a sense of how strict/important/severe this
decision was and how to prioritize future work.
I am asking because we have been working on a new feature since several
months and this feature introduces a new sysfs knob.
Now, although I understand the recommendation of switching to netlink, I
find it a bit impractical to delay a new (and fairly big) feature,
simply because it uses a potentially obsolete, but current, API.
Any opinion about this?
Thanks a lot
Regards,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 4.9-stable] tcp: add tcp_ooo_try_coalesce() helper
From: David Woodhouse @ 2018-08-04 9:10 UTC (permalink / raw)
To: gregkh, davem, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet, dwmw2, jdw
In-Reply-To: <1533373442.16128.123.camel@infradead.org>
From: Eric Dumazet <edumazet@google.com>
commit 58152ecbbcc6a0ce7fddd5bf5f6ee535834ece0c upstream.
In case skb in out_or_order_queue is the result of
multiple skbs coalescing, we would like to get a proper gso_segs
counter tracking, so that future tcp_drop() can report an accurate
number.
I chose to not implement this tracking for skbs in receive queue,
since they are not dropped, unless socket is disconnected.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
net/ipv4/tcp_input.c | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 44d136f..ea2583c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4366,6 +4366,23 @@ static bool tcp_try_coalesce(struct sock *sk,
return true;
}
+static bool tcp_ooo_try_coalesce(struct sock *sk,
+ struct sk_buff *to,
+ struct sk_buff *from,
+ bool *fragstolen)
+{
+ bool res = tcp_try_coalesce(sk, to, from, fragstolen);
+
+ /* In case tcp_drop() is called later, update to->gso_segs */
+ if (res) {
+ u32 gso_segs = max_t(u16, 1, skb_shinfo(to)->gso_segs) +
+ max_t(u16, 1, skb_shinfo(from)->gso_segs);
+
+ skb_shinfo(to)->gso_segs = min_t(u32, gso_segs, 0xFFFF);
+ }
+ return res;
+}
+
static void tcp_drop(struct sock *sk, struct sk_buff *skb)
{
sk_drops_add(sk, skb);
@@ -4489,7 +4506,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
/* In the typical case, we are adding an skb to the end of the list.
* Use of ooo_last_skb avoids the O(Log(N)) rbtree lookup.
*/
- if (tcp_try_coalesce(sk, tp->ooo_last_skb, skb, &fragstolen)) {
+ if (tcp_ooo_try_coalesce(sk, tp->ooo_last_skb,
+ skb, &fragstolen)) {
coalesce_done:
tcp_grow_window(sk, skb);
kfree_skb_partial(skb, fragstolen);
@@ -4539,7 +4557,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
tcp_drop(sk, skb1);
goto merge_right;
}
- } else if (tcp_try_coalesce(sk, skb1, skb, &fragstolen)) {
+ } else if (tcp_ooo_try_coalesce(sk, skb1,
+ skb, &fragstolen)) {
goto coalesce_done;
}
p = &parent->rb_right;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net 0/5] tcp: more robust ooo handling
From: David Woodhouse @ 2018-08-04 9:04 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet
In-Reply-To: <20180804070537.GB15299@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Sat, 2018-08-04 at 09:05 +0200, Greg KH wrote:
>
> Ok, then it's my fault :)
>
> Odds are it did not apply and so I didn't backport it. If you think it
> should be there, please provide a working backport.
It has whitespace issues but that's about it. Will send a version which
applies cleanly...
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]
^ permalink raw reply
* Re: [PATCH 03/17] batman-adv: Add network_coding and mcast sysfs files to README
From: Jiri Pirko @ 2018-08-04 9:36 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
The list for a Better Approach To Mobile Ad-hoc Networking,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <113e9222-3310-71c6-7cec-c253b9b5d194-2CpIooy/SPIKlTDg6p0iyA@public.gmane.org>
Sat, Aug 04, 2018 at 11:24:11AM CEST, a@unstable.cc wrote:
>Hi Jiri,
>
>On 20/05/18 14:19, Jiri Pirko wrote:
>> Tue, Mar 27, 2018 at 05:43:08PM CEST, linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org wrote:
>>> On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote:
>>>>>> I strongly believe it is a huge mistake to use sysfs for things like
>>>>>> this. This should be done via generic netlink api.
>>>>>
>>>>> This doesn't change the problem that it is already that way. This patch
>>>>> only adds the list of available files to the README.
>>>>
>>>> Sure. Just found out you did it like that. Therefore I commented. I
>>>> suggest to rework the api to use genl entirely.
>>>
>>> Hi Jiri,
>>>
>>> Thanks for sharing your thoughts!
>>>
>>> Could you explain a bit more on which disadvantages you see in
>>> the usage of sysfs here?
>>
>> There are 2 major disadvantages.
>> 1) You don't have any events on a change. An app has to poll in order to
>> know what changed in kernel. Netlink handles this by sending
>> multicast messages on a specific socket while whoever is interested
>> gets the messages.
>> 2) In sysfs, everything is string. There are even mixed values like
>> "1 (means something)". There are no well defined values. Every driver
>> can expose same things differently. In Netlink, you have well-defined
>> attributes, with typed values. You can pass multiple attributes for
>> the same value if needed.
>>
>> In general, usage of sysfs in netdev subsystem is frowned upon. I would
>> suggest to convert your iface to Generic Netlink API and let the
>> existing sysfs API to rot.
>
>Do you have any pointer about where this discussion took place? I
>imagine it happened in conjunction with some patches intended to other
>drivers/netdev changes.
>
>Reading that could give us a sense of how strict/important/severe this
>decision was and how to prioritize future work.
>
>I am asking because we have been working on a new feature since several
>months and this feature introduces a new sysfs knob.
>
>Now, although I understand the recommendation of switching to netlink, I
>find it a bit impractical to delay a new (and fairly big) feature,
>simply because it uses a potentially obsolete, but current, API.
>
>Any opinion about this?
I agree, that does not make sense.
I just wanted you to consider introducing netlink iface and migrate to
it as it is generally the preffered way to comunicate with userspace in
networking area (I don't have pointer any specific discussion though -
it is just a common knowledge :)). I will be more then happy to help you
with that. You should look at net/core/devlink.c and net/wireless/nl80211.c
to get some inspiration.
>
>
>Thanks a lot
>
>
>Regards,
>
>
>--
>Antonio Quartulli
>
^ permalink raw reply
* Re: [PATCH v2 7/7] batman-adv: ELP - add throughput meter test duration attribute
From: Antonio Quartulli @ 2018-08-04 9:08 UTC (permalink / raw)
To: Sven Eckelmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
The list for a Better Approach To Mobile Ad-hoc Networking,
Jiri Pirko, Marek Lindner
In-Reply-To: <2057936.2F7DdePauk@sven-edge>
[-- Attachment #1.1: Type: text/plain, Size: 1782 bytes --]
Hi,
On 04/08/18 17:02, Sven Eckelmann wrote:
> On Samstag, 4. August 2018 10:41:09 CEST Antonio Quartulli wrote:
> [...]
>>>> Documentation/ABI/testing/sysfs-class-net-batman-adv | 7 +++++++
>>>
>>> Please discuss this with Jiri [1].
>>>
>>
>> After re-reading Jiri's points I can't really understand why we should
>> now switch to netlink. I think all our sysfs knobs are used to inject
>> settings *to* userspace, therefore his point 1) does not really apply to
>> us. Point 2) is a bit generic and does not really explain why we should
>> *switch*.
>
> Wouldn't it have been better when Jiri would also see your reply? Now he isn't
> even aware of your criticism.
>
>> This said, I'd rather keep this patch as it is and possibly discuss the
>> matter when sending this code to netdev for merging.
>>
>> I've discussed this with Marek too and he is fine with this approach.
>
> Interesting, I don't see it this way. This patch [0] is for netdev and we have
> the statement that "usage of sysfs in netdev subsystem is frowned upon". Now
> you want that we ignore that and than maybe Simon have to deal with the
> fallout when he forwards it to David?
Nope, I'd rather step in myself, should David or anybody else complain
about the patch once sent to netdev. But I totally understand your point.
Personally I did not see Jiri's statements as representative of netdev
as a whole, but it looked like his personal opinion to me (I might be
wrong).
I will reply to [1] directly so we can take the discussion from there then.
Cheers,
>
> Kind regards,
> Sven
>
> [0] https://patchwork.open-mesh.org/patch/17372/
>
>>> [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2018-May/017814.html
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net 0/5] tcp: more robust ooo handling
From: Greg KH @ 2018-08-04 7:05 UTC (permalink / raw)
To: dwmw2
Cc: David Miller, edumazet, juha-matti.tilli, ycheng, soheil, netdev,
eric.dumazet
In-Reply-To: <20180803.165327.407952757157904364.davem@davemloft.net>
On Fri, Aug 03, 2018 at 04:53:27PM -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Fri, 03 Aug 2018 11:55:37 +0100
>
> > I see the first four in 4.9.116 but not the fifth (adding
> > tcp_ooo_try_coalesce()).
> >
> > Is that intentional?
>
> I don't work on the 4.9 -stable backports, so I personally have
> no idea.
>
> I submitted for 4.17 and 4.14
Ok, then it's my fault :)
Odds are it did not apply and so I didn't backport it. If you think it
should be there, please provide a working backport.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 7/7] batman-adv: ELP - add throughput meter test duration attribute
From: Sven Eckelmann @ 2018-08-04 9:02 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
The list for a Better Approach To Mobile Ad-hoc Networking,
Jiri Pirko, Marek Lindner
In-Reply-To: <314bf0ac-4c10-da7a-d527-45afe92423fa-2CpIooy/SPIKlTDg6p0iyA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
On Samstag, 4. August 2018 10:41:09 CEST Antonio Quartulli wrote:
[...]
> >> Documentation/ABI/testing/sysfs-class-net-batman-adv | 7 +++++++
> >
> > Please discuss this with Jiri [1].
> >
>
> After re-reading Jiri's points I can't really understand why we should
> now switch to netlink. I think all our sysfs knobs are used to inject
> settings *to* userspace, therefore his point 1) does not really apply to
> us. Point 2) is a bit generic and does not really explain why we should
> *switch*.
Wouldn't it have been better when Jiri would also see your reply? Now he isn't
even aware of your criticism.
> This said, I'd rather keep this patch as it is and possibly discuss the
> matter when sending this code to netdev for merging.
>
> I've discussed this with Marek too and he is fine with this approach.
Interesting, I don't see it this way. This patch [0] is for netdev and we have
the statement that "usage of sysfs in netdev subsystem is frowned upon". Now
you want that we ignore that and than maybe Simon have to deal with the
fallout when he forwards it to David?
Kind regards,
Sven
[0] https://patchwork.open-mesh.org/patch/17372/
> > [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2018-May/017814.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox