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: <5E4F49720D0BAD499EE1F01232234BA877435B2797@AVEXMB1.qlogic.org>
Date:	Tue, 3 Jul 2012 12:38:04 -0700
From:	Jitendra Kalsaria <jitendra.kalsaria@...gic.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev <netdev@...r.kernel.org>,
	Ron Mercer <ron.mercer@...gic.com>,
	Dept-NX Linux NIC Driver 
	<Dept_NX_Linux_NIC_Driver@...gic.com>
Subject: RE: [PATCH net 1/7] qlge: Fixed packet transmit errors due to
 potential driver errors.


-----Original Message-----
>From: David Miller [mailto:davem@...emloft.net] 
>Sent: Monday, July 02, 2012 6:42 PM
>To: Jitendra Kalsaria
>Cc: netdev; Ron Mercer; Dept-NX Linux NIC Driver
>Subject: Re: [PATCH net 1/7] qlge: Fixed packet transmit errors due to potential driver errors.
>
>From: David Miller <davem@...emloft.net>
>Date: Mon, 02 Jul 2012 18:38:26 -0700 (PDT)
>
>> From: Jitendra Kalsaria <jitendra.kalsaria@...gic.com>
>> Date: Mon, 2 Jul 2012 18:30:47 -0700
>> 
>>> As per your comments, TX ring full is not expected behavior? All I
>>> can think of increasing the TX queue to 1024 and clean-up in timer
>>> instead of interrupt?
>> 
>> Your transmit function should never be invoked when the queue is
>> full, logic elsewhere in your driver should have stopped the queue
>> therefore preventing further invocations of your transmit function
>> until you wake the queue when space is liberated in the TX ring.
>
>BTW, did it even occur to you that there is a kernel log message here
>in this code path for a reason?
>
>That log message is there because this event is unexpected and a
>driver error.

I think my patch description might have been misleading. We are not fixing a logical problem but rather a statistics reporting problem. Our transmit function is not getting called when queue is full but when we stop the queue it increment tx_error statistic and one of our customers is running a test that deliberately floods the queue causing it to periodically be stopped. The customer has not reported logical problem with the test were driver perform very well but they merely pointed out that we were incorrectly reporting the queue full condition as a tx_error.

This patch was intended to remove the line that increments the tx_error statistic when the queue is correctly stopped.


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