On 6/2/07, Denis Cheng <[EMAIL PROTECTED]> wrote:
they should merged into one
this patch I have checked, it's not corrupted, I wonder someone can
give some comment on this?
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
net/core/dst.c | 17 -
1 files changed, 4 insertio
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
--
On Saturday 02 June 2007 23:48:31 Ulrich Drepper wrote:
> Take two: I forgot to change the compat code. This has now happened. Only
> one
> additional line changed.
>
> Everything else from the first patch remains the same. I try to avoid
> clogging
> the list unnecessarily by not resending t
On 6/2/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
From: Miklos Szeredi <[EMAIL PROTECTED]>
A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
send()+close() on the peer, causing recv() to return zero, even though
the sent data should be received.
This happens if the send() and the cl
From: Miklos Szeredi <[EMAIL PROTECTED]>
A recv() on an AF_UNIX, SOCK_STREAM socket can race with a
send()+close() on the peer, causing recv() to return zero, even though
the sent data should be received.
This happens if the send() and the close() is performed between
skb_dequeue() and checking s
Take two: I forgot to change the compat code. This has now happened. Only one
additional line changed.
Everything else from the first patch remains the same. I try to avoid clogging
the list unnecessarily by not resending the test program.
Signed-off-by: Ulrich Drepper <[EMAIL PROTECTED]>
--
The more i was thinking about my own suggested solution the more it
turned out to be ugly for me ...
Summarizing we have two problems to solve:
1. Identify the originating sk to potentially trash my own sent messages.
2. Indicate a requested local loopback to the lower (driver) layer.
Regarding
Part two in the O_CLOEXEC saga: adding support for file descriptors received
through Unix domain sockets.
The patch is once again pretty minimal, it introduces a new flag for recvmsg
and passes it just like the existing MSG_CMSG_COMPAT flag. I think this bit
is not used otherwise but the networki
Hi,
[netdev added to CC]
[EMAIL PROTECTED] pisze:
I got following error message when I try to upload file to remote server.
The log generated in remote server is as per below.
KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284)
recvmsg bug: copied BC00D548 seq BC00DAFC
KERNEL:
On Friday 01 June 2007, Geoff Levand wrote:
>
> > What happened to the idea of incorporating support into spidernet?
>
> That is still our goal, but as a first step we want to at least get
> some Ethernet support included for end users.
Right, I agree that having two drivers is a better medium-t
On Sat, 2007-02-06 at 20:02 +1000, Herbert Xu wrote:
> [IPV4]: Convert IPv4 devconf to an array
>
> This patch converts the ipv4_devconf config members (everything except
> sysctl) to an array. This allows easier manipulation which will be
> needed later on to provide better management of default
Mick McCreath <[EMAIL PROTECTED]> wrote:
>
> When I run traceroute -i eth1 5.4.3.2, the UDP packets are routed out
> eth2.
>
> Has anybody seen this behaviour with traceroute??
Well the version of traceroute here actually does a BINDTODEVICE so it
will go out of the right interface. It also bin
Wei Yongjun <[EMAIL PROTECTED]> wrote:
> When received ICMP Fragmentation Needed message, PATH MTU is always set
> to the 576 even if MTU in ICMP message is lager then 576. This is
> because of error condition in function ip_rt_frag_needed(), now if
> packet size of that ICMP message is less the
[IPV4]: Restore old behaviour of default config values
Previously inet devices were only constructed when addresses are added
(or rarely in ipmr). Therefore the default config values they get are
the ones at the time of these operations.
Now that we're creating inet devices earlier, this changes
[IPV4]: Convert IPv4 devconf to an array
This patch converts the ipv4_devconf config members (everything except
sysctl) to an array. This allows easier manipulation which will be
needed later on to provide better management of default config values.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
[IPV4]: Add default config support after inetdev_init
Previously once inetdev_init has been called on a device any changes made
to ipv4_devconf_dflt would have no effect on that device's configuration.
This creates a problem since we have moved the point where inetdev_init
is called from when an
Hi Dave:
When we moved the IPv4/IPv6 device creation from address addition time
to device registration time it changed the behaviour of the default
configuration values (e.g., /proc/sys/net/ipv4/conf/default). Previously
you could specify default configuration values and as long as you do it
befo
[IPV4]: Only panic if inetdev_init fails for loopback
When I made the inetdev_init call work on all devices I incorrectly
left in the panic call as well. It is obviously undesirable to
panic on an allocation failure for a normal network device. This
patch moves the panic call under the loopback
Patrick McHardy wrote:
> Oliver Hartkopp wrote:
>
>> Patrick McHardy wrote:
>>
>
> Yes, its working, but only in certain combinations and you're breaking
> the rules for skb->cb, making it impossible for other layers to use.
> skb->sk is "stable" at the output path, the regular loopback dev
Patrick McHardy <[EMAIL PROTECTED]> writes:
> I have a set of patches coming up that introduce a rtnetlink API
> for adding/modifying/deleting software network devices. I would
> prefer if you could switch this driver over instead of doing the
> "create N devices during loading" that many current
20 matches
Mail list logo
