Hi Jon,
How to get these patches and how to patch these patches to our kernel 3.10?
-Original Message-
From: Jon Maloy [mailto:jon.ma...@ericsson.com]
Sent: 2016年12月6日 19:22
To: tipc-discussion@lists.sourceforge.net;
parthasarathy.bhuvara...@ericsson.com; ying@windriver.com;
jon.m
Jon, just directly submit this to -stable if that's what you want.
If you email this kind of stuff to me privately nothing is going to
happen to it.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Int
On 12/06/2016 12:49 PM, Jon Maloy wrote:
>
>
> On 12/06/2016 03:49 AM, Parthasarathy Bhuvaragan wrote:
>> On 11/29/2016 06:03 PM, Jon Maloy wrote:
>>> The functions tipc_wait_for_sndpkt() and tipc_wait_for_sndmsg() are very
>>> similar. The latter function is also called from two locations, and
>>>
On 12/06/2016 12:41 PM, Jon Maloy wrote:
>
>
>> -Original Message-
>> From: Parthasarathy Bhuvaragan
>> Sent: Tuesday, 06 December, 2016 03:46
>> To: Jon Maloy ; Jon Maloy ;
>> tipc-discussion@lists.sourceforge.net; Ying Xue
>> Cc: thompa@gmail.com
>> Subject: Re: [PATCH net-next v2
On 12/06/2016 03:49 AM, Parthasarathy Bhuvaragan wrote:
> On 11/29/2016 06:03 PM, Jon Maloy wrote:
>> The functions tipc_wait_for_sndpkt() and tipc_wait_for_sndmsg() are very
>> similar. The latter function is also called from two locations, and
>> there will be more in the coming commits, which
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Tuesday, 06 December, 2016 03:46
> To: Jon Maloy ; Jon Maloy ;
> tipc-discussion@lists.sourceforge.net; Ying Xue
> Cc: thompa@gmail.com
> Subject: Re: [PATCH net-next v2 0/3] tipc: improve interaction socket-link
>
> On 1
From: Erik Hugne
When the first fragment of a long data data message is received on a link, a
reassembly buffer large enough to hold the data from this and all subsequent
fragments of the message is allocated. The payload of each new fragment is
copied into this buffer upon arrival. When the last
From: Erik Hugne
When a message fragment is received in a broadcast or unicast link,
the reception code will append the fragment payload to a big reassembly
buffer through a call to the function tipc_recv_fragm(). However, after
the return of that call, the logics goes on and passes the fragment
From: Erik Hugne
If appending a received fragment to the pending fragment chain
in a unicast link fails, the current code tries to force a retransmission
of the fragment by decrementing the 'next received sequence number'
field in the link. This is done under the assumption that the failure
is ca
From: Ying Xue
The message dispatching part of tipc_recv_msg() is wrapped layers of
while/if/if/switch, causing out-of-control indentation and does not
look very good. We reduce two indentation levels by separating the
message dispatching from the blocks that checks link state and
sequence number
From: Ying Xue
Eliminate below sparse warnings:
net/tipc/link.c:1210:37: warning: cast removes address space of expression
net/tipc/link.c:1218:59: warning: incorrect type in argument 2 (different
address spaces)
net/tipc/link.c:1218:59:expected void const [noderef] *from
net/tipc/link.c:12
From: Erik Hugne
struct 'tipc_bearer' is a generic representation of the underlying
media type, and exists in a one-to-one relationship to each interface
TIPC is using. The struct contains a 'blocked' flag that mirrors the
operational and execution state of the represented interface, and is
updat
From: Erik Hugne
When checking statistics or changing parameters on a link, the
link_find_link function is used to locate the link with a given
name. The complex method of deconstructing the name into local
and remote address/interface is error prone and may fail if the
interface names contains s
From: Joe Perches
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto
From: Ying Xue
tipc_msg_build() now copies message data from iovec to skb_buff
using memcpy_fromiovecend(), which doesn't need to be passed the
iovec length to perform the copying.
So we remove the parameter indicating iovec length in all
functions where TIPC messages are built and sent.
Signed
From: Erik Hugne
Should a connect fail, if the publication/server is unavailable or
due to some other error, a positive value will be returned and errno
is never set. If the application code checks for an explicit zero
return from connect (success) or a negative return (failure), it
will not catc
From: Ying Xue
TIPC 'bearer' exists as an abstract concept, while 'media'
is deemed a specific implementation of a bearer, such as Ethernet
or Infiniband media. When a component inside TIPC wants to control
a specific media, it only needs to access the generic bearer API
to achieve this. However,
From: Ying Xue
When creation of TIPC internal server socket fails,
we get an oops with the following dump:
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [] tipc_close_conn+0x59/0xb0 [tipc]
PGD 13719067 PUD 12008067 PMD 0
Oops: [#1] SMP DEBUG_PAGEALLOC
Modules
From: Ying Xue
Currently, rcv_msg() always returns zero on a packet delivery upcall
from net_device.
To make its behavior more compliant with the way this API should be
used, we change this to let it return NET_RX_SUCCESS (which is zero
anyway) when it is able to handle the packet, and NET_RX_DR
From: Ying Xue
tipc_msg_build() calls skb_copy_to_linear_data_offset() to copy data
from user space to kernel space. However, the latter function does
in its turn call memcpy() to perform the actual copying. This poses
an obvious security and robustness risk, since memcpy() never makes
any validi
From: Ying Xue
link_cmd_set_value() takes commands for link, bearer and media related
configuration. Genereally the function returns 0 when a command is
recognized, and -EINVAL when it is not. However, in the switch for link
related commands it returns 0 even when the command is unrecognized. Thi
From: Ying Xue
tipc_block_bearer() currently takes a bearer name (const char*)
as argument. This requires the function to make a lookup to find
the pointer to the corresponding bearer struct. In the current
code base this is not necessary, since the only two callers
(tipc_continue(),recv_notifica
From: dingtianhong
We met lockdep warning when enable and disable the bearer for commands such as:
tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
---
[ 327.693595] ==
See subject.
///jon
Erik Hugne (6):
tipc: set sk_err correctly when connection fails
tipc: simplify the link lookup routine
tipc: don't reroute message fragments
tipc: message reassembly using fragment chain
tipc: reassembly failures should cause link reset
tipc: remove interface state
On 11/29/2016 06:03 PM, Jon Maloy wrote:
> The functions tipc_wait_for_sndpkt() and tipc_wait_for_sndmsg() are very
> similar. The latter function is also called from two locations, and
> there will be more in the coming commits, which will all need to test on
> different conditions.
>
> Instead of
On 12/05/2016 09:59 PM, Jon Maloy wrote:
>
>
>> -Original Message-
>> From: Parthasarathy Bhuvaragan
>> Sent: Monday, 05 December, 2016 15:11
>> To: Jon Maloy ; Jon Maloy ;
>> tipc-discussion@lists.sourceforge.net; Ying Xue
>> Cc: thompa@gmail.com
>> Subject: Re: [PATCH net-next v2 0/3
26 matches
Mail list logo
