linux-kernel - Re: [PATCH 4.19 063/422] ice: Prevent control queue operations during reset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Nov 2019 15:52:18 -0800
From:   Jeff Kirsher <jeffrey.t.kirsher@...el.com>
To:     Pavel Machek <pavel@...x.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Anirudh Venkataramanan <anirudh.venkataramanan@...el.com>,
        Tony Brelinski <tonyx.brelinski@...el.com>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 063/422] ice: Prevent control queue operations
 during reset

On Wed, 2019-11-20 at 22:48 +0100, Pavel Machek wrote:
> Hi!
> > [ Upstream commit fd2a981777d911b2e94cdec50779c85c58a0dec9 ]
> > 
> > Once reset is issued, the driver loses all control queue interfaces.
> > Exercising control queue operations during reset is incorrect and
> > may result in long timeouts.
> > 
> > This patch introduces a new field 'reset_ongoing' in the hw structure.
> > This is set to 1 by the core driver when it receives a reset interrupt.
> > ice_sq_send_cmd checks reset_ongoing before actually issuing the
> > control
> > queue operation. If a reset is in progress, it returns a soft error
> > code
> > (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have
> > to
> > take any action based on this return. Once the driver knows that the
> > reset is done, it has to set reset_ongoing back to 0. This will allow
> > control queue operations to be posted to the hardware again.
> > 
> > This "bail out" logic was specifically added to ice_sq_send_cmd (which
> > is pretty low level function) so that we have one solution in one place
> > that applies to all types of control queues.
> 
> I don't think this is suitable for stable. Would driver maintainers
> comment?

Actually this change is fine for stable.

> 
> > +			 *
> > +			 * As this is the start of the reset/rebuild cycle,
> > set
> > +			 * both to indicate that.
> > +			 */
> > +			hw->reset_ongoing = true;
> >  		}
> >  	}
> 
> This should be = 1, since variable is u8...

This variable is treated as a bool, and since bools vary depending on
architecture, Linus has stated that using a u8 would be more consistent
across the vary architectures.  So we have used u8's for variables treated
as bools.

In addition, there has been no issue assigning "true" or "false" to a u8.

> 
> Best regards,
> 									Pav
> el     	       
> 
> > +++ b/drivers/net/ethernet/intel/ice/ice_type.h
> > @@ -293,6 +293,7 @@ struct ice_hw {
> >  	u8 sw_entry_point_layer;
> >  
> >  	u8 evb_veb;		/* true for VEB, false for VEPA */
> > +	u8 reset_ongoing;	/* true if hw is in reset, false otherwise */
> >  	struct ice_bus_info bus;
> >  	struct ice_nvm_info nvm;
> >  	struct ice_hw_dev_caps dev_caps;	/* device capabilities */
> > -- 


Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)