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]
Message-ID: <20191217115211.GA3141324@kroah.com>
Date:   Tue, 17 Dec 2019 12:52:11 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Jérôme Pouiller <Jerome.Pouiller@...abs.com>
Cc:     "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Kalle Valo <kvalo@...eaurora.org>
Subject: Re: [PATCH 01/55] staging: wfx: fix the cache of rate policies on
 interface reset

On Mon, Dec 16, 2019 at 05:03:33PM +0000, Jérôme Pouiller wrote:
> From: Jérôme Pouiller <jerome.pouiller@...abs.com>
> 
> Device and driver maintain a cache of rate policies (aka.
> tx_retry_policy in hardware API).
> 
> When hif_reset() is sent to hardware, device resets its cache of rate
> policies. In order to keep driver in sync, it is necessary to do the
> same on driver.
> 
> Note, when driver tries to use a rate policy that has not been defined
> on device, data is sent at 1Mbps. So, this patch should fix abnormal
> throughput observed sometime after a reset of the interface.
> 
> Signed-off-by: Jérôme Pouiller <jerome.pouiller@...abs.com>
> ---
>  drivers/staging/wfx/data_tx.c | 3 +--
>  drivers/staging/wfx/data_tx.h | 1 +
>  drivers/staging/wfx/sta.c     | 6 +++++-
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/wfx/data_tx.c b/drivers/staging/wfx/data_tx.c
> index b722e9773232..02f001dab62b 100644
> --- a/drivers/staging/wfx/data_tx.c
> +++ b/drivers/staging/wfx/data_tx.c
> @@ -249,7 +249,7 @@ static int wfx_tx_policy_upload(struct wfx_vif *wvif)
>  	return 0;
>  }
>  
> -static void wfx_tx_policy_upload_work(struct work_struct *work)
> +void wfx_tx_policy_upload_work(struct work_struct *work)
>  {
>  	struct wfx_vif *wvif =
>  		container_of(work, struct wfx_vif, tx_policy_upload_work);
> @@ -270,7 +270,6 @@ void wfx_tx_policy_init(struct wfx_vif *wvif)
>  	spin_lock_init(&cache->lock);
>  	INIT_LIST_HEAD(&cache->used);
>  	INIT_LIST_HEAD(&cache->free);
> -	INIT_WORK(&wvif->tx_policy_upload_work, wfx_tx_policy_upload_work);
>  
>  	for (i = 0; i < HIF_MIB_NUM_TX_RATE_RETRY_POLICIES; ++i)
>  		list_add(&cache->cache[i].link, &cache->free);
> diff --git a/drivers/staging/wfx/data_tx.h b/drivers/staging/wfx/data_tx.h
> index 29faa5640516..a0f9ae69baf5 100644
> --- a/drivers/staging/wfx/data_tx.h
> +++ b/drivers/staging/wfx/data_tx.h
> @@ -61,6 +61,7 @@ struct wfx_tx_priv {
>  } __packed;
>  
>  void wfx_tx_policy_init(struct wfx_vif *wvif);
> +void wfx_tx_policy_upload_work(struct work_struct *work);
>  
>  void wfx_tx(struct ieee80211_hw *hw, struct ieee80211_tx_control *control,
>  	    struct sk_buff *skb);
> diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
> index 29848a202ab4..471dd15b227f 100644
> --- a/drivers/staging/wfx/sta.c
> +++ b/drivers/staging/wfx/sta.c
> @@ -592,6 +592,7 @@ static void wfx_do_unjoin(struct wfx_vif *wvif)
>  	wfx_tx_flush(wvif->wdev);
>  	hif_keep_alive_period(wvif, 0);
>  	hif_reset(wvif, false);
> +	wfx_tx_policy_init(wvif);
>  	hif_set_output_power(wvif, wvif->wdev->output_power * 10);
>  	wvif->dtim_period = 0;
>  	hif_set_macaddr(wvif, wvif->vif->addr);
> @@ -880,8 +881,10 @@ static int wfx_update_beaconing(struct wfx_vif *wvif)
>  		if (wvif->state != WFX_STATE_AP ||
>  		    wvif->beacon_int != conf->beacon_int) {
>  			wfx_tx_lock_flush(wvif->wdev);
> -			if (wvif->state != WFX_STATE_PASSIVE)
> +			if (wvif->state != WFX_STATE_PASSIVE) {
>  				hif_reset(wvif, false);
> +				wfx_tx_policy_init(wvif);
> +			}
>  			wvif->state = WFX_STATE_PASSIVE;
>  			wfx_start_ap(wvif);
>  			wfx_tx_unlock(wvif->wdev);
> @@ -1567,6 +1570,7 @@ int wfx_add_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
>  	INIT_WORK(&wvif->set_cts_work, wfx_set_cts_work);
>  	INIT_WORK(&wvif->unjoin_work, wfx_unjoin_work);
>  
> +	INIT_WORK(&wvif->tx_policy_upload_work, wfx_tx_policy_upload_work);
>  	mutex_unlock(&wdev->conf_mutex);
>  
>  	hif_set_macaddr(wvif, vif->addr);

Meta-comment here.

I've been having to hand-edit your patches to get them to be able to
apply so far, which is fine for 1-10 patches at a time, but when staring
down a 55-patch series, that's not ok for my end.

The problem is that your email client is turning everything into base64
text.  On it's own, that's fine, but when doing so it turns the
line-ends from unix ones, into dos line-ends.  So, when git decodes the
base64 text into "plain text" the patch obviously does not apply due to
the line-ends not matching up.

Any chance you can fix your email client to not convert the line-ends?

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ