netdev - Re: can: c_can: TX echo

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:	Wed, 23 Mar 2011 14:54:07 +0100
From:	"Jan Altenberg" <jan@...utronix.de>
To:	"Kurt Van Dijck" <kurt.van.dijck@....be>
Cc:	"Jan Altenberg" <jan@...utronix.de>, bhupesh.sharma@...com,
	wg@...ndegger.com, b.spranger@...utronix.de, netdev@...r.kernel.org
Subject: Re: can: c_can: TX echo

Hi,

>> 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.
>
> IMO, it looks necessary to call c_can_inval_msg_object inside the if
> (), after it has been transmitted. Otherwise, if for some other (TX)
> reason you get in this loop, you may clear a pending transmission?
> Again, I haven't read this one's datasheet. I was familiar with its
> predecessor.

I tried to check, but the datasheet is a bit unclear regarding that
point ;-) My interpretation is, that c_can_inval_msg_object()
shouldn't affect the txrqst bit, but nevertheless calling it inside
the if() statement would make the code more readable.

I can prepare a patch, but I'd like to wait for Wolfgang's / Bupesh's
feedback.

Cheers,
        Jan


--
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