All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] ipw2x00: shift wrap bugs setting ->rt_tsf
Date: Mon, 27 Oct 2014 15:05:27 +0000	[thread overview]
Message-ID: <1414422327.8884.8.camel@perches.com> (raw)
In-Reply-To: <20141027095243.GA6890@mwanda>

On Mon, 2014-10-27 at 12:52 +0300, Dan Carpenter wrote:
> On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> > On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct ipw_priv *priv,
> > >  
> > >  	/* Zero the flags, we'll add to them as we go */
> > >  	ipw_rt->rt_flags = 0;
> > > -	ipw_rt->rt_tsf = (u64)(frame->parent_tsf[3] << 24 |
> > > -			       frame->parent_tsf[2] << 16 |
> > > -			       frame->parent_tsf[1] << 8  |
> > > -			       frame->parent_tsf[0]);
> > > +	ipw_rt->rt_tsf = (u64)frame->parent_tsf[3] << 24 |
> > > +			      frame->parent_tsf[2] << 16 |
> > > +			      frame->parent_tsf[1] << 8  |
> > > +			      frame->parent_tsf[0];
> > >  
> > >  	/* Convert to DBM */
> > >  	ipw_rt->rt_dbmsignal = signal;
> > 
> > struct ipw_rt_hdr {
> > 	struct ieee80211_radiotap_header rt_hdr;
> > 	u64 rt_tsf;      /* TSF */	/* XXX */
> > 	u8 rt_flags;	/* radiotap packet flags *
> > 	u8 rt_rate;	/* rate in 500kb/s */
> > 	__le16 rt_channel;	/* channel in mhz */
> > 	__le16 rt_chbitmask;	/* channel bitfield */
> > 	s8 rt_dbmsignal;	/* signal in dbM, kluged to signed */
> > 	s8 rt_dbmnoise;
> > 	u8 rt_antenna;	/* antenna number */
> > 	u8 payload[0];  /* payload... */
> > } __packed;
> > 
> > Maybe rt_tsf (which is otherwise unused in this code),
> > should be __le64 so maybe use (u32) ?
> > 
> > 	ipw_rt->rt_txf = cpu_to_le64((u32)(frame->parent_tsf[3] << 24 |
> > 					   frame->parent_tsf[2] << 16 |
> > 					   frame->parent_tsf[1] << 8  |
> > 					   frame->parent_tsf[0]));
> > 
> 
> Hm...  It don't think it makes sense to truncate the top bits away by
> truncating to u32.  You may be right though that there is some larger
> bugs here than just the truncation.

<shrug>  It'd be a tad faster than using multiple 64 bit
operations on a 32 bit machine.

> Both the "frame" and the "ipw_rt" struct seem to hold little endian
> values generally so probably ->rt_txf should be an __le64 like you say.
>   
> Perhaps the maintainers know what should be done?

Are there any maintainers left?

Likely this was only ever tested/used on x86 hardware.



WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] ipw2x00: shift wrap bugs setting ->rt_tsf
Date: Mon, 27 Oct 2014 08:05:27 -0700	[thread overview]
Message-ID: <1414422327.8884.8.camel@perches.com> (raw)
In-Reply-To: <20141027095243.GA6890@mwanda>

On Mon, 2014-10-27 at 12:52 +0300, Dan Carpenter wrote:
> On Fri, Oct 24, 2014 at 02:43:31AM -0700, Joe Perches wrote:
> > On Fri, 2014-10-24 at 11:15 +0300, Dan Carpenter wrote:
> > > @@ -8028,10 +8028,10 @@ static void ipw_handle_promiscuous_rx(struct ipw_priv *priv,
> > >  
> > >  	/* Zero the flags, we'll add to them as we go */
> > >  	ipw_rt->rt_flags = 0;
> > > -	ipw_rt->rt_tsf = (u64)(frame->parent_tsf[3] << 24 |
> > > -			       frame->parent_tsf[2] << 16 |
> > > -			       frame->parent_tsf[1] << 8  |
> > > -			       frame->parent_tsf[0]);
> > > +	ipw_rt->rt_tsf = (u64)frame->parent_tsf[3] << 24 |
> > > +			      frame->parent_tsf[2] << 16 |
> > > +			      frame->parent_tsf[1] << 8  |
> > > +			      frame->parent_tsf[0];
> > >  
> > >  	/* Convert to DBM */
> > >  	ipw_rt->rt_dbmsignal = signal;
> > 
> > struct ipw_rt_hdr {
> > 	struct ieee80211_radiotap_header rt_hdr;
> > 	u64 rt_tsf;      /* TSF */	/* XXX */
> > 	u8 rt_flags;	/* radiotap packet flags *
> > 	u8 rt_rate;	/* rate in 500kb/s */
> > 	__le16 rt_channel;	/* channel in mhz */
> > 	__le16 rt_chbitmask;	/* channel bitfield */
> > 	s8 rt_dbmsignal;	/* signal in dbM, kluged to signed */
> > 	s8 rt_dbmnoise;
> > 	u8 rt_antenna;	/* antenna number */
> > 	u8 payload[0];  /* payload... */
> > } __packed;
> > 
> > Maybe rt_tsf (which is otherwise unused in this code),
> > should be __le64 so maybe use (u32) ?
> > 
> > 	ipw_rt->rt_txf = cpu_to_le64((u32)(frame->parent_tsf[3] << 24 |
> > 					   frame->parent_tsf[2] << 16 |
> > 					   frame->parent_tsf[1] << 8  |
> > 					   frame->parent_tsf[0]));
> > 
> 
> Hm...  It don't think it makes sense to truncate the top bits away by
> truncating to u32.  You may be right though that there is some larger
> bugs here than just the truncation.

<shrug>  It'd be a tad faster than using multiple 64 bit
operations on a 32 bit machine.

> Both the "frame" and the "ipw_rt" struct seem to hold little endian
> values generally so probably ->rt_txf should be an __le64 like you say.
>   
> Perhaps the maintainers know what should be done?

Are there any maintainers left?

Likely this was only ever tested/used on x86 hardware.



  reply	other threads:[~2014-10-27 15:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24  8:15 [patch] ipw2x00: shift wrap bugs setting ->rt_tsf Dan Carpenter
2014-10-24  8:15 ` Dan Carpenter
2014-10-24  9:43 ` Joe Perches
2014-10-24  9:43   ` Joe Perches
2014-10-27  9:52   ` Dan Carpenter
2014-10-27  9:52     ` Dan Carpenter
2014-10-27 15:05     ` Joe Perches [this message]
2014-10-27 15:05       ` Joe Perches
2014-10-27 15:18       ` Dan Carpenter
2014-10-27 15:18         ` Dan Carpenter
2014-10-28  9:20   ` Stanislav Yakovlev
2014-10-28  9:20     ` Stanislav Yakovlev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1414422327.8884.8.camel@perches.com \
    --to=joe@perches.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=stas.yakovlev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.