> In many respects, I expect the ib_unregister_device() call to mirror the
> error unwind found in the register call with the modifications for
> dealing with a device that was actually live.
Yes, it should look like that, I also noticed there were ordering
problems in this area. and we probably
Begin forwarded message:
Date: Sat, 1 Aug 2015 09:43:46 +
From: "bugzilla-dae...@bugzilla.kernel.org"
To: "shemmin...@linux-foundation.org"
Subject: [Bug 102181] New: kernel soft lockup when using tcp_keepalive_timer
https://bugzilla.kernel.org/show_bug.cgi?id=102181
Bug ID
From: Corcodel Marian
Date: Sat, 1 Aug 2015 20:20:21 +0300
>Add parameter ff_dup wich disable advertise 10/100Mbs
> duplex full for card wich start on low speed on full duplex.Verry strange
> with this patch
> First insert module with ff_dup=1 link is good , unload module, load module
On Sat, Aug 1, 2015 at 1:01 AM, Jason Gunthorpe
wrote:
> On Sat, Aug 01, 2015 at 12:24:23AM +0300, Or Gerlitz wrote:
>
>> addressed in incremental patch, as Doug suggested. Jason, it's wrong
>> to send developers again and again to fix things which were
>> perfect in Vn-1 but also not being covere
On Mon, 2015-06-01 at 09:28 +, Junling Zheng wrote:
> Hi, Greg:
>
> We found that after v3.10.73, recvmsg might return -EFAULT while -EINVAL
> was expected.
>
> We tested it through the recvmsg01 testcase come from LTP testsuit. It set
> msg->msg_namelen to -1 and the recvmsg syscall returned
On 07/31/15 at 10:51am, Joe Stringer wrote:
> On 31 July 2015 at 07:34, Hannes Frederic Sowa wrote:
> > In general, this shouldn't be necessary as the packet should already be
> > scrubbed before they arrive here.
> >
> > Could you maybe add a WARN_ON and check how those skbs with conntrack
> > da
Eyal Moscovici writes:
...
>
> We can start to implement polling, but I am unsure if the cgroups
> integration
> will be sufficient. The polling vhost thread should be scheduled all
> the time and just moving it from one cgroup to the other wont be
> sufficient.
> I think it needs a deeper int
Add parameter ff_dup wich disable advertise 10/100Mbs
duplex full for card wich start on low speed on full duplex.Verry strange
with this patch
First insert module with ff_dup=1 link is good , unload module, load module wo
parameter ff_dup
and is full duplex and full speed on RTL_GIGA_MAC
Hi Thomas,
Thanks for your clarification.
Could you please forward me the userspace patch you are mentioning. I guess
version 6 is the latest,
but I could not get the patch in internet. We are interested in testing this
feature thoroughly.
Also In the case of NORMAL mode as you said without pa
On 28.07, Phil Sutter wrote:
> Hi,
>
> When synproxy_send_server_ack() calls synproxy_send_tcp(), it passes
> NULL as third parameter (struct nf_conntrack *nfct). And the first thing
> synproxy_send_tcp() does, is dereference it:
>
> | struct net *net = nf_ct_net((struct nf_conn *)nfct);
>
> I c
"len" is a signed integer. We check that len is not negative, so it
goes from zero to INT_MAX. PAGE_SIZE is unsigned long so the comparison
is type promoted to unsigned long. ULONG_MAX - 4095 is a higher than
INT_MAX so the condition can never be true.
I don't know if this is harmful but it see
From: Eric Dumazet
Multicast dst are not cached. They carry DST_NOCACHE.
As mentioned in commit f8864972126899 ("ipv4: fix dst race in
sk_dst_get()"), these dst need special care before caching them
into a socket.
Caching them is allowed only if their refcnt was not 0, ie we
must use atomic_inc
12 matches
Mail list logo
