<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/net, branch v3.13.10</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/net?h=v3.13.10</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/net?h=v3.13.10'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-04-14T13:47:20Z</updated>
<entry>
<title>tcp: syncookies: do not use getnstimeofday()</title>
<updated>2014-04-14T13:47:20Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-03-20T04:02:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=652c3e3e38667d11e6e7ca204497930c24d059c3'/>
<id>urn:sha1:652c3e3e38667d11e6e7ca204497930c24d059c3</id>
<content type='text'>
[ Upstream commit 632623153196bf183a69686ed9c07eee98ff1bf8 ]

While it is true that getnstimeofday() uses about 40 cycles if TSC
is available, it can use 1600 cycles if hpet is the clocksource.

Switch to get_jiffies_64(), as this is more than enough, and
go back to 60 seconds periods.

Fixes: 8c27bd75f04f ("tcp: syncookies: reduce cookie lifetime to 128 seconds")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Florian Westphal &lt;fw@strlen.de&gt;
Acked-by: Florian Westphal &lt;fw@strlen.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tcp: tcp_release_cb() should release socket ownership</title>
<updated>2014-04-14T13:47:19Z</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2014-03-10T16:50:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=426f46a7985905445cfedbb00e95d9417d530649'/>
<id>urn:sha1:426f46a7985905445cfedbb00e95d9417d530649</id>
<content type='text'>
[ Upstream commit c3f9b01849ef3bc69024990092b9f42e20df7797 ]

Lars Persson reported following deadlock :

-000 |M:0x0:0x802B6AF8(asm) &lt;-- arch_spin_lock
-001 |tcp_v4_rcv(skb = 0x8BD527A0) &lt;-- sk = 0x8BE6B2A0
-002 |ip_local_deliver_finish(skb = 0x8BD527A0)
-003 |__netif_receive_skb_core(skb = 0x8BD527A0, ?)
-004 |netif_receive_skb(skb = 0x8BD527A0)
-005 |elk_poll(napi = 0x8C770500, budget = 64)
-006 |net_rx_action(?)
-007 |__do_softirq()
-008 |do_softirq()
-009 |local_bh_enable()
-010 |tcp_rcv_established(sk = 0x8BE6B2A0, skb = 0x87D3A9E0, th = 0x814EBE14, ?)
-011 |tcp_v4_do_rcv(sk = 0x8BE6B2A0, skb = 0x87D3A9E0)
-012 |tcp_delack_timer_handler(sk = 0x8BE6B2A0)
-013 |tcp_release_cb(sk = 0x8BE6B2A0)
-014 |release_sock(sk = 0x8BE6B2A0)
-015 |tcp_sendmsg(?, sk = 0x8BE6B2A0, ?, ?)
-016 |sock_sendmsg(sock = 0x8518C4C0, msg = 0x87D8DAA8, size = 4096)
-017 |kernel_sendmsg(?, ?, ?, ?, size = 4096)
-018 |smb_send_kvec()
-019 |smb_send_rqst(server = 0x87C4D400, rqst = 0x87D8DBA0)
-020 |cifs_call_async()
-021 |cifs_async_writev(wdata = 0x87FD6580)
-022 |cifs_writepages(mapping = 0x852096E4, wbc = 0x87D8DC88)
-023 |__writeback_single_inode(inode = 0x852095D0, wbc = 0x87D8DC88)
-024 |writeback_sb_inodes(sb = 0x87D6D800, wb = 0x87E4A9C0, work = 0x87D8DD88)
-025 |__writeback_inodes_wb(wb = 0x87E4A9C0, work = 0x87D8DD88)
-026 |wb_writeback(wb = 0x87E4A9C0, work = 0x87D8DD88)
-027 |wb_do_writeback(wb = 0x87E4A9C0, force_wait = 0)
-028 |bdi_writeback_workfn(work = 0x87E4A9CC)
-029 |process_one_work(worker = 0x8B045880, work = 0x87E4A9CC)
-030 |worker_thread(__worker = 0x8B045880)
-031 |kthread(_create = 0x87CADD90)
-032 |ret_from_kernel_thread(asm)

Bug occurs because __tcp_checksum_complete_user() enables BH, assuming
it is running from softirq context.

Lars trace involved a NIC without RX checksum support but other points
are problematic as well, like the prequeue stuff.

Problem is triggered by a timer, that found socket being owned by user.

tcp_release_cb() should call tcp_write_timer_handler() or
tcp_delack_timer_handler() in the appropriate context :

BH disabled and socket lock held, but 'owned' field cleared,
as if they were running from timer handlers.

Fixes: 6f458dfb4092 ("tcp: improve latencies of timer triggered events")
Reported-by: Lars Persson &lt;lars.persson@axis.com&gt;
Tested-by: Lars Persson &lt;lars.persson@axis.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net-tcp: fastopen: fix high order allocations</title>
<updated>2014-03-24T04:44:00Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-02-20T18:09:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4a7ca91f73c57607ec0bf71540a3a99dc22ce3cd'/>
<id>urn:sha1:4a7ca91f73c57607ec0bf71540a3a99dc22ce3cd</id>
<content type='text'>
[ Upstream commit f5ddcbbb40aa0ba7fbfe22355d287603dbeeaaac ]

This patch fixes two bugs in fastopen :

1) The tcp_sendmsg(...,  @size) argument was ignored.

   Code was relying on user not fooling the kernel with iovec mismatches

2) When MTU is about 64KB, tcp_send_syn_data() attempts order-5
allocations, which are likely to fail when memory gets fragmented.

Fixes: 783237e8daf13 ("net-tcp: Fast Open client - sending SYN-data")
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Cc: Yuchung Cheng &lt;ycheng@google.com&gt;
Acked-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Tested-by: Yuchung Cheng &lt;ycheng@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipv6: simplify detection of first operational link-local address on interface</title>
<updated>2014-01-18T02:10:01Z</updated>
<author>
<name>Hannes Frederic Sowa</name>
<email>hannes@stressinduktion.org</email>
</author>
<published>2014-01-16T19:13:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=11ffff752c6a5adc86f7dd397b2f75af8f917c51'/>
<id>urn:sha1:11ffff752c6a5adc86f7dd397b2f75af8f917c51</id>
<content type='text'>
In commit 1ec047eb4751e3 ("ipv6: introduce per-interface counter for
dad-completed ipv6 addresses") I build the detection of the first
operational link-local address much to complex. Additionally this code
now has a race condition.

Replace it with a much simpler variant, which just scans the address
list when duplicate address detection completes, to check if this is
the first valid link local address and send RS and MLD reports then.

Fixes: 1ec047eb4751e3 ("ipv6: introduce per-interface counter for dad-completed ipv6 addresses")
Reported-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Cc: Flavio Leitner &lt;fbl@redhat.com&gt;
Signed-off-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&gt;
Acked-by: Flavio Leitner &lt;fbl@redhat.com&gt;
Acked-by: Jiri Pirko &lt;jiri@resnulli.us&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Remove outqueue empty state</title>
<updated>2014-01-02T22:22:48Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevich@gmail.com</email>
</author>
<published>2014-01-02T19:39:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=619a60ee04be33238721a15c1f9704a2a515a33e'/>
<id>urn:sha1:619a60ee04be33238721a15c1f9704a2a515a33e</id>
<content type='text'>
The SCTP outqueue structure maintains a data chunks
that are pending transmission, the list of chunks that
are pending a retransmission and a length of data in
flight.  It also tries to keep the emtpy state so that
it can performe shutdown sequence or notify user.

The problem is that the empy state is inconsistently
tracked.  It is possible to completely drain the queue
without sending anything when using PR-SCTP.  In this
case, the empty state will not be correctly state as
report by Jamal Hadi Salim &lt;jhs@mojatatu.com&gt;.  This
can cause an association to be perminantly stuck in the
SHUTDOWN_PENDING state.

Additionally, SCTP is incredibly inefficient when setting
the empty state.  Even though all the data is availaible
in the outqueue structure, we ignore it and walk a list
of trasnports.

In the end, we can completely remove the extra empty
state and figure out if the queue is empty by looking
at 3 things:  length of pending data, length of in-flight
data, and exisiting of retransmit data.  All of these
are already in the strucutre.

Reported-by: Jamal Hadi Salim &lt;jhs@mojatatu.com&gt;
Signed-off-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Tested-by: Jamal Hadi Salim &lt;jhs@mojatatu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: llc: fix order of evaluation in llc_conn_ac_inc_vr_by_1</title>
<updated>2014-01-02T03:22:43Z</updated>
<author>
<name>Daniel Borkmann</name>
<email>dborkman@redhat.com</email>
</author>
<published>2014-01-01T22:04:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7e0309631ecf0cd16edba72ff74747fa1b96ead3'/>
<id>urn:sha1:7e0309631ecf0cd16edba72ff74747fa1b96ead3</id>
<content type='text'>
Function llc_conn_ac_inc_vr_by_1() evaluates via macro
PDU_GET_NEXT_Vr() into ...

  llc_sk(sk)-&gt;vR = ++llc_sk(sk)-&gt;vR &amp; 0xffffffffffffff7f

... but the order in which the side effects take place is
undefined because there is no intervening sequence point.

As llc_sk(sk)-&gt;vR is written in llc_sk(sk)-&gt;vR (assignment
left-hand side) and written in ++llc_sk(sk)-&gt;vR &amp; 0xffffffffffffff7f
this might possibly yield undefined behavior.

The final value of llc_sk(sk)-&gt;vR is ambiguous, because,
depending on the order of expression evaluation, the
increment may occur before, after, or interleaved with
the assignment. In C, evaluating such an expression yields
undefined behavior.

Since we're doing the increment via PDU_GET_NEXT_Vr() macro
and the only place it is being used is from
llc_conn_ac_inc_vr_by_1(), in order to increment vR by 1
with a follow-up optimized modulo, rewrite the expression
into ((vR + 1) &amp; CONST) in order to fix this.

Signed-off-by: Daniel Borkmann &lt;dborkman@redhat.com&gt;
Cc: Arnaldo Carvalho de Melo &lt;acme@ghostprotocols.net&gt;
Cc: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: properly latch and use autoclose value from sock to association</title>
<updated>2013-12-11T03:41:26Z</updated>
<author>
<name>Neil Horman</name>
<email>nhorman@tuxdriver.com</email>
</author>
<published>2013-12-10T11:48:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9f70f46bd4c7267d48ef461a1d613ec9ec0d520c'/>
<id>urn:sha1:9f70f46bd4c7267d48ef461a1d613ec9ec0d520c</id>
<content type='text'>
Currently, sctp associations latch a sockets autoclose value to an association
at association init time, subject to capping constraints from the max_autoclose
sysctl value.  This leads to an odd situation where an application may set a
socket level autoclose timeout, but sliently sctp will limit the autoclose
timeout to something less than that.

Fix this by modifying the autoclose setsockopt function to check the limit, cap
it and warn the user via syslog that the timeout is capped.  This will allow
getsockopt to return valid autoclose timeout values that reflect what subsequent
associations actually use.

While were at it, also elimintate the assoc-&gt;autoclose variable, it duplicates
whats in the timeout array, which leads to multiple sources for the same
information, that may differ (as the former isn't subject to any capping).  This
gives us the timeout information in a canonical place and saves some space in
the association structure as well.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: Wang Weidong &lt;wangweidong1@huawei.com&gt;
CC: David Miller &lt;davem@davemloft.net&gt;
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: netdev@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>tcp_memcontrol: Cleanup/fix cg_proto-&gt;memory_pressure handling.</title>
<updated>2013-12-06T02:01:01Z</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2013-12-05T04:12:04Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7f2cbdc28c034ef2c3be729681f631d5744e3cd5'/>
<id>urn:sha1:7f2cbdc28c034ef2c3be729681f631d5744e3cd5</id>
<content type='text'>
kill memcg_tcp_enter_memory_pressure.  The only function of
memcg_tcp_enter_memory_pressure was to reduce deal with the
unnecessary abstraction that was tcp_memcontrol.  Now that struct
tcp_memcontrol is gone remove this unnecessary function, the
unnecessary function pointer, and modify sk_enter_memory_pressure to
set this field directly, just as sk_leave_memory_pressure cleas this
field directly.

This fixes a small bug I intruduced when killing struct tcp_memcontrol
that caused memcg_tcp_enter_memory_pressure to never be called and
thus failed to ever set cg_proto-&gt;memory_pressure.

Remove the cg_proto enter_memory_pressure function as it now serves
no useful purpose.

Don't test cg_proto-&gt;memory_presser in sk_leave_memory_pressure before
clearing it.  The test was originally there to ensure that the pointer
was non-NULL.  Now that cg_proto is not a pointer the pointer does not
matter.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>xen-netback: fix fragment detection in checksum setup</title>
<updated>2013-12-06T01:31:40Z</updated>
<author>
<name>Paul Durrant</name>
<email>Paul.Durrant@citrix.com</email>
</author>
<published>2013-12-03T17:39:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1431fb31ecbaba1b5718006128f0f2ed0b94e1c3'/>
<id>urn:sha1:1431fb31ecbaba1b5718006128f0f2ed0b94e1c3</id>
<content type='text'>
The code to detect fragments in checksum_setup() was missing for IPv4 and
too eager for IPv6. (It transpires that Windows seems to send IPv6 packets
with a fragment header even if they are not a fragment - i.e. offset is zero,
and M bit is not set).

This patch also incorporates a fix to callers of maybe_pull_tail() where
skb-&gt;network_header was being erroneously added to the length argument.

Signed-off-by: Paul Durrant &lt;paul.durrant@citrix.com&gt;
Signed-off-by: Zoltan Kiss &lt;zoltan.kiss@citrix.com&gt;
Cc: Wei Liu &lt;wei.liu2@citrix.com&gt;
Cc: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Cc: David Vrabel &lt;david.vrabel@citrix.com&gt;
cc: David Miller &lt;davem@davemloft.net&gt;
Acked-by: Wei Liu &lt;wei.liu2@citrix.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Restore 'resent' bit to avoid retransmitted chunks for RTT measurements</title>
<updated>2013-11-28T23:29:58Z</updated>
<author>
<name>Xufeng Zhang</name>
<email>xufeng.zhang@windriver.com</email>
</author>
<published>2013-11-25T03:26:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6eabca54d6781f61c7318517c1463a098acb7a87'/>
<id>urn:sha1:6eabca54d6781f61c7318517c1463a098acb7a87</id>
<content type='text'>
Currently retransmitted DATA chunks could also be used for
RTT measurements since there are no flag to identify whether
the transmitted DATA chunk is a new one or a retransmitted one.
This problem is introduced by commit ae19c5486 ("sctp: remove
'resent' bit from the chunk") which inappropriately removed the
'resent' bit completely, instead of doing this, we should set
the resent bit only for the retransmitted DATA chunks.

Signed-off-by: Xufeng Zhang &lt;xufeng.zhang@windriver.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
