* [PATCH net-next] ip_gre: fix a possible crash in parse_gre_header()
From: Eric Dumazet @ 2013-04-05 1:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Pravin B Shelar
From: Eric Dumazet <edumazet@google.com>
pskb_may_pull() can change skb->head, so we must init iph/greh after
calling it.
Bug added in commit c54419321455 (GRE: Refactor GRE tunneling code.)
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
---
net/ipv4/ip_gre.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index e5dfd28..987a4e5 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -159,14 +159,14 @@ static int ip_gre_calc_hlen(__be16 o_flags)
static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
bool *csum_err, int *hdr_len)
{
- struct iphdr *iph = ip_hdr(skb);
- struct gre_base_hdr *greh;
+ unsigned int ip_hlen = ip_hdrlen(skb);
+ const struct gre_base_hdr *greh;
__be32 *options;
if (unlikely(!pskb_may_pull(skb, sizeof(struct gre_base_hdr))))
return -EINVAL;
- greh = (struct gre_base_hdr *)((u8 *)iph + (iph->ihl << 2));
+ greh = (struct gre_base_hdr *)(skb_network_header(skb) + ip_hlen);
if (unlikely(greh->flags & (GRE_VERSION | GRE_ROUTING)))
return -EINVAL;
@@ -176,6 +176,8 @@ static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
if (!pskb_may_pull(skb, *hdr_len))
return -EINVAL;
+ greh = (struct gre_base_hdr *)(skb_network_header(skb) + ip_hlen);
+
tpi->proto = greh->protocol;
options = (__be32 *)(greh + 1);
^ permalink raw reply related
* Re: Fw: [Bug 56221] New: bonding: ARP monitoring doesn't work with bridges
From: Jay Vosburgh @ 2013-04-05 2:11 UTC (permalink / raw)
To: Stephen Hemminger, c.ruppert; +Cc: Andy Gospodarek, netdev
In-Reply-To: <20130404094633.052fa5ee@samsung-9>
Stephen Hemminger <stephen@networkplumber.org> wrote:
>Begin forwarded message:
>
>Date: Thu, 4 Apr 2013 06:58:50 -0700
>From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
>To: "stephen@networkplumber.org" <stephen@networkplumber.org>
>Subject: [Bug 56221] New: bonding: ARP monitoring doesn't work with bridges
>
>
>https://bugzilla.kernel.org/show_bug.cgi?id=56221
>
> Summary: bonding: ARP monitoring doesn't work with bridges
> Product: Networking
> Version: 2.5
> Kernel Version: 3.8.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: c.ruppert@babiel.com
> Regression: No
>
>
>Hi,
>
>we tried to setup VLANs and bridges on top of the bonding device.
>
>Creating a bond over eth0 and eth1:
>eth0 \
> --> bond0
>eth1 /
>
>Adding VLANs 1, 2 and 3 on top of the bond:
> --> bond0.1
> /
>bond0 ---> bond0.2
> \
> --> bond0.3
>
>And finally adding bridges on top of the VLAN bonds:
>bond0.1 -> br1
>bond0.2 -> br2
>bond0.3 -> br3
>
>Those three VLANs are all tagged. br1 will also get the default route.
>
>So the ARP monitoring doesn't work as soon as a bridge gets the default route
>(or at least the route to the ARP IP target).
><snip>
>[76655.096076] bonding: bond0: no path to arp_ip_target 172.16.0.1 via rt.dev
>br1
></snip>
>
>I then tried it with just the VLANs (no bridges) and it works fine.
>Then I tried it with just bridges and no VLAN - it doesn't.
>
>Here are some steps to reproduce it:
>ifconfig eth0 0.0.0.0 up
>ifconfig eth1 0.0.0.0 up
>
>modprobe bonding mode="active-backup" primary="eth0" arp_interval=3000
>arp_ip_target="172.16.0.1"
>
>ifconfig bond0 0.0.0.0 up
>ifenslave bond0 eth0
>ifenslave bond0 eth1
>
>brctl addbr br1
>brctl addif br1 bond0
>ifconfig br1 172.16.0.2/28 up
>
>With tcpdump you'll see that there are no ARP requests/pings at all and in
>either dmesg or the kernel log you'll notice the "no path to ..." warnings.
>
>So I took a look into the bonding driver souces (mainly bond_main.c):
>The bonding driver asks for the route to the arp_ip_target which is br1 in this
>case and it then compares it against the bond device(s) so bond0 and/or
>bond0.1, bond0.2 and so forth. So neither bond->dev nor vlan_dev will ever be
>the same as rt->dst.dev as long as you add the route to the bridge.
>There is no check for bridged devices at all.
>The driver should get an event/notify when the device (bond) became a member of
>a bridge or has been removed and so forth, basically the same that has been
>added for the VLAN stuff.
The bonding driver is (in bond_arp_send_all) using the routing
table to try and figure out what VLAN tag (if any) needs to be added to
the ARP it wants to send. This is to handle the case of, e.g.,
for an arp_ip_target of 10.0.0.1,
[ eth0, eth1 ] -> bond0 -> vlan123 { IP=10.0.0.2 }
The case you describe is, however,
[ eth0, eth1 ] -> bond0 -> vlan123 -> bridge { IP=10.0.0.2 }
in this case, with just the arp_ip_target of 10.0.0.1, it can't
find the VLAN because the arp_ip_target would be routed out a different
interface.
It might be feasible to have the bonding code check the upper
dev(s) of the VLAN interface it looks up, but there's no guarantee that
the desired interface is only one layer above the VLAN (or there could
be netsted VLANs, which aren't handled by this bonding code). E.g., in
here:
vlan_id = 0;
list_for_each_entry(vlan, &bond->vlan_list, vlan_list) {
rcu_read_lock();
vlan_dev = __vlan_find_dev_deep(bond->dev,
vlan->vlan_id);
rcu_read_unlock();
if (vlan_dev == rt->dst.dev) {
vlan_id = vlan->vlan_id;
pr_debug("basa: vlan match on %s %d\n",
vlan_dev->name, vlan_id);
break;
}
}
add an else for the if, that's something like
} else {
ndev = netdev_master_upper_dev_get_rcu(vlan_dev);
if (ndev == rt->dst.dev) {
vlan_id = vlan->vlan_id;
vlan_dev = ndev; /* for confirm */
break;
}
}
and probably move the rcu_read_unlock() protection to the end of
the loop (or add another rcu_read block to the new code). This isn't a
proper patch, I'm just kind of typing it out as I think about it before
I have to leave for the evening, so it's not tested or anything but in
principle could work.
I was afraid initially that adding another check would be really
complicated, but this doesn't seem at first glance to be as awful as I
had feared. I could be wrong, though.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [Suggestion] ISDN: isdnloop: C grammar issue, '}' miss match 'if' and 'switch' statement.
From: Joe Perches @ 2013-04-05 3:00 UTC (permalink / raw)
To: David Miller
Cc: gang.chen, torvalds, eric.dumazet, mkubecek, fengguang.wu, isdn,
netdev
In-Reply-To: <20130404.140956.2233513394092413594.davem@davemloft.net>
On Thu, 2013-04-04 at 14:09 -0400, David Miller wrote:
> From: Chen Gang <gang.chen@asianux.com>
> Date: Thu, 04 Apr 2013 16:30:01 +0800
> >> Of course, nobody sane actually cares about ISDN any more, so I think
> >> this is all pretty academic. I think even Germany (where ISDN *used*
> >> to be very common due to telephone monopolies and odd rules) no longer
> >> uses it. I can't imagine that anybody else does either.
> > can we delete it ?
> I think the point is no that we can delete it, but rather that we
> should concentrate our efforts on code that more people use rather
> than trying to clean up antiquated code with very few users.
Very sensible.
I was going to see about moving drivers/isdn/hardware/eicon
to staging but it seems the hardware is still for sale.
http://www.dialogic.com/en/products/media/diva/diva-bri-2.aspx
Anyone have suggestions on other obsolete isdn drivers that
could be moved to staging for awhile before deletion?
^ permalink raw reply
* Re: [PATCH 2/2] at86rf230: change irq handling to prevent lockups with edge type irq
From: Werner Almesberger @ 2013-04-05 3:59 UTC (permalink / raw)
To: Sascha Herrmann
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <57c67195742f5e7482dc57f5a05b6d69156b00d2.1365107512.git.sascha-2k69yqSu1NaELgA04lAiVw@public.gmane.org>
Sascha Herrmann wrote:
> - rc = request_irq(spi->irq, at86rf230_isr, IRQF_SHARED,
> + rc = request_irq(spi->irq, at86rf230_isr,
> + IRQF_SHARED | IRQF_TRIGGER_RISING,
To clarify the purpose of your patch, I think it's only needed
for platforms that don't support level-triggered interrupts.
I.e., if you used IRQF_TRIGGER_HIGH (and happened to have a
platform that supports it, which you said on IRC you don't),
the existing code should work fine. Correct ?
I wonder if it wouldn't be better to make the code work with
both edge and level interrupts instead of having to choose.
E.g., this sort of loop in at86rf230_irqwork should work with
either:
while (1) {
irq = read_and_clear_interrupt();
...
if (!test_and_clear_bit(0, &lp->irq_disabled))
break;
enable_irq();
}
lp->irq_busy = 0; /* allow _xmit */
Disadvantage: you get extra IRQ_STATUS reads, which has a
slight penalty, given that all this is on SPI.
To achieve perfection, at86rf230_probe could try all four
possible trigger modes, pick one the platform supports, and
set TRX_CTRL_1.IRQ_POLARITY accordingly.
In any case, I gave your patch very light testing on ATBEN and
it performed as good as the original code.
- Werner
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
^ permalink raw reply
* Re: [PATCH] lib80211: make lib80211 can be enabled independently
From: Randy Dunlap @ 2013-04-05 4:01 UTC (permalink / raw)
To: Julian Calaby
Cc: Wang YanQing, Johannes Berg, linux-wireless, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <CAGRGNgXj7mSF0Fgyjek4Xcc34N26WHtt4HMmHk7DOopaEPrYFw@mail.gmail.com>
On 04/04/13 16:51, Julian Calaby wrote:
> Hi Wang,
>
> On Fri, Apr 5, 2013 at 3:01 AM, Wang YanQing <udknight@gmail.com> wrote:
>>
>> Current we can only enable lib80211 by enable a driver
>> in tree use it which will select it, but some out tree's
>> drivers also use it, so I think it has sense to make lib80211
>> can be enabled independently.
>
> Just as a bit of explanation for Johannes' NACK:
>
> 1. The only reason lib80211 still exists is because a couple of
> in-tree drivers still use it. If this weren't the case, the code would
> have been removed a long time ago as it's been completely replaced by
> mac80211 and cfg80211. All modern drivers _must_ use mac80211 or
> cfg80211 without exception.
> 2. In general, there is no official in-kernel support for
> out-of-kernel drivers, regardless of quality, status or importance.
> 3. I believe that the in-tree brcmsmac driver already supports the
> Broadcom card you reference.
3b. If 3. is not correct, someone should endeavor to merge this
out-of-tree driver into the kernel tree.
--
~Randy
^ permalink raw reply
* Re: [PATCH] net: count hw_addr syncs so that unsync works properly.
From: David Miller @ 2013-04-05 4:20 UTC (permalink / raw)
To: vyasevic; +Cc: netdev
In-Reply-To: <1364937007-23894-1-git-send-email-vyasevic@redhat.com>
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Tue, 2 Apr 2013 17:10:07 -0400
> A few drivers use dev_uc_sync/unsync to synchronize the
> address lists from master down to slave/lower devices. In
> some cases (bond/team) a single address list is synched down
> to multiple devices. At the time of unsync, we have a leak
> in these lower devices, because "synced" is treated as a
> boolean and the address will not be unsynced for anything after
> the fist device/call.
>
> Treat "synced" as a count (same as refcount) and allow all
> unsync calls to work.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Applied and queued up for -stable, thanks Vlad.
^ permalink raw reply
* Re: [PATCH 1/2] Revert "af_unix: dont send SCM_CREDENTIAL when dest socket is NULL"
From: David Miller @ 2013-04-05 4:47 UTC (permalink / raw)
To: ebiederm
Cc: svenjoac, gregkh, linux-kernel, stable, dingtianhong, edumazet,
luto, ksrot, netdev, eric.dumazet
In-Reply-To: <87li8zhwkw.fsf_-_@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 03 Apr 2013 19:13:35 -0700
>
> This reverts commit 14134f6584212d585b310ce95428014b653dfaf6.
>
> The problem that the above patch was meant to address is that af_unix
> messages are not being coallesced because we are sending unnecesarry
> credentials. Not sending credentials in maybe_add_creds totally
> breaks unconnected unix domain sockets that wish to send credentails
> to other sockets.
>
> In practice this break some versions of udev because they receive a
> message and the sending uid is bogus so they drop the message.
>
> Cc: stable@vger.kernel.org
> Reported-by: Sven Joachim <svenjoac@gmx.de>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] af_unix: If we don't care about credentials coallesce all messages
From: David Miller @ 2013-04-05 4:47 UTC (permalink / raw)
To: ebiederm
Cc: svenjoac, gregkh, linux-kernel, stable, dingtianhong, edumazet,
luto, ksrot, netdev, eric.dumazet
In-Reply-To: <87d2ubhwiw.fsf_-_@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 03 Apr 2013 19:14:47 -0700
>
> It was reported that the following LSB test case failed
> https://lsbbugs.linuxfoundation.org/attachment.cgi?id=2144 because we
> were not coallescing unix stream messages when the application was
> expecting us to.
>
> The problem was that the first send was before the socket was accepted
> and thus sock->sk_socket was NULL in maybe_add_creds, and the second
> send after the socket was accepted had a non-NULL value for sk->socket
> and thus we could tell the credentials were not needed so we did not
> bother.
>
> The unnecessary credentials on the first message cause
> unix_stream_recvmsg to start verifying that all messages had the same
> credentials before coallescing and then the coallescing failed because
> the second message had no credentials.
>
> Ignoring credentials when we don't care in unix_stream_recvmsg fixes a
> long standing pessimization which would fail to coallesce messages when
> reading from a unix stream socket if the senders were different even if
> we did not care about their credentials.
>
> I have tested this and verified that the in the LSB test case mentioned
> above that the messages do coallesce now, while the were failing to
> coallesce without this change.
>
> Reported-by: Karel Srot <ksrot@redhat.com>
> Reported-by: Ding Tianhong <dingtianhong@huawei.com>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/2] scm: Stop passing struct cred
From: David Miller @ 2013-04-05 4:47 UTC (permalink / raw)
To: ebiederm
Cc: svenjoac, gregkh, linux-kernel, dingtianhong, edumazet, luto,
ksrot, netdev, eric.dumazet
In-Reply-To: <87li8zezzj.fsf_-_@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Wed, 03 Apr 2013 20:28:16 -0700
>
> Now that uids and gids are completely encapsulated in kuid_t
> and kgid_t we no longer need to pass struct cred which allowed
> us to test both the uid and the user namespace for equality.
>
> Passing struct cred potentially allows us to pass the entire group
> list as BSD does but I don't believe the cost of cache line misses
> justifies retaining code for a future potential application.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
I'll apply this to net-next once #1 and #2 propagate there.
Thanks!
^ permalink raw reply
* Re: [PATCH net] atl1e: limit gso segment size to prevent generation of wrong ip length fields
From: David Miller @ 2013-04-05 4:49 UTC (permalink / raw)
To: hannes; +Cc: netdev
In-Reply-To: <20130403003646.GJ4924@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Wed, 3 Apr 2013 02:36:46 +0200
> The limit of 0x3c00 is taken from the windows driver.
>
> Suggested-by: Huang, Xiong <xiong@qca.qualcomm.com>
> Cc: Huang, Xiong <xiong@qca.qualcomm.com>
> Cc: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH] bonding: remove sysfs before removing devices
From: David Miller @ 2013-04-05 4:50 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy, nikolay
In-Reply-To: <1365003993-13181-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Wed, 3 Apr 2013 17:46:33 +0200
> We have a race condition if we try to rmmod bonding and simultaneously add
> a bond master through sysfs. In bonding_exit() we first remove the devices
> (through rtnl_link_unregister() ) and only after that we remove the sysfs.
> If we manage to add a device through sysfs after that the devices were
> removed - we'll end up with that device/sysfs structure and with the module
> unloaded.
>
> Fix this by first removing the sysfs and only after that calling
> rtnl_link_unregister().
>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [net] ixgbe: fix registration order of driver and DCA nofitication
From: David Miller @ 2013-04-05 4:50 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jakub.kicinski, netdev, gospo, sassmann, stable
In-Reply-To: <1365043854-8443-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 3 Apr 2013 19:50:54 -0700
> From: Jakub Kicinski <jakub.kicinski@intel.com>
>
> ixgbe_notify_dca cannot be called before driver registration
> because it expects driver's klist_devices to be allocated and
> initialized. While on it make sure debugfs files are removed
> when registration fails.
>
> Cc: stable <stable@vger.kernel.org>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks Jeff.
^ permalink raw reply
* Re: [patch net] net: ipv4: notify when address lifetime changes
From: David Miller @ 2013-04-05 4:51 UTC (permalink / raw)
To: jiri; +Cc: netdev, kuznet, jmorris, yoshfuji, kaber
In-Reply-To: <1365100380-6796-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 4 Apr 2013 20:33:00 +0200
> if userspace changes lifetime of address, send netlink notification and
> call notifier.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Applied and queued up for -stable, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] lib80211: make lib80211 can be enabled independently
From: Wang YanQing @ 2013-04-05 5:45 UTC (permalink / raw)
To: Julian Calaby
Cc: Johannes Berg, linux-wireless, netdev,
linux-kernel@vger.kernel.org, rdunlap
In-Reply-To: <CAGRGNgXj7mSF0Fgyjek4Xcc34N26WHtt4HMmHk7DOopaEPrYFw@mail.gmail.com>
On Fri, Apr 05, 2013 at 10:51:30AM +1100, Julian Calaby wrote:
> Just as a bit of explanation for Johannes' NACK:
>
> 1. The only reason lib80211 still exists is because a couple of
> in-tree drivers still use it. If this weren't the case, the code would
> have been removed a long time ago as it's been completely replaced by
> mac80211 and cfg80211. All modern drivers _must_ use mac80211 or
> cfg80211 without exception.
> 2. In general, there is no official in-kernel support for
> out-of-kernel drivers, regardless of quality, status or importance.
> 3. I believe that the in-tree brcmsmac driver already supports the
> Broadcom card you reference.
Hi Julian.
Thanks for your complete explanation.
I have tried in-tree brcmsmac driver and it works well,
I use it to send out this email! This is wonderful, then
I don't need to fix compilation errors about the old, ugly
and closed wl driver for my notebook with BCM43225 802.11b/g/n
every time I upgrade kernel.
Thanks Julian and all.
^ permalink raw reply
* Re: [Suggestion] ISDN: isdnloop: C grammar issue, '}' miss match 'if' and 'switch' statement.
From: Chen Gang @ 2013-04-05 6:09 UTC (permalink / raw)
To: David Miller
Cc: torvalds, eric.dumazet, mkubecek, fengguang.wu, isdn, netdev, joe
In-Reply-To: <20130404.140956.2233513394092413594.davem@davemloft.net>
On 2013年04月05日 02:09, David Miller wrote:
> From: Chen Gang <gang.chen@asianux.com>
> Date: Thu, 04 Apr 2013 16:30:01 +0800
>
>>> >> Of course, nobody sane actually cares about ISDN any more, so I think
>>> >> this is all pretty academic. I think even Germany (where ISDN *used*
>>> >> to be very common due to telephone monopolies and odd rules) no longer
>>> >> uses it. I can't imagine that anybody else does either.
>>> >>
>> >
>> > can we delete it ?
> I think the point is no that we can delete it, but rather that we
> should concentrate our efforts on code that more people use rather
> than trying to clean up antiquated code with very few users.
>
>
ok, we should respect the opinions of the related maintainers.
although for me:
I still suggest to apply the Linus' patch, if we do not delete ISDN.
next, I will not be still focus on ISDN.
BTW:
the reasons why I am interested in ISDN are:
a: I am trying to improve finding issues ability, by reading code.
b: quite a few of ISDN codes seem quite surprising or strange.
c: when I am reading, I make several mistakes and misunderstanding.
the above 3 are the whole reasons why I am interested in ISDN.
thanks.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [Suggestion] ISDN: isdnloop: C grammar issue, '}' miss match 'if' and 'switch' statement.
From: Chen Gang @ 2013-04-05 6:13 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, torvalds, eric.dumazet, mkubecek, fengguang.wu,
isdn, netdev
In-Reply-To: <1365130824.25884.8.camel@joe-AO722>
On 2013年04月05日 11:00, Joe Perches wrote:
> On Thu, 2013-04-04 at 14:09 -0400, David Miller wrote:
>> > From: Chen Gang <gang.chen@asianux.com>
>> > Date: Thu, 04 Apr 2013 16:30:01 +0800
>>>> > >> Of course, nobody sane actually cares about ISDN any more, so I think
>>>> > >> this is all pretty academic. I think even Germany (where ISDN *used*
>>>> > >> to be very common due to telephone monopolies and odd rules) no longer
>>>> > >> uses it. I can't imagine that anybody else does either.
>>> > > can we delete it ?
>> > I think the point is no that we can delete it, but rather that we
>> > should concentrate our efforts on code that more people use rather
>> > than trying to clean up antiquated code with very few users.
> Very sensible.
>
> I was going to see about moving drivers/isdn/hardware/eicon
> to staging but it seems the hardware is still for sale.
>
> http://www.dialogic.com/en/products/media/diva/diva-bri-2.aspx
>
> Anyone have suggestions on other obsolete isdn drivers that
> could be moved to staging for awhile before deletion?
>
>
>
thank you for your information
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx4_en: Enable open-lldp DCB support
From: Or Gerlitz @ 2013-04-05 7:15 UTC (permalink / raw)
To: John Fastabend
Cc: John Fastabend, Sagi Grimberg, Or Gerlitz, davem, netdev, amirv
In-Reply-To: <515E129D.2020009@gmail.com>
John Fastabend <john.fastabend@gmail.com> wrote:
> Agree it doesn't work without this patch but we can fix it in user
> space. This has the nice benefit of letting lldpad work with mlx4 on
> older kernels. In general I think its easier to update user space then
> the kernel for most users. I'll send you a lldpad patch in a few moments.
So to be sure we're on the same page, what we should do is enhance
mlx4_en_dcbnl_getdcbx() routine to also return DCB_CAP_DCBX_HOST and
work with your user space patch? sounds nice, except for what happens
if people run with older versions of lldpad..
Or.
^ permalink raw reply
* Re: [PATCH] lib80211: make lib80211 can be enabled independently
From: Arend van Spriel @ 2013-04-05 7:23 UTC (permalink / raw)
To: Julian Calaby
Cc: Wang YanQing, Johannes Berg, linux-wireless, netdev,
linux-kernel@vger.kernel.org
In-Reply-To: <CAGRGNgXj7mSF0Fgyjek4Xcc34N26WHtt4HMmHk7DOopaEPrYFw@mail.gmail.com>
On 04/05/2013 01:51 AM, Julian Calaby wrote:
> Hi Wang,
>
> On Fri, Apr 5, 2013 at 3:01 AM, Wang YanQing <udknight@gmail.com> wrote:
>>
>> Current we can only enable lib80211 by enable a driver
>> in tree use it which will select it, but some out tree's
>> drivers also use it, so I think it has sense to make lib80211
>> can be enabled independently.
>
> Just as a bit of explanation for Johannes' NACK:
>
> 3. I believe that the in-tree brcmsmac driver already supports the
> Broadcom card you reference.
That is correct.
Gr. AvS
^ permalink raw reply
* Re: [PATCH] lib80211: make lib80211 can be enabled independently
From: Arend van Spriel @ 2013-04-05 7:25 UTC (permalink / raw)
To: Randy Dunlap
Cc: Julian Calaby, Wang YanQing, Johannes Berg, linux-wireless,
netdev, linux-kernel@vger.kernel.org
In-Reply-To: <515E4CB7.6020405@infradead.org>
On 04/05/2013 06:01 AM, Randy Dunlap wrote:
> On 04/04/13 16:51, Julian Calaby wrote:
>> Hi Wang,
>>
>> On Fri, Apr 5, 2013 at 3:01 AM, Wang YanQing <udknight@gmail.com> wrote:
>>>
>>> Current we can only enable lib80211 by enable a driver
>>> in tree use it which will select it, but some out tree's
>>> drivers also use it, so I think it has sense to make lib80211
>>> can be enabled independently.
>>
>> Just as a bit of explanation for Johannes' NACK:
>>
>> 1. The only reason lib80211 still exists is because a couple of
>> in-tree drivers still use it. If this weren't the case, the code would
>> have been removed a long time ago as it's been completely replaced by
>> mac80211 and cfg80211. All modern drivers _must_ use mac80211 or
>> cfg80211 without exception.
>> 2. In general, there is no official in-kernel support for
>> out-of-kernel drivers, regardless of quality, status or importance.
>> 3. I believe that the in-tree brcmsmac driver already supports the
>> Broadcom card you reference.
>
>
> 3b. If 3. is not correct, someone should endeavor to merge this
> out-of-tree driver into the kernel tree.
Actually, it is correct and brcmsmac and the out-of-tree wl driver are
coming from the same code base although you should not compare the two
these days.
Gr. AvS
^ permalink raw reply
* Re: [PATCH v2 net-next] drivers/net: Enable IOMMU pass through for be2net
From: Ivan Vecera @ 2013-04-05 7:51 UTC (permalink / raw)
To: David Miller
Cc: Craig Hada, netdev, sathya.perla, subbu.seetharaman,
ajit.khaparde, linux-kernel
In-Reply-To: <1358562195-2028-2-git-send-email-craig.hada@hp.com>
On 01/19/2013 03:23 AM, Craig Hada wrote:
> This patch sets the coherent DMA mask to 64-bit after the be2net driver
> has been acknowledged that the system is 64-bit DMA capable. The coherent
> DMA mask is examined by the Intel IOMMU driver to determine whether to
> allow pass through context mapping for all devices. With this patch, the
> be2net driver combined with be2net compatible hardware provides
> comparable performance to the case where vt-d is disabled. The main use
> case for this change is to decrease the time necessary to copy virtual
> machine memory during KVM live migration instantiations.
>
> This patch was tested on a system that enables the IOMMU in non-coherent
> mode. Two DMA remapper issues were encountered in the previous version and
> both patches have been committed.
> commit ea2447f700cab264019b52e2b417d689e052dcfd
> commit 2e12bc29fc5a12242d68e11875db3dd58efad9ff
>
> Signed-off-by: Craig Hada <craig.hada@hp.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 9dca22b..b507e99 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -4052,6 +4052,12 @@ static int be_probe(struct pci_dev *pdev, const struct pci_device_id *pdev_id)
>
> status = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!status) {
> + status = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
> + if (status < 0) {
> + dev_err(&pdev->dev,
> + "dma_set_coherent_mask failed, aborting\n");
> + goto free_netdev;
> + }
> netdev->features |= NETIF_F_HIGHDMA;
> } else {
> status = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
>
Dave, I'd like to ask when do you plan to apply this patch?
Thanks,
Ivan
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx4_en: Enable open-lldp DCB support
From: John Fastabend @ 2013-04-05 7:52 UTC (permalink / raw)
To: Or Gerlitz
Cc: John Fastabend, Sagi Grimberg, Or Gerlitz, davem, netdev, amirv
In-Reply-To: <CAJZOPZJgZNkABE4+40+CnmpDRHDzEY-ZZmTH3L5JyoMHJX0Cow@mail.gmail.com>
On 04/05/2013 12:15 AM, Or Gerlitz wrote:
> John Fastabend <john.fastabend@gmail.com> wrote:
>
>> Agree it doesn't work without this patch but we can fix it in user
>> space. This has the nice benefit of letting lldpad work with mlx4 on
>> older kernels. In general I think its easier to update user space then
>> the kernel for most users. I'll send you a lldpad patch in a few moments.
>
> So to be sure we're on the same page, what we should do is enhance
> mlx4_en_dcbnl_getdcbx() routine to also return DCB_CAP_DCBX_HOST and
Right I think this is a better approach in the long run.
> work with your user space patch? sounds nice, except for what happens
> if people run with older versions of lldpad..
>
Well it won't work. But on the flip side all your older drivers _will_
work with the new daemon. My working assumption is for most users its
easier to upgrade a user space pkg than a kernel. And the simpler we
can keep the kernel code the better. Oh and also if there is a bug in
user space we shouldn't fix it with kernel code.
> Or.
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH v2 net-next] drivers/net: Enable IOMMU pass through for be2net
From: David Miller @ 2013-04-05 8:24 UTC (permalink / raw)
To: ivecera
Cc: craig.hada, netdev, sathya.perla, subbu.seetharaman,
ajit.khaparde, linux-kernel
In-Reply-To: <515E827C.3070702@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Fri, 05 Apr 2013 09:51:24 +0200
> Dave, I'd like to ask when do you plan to apply this patch?
I'm waiting for the be2net driver maintainers to integrate it and
resend it to me, they're usually very good about that.
^ permalink raw reply
* RE: [PATCH v2 net-next] drivers/net: Enable IOMMU pass through for be2net
From: Perla, Sathya @ 2013-04-05 8:37 UTC (permalink / raw)
To: David Miller, ivecera@redhat.com
Cc: craig.hada@hp.com, netdev@vger.kernel.org,
Seetharaman, Subramanian, Khaparde, Ajit,
linux-kernel@vger.kernel.org
In-Reply-To: <20130405.042427.456273365605730206.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
>
> From: Ivan Vecera <ivecera@redhat.com>
> Date: Fri, 05 Apr 2013 09:51:24 +0200
>
> > Dave, I'd like to ask when do you plan to apply this patch?
>
> I'm waiting for the be2net driver maintainers to integrate it and resend it to
> me, they're usually very good about that.
Ok, I'll do it and send out a patch soon...thanks!
^ permalink raw reply
* Re: [PATCH 3/5 v2] ARM: kirkwood: add device node entries for the gigabit interfaces
From: Florian Fainelli @ 2013-04-05 9:21 UTC (permalink / raw)
To: Simon Baatz
Cc: thomas.petazzoni, moinejf, jason, andrew, netdev,
devicetree-discuss, rob.herring, grant.likely, jogo,
linux-arm-kernel, jm, davem, buytenh, sebastian.hesselbarth
In-Reply-To: <20130404213517.GB25904@schnuecks.de>
Le 04/04/13 23:35, Simon Baatz a écrit :
> Hi Florian,
>
> On Thu, Apr 04, 2013 at 12:27:13PM +0200, Florian Fainelli wrote:
>> This patch modifies kirkwood.dtsi to specify the various gigabit
>> interfaces nodes available on kirkwood devices. They are disabled by
>> default and should be enabled on a per-board basis. egiga0 and egiga1
>> aliases are defined for convenience. The mdio node is also present and
>> should be enabled on a per-board basis as well.
>>
>> Signed-off-by: Florian Fainelli <florian@openwrt.org>
>> ---
>> Changes since v1:
>> - dropped change to arch/arm/mach-kirkwood/common.c to avoid merge conflicts
>
> I think we should remove the clock aliases in
> kirkwood_legacy_clk_init() in mach-kirkwood/dt-board.c (once we have
> proper clock support, see my other mail).
>
[snip]
>
> Don't we need to add:
>
> interrupts = <46>;
>
> here?
Right this is missing, in fact it still works ok because the orion-mdio
driver can do busy waiting instead of interrupt signaling. Will fix that
in the next round, thanks!
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [patch net 0/2] net: ipv4: fix couple of addr lifetime related bugs
From: Jiri Pirko @ 2013-04-05 9:39 UTC (permalink / raw)
To: netdev; +Cc: davem, kuznet, jmorris, yoshfuji, kaber
Jiri Pirko (2):
net: ipv4: reset check_lifetime_work after changing lifetime
net: ipv4: fix schelude while atomic bug in check_lifetime()
net/ipv4/devinet.c | 60 +++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 44 insertions(+), 16 deletions(-)
--
1.8.1.2
^ 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