* Binding a packet socket to interface down
From: Robert Iakobashvili @ 2006-06-22 15:32 UTC (permalink / raw)
To: netdev
Hi,
When packet socket (PF_SOCKET) is attempted in syscall bind () to the
network interface, which is down (no IF_UPP flag), packet_do_bind ()
sets error to the socket, but bind () does not fail.
When datagram, stream or raw socket fail to bind to some local
ip-port/ip, bind () fails.
Is this behavior of bind () for packet socket done deliberately, or
better to correct it so that bind will fail and return errno, e.g. ENODEV?
Thanks.
--
Sincerely,
------------------------------------------------------------------
Robert Iakobashvili, coroberti at gmail dot com
Navigare necesse est, vivere non est necesse.
------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Auke Kok @ 2006-06-22 15:36 UTC (permalink / raw)
To: Ben Greear
Cc: Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke, Ronciak, John
In-Reply-To: <449A2B20.2020006@candelatech.com>
Ben Greear wrote:
> Kok, Auke wrote:
>> CRC stripping is breaking SMBUS-connected BMC's. We disable this
>> feature to make it work. This fixes related bugs regarding SOL.
>
> Shouldn't you also have to subtract 4 bytes when setting the skb len
> in the receive logic? Perhaps when setting the rx-bytes counter as well?
the hardware corrects for the size properly when we disable CRC stripping. The
end result is the same.
Cheers,
Auke
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Jesse Brandeburg @ 2006-06-22 15:39 UTC (permalink / raw)
To: Ben Greear
Cc: Kok, Auke, Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke,
Ronciak, John
In-Reply-To: <449A2B20.2020006@candelatech.com>
On 6/21/06, Ben Greear <greearb@candelatech.com> wrote:
> Kok, Auke wrote:
> > CRC stripping is breaking SMBUS-connected BMC's. We disable this
> > feature to make it work. This fixes related bugs regarding SOL.
>
> Shouldn't you also have to subtract 4 bytes when setting the skb len
> in the receive logic? Perhaps when setting the rx-bytes counter as well?
we thought about this, but most drivers don't strip the CRC, and we
couldn't find any tests including bridging that cared if the CRC was
there in the indicated packet.
If you can find me a failing case I'll fix it. It was much simpler to
leave it out, especially when we add back in the multiple descriptor
receive code in the future (think about the case when subtracting the
CRC makes the last descriptor disappear)
Once again, let me know if you have info I don't :-)
Thanks for the review,
Jesse
^ permalink raw reply
* Re: Binding a packet socket to interface down
From: Evgeniy Polyakov @ 2006-06-22 15:51 UTC (permalink / raw)
To: Robert Iakobashvili; +Cc: netdev
In-Reply-To: <7e63f56c0606220832i6b00f77bk352482c4a7c638cb@mail.gmail.com>
On Thu, Jun 22, 2006 at 06:32:29PM +0300, Robert Iakobashvili (coroberti@gmail.com) wrote:
> Hi,
>
> When packet socket (PF_SOCKET) is attempted in syscall bind () to the
> network interface, which is down (no IF_UPP flag), packet_do_bind ()
> sets error to the socket, but bind () does not fail.
>
> When datagram, stream or raw socket fail to bind to some local
> ip-port/ip, bind () fails.
>
> Is this behavior of bind () for packet socket done deliberately, or
> better to correct it so that bind will fail and return errno, e.g. ENODEV?
> Thanks.
man page says that packet socket does not handle any errors.
And actually packet socket binds to the device, but you can not read
data. When device will be turned on, packet socket should start
to function (packet_notifier() -> NETDEV_UP)..
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: Ryan Pratt @ 2006-06-22 15:57 UTC (permalink / raw)
To: Paul Moore
Cc: David Miller, redhat-lspp, selinux, linux-security-module, netdev,
sds, jmorris, sgrubb
In-Reply-To: <200606220943.11185.paul.moore@hp.com>
Paul Moore wrote:
>On Thursday 22 June 2006 5:12 am, David Miller wrote:
>
>
>>From: paul.moore@hp.com
>>Date: Wed, 21 Jun 2006 15:42:38 -0400
>>
>>
>>
>>The thing that concerns me most about CIPSO is that even once users
>>migrate to a more SELINUX native approach from this CIPSO stuff, the
>>CIPSO code, it's bloat, and it's maintainence burdon will remain.
>>
>>It's easy to put stuff it, it's impossible to take stuff out even
>>once it's largely unused by even it's original target audience.
>>
>>And that's what I see happening here.
>>
>>This is why, to be perfectly honest with you, I'd much rather
>>something like this stay out-of-tree and people are strongly
>>encouraged to use the more native stuff under Linux.
>>
>>
>
>Well, not exactly the response I was hoping for, but let me plead my case one
>more time :)
>
>Traditional MLS CIPSO is a niche "protocol", I won't try to argue that point,
>and I also won't try to argue that the NetLabel patch is late to the party,
>the IPsec/XFRM labeling approach has already been accepted as "the" SELinux
>packet labeling mechanism. However, the XFRM labeling mechanism in not
>currently supported by any OS other than Linux/SELinux. I have spoken with
>users that need CIPSO to interoperate with their other trusted systems, the
>XFRM approach is simply not a viable solution for them. I strongly believe
>that failure to support an interoperable packet labeling mechanism on Linux
>will seriously restrict Linux's deployment in trusted networks.
>
The PitBull product uses the CIPSO/RIPSO labeling protocol in order to
do interop packet labeling with other trusted systems and for passing
labels between our own systems. Because it is the standard, it is the
protocol that government agencies use to do packet labeling across
networks. Not having CIPSO in the mainline would mean that government
agencies would either a) only use SELinux from a distro that supports
the CIPSO patch (by maintaining it in their kernel themselves), if such
a distro exists, b) have to patch the kernels themselves (unlikely), or
c) not use SELinux at all.
Also, the port of PitBull to Linux that I'm working on is currently
using the netlabel patch to handle the CIPSO/RIPSO labeling. Since the
actual protocol for reading and writing out the IPSec option is
independent from the security enforcment module it makes a lot of sense
to have a generic handler in the kernel that LSM modules can use. So,
in short, it makes my life a lot easier to have all that work already
done :)
--
Ryan Pratt
Chief Solaris Engineer
Innovative Security Systems, Inc.
(dba Argus Systems Group)
1809 Woodfield Dr.
Savoy IL 61874
(217) 355-6308
www.argus-systems.com
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Ben Greear @ 2006-06-22 15:55 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Kok, Auke, Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke,
Ronciak, John
In-Reply-To: <4807377b0606220839i5de14797ocb9e404fd21540e3@mail.gmail.com>
Jesse Brandeburg wrote:
> On 6/21/06, Ben Greear <greearb@candelatech.com> wrote:
>
>> Kok, Auke wrote:
>> > CRC stripping is breaking SMBUS-connected BMC's. We disable this
>> > feature to make it work. This fixes related bugs regarding SOL.
>>
>> Shouldn't you also have to subtract 4 bytes when setting the skb len
>> in the receive logic? Perhaps when setting the rx-bytes counter as well?
>
>
> we thought about this, but most drivers don't strip the CRC, and we
> couldn't find any tests including bridging that cared if the CRC was
> there in the indicated packet.
>
> If you can find me a failing case I'll fix it. It was much simpler to
> leave it out, especially when we add back in the multiple descriptor
> receive code in the future (think about the case when subtracting the
> CRC makes the last descriptor disappear)
>
> Once again, let me know if you have info I don't :-)
It should only be a problem if skb->len includes the extra 4 bytes for
the crc. Then, if I transmit that skb to another interface, I am afraid
that the crc will be seen as data in the packet. In the 2.6.13 days,
the e1000 did not strip the CRC, but it subtracted 4 before it did the
skb_put. So, the crc was correctly stripped/ignored. The e100
functioned similarly I believe.
If you skb_put the extra 4 bytes, I believe this will break my
(proprietary) app because on transmit it will append the extra 4 crc
bytes, but that isn't your problem..and I can work around it. If the
receiving NIC can handle pkts 4 bytes bigger than normal, it will
probably still receive the packet w/out problem, but in truth, the frame
will not be exactly correct.
When you did your bridging tests, did you sniff the packets on the far
side of the bridge to see if they were the right size?
Thanks,
Ben
>
> Thanks for the review,
> Jesse
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Jiri Benc @ 2006-06-22 15:55 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Stefan Rompf, Francois Romieu, netdev, Vojtech Pavlik
In-Reply-To: <200606171705.59498.IvDoorn@gmail.com>
On Sat, 17 Jun 2006 17:05:55 +0200, Ivo van Doorn wrote:
> With this approach more buttons can be registered,
> it includes the optional field to report an update of the key status
> to the driver that registered it, and it supports for non-polling keys.
I think this is not specific to networking anymore, so it should go to
lkml. Please be sure to Cc: input devices maintainer, Dmitry Torokhov.
Regarding rfkill button, I talked about that with Vojtech Pavlik (Cc:ed)
and he suggests this solution:
- driver is responsible for turning on/off radio when the input device
is not opened;
- when something opens the input device, it receives input events and
gets responsible to turn on/off the radio (by ioctl or putting the
network interfaces up/down).
This is of course not possible for all hardware, but it gives the most
flexibility while keeping the possibility to switch of the radio without
userspace support.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Lennert Buytenhek @ 2006-06-22 15:57 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Ben Greear, Kok, Auke, Garzik, Jeff, netdev, Brandeburg, Jesse,
Kok, Auke, Ronciak, John
In-Reply-To: <4807377b0606220839i5de14797ocb9e404fd21540e3@mail.gmail.com>
On Thu, Jun 22, 2006 at 08:39:10AM -0700, Jesse Brandeburg wrote:
> >> CRC stripping is breaking SMBUS-connected BMC's. We disable this
> >> feature to make it work. This fixes related bugs regarding SOL.
> >
> >Shouldn't you also have to subtract 4 bytes when setting the skb len
> >in the receive logic? Perhaps when setting the rx-bytes counter as well?
>
> we thought about this, but most drivers don't strip the CRC,
Really?
> and we couldn't find any tests including bridging that cared if the
> CRC was there in the indicated packet.
Bridging definitely cares -- some years ago there was a case where
8139too NICs would pass packets up the stack with 4 bytes of FCS, and
that causes frames received on 8139too interfaces not to be forwarded
to other interfaces because on TX, the frame would be too long.
Maybe e1000 is okay with sending oversized frames, but other NIC
drivers might not be.
(Did you test without bridge-netfilter enabled? bridge-nf might trim
incoming IP packets even in the bridging case.)
cheers,
Lennert
^ permalink raw reply
* Re: [PATCH 11/21] e1000: disable CRC stripping workaround
From: Jesse Brandeburg @ 2006-06-22 16:01 UTC (permalink / raw)
To: Ben Greear
Cc: Kok, Auke, Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke,
Ronciak, John
In-Reply-To: <449ABD6D.9090808@candelatech.com>
On 6/22/06, Ben Greear <greearb@candelatech.com> wrote:
> Jesse Brandeburg wrote:
> > On 6/21/06, Ben Greear <greearb@candelatech.com> wrote:
> >
> >> Kok, Auke wrote:
> >> > CRC stripping is breaking SMBUS-connected BMC's. We disable this
> >> > feature to make it work. This fixes related bugs regarding SOL.
> >>
> >> Shouldn't you also have to subtract 4 bytes when setting the skb len
> >> in the receive logic? Perhaps when setting the rx-bytes counter as well?
> >
> >
> > we thought about this, but most drivers don't strip the CRC, and we
> > couldn't find any tests including bridging that cared if the CRC was
> > there in the indicated packet.
> >
> > If you can find me a failing case I'll fix it. It was much simpler to
> > leave it out, especially when we add back in the multiple descriptor
> > receive code in the future (think about the case when subtracting the
> > CRC makes the last descriptor disappear)
> >
> > Once again, let me know if you have info I don't :-)
>
> It should only be a problem if skb->len includes the extra 4 bytes for
> the crc. Then, if I transmit that skb to another interface, I am afraid
> that the crc will be seen as data in the packet. In the 2.6.13 days,
> the e1000 did not strip the CRC, but it subtracted 4 before it did the
> skb_put. So, the crc was correctly stripped/ignored. The e100
> functioned similarly I believe.
currently the e100 driver in 2.6.X strips the CRC in hardware.
> If you skb_put the extra 4 bytes, I believe this will break my
> (proprietary) app because on transmit it will append the extra 4 crc
> bytes, but that isn't your problem..and I can work around it. If the
> receiving NIC can handle pkts 4 bytes bigger than normal, it will
> probably still receive the packet w/out problem, but in truth, the frame
> will not be exactly correct.
>
> When you did your bridging tests, did you sniff the packets on the far
> side of the bridge to see if they were the right size?
hm, probably not, we touch tested bridging (probably with TCP), and
have completed several internal testing passes, to make sure it worked
but I don't think we went so far as to sniff the traffic at the
other end of the bridge. I'll look into it.
Jesse
^ permalink raw reply
* Re: [RFC] sysfs + configfs on 802.11 wireless drivers
From: Michael Wu @ 2006-06-22 16:44 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: netdev, John W. Linville, Greg KH
In-Reply-To: <43e72e890606220512h5197d473s5f7da9e734814005@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
On Thursday 22 June 2006 05:12, Luis R. Rodriguez wrote:
> (3) On resume() talk to userspace via netlink to read our sysfs and
> configfs us
>
I think that's fairly overkill. I really do not like the idea of requiring any
more userspace involvement in the suspend process than needed. At least for
ADM8211, all the data needed to restore the card properly is already stored
somewhere for userspace (iwconfig) to query, so I don't understand how this
is suppose to reduce bloat. All the data that is needed should already be
stored in the driver to support configuring the interface before taking the
interface up.
-Michael Wu
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [1/1] Kevent subsystem.
From: Evgeniy Polyakov @ 2006-06-22 17:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
Hello.
Kevent subsystem incorporates several AIO/kqueue design notes and ideas.
Kevent can be used both for edge and level notifications. It supports
socket notifications, network AIO (aio_send(), aio_recv() and
aio_sendfile()), inode notifications (create/remove),
generic poll()/select() notifications and timer notifications.
It was tested against FreeBSD kqueue and Linux epoll and showed
noticeble performance win.
Network asynchronous IO operations were tested against Linux synchronous
socket code and showed noticeble performance win.
Patch against linux-2.6.17-git tree attached (gzipped).
I would like to hear some comments about the overall design,
implementation and plans about it's usefullness for generic kernel.
Design notes, patches, userspace application and perfomance tests can be
found at project's homepages.
1. Kevent subsystem.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
2. Network AIO.
http://tservice.net.ru/~s0mbre/old/?section=projects&item=naio
3. LWN article about kevent.
http://lwn.net/Articles/172844/
Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Thank you.
--
Evgeniy Polyakov
[-- Attachment #2: kevent-2.6.17-git.diff.gz --]
[-- Type: application/x-gunzip, Size: 24054 bytes --]
^ permalink raw reply
* Re: [PATCH] Export accept queue len of a TCP listening socket via rx_queue
From: Sridhar Samudrala @ 2006-06-22 17:38 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, netdev
In-Reply-To: <E1FtDPD-0005mc-00@gondolin.me.apana.org.au>
On Thu, 2006-06-22 at 10:50 +1000, Herbert Xu wrote:
> Sridhar Samudrala <sri@us.ibm.com> wrote:
> >>
> >> What about using the same fields (rqueue/wqueue) as you did for /proc?
> >
> > I meant extending tcp_info structure to add new fields. I think the user
> > space also uses this structure.
>
> What about putting it into inet_idiag_msg.idiag_[rw]queue instead?
OK. I was under the mistaken assumption that [rw]queue fields are exported
via tcp_info. This makes it pretty simple to support netlink users also.
Here is the updated patch.
Thanks
Sridhar
While debugging a TCP server hang issue, we noticed that currently there is
no way for a user to get the acceptq backlog value for a TCP listen socket.
All the standard networking utilities that display socket info like netstat,
ss and /proc/net/tcp have 2 fields called rx_queue and tx_queue. These
fields do not mean much for listening sockets. This patch uses one of these
unused fields(rx_queue) to export the accept queue len for listening sockets.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index c148c10..b56399c 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -26,7 +26,10 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
+ if (sk->sk_state == TCP_LISTEN)
+ r->idiag_rqueue = sk->sk_ack_backlog;
+ else
+ r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
r->idiag_wqueue = tp->write_seq - tp->snd_una;
if (info != NULL)
tcp_get_info(sk, info);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 25ecc6e..4c6ef47 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1726,7 +1726,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
"%08X %5d %8d %lu %d %p %u %u %u %u %d",
i, src, srcp, dest, destp, sp->sk_state,
- tp->write_seq - tp->snd_una, tp->rcv_nxt - tp->copied_seq,
+ tp->write_seq - tp->snd_una,
+ (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk->icsk_retransmits,
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index a50eb30..b36d5b2 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1469,7 +1469,8 @@ static void get_tcp6_sock(struct seq_fil
dest->s6_addr32[0], dest->s6_addr32[1],
dest->s6_addr32[2], dest->s6_addr32[3], destp,
sp->sk_state,
- tp->write_seq-tp->snd_una, tp->rcv_nxt-tp->copied_seq,
+ tp->write_seq-tp->snd_una,
+ (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk->icsk_retransmits,
^ permalink raw reply related
* Executive Management Placement
From: Mr.David Aaron Simmond @ 2006-06-22 18:29 UTC (permalink / raw)
David Aaron Simmonds.
David A. Simmonds Consultancy
Suite 14 Millers
Yard
Mill Lane, Cambridge
CB2 1RQ, ENGLAND
Private Email:
davidsconsultant@aim.com
Cell Phone: +44 704 011 9859
Tel/Fax: +44 870
490 2540
Dear Executive,
Subject: Executive Management Placement
I
am facilitating for a private investor who has interest to do business
relative to long term investments in your Company or Country. The area
of interest is Health, Real Estate, Crude-Oil, Farm, Services and
construction or any business of your choice.
You will be required
to;
[1]. Receive the funds in cash into a business/private bank
account.
[2]. Invest and Manage the funds in the specified areas of
investment.
The total sum available for investment is Twenty One
Million, Five Hundred Thousand United States Dollars. My client is
willing to pay 10% as participation fee for your role as the receiver
partner to the funds and a subsequent 10% "Management Commission" for
your advised investment services. Absolute confidentiality and
professionalism is required in the handling of this funds and
subsequent investments.
Direct all your enquiries to My Email:
david_simmond50@graffiti.net You may as well send me your Direct
Telephone and Cell phone number so to ease communication.
I look
forward to your swift response to this mail.
Sincerely Yours.
David
Simmonds
David A. Simmonds Consultancy
^ permalink raw reply
* Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
From: jamal @ 2006-06-22 18:41 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, hawk, russell-tcatm, netdev,
Stephen Hemminger
In-Reply-To: <44980FA3.1000009@trash.net>
On Tue, 2006-20-06 at 17:09 +0200, Patrick McHardy wrote:
> jamal wrote:
> "Depend on bandwidth" is not the right term. All of TBF, HTB and HFSC
> provide bandwidth per time, but with TBF and HTB the relation between
> the amount of bandwidth is linear to the amount of time, with HFSC
> it is only on a linear on larger scale since it uses service curves,
> which are represented as two linear pieces. So you have bandwidth b1
> for time t1, bandwidth b2 after that until eternity. By scaling the
> clock rate you alter after how much time b2 kicks in, which affects
> the guaranteed delays. The end result should be that both bandwidth
> and delay scale up or down proportionally, but I'm not sure that this
> is what HFSC would do in all cases (on small scale). But it should
> be easy to answer with a bit more time for visualizing it.
>
Ok, this makes things a little trickier though, no?
> The thing I'm not sure about is whether this wouldn't be handled better
> by userspace,
If you do it in user space you will need a daemon of some form; this is
my preference but it seems a lot of people hate daemons - the standard
claim is it is counter-usability. Such people are forgiving if you built
the daemon into the kernel as a thread. Perhaps the netcarrier that
Stefan Rompf has added could be extended to handle this)
Note, if you wanna do it right as well you will factor in other things
like some wireless technologies which changes their throughput
capability over a period of time ( A lot of these guys try to have their
own hardware level schedulers to compensate for this).
> if the link layer speed changes you might not want
> proportional scaling but prefer to still give a fixed amount of that
> bandwidth to some class, for example VoIP traffic. Do we have netlink
> notifications for link speed changes?
Not there at the moment - but we do emit event for other link layer
stuff like carrier on/off - so adding this should be trivial and a
reasonable thing to have; with a caveat: it will be link-layer specific;
so whoever ends up adding will have to be careful to make sure it is not
hard-coded to be specific to ethernet-like netdevices. It could probably
be reported together with link state as a TLV like ETHER_SPEED_CHANGED
which carries probably old speed and new speed
and maybe even reason why it changed.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 7/32] [TIPC] Multicast link failure now resets all links to "nacking" node.
From: James Morris @ 2006-06-22 18:51 UTC (permalink / raw)
To: Per Liden; +Cc: David Miller, netdev, Allan Stephens
In-Reply-To: <1150984785859-git-send-email-per.liden@ericsson.com>
On Thu, 22 Jun 2006, Per Liden wrote:
> +static void link_reset_all(unsigned long addr)
> +{
> + struct node *n_ptr;
> + char addr_string[16];
> + u32 i;
> +
> + read_lock_bh(&tipc_net_lock);
> + n_ptr = tipc_node_find((u32)addr);
> + if (!n_ptr) {
> + read_unlock_bh(&tipc_net_lock);
> + return; /* node no longer exists */
> + }
> +
> + tipc_node_lock(n_ptr);
You already have bh's disabled here, and tipc_node_lock() also disables
them.
Not sure if it's really worth worrying about but if so, you could perhaps
implement tipc_node_lock_bh() and tipc_node_lock().
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC 2/7] NetLabel: core network changes
From: James Morris @ 2006-06-22 18:58 UTC (permalink / raw)
To: Steve Grubb
Cc: David Miller, paul.moore, redhat-lspp, selinux,
linux-security-module, netdev, sds, jmorris
In-Reply-To: <200606221105.00331.sgrubb@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1049 bytes --]
On Thu, 22 Jun 2006, Steve Grubb wrote:
> On Thursday 22 June 2006 05:00, David Miller wrote:
> > > #define NETLINK_GENERIC 16
> > > +#define NETLINK_NETLABEL 17 /* Network packet labeling */
> > >
> > > #define MAX_LINKS 32
> >
> > Please use generic netlink.
>
> Since this is a security interface, shouldn't it be its own protocol so that
> SE Linux can control commands being sent? Paul's patches do include a netlink
> table in security/selinux/nlmsgtab.c. But I do not see any hooks to control
> generic netlink messages. (There seems to be several protocols that SE Linux
> is not controlling.) I could see that someone in secadm role should be able
> to issue these commands, but someone at sysadm or auditadm would not.
>
> If moving this over to generic is a must, then I think SE Linux will have to
> clip into generic to control its packet flow.
SELinux will mediate them as 'generic' netlink.
Fine-grained SELinux support for generic netlink is todo.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [1/1] Kevent subsystem.
From: James Morris @ 2006-06-22 19:01 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: David Miller, netdev
In-Reply-To: <20060622171436.GA26161@2ka.mipt.ru>
On Thu, 22 Jun 2006, Evgeniy Polyakov wrote:
> Patch against linux-2.6.17-git tree attached (gzipped).
> I would like to hear some comments about the overall design,
> implementation and plans about it's usefullness for generic kernel.
Please send patches as in-line ascii text, along with documentation.
If they're too big, split them up logically into smaller pieces.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
From: jamal @ 2006-06-22 19:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: Jesper Dangaard Brouer, netdev, Stephen Hemminger, Alan Cox,
Russell Stuart
In-Reply-To: <44982781.8030301@trash.net>
On Tue, 2006-20-06 at 18:51 +0200, Patrick McHardy wrote:
> jamal wrote:
> > The issue is really is whether Linux should be interested in the
> > throughput it is told about or the goodput (also known as effective
> > throughput) the service provider offers. Two different issues by
> > definition.
> In the case of PPPoE non-work-conserving qdiscs are already used
> to manage a link that is non-local with knowledge of the its
> bandwidth,
I think that is a different issue though- you are managing a
point-to-point link then you will be working under the assumption of
throughput not goodput.
If you had knowledge of the goodput you should use that for a working
assumption; i think in practise that approach is valuable.
My arguement is against trying to make complex changes to compensate
the scheduler for such changes. Therefore i am not feeling sorry
for the poor guy who has to go and tell their PPP device "bandwith is
only 1Mbps" when their ISP is claiming it is 2Mbps i.e
The ADSL case i have seen thus far is you trying manage something
because a BRAS 3-4 hops down the path uses ATM. To use my earlier
example the arguement is no different than saying 3-4 hops downlink
there is a wireless link which is 20% lossy. Armed with knowledge
like that you can tell something to the scheduler to resolve thing.
The daemon in user space for example could be sending bandwidth
measuring probes and telling the kernel of the new goodput.
> contrary to a local link that would be best managed
> in work-conserving mode. And I think for better accuracy it is
> necessary to manage effective throughput, especially if you're
> interested in guaranteed delays.
>
Indeed - but "fixing" the scheduler to achieve such management is not
the first choice (would be fine if it is generic and non-intrusive)
> >>>Yes, Linux cant tell if your service provider is lying to you.
> >>
> >>I wouldn't call it lying as long as they don't say "1.5mbps IP
> >>layer throughput".
> >
> >
> > It is a scam for sure.
> > By definition of what throughput is - you are telling the truth; just
> > not the whole truth. Most users think in terms of goodput and not
> > throughput.
> > i.e you are not telling the whole truth by not saying "it is 1.5Mbps ATM
> > throughput". Tpyically not an issue until somebody finds that by leaving
> > out "ATM" you meant throughput and not goodput.
>
>
> I think that point can be used to argue in favour of that Linux should
> be able to manage effective throughput :)
>
I think you have convinced me this is valuable I even suggest probes
above to discover goodput;-). I hope i have convinced you how rude it
would be to make extensive changes to compensate for goodput;->
> > I am saying that #2 is the choice to go with hence my assertion earlier,
> > it should be fine to tell the scheduler all it has is 1Mbps and nobody
> > gets hurt. #1 if i could do it with minimal intrusion and still get to
> > use it when i have 802.11g.
> >
> > Not sure i made sense.
>
> HFSC is actually capable of handling this quite well. If you use it
> in work-conserving mode (and the card doesn't do (much) internal
> queueing) it will get clocked by successful transmissions. Using
> link-sharing classes you can define proportions for use of available
> bandwidth, possibly with upper limits. No hacks required :)
>
HFSC sounds very interesting - I should go and study it a little more.
My understanding is though that it is a bit of a CPU pig, true?
> Anyway, this again goes more in the direction of handling link speed
> changes.
>
The more we discuss this, the more i think they are the same thing ;->
> > ip dev add compensate_header 100 bytes
>
> Something like that, but its a bit more complicated.
> For ATM we need some mapping:
> [0-48] -> 53
> [49-96] -> 106
> ...
>
> for Ethernet we need:
> [0-60] -> 64
> [60-n] -> n + 4
>
an upper bound check against MTU would be reasonable.
> We could do something like this (feel free to imagine nicer names):
>
The name should reflect that the table exists to "compensate for
goodput".
> ATM:
> table = {
> .step = 53,
> .map = {
> [0..48] = 53,
> [49..96] = 106,
> ...
> }
> };
>
> Requiring a table of size 32 for typical MTUs.
>
> Ethernet:
>
> table = {
> .step = 60,
> .map = {
> [0..60] = 60,
> [...] = 0,
> },
> .fixed_overhead = 4,
> };
>
> static inline unsigned int
> skb_wire_len(struct sk_buff *skb, struct net_device *dev)
> {
> unsigned int idx, len;
>
> if (dev->lengthtable == NULL)
> return skb->len;
> idx = skb->len / dev->lengthtable->step;
> len = dev->lengthtable->map[idx];
> return dev->lengthtable->fixed_overhead + len ? len : skb->len;
> }
>
> Unforunately I can't think of a way to handle the ATM case without
> a division .. or iteration.
>
I am not thinking straight right now but it does not sound like a big
change to me i.e within reason. Note, it may be valuable to think of
this as related to the speed changing daemon as i stated earlier.
Only in this case it is "static" discovery of link layer
goodput/throughput vs some other way to dynamically discover things.
cheers,
jamal
^ permalink raw reply
* Re: [DOC]: generic netlink
From: jamal @ 2006-06-22 19:07 UTC (permalink / raw)
To: Thomas Graf; +Cc: netdev, David S. Miller, Jay Lan, Shailabh Nagar, Per Liden
In-Reply-To: <20060620213435.GN1376@postel.suug.ch>
On Tue, 2006-20-06 at 23:34 +0200, Thomas Graf wrote:
> Ask Mr. Mashimaro has become my replacement for 8ball. Renaming
> it would lead to a serious loss of coolness ;-)
>
;-> Blame Dave for that ;->
I think if you put it in some website, I will just add a url to point to
it. Shailabh has sent me an extension to the example, but i think it is
still not encompassing.
> > > > b) Describe some details on how user space -> kernel works
> > > > probably using libnl??
> > >
> > > I'll take care of that.
> >
> > Whats the plan? To add to this doc or separate doc?
>
> The status is that the code is there including userspace tools
> to query the controller.
I have a patch for the controller for iproute2 that i would like to
submit as well - but that is separate from this i think.
> Documentation is written as part of
> the API reference (coming up with -pre6), no architectural notes
> yet though. I think it's best to keep it separated and refer to
> it both ways.
>
So you mean just refer to the one in the kernel headers?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH, RFT] bcm43xx: AccessPoint mode
From: Alexander Tsvyashchenko @ 2006-06-22 19:08 UTC (permalink / raw)
To: Jiri Benc, Michael Buesch
Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko, Francois Barre
In-Reply-To: <20060622173013.28e61873@griffin.suse.cz>
Hello Jiri,
On 6/22/2006, "Jiri Benc" <jbenc@suse.cz> wrote:
>Great work! I was even able to ping. (Tried only open system
>authentication for now, it seems it works quite well.)
Well, I use first version of this patch from the end of April, and had no
problems so far, so,
while it's probably cannot be really called "stable" yet, it's at
least 'working somehow" ;-)
>Or, if you don't want to patch hostapd (untested, but should work):
>
>iwpriv wlan0 param 1046 1
>ip link set wmgmt0 name wmaster0ap
>hostapd /path/to/hostapd.conf
>iwpriv wlan0 param 1046 0
Thanks for the information! This is easier way indeed ;-)
>Hopefully we will convert the whole hostapd<->stack communication to
>netlink in some near future ;-)
Yes, it would be nice if things get a bit more settled & stable there ;-)
>> 2) Insert modules (80211, rate_control and bcm43xx-d80211)
>
>modprobe bcm43xx-d80211 is enough, other modules will load
>automatically.
I just had no modprobe on my test system, that's why I listed all of
them separately ;-)
But yes, for "normal" usage modprobe is easier.
>> 6) "iwconfig wlan0 essid <your-SSID-name>" (this also should not be
>> required, but current combination of hostapd + dscape doesn't seem to
>> generate config_interface callback when setting beacon, so this is
>> required just to force call of config_interface).
>
>The stack currently has very limited support for cards with "beacon
>templates". ieee80211_beacon_get function is not designed in a way it is
>used in bcm43xx. Although this seems to be easy to fix now, we will run
>into other problems later (with TIM elements mainly).
>I need to look how PS mode works in bcm chipsets to find a correct
>solution for this. Do you have any ideas?
Well, current use of ieee80211_beacon_get in bcm43xx is plain wrong
indeed,
it just happens that it seems to work anyway ;-)
As for the PS, the main problem currently seems to be the lack of hardware
specifications: quite some things that are needed to make it work are
unknown.
The information/speculations I have so far
(please note my understanding of 802.11 specs is very limited!!!):
1) TIM seems to be generated by software (I think it was confirmed by smb
from specs group).
2) DTIM counter in beacons sent is updated by hardware (confirmed by
specs group).
3) There is PS interrupt that in my experiments seemed to correlate with
the beacon interval
(one PS interrupt for one beacon sent?)
My original idea was that it could be used to update beacon template, but
specs group seemed
to be sceptical about this idea saying that in original driver the beacon
template was not updated
in PS interrupt handler.
Now I think that it's, probably, not necessary to update beacon template
exactly before/after current
beacon is sent, as the reason to update beacon is only change in TIM, and
we can just update
template as soon as TIM is changed (so, some sort of callback from dscape
to the driver is needed).
However, this PS interrupt could be used for sending broadcast packets
(which, as far as I understood
from 802.11 specs, should be sent after DTIM beacon). To use it for this
purpose, we need the following information:
a) Confirmation that PS interrupt is invoked exactly after current
beacon is sent.
b) The way to know whether current beacon was DTIM or not.
I do not have answers to these questions so far :-(
Yet another idea (which still should be checked) is that probably, PS
interrupt is invoked not for every beacon,
but for DTIM beacons only (I'm not sure that in my experiments I had
DTIM interval larger than beacon interval,
so it's possible every TIM was DTIM, that's why PS interrupt was called
for every beacon).
There's yet another interrupt that I currently don't fully understand -
beacon update interrupt, I did not see it called at all
so far, so I don't know where/how it could be used.
All other PS things seem to be relatively OK - there's also some support
in hardware for processing entering/exiting
PS mode for STAs, but these packets seem to be passed to dscape layer
also, and as they are already processed
in dscape, it looks like there's no need to bother with using hardware
for that.
Currently I just have not enough time to finish the experiments with PS,
and anyway I'm afraid some of these
things can be a bit hard to find out by experimenting only :-(
Good luck! Alexander
^ permalink raw reply
* Re: [NET]: Prevent multiple qdisc runs
From: jamal @ 2006-06-22 19:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller, Robert Olsson
In-Reply-To: <20060620235207.GA31493@gondor.apana.org.au>
On Wed, 2006-21-06 at 09:52 +1000, Herbert Xu wrote:
> Well my gut feeling is that multiple qdisc_run's on the same dev can't
> be good for perfomance. The reason is that SMP is only good when the
> CPUs work on different tasks. If you get two or more CPUs to work on
> qdisc_run at the same time they can still only supply one skb to the
> device at any time. What's worse is that they will now have to fight
> over the two spin locks involved which means that their cache lines
> will bounce back and forth.
1) If the CPUs collide all the time it is without a doubt
it is a bad thing (you can tell from tx_collission stats).
2) If on the other hand, the iota that a CPU enters that path in the
softirq it gets the txlock then there is benefit to not serialize
at the level you have done with that patch - you are enlarging the
granularity of the serialization so much so that the CPU wont even
get the opportunity to try and grab tx lock because it finds qdisc is
already running.
Your gut feeling is for #1 and my worry is for #2 ;->
I actually think your change is obviously valuable for scenarios where
the bus is slower and therefore transmits take longer - my feeling is it
may not be beneficial for fast buses like PCI-E or high speed PCI/X
where the possibility of getting access tx collision is lower.
The other reason I mentioned earlier as justification to leave the
granularity at the level where it was is for good qos clocking. i.e
to allow incoming packets to be used to clock the tx path - otherwise
you will be dependent on HZ for your egress rate accuracy. I am not sure
if this later point made sense - I could elaborate.
The experiment needed to prove things is not hard: one needs to get a 2
or 4way machine and create a "funneling" effect to one NIC.
For forwarding, the best setup will be to have 3 NICs. packets coming in
on 2 NICs are forwarded to a third. The incoming-packet NICS are tied to
different CPUs. In a 4way, the outgoing as well is tied to its own CPU.
You then pummel the two incoming CPUs with pktgen or otherwise
at something like 1Mpps (which is higher than the wire rate the third
nic can handle).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: jamal @ 2006-06-22 19:43 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, David Miller
In-Reply-To: <1150990041.3040.6.camel@stevo-desktop>
On Thu, 2006-22-06 at 10:27 -0500, Steve Wise wrote:
>
> The in-kernel Infiniband subsystem needs to know when certain events
> happen. For example, if the mac address of a neighbour changes. Any
> rdma devices that are using said neighbour need to be notified of the
> change. You are asking that I extend the netlink facility (if
> necessary) to provide this functionality.
>
No - what these 2 gents are saying was these events and infrastructure
already exist. If there are some events that dont and you need to extend
what already exists. Your patch was a serious reinvention of the wheel
(and in the case of the neighbor code looking very wrong).
As an example, search for NETDEV_CHANGEADDR,NETDEV_CHANGEMTU etc.
Actually you are probably making this too complicated. Listen to events
in user space and tell infiniband from user space.
cheers,
jamal
^ permalink raw reply
* Re: [1/1] Kevent subsystem.
From: Robert Iakobashvili @ 2006-06-22 19:53 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev
In-Reply-To: <20060622171436.GA26161@2ka.mipt.ru>
Evgeniy,
On 6/22/06, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> Kevent subsystem incorporates several AIO/kqueue design notes and ideas.
> Kevent can be used both for edge and level notifications. It supports
> socket notifications, network AIO (aio_send(), aio_recv() and
> aio_sendfile()), inode notifications (create/remove),
> generic poll()/select() notifications and timer notifications.
Great job!
Smooth integration with userland asynch POSIX frameworks
(e.g. ACE POSIX_Proactor) may require syscalls (or their emulation)
with POSIX interface:
* POSIX_API
* aio_read
* aio_write
* aio_suspend
* aio_error
* aio_return
* aio_cancel
where aio_suspend is very important.
--
Sincerely,
------------------------------------------------------------------
Robert Iakobashvili, coroberti at gmail dot com
Navigare necesse est, vivere non est necesse.
------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: Steve Wise @ 2006-06-22 20:18 UTC (permalink / raw)
To: hadi; +Cc: netdev, David Miller
In-Reply-To: <1151005381.5392.108.camel@jzny2>
On Thu, 2006-06-22 at 15:43 -0400, jamal wrote:
> On Thu, 2006-22-06 at 10:27 -0500, Steve Wise wrote:
>
> >
> > The in-kernel Infiniband subsystem needs to know when certain events
> > happen. For example, if the mac address of a neighbour changes. Any
> > rdma devices that are using said neighbour need to be notified of the
> > change. You are asking that I extend the netlink facility (if
> > necessary) to provide this functionality.
> >
>
> No - what these 2 gents are saying was these events and infrastructure
> already exist. If there are some events that dont and you need to extend
> what already exists. Your patch was a serious reinvention of the wheel
> (and in the case of the neighbor code looking very wrong).
ok.
> As an example, search for NETDEV_CHANGEADDR,NETDEV_CHANGEMTU etc.
> Actually you are probably making this too complicated.
NETDEV_CHANGEADDR uses a notifier block, and the network subsystem calls
call_netdevice_notifiers() when it sets an addr. And any kernel module
can register for these events. That's the model I used to create the
netevent_notifier mechanism in the patch I posted.
I could add the new events to this netdevice notifier, but these aren't
really net device events. Their network events.
> Listen to events
> in user space and tell infiniband from user space.
>
I can indeed extend the rtnetlink stuff to add the events in question
(neighbour mac addr change, route redirect, etc). In fact, there is
similar functionality under the CONFIG_ARPD option to support a user
space arp daemon. Its not quite the same, and it doesn't cover redirect
and routing events, just neighbour events.
But in the case of the RDMA subsystem, the consumer of these events is
in the kernel. Why is it better to propagate events all the way up to
user space, then send the event back down into the Infiniband kernel
subsystem? That seems very inefficient.
Steve.
^ permalink raw reply
* [PATCH] WAN: register_hdlc_device() doesn't need dev_alloc_name()
From: Krzysztof Halasa @ 2006-06-22 20:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
David Boggs noticed that register_hdlc_device() no longer needs
to call dev_alloc_name() as it's called by register_netdev().
register_hdlc_device() is currently equivalent to register_netdev().
hdlc_setup() is now EXPORTed as per David's request.
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
--- a/include/linux/hdlc.h
+++ b/include/linux/hdlc.h
@@ -188,7 +188,7 @@ int hdlc_x25_ioctl(struct net_device *de
int hdlc_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd);
/* Must be used by hardware driver on module startup/exit */
-int register_hdlc_device(struct net_device *dev);
+#define register_hdlc_device(dev) register_netdev(dev)
void unregister_hdlc_device(struct net_device *dev);
struct net_device *alloc_hdlcdev(void *priv);
--- a/drivers/net/wan/hdlc_generic.c
+++ b/drivers/net/wan/hdlc_generic.c
@@ -259,7 +259,7 @@ int hdlc_ioctl(struct net_device *dev, s
}
}
-static void hdlc_setup(struct net_device *dev)
+void hdlc_setup(struct net_device *dev)
{
hdlc_device *hdlc = dev_to_hdlc(dev);
@@ -288,26 +288,6 @@ struct net_device *alloc_hdlcdev(void *p
return dev;
}
-int register_hdlc_device(struct net_device *dev)
-{
- int result = dev_alloc_name(dev, "hdlc%d");
- if (result < 0)
- return result;
-
- result = register_netdev(dev);
- if (result != 0)
- return -EIO;
-
-#if 0
- if (netif_carrier_ok(dev))
- netif_carrier_off(dev); /* no carrier until DCD goes up */
-#endif
-
- return 0;
-}
-
-
-
void unregister_hdlc_device(struct net_device *dev)
{
rtnl_lock();
@@ -326,8 +306,8 @@ EXPORT_SYMBOL(hdlc_open);
EXPORT_SYMBOL(hdlc_close);
EXPORT_SYMBOL(hdlc_set_carrier);
EXPORT_SYMBOL(hdlc_ioctl);
+EXPORT_SYMBOL(hdlc_setup);
EXPORT_SYMBOL(alloc_hdlcdev);
-EXPORT_SYMBOL(register_hdlc_device);
EXPORT_SYMBOL(unregister_hdlc_device);
static struct packet_type hdlc_packet_type = {
^ 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