Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Fri, Jul 19, 2024 at 9:19 AM Michael S. Tsirkin wrote: > > On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote: > > On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote: > > > > > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin > > > wrote: > > > > > > > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > > > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang > > > > > wrote: > > > > > > > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. This allows propagate > > > > > > > > status > > > > > > > > correctly to stacked devices like: > > > > > > > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > > > > ip link set link enp0s3 down > > > > > > > > ip link show > > > > > > > > > > > > > > > > Before this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > .. > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen > > > > > > > > 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > > > After this patch: > > > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast > > > > > > > > state DOWN mode DEFAULT group default qlen 1000 > > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > > ... > > > > > > > > 5: macvlan0@enp0s3: > > > > > > > > mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group > > > > > > > > default qlen 1000 > > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > > > > the issue fixed is synchronizing state with hardware > > > > > > > config change. > > > > > > > But your example does not show any > > > > > > > hardware change. Isn't this example really just > > > > > > > a side effect of setting carrier off on close? > > > > > > > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. > > > > > > The > > > > > > main thing that is missed is to synchronize the operstate with admin > > > > > > state, if we do this, we get several good results, one of the > > > > > > obvious > > > > > > one is to allow virtio-net to propagate status to the upper layer, > > > > > > for > > > > > > example if the admin state of the lower virtio-net is down it should > > > > > > be propagated to the macvlan on top, so I give the example of using > > > > > > a > > > > > > stacked device. I'm not we had others but the commit log is probably > > > > > > too small to say all of it. > > > > > > > > > > Michael, any more comments on this? > > > > > > > > > > Thans > > > > > > > > > > > > Still don't get it, sorry. > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > > synchronize with the config change work. > > > > What does this sentence mean? What is not synchronized with config > > > > change that needs to be? > > > > > > I meant, > > > > > > 1) maclvan depends on the linkwatch to transfer operstate from the > > > lower device to itself. > > > 2) ndo_open()/close() will not trigger the linkwatch so we need to do > > > it by ourselves in virtio-net to make sure macvlan get the correct > > > opersate > > > 3) consider config change work can change the state so ndo_close() > > > needs to synchronize with it > > > > > > Thanks > > > > Michael, are you fine with the above or I miss something there? > > > > Thanks > > > I don't understand 3. config change can always trigger. > what I do not like is all these reads from config space > that now trigger on open/close. previously we did > read > - on probe > - after probe, if config changed > > > and that made sense. Ok, not sure I get you all but I will post a new version to see. Thanks > > -- > MST >
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote: > On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote: > > > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin wrote: > > > > > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote: > > > > > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin > > > > > wrote: > > > > > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > synchronize with the config change work. This allows propagate > > > > > > > status > > > > > > > correctly to stacked devices like: > > > > > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > > > ip link set link enp0s3 down > > > > > > > ip link show > > > > > > > > > > > > > > Before this patch: > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state > > > > > > > DOWN mode DEFAULT group default qlen 1000 > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > .. > > > > > > > 5: macvlan0@enp0s3: mtu > > > > > > > 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > > > After this patch: > > > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state > > > > > > > DOWN mode DEFAULT group default qlen 1000 > > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > > ... > > > > > > > 5: macvlan0@enp0s3: > > > > > > > mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group > > > > > > > default qlen 1000 > > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > > > the issue fixed is synchronizing state with hardware > > > > > > config change. > > > > > > But your example does not show any > > > > > > hardware change. Isn't this example really just > > > > > > a side effect of setting carrier off on close? > > > > > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. The > > > > > main thing that is missed is to synchronize the operstate with admin > > > > > state, if we do this, we get several good results, one of the obvious > > > > > one is to allow virtio-net to propagate status to the upper layer, for > > > > > example if the admin state of the lower virtio-net is down it should > > > > > be propagated to the macvlan on top, so I give the example of using a > > > > > stacked device. I'm not we had others but the commit log is probably > > > > > too small to say all of it. > > > > > > > > Michael, any more comments on this? > > > > > > > > Thans > > > > > > > > > Still don't get it, sorry. > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > > synchronize with the config change work. > > > What does this sentence mean? What is not synchronized with config > > > change that needs to be? > > > > I meant, > > > > 1) maclvan depends on the linkwatch to transfer operstate from the > > lower device to itself. > > 2) ndo_open()/close() will not trigger the linkwatch so we need to do > > it by ourselves in virtio-net to make sure macvlan get the correct > > opersate > > 3) consider config change work can change the state so ndo_close() > > needs to synchronize with it > > > > Thanks > > Michael, are you fine with the above or I miss something there? > > Thanks I don't understand 3. config change can always trigger. what I do not like is all these reads from config space that now trigger on open/close. previously we did read - on probe - after probe, if config changed and that made sense. -- MST
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote: > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin wrote: > > > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote: > > > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin > > > > wrote: > > > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > synchronize with the config change work. This allows propagate > > > > > > status > > > > > > correctly to stacked devices like: > > > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > > ip link set link enp0s3 down > > > > > > ip link show > > > > > > > > > > > > Before this patch: > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state > > > > > > DOWN mode DEFAULT group default qlen 1000 > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > .. > > > > > > 5: macvlan0@enp0s3: mtu > > > > > > 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > > > After this patch: > > > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state > > > > > > DOWN mode DEFAULT group default qlen 1000 > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > > ... > > > > > > 5: macvlan0@enp0s3: mtu > > > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default > > > > > > qlen 1000 > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > > the issue fixed is synchronizing state with hardware > > > > > config change. > > > > > But your example does not show any > > > > > hardware change. Isn't this example really just > > > > > a side effect of setting carrier off on close? > > > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. The > > > > main thing that is missed is to synchronize the operstate with admin > > > > state, if we do this, we get several good results, one of the obvious > > > > one is to allow virtio-net to propagate status to the upper layer, for > > > > example if the admin state of the lower virtio-net is down it should > > > > be propagated to the macvlan on top, so I give the example of using a > > > > stacked device. I'm not we had others but the commit log is probably > > > > too small to say all of it. > > > > > > Michael, any more comments on this? > > > > > > Thans > > > > > > Still don't get it, sorry. > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > > synchronize with the config change work. > > What does this sentence mean? What is not synchronized with config > > change that needs to be? > > I meant, > > 1) maclvan depends on the linkwatch to transfer operstate from the > lower device to itself. > 2) ndo_open()/close() will not trigger the linkwatch so we need to do > it by ourselves in virtio-net to make sure macvlan get the correct > opersate > 3) consider config change work can change the state so ndo_close() > needs to synchronize with it > > Thanks Michael, are you fine with the above or I miss something there? Thanks
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin wrote: > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote: > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote: > > > > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin wrote: > > > > > > > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote: > > > > > This patch synchronize operstate with admin state per RFC2863. > > > > > > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > synchronize with the config change work. This allows propagate status > > > > > correctly to stacked devices like: > > > > > > > > > > ip link add link enp0s3 macvlan0 type macvlan > > > > > ip link set link enp0s3 down > > > > > ip link show > > > > > > > > > > Before this patch: > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN > > > > > mode DEFAULT group default qlen 1000 > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > .. > > > > > 5: macvlan0@enp0s3: mtu 1500 > > > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000 > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > > > After this patch: > > > > > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN > > > > > mode DEFAULT group default qlen 1000 > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff > > > > > ... > > > > > 5: macvlan0@enp0s3: mtu > > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default > > > > > qlen 1000 > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff > > > > > > > > I think that the commit log is confusing. It seems to say that > > > > the issue fixed is synchronizing state with hardware > > > > config change. > > > > But your example does not show any > > > > hardware change. Isn't this example really just > > > > a side effect of setting carrier off on close? > > > > > > The main goal for this patch is to make virtio-net follow RFC2863. The > > > main thing that is missed is to synchronize the operstate with admin > > > state, if we do this, we get several good results, one of the obvious > > > one is to allow virtio-net to propagate status to the upper layer, for > > > example if the admin state of the lower virtio-net is down it should > > > be propagated to the macvlan on top, so I give the example of using a > > > stacked device. I'm not we had others but the commit log is probably > > > too small to say all of it. > > > > Michael, any more comments on this? > > > > Thans > > > Still don't get it, sorry. > > > > > This is done by trying to toggle the carrier upon open/close and > > > > > synchronize with the config change work. > What does this sentence mean? What is not synchronized with config > change that needs to be? I meant, 1) maclvan depends on the linkwatch to transfer operstate from the lower device to itself. 2) ndo_open()/close() will not trigger the linkwatch so we need to do it by ourselves in virtio-net to make sure macvlan get the correct opersate 3) consider config change work can change the state so ndo_close() needs to synchronize with it Thanks
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote:
> On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote:
> >
> > On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote:
> > > > This patch synchronize operstate with admin state per RFC2863.
> > > >
> > > > This is done by trying to toggle the carrier upon open/close and
> > > > synchronize with the config change work. This allows propagate status
> > > > correctly to stacked devices like:
> > > >
> > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > ip link set link enp0s3 down
> > > > ip link show
> > > >
> > > > Before this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ..
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > >
> > > > After this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ...
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > I think that the commit log is confusing. It seems to say that
> > > the issue fixed is synchronizing state with hardware
> > > config change.
> > > But your example does not show any
> > > hardware change. Isn't this example really just
> > > a side effect of setting carrier off on close?
> >
> > The main goal for this patch is to make virtio-net follow RFC2863. The
> > main thing that is missed is to synchronize the operstate with admin
> > state, if we do this, we get several good results, one of the obvious
> > one is to allow virtio-net to propagate status to the upper layer, for
> > example if the admin state of the lower virtio-net is down it should
> > be propagated to the macvlan on top, so I give the example of using a
> > stacked device. I'm not we had others but the commit log is probably
> > too small to say all of it.
>
> Michael, any more comments on this?
>
> Thans
Still don't get it, sorry.
> > > > This is done by trying to toggle the carrier upon open/close and
> > > > synchronize with the config change work.
What does this sentence mean? What is not synchronized with config
change that needs to be?
> >
> > >
> > >
> > > > Cc: Venkat Venkatsubra
> > > > Cc: Gia-Khanh Nguyen
> > > > Signed-off-by: Jason Wang
> > >
> > > Yes but this just forces lots of re-reads of config on each
> > > open/close for no good reason.
> >
> > Does it really harm? Technically the link status could be changed
> > several times when the admin state is down as well.
> >
> > > Config interrupt is handled in core, you can read once
> > > on probe and then handle config changes.
> >
> > Per RFC2863, the code tries to avoid dealing with any operstate change
> > via config space read when the admin state is down.
> >
> > >
> > >
> > >
> > >
> > >
> > > > ---
> > > > drivers/net/virtio_net.c | 64
> > > > 1 file changed, 38 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 0b4747e81464..e6626ba25b29 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct
> > > > virtnet_info *vi, struct dim *dim)
> > > > net_dim_work_cancel(dim);
> > > > }
> > > >
> > > > +static void virtnet_update_settings(struct virtnet_info *vi)
> > > > +{
> > > > + u32 speed;
> > > > + u8 duplex;
> > > > +
> > > > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > > > + return;
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote:
>
> On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin wrote:
> >
> > On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote:
> > > This patch synchronize operstate with admin state per RFC2863.
> > >
> > > This is done by trying to toggle the carrier upon open/close and
> > > synchronize with the config change work. This allows propagate status
> > > correctly to stacked devices like:
> > >
> > > ip link add link enp0s3 macvlan0 type macvlan
> > > ip link set link enp0s3 down
> > > ip link show
> > >
> > > Before this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ..
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > After this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ...
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > I think that the commit log is confusing. It seems to say that
> > the issue fixed is synchronizing state with hardware
> > config change.
> > But your example does not show any
> > hardware change. Isn't this example really just
> > a side effect of setting carrier off on close?
>
> The main goal for this patch is to make virtio-net follow RFC2863. The
> main thing that is missed is to synchronize the operstate with admin
> state, if we do this, we get several good results, one of the obvious
> one is to allow virtio-net to propagate status to the upper layer, for
> example if the admin state of the lower virtio-net is down it should
> be propagated to the macvlan on top, so I give the example of using a
> stacked device. I'm not we had others but the commit log is probably
> too small to say all of it.
Michael, any more comments on this?
Thans
>
> >
> >
> > > Cc: Venkat Venkatsubra
> > > Cc: Gia-Khanh Nguyen
> > > Signed-off-by: Jason Wang
> >
> > Yes but this just forces lots of re-reads of config on each
> > open/close for no good reason.
>
> Does it really harm? Technically the link status could be changed
> several times when the admin state is down as well.
>
> > Config interrupt is handled in core, you can read once
> > on probe and then handle config changes.
>
> Per RFC2863, the code tries to avoid dealing with any operstate change
> via config space read when the admin state is down.
>
> >
> >
> >
> >
> >
> > > ---
> > > drivers/net/virtio_net.c | 64
> > > 1 file changed, 38 insertions(+), 26 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 0b4747e81464..e6626ba25b29 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info
> > > *vi, struct dim *dim)
> > > net_dim_work_cancel(dim);
> > > }
> > >
> > > +static void virtnet_update_settings(struct virtnet_info *vi)
> > > +{
> > > + u32 speed;
> > > + u8 duplex;
> > > +
> > > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > > + return;
> > > +
> > > + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> > > +
> > > + if (ethtool_validate_speed(speed))
> > > + vi->speed = speed;
> > > +
> > > + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex,
> > > );
> > > +
> > > + if (ethtool_validate_duplex(duplex))
> > > + vi->duplex = duplex;
> > > +}
> > > +
> > > static int virtnet_open(struct net_device *dev)
> > > {
> > > struct virtnet_info *vi = netdev_priv(dev);
> > > @@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
> > > goto err_enable_qp;
> > > }
> &
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jul 9, 2024 at 9:28 PM Michael S. Tsirkin wrote:
>
> On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote:
> > This patch synchronize operstate with admin state per RFC2863.
> >
> > This is done by trying to toggle the carrier upon open/close and
> > synchronize with the config change work. This allows propagate status
> > correctly to stacked devices like:
> >
> > ip link add link enp0s3 macvlan0 type macvlan
> > ip link set link enp0s3 down
> > ip link show
> >
> > Before this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ..
> > 5: macvlan0@enp0s3: mtu 1500 qdisc
> > noqueue state UP mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > After this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ...
> > 5: macvlan0@enp0s3: mtu 1500
> > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> I think that the commit log is confusing. It seems to say that
> the issue fixed is synchronizing state with hardware
> config change.
> But your example does not show any
> hardware change. Isn't this example really just
> a side effect of setting carrier off on close?
The main goal for this patch is to make virtio-net follow RFC2863. The
main thing that is missed is to synchronize the operstate with admin
state, if we do this, we get several good results, one of the obvious
one is to allow virtio-net to propagate status to the upper layer, for
example if the admin state of the lower virtio-net is down it should
be propagated to the macvlan on top, so I give the example of using a
stacked device. I'm not we had others but the commit log is probably
too small to say all of it.
>
>
> > Cc: Venkat Venkatsubra
> > Cc: Gia-Khanh Nguyen
> > Signed-off-by: Jason Wang
>
> Yes but this just forces lots of re-reads of config on each
> open/close for no good reason.
Does it really harm? Technically the link status could be changed
several times when the admin state is down as well.
> Config interrupt is handled in core, you can read once
> on probe and then handle config changes.
Per RFC2863, the code tries to avoid dealing with any operstate change
via config space read when the admin state is down.
>
>
>
>
>
> > ---
> > drivers/net/virtio_net.c | 64
> > 1 file changed, 38 insertions(+), 26 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 0b4747e81464..e6626ba25b29 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info
> > *vi, struct dim *dim)
> > net_dim_work_cancel(dim);
> > }
> >
> > +static void virtnet_update_settings(struct virtnet_info *vi)
> > +{
> > + u32 speed;
> > + u8 duplex;
> > +
> > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > + return;
> > +
> > + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> > +
> > + if (ethtool_validate_speed(speed))
> > + vi->speed = speed;
> > +
> > + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> > +
> > + if (ethtool_validate_duplex(duplex))
> > + vi->duplex = duplex;
> > +}
> > +
> > static int virtnet_open(struct net_device *dev)
> > {
> > struct virtnet_info *vi = netdev_priv(dev);
> > @@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
> > goto err_enable_qp;
> > }
> >
> > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> > + virtio_config_driver_enable(vi->vdev);
> > + /* Do not schedule the config change work as the
> > + * config change notification might have been disabled
> > + * by the virtio core. */
>
> I don't get why you need this.
> If the notification was disabled it will just trigger later.
> This is exactly why using core is a good idea.
So we need a read here (this seems to be not rare for most modern
hardware NICs) because we don't know if the link status is changed or
not and it i
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jul 09, 2024 at 04:02:14PM +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
> ip link add link enp0s3 macvlan0 type macvlan
> ip link set link enp0s3 down
> ip link show
>
> Before this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ..
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> After this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ...
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
I think that the commit log is confusing. It seems to say that
the issue fixed is synchronizing state with hardware
config change. But your example does not show any
hardware change. Isn't this example really just
a side effect of setting carrier off on close?
> Cc: Venkat Venkatsubra
> Cc: Gia-Khanh Nguyen
> Signed-off-by: Jason Wang
Yes but this just forces lots of re-reads of config on each
open/close for no good reason.
Config interrupt is handled in core, you can read once
on probe and then handle config changes.
> ---
> drivers/net/virtio_net.c | 64
> 1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 0b4747e81464..e6626ba25b29 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info
> *vi, struct dim *dim)
> net_dim_work_cancel(dim);
> }
>
> +static void virtnet_update_settings(struct virtnet_info *vi)
> +{
> + u32 speed;
> + u8 duplex;
> +
> + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> + return;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> +
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> +
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
> goto err_enable_qp;
> }
>
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> + virtio_config_driver_enable(vi->vdev);
> + /* Do not schedule the config change work as the
> + * config change notification might have been disabled
> + * by the virtio core. */
I don't get why you need this.
If the notification was disabled it will just trigger later.
This is exactly why using core is a good idea.
> + virtio_config_changed(vi->vdev);
> + } else {
> + vi->status = VIRTIO_NET_S_LINK_UP;
> + virtnet_update_settings(vi);
And why do we need this here I don't get at all.
> + netif_carrier_on(dev);
> + }
> +
> return 0;
>
> err_enable_qp:
> @@ -2936,12 +2967,19 @@ static int virtnet_close(struct net_device *dev)
> disable_delayed_refill(vi);
> /* Make sure refill_work doesn't re-enable napi! */
> cancel_delayed_work_sync(>refill);
> + /* Make sure config notification doesn't schedule config work */
> + virtio_config_driver_disable(vi->vdev);
> + /* Make sure status updating is cancelled */
> + cancel_work_sync(>config_work);
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_disable_queue_pair(vi, i);
> virtnet_cancel_dim(vi, >rq[i].dim);
> }
>
> + vi->status &= ~VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> +
> return 0;
> }
>
> @@ -4640,25 +4678,6 @@ static void virtnet_init_settings(struct net_device
> *dev)
> vi->duplex = DUPLEX_UNKNOWN;
> }
>
> -static void virtnet_update_settings(struct virtnet_info *vi)
> -{
> - u32 speed;
> - u8 duplex;
> -
> - if (!virtio_has_fea
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, 9 Jul 2024 16:02:14 +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
> ip link add link enp0s3 macvlan0 type macvlan
> ip link set link enp0s3 down
> ip link show
>
> Before this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ..
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> After this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ...
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> Cc: Venkat Venkatsubra
> Cc: Gia-Khanh Nguyen
> Signed-off-by: Jason Wang
Reviewed-by: Xuan Zhuo
> ---
> drivers/net/virtio_net.c | 64
> 1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 0b4747e81464..e6626ba25b29 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info
> *vi, struct dim *dim)
> net_dim_work_cancel(dim);
> }
>
> +static void virtnet_update_settings(struct virtnet_info *vi)
> +{
> + u32 speed;
> + u8 duplex;
> +
> + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> + return;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> +
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> +
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
> goto err_enable_qp;
> }
>
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> + virtio_config_driver_enable(vi->vdev);
> + /* Do not schedule the config change work as the
> + * config change notification might have been disabled
> + * by the virtio core. */
> + virtio_config_changed(vi->vdev);
> + } else {
> + vi->status = VIRTIO_NET_S_LINK_UP;
> + virtnet_update_settings(vi);
> + netif_carrier_on(dev);
> + }
> +
> return 0;
>
> err_enable_qp:
> @@ -2936,12 +2967,19 @@ static int virtnet_close(struct net_device *dev)
> disable_delayed_refill(vi);
> /* Make sure refill_work doesn't re-enable napi! */
> cancel_delayed_work_sync(>refill);
> + /* Make sure config notification doesn't schedule config work */
> + virtio_config_driver_disable(vi->vdev);
> + /* Make sure status updating is cancelled */
> + cancel_work_sync(>config_work);
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_disable_queue_pair(vi, i);
> virtnet_cancel_dim(vi, >rq[i].dim);
> }
>
> + vi->status &= ~VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> +
> return 0;
> }
>
> @@ -4640,25 +4678,6 @@ static void virtnet_init_settings(struct net_device
> *dev)
> vi->duplex = DUPLEX_UNKNOWN;
> }
>
> -static void virtnet_update_settings(struct virtnet_info *vi)
> -{
> - u32 speed;
> - u8 duplex;
> -
> - if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> - return;
> -
> - virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> -
> - if (ethtool_validate_speed(speed))
> - vi->speed = speed;
> -
> - virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> -
> - if (ethtool_validate_duplex(duplex))
> - vi->duplex = duplex;
> -}
> -
> static u32 virtnet_get_rxfh_key_size(struct net_device *dev)
> {
> return ((struct virtnet_info *)netdev_priv(dev))->rss_key_size;
> @@ -6000,13 +6019,6 @@ static int virtnet_probe(struc
Re: [PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, 9 Jul 2024 16:02:14 +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
> ip link add link enp0s3 macvlan0 type macvlan
> ip link set link enp0s3 down
> ip link show
>
> Before this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ..
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> After this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ...
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> Cc: Venkat Venkatsubra
> Cc: Gia-Khanh Nguyen
> Signed-off-by: Jason Wang
> ---
> drivers/net/virtio_net.c | 64
> 1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 0b4747e81464..e6626ba25b29 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info
> *vi, struct dim *dim)
> net_dim_work_cancel(dim);
> }
>
> +static void virtnet_update_settings(struct virtnet_info *vi)
> +{
> + u32 speed;
> + u8 duplex;
> +
> + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> + return;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> +
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> +
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
> goto err_enable_qp;
> }
>
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> + virtio_config_driver_enable(vi->vdev);
> + /* Do not schedule the config change work as the
> + * config change notification might have been disabled
> + * by the virtio core. */
> + virtio_config_changed(vi->vdev);
> + } else {
> + vi->status = VIRTIO_NET_S_LINK_UP;
> + virtnet_update_settings(vi);
> + netif_carrier_on(dev);
> + }
> +
> return 0;
>
> err_enable_qp:
> @@ -2936,12 +2967,19 @@ static int virtnet_close(struct net_device *dev)
> disable_delayed_refill(vi);
> /* Make sure refill_work doesn't re-enable napi! */
> cancel_delayed_work_sync(>refill);
> + /* Make sure config notification doesn't schedule config work */
> + virtio_config_driver_disable(vi->vdev);
> + /* Make sure status updating is cancelled */
> + cancel_work_sync(>config_work);
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_disable_queue_pair(vi, i);
> virtnet_cancel_dim(vi, >rq[i].dim);
> }
>
> + vi->status &= ~VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> +
> return 0;
> }
>
> @@ -4640,25 +4678,6 @@ static void virtnet_init_settings(struct net_device
> *dev)
> vi->duplex = DUPLEX_UNKNOWN;
> }
>
> -static void virtnet_update_settings(struct virtnet_info *vi)
> -{
> - u32 speed;
> - u8 duplex;
> -
> - if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> - return;
> -
> - virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> -
> - if (ethtool_validate_speed(speed))
> - vi->speed = speed;
> -
> - virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> -
> - if (ethtool_validate_duplex(duplex))
> - vi->duplex = duplex;
> -}
> -
> static u32 virtnet_get_rxfh_key_size(struct net_device *dev)
> {
> return ((struct virtnet_info *)netdev_priv(dev))->rss_key_size;
> @@ -6000,13 +6019,6 @@ static int virtnet_probe(struct virtio_device *vd
[PATCH net-next v3 3/3] virtio-net: synchronize operstate with admin state on up/down
This patch synchronize operstate with admin state per RFC2863.
This is done by trying to toggle the carrier upon open/close and
synchronize with the config change work. This allows propagate status
correctly to stacked devices like:
ip link add link enp0s3 macvlan0 type macvlan
ip link set link enp0s3 down
ip link show
Before this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
..
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
After this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
...
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
Cc: Venkat Venkatsubra
Cc: Gia-Khanh Nguyen
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 64
1 file changed, 38 insertions(+), 26 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 0b4747e81464..e6626ba25b29 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2476,6 +2476,25 @@ static void virtnet_cancel_dim(struct virtnet_info *vi,
struct dim *dim)
net_dim_work_cancel(dim);
}
+static void virtnet_update_settings(struct virtnet_info *vi)
+{
+ u32 speed;
+ u8 duplex;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
+ return;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
+
+ if (ethtool_validate_speed(speed))
+ vi->speed = speed;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
+
+ if (ethtool_validate_duplex(duplex))
+ vi->duplex = duplex;
+}
+
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -2494,6 +2513,18 @@ static int virtnet_open(struct net_device *dev)
goto err_enable_qp;
}
+ if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
+ virtio_config_driver_enable(vi->vdev);
+ /* Do not schedule the config change work as the
+* config change notification might have been disabled
+* by the virtio core. */
+ virtio_config_changed(vi->vdev);
+ } else {
+ vi->status = VIRTIO_NET_S_LINK_UP;
+ virtnet_update_settings(vi);
+ netif_carrier_on(dev);
+ }
+
return 0;
err_enable_qp:
@@ -2936,12 +2967,19 @@ static int virtnet_close(struct net_device *dev)
disable_delayed_refill(vi);
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(>refill);
+ /* Make sure config notification doesn't schedule config work */
+ virtio_config_driver_disable(vi->vdev);
+ /* Make sure status updating is cancelled */
+ cancel_work_sync(>config_work);
for (i = 0; i < vi->max_queue_pairs; i++) {
virtnet_disable_queue_pair(vi, i);
virtnet_cancel_dim(vi, >rq[i].dim);
}
+ vi->status &= ~VIRTIO_NET_S_LINK_UP;
+ netif_carrier_off(dev);
+
return 0;
}
@@ -4640,25 +4678,6 @@ static void virtnet_init_settings(struct net_device *dev)
vi->duplex = DUPLEX_UNKNOWN;
}
-static void virtnet_update_settings(struct virtnet_info *vi)
-{
- u32 speed;
- u8 duplex;
-
- if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
- return;
-
- virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
-
- if (ethtool_validate_speed(speed))
- vi->speed = speed;
-
- virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
-
- if (ethtool_validate_duplex(duplex))
- vi->duplex = duplex;
-}
-
static u32 virtnet_get_rxfh_key_size(struct net_device *dev)
{
return ((struct virtnet_info *)netdev_priv(dev))->rss_key_size;
@@ -6000,13 +6019,6 @@ static int virtnet_probe(struct virtio_device *vdev)
/* Assume link up if device can't report link status,
otherwise get link status from config. */
netif_carrier_off(dev);
- if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
- schedule_work(>config_work);
- } else {
- vi->status = VIRTIO_NET_S_LINK_UP;
- virtnet_update_settings(vi);
- netif_carrier_on(dev);
- }
for (i = 0; i < ARRAY_SIZE(guest_offloads); i++)
if (virtio_has_feature(vi->vdev, guest_offloads[i]))
--
2.31.1
[PATCH net-next v3 0/3] virtio-net: synchronize op/admin state
Hi All: This series tries to synchronize the operstate with the admin state which allows the lower virtio-net to propagate the link status to the upper devices like macvlan. This is done by toggling carrier during ndo_open/stop. Changes since V2: - introduce config_driver_disabled and helpers - schedule config change work unconditionally Jason Wang (3): virtio: rename virtio_config_enabled to virtio_config_core_enabled virtio: allow driver to disable the configure change notification virtio-net: synchronize operstate with admin state on up/down drivers/net/virtio_net.c | 64 drivers/virtio/virtio.c | 59 include/linux/virtio.h | 11 +-- 3 files changed, 93 insertions(+), 41 deletions(-) -- 2.31.1
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Wed, Jun 26, 2024 at 09:58:32AM +0800, Jason Wang wrote: > On Tue, Jun 25, 2024 at 4:32 PM Michael S. Tsirkin wrote: > > > > On Tue, Jun 25, 2024 at 04:11:05PM +0800, Jason Wang wrote: > > > On Tue, Jun 25, 2024 at 3:57 PM Michael S. Tsirkin > > > wrote: > > > > > > > > On Tue, Jun 25, 2024 at 03:46:44PM +0800, Jason Wang wrote: > > > > > Workqueue is used to serialize those so we won't lose any change. > > > > > > > > So we don't need to re-read then? > > > > > > > > > > We might have to re-read but I don't get why it is a problem for us. > > > > > > Thanks > > > > I don't think each ethtool command should force a full config read, > > is what I mean. Only do it if really needed. > > We don't, as we will check config_pending there. > > Thanks And config_pending set from an interrupt? That's fine. But it's not what this patch does, right? > > > > -- > > MST > >
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 4:32 PM Michael S. Tsirkin wrote: > > On Tue, Jun 25, 2024 at 04:11:05PM +0800, Jason Wang wrote: > > On Tue, Jun 25, 2024 at 3:57 PM Michael S. Tsirkin wrote: > > > > > > On Tue, Jun 25, 2024 at 03:46:44PM +0800, Jason Wang wrote: > > > > Workqueue is used to serialize those so we won't lose any change. > > > > > > So we don't need to re-read then? > > > > > > > We might have to re-read but I don't get why it is a problem for us. > > > > Thanks > > I don't think each ethtool command should force a full config read, > is what I mean. Only do it if really needed. We don't, as we will check config_pending there. Thanks > > -- > MST >
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 04:11:05PM +0800, Jason Wang wrote: > On Tue, Jun 25, 2024 at 3:57 PM Michael S. Tsirkin wrote: > > > > On Tue, Jun 25, 2024 at 03:46:44PM +0800, Jason Wang wrote: > > > Workqueue is used to serialize those so we won't lose any change. > > > > So we don't need to re-read then? > > > > We might have to re-read but I don't get why it is a problem for us. > > Thanks I don't think each ethtool command should force a full config read, is what I mean. Only do it if really needed. -- MST
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 3:57 PM Michael S. Tsirkin wrote: > > On Tue, Jun 25, 2024 at 03:46:44PM +0800, Jason Wang wrote: > > Workqueue is used to serialize those so we won't lose any change. > > So we don't need to re-read then? > We might have to re-read but I don't get why it is a problem for us. Thanks
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 03:46:44PM +0800, Jason Wang wrote: > Workqueue is used to serialize those so we won't lose any change. So we don't need to re-read then?
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 3:16 PM Michael S. Tsirkin wrote:
>
> On Tue, Jun 25, 2024 at 09:27:38AM +0800, Jason Wang wrote:
> > On Mon, Jun 24, 2024 at 6:07 PM Michael S. Tsirkin wrote:
> > >
> > > On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> > > > This patch synchronize operstate with admin state per RFC2863.
> > > >
> > > > This is done by trying to toggle the carrier upon open/close and
> > > > synchronize with the config change work. This allows propagate status
> > > > correctly to stacked devices like:
> > > >
> > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > ip link set link enp0s3 down
> > > > ip link show
> > > >
> > > > Before this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ..
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > >
> > > > After this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ...
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > >
> > > > Cc: Venkat Venkatsubra
> > > > Cc: Gia-Khanh Nguyen
> > > > Signed-off-by: Jason Wang
> > > > ---
> > > > drivers/net/virtio_net.c | 72 +++-
> > > > 1 file changed, 42 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index b1f8b720733e..eff3ad3d6bcc 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2468,6 +2468,25 @@ static int virtnet_enable_queue_pair(struct
> > > > virtnet_info *vi, int qp_index)
> > > > return err;
> > > > }
> > > >
> > > > +static void virtnet_update_settings(struct virtnet_info *vi)
> > > > +{
> > > > + u32 speed;
> > > > + u8 duplex;
> > > > +
> > > > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > > > + return;
> > > > +
> > > > + virtio_cread_le(vi->vdev, struct virtio_net_config, speed,
> > > > );
> > > > +
> > > > + if (ethtool_validate_speed(speed))
> > > > + vi->speed = speed;
> > > > +
> > > > + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex,
> > > > );
> > > > +
> > > > + if (ethtool_validate_duplex(duplex))
> > > > + vi->duplex = duplex;
> > > > +}
> > > > +
> > > > static int virtnet_open(struct net_device *dev)
> > > > {
> > > > struct virtnet_info *vi = netdev_priv(dev);
> > > > @@ -2486,6 +2505,22 @@ static int virtnet_open(struct net_device *dev)
> > > > goto err_enable_qp;
> > > > }
> > > >
> > > > + /* Assume link up if device can't report link status,
> > > > +otherwise get link status from config. */
> > > > + netif_carrier_off(dev);
> > > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> > > > + virtio_config_enable(vi->vdev);
> > > > + /* We are not sure if config interrupt is disabled by
> > > > + * core or not, so we can't schedule config_work by
> > > > + * ourselves.
> > > > + */
> > >
> > > This comment confuses more than it explains.
> > > You seem to be arguing about some alternative design
> > > you had in mind, but readers don't have it in mind.
> > >
> > >
> > > Please just explain what this does and why.
> > > For what: something like "Trigger re-read of config - same
> > > as we'd do if config
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Tue, Jun 25, 2024 at 09:27:38AM +0800, Jason Wang wrote:
> On Mon, Jun 24, 2024 at 6:07 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> > > This patch synchronize operstate with admin state per RFC2863.
> > >
> > > This is done by trying to toggle the carrier upon open/close and
> > > synchronize with the config change work. This allows propagate status
> > > correctly to stacked devices like:
> > >
> > > ip link add link enp0s3 macvlan0 type macvlan
> > > ip link set link enp0s3 down
> > > ip link show
> > >
> > > Before this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ..
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > After this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ...
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > Cc: Venkat Venkatsubra
> > > Cc: Gia-Khanh Nguyen
> > > Signed-off-by: Jason Wang
> > > ---
> > > drivers/net/virtio_net.c | 72 +++-
> > > 1 file changed, 42 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index b1f8b720733e..eff3ad3d6bcc 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -2468,6 +2468,25 @@ static int virtnet_enable_queue_pair(struct
> > > virtnet_info *vi, int qp_index)
> > > return err;
> > > }
> > >
> > > +static void virtnet_update_settings(struct virtnet_info *vi)
> > > +{
> > > + u32 speed;
> > > + u8 duplex;
> > > +
> > > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > > + return;
> > > +
> > > + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> > > +
> > > + if (ethtool_validate_speed(speed))
> > > + vi->speed = speed;
> > > +
> > > + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex,
> > > );
> > > +
> > > + if (ethtool_validate_duplex(duplex))
> > > + vi->duplex = duplex;
> > > +}
> > > +
> > > static int virtnet_open(struct net_device *dev)
> > > {
> > > struct virtnet_info *vi = netdev_priv(dev);
> > > @@ -2486,6 +2505,22 @@ static int virtnet_open(struct net_device *dev)
> > > goto err_enable_qp;
> > > }
> > >
> > > + /* Assume link up if device can't report link status,
> > > +otherwise get link status from config. */
> > > + netif_carrier_off(dev);
> > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> > > + virtio_config_enable(vi->vdev);
> > > + /* We are not sure if config interrupt is disabled by
> > > + * core or not, so we can't schedule config_work by
> > > + * ourselves.
> > > + */
> >
> > This comment confuses more than it explains.
> > You seem to be arguing about some alternative design
> > you had in mind, but readers don't have it in mind.
> >
> >
> > Please just explain what this does and why.
> > For what: something like "Trigger re-read of config - same
> > as we'd do if config changed".
> >
> > Now, please do what you don't do here: explain the why:
> >
> >
> > why do we want all these VM
> > exits on each open/close as opposed to once on probe and later on
> > config changed interrupt.
>
> Fine, the main reason is that a config interrupt might be pending
> during ifdown and core may disable configure interrupt due to several
> reasons.
>
> Thanks
If the config changes exactly as command is executing?
Then we'll get an interrupt later and u
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Mon, Jun 24, 2024 at 6:07 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> > This patch synchronize operstate with admin state per RFC2863.
> >
> > This is done by trying to toggle the carrier upon open/close and
> > synchronize with the config change work. This allows propagate status
> > correctly to stacked devices like:
> >
> > ip link add link enp0s3 macvlan0 type macvlan
> > ip link set link enp0s3 down
> > ip link show
> >
> > Before this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ..
> > 5: macvlan0@enp0s3: mtu 1500 qdisc
> > noqueue state UP mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > After this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ...
> > 5: macvlan0@enp0s3: mtu 1500
> > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > Cc: Venkat Venkatsubra
> > Cc: Gia-Khanh Nguyen
> > Signed-off-by: Jason Wang
> > ---
> > drivers/net/virtio_net.c | 72 +++-
> > 1 file changed, 42 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index b1f8b720733e..eff3ad3d6bcc 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -2468,6 +2468,25 @@ static int virtnet_enable_queue_pair(struct
> > virtnet_info *vi, int qp_index)
> > return err;
> > }
> >
> > +static void virtnet_update_settings(struct virtnet_info *vi)
> > +{
> > + u32 speed;
> > + u8 duplex;
> > +
> > + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> > + return;
> > +
> > + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> > +
> > + if (ethtool_validate_speed(speed))
> > + vi->speed = speed;
> > +
> > + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> > +
> > + if (ethtool_validate_duplex(duplex))
> > + vi->duplex = duplex;
> > +}
> > +
> > static int virtnet_open(struct net_device *dev)
> > {
> > struct virtnet_info *vi = netdev_priv(dev);
> > @@ -2486,6 +2505,22 @@ static int virtnet_open(struct net_device *dev)
> > goto err_enable_qp;
> > }
> >
> > + /* Assume link up if device can't report link status,
> > +otherwise get link status from config. */
> > + netif_carrier_off(dev);
> > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> > + virtio_config_enable(vi->vdev);
> > + /* We are not sure if config interrupt is disabled by
> > + * core or not, so we can't schedule config_work by
> > + * ourselves.
> > + */
>
> This comment confuses more than it explains.
> You seem to be arguing about some alternative design
> you had in mind, but readers don't have it in mind.
>
>
> Please just explain what this does and why.
> For what: something like "Trigger re-read of config - same
> as we'd do if config changed".
>
> Now, please do what you don't do here: explain the why:
>
>
> why do we want all these VM
> exits on each open/close as opposed to once on probe and later on
> config changed interrupt.
Fine, the main reason is that a config interrupt might be pending
during ifdown and core may disable configure interrupt due to several
reasons.
Thanks
>
>
> > + virtio_config_changed(vi->vdev);
> > + } else {
> > + vi->status = VIRTIO_NET_S_LINK_UP;
> > + virtnet_update_settings(vi);
> > + netif_carrier_on(dev);
> > + }
> > +
> > return 0;
> >
> > err_enable_qp:
> > @@ -2928,12 +2963,19 @@ static int virtnet_close(struct net_device *dev)
> > disable_delayed_refill(vi);
> > /* Make sure refill_work doesn't re-enable napi! */
> > cancel_delayed_work_sync(>refill);
> > + /* Make sure config notification doesn't schedule config work */
> > + virtio_config_disable(vi->vdev);
> &g
Re: [PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
> ip link add link enp0s3 macvlan0 type macvlan
> ip link set link enp0s3 down
> ip link show
>
> Before this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ..
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> After this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ...
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> Cc: Venkat Venkatsubra
> Cc: Gia-Khanh Nguyen
> Signed-off-by: Jason Wang
> ---
> drivers/net/virtio_net.c | 72 +++-
> 1 file changed, 42 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index b1f8b720733e..eff3ad3d6bcc 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2468,6 +2468,25 @@ static int virtnet_enable_queue_pair(struct
> virtnet_info *vi, int qp_index)
> return err;
> }
>
> +static void virtnet_update_settings(struct virtnet_info *vi)
> +{
> + u32 speed;
> + u8 duplex;
> +
> + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> + return;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> +
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> +
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -2486,6 +2505,22 @@ static int virtnet_open(struct net_device *dev)
> goto err_enable_qp;
> }
>
> + /* Assume link up if device can't report link status,
> +otherwise get link status from config. */
> + netif_carrier_off(dev);
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> + virtio_config_enable(vi->vdev);
> + /* We are not sure if config interrupt is disabled by
> + * core or not, so we can't schedule config_work by
> + * ourselves.
> + */
This comment confuses more than it explains.
You seem to be arguing about some alternative design
you had in mind, but readers don't have it in mind.
Please just explain what this does and why.
For what: something like "Trigger re-read of config - same
as we'd do if config changed".
Now, please do what you don't do here: explain the why:
why do we want all these VM
exits on each open/close as opposed to once on probe and later on
config changed interrupt.
> + virtio_config_changed(vi->vdev);
> + } else {
> + vi->status = VIRTIO_NET_S_LINK_UP;
> + virtnet_update_settings(vi);
> + netif_carrier_on(dev);
> + }
> +
> return 0;
>
> err_enable_qp:
> @@ -2928,12 +2963,19 @@ static int virtnet_close(struct net_device *dev)
> disable_delayed_refill(vi);
> /* Make sure refill_work doesn't re-enable napi! */
> cancel_delayed_work_sync(>refill);
> + /* Make sure config notification doesn't schedule config work */
> + virtio_config_disable(vi->vdev);
> + /* Make sure status updating is cancelled */
> + cancel_work_sync(>config_work);
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_disable_queue_pair(vi, i);
> cancel_work_sync(>rq[i].dim.work);
> }
>
> + vi->status &= ~VIRTIO_NET_S_LINK_UP;
> + netif_carrier_off(dev);
> +
> return 0;
> }
>
> @@ -4632,25 +4674,6 @@ static void virtnet_init_settings(struct net_device
> *dev)
> vi->duplex = DUPLEX_UNKNOWN;
> }
>
> -static void virtnet_update_settings(struct virtnet_info *vi)
> -{
> - u32 speed;
> - u8 duplex;
> -
> - if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
[PATCH V2 3/3] virtio-net: synchronize operstate with admin state on up/down
This patch synchronize operstate with admin state per RFC2863.
This is done by trying to toggle the carrier upon open/close and
synchronize with the config change work. This allows propagate status
correctly to stacked devices like:
ip link add link enp0s3 macvlan0 type macvlan
ip link set link enp0s3 down
ip link show
Before this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
..
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
After this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
...
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
Cc: Venkat Venkatsubra
Cc: Gia-Khanh Nguyen
Signed-off-by: Jason Wang
---
drivers/net/virtio_net.c | 72 +++-
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b1f8b720733e..eff3ad3d6bcc 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2468,6 +2468,25 @@ static int virtnet_enable_queue_pair(struct virtnet_info
*vi, int qp_index)
return err;
}
+static void virtnet_update_settings(struct virtnet_info *vi)
+{
+ u32 speed;
+ u8 duplex;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
+ return;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
+
+ if (ethtool_validate_speed(speed))
+ vi->speed = speed;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
+
+ if (ethtool_validate_duplex(duplex))
+ vi->duplex = duplex;
+}
+
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -2486,6 +2505,22 @@ static int virtnet_open(struct net_device *dev)
goto err_enable_qp;
}
+ /* Assume link up if device can't report link status,
+ otherwise get link status from config. */
+ netif_carrier_off(dev);
+ if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
+ virtio_config_enable(vi->vdev);
+ /* We are not sure if config interrupt is disabled by
+* core or not, so we can't schedule config_work by
+* ourselves.
+*/
+ virtio_config_changed(vi->vdev);
+ } else {
+ vi->status = VIRTIO_NET_S_LINK_UP;
+ virtnet_update_settings(vi);
+ netif_carrier_on(dev);
+ }
+
return 0;
err_enable_qp:
@@ -2928,12 +2963,19 @@ static int virtnet_close(struct net_device *dev)
disable_delayed_refill(vi);
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(>refill);
+ /* Make sure config notification doesn't schedule config work */
+ virtio_config_disable(vi->vdev);
+ /* Make sure status updating is cancelled */
+ cancel_work_sync(>config_work);
for (i = 0; i < vi->max_queue_pairs; i++) {
virtnet_disable_queue_pair(vi, i);
cancel_work_sync(>rq[i].dim.work);
}
+ vi->status &= ~VIRTIO_NET_S_LINK_UP;
+ netif_carrier_off(dev);
+
return 0;
}
@@ -4632,25 +4674,6 @@ static void virtnet_init_settings(struct net_device *dev)
vi->duplex = DUPLEX_UNKNOWN;
}
-static void virtnet_update_settings(struct virtnet_info *vi)
-{
- u32 speed;
- u8 duplex;
-
- if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
- return;
-
- virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
-
- if (ethtool_validate_speed(speed))
- vi->speed = speed;
-
- virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
-
- if (ethtool_validate_duplex(duplex))
- vi->duplex = duplex;
-}
-
static u32 virtnet_get_rxfh_key_size(struct net_device *dev)
{
return ((struct virtnet_info *)netdev_priv(dev))->rss_key_size;
@@ -5958,17 +5981,6 @@ static int virtnet_probe(struct virtio_device *vdev)
goto free_unregister_netdev;
}
- /* Assume link up if device can't report link status,
- otherwise get link status from config. */
- netif_carrier_off(dev);
- if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
- schedule_work(>config_work);
- } else {
- vi->status = VIRTIO_NET_S_LINK_UP;
- virtnet_update_settings(vi);
- netif_
[PATCH V2 0/3] virtio-net: synchronize operstate with admin state on up/down
Hi All:
Currently, we don't synchronize the opersteate with the admin state
currently when prevent the link status to be propagated to the stacked
device on top of the virtio-net.
This patch fixes this issue.
Changes since V1:
- Try to reuse the virtio core facility to enable and disable the
configure interrupt
Jason Wang (3):
virtio: allow nested disabling of the configure interrupt
virtio: export virtio_config_{enable|disable}()
virtio-net: synchronize operstate with admin state on up/down
drivers/net/virtio_net.c | 72 +++-
drivers/virtio/virtio.c | 26 ++-
include/linux/virtio.h | 5 ++-
3 files changed, 63 insertions(+), 40 deletions(-)
--
2.31.1
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, Jun 20, 2024 at 1:58 PM Michael S. Tsirkin wrote:
>
> On Thu, Jun 06, 2024 at 08:22:13AM +0800, Jason Wang wrote:
> > On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
> > >
> > > On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > > > > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin
> > > > > wrote:
> > > > > >
> > > > > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > > > > This patch synchronize operstate with admin state per RFC2863.
> > > > > > >
> > > > > > > This is done by trying to toggle the carrier upon open/close and
> > > > > > > synchronize with the config change work. This allows propagate
> > > > > > > status
> > > > > > > correctly to stacked devices like:
> > > > > > >
> > > > > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > > > > ip link set link enp0s3 down
> > > > > > > ip link show
> > > > > > >
> > > > > > > Before this patch:
> > > > > > >
> > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > > ..
> > > > > > > 5: macvlan0@enp0s3: mtu
> > > > > > > 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > > >
> > > > > > > After this patch:
> > > > > > >
> > > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > > ...
> > > > > > > 5: macvlan0@enp0s3:
> > > > > > > mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group
> > > > > > > default qlen 1000
> > > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > > >
> > > > > > > Cc: Venkat Venkatsubra
> > > > > > > Cc: Gia-Khanh Nguyen
> > > > > > > Reviewed-by: Xuan Zhuo
> > > > > > > Acked-by: Michael S. Tsirkin
> > > > > > > Signed-off-by: Jason Wang
> > > > > > > ---
> > > > > > > Changes since V1:
> > > > > > > - rebase
> > > > > > > - add ack/review tags
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > ---
> > > > > > > drivers/net/virtio_net.c | 94
> > > > > > > +++-
> > > > > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > > > > --- a/drivers/net/virtio_net.c
> > > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > > > > /* The lock to synchronize the access to refill_enabled */
> > > > > > > spinlock_t refill_lock;
> > > > > > >
> > > > > > > + /* Is config change enabled? */
> > > > > > > + bool config_change_enabled;
> > > > > > > +
> > > > > > > + /* The lock to synchronize the access to
> > > > > > > config_change_enabled */
> > > > > > > + spinlock_t config_change_lock;
> > > > > > > +
> > > > > > > /* Work struct for config space updates */
> > > > > > > struct work_struct config_work;
> > > > > > >
> > > > > >
> > > > > >
> > > > > > But we already have dev->config_loc
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, Jun 06, 2024 at 08:22:13AM +0800, Jason Wang wrote:
> On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
> >
> > On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin wrote:
> > >
> > > On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > > > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin
> > > > wrote:
> > > > >
> > > > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > > > This patch synchronize operstate with admin state per RFC2863.
> > > > > >
> > > > > > This is done by trying to toggle the carrier upon open/close and
> > > > > > synchronize with the config change work. This allows propagate
> > > > > > status
> > > > > > correctly to stacked devices like:
> > > > > >
> > > > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > > > ip link set link enp0s3 down
> > > > > > ip link show
> > > > > >
> > > > > > Before this patch:
> > > > > >
> > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > ..
> > > > > > 5: macvlan0@enp0s3: mtu
> > > > > > 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > >
> > > > > > After this patch:
> > > > > >
> > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > ...
> > > > > > 5: macvlan0@enp0s3: mtu
> > > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default
> > > > > > qlen 1000
> > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > >
> > > > > > Cc: Venkat Venkatsubra
> > > > > > Cc: Gia-Khanh Nguyen
> > > > > > Reviewed-by: Xuan Zhuo
> > > > > > Acked-by: Michael S. Tsirkin
> > > > > > Signed-off-by: Jason Wang
> > > > > > ---
> > > > > > Changes since V1:
> > > > > > - rebase
> > > > > > - add ack/review tags
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > ---
> > > > > > drivers/net/virtio_net.c | 94
> > > > > > +++-
> > > > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > > > --- a/drivers/net/virtio_net.c
> > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > > > /* The lock to synchronize the access to refill_enabled */
> > > > > > spinlock_t refill_lock;
> > > > > >
> > > > > > + /* Is config change enabled? */
> > > > > > + bool config_change_enabled;
> > > > > > +
> > > > > > + /* The lock to synchronize the access to
> > > > > > config_change_enabled */
> > > > > > + spinlock_t config_change_lock;
> > > > > > +
> > > > > > /* Work struct for config space updates */
> > > > > > struct work_struct config_work;
> > > > > >
> > > > >
> > > > >
> > > > > But we already have dev->config_lock and dev->config_enabled.
> > > > >
> > > > > And it actually works better - instead of discarding config
> > > > > change events it defers them until enabled.
> > > > >
> > > >
> > > > Yes but then both virtio-net driver and virtio core can ask to enable
> > > > and disable and then we need some kind of synchronization which is
> > > > non-trivial.
> > >
> > > We
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, Jun 6, 2024 at 8:22 AM Jason Wang wrote:
>
> On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
> >
> > On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin wrote:
> > >
> > > On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > > > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin
> > > > wrote:
> > > > >
> > > > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > > > This patch synchronize operstate with admin state per RFC2863.
> > > > > >
> > > > > > This is done by trying to toggle the carrier upon open/close and
> > > > > > synchronize with the config change work. This allows propagate
> > > > > > status
> > > > > > correctly to stacked devices like:
> > > > > >
> > > > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > > > ip link set link enp0s3 down
> > > > > > ip link show
> > > > > >
> > > > > > Before this patch:
> > > > > >
> > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > ..
> > > > > > 5: macvlan0@enp0s3: mtu
> > > > > > 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > >
> > > > > > After this patch:
> > > > > >
> > > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state
> > > > > > DOWN mode DEFAULT group default qlen 1000
> > > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > > ...
> > > > > > 5: macvlan0@enp0s3: mtu
> > > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default
> > > > > > qlen 1000
> > > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > > >
> > > > > > Cc: Venkat Venkatsubra
> > > > > > Cc: Gia-Khanh Nguyen
> > > > > > Reviewed-by: Xuan Zhuo
> > > > > > Acked-by: Michael S. Tsirkin
> > > > > > Signed-off-by: Jason Wang
> > > > > > ---
> > > > > > Changes since V1:
> > > > > > - rebase
> > > > > > - add ack/review tags
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > ---
> > > > > > drivers/net/virtio_net.c | 94
> > > > > > +++-
> > > > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > > > --- a/drivers/net/virtio_net.c
> > > > > > +++ b/drivers/net/virtio_net.c
> > > > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > > > /* The lock to synchronize the access to refill_enabled */
> > > > > > spinlock_t refill_lock;
> > > > > >
> > > > > > + /* Is config change enabled? */
> > > > > > + bool config_change_enabled;
> > > > > > +
> > > > > > + /* The lock to synchronize the access to
> > > > > > config_change_enabled */
> > > > > > + spinlock_t config_change_lock;
> > > > > > +
> > > > > > /* Work struct for config space updates */
> > > > > > struct work_struct config_work;
> > > > > >
> > > > >
> > > > >
> > > > > But we already have dev->config_lock and dev->config_enabled.
> > > > >
> > > > > And it actually works better - instead of discarding config
> > > > > change events it defers them until enabled.
> > > > >
> > > >
> > > > Yes but then both virtio-net driver and virtio core can ask to enable
> > > > and disable and then we need some kind of synchronization which is
> > > > non-trivial.
> > >
> > > Well for core it happens on bring up path before driver works
> > > and later on tear down after it is gone.
> > > So I do not think they ever do it at the same time.
> >
> > For example, there could be a suspend/resume when the admin state is down.
> >
> > >
> > >
> > > > And device enabling on the core is different from bringing the device
> > > > up in the networking subsystem. Here we just delay to deal with the
> > > > config change interrupt on ndo_open(). (E.g try to ack announce is
> > > > meaningless when the device is down).
> > > >
> > > > Thanks
> > >
> > > another thing is that it is better not to re-read all config
> > > on link up if there was no config interrupt - less vm exits.
> >
> > Yes, but it should not matter much as it's done in the ndo_open().
>
> Michael, any more comments on this?
Gentle ping.
Thanks
>
> Please confirm if this patch is ok or not. If you prefer to reuse the
> config_disable() I can change it from a boolean to a counter that
> allows to be nested.
>
> Thanks
>
> >
> > Thanks
> >
> > >
> > > --
> > > MST
> > >
Re: [PATCH v5 7/8] Docs/admin-guide/mm/damon/usage: add missing actions
Hi Honggyu, On Thu, 13 Jun 2024 22:20:54 +0900 Honggyu Kim wrote: > "lru_prio" and "lru_deprio" are missing in the damos action list so they > have to be added properly at damon usage document. > > Signed-off-by: Honggyu Kim > --- > Documentation/admin-guide/mm/damon/usage.rst | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/mm/damon/usage.rst > b/Documentation/admin-guide/mm/damon/usage.rst > index e58ceb89ea2a..7bff54963975 100644 > --- a/Documentation/admin-guide/mm/damon/usage.rst > +++ b/Documentation/admin-guide/mm/damon/usage.rst > @@ -757,7 +757,9 @@ list on :ref:`design doc `. > - 2: ``pageout`` > - 3: ``hugepage`` > - 4: ``nohugepage`` > - - 5: ``stat`` > + - 5: ``lru_prio`` > + - 6: ``lru_deprio`` > + - 7: ``stat`` This section is for DAMON debugfs interface, which is deprecated. After the deprecation, we stopped supporting new DAMOS actions. This section is not documenting lru_[de]prio for the reason. I think this patch is not needed. Please let me know if I'm missing something, though. Thanks, SJ [...]
[PATCH v5 7/8] Docs/admin-guide/mm/damon/usage: add missing actions
"lru_prio" and "lru_deprio" are missing in the damos action list so they have to be added properly at damon usage document. Signed-off-by: Honggyu Kim --- Documentation/admin-guide/mm/damon/usage.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index e58ceb89ea2a..7bff54963975 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -757,7 +757,9 @@ list on :ref:`design doc `. - 2: ``pageout`` - 3: ``hugepage`` - 4: ``nohugepage`` - - 5: ``stat`` + - 5: ``lru_prio`` + - 6: ``lru_deprio`` + - 7: ``stat`` Quota ~ -- 2.34.1
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Fri, May 31, 2024 at 8:18 AM Jason Wang wrote:
>
> On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin wrote:
> >
> > On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > > This patch synchronize operstate with admin state per RFC2863.
> > > > >
> > > > > This is done by trying to toggle the carrier upon open/close and
> > > > > synchronize with the config change work. This allows propagate status
> > > > > correctly to stacked devices like:
> > > > >
> > > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > > ip link set link enp0s3 down
> > > > > ip link show
> > > > >
> > > > > Before this patch:
> > > > >
> > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > > mode DEFAULT group default qlen 1000
> > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > ..
> > > > > 5: macvlan0@enp0s3: mtu 1500
> > > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > >
> > > > > After this patch:
> > > > >
> > > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > > mode DEFAULT group default qlen 1000
> > > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > > ...
> > > > > 5: macvlan0@enp0s3: mtu
> > > > > 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default
> > > > > qlen 1000
> > > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > > >
> > > > > Cc: Venkat Venkatsubra
> > > > > Cc: Gia-Khanh Nguyen
> > > > > Reviewed-by: Xuan Zhuo
> > > > > Acked-by: Michael S. Tsirkin
> > > > > Signed-off-by: Jason Wang
> > > > > ---
> > > > > Changes since V1:
> > > > > - rebase
> > > > > - add ack/review tags
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > ---
> > > > > drivers/net/virtio_net.c | 94
> > > > > +++-
> > > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > > --- a/drivers/net/virtio_net.c
> > > > > +++ b/drivers/net/virtio_net.c
> > > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > > /* The lock to synchronize the access to refill_enabled */
> > > > > spinlock_t refill_lock;
> > > > >
> > > > > + /* Is config change enabled? */
> > > > > + bool config_change_enabled;
> > > > > +
> > > > > + /* The lock to synchronize the access to config_change_enabled
> > > > > */
> > > > > + spinlock_t config_change_lock;
> > > > > +
> > > > > /* Work struct for config space updates */
> > > > > struct work_struct config_work;
> > > > >
> > > >
> > > >
> > > > But we already have dev->config_lock and dev->config_enabled.
> > > >
> > > > And it actually works better - instead of discarding config
> > > > change events it defers them until enabled.
> > > >
> > >
> > > Yes but then both virtio-net driver and virtio core can ask to enable
> > > and disable and then we need some kind of synchronization which is
> > > non-trivial.
> >
> > Well for core it happens on bring up path before driver works
> > and later on tear down after it is gone.
> > So I do not think they ever do it at the same time.
>
> For example, there could be a suspend/resume when the admin state is down.
>
> >
> >
> > > And device enabling on the core is different from bringing the device
> > > up in the networking subsystem. Here we just delay to deal with the
> > > config change interrupt on ndo_open(). (E.g try to ack announce is
> > > meaningless when the device is down).
> > >
> > > Thanks
> >
> > another thing is that it is better not to re-read all config
> > on link up if there was no config interrupt - less vm exits.
>
> Yes, but it should not matter much as it's done in the ndo_open().
Michael, any more comments on this?
Please confirm if this patch is ok or not. If you prefer to reuse the
config_disable() I can change it from a boolean to a counter that
allows to be nested.
Thanks
>
> Thanks
>
> >
> > --
> > MST
> >
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, May 30, 2024 at 9:09 PM Michael S. Tsirkin wrote:
>
> On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> > On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin wrote:
> > >
> > > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > > This patch synchronize operstate with admin state per RFC2863.
> > > >
> > > > This is done by trying to toggle the carrier upon open/close and
> > > > synchronize with the config change work. This allows propagate status
> > > > correctly to stacked devices like:
> > > >
> > > > ip link add link enp0s3 macvlan0 type macvlan
> > > > ip link set link enp0s3 down
> > > > ip link show
> > > >
> > > > Before this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ..
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > >
> > > > After this patch:
> > > >
> > > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > > mode DEFAULT group default qlen 1000
> > > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > > ...
> > > > 5: macvlan0@enp0s3: mtu 1500
> > > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > > >
> > > > Cc: Venkat Venkatsubra
> > > > Cc: Gia-Khanh Nguyen
> > > > Reviewed-by: Xuan Zhuo
> > > > Acked-by: Michael S. Tsirkin
> > > > Signed-off-by: Jason Wang
> > > > ---
> > > > Changes since V1:
> > > > - rebase
> > > > - add ack/review tags
> > >
> > >
> > >
> > >
> > >
> > > > ---
> > > > drivers/net/virtio_net.c | 94 +++-
> > > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > > /* The lock to synchronize the access to refill_enabled */
> > > > spinlock_t refill_lock;
> > > >
> > > > + /* Is config change enabled? */
> > > > + bool config_change_enabled;
> > > > +
> > > > + /* The lock to synchronize the access to config_change_enabled */
> > > > + spinlock_t config_change_lock;
> > > > +
> > > > /* Work struct for config space updates */
> > > > struct work_struct config_work;
> > > >
> > >
> > >
> > > But we already have dev->config_lock and dev->config_enabled.
> > >
> > > And it actually works better - instead of discarding config
> > > change events it defers them until enabled.
> > >
> >
> > Yes but then both virtio-net driver and virtio core can ask to enable
> > and disable and then we need some kind of synchronization which is
> > non-trivial.
>
> Well for core it happens on bring up path before driver works
> and later on tear down after it is gone.
> So I do not think they ever do it at the same time.
For example, there could be a suspend/resume when the admin state is down.
>
>
> > And device enabling on the core is different from bringing the device
> > up in the networking subsystem. Here we just delay to deal with the
> > config change interrupt on ndo_open(). (E.g try to ack announce is
> > meaningless when the device is down).
> >
> > Thanks
>
> another thing is that it is better not to re-read all config
> on link up if there was no config interrupt - less vm exits.
Yes, but it should not matter much as it's done in the ndo_open().
Thanks
>
> --
> MST
>
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, May 30, 2024 at 06:29:51PM +0800, Jason Wang wrote:
> On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin wrote:
> >
> > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > This patch synchronize operstate with admin state per RFC2863.
> > >
> > > This is done by trying to toggle the carrier upon open/close and
> > > synchronize with the config change work. This allows propagate status
> > > correctly to stacked devices like:
> > >
> > > ip link add link enp0s3 macvlan0 type macvlan
> > > ip link set link enp0s3 down
> > > ip link show
> > >
> > > Before this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ..
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > After this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ...
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > Cc: Venkat Venkatsubra
> > > Cc: Gia-Khanh Nguyen
> > > Reviewed-by: Xuan Zhuo
> > > Acked-by: Michael S. Tsirkin
> > > Signed-off-by: Jason Wang
> > > ---
> > > Changes since V1:
> > > - rebase
> > > - add ack/review tags
> >
> >
> >
> >
> >
> > > ---
> > > drivers/net/virtio_net.c | 94 +++-
> > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > /* The lock to synchronize the access to refill_enabled */
> > > spinlock_t refill_lock;
> > >
> > > + /* Is config change enabled? */
> > > + bool config_change_enabled;
> > > +
> > > + /* The lock to synchronize the access to config_change_enabled */
> > > + spinlock_t config_change_lock;
> > > +
> > > /* Work struct for config space updates */
> > > struct work_struct config_work;
> > >
> >
> >
> > But we already have dev->config_lock and dev->config_enabled.
> >
> > And it actually works better - instead of discarding config
> > change events it defers them until enabled.
> >
>
> Yes but then both virtio-net driver and virtio core can ask to enable
> and disable and then we need some kind of synchronization which is
> non-trivial.
Well for core it happens on bring up path before driver works
and later on tear down after it is gone.
So I do not think they ever do it at the same time.
> And device enabling on the core is different from bringing the device
> up in the networking subsystem. Here we just delay to deal with the
> config change interrupt on ndo_open(). (E.g try to ack announce is
> meaningless when the device is down).
>
> Thanks
another thing is that it is better not to re-read all config
on link up if there was no config interrupt - less vm exits.
--
MST
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, May 30, 2024 at 6:29 PM Jason Wang wrote:
>
> On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin wrote:
> >
> > On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > > This patch synchronize operstate with admin state per RFC2863.
> > >
> > > This is done by trying to toggle the carrier upon open/close and
> > > synchronize with the config change work. This allows propagate status
> > > correctly to stacked devices like:
> > >
> > > ip link add link enp0s3 macvlan0 type macvlan
> > > ip link set link enp0s3 down
> > > ip link show
> > >
> > > Before this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ..
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state UP mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > After this patch:
> > >
> > > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN
> > > mode DEFAULT group default qlen 1000
> > > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > > ...
> > > 5: macvlan0@enp0s3: mtu 1500
> > > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> > >
> > > Cc: Venkat Venkatsubra
> > > Cc: Gia-Khanh Nguyen
> > > Reviewed-by: Xuan Zhuo
> > > Acked-by: Michael S. Tsirkin
> > > Signed-off-by: Jason Wang
> > > ---
> > > Changes since V1:
> > > - rebase
> > > - add ack/review tags
> >
> >
> >
> >
> >
> > > ---
> > > drivers/net/virtio_net.c | 94 +++-
> > > 1 file changed, 63 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 4a802c0ea2cb..69e4ae353c51 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -433,6 +433,12 @@ struct virtnet_info {
> > > /* The lock to synchronize the access to refill_enabled */
> > > spinlock_t refill_lock;
> > >
> > > + /* Is config change enabled? */
> > > + bool config_change_enabled;
> > > +
> > > + /* The lock to synchronize the access to config_change_enabled */
> > > + spinlock_t config_change_lock;
> > > +
> > > /* Work struct for config space updates */
> > > struct work_struct config_work;
> > >
> >
> >
> > But we already have dev->config_lock and dev->config_enabled.
> >
> > And it actually works better - instead of discarding config
> > change events it defers them until enabled.
> >
>
> Yes but then both virtio-net driver and virtio core can ask to enable
> and disable and then we need some kind of synchronization which is
> non-trivial.
>
> And device enabling on the core is different from bringing the device
> up in the networking subsystem. Here we just delay to deal with the
> config change interrupt on ndo_open(). (E.g try to ack announce is
> meaningless when the device is down).
Or maybe you meant to make config_enabled a nest counter?
Thanks
>
> Thanks
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, May 30, 2024 at 2:10 PM Michael S. Tsirkin wrote:
>
> On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> > This patch synchronize operstate with admin state per RFC2863.
> >
> > This is done by trying to toggle the carrier upon open/close and
> > synchronize with the config change work. This allows propagate status
> > correctly to stacked devices like:
> >
> > ip link add link enp0s3 macvlan0 type macvlan
> > ip link set link enp0s3 down
> > ip link show
> >
> > Before this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ..
> > 5: macvlan0@enp0s3: mtu 1500 qdisc
> > noqueue state UP mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > After this patch:
> >
> > 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> > DEFAULT group default qlen 1000
> > link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> > ...
> > 5: macvlan0@enp0s3: mtu 1500
> > qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> > link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
> >
> > Cc: Venkat Venkatsubra
> > Cc: Gia-Khanh Nguyen
> > Reviewed-by: Xuan Zhuo
> > Acked-by: Michael S. Tsirkin
> > Signed-off-by: Jason Wang
> > ---
> > Changes since V1:
> > - rebase
> > - add ack/review tags
>
>
>
>
>
> > ---
> > drivers/net/virtio_net.c | 94 +++-
> > 1 file changed, 63 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > index 4a802c0ea2cb..69e4ae353c51 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -433,6 +433,12 @@ struct virtnet_info {
> > /* The lock to synchronize the access to refill_enabled */
> > spinlock_t refill_lock;
> >
> > + /* Is config change enabled? */
> > + bool config_change_enabled;
> > +
> > + /* The lock to synchronize the access to config_change_enabled */
> > + spinlock_t config_change_lock;
> > +
> > /* Work struct for config space updates */
> > struct work_struct config_work;
> >
>
>
> But we already have dev->config_lock and dev->config_enabled.
>
> And it actually works better - instead of discarding config
> change events it defers them until enabled.
>
Yes but then both virtio-net driver and virtio core can ask to enable
and disable and then we need some kind of synchronization which is
non-trivial.
And device enabling on the core is different from bringing the device
up in the networking subsystem. Here we just delay to deal with the
config change interrupt on ndo_open(). (E.g try to ack announce is
meaningless when the device is down).
Thanks
Re: [PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
On Thu, May 30, 2024 at 11:20:55AM +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices like:
>
> ip link add link enp0s3 macvlan0 type macvlan
> ip link set link enp0s3 down
> ip link show
>
> Before this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ..
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state UP mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> After this patch:
>
> 3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
> DEFAULT group default qlen 1000
> link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
> ...
> 5: macvlan0@enp0s3: mtu 1500 qdisc
> noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
> link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
>
> Cc: Venkat Venkatsubra
> Cc: Gia-Khanh Nguyen
> Reviewed-by: Xuan Zhuo
> Acked-by: Michael S. Tsirkin
> Signed-off-by: Jason Wang
> ---
> Changes since V1:
> - rebase
> - add ack/review tags
> ---
> drivers/net/virtio_net.c | 94 +++-
> 1 file changed, 63 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4a802c0ea2cb..69e4ae353c51 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -433,6 +433,12 @@ struct virtnet_info {
> /* The lock to synchronize the access to refill_enabled */
> spinlock_t refill_lock;
>
> + /* Is config change enabled? */
> + bool config_change_enabled;
> +
> + /* The lock to synchronize the access to config_change_enabled */
> + spinlock_t config_change_lock;
> +
> /* Work struct for config space updates */
> struct work_struct config_work;
>
But we already have dev->config_lock and dev->config_enabled.
And it actually works better - instead of discarding config
change events it defers them until enabled.
> @@ -623,6 +629,20 @@ static void disable_delayed_refill(struct virtnet_info
> *vi)
> spin_unlock_bh(>refill_lock);
> }
>
> +static void enable_config_change(struct virtnet_info *vi)
> +{
> + spin_lock_irq(>config_change_lock);
> + vi->config_change_enabled = true;
> + spin_unlock_irq(>config_change_lock);
> +}
> +
> +static void disable_config_change(struct virtnet_info *vi)
> +{
> + spin_lock_irq(>config_change_lock);
> + vi->config_change_enabled = false;
> + spin_unlock_irq(>config_change_lock);
> +}
> +
> static void enable_rx_mode_work(struct virtnet_info *vi)
> {
> rtnl_lock();
> @@ -2421,6 +2441,25 @@ static int virtnet_enable_queue_pair(struct
> virtnet_info *vi, int qp_index)
> return err;
> }
>
> +static void virtnet_update_settings(struct virtnet_info *vi)
> +{
> + u32 speed;
> + u8 duplex;
> +
> + if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
> + return;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
> +
> + if (ethtool_validate_speed(speed))
> + vi->speed = speed;
> +
> + virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
> +
> + if (ethtool_validate_duplex(duplex))
> + vi->duplex = duplex;
> +}
> +
> static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> @@ -2439,6 +2478,18 @@ static int virtnet_open(struct net_device *dev)
> goto err_enable_qp;
> }
>
> + /* Assume link up if device can't report link status,
> +otherwise get link status from config. */
> + netif_carrier_off(dev);
> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
> + enable_config_change(vi);
> + schedule_work(>config_work);
> + } else {
> + vi->status = VIRTIO_NET_S_LINK_UP;
> + virtnet_update_settings(vi);
> + netif_carrier_on(dev);
> + }
> +
> return 0;
>
> err_enable_qp:
> @@ -2875,12 +2926,19 @@ static int virtnet_close(struct net_device *dev)
> disable_delayed_refill(vi);
> /* Make sure refill_work doesn't re-enable napi! */
> cancel_delayed_work_sync(>refill);
> + /* Make sure config notification doesn't schedule config
[PATCH net-next V2] virtio-net: synchronize operstate with admin state on up/down
This patch synchronize operstate with admin state per RFC2863.
This is done by trying to toggle the carrier upon open/close and
synchronize with the config change work. This allows propagate status
correctly to stacked devices like:
ip link add link enp0s3 macvlan0 type macvlan
ip link set link enp0s3 down
ip link show
Before this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
..
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
After this patch:
3: enp0s3: mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT group default qlen 1000
link/ether 00:00:05:00:00:09 brd ff:ff:ff:ff:ff:ff
...
5: macvlan0@enp0s3: mtu 1500 qdisc
noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
link/ether b2:a9:c5:04:da:53 brd ff:ff:ff:ff:ff:ff
Cc: Venkat Venkatsubra
Cc: Gia-Khanh Nguyen
Reviewed-by: Xuan Zhuo
Acked-by: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
Changes since V1:
- rebase
- add ack/review tags
---
drivers/net/virtio_net.c | 94 +++-
1 file changed, 63 insertions(+), 31 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4a802c0ea2cb..69e4ae353c51 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -433,6 +433,12 @@ struct virtnet_info {
/* The lock to synchronize the access to refill_enabled */
spinlock_t refill_lock;
+ /* Is config change enabled? */
+ bool config_change_enabled;
+
+ /* The lock to synchronize the access to config_change_enabled */
+ spinlock_t config_change_lock;
+
/* Work struct for config space updates */
struct work_struct config_work;
@@ -623,6 +629,20 @@ static void disable_delayed_refill(struct virtnet_info *vi)
spin_unlock_bh(>refill_lock);
}
+static void enable_config_change(struct virtnet_info *vi)
+{
+ spin_lock_irq(>config_change_lock);
+ vi->config_change_enabled = true;
+ spin_unlock_irq(>config_change_lock);
+}
+
+static void disable_config_change(struct virtnet_info *vi)
+{
+ spin_lock_irq(>config_change_lock);
+ vi->config_change_enabled = false;
+ spin_unlock_irq(>config_change_lock);
+}
+
static void enable_rx_mode_work(struct virtnet_info *vi)
{
rtnl_lock();
@@ -2421,6 +2441,25 @@ static int virtnet_enable_queue_pair(struct virtnet_info
*vi, int qp_index)
return err;
}
+static void virtnet_update_settings(struct virtnet_info *vi)
+{
+ u32 speed;
+ u8 duplex;
+
+ if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
+ return;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
+
+ if (ethtool_validate_speed(speed))
+ vi->speed = speed;
+
+ virtio_cread_le(vi->vdev, struct virtio_net_config, duplex, );
+
+ if (ethtool_validate_duplex(duplex))
+ vi->duplex = duplex;
+}
+
static int virtnet_open(struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
@@ -2439,6 +2478,18 @@ static int virtnet_open(struct net_device *dev)
goto err_enable_qp;
}
+ /* Assume link up if device can't report link status,
+ otherwise get link status from config. */
+ netif_carrier_off(dev);
+ if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) {
+ enable_config_change(vi);
+ schedule_work(>config_work);
+ } else {
+ vi->status = VIRTIO_NET_S_LINK_UP;
+ virtnet_update_settings(vi);
+ netif_carrier_on(dev);
+ }
+
return 0;
err_enable_qp:
@@ -2875,12 +2926,19 @@ static int virtnet_close(struct net_device *dev)
disable_delayed_refill(vi);
/* Make sure refill_work doesn't re-enable napi! */
cancel_delayed_work_sync(>refill);
+ /* Make sure config notification doesn't schedule config work */
+ disable_config_change(vi);
+ /* Make sure status updating is cancelled */
+ cancel_work_sync(>config_work);
for (i = 0; i < vi->max_queue_pairs; i++) {
virtnet_disable_queue_pair(vi, i);
cancel_work_sync(>rq[i].dim.work);
}
+ vi->status &= ~VIRTIO_NET_S_LINK_UP;
+ netif_carrier_off(dev);
+
return 0;
}
@@ -4583,25 +4641,6 @@ static void virtnet_init_settings(struct net_device *dev)
vi->duplex = DUPLEX_UNKNOWN;
}
-static void virtnet_update_settings(struct virtnet_info *vi)
-{
- u32 speed;
- u8 duplex;
-
- if (!virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX))
- return;
-
- virtio_cread_le(vi->vdev, struct virtio_net_config, speed, );
-
Re: [REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue
On Thu, May 16, 2024 at 5:46 PM Catherine Redfield
wrote:
>
> Feng,
>
> Thank you for providing your debugging steps; I used them on a gce image
> locally and was not able to replicate the issue. I also attempted to
> replicate in qemu/virsh using qemu-guest-agent to enable the S3 suspend
> state, also without success (that is S3 suspend state worked without any
> problems). I have brought this back to the cloud for further debugging of
> their config and guest agent to try and determine what the issue is.
>
> Thank you very much for all your help on this issue and time looking into it!
> Catherine
Does this fix the issue? I guess the reason is that GCE is using legacy virtio.
https://lore.kernel.org/kvm/cacgkmeth_9baewekq862ygzwuozwg96z3g6oyqhzycj2jpu...@mail.gmail.com/T/
Thanks
>
> On Thu, May 9, 2024 at 5:03 AM Feng Liu wrote:
>>
>>
>> On 2024-05-08 a.m.7:18, Catherine Redfield wrote:
>> > *External email: Use caution opening links or attachments*
>> >
>> >
>> > On a VM with the GCP kernel (where we first identified the problem), I see:
>> >
>> > 1. The full kernel log from `journalctl --system > kernlog` attached.
>> > The specific suspend section is here:
>> >
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > systemd[1]: Reached target sleep.target - Sleep.
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > systemd[1]: Starting systemd-suspend.service - System Suspend...
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > systemd-sleep[1413]: Performing sleep operation 'suspend'...
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: PM: suspend entry (deep)
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: Filesystems sync: 0.008 seconds
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: Freezing user space processes
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: Freezing user space processes completed (elapsed 0.001 seconds)
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: OOM killer disabled.
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: Freezing remaining freezable tasks
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: Freezing remaining freezable tasks completed (elapsed 0.000
>> > seconds)
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: printk: Suspending console(s) (use no_console_suspend to debug)
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: port 00:03:0.0: PM: dpm_run_callback():
>> > pm_runtime_force_suspend+0x0/0x130 returns -16
>> > May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
>> > kernel: port 00:03:0.0: PM: failed to suspend: error -16
>>
>> Thanks Joesph and Catherine's help.
>>
>> Hi,
>>
>> I have alreay synced up with Cananical guys offline about this issue.
>>
>> I can run "suspend/resume" sucessfully on my local server and VM.
>> And "PM: failed to suspend: error -16" looks like not cause by my
>> previous virtio patch ( fd27ef6b44be ("virtio-pci: Introduce admin
>> virtqueue")) which only modified "virtio_device_freeze" about "suspend"
>> action.
>>
>> So I have provide the my steps and debug patch to Joesph and Catherine.
>> I will also sync up the information here, as follow:
>>
>> I have read the qemu code and find a way to trigger "suspend/resume" on
>> my setup, and add some debug message in the latest kerenel
>>
>> My setps are:
>> 1. QEMU cmdline add following
>>
>> -global PIIX4_PM.disable_s3=0 \
>> -global PIIX4_PM.disable_s4=1 \
>>
>> -netdev type=tap,ifname=tap0,id=hostnet0,script=no,downscript=no \
>> -device
>> virtio-net-pci,netdev=hostnet0,id=net0,mac=$SSH_MAC,bus=pci.0,addr=0x3 \
>> ..
>>
>> 2. In the VM, run "systemctl suspend" to PM suspend the VM into memory
>> 3. In qemu hmp shell, run "system_wakeup" to resume the VM again
>>
>> My VM configuration:
>> NIC: 1 virtio nic emulated by QEMU
>> OS: Ubuntu 22.04.4 LTS
>> kernel: latest kernel, 6.9-rc7: ee5b455b0ada (kernel2/net-next-virito,
>> kernel2/master, master) Merge tag 'slab
Re: [REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue
On 2024-05-08 a.m.7:18, Catherine Redfield wrote:
*External email: Use caution opening links or attachments*
On a VM with the GCP kernel (where we first identified the problem), I see:
1. The full kernel log from `journalctl --system > kernlog` attached.
The specific suspend section is here:
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd[1]: Reached target sleep.target - Sleep.
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd[1]: Starting systemd-suspend.service - System Suspend...
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
systemd-sleep[1413]: Performing sleep operation 'suspend'...
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: PM: suspend entry (deep)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Filesystems sync: 0.008 seconds
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing user space processes
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing user space processes completed (elapsed 0.001 seconds)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: OOM killer disabled.
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing remaining freezable tasks
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: Freezing remaining freezable tasks completed (elapsed 0.000 seconds)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: printk: Suspending console(s) (use no_console_suspend to debug)
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: port 00:03:0.0: PM: dpm_run_callback():
pm_runtime_force_suspend+0x0/0x130 returns -16
May 08 11:08:42 kernel-test-202405080702.c.ubuntu-catred.internal
kernel: port 00:03:0.0: PM: failed to suspend: error -16
Thanks Joesph and Catherine's help.
Hi,
I have alreay synced up with Cananical guys offline about this issue.
I can run "suspend/resume" sucessfully on my local server and VM.
And "PM: failed to suspend: error -16" looks like not cause by my
previous virtio patch ( fd27ef6b44be ("virtio-pci: Introduce admin
virtqueue")) which only modified "virtio_device_freeze" about "suspend"
action.
So I have provide the my steps and debug patch to Joesph and Catherine.
I will also sync up the information here, as follow:
I have read the qemu code and find a way to trigger "suspend/resume" on
my setup, and add some debug message in the latest kerenel
My setps are:
1. QEMU cmdline add following
-global PIIX4_PM.disable_s3=0 \
-global PIIX4_PM.disable_s4=1 \
-netdev type=tap,ifname=tap0,id=hostnet0,script=no,downscript=no \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=$SSH_MAC,bus=pci.0,addr=0x3 \
..
2. In the VM, run "systemctl suspend" to PM suspend the VM into memory
3. In qemu hmp shell, run "system_wakeup" to resume the VM again
My VM configuration:
NIC: 1 virtio nic emulated by QEMU
OS: Ubuntu 22.04.4 LTS
kernel: latest kernel, 6.9-rc7: ee5b455b0ada (kernel2/net-next-virito,
kernel2/master, master) Merge tag 'slab-for-6.9-rc7-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab)
I add some debug message on the latest kernel, and do above steps to
trigger "suspen/resume". Everything of VM is OK, VM could suspend/resume
successfully.
Follwing is the kernel log:
May 6 15:59:52 feliu-vm kernel: [ 43.446737] PM: suspend entry (deep)
May 6 16:00:04 feliu-vm kernel: [ 43.467640] Filesystems sync: 0.020
seconds
May 6 16:00:04 feliu-vm kernel: [ 43.467923] Freezing user space
processes
May 6 16:00:04 feliu-vm kernel: [ 43.470294] Freezing user space
processes completed (elapsed 0.002 seconds)
May 6 16:00:04 feliu-vm kernel: [ 43.470299] OOM killer disabled.
May 6 16:00:04 feliu-vm kernel: [ 43.470301] Freezing remaining
freezable tasks
May 6 16:00:04 feliu-vm kernel: [ 43.471482] Freezing remaining
freezable tasks completed (elapsed 0.001 seconds)
May 6 16:00:04 feliu-vm kernel: [ 43.471495] printk: Suspending
console(s) (use no_console_suspend to debug)
May 6 16:00:04 feliu-vm kernel: [ 43.474034] virtio_net virtio0:
godeng virtio device freeze
May 6 16:00:04 feliu-vm kernel: [ 43.475714] virtio_net virtio0 ens3:
godfeng virtnet_freeze done
May 6 16:00:04 feliu-vm kernel: [ 43.475717] virtio_net virtio0:
godfeng VIRTIO_F_ADMIN_VQ not enabled
May 6 16:00:04 feliu-vm kernel: [ 43.475719] virtio_net virtio0:
godeng virtio device freeze done
May 6 16:00:04 feliu-vm kernel: [ 43.535382] smpboot: CPU 1 is now
offline
May 6 16:00:04 feliu-vm kernel: [ 43.537283] IRQ fixup: irq 1 move in
progress, old vector 32
May 6 16:00:04 feliu-vm kernel:
Re: [REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue
On Sat, May 4, 2024 at 2:10 AM Joseph Salisbury
wrote:
>
> Hi Feng,
>
> During testing, a kernel bug was identified with the suspend/resume
> functionality on instances running in a public cloud [0]. This bug is a
> regression introduced in v6.8-rc1. After a kernel bisect, the following
> commit was identified as the cause of the regression:
>
> fd27ef6b44be ("virtio-pci: Introduce admin virtqueue")
Have a quick glance at the patch it seems it should not damage the
freeze/restore as it should behave as in the past.
But I found something interesting:
1) assumes 1 admin vq which is not what spec said
2) special function for admin virtqueue during freeze/restore, but it
doesn't do anything special than del_vq()
3) lack real users but I guess e.g the destroy_avq() needs to be
synchronized with the one that is using admin virtqueue
>
> I was hoping to get your feedback, since you are the patch author. Do
> you think gathering any additional data will help diagnose this issue?
Yes, please show us
1) the kernel log here.
2) the features that the device has like
/sys/bus/virtio/devices/virtio0/features
> This commit is depended upon by other virtio commits, so a revert test
> is not really straight forward without reverting all the dependencies.
> Any ideas you have would be greatly appreciated.
Thanks
>
>
> Thanks,
>
> Joe
>
> http://pad.lv/2063315
>
[REGRESSION][v6.8-rc1] virtio-pci: Introduce admin virtqueue
Hi Feng,
During testing, a kernel bug was identified with the suspend/resume
functionality on instances running in a public cloud [0]. This bug is a
regression introduced in v6.8-rc1. After a kernel bisect, the following
commit was identified as the cause of the regression:
fd27ef6b44be ("virtio-pci: Introduce admin virtqueue")
I was hoping to get your feedback, since you are the patch author. Do
you think gathering any additional data will help diagnose this issue?
This commit is depended upon by other virtio commits, so a revert test
is not really straight forward without reverting all the dependencies.
Any ideas you have would be greatly appreciated.
Thanks,
Joe
http://pad.lv/2063315
[PATCH] docs: admin-guide: update description for kernel.modprobe sysctl
When I added CONFIG_MODPROBE_PATH, I neglected to update Documentation/. It's still true that this defaults to /sbin/modprobe, but now via a level of indirection. So document that the kernel might have been built with something other than /sbin/modprobe as the initial value. Signed-off-by: Rasmus Villemoes --- Andrew, this is a followup or a fixup, however you want to handle it, to "modules: add CONFIG_MODPROBE_PATH" (in next-20210419 known as 8bc50a36278dbf3e14b25236e3acee25f75d5bd8). I.e., please add this as-is to your patch queue, or fold this into that one. Documentation/admin-guide/sysctl/kernel.rst | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 1d56a6b73a4e..7ca8df5451d4 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -483,10 +483,11 @@ modprobe The full path to the usermode helper for autoloading kernel modules, -by default "/sbin/modprobe". This binary is executed when the kernel -requests a module. For example, if userspace passes an unknown -filesystem type to mount(), then the kernel will automatically request -the corresponding filesystem module by executing this usermode helper. +by default ``CONFIG_MODPROBE_PATH``, which in turn defaults to +"/sbin/modprobe". This binary is executed when the kernel requests a +module. For example, if userspace passes an unknown filesystem type +to mount(), then the kernel will automatically request the +corresponding filesystem module by executing this usermode helper. This usermode helper should insert the needed module into the kernel. This sysctl only affects module autoloading. It has no effect on the -- 2.29.2
[PATCH] docs: admin-guide: update description for kernel.hotplug sysctl
It's been a few releases since this defaulted to /sbin/hotplug. Update
the text, and include pointers to the two CONFIG_UEVENT_HELPER{,_PATH}
config knobs whose help text could provide more info, but also hint
that the user probably doesn't need to care at all.
Fixes: 7934779a69f1 ("Driver-Core: disable /sbin/hotplug by default")
Signed-off-by: Rasmus Villemoes
---
Documentation/admin-guide/sysctl/kernel.rst | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/sysctl/kernel.rst
b/Documentation/admin-guide/sysctl/kernel.rst
index 1d56a6b73a4e..c24f57f2c782 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -333,7 +333,12 @@ hotplug
===
Path for the hotplug policy agent.
-Default value is "``/sbin/hotplug``".
+Default value is ``CONFIG_UEVENT_HELPER_PATH``, which in turn defaults
+to the empty string.
+
+This file only exists when ``CONFIG_UEVENT_HELPER`` is enabled. Most
+modern systems rely exclusively on the netlink-based uevent source and
+don't need this.
hung_task_all_cpu_backtrace
--
2.29.2
[PATCH 3/4] Documentation/admin-guide: Change doc for bus lock ratelimit
Since bus lock rate limit changes the split_lock_detect parameter, update the documentation for the change. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- Documentation/admin-guide/kernel-parameters.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5892896bedc..c13bbfd8c5aa 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5154,6 +5154,14 @@ exception. Default behavior is by #AC if both features are enabled in hardware. + ratelimit:N - + Set system wide rate limit to N bus locks + per second for bus lock detection. + 0 < N <= 1000. + + N/A for split lock detection. + + If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" -- 2.31.1
[PATCH v5,4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
Re: [PATCH] doc: admin-guide: remove explanation of "watchdog/%u"
Wang Qing writes: > "watchdog/%u" threads has be replaced by cpu_stop_work, > which will mislead the reader. > > Signed-off-by: Wang Qing > --- > .../admin-guide/kernel-per-CPU-kthreads.rst | 20 > > 1 file changed, 20 deletions(-) Applied, thanks. jon
[PATCH v1 2/4] MAINTAINERS: add entry for Documentation/admin-guide/reporting-issues.rst
Thorsten will keep an eye on the new document about reporting issues (aka bugs). Signed-off-by: Thorsten Leemhuis --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e66ff3daf23c..b5d38fedff6c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5413,6 +5413,12 @@ X: Documentation/power/ X: Documentation/spi/ X: Documentation/userspace-api/media/ +DOCUMENTATION REPORTING ISSUES +M: Thorsten Leemhuis +L: linux-...@vger.kernel.org +S: Maintained +F: Documentation/admin-guide/reporting-issues.rst + DOCUMENTATION SCRIPTS M: Mauro Carvalho Chehab L: linux-...@vger.kernel.org -- 2.30.2
[tip: x86/splitlock] Documentation/admin-guide: Change doc for split_lock_detect parameter
The following commit has been merged into the x86/splitlock branch of tip: Commit-ID: ebca17707e38f2050b188d837bd4646b29a1b0c2 Gitweb: https://git.kernel.org/tip/ebca17707e38f2050b188d837bd4646b29a1b0c2 Author:Fenghua Yu AuthorDate:Mon, 22 Mar 2021 13:53:25 Committer: Thomas Gleixner CommitterDate: Sun, 28 Mar 2021 22:52:16 +02:00 Documentation/admin-guide: Change doc for split_lock_detect parameter Since #DB for bus lock detect changes the split_lock_detect parameter, update the documentation for the changes. Signed-off-by: Fenghua Yu Signed-off-by: Thomas Gleixner Reviewed-by: Tony Luck Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20210322135325.682257-4-fenghua...@intel.com --- Documentation/admin-guide/kernel-parameters.txt | 22 +++- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 0454572..aef927c 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5100,27 +5100,37 @@ spia_peddr= split_lock_detect= - [X86] Enable split lock detection + [X86] Enable split lock detection or bus lock detection When enabled (and if hardware support is present), atomic instructions that access data across cache line - boundaries will result in an alignment check exception. + boundaries will result in an alignment check exception + for split lock detection or a debug exception for + bus lock detection. off - not enabled - warn- the kernel will emit rate limited warnings + warn- the kernel will emit rate-limited warnings about applications triggering the #AC - exception. This mode is the default on CPUs - that supports split lock detection. + exception or the #DB exception. This mode is + the default on CPUs that support split lock + detection or bus lock detection. Default + behavior is by #AC if both features are + enabled in hardware. fatal - the kernel will send SIGBUS to applications - that trigger the #AC exception. + that trigger the #AC exception or the #DB + exception. Default behavior is by #AC if + both features are enabled in hardware. If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" mode. + #DB exception for bus lock is triggered only when + CPL > 0. + srbds= [X86,INTEL] Control the Special Register Buffer Data Sampling (SRBDS) mitigation.
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH v6 3/3] Documentation/admin-guide: Change doc for split_lock_detect parameter
Since #DB for bus lock detect changes the split_lock_detect parameter, update the documentation for the changes. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck Acked-by: Randy Dunlap --- Change Log: v6: - Remove the ratelimit info which will be released later in a ratelimit specific patch set (Thomas). v5: - Remove N < HZ/2 check info in the doc (Thomas). v4: - Fix a ratelimit wording issue in the doc (Randy). - Patch 4 is acked by Randy (Randy). v3: - Enable Bus Lock Detection when fatal to handle bus lock from non-WB (PeterZ). v1: - Fix a few wording issues (Randy). RFC v2: - Simplify the documentation (Randy). .../admin-guide/kernel-parameters.txt | 22 ++- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 04545725f187..aef927cec602 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5100,27 +5100,37 @@ spia_peddr= split_lock_detect= - [X86] Enable split lock detection + [X86] Enable split lock detection or bus lock detection When enabled (and if hardware support is present), atomic instructions that access data across cache line - boundaries will result in an alignment check exception. + boundaries will result in an alignment check exception + for split lock detection or a debug exception for + bus lock detection. off - not enabled - warn- the kernel will emit rate limited warnings + warn- the kernel will emit rate-limited warnings about applications triggering the #AC - exception. This mode is the default on CPUs - that supports split lock detection. + exception or the #DB exception. This mode is + the default on CPUs that support split lock + detection or bus lock detection. Default + behavior is by #AC if both features are + enabled in hardware. fatal - the kernel will send SIGBUS to applications - that trigger the #AC exception. + that trigger the #AC exception or the #DB + exception. Default behavior is by #AC if + both features are enabled in hardware. If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" mode. + #DB exception for bus lock is triggered only when + CPL > 0. + srbds= [X86,INTEL] Control the Special Register Buffer Data Sampling (SRBDS) mitigation. -- 2.31.0
Re: [PATCH v5 3/3] Documentation/admin-guide: Change doc for split_lock_detect parameter
On Sat, Mar 13 2021 at 05:49, Fenghua Yu wrote: > + ratelimit:N - > + Set rate limit to N bus locks per second > + for bus lock detection. 0 < N. > + Only applied to non-root users. Of course this does not mention that the limit is per UID and it neither tells what the action is to rate limit the bus lock attempts. The rate limit saturation which is induced by msleep() is not mentioned either. Really useful for administrators. Thanks, tglx
Re: [PATCH] docs: admin-guide: cgroup-v1: Fix typos in the file memory.rst
Bhaskar Chowdhury writes: > s/overcommited/overcommitted/ > s/Overcommiting/Overcommitting/ > > Signed-off-by: Bhaskar Chowdhury > --- > Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst > b/Documentation/admin-guide/cgroup-v1/memory.rst > index 52688ae34461..0d574fd3f8e3 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -360,8 +360,8 @@ U != 0, K = unlimited: > > U != 0, K < U: > Kernel memory is a subset of the user memory. This setup is useful in > -deployments where the total amount of memory per-cgroup is overcommited. > -Overcommiting kernel memory limits is definitely not recommended, since > the > +deployments where the total amount of memory per-cgroup is overcommitted. > +Overcommitting kernel memory limits is definitely not recommended, since > the > box can still run out of non-reclaimable memory. Applied, thanks. jon
[PATCH] doc: admin-guide: remove explanation of "watchdog/%u"
"watchdog/%u" threads has be replaced by cpu_stop_work, which will mislead the reader. Signed-off-by: Wang Qing --- .../admin-guide/kernel-per-CPU-kthreads.rst | 20 1 file changed, 20 deletions(-) diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst index 531f689..5e51ee5 --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst @@ -332,23 +332,3 @@ To reduce its OS jitter, do at least one of the following: kthreads from being created in the first place. However, please note that this will not eliminate OS jitter, but will instead shift it to RCU_SOFTIRQ. - -Name: - watchdog/%u - -Purpose: - Detect software lockups on each CPU. - -To reduce its OS jitter, do at least one of the following: - -1. Build with CONFIG_LOCKUP_DETECTOR=n, which will prevent these - kthreads from being created in the first place. -2. Boot with "nosoftlockup=0", which will also prevent these kthreads - from being created. Other related watchdog and softlockup boot - parameters may be found in Documentation/admin-guide/kernel-parameters.rst - and Documentation/watchdog/watchdog-parameters.rst. -3. Echo a zero to /proc/sys/kernel/watchdog to disable the - watchdog timer. -4. Echo a large number of /proc/sys/kernel/watchdog_thresh in - order to reduce the frequency of OS jitter due to the watchdog - timer down to a level that is acceptable for your workload. -- 2.7.4
Re: [PATCH] docs: admin-guide: cgroup-v1: Fix typos in the file memory.rst
On 3/12/21 10:10 PM, Bhaskar Chowdhury wrote: > > s/overcommited/overcommitted/ > s/Overcommiting/Overcommitting/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst > b/Documentation/admin-guide/cgroup-v1/memory.rst > index 52688ae34461..0d574fd3f8e3 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -360,8 +360,8 @@ U != 0, K = unlimited: > > U != 0, K < U: > Kernel memory is a subset of the user memory. This setup is useful in > -deployments where the total amount of memory per-cgroup is overcommited. > -Overcommiting kernel memory limits is definitely not recommended, since > the > +deployments where the total amount of memory per-cgroup is overcommitted. > +Overcommitting kernel memory limits is definitely not recommended, since > the > box can still run out of non-reclaimable memory. > In this case, the admin could set up K so that the sum of all groups is > never greater than the total memory, and freely set U at the cost of his > -- -- ~Randy
[PATCH] docs: admin-guide: cgroup-v1: Fix typos in the file memory.rst
s/overcommited/overcommitted/ s/Overcommiting/Overcommitting/ Signed-off-by: Bhaskar Chowdhury --- Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 52688ae34461..0d574fd3f8e3 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -360,8 +360,8 @@ U != 0, K = unlimited: U != 0, K < U: Kernel memory is a subset of the user memory. This setup is useful in -deployments where the total amount of memory per-cgroup is overcommited. -Overcommiting kernel memory limits is definitely not recommended, since the +deployments where the total amount of memory per-cgroup is overcommitted. +Overcommitting kernel memory limits is definitely not recommended, since the box can still run out of non-reclaimable memory. In this case, the admin could set up K so that the sum of all groups is never greater than the total memory, and freely set U at the cost of his -- 2.26.2
[PATCH v5 3/3] Documentation/admin-guide: Change doc for split_lock_detect parameter
Since #DB for bus lock detect changes the split_lock_detect parameter, update the documentation for the changes. Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck Acked-by: Randy Dunlap --- Change Log: v5: - Remove N < HZ/2 check info in the doc (Thomas). v4: - Fix a ratelimit wording issue in the doc (Randy). - Patch 4 is acked by Randy (Randy). v3: - Enable Bus Lock Detection when fatal to handle bus lock from non-WB (PeterZ). v1: - Fix a few wording issues (Randy). RFC v2: - Simplify the documentation (Randy). .../admin-guide/kernel-parameters.txt | 30 +++ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 04545725f187..16b2e1c45d04 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5100,27 +5100,45 @@ spia_peddr= split_lock_detect= - [X86] Enable split lock detection + [X86] Enable split lock detection or bus lock detection When enabled (and if hardware support is present), atomic instructions that access data across cache line - boundaries will result in an alignment check exception. + boundaries will result in an alignment check exception + for split lock detection or a debug exception for + bus lock detection. off - not enabled - warn- the kernel will emit rate limited warnings + warn- the kernel will emit rate-limited warnings about applications triggering the #AC - exception. This mode is the default on CPUs - that supports split lock detection. + exception or the #DB exception. This mode is + the default on CPUs that support split lock + detection or bus lock detection. Default + behavior is by #DB if both features are + enabled in hardware. fatal - the kernel will send SIGBUS to applications - that trigger the #AC exception. + that trigger the #AC exception or the #DB + exception. If both features are enabled in + hardware, split lock triggers #AC and bus + lock from non-WB triggers #DB. + + ratelimit:N - + Set rate limit to N bus locks per second + for bus lock detection. 0 < N. + Only applied to non-root users. + + N/A for split lock detection. If an #AC exception is hit in the kernel or in firmware (i.e. not while executing in user mode) the kernel will oops in either "warn" or "fatal" mode. + #DB exception for bus lock is triggered only when + CPL > 0. + srbds= [X86,INTEL] Control the Special Register Buffer Data Sampling (SRBDS) mitigation. -- 2.30.2
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..ca3b8f19466c 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option is enabled, the following openssl +command option should be added where for generating CodeSign extended key usage +in X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
Re: [PATCH] Documentation/admin-guide: kernel-parameters: correct the architectures for numa_balancing
Barry Song writes: > X86 isn't the only architecture supporting NUMA_BALANCING. ARM64, PPC, > S390 and RISCV also support it: Applied, thanks. jon
Re: [PATCH 5.10 083/102] scsi: iscsi: Restrict sessions and handles to admin capabilities
On 3/5/21 2:42 PM, Pavel Machek wrote:
> Hi!
>
>> From: Lee Duncan
>>
>> commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
>>
>> Protect the iSCSI transport handle, available in sysfs, by requiring
>> CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
>> reception of messages to ones sent with CAP_SYS_ADMIN. This disables
>> normal users from being able to end arbitrary iSCSI sessions.
>
> Should not normal filesystem permissions be used?
>
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -132,6 +132,9 @@ show_transport_handle(struct device *dev
>>char *buf)
>> {
>> struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
>> +
>> +if (!capable(CAP_SYS_ADMIN))
>> +return -EACCES;
>> return sprintf(buf, "%llu\n", (unsigned long
>> long)iscsi_handle(priv->iscsi_transport));
>> }
>> static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
>
> AFAICT we make the file 0444 (world readable) and then fail the read
> with capability check. If the file is not supposed to be
> world-readable, it should have 0400 permissions, right?
>
> Best regards,
> Pavel
>
I am ok with changing file permissions, but there's nothing wrong with
checking capabilities upon entry, as well, since capability checks are a
higher degree of security than ACLs.
--
Lee Duncan
Re: [PATCH 5.10 083/102] scsi: iscsi: Restrict sessions and handles to admin capabilities
Hi!
> From: Lee Duncan
>
> commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
>
> Protect the iSCSI transport handle, available in sysfs, by requiring
> CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
> reception of messages to ones sent with CAP_SYS_ADMIN. This disables
> normal users from being able to end arbitrary iSCSI sessions.
Should not normal filesystem permissions be used?
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -132,6 +132,9 @@ show_transport_handle(struct device *dev
> char *buf)
> {
> struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> return sprintf(buf, "%llu\n", (unsigned long
> long)iscsi_handle(priv->iscsi_transport));
> }
> static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
AFAICT we make the file 0444 (world readable) and then fail the read
with capability check. If the file is not supposed to be
world-readable, it should have 0400 permissions, right?
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
signature.asc
Description: Digital signature
[PATCH 4.4 22/30] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -119,6 +119,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3523,6 +3526,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 4.9 33/41] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -119,6 +119,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3522,6 +3525,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 4.14 31/39] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -119,6 +119,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3504,6 +3507,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 4.19 42/52] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -119,6 +119,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3504,6 +3507,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 5.4 61/72] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -124,6 +124,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3506,6 +3509,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 5.10 083/102] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -132,6 +132,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3624,6 +3627,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH 5.11 089/104] scsi: iscsi: Restrict sessions and handles to admin capabilities
From: Lee Duncan
commit 688e8128b7a92df982709a4137ea4588d16f24aa upstream.
Protect the iSCSI transport handle, available in sysfs, by requiring
CAP_SYS_ADMIN to read it. Also protect the netlink socket by restricting
reception of messages to ones sent with CAP_SYS_ADMIN. This disables
normal users from being able to end arbitrary iSCSI sessions.
Cc: sta...@vger.kernel.org
Reported-by: Adam Nichols
Reviewed-by: Chris Leech
Reviewed-by: Mike Christie
Signed-off-by: Lee Duncan
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/scsi_transport_iscsi.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -132,6 +132,9 @@ show_transport_handle(struct device *dev
char *buf)
{
struct iscsi_internal *priv = dev_to_iscsi_internal(dev);
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
return sprintf(buf, "%llu\n", (unsigned long
long)iscsi_handle(priv->iscsi_transport));
}
static DEVICE_ATTR(handle, S_IRUGO, show_transport_handle, NULL);
@@ -3624,6 +3627,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, s
struct iscsi_cls_conn *conn;
struct iscsi_endpoint *ep = NULL;
+ if (!netlink_capable(skb, CAP_SYS_ADMIN))
+ return -EPERM;
+
if (nlh->nlmsg_type == ISCSI_UEVENT_PATH_UPDATE)
*group = ISCSI_NL_GRP_UIP;
else
[PATCH v1 3/3] i40e: use minimal admin queue for kdump
The minimum size of admin send/receive queue is 1 and 2 respectively.
The admin send queue can't be set to 1 because in that case, the
firmware would fail to init.
Signed-off-by: Coiby Xu
---
drivers/net/ethernet/intel/i40e/i40e.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_main.c | 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
b/drivers/net/ethernet/intel/i40e/i40e.h
index cd53981fa5e0..09217944baa4 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -66,6 +66,8 @@
#define I40E_FDIR_RING_COUNT 32
#define I40E_MAX_AQ_BUF_SIZE 4096
#define I40E_AQ_LEN256
+#define I40E_MIN_ARQ_LEN 1
+#define I40E_MIN_ASQ_LEN 2
#define I40E_AQ_WORK_LIMIT 66 /* max number of VFs + a little */
#define I40E_MAX_USER_PRIORITY 8
#define I40E_DEFAULT_TRAFFIC_CLASS BIT(0)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index d6868c7aee05..5d67fb12e576 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -15327,8 +15327,13 @@ static int i40e_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
i40e_check_recovery_mode(pf);
- hw->aq.num_arq_entries = I40E_AQ_LEN;
- hw->aq.num_asq_entries = I40E_AQ_LEN;
+ if (is_kdump_kernel()) {
+ hw->aq.num_arq_entries = I40E_MIN_ARQ_LEN;
+ hw->aq.num_asq_entries = I40E_MIN_ASQ_LEN;
+ } else {
+ hw->aq.num_arq_entries = I40E_AQ_LEN;
+ hw->aq.num_asq_entries = I40E_AQ_LEN;
+ }
hw->aq.arq_buf_size = I40E_MAX_AQ_BUF_SIZE;
hw->aq.asq_buf_size = I40E_MAX_AQ_BUF_SIZE;
pf->adminq_work_limit = I40E_AQ_WORK_LIMIT;
--
2.30.1
Re: [PATCH] Documentation/admin-guide: kernel-parameters: correct the architectures for numa_balancing
On Tue, 02 Mar 2021 00:41:59 PST (-0800), song.bao@hisilicon.com wrote: X86 isn't the only architecture supporting NUMA_BALANCING. ARM64, PPC, S390 and RISCV also support it: arch$ git grep NUMA_BALANCING arm64/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING arm64/configs/defconfig:CONFIG_NUMA_BALANCING=y arm64/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/configs/powernv_defconfig:CONFIG_NUMA_BALANCING=y powerpc/configs/ppc64_defconfig:CONFIG_NUMA_BALANCING=y powerpc/configs/pseries_defconfig:CONFIG_NUMA_BALANCING=y powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/include/asm/nohash/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/nohash/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/platforms/Kconfig.cputype: select ARCH_SUPPORTS_NUMA_BALANCING riscv/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING riscv/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING s390/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING s390/configs/debug_defconfig:CONFIG_NUMA_BALANCING=y s390/configs/defconfig:CONFIG_NUMA_BALANCING=y s390/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING x86/Kconfig:select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 x86/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING x86/include/asm/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ On the other hand, setup_numabalancing() is implemented in mm/mempolicy.c which doesn't depend on architectures. Cc: Mel Gorman Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: "Paul E. McKenney" Cc: Randy Dunlap Cc: Andrew Morton Cc: Thomas Gleixner Cc: Mauro Carvalho Chehab Cc: Viresh Kumar Cc: Mike Kravetz Cc: Peter Zijlstra Signed-off-by: Barry Song --- Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 1132796a8d96..24302cad174a 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -140,6 +140,7 @@ parameter is applicable:: PPT Parallel port support is enabled. PS2 Appropriate PS/2 support is enabled. RAM RAM disk support is enabled. + RISCV RISCV architecture is enabled. RDT Intel Resource Director Technology. S390S390 architecture is enabled. SCSIAppropriate SCSI support is enabled. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 04545725f187..371a02ae1e21 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3472,7 +3472,8 @@ nr_uarts= [SERIAL] maximum number of UARTs to be registered. - numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing. + numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic + NUMA balancing. Allowed values are enable and disable numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt
[PATCH] Documentation/admin-guide: kernel-parameters: correct the architectures for numa_balancing
X86 isn't the only architecture supporting NUMA_BALANCING. ARM64, PPC, S390 and RISCV also support it: arch$ git grep NUMA_BALANCING arm64/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING arm64/configs/defconfig:CONFIG_NUMA_BALANCING=y arm64/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/configs/powernv_defconfig:CONFIG_NUMA_BALANCING=y powerpc/configs/ppc64_defconfig:CONFIG_NUMA_BALANCING=y powerpc/configs/pseries_defconfig:CONFIG_NUMA_BALANCING=y powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/include/asm/nohash/pgtable.h:#ifdef CONFIG_NUMA_BALANCING powerpc/include/asm/nohash/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ powerpc/platforms/Kconfig.cputype: select ARCH_SUPPORTS_NUMA_BALANCING riscv/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING riscv/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING s390/Kconfig: select ARCH_SUPPORTS_NUMA_BALANCING s390/configs/debug_defconfig:CONFIG_NUMA_BALANCING=y s390/configs/defconfig:CONFIG_NUMA_BALANCING=y s390/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING x86/Kconfig:select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 x86/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING x86/include/asm/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */ On the other hand, setup_numabalancing() is implemented in mm/mempolicy.c which doesn't depend on architectures. Cc: Mel Gorman Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: "Paul E. McKenney" Cc: Randy Dunlap Cc: Andrew Morton Cc: Thomas Gleixner Cc: Mauro Carvalho Chehab Cc: Viresh Kumar Cc: Mike Kravetz Cc: Peter Zijlstra Signed-off-by: Barry Song --- Documentation/admin-guide/kernel-parameters.rst | 1 + Documentation/admin-guide/kernel-parameters.txt | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 1132796a8d96..24302cad174a 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -140,6 +140,7 @@ parameter is applicable:: PPT Parallel port support is enabled. PS2 Appropriate PS/2 support is enabled. RAM RAM disk support is enabled. + RISCV RISCV architecture is enabled. RDT Intel Resource Director Technology. S390S390 architecture is enabled. SCSIAppropriate SCSI support is enabled. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 04545725f187..371a02ae1e21 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3472,7 +3472,8 @@ nr_uarts= [SERIAL] maximum number of UARTs to be registered. - numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing. + numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable automatic + NUMA balancing. Allowed values are enable and disable numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. -- 2.25.1
Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Hi Randy, On Mon, Feb 22, 2021 at 08:48:42AM -0800, Randy Dunlap wrote: > Hi, > > On 2/21/21 10:42 PM, Lee, Chun-Yi wrote: > > Add an openssl command option example for generating CodeSign extended > > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. > > > > Signed-off-by: "Lee, Chun-Yi" > > --- > > Documentation/admin-guide/module-signing.rst | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/admin-guide/module-signing.rst > > b/Documentation/admin-guide/module-signing.rst > > index 7d7c7c8a545c..b57b30c7125f 100644 > > --- a/Documentation/admin-guide/module-signing.rst > > +++ b/Documentation/admin-guide/module-signing.rst > > @@ -170,6 +170,12 @@ generate the public/private key files:: > >-config x509.genkey -outform PEM -out kernel_key.pem \ > >-keyout kernel_key.pem > > > > +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl > > is enabled, > > > +command option should be added for generating CodeSign extended key usage > > in > > should be added ? > > > +X.509:: Thanks for your review! I will update to next version. Joey Lee
Re: [PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Hi, On 2/21/21 10:42 PM, Lee, Chun-Yi wrote: > Add an openssl command option example for generating CodeSign extended > key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. > > Signed-off-by: "Lee, Chun-Yi" > --- > Documentation/admin-guide/module-signing.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/admin-guide/module-signing.rst > b/Documentation/admin-guide/module-signing.rst > index 7d7c7c8a545c..b57b30c7125f 100644 > --- a/Documentation/admin-guide/module-signing.rst > +++ b/Documentation/admin-guide/module-signing.rst > @@ -170,6 +170,12 @@ generate the public/private key files:: > -config x509.genkey -outform PEM -out kernel_key.pem \ > -keyout kernel_key.pem > > +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl is enabled, > +command option should be added for generating CodeSign extended key usage in should be added ? > +X.509:: > + > +-addext "extendedKeyUsage=codeSigning" > + > The full pathname for the resulting kernel_key.pem file can then be specified > in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein > will > be used instead of an autogenerated keypair. > thanks. -- ~Randy
[RFC PATCH 3/4] i40e: use minimal admin queue for kdump
The minimum size of admin send/receive queue is 1 and 2 respectively.
The admin send queue can't be set to 1 because in that case, the
firmware would fail to init.
Signed-off-by: Coiby Xu
---
drivers/net/ethernet/intel/i40e/i40e.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_main.c | 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
b/drivers/net/ethernet/intel/i40e/i40e.h
index 118473dfdcbd..e106c33ff958 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -66,6 +66,8 @@
#define I40E_FDIR_RING_COUNT 32
#define I40E_MAX_AQ_BUF_SIZE 4096
#define I40E_AQ_LEN256
+#define I40E_MIN_ARQ_LEN 1
+#define I40E_MIN_ASQ_LEN 2
#define I40E_AQ_WORK_LIMIT 66 /* max number of VFs + a little */
#define I40E_MAX_USER_PRIORITY 8
#define I40E_DEFAULT_TRAFFIC_CLASS BIT(0)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 5307f1744766..2fd8db80b585 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14847,8 +14847,13 @@ static int i40e_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
i40e_check_recovery_mode(pf);
- hw->aq.num_arq_entries = I40E_AQ_LEN;
- hw->aq.num_asq_entries = I40E_AQ_LEN;
+ if (is_kdump_kernel()) {
+ hw->aq.num_arq_entries = I40E_MIN_ARQ_LEN;
+ hw->aq.num_asq_entries = I40E_MIN_ASQ_LEN;
+ } else {
+ hw->aq.num_arq_entries = I40E_AQ_LEN;
+ hw->aq.num_asq_entries = I40E_AQ_LEN;
+ }
hw->aq.arq_buf_size = I40E_MAX_AQ_BUF_SIZE;
hw->aq.asq_buf_size = I40E_MAX_AQ_BUF_SIZE;
pf->adminq_work_limit = I40E_AQ_WORK_LIMIT;
--
2.30.0
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..b57b30c7125f 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl +command option should be added for generating CodeSign extended key usage in +X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
Re: [PATCH] doc/admin-guide: fix spelling mistake: "perfomance" -> "performance"
Colin King writes: > From: Colin Ian King > > There is a spelling mistake in the perf-security documentation. Fix it. > > Signed-off-by: Colin Ian King > --- > Documentation/admin-guide/perf-security.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/perf-security.rst > b/Documentation/admin-guide/perf-security.rst > index 904e4eb37f99..34aa334320ca 100644 > --- a/Documentation/admin-guide/perf-security.rst > +++ b/Documentation/admin-guide/perf-security.rst > @@ -72,7 +72,7 @@ monitoring and observability operations, thus, bypass > *scope* permissions > checks in the kernel. CAP_PERFMON implements the principle of least > privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for performance monitoring and > observability operations in the kernel and provides a secure approach to > -perfomance monitoring and observability in the system. > +performance monitoring and observability in the system. Applied, thanks. jon
Re: [PATCH v2] Documentation/admin-guide: kernel-parameters: Update nohlt section
Florian Fainelli writes: > Update the documentation regarding "nohlt" and indicate that it is not > only for bugs, but can be useful to disable the architecture specific > sleep instructions. ARM, ARM64, SuperH and Microblaze all use > CONFIG_GENERIC_IDLE_POLL_SETUP which takes care of honoring the > "hlt"/"nohlt" parameters. > > Acked-by: Randy Dunlap > Signed-off-by: Florian Fainelli > --- > Changes in v2: > > - used ';' after requires CONFIG_GENERIC_IDLE_POLL_SETUP (Randy) > > Documentation/admin-guide/kernel-parameters.txt | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) Applied, thanks. jon
[net-next v6 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max MTU of 16K on LMAC links and 64k on LBK
links and Octeontx2 silicon supports 9K mtu on both links.
Get the same from nix_get_hw_info mbox message in netdev probe.
This patch also calculates receive buffer size required based
on the MTU set.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
.../ethernet/marvell/octeontx2/nic/cn10k.c| 2 +-
.../marvell/octeontx2/nic/otx2_common.c | 45 +--
.../marvell/octeontx2/nic/otx2_common.h | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_pf.c | 35 +--
.../marvell/octeontx2/nic/otx2_txrx.c | 28 +---
.../marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 97 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index d6ca809edaed..9ec0313f13fc 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index 2779802eed84..cf7875d51d87 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -230,7 +230,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -606,8 +605,8 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
- OTX2_MIN_MTU;
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
+ | OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
(0x2ULL << 36);
@@ -1637,6 +1636,46 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+EXPORT_SYMBOL(otx2_get_max_mtu);
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index 51aaa6ae0fd3..4c472646a0ac 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -798,5 +798,5 @@ int otx2_del_macfilter(struct net_device *netdev, const u8
*mac);
int otx2_add_macfilter(struct net_device *netdev, const u8 *mac);
int otx2_enable_rxvlan(struct otx2_nic *pf, bool enable);
int otx2_install_rxvlan_offload_flow(struct otx2_nic *pfvf);
-
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf);
#endif /* OTX2_COMMON_H */
diff --git
[net-next v5 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max MTU of 16K on LMAC links and 64k on LBK
links and Octeontx2 silicon supports 9K mtu on both links.
Get the same from nix_get_hw_info mbox message in netdev probe.
This patch also calculates receive buffer size required based
on the MTU set.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
.../ethernet/marvell/octeontx2/nic/cn10k.c| 2 +-
.../marvell/octeontx2/nic/otx2_common.c | 45 +--
.../marvell/octeontx2/nic/otx2_common.h | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_pf.c | 35 +--
.../marvell/octeontx2/nic/otx2_txrx.c | 28 +---
.../marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 97 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index 70548d12ff42..da82f9fd177a 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index 49351a2d7629..3a72e8588d38 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -217,7 +217,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -591,8 +590,8 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
- OTX2_MIN_MTU;
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
+ | OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
(0x2ULL << 36);
@@ -1618,6 +1617,46 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+EXPORT_SYMBOL(otx2_get_max_mtu);
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index 52205cbd6ada..23e1c242175a 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -790,5 +790,5 @@ int otx2_del_macfilter(struct net_device *netdev, const u8
*mac);
int otx2_add_macfilter(struct net_device *netdev, const u8 *mac);
int otx2_enable_rxvlan(struct otx2_nic *pf, bool enable);
int otx2_install_rxvlan_offload_flow(struct otx2_nic *pfvf);
-
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf);
#endif /* OTX2_COMMON_H */
diff --git
[PATCH] doc/admin-guide: fix spelling mistake: "perfomance" -> "performance"
From: Colin Ian King There is a spelling mistake in the perf-security documentation. Fix it. Signed-off-by: Colin Ian King --- Documentation/admin-guide/perf-security.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst index 904e4eb37f99..34aa334320ca 100644 --- a/Documentation/admin-guide/perf-security.rst +++ b/Documentation/admin-guide/perf-security.rst @@ -72,7 +72,7 @@ monitoring and observability operations, thus, bypass *scope* permissions checks in the kernel. CAP_PERFMON implements the principle of least privilege [13]_ (POSIX 1003.1e: 2.2.2.39) for performance monitoring and observability operations in the kernel and provides a secure approach to -perfomance monitoring and observability in the system. +performance monitoring and observability in the system. For backward compatibility reasons the access to perf_events monitoring and observability operations is also open for CAP_SYS_ADMIN privileged -- 2.30.0
[PATCH v2] Documentation/admin-guide: kernel-parameters: Update nohlt section
Update the documentation regarding "nohlt" and indicate that it is not only for bugs, but can be useful to disable the architecture specific sleep instructions. ARM, ARM64, SuperH and Microblaze all use CONFIG_GENERIC_IDLE_POLL_SETUP which takes care of honoring the "hlt"/"nohlt" parameters. Acked-by: Randy Dunlap Signed-off-by: Florian Fainelli --- Changes in v2: - used ';' after requires CONFIG_GENERIC_IDLE_POLL_SETUP (Randy) Documentation/admin-guide/kernel-parameters.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a10b545c2070..0ea023242327 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3266,9 +3266,14 @@ parameter, xsave area per process might occupy more memory on xsaves enabled systems. - nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or - wfi(ARM) instruction doesn't work correctly and not to - use it. This is also useful when using JTAG debugger. + nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait + in do_idle() and not use the arch_cpu_idle() + implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP + to be effective. This is useful on platforms where the + sleep(SH) or wfi(ARM,ARM64) instructions do not work + correctly or when doing power measurements to evalute + the impact of the sleep instructions. This is also + useful when using JTAG debugger. no_file_capsTells the kernel not to honor file capabilities. The only way then for a file to be executed with privilege -- 2.25.1
Re: [PATCH] Documentation/admin-guide: kernel-parameters: Update nohlt section
On 2/8/21 4:30 PM, Florian Fainelli wrote: > Update the documentation regarding "nohlt" and indicate that it is not > only for bugs, but can be useful to disable the architecture specific > sleep instructions. ARM, ARM64, SuperH and Microblaze all use > CONFIG_GENERIC_IDLE_POLL_SETUP which takes care of honoring the > "hlt"/"nohlt" parameters. > > Signed-off-by: Florian Fainelli > --- > Documentation/admin-guide/kernel-parameters.txt | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index a10b545c2070..83c37e23e1e2 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -3266,9 +3266,14 @@ > parameter, xsave area per process might occupy more > memory on xsaves enabled systems. > > - nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or > - wfi(ARM) instruction doesn't work correctly and not to > - use it. This is also useful when using JTAG debugger. > + nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait > + in do_idle() and not use the arch_cpu_idle() > + implementation, requires CONFIG_GENERIC_IDLE_POLL_SETUP Sounds good... but above, I would prefer s/,/;/ > + to be effective. This is useful on platforms where the > + sleep(SH) or wfi(ARM,ARM64) instructions do not work > + correctly or when doing power measurements to evalute > + the impact of the sleep instructions. This is also > + useful when using JTAG debugger. > > no_file_capsTells the kernel not to honor file capabilities. The > only way then for a file to be executed with privilege > Acked-by: Randy Dunlap thanks. -- ~Randy
[PATCH] Documentation/admin-guide: kernel-parameters: Update nohlt section
Update the documentation regarding "nohlt" and indicate that it is not only for bugs, but can be useful to disable the architecture specific sleep instructions. ARM, ARM64, SuperH and Microblaze all use CONFIG_GENERIC_IDLE_POLL_SETUP which takes care of honoring the "hlt"/"nohlt" parameters. Signed-off-by: Florian Fainelli --- Documentation/admin-guide/kernel-parameters.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a10b545c2070..83c37e23e1e2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3266,9 +3266,14 @@ parameter, xsave area per process might occupy more memory on xsaves enabled systems. - nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or - wfi(ARM) instruction doesn't work correctly and not to - use it. This is also useful when using JTAG debugger. + nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait + in do_idle() and not use the arch_cpu_idle() + implementation, requires CONFIG_GENERIC_IDLE_POLL_SETUP + to be effective. This is useful on platforms where the + sleep(SH) or wfi(ARM,ARM64) instructions do not work + correctly or when doing power measurements to evalute + the impact of the sleep instructions. This is also + useful when using JTAG debugger. no_file_capsTells the kernel not to honor file capabilities. The only way then for a file to be executed with privilege -- 2.25.1
[net-next v4 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max MTU of 16K on LMAC links and 64k on LBK
links and Octeontx2 silicon supports 9K mtu on both links.
Get the same from nix_get_hw_info mbox message in netdev probe.
This patch also calculates receive buffer size required based
on the MTU set.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.c | 43 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.h | 2 +-
.../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 35 --
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.c | 27 ++
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../net/ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 95 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index 70548d1..da82f9f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index fe62bfd..c496629 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -217,7 +217,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -592,7 +591,7 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
|
OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
@@ -1619,6 +1618,46 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+EXPORT_SYMBOL(otx2_get_max_mtu);
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index 52205cb..23e1c24 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -790,5 +790,5 @@ int otx2_del_macfilter(struct net_device *netdev, const u8
*mac);
int otx2_add_macfilter(struct net_device *netdev, const u8 *mac);
int otx2_enable_rxvlan(struct otx2_nic *pf, bool enable);
int otx2_install_rxvlan_offload_flow(struct otx2_nic *pfvf);
-
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf);
#endif /* OTX2_COMMON_H */
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
[net-next v3 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max MTU of 16K on LMAC links and 64k on LBK
links and Octeontx2 silicon supports 9K mtu on both links.
Get the same from nix_get_hw_info mbox message in netdev probe.
This patch also calculates receive buffer size required based
on the MTU set.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.c | 43 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.h | 2 +-
.../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 35 --
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.c | 27 ++
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../net/ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 95 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index 70548d1..da82f9f 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index fe62bfd..c496629 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -217,7 +217,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -592,7 +591,7 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
|
OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
@@ -1619,6 +1618,46 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+EXPORT_SYMBOL(otx2_get_max_mtu);
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index b6bdc6f..1cc7772 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -790,5 +790,5 @@ int otx2_del_macfilter(struct net_device *netdev, const u8
*mac);
int otx2_add_macfilter(struct net_device *netdev, const u8 *mac);
int otx2_enable_rxvlan(struct otx2_nic *pf, bool enable);
int otx2_install_rxvlan_offload_flow(struct otx2_nic *pfvf);
-
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf);
#endif /* OTX2_COMMON_H */
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
[net-next v2 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max MTU of 16K on LMAC links and 64k on LBK
links and Octeontx2 silicon supports 9K mtu on both links.
Get the same from nix_get_hw_info mbox message in netdev probe.
This patch also calculates receive buffer size required based
on the MTU set.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.c | 43 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.h | 2 +-
.../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 33 +++--
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.c | 27 ++
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../net/ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 93 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index 1c7d478..238238b 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index 2accdc7..f5b3074 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -217,7 +217,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -591,7 +590,7 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
|
OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
@@ -1618,6 +1617,46 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+EXPORT_SYMBOL(otx2_get_max_mtu);
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index b6bdc6f..1cc7772 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -790,5 +790,5 @@ int otx2_del_macfilter(struct net_device *netdev, const u8
*mac);
int otx2_add_macfilter(struct net_device *netdev, const u8 *mac);
int otx2_enable_rxvlan(struct otx2_nic *pf, bool enable);
int otx2_install_rxvlan_offload_flow(struct otx2_nic *pfvf);
-
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf);
#endif /* OTX2_COMMON_H */
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
[net-next 11/14] octeontx2-pf: cn10k: Get max mtu supported from admin function
From: Hariprasad Kelam
CN10K supports max mtu of 16K on lmac links and 64k on lbk
links and Octeontx2 silicon supports 9K mtu on both links. Get the same
from nix_get_hw_info mbox message in netdev probe.
remove updating port field value in ethtool(get_link_ksettings) as
firmware does not support the same.
octeontx2-pf: Use multi segments in NIX CQE_RX
To receive frame sizes upto 64K a single receive
packet buffer is not sufficient because maximum
receive buffer size which can be set is 32K
(configured in NIX_RQ_CTX_S[LPB_SIZEM1]<35:24>).
Hardware transfers bigger frames using RX scatter
gather and writes the CQE RX descriptor with
addresses of all the segments of the packet.
This patch modifies current code to read
all the segments in CQE_RX and to use fixed
size packet receive buffers of 4K.
Signed-off-by: Hariprasad Kelam
Signed-off-by: Subbaraya Sundeep
Signed-off-by: Geetha sowjanya
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c | 2 +-
.../ethernet/marvell/octeontx2/nic/otx2_common.c | 42 --
.../ethernet/marvell/octeontx2/nic/otx2_common.h | 2 +-
.../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 29 ---
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.c | 27 ++
.../net/ethernet/marvell/octeontx2/nic/otx2_txrx.h | 1 -
.../net/ethernet/marvell/octeontx2/nic/otx2_vf.c | 2 +-
7 files changed, 88 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
index 1c7d478..238238b 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/cn10k.c
@@ -108,7 +108,7 @@ int cn10k_sq_aq_init(void *dev, u16 qidx, u16 sqb_aura)
/* Only one SMQ is allocated, map all SQ's to that SMQ */
aq->sq.smq = pfvf->hw.txschq_list[NIX_TXSCH_LVL_SMQ][0];
/* FIXME: set based on NIX_AF_DWRR_RPM_MTU*/
- aq->sq.smq_rr_weight = OTX2_MAX_MTU;
+ aq->sq.smq_rr_weight = pfvf->netdev->mtu;
aq->sq.default_chan = pfvf->hw.tx_chan_base;
aq->sq.sqe_stype = NIX_STYPE_STF; /* Cache SQB */
aq->sq.sqb_aura = sqb_aura;
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index 2accdc7..61aea78 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -217,7 +217,6 @@ int otx2_hw_set_mtu(struct otx2_nic *pfvf, int mtu)
return -ENOMEM;
}
- pfvf->max_frs = mtu + OTX2_ETH_HLEN;
req->maxlen = pfvf->max_frs;
err = otx2_sync_mbox_msg(>mbox);
@@ -591,7 +590,7 @@ int otx2_txschq_config(struct otx2_nic *pfvf, int lvl)
/* Set topology e.t.c configuration */
if (lvl == NIX_TXSCH_LVL_SMQ) {
req->reg[0] = NIX_AF_SMQX_CFG(schq);
- req->regval[0] = ((OTX2_MAX_MTU + OTX2_ETH_HLEN) << 8) |
+ req->regval[0] = ((pfvf->netdev->max_mtu + OTX2_ETH_HLEN) << 8)
|
OTX2_MIN_MTU;
req->regval[0] |= (0x20ULL << 51) | (0x80ULL << 39) |
@@ -1618,6 +1617,45 @@ void otx2_set_cints_affinity(struct otx2_nic *pfvf)
}
}
+u16 otx2_get_max_mtu(struct otx2_nic *pfvf)
+{
+ struct nix_hw_info *rsp;
+ struct msg_req *req;
+ u16 max_mtu;
+ int rc;
+
+ mutex_lock(>mbox.lock);
+
+ req = otx2_mbox_alloc_msg_nix_get_hw_info(>mbox);
+ if (!req) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ rc = otx2_sync_mbox_msg(>mbox);
+ if (!rc) {
+ rsp = (struct nix_hw_info *)
+ otx2_mbox_get_rsp(>mbox.mbox, 0, >hdr);
+
+ /* HW counts VLAN insertion bytes (8 for double tag)
+* irrespective of whether SQE is requesting to insert VLAN
+* in the packet or not. Hence these 8 bytes have to be
+* discounted from max packet size otherwise HW will throw
+* SMQ errors
+*/
+ max_mtu = rsp->max_mtu - 8 - OTX2_ETH_HLEN;
+ }
+
+out:
+ mutex_unlock(>mbox.lock);
+ if (rc) {
+ dev_warn(pfvf->dev,
+"Failed to get MTU from hardware setting default
value(1500)\n");
+ max_mtu = 1500;
+ }
+ return max_mtu;
+}
+
#define M(_name, _id, _fn_name, _req_type, _rsp_type) \
int __weak \
otx2_mbox_up_handler_ ## _fn_name(struct otx2_nic *pfvf, \
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index b6bdc6f..1cc7772 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++
[PATCH 2/2] Documentation: admin-guide: Update kvm/xen config option
Since commit 9bba03d4473d ("kconfig: remove 'kvmconfig' and 'xenconfig'
shorthands") kvm/xen config shortcuts are not available anymore. Update
the file to reflect how they should be used, with the full filename.
Signed-off-by: André Almeida
---
Documentation/admin-guide/README.rst | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/README.rst
b/Documentation/admin-guide/README.rst
index 261b7b4cca1f..35314b63008c 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -226,10 +226,11 @@ Configuring the kernel
all module options to built in (=y) options. You can
also preserve modules by LMC_KEEP.
- "make kvmconfig" Enable additional options for kvm guest kernel support.
+ "make kvm_guest.config" Enable additional options for kvm guest kernel
+ support.
- "make xenconfig" Enable additional options for xen dom0 guest kernel
-support.
+ "make xen.config" Enable additional options for xen dom0 guest kernel
+ support.
"make tinyconfig" Configure the tiniest possible kernel.
--
2.30.0
Re: [PATCH] Update Documentation/admin-guide/sysctl/fs.rst
On Wed, 20 Jan 2021 13:26:47 + Eric Curtin wrote: > max_user_watches for epoll should say 1/25, rather than 1/32 > > Signed-off-by: Eric Curtin > --- > Documentation/admin-guide/sysctl/fs.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/sysctl/fs.rst > b/Documentation/admin-guide/sysctl/fs.rst > index f48277a0a850..2a501c9ddc55 100644 > --- a/Documentation/admin-guide/sysctl/fs.rst > +++ b/Documentation/admin-guide/sysctl/fs.rst > @@ -380,5 +380,5 @@ This configuration option sets the maximum number of > "watches" that are > allowed for each user. > Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes > on a 64bit one. > -The current default value for max_user_watches is the 1/32 of the available > -low memory, divided for the "watch" cost in bytes. > +The current default value for max_user_watches is the 1/25 (4%) of the > +available low memory, divided for the "watch" cost in bytes. That does appear to be the way of it...patch applied, thanks. jon
Re: [PATCH v2] Documentation/admin-guide: kernel-parameters: update CMA entries
On Sun, 24 Jan 2021 20:32:02 -0800 Randy Dunlap wrote: > Add qualifying build option legend [CMA] to kernel boot options > that requirce CMA support to be enabled for them to be usable. > > Also capitalize 'CMA' when it is used as an acronym. > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: linux...@kvack.org > Cc: Andrew Morton > Cc: Mike Kravetz > --- > v2: rebase & resend > > Documentation/admin-guide/kernel-parameters.txt |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Applied, thanks. jon
Re: [PATCH v4 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote: > Since #DB for bus lock detect changes the split_lock_detect parameter, > update the documentation for the changes. Why is this seperate and an all in one thing? patch 2/4 changes the parameter first and 3/4 adds a new option > > Signed-off-by: Fenghua Yu > Reviewed-by: Tony Luck > Acked-by: Randy Dunlap > --- > Change Log: > v4: > - Fix a ratelimit wording issue in the doc (Randy). > - Patch 4 is acked by Randy (Randy). > > v3: > - Enable Bus Lock Detection when fatal to handle bus lock from non-WB > (PeterZ). > > v1: > - Fix a few wording issues (Randy). > > RFC v2: > - Simplify the documentation (Randy). > > .../admin-guide/kernel-parameters.txt | 30 +++ > 1 file changed, 24 insertions(+), 6 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 44fde25bb221..28228539b02a 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -5051,27 +5051,45 @@ > spia_peddr= > + > + ratelimit:N - > + Set rate limit to N bus locks per second > + for bus lock detection. 0 < N <= HZ/2. Oh well. So if I have ratelimit:500 on the kernel command line and then this works for CONFIG_HZ=1000, but after rebuilding the kernel with HZ=250 it fails. What? If I allow 500 hits per second then CONFIG_HZ has absolutely nothing to do with it. A second stays a second independent of CONFIG_HZ. So what's the purpose of this HZ business? Thanks, tglx
Re: [PATCH v2] Documentation/admin-guide: kernel-parameters: update CMA entries
On 1/24/21 8:32 PM, Randy Dunlap wrote: > Add qualifying build option legend [CMA] to kernel boot options > that requirce CMA support to be enabled for them to be usable. > > Also capitalize 'CMA' when it is used as an acronym. > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: linux...@kvack.org > Cc: Andrew Morton > Cc: Mike Kravetz > --- > v2: rebase & resend > > Documentation/admin-guide/kernel-parameters.txt |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks, Acked-by: Mike Kravetz -- Mike Kravetz > > --- linux-next-20210122.orig/Documentation/admin-guide/kernel-parameters.txt > +++ linux-next-20210122/Documentation/admin-guide/kernel-parameters.txt > @@ -631,7 +631,7 @@ > kernel/dma/contiguous.c > > cma_pernuma=nn[MG] > - [ARM64,KNL] > + [ARM64,KNL,CMA] > Sets the size of kernel per-numa memory area for > contiguous memory allocations. A value of 0 disables > per-numa CMA altogether. And If this option is not > @@ -1556,12 +1556,12 @@ > hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET > registers. Default set by CONFIG_HPET_MMAP_DEFAULT. > > - hugetlb_cma=[HW] The size of a cma area used for allocation > + hugetlb_cma=[HW,CMA] The size of a CMA area used for allocation > of gigantic hugepages. > Format: nn[KMGTPE] > > - Reserve a cma area of given size and allocate gigantic > - hugepages using the cma allocator. If enabled, the > + Reserve a CMA area of given size and allocate gigantic > + hugepages using the CMA allocator. If enabled, the > boot-time allocation of gigantic hugepages is skipped. > > hugepages= [HW] Number of HugeTLB pages to allocate at boot. >
[PATCH v2] Documentation/admin-guide: kernel-parameters: update CMA entries
Add qualifying build option legend [CMA] to kernel boot options that requirce CMA support to be enabled for them to be usable. Also capitalize 'CMA' when it is used as an acronym. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: linux...@kvack.org Cc: Andrew Morton Cc: Mike Kravetz --- v2: rebase & resend Documentation/admin-guide/kernel-parameters.txt |8 1 file changed, 4 insertions(+), 4 deletions(-) --- linux-next-20210122.orig/Documentation/admin-guide/kernel-parameters.txt +++ linux-next-20210122/Documentation/admin-guide/kernel-parameters.txt @@ -631,7 +631,7 @@ kernel/dma/contiguous.c cma_pernuma=nn[MG] - [ARM64,KNL] + [ARM64,KNL,CMA] Sets the size of kernel per-numa memory area for contiguous memory allocations. A value of 0 disables per-numa CMA altogether. And If this option is not @@ -1556,12 +1556,12 @@ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET registers. Default set by CONFIG_HPET_MMAP_DEFAULT. - hugetlb_cma=[HW] The size of a cma area used for allocation + hugetlb_cma=[HW,CMA] The size of a CMA area used for allocation of gigantic hugepages. Format: nn[KMGTPE] - Reserve a cma area of given size and allocate gigantic - hugepages using the cma allocator. If enabled, the + Reserve a CMA area of given size and allocate gigantic + hugepages using the CMA allocator. If enabled, the boot-time allocation of gigantic hugepages is skipped. hugepages= [HW] Number of HugeTLB pages to allocate at boot.
[PATCH] Update Documentation/admin-guide/sysctl/fs.rst
max_user_watches for epoll should say 1/25, rather than 1/32 Signed-off-by: Eric Curtin --- Documentation/admin-guide/sysctl/fs.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst index f48277a0a850..2a501c9ddc55 100644 --- a/Documentation/admin-guide/sysctl/fs.rst +++ b/Documentation/admin-guide/sysctl/fs.rst @@ -380,5 +380,5 @@ This configuration option sets the maximum number of "watches" that are allowed for each user. Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes on a 64bit one. -The current default value for max_user_watches is the 1/32 of the available -low memory, divided for the "watch" cost in bytes. +The current default value for max_user_watches is the 1/25 (4%) of the +available low memory, divided for the "watch" cost in bytes. -- 2.25.1
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..b57b30c7125f 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl +command option should be added for generating CodeSign extended key usage in +X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
Re: [PATCH] docs: admin-guide: bootconfig: Fix feils to fails
On Thu, 7 Jan 2021 18:26:10 +0530 Bhaskar Chowdhury wrote: > s/feils/fails/p > > Signed-off-by: Bhaskar Chowdhury > --- > Documentation/admin-guide/bootconfig.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/bootconfig.rst > b/Documentation/admin-guide/bootconfig.rst > index 9b90efcc3a35..452b7dcd7f6b 100644 > --- a/Documentation/admin-guide/bootconfig.rst > +++ b/Documentation/admin-guide/bootconfig.rst > @@ -154,7 +154,7 @@ get the boot configuration data. > Because of this "piggyback" method, there is no need to change or > update the boot loader and the kernel image itself as long as the boot > loader passes the correct initrd file size. If by any chance, the boot > -loader passes a longer size, the kernel feils to find the bootconfig data. > +loader passes a longer size, the kernel fails to find the bootconfig data. Applied, thanks. jon
Re: [PATCH v2] Documentation/admin-guide: kernel-parameters: hyphenate comma-separated
On Thu, 31 Dec 2020 20:08:31 -0800 Randy Dunlap wrote: > Hyphenate "comma separated" when it is used as a compound adjective. > hyphenated. > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > v2: rebase & resend > > Documentation/admin-guide/kernel-parameters.txt | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Applied, thanks. jon
Re: [PATCH] docs: admin-guide: bootconfig: Fix feils to fails
On 1/7/21 4:56 AM, Bhaskar Chowdhury wrote: > s/feils/fails/p > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap Thanks. > --- > Documentation/admin-guide/bootconfig.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/bootconfig.rst > b/Documentation/admin-guide/bootconfig.rst > index 9b90efcc3a35..452b7dcd7f6b 100644 > --- a/Documentation/admin-guide/bootconfig.rst > +++ b/Documentation/admin-guide/bootconfig.rst > @@ -154,7 +154,7 @@ get the boot configuration data. > Because of this "piggyback" method, there is no need to change or > update the boot loader and the kernel image itself as long as the boot > loader passes the correct initrd file size. If by any chance, the boot > -loader passes a longer size, the kernel feils to find the bootconfig data. > +loader passes a longer size, the kernel fails to find the bootconfig data. > > To do this operation, Linux kernel provides "bootconfig" command under > tools/bootconfig, which allows admin to apply or delete the config file > -- > 2.30.0 > -- ~Randy
[PATCH] docs: admin-guide: bootconfig: Fix feils to fails
s/feils/fails/p Signed-off-by: Bhaskar Chowdhury --- Documentation/admin-guide/bootconfig.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index 9b90efcc3a35..452b7dcd7f6b 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -154,7 +154,7 @@ get the boot configuration data. Because of this "piggyback" method, there is no need to change or update the boot loader and the kernel image itself as long as the boot loader passes the correct initrd file size. If by any chance, the boot -loader passes a longer size, the kernel feils to find the bootconfig data. +loader passes a longer size, the kernel fails to find the bootconfig data. To do this operation, Linux kernel provides "bootconfig" command under tools/bootconfig, which allows admin to apply or delete the config file -- 2.30.0
[PATCH v2] Documentation/admin-guide: kernel-parameters: hyphenate comma-separated
Hyphenate "comma separated" when it is used as a compound adjective. hyphenated. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- v2: rebase & resend Documentation/admin-guide/kernel-parameters.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- lnx-511-rc1.orig/Documentation/admin-guide/kernel-parameters.txt +++ lnx-511-rc1/Documentation/admin-guide/kernel-parameters.txt @@ -1385,7 +1385,7 @@ ftrace_filter=[function-list] [FTRACE] Limit the functions traced by the function - tracer at boot up. function-list is a comma separated + tracer at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the set_ftrace_filter file in the debugfs tracing directory. @@ -1399,13 +1399,13 @@ ftrace_graph_filter=[function-list] [FTRACE] Limit the top level callers functions traced by the function graph tracer at boot up. - function-list is a comma separated list of functions + function-list is a comma-separated list of functions that can be changed at run time by the set_graph_function file in the debugfs tracing directory. ftrace_graph_notrace=[function-list] [FTRACE] Do not trace from the functions specified in - function-list. This list is a comma separated list of + function-list. This list is a comma-separated list of functions that can be changed at run time by the set_graph_notrace file in the debugfs tracing directory. @@ -2421,7 +2421,7 @@ when set. Format: - libata.force= [LIBATA] Force configurations. The format is comma + libata.force= [LIBATA] Force configurations. The format is comma- separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches @@ -5145,7 +5145,7 @@ stacktrace_filter=[function-list] [FTRACE] Limit the functions that the stack tracer - will trace at boot up. function-list is a comma separated + will trace at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the stack_trace_filter file in the debugfs tracing directory. Note, this enables stack tracing @@ -5348,7 +5348,7 @@ trace_event=[event-list] [FTRACE] Set and start specified trace events in order to facilitate early boot debugging. The event-list is a - comma separated list of trace events to enable. See + comma-separated list of trace events to enable. See also Documentation/trace/events.rst trace_options=[option-list]
Re: [PATCH] Documentation: admin: early_param()s are also listed in kernel-parameters
On Sat, 26 Dec 2020 09:44:33 -0800 Randy Dunlap wrote: > Add info that "early_param()" kernel boot parameters are also listed > in kernel-parameters.txt. > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > --- > Documentation/admin-guide/kernel-parameters.rst |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- linux-next-20201223.orig/Documentation/admin-guide/kernel-parameters.rst > +++ linux-next-20201223/Documentation/admin-guide/kernel-parameters.rst > @@ -3,8 +3,8 @@ > The kernel's command-line parameters > > > -The following is a consolidated list of the kernel parameters as > -implemented by the __setup(), core_param() and module_param() macros > +The following is a consolidated list of the kernel parameters as implemented > +by the __setup(), early_param(), core_param() and module_param() macros Applied, thanks. jon
[PATCH] Documentation: admin: early_param()s are also listed in kernel-parameters
Add info that "early_param()" kernel boot parameters are also listed in kernel-parameters.txt. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20201223.orig/Documentation/admin-guide/kernel-parameters.rst +++ linux-next-20201223/Documentation/admin-guide/kernel-parameters.rst @@ -3,8 +3,8 @@ The kernel's command-line parameters -The following is a consolidated list of the kernel parameters as -implemented by the __setup(), core_param() and module_param() macros +The following is a consolidated list of the kernel parameters as implemented +by the __setup(), early_param(), core_param() and module_param() macros and sorted into English Dictionary order (defined as ignoring all punctuation and sorting digits before letters in a case insensitive manner), and with descriptions where known.
