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: <D5ECB3C7A6F99444980976A8C6D896384DF0D6F721@EAPEX1MAIL1.st.com>
Date:	Thu, 24 Mar 2011 13:43:06 +0800
From:	Bhupesh SHARMA <bhupesh.sharma@...com>
To:	Jan Altenberg <jan@...utronix.de>
Cc:	"wg@...ndegger.com" <wg@...ndegger.com>,
	"kurt.van.dijck@....be" <kurt.van.dijck@....be>,
	"b.spranger@...utronix.de" <b.spranger@...utronix.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Socketcan-core@...ts.berlios.de" <Socketcan-core@...ts.berlios.de>
Subject: RE: c_can: TX handling

Hi Jan,

> > I did some more testing on the SocketCAN driver for the Bosch c_can
> > controller and I observed some strange behaviour for the TX handling.
> > First of all the TX bytes are not accounted correctly. The reason for
> > that
> > seems to be quite obvious if we look into c_can_do_tx():
> >
> > [...]
> >
> > c_can_inval_msg_object(dev, 0, msg_obj_no);
> > val = c_can_read_reg32(priv, &priv->regs->txrqst1);
> > if (!(val & (1 << msg_obj_no))) {
> >         can_get_echo_skb(dev,
> >                         msg_obj_no - C_CAN_MSG_OBJ_TX_FIRST);
> >         stats->tx_bytes += priv->read_reg(priv,
> >                         &priv->regs->ifregs[0].msg_cntrl)
> >                         & IF_MCONT_DLC_MASK;
> >
> > So, we first invalidate the message object and afterwards we read the
> > DLC
> > value from the msg_cntrl (which is 0 after invalidating the
> > message object) to account the TX bytes. So tx_bytes will always be
> 0.
> > The
> > fix should be easy, I think, we can just move
> > c_can_inval_msg_object to the end of that loop.
> 
> Hmmm..
> As far as I remember, *ifconfig* used to provide the correct tx_bytes
> stats
> on my SPEAr board. Let me recheck this again today evening and get back
> to you.

I managed to get hold of one SPEAr board and did some quick tests.
Indeed the tx_bytes field is 0 when we execute *ifconfig*

I think the easy fix would be to add c_can_inval_msg_object(dev, 0, msg_obj_no);
call inside the *if* construct. Could you please prepare a patch after
testing the same at your end.

Regards,
Bhupesh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ