* Re: [PATCH] ip: reuse ip_summed of first fragment for all subsequent fragments
From: Timo Juhani Lindfors @ 2011-02-16 9:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110112.184220.250810179.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> You're now not handling the code block above this one, guarded
> by the "if (len <= 0)" check.
Yes that's true. Should we use skb_copy_bits() when sk->sk_no_check ==
UDP_CSUM_NOXMIT?
> You seem to just be peppering checks all over the place rather
> than coming up with a coherent, complete, fix for this problem.
I can understand that but I'm afraid that I lack the expertise to do
that. I might be able to fix the above problem but I can't be sure that
it is the only one. The bug report will remain at
https://bugzilla.kernel.org/show_bug.cgi?id=24832
in case somebody wants to continue from here.
^ permalink raw reply
* Off-by-one error in net/8021q/vlan.c
From: Phil Karn @ 2011-02-16 10:58 UTC (permalink / raw)
To: kaber; +Cc: netdev
The range check on vlan_id in register_vlan_device is off by one, and it
prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
this, I checked.)
Here's the trivial patch:
--- linux-2.6.37/net/8021q/vlan.c~ 2011-01-04 16:50:19.000000000 -0800
+++ linux-2.6.37/net/8021q/vlan.c 2011-02-16 02:43:13.988812958 -0800
@@ -239,7 +239,7 @@
char name[IFNAMSIZ];
int err;
- if (vlan_id >= VLAN_VID_MASK)
+ if (vlan_id > VLAN_VID_MASK)
return -ERANGE;
err = vlan_check_real_dev(real_dev, vlan_id);
^ permalink raw reply
* Re: [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-16 11:30 UTC (permalink / raw)
To: KOVACS Krisztian
Cc: Patrick McHardy, netfilter-devel, netdev, Balazs Scheidler
In-Reply-To: <4D5B90C7.5040603@balabit.hu>
KOVACS Krisztian <hidden@balabit.hu> wrote:
> On 02/14/2011 04:51 PM, Patrick McHardy wrote:
> >Am 14.02.2011 12:44, schrieb Florian Westphal:
> >>Assigning a socket in timewait state to skb->sk can trigger
> >>kernel oops, e.g. in nfnetlink_log, which does:
> >>
> >>if (skb->sk) {
> >> read_lock_bh(&skb->sk->sk_callback_lock);
> >> if (skb->sk->sk_socket&& skb->sk->sk_socket->file) ...
> >>
> >>in the timewait case, accessing sk->sk_callback_lock and sk->sk_socket
> >>is invalid.
> >>
> >>Either all of these spots will need to add a test for sk->sk_state != TCP_TIME_WAIT,
> >>or xt_TPROXY must not assign a timewait socket to skb->sk.
> >>
> >>This does the latter.
> >>
> >>If a TW socket is found, assign the tproxy nfmark, but skip the skb->sk assignment,
> >>thus mimicking behaviour of a '-m socket .. -j MARK/ACCEPT' re-routing rule.
> >>
> >>The 'SYN to TW socket' case is left unchanged -- we try to redirect to the
> >>listener socket.
> >>
> >>Cc: Balazs Scheidler<bazsi@balabit.hu>
> >>Cc: KOVACS Krisztian<hidden@balabit.hu>
> >>Signed-off-by: Florian Westphal<fwestphal@astaro.com>
> >
> >Looks fine to me. Balazs. Krisztian, any objections?
>
> Seems to be OK, as far as I can see.
>
> Florian, did you make sure the tests still run after applying this patch?
>
> http://git.balabit.hu/?p=bazsi/tproxy-test.git;a=summary
Thanks for the hint, I cloned this and ran it on my test setup:
./tproxy-test.py
[..]
PASS: ('192.168.10.8', 50080), we got a connection as we deserved
PASS: everything is fine
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: richard -rw- weinberger @ 2011-02-16 12:51 UTC (permalink / raw)
To: Phil Karn; +Cc: kaber, netdev
In-Reply-To: <4D5BADCF.5000804@ka9q.net>
On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
> The range check on vlan_id in register_vlan_device is off by one, and it
> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
> this, I checked.)
Then OSX should fix their code. 4095 is reserved.
//richard
> Here's the trivial patch:
>
> --- linux-2.6.37/net/8021q/vlan.c~ 2011-01-04 16:50:19.000000000 -0800
> +++ linux-2.6.37/net/8021q/vlan.c 2011-02-16 02:43:13.988812958 -0800
> @@ -239,7 +239,7 @@
> char name[IFNAMSIZ];
> int err;
>
> - if (vlan_id >= VLAN_VID_MASK)
> + if (vlan_id > VLAN_VID_MASK)
> return -ERANGE;
>
> err = vlan_check_real_dev(real_dev, vlan_id);
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thanks,
//richard
^ permalink raw reply
* NFS on little-endian platform - Microblaze
From: Michal Simek @ 2011-02-16 13:09 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Hi All,
I am trying to understand one problem which we have found.
The problem is that I can't on Microblaze little-endian platform
mount nfs without -o nolock options. (Log below)
Selecting tcp or udp has no effect.
I am using emaclite driver and there is no problem on big endian microblaze.
ping, telnet, http, ftp, iperf, netperf work well.
That's why I have a question if there is any endian specific option for NFS?
Thanks,
Michal
~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
svc: failed to register lockdv1 RPC service (errno 13).
lockd_up: makesock failed, error=-13
svc: failed to register lockdv1 RPC service (errno 13).
~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
~ # mount
rootfs on / type rootfs (rw)
proc on /proc type proc (rw,relatime)
none on /var type ramfs (rw,relatime)
none on /sys type sysfs (rw,relatime)
none on /etc/config type ramfs (rw,relatime)
none on /dev/pts type devpts (rw,relatime,mode=600)
192.168.0.101:/tftpboot/nfs on /mnt type nfs
(rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
~ #
~ # ps
PID USER TIME COMMAND
1 root 0:02 init
2 root 0:00 [kthreadd]
3 root 0:00 [ksoftirqd/0]
4 root 0:00 [kworker/0:0]
5 root 0:00 [kworker/u:0]
6 root 0:00 [khelper]
7 root 0:00 [sync_supers]
8 root 0:00 [bdi-default]
9 root 0:00 [kblockd]
10 root 0:00 [rpciod]
11 root 0:00 [kworker/0:1]
12 root 0:00 [kswapd0]
13 root 0:00 [fsnotify_mark]
14 root 0:00 [aio]
15 root 0:00 [nfsiod]
16 root 0:00 [kworker/u:1]
58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
62 1 0:00 /bin/portmap
64 root 0:00 /bin/inetd /etc/inetd.conf
65 root 0:01 -sh
66 root 0:00 /bin/syslogd -n
67 root 0:00 /bin/flatfsd
68 root 0:00 [kworker/0:2]
91 root 0:00 ps
~ # cat /proc/cpuinfo
CPU-Family: MicroBlaze
FPGA-Arch: spartan6
CPU-Ver: 8.00.a, little endian
CPU-MHz: 50.00
BogoMips: 24.06
HW:
Shift: yes
MSR: yes
PCMP: yes
DIV: yes
MMU: 3
MUL: v2
FPU: no
Exc: op0x0 unal ill iopb dopb zero
Icache: 16kB line length: 32B
Dcache: 16kB line length: 16B
write-through
HW-Debug: yes
PVR-USR1: 00
PVR-USR2: 00000000
Page size: 4096
~ #
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: NFS on little-endian platform - Microblaze
From: Michal Simek @ 2011-02-16 13:16 UTC (permalink / raw)
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
In-Reply-To: <4D5BCC74.9010301-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
Hi again,
I forget to cc linux-nfs mailing list.
Michal
P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
Michal Simek wrote:
> Hi All,
>
> I am trying to understand one problem which we have found.
> The problem is that I can't on Microblaze little-endian platform
> mount nfs without -o nolock options. (Log below)
> Selecting tcp or udp has no effect.
> I am using emaclite driver and there is no problem on big endian
> microblaze.
>
> ping, telnet, http, ftp, iperf, netperf work well.
>
> That's why I have a question if there is any endian specific option for
> NFS?
>
> Thanks,
> Michal
>
> ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
> svc: failed to register lockdv1 RPC service (errno 13).
> lockd_up: makesock failed, error=-13
> svc: failed to register lockdv1 RPC service (errno 13).
> ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
> ~ # mount
> rootfs on / type rootfs (rw)
> proc on /proc type proc (rw,relatime)
> none on /var type ramfs (rw,relatime)
> none on /sys type sysfs (rw,relatime)
> none on /etc/config type ramfs (rw,relatime)
> none on /dev/pts type devpts (rw,relatime,mode=600)
> 192.168.0.101:/tftpboot/nfs on /mnt type nfs
> (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
>
> ~ #
> ~ # ps
> PID USER TIME COMMAND
> 1 root 0:02 init
> 2 root 0:00 [kthreadd]
> 3 root 0:00 [ksoftirqd/0]
> 4 root 0:00 [kworker/0:0]
> 5 root 0:00 [kworker/u:0]
> 6 root 0:00 [khelper]
> 7 root 0:00 [sync_supers]
> 8 root 0:00 [bdi-default]
> 9 root 0:00 [kblockd]
> 10 root 0:00 [rpciod]
> 11 root 0:00 [kworker/0:1]
> 12 root 0:00 [kswapd0]
> 13 root 0:00 [fsnotify_mark]
> 14 root 0:00 [aio]
> 15 root 0:00 [nfsiod]
> 16 root 0:00 [kworker/u:1]
> 58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
> 62 1 0:00 /bin/portmap
> 64 root 0:00 /bin/inetd /etc/inetd.conf
> 65 root 0:01 -sh
> 66 root 0:00 /bin/syslogd -n
> 67 root 0:00 /bin/flatfsd
> 68 root 0:00 [kworker/0:2]
> 91 root 0:00 ps
> ~ # cat /proc/cpuinfo
> CPU-Family: MicroBlaze
> FPGA-Arch: spartan6
> CPU-Ver: 8.00.a, little endian
> CPU-MHz: 50.00
> BogoMips: 24.06
> HW:
> Shift: yes
> MSR: yes
> PCMP: yes
> DIV: yes
> MMU: 3
> MUL: v2
> FPU: no
> Exc: op0x0 unal ill iopb dopb zero
> Icache: 16kB line length: 32B
> Dcache: 16kB line length: 16B
> write-through
> HW-Debug: yes
> PVR-USR1: 00
> PVR-USR2: 00000000
> Page size: 4096
> ~ #
>
>
>
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next-2.6 1/4] rtnetlink: implement setting of master device
From: Stephen Hemminger @ 2011-02-16 13:18 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian
In-Reply-To: <20110213193105.GD2740@psychotron.redhat.com>
On Sun, 13 Feb 2011 20:31:06 +0100
Jiri Pirko <jpirko@redhat.com> wrote:
> This patch allows userspace to enslave/release slave devices via netlink
> interface using IFLA_MASTER. This introduces generic way to add/remove
> underling devices.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
But, setting master means something different for each type of device?
What happens if you move eth0 from br0 to bond0?
The name "master" is only used in the bonding spec. It is not used in
description of bridges in the 802.1 spec. There are also some companies
that have very "politically correct" HR departments that think that any
reference to master or slave is racist.
^ permalink raw reply
* Re: [GIT PULL nf-next-2.6] IPVS
From: Patrick McHardy @ 2011-02-16 13:19 UTC (permalink / raw)
To: Simon Horman
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Julian Anastasov,
Patrick Schaaf
In-Reply-To: <1297836293-5942-1-git-send-email-horms@verge.net.au>
On 16.02.2011 07:04, Simon Horman wrote:
> Hi Patrick,
>
> please consider pulling
> git://git.kernel.org/pub/scm/linux/kernel/git/horms/lvs-test-2.6.git master
> go get:
>
> * Removal of unused ICMP code by Julian
> * More informative "no destination available" messages
> by Patrick Schaaf
> * Fix to buffering of synchronisation messages
> by Tinggong Wang and Julian
>
Pulled, thanks Simon.
^ permalink raw reply
* Re: [patch net-next-2.6 4/4] bridge: implement [add/del]_slave ops
From: Stephen Hemminger @ 2011-02-16 13:21 UTC (permalink / raw)
To: David Miller
Cc: jpirko, netdev, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian
In-Reply-To: <20110213.165903.184824754.davem@davemloft.net>
On Sun, 13 Feb 2011 16:59:03 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Jiri Pirko <jpirko@redhat.com>
> Date: Sun, 13 Feb 2011 20:33:42 +0100
>
> > add possibility to addif/delif via rtnetlink
> >
> > Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
> Applied.
You should follow established protocol and wait until I have
had time to review code that impacts areas which I maintain.
The linux-foundation email address is not listed in MAINTAINERS
file and is mainly a spam catcher that I never read.
Maybe I should just start sending networking patches to Linus.
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: Patrick McHardy @ 2011-02-16 13:22 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: Phil Karn, netdev
In-Reply-To: <AANLkTinBOk8ZNQvRpMqZQE_vOu63QVzDZ4ceRRUDvJD_@mail.gmail.com>
On 16.02.2011 13:51, richard -rw- weinberger wrote:
> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>> The range check on vlan_id in register_vlan_device is off by one, and it
>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>> this, I checked.)
>
> Then OSX should fix their code. 4095 is reserved.
I agree.
^ permalink raw reply
* Re: NFS on little-endian platform - Microblaze
From: Trond Myklebust @ 2011-02-16 13:22 UTC (permalink / raw)
To: monstr; +Cc: netdev, David Miller, linux-nfs
In-Reply-To: <4D5BCE43.1090401@monstr.eu>
On Wed, 2011-02-16 at 14:16 +0100, Michal Simek wrote:
> Hi again,
>
> I forget to cc linux-nfs mailing list.
>
> Michal
>
> P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
>
> Michal Simek wrote:
> > Hi All,
> >
> > I am trying to understand one problem which we have found.
> > The problem is that I can't on Microblaze little-endian platform
> > mount nfs without -o nolock options. (Log below)
> > Selecting tcp or udp has no effect.
> > I am using emaclite driver and there is no problem on big endian
> > microblaze.
> >
> > ping, telnet, http, ftp, iperf, netperf work well.
> >
> > That's why I have a question if there is any endian specific option for
> > NFS?
> >
> > Thanks,
> > Michal
> >
> > ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
> > svc: failed to register lockdv1 RPC service (errno 13).
> > lockd_up: makesock failed, error=-13
> > svc: failed to register lockdv1 RPC service (errno 13).
> > ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
> > ~ # mount
> > rootfs on / type rootfs (rw)
> > proc on /proc type proc (rw,relatime)
> > none on /var type ramfs (rw,relatime)
> > none on /sys type sysfs (rw,relatime)
> > none on /etc/config type ramfs (rw,relatime)
> > none on /dev/pts type devpts (rw,relatime,mode=600)
> > 192.168.0.101:/tftpboot/nfs on /mnt type nfs
> > (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
> >
> > ~ #
> > ~ # ps
> > PID USER TIME COMMAND
> > 1 root 0:02 init
> > 2 root 0:00 [kthreadd]
> > 3 root 0:00 [ksoftirqd/0]
> > 4 root 0:00 [kworker/0:0]
> > 5 root 0:00 [kworker/u:0]
> > 6 root 0:00 [khelper]
> > 7 root 0:00 [sync_supers]
> > 8 root 0:00 [bdi-default]
> > 9 root 0:00 [kblockd]
> > 10 root 0:00 [rpciod]
> > 11 root 0:00 [kworker/0:1]
> > 12 root 0:00 [kswapd0]
> > 13 root 0:00 [fsnotify_mark]
> > 14 root 0:00 [aio]
> > 15 root 0:00 [nfsiod]
> > 16 root 0:00 [kworker/u:1]
> > 58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
> > 62 1 0:00 /bin/portmap
> > 64 root 0:00 /bin/inetd /etc/inetd.conf
> > 65 root 0:01 -sh
> > 66 root 0:00 /bin/syslogd -n
> > 67 root 0:00 /bin/flatfsd
> > 68 root 0:00 [kworker/0:2]
> > 91 root 0:00 ps
Where is rpc.statd? Without it, the above behaviour is 100% expected.
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* [PATCH] sfc: lower stack usage in efx_ethtool_self_test
From: Eric Dumazet @ 2011-02-16 13:48 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1297800733.2584.15.camel@bwh-desktop>
drivers/net/sfc/ethtool.c: In function ‘efx_ethtool_self_test’:
drivers/net/sfc/ethtool.c:613: warning: the frame size of 1200 bytes
is larger than 1024 bytes
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/sfc/ethtool.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/sfc/ethtool.c b/drivers/net/sfc/ethtool.c
index 272cfe7..0836b37 100644
--- a/drivers/net/sfc/ethtool.c
+++ b/drivers/net/sfc/ethtool.c
@@ -569,9 +569,14 @@ static void efx_ethtool_self_test(struct net_device *net_dev,
struct ethtool_test *test, u64 *data)
{
struct efx_nic *efx = netdev_priv(net_dev);
- struct efx_self_tests efx_tests;
+ struct efx_self_tests *efx_tests;
int already_up;
- int rc;
+ int rc = -ENOMEM;
+
+ efx_tests = kzalloc(sizeof(*efx_tests), GFP_KERNEL);
+ if (!efx_tests)
+ goto fail;
+
ASSERT_RTNL();
if (efx->state != STATE_RUNNING) {
@@ -589,13 +594,11 @@ static void efx_ethtool_self_test(struct net_device *net_dev,
if (rc) {
netif_err(efx, drv, efx->net_dev,
"failed opening device.\n");
- goto fail2;
+ goto fail1;
}
}
- memset(&efx_tests, 0, sizeof(efx_tests));
-
- rc = efx_selftest(efx, &efx_tests, test->flags);
+ rc = efx_selftest(efx, efx_tests, test->flags);
if (!already_up)
dev_close(efx->net_dev);
@@ -604,10 +607,11 @@ static void efx_ethtool_self_test(struct net_device *net_dev,
rc == 0 ? "passed" : "failed",
(test->flags & ETH_TEST_FL_OFFLINE) ? "off" : "on");
- fail2:
- fail1:
+fail1:
/* Fill ethtool results structures */
- efx_ethtool_fill_self_tests(efx, &efx_tests, NULL, data);
+ efx_ethtool_fill_self_tests(efx, efx_tests, NULL, data);
+ kfree(efx_tests);
+fail:
if (rc)
test->flags |= ETH_TEST_FL_FAILED;
}
^ permalink raw reply related
* Re: NFS on little-endian platform - Microblaze
From: Michal Simek @ 2011-02-16 13:53 UTC (permalink / raw)
To: Trond Myklebust
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1297862575.6596.0.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
Trond Myklebust wrote:
> On Wed, 2011-02-16 at 14:16 +0100, Michal Simek wrote:
>> Hi again,
>>
>> I forget to cc linux-nfs mailing list.
>>
>> Michal
>>
>> P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
>>
>> Michal Simek wrote:
>>> Hi All,
>>>
>>> I am trying to understand one problem which we have found.
>>> The problem is that I can't on Microblaze little-endian platform
>>> mount nfs without -o nolock options. (Log below)
>>> Selecting tcp or udp has no effect.
>>> I am using emaclite driver and there is no problem on big endian
>>> microblaze.
>>>
>>> ping, telnet, http, ftp, iperf, netperf work well.
>>>
>>> That's why I have a question if there is any endian specific option for
>>> NFS?
>>>
>>> Thanks,
>>> Michal
>>>
>>> ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
>>> svc: failed to register lockdv1 RPC service (errno 13).
>>> lockd_up: makesock failed, error=-13
>>> svc: failed to register lockdv1 RPC service (errno 13).
>>> ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
>>> ~ # mount
>>> rootfs on / type rootfs (rw)
>>> proc on /proc type proc (rw,relatime)
>>> none on /var type ramfs (rw,relatime)
>>> none on /sys type sysfs (rw,relatime)
>>> none on /etc/config type ramfs (rw,relatime)
>>> none on /dev/pts type devpts (rw,relatime,mode=600)
>>> 192.168.0.101:/tftpboot/nfs on /mnt type nfs
>>> (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
>>>
>>> ~ #
>>> ~ # ps
>>> PID USER TIME COMMAND
>>> 1 root 0:02 init
>>> 2 root 0:00 [kthreadd]
>>> 3 root 0:00 [ksoftirqd/0]
>>> 4 root 0:00 [kworker/0:0]
>>> 5 root 0:00 [kworker/u:0]
>>> 6 root 0:00 [khelper]
>>> 7 root 0:00 [sync_supers]
>>> 8 root 0:00 [bdi-default]
>>> 9 root 0:00 [kblockd]
>>> 10 root 0:00 [rpciod]
>>> 11 root 0:00 [kworker/0:1]
>>> 12 root 0:00 [kswapd0]
>>> 13 root 0:00 [fsnotify_mark]
>>> 14 root 0:00 [aio]
>>> 15 root 0:00 [nfsiod]
>>> 16 root 0:00 [kworker/u:1]
>>> 58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
>>> 62 1 0:00 /bin/portmap
>>> 64 root 0:00 /bin/inetd /etc/inetd.conf
>>> 65 root 0:01 -sh
>>> 66 root 0:00 /bin/syslogd -n
>>> 67 root 0:00 /bin/flatfsd
>>> 68 root 0:00 [kworker/0:2]
>>> 91 root 0:00 ps
>
> Where is rpc.statd? Without it, the above behaviour is 100% expected.
I see on BE that lockd is used but it is enabled on little endian too but hasn't started.
Enabled options:
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
On Be lockd is up.
69 root 0:00 /bin/flatfsd
71 root 0:00 [lockd]
73 root 0:00 ps
I have to look why.
How is it started?
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: NFS on little-endian platform - Microblaze
From: Trond Myklebust @ 2011-02-16 14:04 UTC (permalink / raw)
To: monstr; +Cc: netdev, David Miller, linux-nfs
In-Reply-To: <4D5BD6E5.8010903@monstr.eu>
On Wed, 2011-02-16 at 14:53 +0100, Michal Simek wrote:
> Trond Myklebust wrote:
> > On Wed, 2011-02-16 at 14:16 +0100, Michal Simek wrote:
> >> Hi again,
> >>
> >> I forget to cc linux-nfs mailing list.
> >>
> >> Michal
> >>
> >> P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
> >>
> >> Michal Simek wrote:
> >>> Hi All,
> >>>
> >>> I am trying to understand one problem which we have found.
> >>> The problem is that I can't on Microblaze little-endian platform
> >>> mount nfs without -o nolock options. (Log below)
> >>> Selecting tcp or udp has no effect.
> >>> I am using emaclite driver and there is no problem on big endian
> >>> microblaze.
> >>>
> >>> ping, telnet, http, ftp, iperf, netperf work well.
> >>>
> >>> That's why I have a question if there is any endian specific option for
> >>> NFS?
> >>>
> >>> Thanks,
> >>> Michal
> >>>
> >>> ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
> >>> svc: failed to register lockdv1 RPC service (errno 13).
> >>> lockd_up: makesock failed, error=-13
> >>> svc: failed to register lockdv1 RPC service (errno 13).
> >>> ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
> >>> ~ # mount
> >>> rootfs on / type rootfs (rw)
> >>> proc on /proc type proc (rw,relatime)
> >>> none on /var type ramfs (rw,relatime)
> >>> none on /sys type sysfs (rw,relatime)
> >>> none on /etc/config type ramfs (rw,relatime)
> >>> none on /dev/pts type devpts (rw,relatime,mode=600)
> >>> 192.168.0.101:/tftpboot/nfs on /mnt type nfs
> >>> (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
> >>>
> >>> ~ #
> >>> ~ # ps
> >>> PID USER TIME COMMAND
> >>> 1 root 0:02 init
> >>> 2 root 0:00 [kthreadd]
> >>> 3 root 0:00 [ksoftirqd/0]
> >>> 4 root 0:00 [kworker/0:0]
> >>> 5 root 0:00 [kworker/u:0]
> >>> 6 root 0:00 [khelper]
> >>> 7 root 0:00 [sync_supers]
> >>> 8 root 0:00 [bdi-default]
> >>> 9 root 0:00 [kblockd]
> >>> 10 root 0:00 [rpciod]
> >>> 11 root 0:00 [kworker/0:1]
> >>> 12 root 0:00 [kswapd0]
> >>> 13 root 0:00 [fsnotify_mark]
> >>> 14 root 0:00 [aio]
> >>> 15 root 0:00 [nfsiod]
> >>> 16 root 0:00 [kworker/u:1]
> >>> 58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
> >>> 62 1 0:00 /bin/portmap
> >>> 64 root 0:00 /bin/inetd /etc/inetd.conf
> >>> 65 root 0:01 -sh
> >>> 66 root 0:00 /bin/syslogd -n
> >>> 67 root 0:00 /bin/flatfsd
> >>> 68 root 0:00 [kworker/0:2]
> >>> 91 root 0:00 ps
> >
> > Where is rpc.statd? Without it, the above behaviour is 100% expected.
>
> I see on BE that lockd is used but it is enabled on little endian too but hasn't started.
>
> Enabled options:
> CONFIG_NETWORK_FILESYSTEMS=y
> CONFIG_NFS_FS=y
> CONFIG_NFS_V3=y
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_NFS_COMMON=y
> CONFIG_SUNRPC=y
>
> On Be lockd is up.
> 69 root 0:00 /bin/flatfsd
> 71 root 0:00 [lockd]
> 73 root 0:00 ps
>
> I have to look why.
> How is it started?
Either rpc.bind or rpc.portmap and then rpc.statd need to be started
manually (in that order) before you may mount the NFS partition without
'-onolock'. The lockd daemon itself will be started by the kernel
whenever there is a need for it.
Please check your 'init' boot scripts to find out why they are not being
started as expected.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: NFS on little-endian platform - Microblaze
From: Michal Simek @ 2011-02-16 14:16 UTC (permalink / raw)
To: Trond Myklebust
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1297865074.6596.10.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
Trond Myklebust wrote:
> On Wed, 2011-02-16 at 14:53 +0100, Michal Simek wrote:
>> Trond Myklebust wrote:
>>> On Wed, 2011-02-16 at 14:16 +0100, Michal Simek wrote:
>>>> Hi again,
>>>>
>>>> I forget to cc linux-nfs mailing list.
>>>>
>>>> Michal
>>>>
>>>> P.S.: Tested on kernels 2.6.38-rc4, 2.6.37 and 2.6.36
>>>>
>>>> Michal Simek wrote:
>>>>> Hi All,
>>>>>
>>>>> I am trying to understand one problem which we have found.
>>>>> The problem is that I can't on Microblaze little-endian platform
>>>>> mount nfs without -o nolock options. (Log below)
>>>>> Selecting tcp or udp has no effect.
>>>>> I am using emaclite driver and there is no problem on big endian
>>>>> microblaze.
>>>>>
>>>>> ping, telnet, http, ftp, iperf, netperf work well.
>>>>>
>>>>> That's why I have a question if there is any endian specific option for
>>>>> NFS?
>>>>>
>>>>> Thanks,
>>>>> Michal
>>>>>
>>>>> ~ # mount -t nfs 192.168.0.101:/tftpboot/nfs /mnt
>>>>> svc: failed to register lockdv1 RPC service (errno 13).
>>>>> lockd_up: makesock failed, error=-13
>>>>> svc: failed to register lockdv1 RPC service (errno 13).
>>>>> ~ # mount -t nfs -o nolock 192.168.0.101:/tftpboot/nfs /mnt
>>>>> ~ # mount
>>>>> rootfs on / type rootfs (rw)
>>>>> proc on /proc type proc (rw,relatime)
>>>>> none on /var type ramfs (rw,relatime)
>>>>> none on /sys type sysfs (rw,relatime)
>>>>> none on /etc/config type ramfs (rw,relatime)
>>>>> none on /dev/pts type devpts (rw,relatime,mode=600)
>>>>> 192.168.0.101:/tftpboot/nfs on /mnt type nfs
>>>>> (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,local_lock=all,addr=192.168.0.101)
>>>>>
>>>>> ~ #
>>>>> ~ # ps
>>>>> PID USER TIME COMMAND
>>>>> 1 root 0:02 init
>>>>> 2 root 0:00 [kthreadd]
>>>>> 3 root 0:00 [ksoftirqd/0]
>>>>> 4 root 0:00 [kworker/0:0]
>>>>> 5 root 0:00 [kworker/u:0]
>>>>> 6 root 0:00 [khelper]
>>>>> 7 root 0:00 [sync_supers]
>>>>> 8 root 0:00 [bdi-default]
>>>>> 9 root 0:00 [kblockd]
>>>>> 10 root 0:00 [rpciod]
>>>>> 11 root 0:00 [kworker/0:1]
>>>>> 12 root 0:00 [kswapd0]
>>>>> 13 root 0:00 [fsnotify_mark]
>>>>> 14 root 0:00 [aio]
>>>>> 15 root 0:00 [nfsiod]
>>>>> 16 root 0:00 [kworker/u:1]
>>>>> 58 root 0:00 udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
>>>>> 62 1 0:00 /bin/portmap
>>>>> 64 root 0:00 /bin/inetd /etc/inetd.conf
>>>>> 65 root 0:01 -sh
>>>>> 66 root 0:00 /bin/syslogd -n
>>>>> 67 root 0:00 /bin/flatfsd
>>>>> 68 root 0:00 [kworker/0:2]
>>>>> 91 root 0:00 ps
>>> Where is rpc.statd? Without it, the above behaviour is 100% expected.
>> I see on BE that lockd is used but it is enabled on little endian too but hasn't started.
>>
>> Enabled options:
>> CONFIG_NETWORK_FILESYSTEMS=y
>> CONFIG_NFS_FS=y
>> CONFIG_NFS_V3=y
>> CONFIG_LOCKD=y
>> CONFIG_LOCKD_V4=y
>> CONFIG_NFS_COMMON=y
>> CONFIG_SUNRPC=y
>>
>> On Be lockd is up.
>> 69 root 0:00 /bin/flatfsd
>> 71 root 0:00 [lockd]
>> 73 root 0:00 ps
>>
>> I have to look why.
>> How is it started?
>
> Either rpc.bind or rpc.portmap and then rpc.statd need to be started
> manually (in that order) before you may mount the NFS partition without
> '-onolock'. The lockd daemon itself will be started by the kernel
> whenever there is a need for it.
On big-endian system is not any rpc* binary either that's why I think this is not a problem.
Only portmap is started on both systems. Nothing more. If you want I can send you cpio archive.
>
> Please check your 'init' boot scripts to find out why they are not being
> started as expected.
ok.
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next-2.6 1/4] rtnetlink: implement setting of master device
From: Jiri Pirko @ 2011-02-16 14:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet,
nicolas.2p.debian
In-Reply-To: <20110216051844.53f577d5@s6510>
Wed, Feb 16, 2011 at 02:18:44PM CET, shemminger@vyatta.com wrote:
>On Sun, 13 Feb 2011 20:31:06 +0100
>Jiri Pirko <jpirko@redhat.com> wrote:
>
>> This patch allows userspace to enslave/release slave devices via netlink
>> interface using IFLA_MASTER. This introduces generic way to add/remove
>> underling devices.
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>
>But, setting master means something different for each type of device?
Why isn't correct to use master also for bridge? It had no meaning there.
>What happens if you move eth0 from br0 to bond0?
you mean by:
ip link set eth0 master br0
ip link set eth0 master bond0
It's first removed from bridge, then added into bond. No problem here.
>
>The name "master" is only used in the bonding spec. It is not used in
>description of bridges in the 802.1 spec. There are also some companies
>that have very "politically correct" HR departments that think that any
>reference to master or slave is racist.
>
>
^ permalink raw reply
* Re: [patch net-next-2.6 1/4] rtnetlink: implement setting of master device
From: Patrick McHardy @ 2011-02-16 15:25 UTC (permalink / raw)
To: Jiri Pirko
Cc: Stephen Hemminger, netdev, davem, shemminger, fubar, eric.dumazet,
nicolas.2p.debian
In-Reply-To: <20110216143923.GB5727@psychotron.brq.redhat.com>
On 16.02.2011 15:39, Jiri Pirko wrote:
> Wed, Feb 16, 2011 at 02:18:44PM CET, shemminger@vyatta.com wrote:
>> On Sun, 13 Feb 2011 20:31:06 +0100
>> Jiri Pirko <jpirko@redhat.com> wrote:
>>
>>> This patch allows userspace to enslave/release slave devices via netlink
>>> interface using IFLA_MASTER. This introduces generic way to add/remove
>>> underling devices.
>>>
>>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>>
>> But, setting master means something different for each type of device?
>
> Why isn't correct to use master also for bridge? It had no meaning there.
In fact the bridge netlink family uses IFLA_MASTER for exactly
the same purpose.
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: Phil Karn @ 2011-02-16 15:58 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: kaber, netdev
In-Reply-To: <AANLkTinBOk8ZNQvRpMqZQE_vOu63QVzDZ4ceRRUDvJD_@mail.gmail.com>
On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>> The range check on vlan_id in register_vlan_device is off by one, and it
>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>> this, I checked.)
>
> Then OSX should fix their code. 4095 is reserved.
>
If it's reserved, then it's up to the user to reserve it.
I actually had reason to use this to fix a misconfigured host that was
using vlan 4095. This got in my way.
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: richard -rw- weinberger @ 2011-02-16 16:10 UTC (permalink / raw)
To: Phil Karn; +Cc: kaber, netdev
In-Reply-To: <4D5BF411.4020204@ka9q.net>
On Wed, Feb 16, 2011 at 4:58 PM, Phil Karn <karn@ka9q.net> wrote:
> On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
>> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>>> The range check on vlan_id in register_vlan_device is off by one, and it
>>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>>> this, I checked.)
>>
>> Then OSX should fix their code. 4095 is reserved.
>>
>
> If it's reserved, then it's up to the user to reserve it.
No.
See:
http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
--
Thanks,
//richard
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: Phil Karn @ 2011-02-16 16:28 UTC (permalink / raw)
To: richard -rw- weinberger; +Cc: kaber, netdev
In-Reply-To: <AANLkTikNrwd31RBj1gc6kSaT=qodS=A=YntM=72PMbDf@mail.gmail.com>
On 2/16/11 8:10 AM, richard -rw- weinberger wrote:
> On Wed, Feb 16, 2011 at 4:58 PM, Phil Karn <karn@ka9q.net> wrote:
>> On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
>>> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>>>> The range check on vlan_id in register_vlan_device is off by one, and it
>>>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>>>> this, I checked.)
>>>
>>> Then OSX should fix their code. 4095 is reserved.
>>>
>>
>> If it's reserved, then it's up to the user to reserve it.
>
> No.
>
> See:
> http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
>
Well, then I guess we all know better than the user. That's the Windows
Way...no, wait, I thought this is Linux.
The fact is that I did encounter a misconfigured switch using vlan 4095,
and because of this off-by-one error I was unable to talk to it and fix it.
I was hoping I wouldn't have to patch every new kernel I install.
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: richard -rw- weinberger @ 2011-02-16 16:35 UTC (permalink / raw)
To: Phil Karn; +Cc: kaber, netdev
In-Reply-To: <4D5BFB39.8070805@ka9q.net>
On Wed, Feb 16, 2011 at 5:28 PM, Phil Karn <karn@ka9q.net> wrote:
> On 2/16/11 8:10 AM, richard -rw- weinberger wrote:
>> On Wed, Feb 16, 2011 at 4:58 PM, Phil Karn <karn@ka9q.net> wrote:
>>> On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
>>>> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>>>>> The range check on vlan_id in register_vlan_device is off by one, and it
>>>>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>>>>> this, I checked.)
>>>>
>>>> Then OSX should fix their code. 4095 is reserved.
>>>>
>>>
>>> If it's reserved, then it's up to the user to reserve it.
>>
>> No.
>>
>> See:
>> http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
>>
>
> Well, then I guess we all know better than the user. That's the Windows
> Way...no, wait, I thought this is Linux.
>
> The fact is that I did encounter a misconfigured switch using vlan 4095,
> and because of this off-by-one error I was unable to talk to it and fix it.
>
> I was hoping I wouldn't have to patch every new kernel I install.
>
The switch violates the standard. Why should Linux also do so?
This would only produce more broken VLANs...
--
Thanks,
//richard
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: Eric Dumazet @ 2011-02-16 16:39 UTC (permalink / raw)
To: Phil Karn; +Cc: richard -rw- weinberger, kaber, netdev
In-Reply-To: <4D5BFB39.8070805@ka9q.net>
Le mercredi 16 février 2011 à 08:28 -0800, Phil Karn a écrit :
> On 2/16/11 8:10 AM, richard -rw- weinberger wrote:
> > On Wed, Feb 16, 2011 at 4:58 PM, Phil Karn <karn@ka9q.net> wrote:
> >> On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
> >>> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
> >>>> The range check on vlan_id in register_vlan_device is off by one, and it
> >>>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
> >>>> this, I checked.)
> >>>
> >>> Then OSX should fix their code. 4095 is reserved.
> >>>
> >>
> >> If it's reserved, then it's up to the user to reserve it.
> >
> > No.
> >
> > See:
> > http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
> >
>
> Well, then I guess we all know better than the user. That's the Windows
> Way...no, wait, I thought this is Linux.
>
> The fact is that I did encounter a misconfigured switch using vlan 4095,
> and because of this off-by-one error I was unable to talk to it and fix it.
>
> I was hoping I wouldn't have to patch every new kernel I install.
>
You can use an OSX gateway ;)
If we allow ID 4095, then some users will complain we violate rules.
Really you cannot push this patch in official kernel only to ease your
life ;)
^ permalink raw reply
* RE: Process for subsystem maintainers to get Hyper-V code out of staging. - CORRECTED RECIPIENTS
From: Hank Janssen @ 2011-02-16 17:43 UTC (permalink / raw)
To: Robert Hancock
Cc: shemminger@linux-foundation.org, netdev@vger.kernel.org,
davem@davemloft.net, ide, KY Srinivasan, Hashir Abdi,
Mike Sterling, Haiyang Zhang, gregkh@suse.de" "
In-Reply-To: <4D59CCAD.90503@gmail.com>
> From: Robert Hancock [mailto:hancockrwd@gmail.com]
> Sent: Monday, February 14, 2011 4:46 PM
> On 02/14/2011 05:42 PM, Hank Janssen wrote:
> >
> > MY APOLOGIES-I made a typo on James email address. I corrected it and
> resend.
> > Sorry for the double email.
> >
> >
> > Stephen/James/David,
> >
> > Greetings to you all. As you might be aware, we submitted Hyper-V
> drivers to the kernel 2009.
> > We have been extending these drivers with additional functionality
> and our primary focus now
> > is doing the work needed to exit the staging area.
> >
> > To give you some background, the following are Hyper-V specific Linux
> drivers:
> >
> > hv_vmbus The vmbus driver that is the
> bridge between guest and the
> > host
> > hv_storvsc The SCSI device driver
> > hv_blkvsc The IDE driver
>
> Given that the IDE subsystem (drivers/ide) is currently in
> maintenance-only mode, and isn't used by modern distributions, you
> likely want to make this a libata driver instead.
>
> Though, from what's in current git, it's not clear to me what the HV
> IDE
> (and SCSI) drivers are attempting to do. Is it really something that
> looks like an IDE controller from the guest OS point of view? If not,
> then having it as an IDE driver would be the wrong thing to do, it
> should be more of a generic block driver. In that case, then, why are
> there both SCSI and IDE drivers in the first place?
>
Robert,
Thank you very much for your responses, today Hyper-V host only supports
IDE and SCSI, and the code was initially written against 2.6.9 kernel.
Hyper-V still treats them a separate interface and is designed to emulate
A pretty old BIOS.
What my approach will be is to dig into libsata (something I have not
Much knowledge of) and see if we can use it and find a way to more sanely
Merge the behavior of Hyper-V's IDE and SCSI.
Hank.
^ permalink raw reply
* Re: [RFC !!BONUS!! PATCH 6/5] ipv4: Delete routing cache.
From: David Miller @ 2011-02-16 18:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1297842977.3201.7.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Feb 2011 08:56:17 +0100
> Le mardi 15 février 2011 à 18:55 -0800, David Miller a écrit :
>> From: David Miller <davem@davemloft.net>
>> Date: Wed, 09 Feb 2011 22:39:39 -0800 (PST)
>>
>> >
>> > Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> Ok, this patch had one nasty bug:
>>
>> > + if (!err == 0)
>>
>> Yeah... right.
>>
>> I'm actively testing this version at the moment, against net-next-2.6,
>> works fine thus far.
>>
>> --------------------
>> ipv4: Delete routing cache.
>>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>> ---
>
> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> I suspect we can zap DST_NOCACHE later ?
Yes, the number of cleanups we can do after this patch is actually
quite large.
^ permalink raw reply
* Re: Off-by-one error in net/8021q/vlan.c
From: Michał Mirosław @ 2011-02-16 18:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Phil Karn, richard -rw- weinberger, kaber, netdev
In-Reply-To: <1297874372.30541.29.camel@edumazet-laptop>
2011/2/16 Eric Dumazet <eric.dumazet@gmail.com>:
> Le mercredi 16 février 2011 à 08:28 -0800, Phil Karn a écrit :
>> On 2/16/11 8:10 AM, richard -rw- weinberger wrote:
>> > On Wed, Feb 16, 2011 at 4:58 PM, Phil Karn <karn@ka9q.net> wrote:
>> >> On 2/16/11 4:51 AM, richard -rw- weinberger wrote:
>> >>> On Wed, Feb 16, 2011 at 11:58 AM, Phil Karn <karn@ka9q.net> wrote:
>> >>>> The range check on vlan_id in register_vlan_device is off by one, and it
>> >>>> prevents the creation of a vlan interface for vlan ID 4095. (OSX allows
>> >>>> this, I checked.)
>> >>>
>> >>> Then OSX should fix their code. 4095 is reserved.
>> >> If it's reserved, then it's up to the user to reserve it.
>> > No.
>> > See:
>> > http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf
>> Well, then I guess we all know better than the user. That's the Windows
>> Way...no, wait, I thought this is Linux.
>>
>> The fact is that I did encounter a misconfigured switch using vlan 4095,
>> and because of this off-by-one error I was unable to talk to it and fix it.
>>
>> I was hoping I wouldn't have to patch every new kernel I install.
> You can use an OSX gateway ;)
>
> If we allow ID 4095, then some users will complain we violate rules.
>
> Really you cannot push this patch in official kernel only to ease your
> life ;)
The idea is that you don't have to use ID 4095 and if you don't -
nothing's broken by just allowing it. The same goes with ID 0 - it's
defined to be 802.1p packet, but people do use it as normal VLAN
(especially with hardware that can cope with only small number of
VLANs at once).
Allowing it but with a big fat warning in logs is even better: "You
want your network broken? Sure, can do, but you have been warned."
Best Regards,
Michał Mirosław
^ 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