* [PATCHv2] virtio-spec: virtio network device multiqueue support
From: Michael S. Tsirkin @ 2012-09-03 11:55 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, kvm, virtualization
At Jason's request, I am trying to help finalize the spec for
the new multiqueue feature.
Changes from Jason's rfc:
- reserved vq 3: this makes all rx vqs even and tx vqs odd, which
looks nicer to me.
- documented packet steering, added a generalized steering programming
command. Current modes are single queue and host driven multiqueue,
but I envision support for guest driven multiqueue in the future.
- make default vqs unused when in mq mode - this wastes some memory
but makes it more efficient to switch between modes as
we can avoid this causing packet reordering.
Rusty, could you please take a look and comment?
If this looks OK to everyone, we can proceed with finalizing the
implementation. This patch is against
eb9fc84d0d3c46438aaab190e2401a9e5409a052 in virtio-spec git tree.
-->
virtio-spec: virtio network device multiqueue support
Add multiqueue support to virtio network device.
Add a new feature flag VIRTIO_NET_F_MULTIQUEUE for this feature, a new
configuration field max_virtqueue_pairs to detect supported number of
virtqueues as well as a new command VIRTIO_NET_CTRL_STEERING to program
packet steering.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
--
diff --git a/virtio-spec.lyx b/virtio-spec.lyx
index 7a073f4..583debc 100644
--- a/virtio-spec.lyx
+++ b/virtio-spec.lyx
@@ -58,6 +58,7 @@
\html_be_strict false
\author -608949062 "Rusty Russell,,,"
\author 1531152142 "Paolo Bonzini,,,"
+\author 1986246365 "Michael S. Tsirkin"
\end_header
\begin_body
@@ -3896,6 +3897,37 @@ Only if VIRTIO_NET_F_CTRL_VQ set
\end_inset
+\change_inserted 1986246365 1346663522
+ 3: reserved
+\end_layout
+
+\begin_layout Description
+
+\change_inserted 1986246365 1346663550
+4: receiveq1.
+ 5: transmitq1.
+ 6: receiveq2.
+ 7.
+ transmitq2.
+ ...
+ 2N+2:receivqN, 2N+3:transmitqN
+\begin_inset Foot
+status open
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346663558
+Only if VIRTIO_NET_F_CTRL_VQ set.
+ N is indicated by max_virtqueue_pairs field.
+\change_unchanged
+
+\end_layout
+
+\end_inset
+
+
+\change_unchanged
+
\end_layout
\begin_layout Description
@@ -4056,6 +4088,17 @@ VIRTIO_NET_F_CTRL_VLAN
\begin_layout Description
VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous packets.
+\change_inserted 1986246365 1346617842
+
+\end_layout
+
+\begin_layout Description
+
+\change_inserted 1986246365 1346618103
+VIRTIO_NET_F_MULTIQUEUE(22) Device has multiple receive and transmission
+ queues.
+\change_unchanged
+
\end_layout
\end_deeper
@@ -4068,11 +4111,45 @@ configuration
\begin_inset space ~
\end_inset
-layout Two configuration fields are currently defined.
+layout
+\change_deleted 1986246365 1346671560
+Two
+\change_inserted 1986246365 1346671647
+Six
+\change_unchanged
+ configuration fields are currently defined.
The mac address field always exists (though is only valid if VIRTIO_NET_F_MAC
is set), and the status field only exists if VIRTIO_NET_F_STATUS is set.
Two read-only bits are currently defined for the status field: VIRTIO_NET_S_LIN
K_UP and VIRTIO_NET_S_ANNOUNCE.
+
+\change_inserted 1986246365 1346672138
+ The following four read-only fields only exists if VIRTIO_NET_F_MULTIQUEUE
+ is set.
+ The max_virtqueue_pairs field specifies the maximum number of each of transmit
+ and receive virtqueues that can used for multiqueue operation.
+ The following read-only fields:
+\emph on
+current_steering_rule
+\emph default
+,
+\emph on
+reserved
+\emph default
+ and
+\emph on
+current_steering_param
+\emph default
+ store the last successful VIRTIO_NET_CTRL_STEERING
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:Transmit-Packet-Steering"
+
+\end_inset
+
+ command executed by driver, for debugging.
+
+\change_unchanged
\begin_inset listings
inline false
@@ -4105,6 +4182,40 @@ struct virtio_net_config {
\begin_layout Plain Layout
u16 status;
+\change_inserted 1986246365 1346671221
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671532
+
+ u16 max_virtqueue_pairs;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671531
+
+ u8 current_steering_rule;
+\change_unchanged
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671499
+
+ u8 reserved;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671530
+
+ u16 current_steering_param;
+\change_unchanged
+
\end_layout
\begin_layout Plain Layout
@@ -4151,6 +4262,18 @@ physical
\begin_layout Enumerate
If the VIRTIO_NET_F_CTRL_VQ feature bit is negotiated, identify the control
virtqueue.
+\change_inserted 1986246365 1346618052
+
+\end_layout
+
+\begin_layout Enumerate
+
+\change_inserted 1986246365 1346618175
+If VIRTIO_NET_F_MULTIQUEUE feature bit is negotiated, identify the receive
+ and transmission queues that are going to be used in multiqueue mode.
+ Only queues that are going to be used need to be initialized.
+\change_unchanged
+
\end_layout
\begin_layout Enumerate
@@ -4168,7 +4291,11 @@ status
\end_layout
\begin_layout Enumerate
-The receive virtqueue should be filled with receive buffers.
+The receive virtqueue
+\change_inserted 1986246365 1346618180
+(s)
+\change_unchanged
+ should be filled with receive buffers.
This is described in detail below in
\begin_inset Quotes eld
\end_inset
@@ -4516,6 +4643,201 @@ Note that the header will be two bytes longer for the VIRTIO_NET_F_MRG_RXBUF
\end_layout
\begin_layout Subsection*
+
+\change_inserted 1986246365 1346670975
+\begin_inset CommandInset label
+LatexCommand label
+name "sub:Transmit-Packet-Steering"
+
+\end_inset
+
+Transmit Packet Steering
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670592
+When VIRTIO_NET_F_MULTIQUEUE feature bit is negotiated, guest can use any
+ of multiple configured transmit queues to transmit a given packet.
+ To avoid packet reordering by device (which gnerally leads to performance
+ degradation) driver should attempt to utilize the same transmit virtqueue
+ for all packets of a given transmit flow.
+ For bi-directional protocols (in practice, TCP), a given network connection
+ can utilize both transmit and receive queues.
+ For best performance, packets from a single connection should utilize the
+ paired transmit and receive queues from the same virtqueue pair; for example
+ both transmitqN and receiveqN.
+ This rule makes it possible to optimize processing on the device side,
+ but this is not a hard requirement: devices should function correctly even
+ when this rule is not followed.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670727
+Driver selects an active steering rule using VIRTIO_NET_CTRL_STEERING command
+ (this controls both which virtqueue is selected for a given packet for
+ receive and notifies the device which virtqueues are about to be used for
+ transmit).
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670594
+This command accepts a single out argument in the following format:
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670594
+\begin_inset listings
+inline false
+status open
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+#define VIRTIO_NET_CTRL_STEERING 4
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+struct virtio_net_ctrl_steering {
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671425
+
+ u8 current_steering_rule;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+ u8 reserved;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346671485
+
+ u16 current_steering_param;
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+};
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+#define VIRTIO_NET_CTRL_STEERING_SINGLE 0
+\end_layout
+
+\begin_layout Plain Layout
+
+\change_inserted 1986246365 1346670594
+
+#define VIRTIO_NET_CTRL_STEERING_HOST 1
+\end_layout
+
+\end_inset
+
+
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671803
+The field
+\emph on
+rule
+\emph default
+ specifies the function used to select transmit virtqueue for a given packet;
+ the field
+\emph on
+param
+\emph default
+ makes it possible to pass an extra parameter if appropriate.
+ When
+\emph on
+rule
+\emph default
+ is set to VIRTIO_NET_CTRL_STEERING_SINGLE all packets are steered to the
+ default virtqueue transmitq (1); param is unused; this is the default.
+ When
+\emph on
+rule
+\emph default
+ is set to VIRTIO_NET_CTRL_STEERING_HOST packets are steered by driver to
+ the first (
+\emph on
+param
+\emph default
++1) multiqueue virtqueues transmitq1...transmitqN; the default transmitq is
+ unused.
+ Driver must have configured all these (
+\emph on
+param
+\emph default
++1) virtqueues beforehand.
+ For best performance, driver should detects flow to virtqueue pair mapping
+ on receive and selects the transmit virtqueue from the same virtqueue pair.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670762
+Supported steering rules can be added and removed in the future.
+ Driver should probe for supported rules by checking ack values of the command.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671315
+When steering rule is modified, some packets can still be outstanding in
+ one or more of the virtqueues.
+ For transmit, device is recommended to complete processing of the transmit
+ queue(s) utilized by the original steering before processing any packets
+ delivered by the modified steering rule.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671412
+For debugging, current steering rule can also be read from the configuration
+ space.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346670762
+See also receive steering description
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:Receive-Packet-Steering"
+
+\end_inset
+
+.
+\end_layout
+
+\begin_layout Subsection*
Packet Transmission Interrupt
\end_layout
@@ -4988,8 +5310,24 @@ status open
The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status field when
it notices the changes of device configuration.
The command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that driver
- has recevied the notification and device would clear the VIRTIO_NET_S_ANNOUNCE
- bit in the status filed after it received this command.
+ has rece
+\change_inserted 1986246365 1346663932
+i
+\change_unchanged
+v
+\change_deleted 1986246365 1346663934
+i
+\change_unchanged
+ed the notification and device would clear the VIRTIO_NET_S_ANNOUNCE bit
+ in the status fi
+\change_inserted 1986246365 1346663942
+e
+\change_unchanged
+l
+\change_deleted 1986246365 1346663943
+e
+\change_unchanged
+d after it received this command.
\end_layout
\begin_layout Standard
@@ -5004,10 +5342,101 @@ Sending the gratuitous packets or marking there are pending gratuitous packets
\begin_layout Enumerate
Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control vq.
+\change_deleted 1986246365 1346662247
+
\end_layout
-\begin_layout Enumerate
+\begin_layout Subsection*
+
+\change_inserted 1986246365 1346670357
+\begin_inset CommandInset label
+LatexCommand label
+name "sub:Receive-Packet-Steering"
+
+\end_inset
+
+Receive Packet Steering
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671046
+When VIRTIO_NET_F_MULTIQUEUE feature bit is negotiated, device can use any
+ of multiple configured receive queues to pass a given packet to driver.
+ Driver controls which virtqueue is selected in practice by configuring
+ packet steering rule using VIRTIO_NET_CTRL_STEERING command, as described
+ above
+\begin_inset CommandInset ref
+LatexCommand ref
+reference "sub:Transmit-Packet-Steering"
+
+\end_inset
+
.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671818
+The field
+\emph on
+rule
+\emph default
+ specifies the function used to select receive virtqueue for a given packet;
+ the field
+\emph on
+param
+\emph default
+ makes it possible to pass an extra parameter if appropriate.
+ When
+\emph on
+rule
+\emph default
+ is set to VIRTIO_NET_CTRL_STEERING_SINGLE all packets are steered to the
+ default virtqueue receveq (0); param is unused; this is the default.
+ When
+\emph on
+rule
+\emph default
+ is set to VIRTIO_NET_CTRL_STEERING_HOST packets are steered by host using
+ a device-specific steering function to the first (
+\emph on
+param
+\emph default
++1) multiqueue virtqueues receiveq1...receiveqN; the default receiveq is unused.
+ Driver must have configured all these (
+\emph on
+param
+\emph default
++1) virtqueues beforehand.
+ For best performance, driver is expected to detect flow to virtqueue pair
+ mapping on receive and select the transmit virtqueue from the same virtqueue
+ pair.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346669564
+Supported steering rules can be added and removed in the future.
+ Driver should probe for supported rules by checking ack values of the command.
+\end_layout
+
+\begin_layout Standard
+
+\change_inserted 1986246365 1346671151
+When steering rule is modified, some packets can still be outstanding in
+ one or more of the virtqueues.
+ For receive, driver is recommended to complete processing of the receive
+ queue(s) utilized by the original steering before processing any packets
+ delivered by the modified steering rule.
+\end_layout
+
+\begin_layout Standard
+
+\change_deleted 1986246365 1346664095
+.
+
+\change_unchanged
\end_layout
^ permalink raw reply related
* Re: [PATCH RFC 0/2] Interface for TCP Metrics
From: Renato Westphal @ 2012-09-03 12:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Stephen Hemminger, netdev
In-Reply-To: <alpine.LFD.2.00.1208231908380.28424@ja.ssi.bg>
> BTW, I noticed that the GENL part in iproute is
> not separated in common place. Should we create common
> place for functions like genl_ctrl_resolve_family and
> genl_parse_getfamily ?
I think it would be nice to extend libnetlink or create something like
'libgenetlink' with these GENL facilities you created. The tendency is
to increase the number of genetlink users over time, so it seems to
make sense to provide some basic infrastructure for these new users.
Every genetlink application needs to resolve family names and possibly
multicast group names, so I think putting these basic facilities in
common place will help to reduce code duplication in the future.
--
Renato Westphal
^ permalink raw reply
* Re: [net-next.git 5/7] stmmac: add sysFs support
From: Ben Hutchings @ 2012-09-03 12:44 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev
In-Reply-To: <1346658422-1925-6-git-send-email-peppe.cavallaro@st.com>
On Mon, 2012-09-03 at 09:47 +0200, Giuseppe CAVALLARO wrote:
> This patch adds the sysFs support.
> Some internal driver parameters can be tuned by using some
> entries exposed via sysFS. There parameter currently are,
> for example, for internal timers used to mitigate the rx/tx
> interrupts or for EEE.
[...]
Why are you not exposing these through the standard ethtool operations?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next.git 5/7] stmmac: add sysFs support
From: Giuseppe CAVALLARO @ 2012-09-03 13:36 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1346676267.7787.82.camel@deadeye.wl.decadent.org.uk>
Hello Ben,
On 9/3/2012 2:44 PM, Ben Hutchings wrote:
> On Mon, 2012-09-03 at 09:47 +0200, Giuseppe CAVALLARO wrote:
>> This patch adds the sysFs support.
>> Some internal driver parameters can be tuned by using some
>> entries exposed via sysFS. There parameter currently are,
>> for example, for internal timers used to mitigate the rx/tx
>> interrupts or for EEE.
> [...]
>
> Why are you not exposing these through the standard ethtool operations?
>
> Ben.
yes I want to expose them via ethtool and I'll do this as soon as I have
clear with ethtool parameters have to be used (
http://marc.info/?l=linux-netdev&m=134561966226677&w=2 ).
For the reception side, I have the RI Watchdog Timer count field and I
do not know what is the appropriate ethtool parameter to use.
>From the Synopsys databook, the RI Watchdog Timer count indicates the
number of system clock cycles. When the it runs out, the receive
interrupt bit is set and the timer is stopped.
No idea if it can be actually covered, for example, with
rx_coalesce_usecs_irq.
For the transmission I have a SW timer that periodically calls the tx
function (stmmac_tx) and a threshold to also set the "Interrupt on
completion" bit in the TDES when a frame is transmitted.
I wonder (but not sure) if in this case I could be: tx_coalesce_usec and
tx_mac_coalesced_frames.
>From the kernel documentation IIUC these seem to have other meaning.
No problem, to extend ethtool to cover these kind of parameters if
necessary.
Welcome advice,
Peppe
^ permalink raw reply
* [PATCH] sctp: Don't charge for data in sndbuf again when transmitting packet
From: Thomas Graf @ 2012-09-03 14:27 UTC (permalink / raw)
To: linux-sctp; +Cc: netdev, Vlad Yasevich, Neil Horman, David Miller
SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and via
skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken up
by __sctp_write_space().
Buffer space charged via sctp_set_owner_w() is released in sctp_wfree()
which calls __sctp_write_space() directly.
Buffer space charged via skb_set_owner_w() is released via sock_wfree()
which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
Therefore if sctp_packet_transmit() manages to queue up more than sndbuf
bytes, sctp_wait_for_sndbuf() will never be woken up again unless it is
interrupted by a signal.
This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
Charging for the data twice does not make sense in the first place, it
leads to overcharging sndbuf by a factor 2. Therefore this patch only
charges a single byte in wmem_alloc when transmitting an SCTP packet to
ensure that the socket stays alive until the packet has been released.
This means that control chunks are no longer accounted for in wmem_alloc
which I believe is not a problem as skb->truesize will typically lead
to overcharging anyway and thus compensates for any control overhead.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
CC: Vlad Yasevich <vyasevic@redhat.com>
CC: Neil Horman <nhorman@tuxdriver.com>
CC: David Miller <davem@davemloft.net>
---
net/sctp/output.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 838e18b..be50aa2 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -364,6 +364,25 @@ finish:
return retval;
}
+static void sctp_packet_release_owner(struct sk_buff *skb)
+{
+ sk_free(skb->sk);
+}
+
+static void sctp_packet_set_owner_w(struct sk_buff *skb, struct sock *sk)
+{
+ skb_orphan(skb);
+ skb->sk = sk;
+ skb->destructor = sctp_packet_release_owner;
+
+ /*
+ * The data chunks have already been accounted for in sctp_sendmsg(),
+ * therefore only reserve a single byte to keep socket around until
+ * the packet has been transmitted.
+ */
+ atomic_inc(&sk->sk_wmem_alloc);
+}
+
/* All packets are sent to the network through this function from
* sctp_outq_tail().
*
@@ -405,7 +424,7 @@ int sctp_packet_transmit(struct sctp_packet *packet)
/* Set the owning socket so that we know where to get the
* destination IP address.
*/
- skb_set_owner_w(nskb, sk);
+ sctp_packet_set_owner_w(nskb, sk);
if (!sctp_transport_dst_check(tp)) {
sctp_transport_route(tp, NULL, sctp_sk(sk));
--
1.7.11.4
^ permalink raw reply related
* Re: [PATCH] sctp: Don't charge for data in sndbuf again when transmitting packet
From: Vlad Yasevich @ 2012-09-03 15:02 UTC (permalink / raw)
To: Thomas Graf
Cc: linux-sctp@vger.kernel.org, netdev@vger.kernel.org, Vlad Yasevich,
Neil Horman, David Miller
In-Reply-To: <ed0aceea14e890e55829f42d1594ae9417b8ca25.1346681739.git.tgraf@suug.ch>
On Sep 3, 2012, at 10:27 AM, Thomas Graf <tgraf@suug.ch> wrote:
> SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and
> via
> skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
> sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be
> waken up
> by __sctp_write_space().
>
> Buffer space charged via sctp_set_owner_w() is released in sctp_wfree
> ()
> which calls __sctp_write_space() directly.
>
> Buffer space charged via skb_set_owner_w() is released via sock_wfree
> ()
> which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
> sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
>
> Therefore if sctp_packet_transmit() manages to queue up more than
> sndbuf
> bytes, sctp_wait_for_sndbuf() will never be woken up again unless it
> is
> interrupted by a signal.
>
> This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
>
> Charging for the data twice does not make sense in the first place, it
> leads to overcharging sndbuf by a factor 2. Therefore this patch only
> charges a single byte in wmem_alloc when transmitting an SCTP packet
> to
> ensure that the socket stays alive until the packet has been released.
>
> This means that control chunks are no longer accounted for in
> wmem_alloc
> which I believe is not a problem as skb->truesize will typically lead
> to overcharging anyway and thus compensates for any control overhead.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> CC: Vlad Yasevich <vyasevic@redhat.com>
> CC: Neil Horman <nhorman@tuxdriver.com>
> CC: David Miller <davem@davemloft.net>
> ---
> net/sctp/output.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/output.c b/net/sctp/output.c
> index 838e18b..be50aa2 100644
> --- a/net/sctp/output.c
> +++ b/net/sctp/output.c
> @@ -364,6 +364,25 @@ finish:
> return retval;
> }
>
> +static void sctp_packet_release_owner(struct sk_buff *skb)
> +{
> + sk_free(skb->sk);
> +}
> +
> +static void sctp_packet_set_owner_w(struct sk_buff *skb, struct
> sock *sk)
> +{
> + skb_orphan(skb);
> + skb->sk = sk;
> + skb->destructor = sctp_packet_release_owner;
> +
> + /*
> + * The data chunks have already been accounted for in
> sctp_sendmsg(),
> + * therefore only reserve a single byte to keep socket around
> until
> + * the packet has been transmitted.
> + */
> + atomic_inc(&sk->sk_wmem_alloc);
> +}
> +
> /* All packets are sent to the network through this function from
> * sctp_outq_tail().
> *
> @@ -405,7 +424,7 @@ int sctp_packet_transmit(struct sctp_packet
> *packet)
> /* Set the owning socket so that we know where to get the
> * destination IP address.
> */
> - skb_set_owner_w(nskb, sk);
> + sctp_packet_set_owner_w(nskb, sk);
>
> if (!sctp_transport_dst_check(tp)) {
> sctp_transport_route(tp, NULL, sctp_sk(sk));
> --
> 1.7.11.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next.git 5/7] stmmac: add sysFs support
From: Ben Hutchings @ 2012-09-03 15:09 UTC (permalink / raw)
To: Giuseppe CAVALLARO; +Cc: netdev
In-Reply-To: <5044B245.5050703@st.com>
On Mon, 2012-09-03 at 15:36 +0200, Giuseppe CAVALLARO wrote:
> Hello Ben,
>
> On 9/3/2012 2:44 PM, Ben Hutchings wrote:
> > On Mon, 2012-09-03 at 09:47 +0200, Giuseppe CAVALLARO wrote:
> >> This patch adds the sysFs support.
> >> Some internal driver parameters can be tuned by using some
> >> entries exposed via sysFS. There parameter currently are,
> >> for example, for internal timers used to mitigate the rx/tx
> >> interrupts or for EEE.
> > [...]
> >
> > Why are you not exposing these through the standard ethtool operations?
> >
> > Ben.
>
> yes I want to expose them via ethtool and I'll do this as soon as I have
> clear with ethtool parameters have to be used (
> http://marc.info/?l=linux-netdev&m=134561966226677&w=2 ).
Sorry, I meant to reply to that but didn't get round to it.
> For the reception side, I have the RI Watchdog Timer count field and I
> do not know what is the appropriate ethtool parameter to use.
> From the Synopsys databook, the RI Watchdog Timer count indicates the
> number of system clock cycles. When the it runs out, the receive
> interrupt bit is set and the timer is stopped.
> No idea if it can be actually covered, for example, with
> rx_coalesce_usecs_irq.
As I understand it, interrupt moderation time is supposed to be the
minimum time between completion IRQs, not a minimum delay from
completion-with-IRQ-armed to assertion of the IRQ. The timer should
start running again immediately after the associated IRQ is asserted.
But I don't know whether it's universally implemented this way.
The field names including '_irq' are to be used if the hardware can use
a different moderation time while the IRQ is still masked (i.e. NAPI or
hard interrupt handler is still running). I think most hardware doesn't
support this.
> For the transmission I have a SW timer that periodically calls the tx
> function (stmmac_tx) and a threshold to also set the "Interrupt on
> completion" bit in the TDES when a frame is transmitted.
> I wonder (but not sure) if in this case I could be: tx_coalesce_usec and
> tx_mac_coalesced_frames.
> From the kernel documentation IIUC these seem to have other meaning.
The semantics don't seem to match the documentation exactly but I think
this is probably close enough.
Ben.
> No problem, to extend ethtool to cover these kind of parameters if
> necessary.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/2] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_iterate()
From: Pablo Neira Ayuso @ 2012-09-03 15:31 UTC (permalink / raw)
To: Michael Wang
Cc: LKML, netdev@vger.kernel.org, coreteam, netfilter,
netfilter-devel, David Miller, kaber
In-Reply-To: <5035C6DD.3000600@linux.vnet.ibm.com>
On Thu, Aug 23, 2012 at 01:59:57PM +0800, Michael Wang wrote:
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
>
> Since 'list_for_each_continue_rcu' has already been replaced by
> 'list_for_each_entry_continue_rcu', pass 'list_head' to nf_iterate() as a
> parameter can not benefit us any more.
>
> This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
> nf_iterate() to save code.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] netfilter: pass 'nf_hook_ops' instead of 'list_head' to nf_queue()
From: Pablo Neira Ayuso @ 2012-09-03 15:31 UTC (permalink / raw)
To: Michael Wang
Cc: LKML, netdev@vger.kernel.org, coreteam, netfilter,
netfilter-devel, David Miller, kaber
In-Reply-To: <5035C6E6.6040001@linux.vnet.ibm.com>
On Thu, Aug 23, 2012 at 02:00:06PM +0800, Michael Wang wrote:
> From: Michael Wang <wangyun@linux.vnet.ibm.com>
>
> Since 'list_for_each_continue_rcu' has already been replaced by
> 'list_for_each_entry_continue_rcu', pass 'list_head' to nf_queue() as a
> parameter can not benefit us any more.
>
> This patch will replace 'list_head' with 'nf_hook_ops' as the parameter of
> nf_queue() and __nf_queue() to save code.
Applied, thanks.
^ permalink raw reply
* Re: [net-next.git 5/7] stmmac: add sysFs support
From: David Miller @ 2012-09-03 17:20 UTC (permalink / raw)
To: bhutchings; +Cc: peppe.cavallaro, netdev
In-Reply-To: <1346676267.7787.82.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 3 Sep 2012 13:44:27 +0100
> On Mon, 2012-09-03 at 09:47 +0200, Giuseppe CAVALLARO wrote:
>> This patch adds the sysFs support.
>> Some internal driver parameters can be tuned by using some
>> entries exposed via sysFS. There parameter currently are,
>> for example, for internal timers used to mitigate the rx/tx
>> interrupts or for EEE.
> [...]
>
> Why are you not exposing these through the standard ethtool operations?
Guiseppe, I'm not appyling driver patches that add sysfs crap like
this. Either use existing ethtool interfaces or create new ones that
provide the necessary functionality.
Adding unique configuration mechanisms to a device driver is always a
bug.
And I'm getting real fed up with driver writers simply not getting the
message. Every time someone adds sysfs or ioctl crap, we push back,
so just don't do it and stop wasting our time.
^ permalink raw reply
* Re: [PATCH v2] netfilter: take care of timewait sockets
From: David Miller @ 2012-09-03 17:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: fw, hvtaifwkbgefbaei, netdev, e1000-devel
In-Reply-To: <1346666238.2563.113.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Sep 2012 11:57:18 +0200
> David, tell me if you prefer to change TCP demux to avoid timewait,
> as I have no strong opinion.
It would be the stupidest thing ever to do the whole hash lookup
just to throw the result away just because it's a timewait socket.
> [PATCH] net: sock_edemux() should take care of timewait sockets
>
> sock_edemux() can handle either a regular socket or a timewait socket
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: Don't charge for data in sndbuf again when transmitting packet
From: David Miller @ 2012-09-03 17:24 UTC (permalink / raw)
To: vyasevich; +Cc: tgraf, linux-sctp, netdev, vyasevic, nhorman
In-Reply-To: <378685E0-7225-4C9D-AE0F-7B8767ECB16A@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Mon, 3 Sep 2012 11:02:51 -0400
>
>
> On Sep 3, 2012, at 10:27 AM, Thomas Graf <tgraf@suug.ch> wrote:
>
>> SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and
>> via
>> skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
>> sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken
>> up
>> by __sctp_write_space().
>>
>> Buffer space charged via sctp_set_owner_w() is released in
>> sctp_wfree()
>> which calls __sctp_write_space() directly.
>>
>> Buffer space charged via skb_set_owner_w() is released via
>> sock_wfree()
>> which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
>> sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
>>
>> Therefore if sctp_packet_transmit() manages to queue up more than
>> sndbuf
>> bytes, sctp_wait_for_sndbuf() will never be woken up again unless it
>> is
>> interrupted by a signal.
>>
>> This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
>>
>> Charging for the data twice does not make sense in the first place, it
>> leads to overcharging sndbuf by a factor 2. Therefore this patch only
>> charges a single byte in wmem_alloc when transmitting an SCTP packet
>> to
>> ensure that the socket stays alive until the packet has been released.
>>
>> This means that control chunks are no longer accounted for in
>> wmem_alloc
>> which I believe is not a problem as skb->truesize will typically lead
>> to overcharging anyway and thus compensates for any control overhead.
>
> Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* RE: Possible issue with Mellanox mlx4/port handling
From: Yevgeny Petrilin @ 2012-09-03 17:32 UTC (permalink / raw)
To: mleitner@redhat.com; +Cc: netdev@vger.kernel.org, Or Gerlitz
> Commit
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4c41b3673759d096106e68bce586f103c51d4119
> inserted changes like:
>
> @@ -361,7 +361,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8
> port,
> int err;
> struct mlx4_priv *priv = mlx4_priv(dev);
>
> - s_steer = &mlx4_priv(dev)->steer[0];
> + s_steer = &mlx4_priv(dev)->steer[port - 1];
>
> mutex_lock(&priv->mcg_table.mutex);
>
> But I fear we missed one part of the deal. Concept patch:
>
> @@ -365,7 +365,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8
> port,
>
> mutex_lock(&priv->mcg_table.mutex);
>
> - if (get_promisc_qp(dev, 0, steer, qpn)) {
> + if (get_promisc_qp(dev, port - 1, steer, qpn)) {
> err = 0; /* Noting to do, already exists */
> goto out_mutex;
> }
>
...
>
> As far as I can understand, we are changing a list for a port and checking for
> duplicates on the other list. Points marked as A, B and C for highlighting. Am I
> missing something? What do you think?
>
> FWIW, this call get_promisc_qp(dev, 0, ...) happens in other places too.
>
> Thank you,
> Marcelo.
Hi Marcelo,
Thanks for this, You are absolutely right.
We actually have a fix for this issue which we are now verifying, and it will be sent to the mailing list in a few days.
Thanks,
Yevgeny
^ permalink raw reply
* Re: Possible issue with Mellanox mlx4/port handling
From: Marcelo Ricardo Leitner @ 2012-09-03 17:45 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <953B660C027164448AE903364AC447D28720CF7D@MTLDAG01.mtl.com>
On 09/03/2012 02:32 PM, Yevgeny Petrilin wrote:
>> Commit
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4c41b3673759d096106e68bce586f103c51d4119
>> inserted changes like:
>>
>> @@ -361,7 +361,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8
>> port,
>> int err;
>> struct mlx4_priv *priv = mlx4_priv(dev);
>>
>> - s_steer =&mlx4_priv(dev)->steer[0];
>> + s_steer =&mlx4_priv(dev)->steer[port - 1];
>>
>> mutex_lock(&priv->mcg_table.mutex);
>>
>> But I fear we missed one part of the deal. Concept patch:
>>
>> @@ -365,7 +365,7 @@ static int add_promisc_qp(struct mlx4_dev *dev, u8
>> port,
>>
>> mutex_lock(&priv->mcg_table.mutex);
>>
>> - if (get_promisc_qp(dev, 0, steer, qpn)) {
>> + if (get_promisc_qp(dev, port - 1, steer, qpn)) {
>> err = 0; /* Noting to do, already exists */
>> goto out_mutex;
>> }
>>
> ...
>>
>> As far as I can understand, we are changing a list for a port and checking for
>> duplicates on the other list. Points marked as A, B and C for highlighting. Am I
>> missing something? What do you think?
>>
>> FWIW, this call get_promisc_qp(dev, 0, ...) happens in other places too.
>>
>> Thank you,
>> Marcelo.
>
> Hi Marcelo,
> Thanks for this, You are absolutely right.
> We actually have a fix for this issue which we are now verifying, and it will be sent to the mailing list in a few days.
Hi Yevgeny,
Thanks for the fast confirmation.
If you can share, what can we expect it to be like? Like the chunk I
suggested above or is there anything else needed? I could notice only 6
places calling get_promisc_qp() that way and couldn't find any other
issue like that.
Thanks,
Marcelo.
^ permalink raw reply
* Re: [PATCH net] net: usbnet: fix softirq storm on suspend
From: David Miller @ 2012-09-03 17:49 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw, oneukum-l3A5Bk7waGM
In-Reply-To: <1346660778-24539-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 3 Sep 2012 10:26:18 +0200
> Suspending an open usbnet device results in constant
> rescheduling of usbnet_bh.
>
> commit 65841fd5 "usbnet: handle remote wakeup asap"
> refactored the usbnet_bh code to allow sharing the
> urb allocate and submit code with usbnet_resume. In
> this process, a test for, and immediate return on,
> ENOLINK from rx_submit was unintentionally dropped.
>
> The rx queue will not grow if rx_submit fails,
> making usbnet_bh reschedule itself. This results
> in a softirq storm if the error is persistent.
> rx_submit translates the usb_submit_urb error
> EHOSTUNREACH into ENOLINK, so this is an expected
> and persistent error for a suspended device. The
> old code tested for this condition and avoided
> rescheduling. Putting this test back.
>
> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.5
> Cc: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Cc: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] net: cx82310_eth: use common match macro
From: David Miller @ 2012-09-03 17:51 UTC (permalink / raw)
To: bjorn-yOkvZcmFvRU
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1346664033-30284-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Mon, 3 Sep 2012 11:20:31 +0200
> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: sierra_net: make private symbols static
From: David Miller @ 2012-09-03 17:51 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1346664033-30284-2-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 3 Sep 2012 11:20:32 +0200
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: sierra_net: rx_urb_size is constant
From: David Miller @ 2012-09-03 17:51 UTC (permalink / raw)
To: bjorn; +Cc: netdev, linux-usb
In-Reply-To: <1346664033-30284-3-git-send-email-bjorn@mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Mon, 3 Sep 2012 11:20:33 +0200
> The rx_urb_size is set to the same value for every device
> supported by this driver. No need to keep a per-device
> data structure to do that. Replacing with a macro constant.
>
> This was the last device specific info, and removing it
> allows us to delete the sierra_net_info_data struct.
>
> Signed-off-by: Bjørn Mork <bjorn@mork.no>
Applied.
^ permalink raw reply
* RE: Possible issue with Mellanox mlx4/port handling
From: Yevgeny Petrilin @ 2012-09-03 17:51 UTC (permalink / raw)
To: mleitner@redhat.com; +Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <5044ECA9.5080100@redhat.com>
> If you can share, what can we expect it to be like? Like the chunk I suggested
> above or is there anything else needed? I could notice only 6 places calling
> get_promisc_qp() that way and couldn't find any other issue like that.
>
The fix is pretty much the same style like what you suggested.
Yevgeny
^ permalink raw reply
* Re: Possible issue with Mellanox mlx4/port handling
From: Marcelo Ricardo Leitner @ 2012-09-03 18:16 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: netdev@vger.kernel.org, Or Gerlitz
In-Reply-To: <953B660C027164448AE903364AC447D28720CFEB@MTLDAG01.mtl.com>
On 09/03/2012 02:51 PM, Yevgeny Petrilin wrote:
>> If you can share, what can we expect it to be like? Like the chunk I suggested
>> above or is there anything else needed? I could notice only 6 places calling
>> get_promisc_qp() that way and couldn't find any other issue like that.
>>
>
> The fix is pretty much the same style like what you suggested.
Awesome. Thanks!
Marcelo
^ permalink raw reply
* Re: [PATCH 1/3] tcp: move tcp_enter_cwr()
From: David Miller @ 2012-09-03 18:34 UTC (permalink / raw)
To: ncardwell; +Cc: ycheng, nanditad, mattmathis, edumazet, netdev
In-Reply-To: <CADVnQymfu8YdGT_Rc0GBQ5wzncVQi6-BmTLtzD3MwQV8A3WFUQ@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sun, 2 Sep 2012 23:56:09 -0400
> On Sun, Sep 2, 2012 at 11:38 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> To prepare replacing rate halving with PRR algorithm in CWR state.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH 2/3] tcp: move tcp_update_cwnd_in_recovery
From: David Miller @ 2012-09-03 18:34 UTC (permalink / raw)
To: ncardwell; +Cc: ycheng, nanditad, mattmathis, edumazet, netdev
In-Reply-To: <CADVnQy=RH=3bGhfiKpMBCY-6n16FY9iSXBRWDbbT7h+5FbKKWg@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sun, 2 Sep 2012 23:57:02 -0400
> On Sun, Sep 2, 2012 at 11:38 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> To prepare replacing rate halving with PRR algorithm in CWR state.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH 3/3] tcp: use PRR to reduce cwin in CWR state
From: David Miller @ 2012-09-03 18:34 UTC (permalink / raw)
To: ncardwell; +Cc: ycheng, nanditad, mattmathis, edumazet, netdev
In-Reply-To: <CADVnQyma09UtSLusyQ6986uz2yfy-3xZ+mXrHfn1A2HO+3=X_g@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Mon, 3 Sep 2012 00:00:44 -0400
> On Sun, Sep 2, 2012 at 11:38 PM, Yuchung Cheng <ycheng@google.com> wrote:
>> Use proportional rate reduction (PRR) algorithm to reduce cwnd in CWR state,
>> in addition to Recovery state. Retire the current rate-halving in CWR.
>> When losses are detected via ACKs in CWR state, the sender enters Recovery
>> state but the cwnd reduction continues and does not restart.
>>
>> Rename and refactor cwnd reduction functions since both CWR and Recovery
>> use the same algorithm:
>> tcp_init_cwnd_reduction() is new and initiates reduction state variables.
>> tcp_cwnd_reduction() is previously tcp_update_cwnd_in_recovery().
>> tcp_ends_cwnd_reduction() is previously tcp_complete_cwr().
>>
>> The rate halving functions and logic such as tcp_cwnd_down(), tcp_min_cwnd(),
>> and the cwnd moderation inside tcp_enter_cwr() are removed. The unused
>> parameter, flag, in tcp_cwnd_reduction() is also removed.
>>
>> Signed-off-by: Yuchung Cheng <ycheng@google.com>
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] fq_codel: dont reinit flow state
From: David Miller @ 2012-09-03 18:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, dave.taht
In-Reply-To: <1346505597.7996.76.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 01 Sep 2012 06:19:57 -0700
> When fq_codel builds a new flow, it should not reset codel state.
>
> Codel algo needs to get previous values (lastcount, drop_next) to get
> proper behavior.
>
> Signed-off-by: Dave Taht <dave.taht@gmail.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied to 'net', thanks.
^ permalink raw reply
* Re: [PATCH] mISDN: fix possible memory leak in hfcmulti_init()
From: David Miller @ 2012-09-03 19:37 UTC (permalink / raw)
To: weiyj.lk; +Cc: isdn, yongjun_wei, netdev
In-Reply-To: <CAPgLHd_vRu-ACoVhf2LwL_1pYXuvXArindYOpHh6T-syn_CVUg@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 3 Sep 2012 15:31:00 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> hc has been allocated in this function and missing free it before
> leaving from some error handling cases.
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox