* [net-2.6 PATCH 1/2] ixgbe: add support for 82599 Combined Backplane
From: Jeff Kirsher @ 2009-10-02 18:58 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Don Skidmore, Peter P Waskiewicz Jr, Jeff Kirsher
From: Don Skidmore <donald.c.skidmore@intel.com>
This patch will add support for the 82599 Dual port Backplane
device (0x10f8). This device has the ability to link in serial (KR) and
parallel (KX4/KX) modes, depending on what the switch capabilities are in
the blade chassis.
Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_82599.c | 1 +
drivers/net/ixgbe/ixgbe_main.c | 2 ++
drivers/net/ixgbe/ixgbe_type.h | 1 +
3 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_82599.c b/drivers/net/ixgbe/ixgbe_82599.c
index 2ec58dc..bb87c43 100644
--- a/drivers/net/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ixgbe/ixgbe_82599.c
@@ -330,6 +330,7 @@ static enum ixgbe_media_type ixgbe_get_media_type_82599(struct ixgbe_hw *hw)
switch (hw->device_id) {
case IXGBE_DEV_ID_82599_KX4:
+ case IXGBE_DEV_ID_82599_COMBO_BACKPLANE:
case IXGBE_DEV_ID_82599_XAUI_LOM:
/* Default device ID is mezzanine card KX/KX4 */
media_type = ixgbe_media_type_backplane;
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 1cbc6a3..dc4afa5 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -99,6 +99,8 @@ static struct pci_device_id ixgbe_pci_tbl[] = {
board_82599 },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_CX4),
board_82599 },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_COMBO_BACKPLANE),
+ board_82599 },
/* required last entry */
{0, }
diff --git a/drivers/net/ixgbe/ixgbe_type.h b/drivers/net/ixgbe/ixgbe_type.h
index 7c93e92..a71f712 100644
--- a/drivers/net/ixgbe/ixgbe_type.h
+++ b/drivers/net/ixgbe/ixgbe_type.h
@@ -52,6 +52,7 @@
#define IXGBE_DEV_ID_82599_CX4 0x10F9
#define IXGBE_DEV_ID_82599_SFP 0x10FB
#define IXGBE_DEV_ID_82599_XAUI_LOM 0x10FC
+#define IXGBE_DEV_ID_82599_COMBO_BACKPLANE 0x10F8
/* General Registers */
#define IXGBE_CTRL 0x00000
^ permalink raw reply related
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: Greg KH @ 2009-10-02 18:15 UTC (permalink / raw)
To: David Miller
Cc: philipp.reisner, linux-kernel, netdev, akpm, dm-devel, zbr,
linux-fbdev-devel
In-Reply-To: <20091002.110504.08207839.davem@davemloft.net>
On Fri, Oct 02, 2009 at 11:05:04AM -0700, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Fri, 2 Oct 2009 11:00:22 -0700
>
> > On Fri, Oct 02, 2009 at 10:56:59AM -0700, David Miller wrote:
> >> All applied to net-2.6, I'll push this out to Linus later
> >> today.
> >
> > Should it also go to -stable? If so, I can pick it up once it hits
> > Linus's tree.
>
> Yes, please take it into -stable.
Will do.
> Greg, I'll also send you a batch of other networking bits
> for -stable later this afternoon as well, just FYI...
Great, I'll queue it up for the next -stable releases, these are full
enough as it is already :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: export device speed and duplex via sysfs
From: Ben Hutchings @ 2009-10-02 18:19 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20091002180742.GH4436@gospo.rdu.redhat.com>
On Fri, 2009-10-02 at 14:07 -0400, Andy Gospodarek wrote:
> This exports the link-speed (in Mbps) and duplex of an interface via
> sysfs. This eliminates the need to use ethtool just to check the
> link-speed. Not requiring 'ethtool' and not relying on the SIOCETHTOOL
> ioctl should be helpful in an embedded environment where space is at a
> premium as well.
It's trivial to write an ethtool-lite that does this. That might be
worth adding to busybox.
> NOTE: This patch also intentionally allows non-root users to check the link
> speed and duplex -- something not possible with ethtool.
[...]
Assuming this is desirable (I'm not sure), wouldn't it would make more
sense to move the permissions check for SIOCETHTOOL so that get_settings
is non-privileged?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] Use sk_mark for IPv6 routing lookups
From: Brian Haley @ 2009-10-02 18:19 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Eric Dumazet, David Miller, atis, panther, netdev
In-Reply-To: <55a4f86e0910021025u7523029av1e4ee917d1fb1ee5@mail.gmail.com>
Maciej Żenczykowski wrote:
> Cool!
>
> As I've already pointed out in a post 2 or so weeks ago, we need the
> exact same treatment in a ton of places throughout the code (tcp,
> ipv6, decnet, etc...).
Here's a try at the IPv6 part...
Add support for IPv6 route lookups using sk_mark.
Signed-off-by: Brian Haley <brian.haley@hp.com>
---
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index e2bdc6d..a615b4d 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -147,6 +147,7 @@ ipv4_connected:
ipv6_addr_copy(&fl.fl6_dst, &np->daddr);
ipv6_addr_copy(&fl.fl6_src, &np->saddr);
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
fl.fl_ip_dport = inet->dport;
fl.fl_ip_sport = inet->sport;
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index cc4797d..a9f4a21 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -194,6 +194,7 @@ int inet6_csk_xmit(struct sk_buff *skb, int ipfragok)
fl.fl6_flowlabel = np->flow_label;
IP6_ECN_flow_xmit(sk, fl.fl6_flowlabel);
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
fl.fl_ip_sport = inet->sport;
fl.fl_ip_dport = inet->dport;
security_sk_classify_flow(sk, &fl);
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 7161539..d98df54 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1523,6 +1523,7 @@ static int ip6mr_forward2(struct sk_buff *skb, struct mfc6_cache *c, int vifi)
fl = (struct flowi) {
.oif = vif->link,
+ .mark = skb->mark,
.nl_u = { .ip6_u =
{ .daddr = ipv6h->daddr, }
}
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 14f54eb..dc0f736 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -424,6 +424,7 @@ sticky_done:
fl.fl6_flowlabel = 0;
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
if (optlen == 0)
goto update;
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index dbd19a7..03a64c1 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -629,6 +629,7 @@ static netdev_tx_t ipip6_tunnel_xmit(struct sk_buff *skb,
.saddr = tiph->saddr,
.tos = RT_TOS(tos) } },
.oif = tunnel->parms.link,
+ .mark = skb->mark,
.proto = IPPROTO_IPV6 };
if (ip_route_output_key(dev_net(dev), &rt, &fl)) {
stats->tx_carrier_errors++;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 21d100b..321aafd 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -243,6 +243,7 @@ static int tcp_v6_connect(struct sock *sk, struct sockaddr *uaddr,
ipv6_addr_copy(&fl.fl6_src,
(saddr ? saddr : &np->saddr));
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
fl.fl_ip_dport = usin->sin6_port;
fl.fl_ip_sport = inet->sport;
@@ -383,6 +384,7 @@ static void tcp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
ipv6_addr_copy(&fl.fl6_dst, &np->daddr);
ipv6_addr_copy(&fl.fl6_src, &np->saddr);
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
fl.fl_ip_dport = inet->dport;
fl.fl_ip_sport = inet->sport;
security_skb_classify_flow(skb, &fl);
@@ -477,6 +479,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req)
ipv6_addr_copy(&fl.fl6_src, &treq->loc_addr);
fl.fl6_flowlabel = 0;
fl.oif = treq->iif;
+ fl.mark = sk->sk_mark;
fl.fl_ip_dport = inet_rsk(req)->rmt_port;
fl.fl_ip_sport = inet_rsk(req)->loc_port;
security_req_classify_flow(req, &fl);
@@ -1345,6 +1348,7 @@ static struct sock * tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
}
ipv6_addr_copy(&fl.fl6_src, &treq->loc_addr);
fl.oif = sk->sk_bound_dev_if;
+ fl.mark = sk->sk_mark;
fl.fl_ip_dport = inet_rsk(req)->rmt_port;
fl.fl_ip_sport = inet_rsk(req)->loc_port;
security_req_classify_flow(req, &fl);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 3a60f12..3842c55 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -879,6 +879,8 @@ do_udp_sendmsg:
if (!fl.oif)
fl.oif = np->sticky_pktinfo.ipi6_ifindex;
+ fl.mark = sk->sk_mark;
+
if (msg->msg_controllen) {
opt = &opt_space;
memset(opt, 0, sizeof(struct ipv6_txoptions));
^ permalink raw reply related
* Re: [PATCH] net: export device speed and duplex via sysfs
From: Eric Dumazet @ 2009-10-02 18:15 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20091002180742.GH4436@gospo.rdu.redhat.com>
Andy Gospodarek a écrit :
> +static ssize_t show_speed(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct net_device *netdev = to_net_dev(dev);
> + int ret = -EINVAL;
> +
> + if (!rtnl_trylock())
> + return restart_syscall();
> +
> + if (netif_running(netdev) && netdev->ethtool_ops->get_settings) {
> + struct ethtool_cmd cmd = { ETHTOOL_GSET };
> +
> + if (netdev->ethtool_ops->get_settings(netdev, &cmd) < 0)
rtnl lock leak ?
> + return -EINVAL;
> + ret = sprintf(buf, fmt_dec, cmd.speed);
> + }
> + rtnl_unlock();
> + return ret;
> +}
> +
> +static ssize_t show_duplex(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct net_device *netdev = to_net_dev(dev);
> + int ret = -EINVAL;
> +
> + if (!rtnl_trylock())
> + return restart_syscall();
> +
> + if (netif_running(netdev) && netdev->ethtool_ops->get_settings) {
> + struct ethtool_cmd cmd = { ETHTOOL_GSET };
> +
> + if (netdev->ethtool_ops->get_settings(netdev, &cmd) < 0)
rtnl lock leak ?
> + return -EINVAL;
> + ret = sprintf(buf, "%s\n", cmd.duplex ? "full" : "half");
> + }
> + rtnl_unlock();
> + return ret;
> +}
> +
^ permalink raw reply
* [GIT]: Networking
From: David Miller @ 2009-10-02 18:13 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) connector credentials fix patch set from Philipp Reisner
2) IXGBE bug fixes from Peter P Waskiewicz Jr,Ben Greear,
and Jiri Pirko.
3) sk->sk_mark not used consistently for routing lookups keys,
fix from Atis Elsts
4) splice() nonblocking fix, from Eric Dumazet
5) pktgen delay handling regressed, fix from Eric Dumazet
6) ks8851_mll ethernet driver, from David Choi
7) TCP build warning fix from Andrew Morton
8) be2net RX completion bug workaround from Ajit Khaparde
9) Bonding doesn't set primary param properly, fix from Jiri Pirko.
10) Even if window scale is zero, TCP should advertise the option
so that the other ends knows we support window scaling and thus
they can advertise a non-zero scale if they want to.
From Ori Finkelman.
11) qlge bug fixes from Ron Mercer.
12) SKY2 and SKGE irq names can conflict because the IRQ manages two devices
and if one of them gets it's name changed just right (by udev
or whatever) the request_irq() fails. Fix from Stephen Hemminger
and Michal Schmidt.
13) Wireless bug fixes via John Linville.
Please pull, thanks a lot!
The following changes since commit 817b33d38f81c8736d39283c35c886ae4668f1af:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Ajit Khaparde (1):
be2net: Workaround to fix a bug in Rx Completion processing.
Andrew Morton (1):
net/ipv4/tcp.c: fix min() type mismatch warning
Anton Vorontsov (1):
3c59x: Rework suspend and resume
Atis Elsts (1):
net: Use sk_mark for routing lookup in more places
Ben Greear (1):
ixgbe patch to provide NIC's tx/rx counters via ethtool
Choi, David (1):
drivers/net: ks8851_mll ethernet network driver
Christian Lamparter (1):
ar9170: fix bug in iq-auto calibration value calculation
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-2.6
Eric Dumazet (3):
pktgen: Fix delay handling
tg3: Remove prev_vlan_tag from struct tx_ring_info
net: splice() from tcp to pipe should take into account O_NONBLOCK
Frans Pop (1):
e1000e/igb/ixgbe: Don't report an error if devices don't support AER
Igor Perminov (1):
mac80211: Fix [re]association power saving issue on AP side
Jean Delvare (1):
net: Fix wrong sizeof
Jiri Pirko (2):
ixgbe: correct the parameter description
bonding: set primary param via sysfs
Jouni Malinen (1):
mac80211_hwsim: Fix initial beacon timer configuration
Michael Buesch (1):
b43: Always use block-I/O for the PIO data registers
Michael Chan (1):
cnic: Fix NETDEV_UP event processing.
Michal Schmidt (1):
skge: use unique IRQ name
Michal Szalata (1):
rt2x00: Thrustmaster FunAccess WIFI USB and rt73usb
Mike McCormack (1):
skge: Make sure both ports initialize correctly
Ori Finkelman (1):
IPv4 TCP fails to send window scale option when window scale is zero
Peter P Waskiewicz Jr (4):
ixgbe: Fix disabling of relaxed ordering with Tx DCA
ixgbe: Fix backplane flow control autoneg
ixgbe: Bump driver version number
ixgbe: Remove ATR computation for UDP traffic
Philipp Reisner (8):
connector: Keep the skb in cn_callback_data
connector: Provide the sender's credentials to the callback
connector/dm: Fixed a compilation warning
connector: Removed the destruct_data callback since it is always kfree_skb()
dm/connector: Only process connector packages from privileged processes
dst/connector: Disallow unpliviged users to configure dst
pohmelfs/connector: Disallow unpliviged users to configure pohmelfs
uvesafb/connector: Disallow unpliviged users to send netlink packets
Ralf Baechle (2):
NET: mkiss: Fix typo
Kconfig: STRIP: Remove stale bits of STRIP help text
Ron Mercer (5):
qlge: Fix bad bit definitions.
qlge: Fix out of sync hardware semaphore.
qlge: Fix spin_lock warning.
qlge: Protect reset recovery with rtnl_lock().
qlge: Fix error exit for probe call.
Stephen Hemminger (1):
sky2: irqname based on pci address
Uwe Kleine-König (3):
don't use __devexit_p to wrap meth_remove
don't use __devexit_p to wrap sgiseeq_remove
move virtnet_remove to .devexit.text
roel kluin (1):
bcm63xx_enet: timeout off by one in do_mdio_op()
Documentation/connector/cn_test.c | 2 +-
Documentation/connector/connector.txt | 8 +-
.../networking/timestamping/timestamping.c | 2 +-
drivers/connector/cn_queue.c | 12 +-
drivers/connector/connector.c | 22 +-
drivers/md/dm-log-userspace-transfer.c | 6 +-
drivers/net/3c59x.c | 77 +-
drivers/net/Kconfig | 7 +
drivers/net/Makefile | 1 +
drivers/net/bcm63xx_enet.c | 2 +-
drivers/net/benet/be.h | 1 +
drivers/net/benet/be_cmds.c | 3 +-
drivers/net/benet/be_cmds.h | 3 +-
drivers/net/benet/be_main.c | 23 +-
drivers/net/bonding/bond_sysfs.c | 1 +
drivers/net/cnic.c | 3 +-
drivers/net/cnic_if.h | 4 +-
drivers/net/e1000e/netdev.c | 13 +-
drivers/net/hamradio/mkiss.c | 4 +-
drivers/net/igb/igb_main.c | 13 +-
drivers/net/iseries_veth.c | 2 +-
drivers/net/ixgbe/ixgbe_82598.c | 2 +-
drivers/net/ixgbe/ixgbe_common.c | 232 ++-
drivers/net/ixgbe/ixgbe_ethtool.c | 4 +
drivers/net/ixgbe/ixgbe_main.c | 52 +-
drivers/net/ixgbe/ixgbe_type.h | 9 +
drivers/net/ks8851_mll.c | 1697 ++++++++++++++++++++
drivers/net/meth.c | 2 +-
drivers/net/qlge/qlge.h | 18 +-
drivers/net/qlge/qlge_main.c | 26 +-
drivers/net/sgiseeq.c | 2 +-
drivers/net/skge.c | 16 +-
drivers/net/skge.h | 2 +
drivers/net/sky2.c | 7 +-
drivers/net/sky2.h | 2 +
drivers/net/tg3.h | 1 -
drivers/net/virtio_net.c | 2 +-
drivers/net/wireless/Kconfig | 13 +-
drivers/net/wireless/ath/ar9170/phy.c | 6 +-
drivers/net/wireless/b43/pio.c | 60 +-
drivers/net/wireless/mac80211_hwsim.c | 3 +
drivers/net/wireless/rt2x00/rt73usb.c | 1 +
drivers/staging/dst/dcore.c | 7 +-
drivers/staging/pohmelfs/config.c | 5 +-
drivers/video/uvesafb.c | 5 +-
drivers/w1/w1_netlink.c | 2 +-
include/linux/connector.h | 11 +-
net/core/pktgen.c | 6 +-
net/ipv4/af_inet.c | 1 +
net/ipv4/ip_output.c | 1 +
net/ipv4/tcp.c | 4 +-
net/ipv4/tcp_output.c | 11 +-
net/ipv4/udp.c | 1 +
net/mac80211/tx.c | 5 +-
54 files changed, 2157 insertions(+), 268 deletions(-)
create mode 100644 drivers/net/ks8851_mll.c
^ permalink raw reply
* [PATCH] net: export device speed and duplex via sysfs
From: Andy Gospodarek @ 2009-10-02 18:07 UTC (permalink / raw)
To: netdev
This exports the link-speed (in Mbps) and duplex of an interface via
sysfs. This eliminates the need to use ethtool just to check the
link-speed. Not requiring 'ethtool' and not relying on the SIOCETHTOOL
ioctl should be helpful in an embedded environment where space is at a
premium as well.
NOTE: This patch also intentionally allows non-root users to check the link
speed and duplex -- something not possible with ethtool.
Here's some sample output:
# cat /sys/class/net/eth0/speed
100
# cat /sys/class/net/eth0/duplex
half
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Half
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x000000ff (255)
Link detected: yes
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
net/core/net-sysfs.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index ad91e9e..d5964b2 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -130,6 +130,46 @@ static ssize_t show_carrier(struct device *dev,
return -EINVAL;
}
+static ssize_t show_speed(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct net_device *netdev = to_net_dev(dev);
+ int ret = -EINVAL;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ if (netif_running(netdev) && netdev->ethtool_ops->get_settings) {
+ struct ethtool_cmd cmd = { ETHTOOL_GSET };
+
+ if (netdev->ethtool_ops->get_settings(netdev, &cmd) < 0)
+ return -EINVAL;
+ ret = sprintf(buf, fmt_dec, cmd.speed);
+ }
+ rtnl_unlock();
+ return ret;
+}
+
+static ssize_t show_duplex(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct net_device *netdev = to_net_dev(dev);
+ int ret = -EINVAL;
+
+ if (!rtnl_trylock())
+ return restart_syscall();
+
+ if (netif_running(netdev) && netdev->ethtool_ops->get_settings) {
+ struct ethtool_cmd cmd = { ETHTOOL_GSET };
+
+ if (netdev->ethtool_ops->get_settings(netdev, &cmd) < 0)
+ return -EINVAL;
+ ret = sprintf(buf, "%s\n", cmd.duplex ? "full" : "half");
+ }
+ rtnl_unlock();
+ return ret;
+}
+
static ssize_t show_dormant(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -259,6 +299,8 @@ static struct device_attribute net_class_attributes[] = {
__ATTR(address, S_IRUGO, show_address, NULL),
__ATTR(broadcast, S_IRUGO, show_broadcast, NULL),
__ATTR(carrier, S_IRUGO, show_carrier, NULL),
+ __ATTR(speed, S_IRUGO, show_speed, NULL),
+ __ATTR(duplex, S_IRUGO, show_duplex, NULL),
__ATTR(dormant, S_IRUGO, show_dormant, NULL),
__ATTR(operstate, S_IRUGO, show_operstate, NULL),
__ATTR(mtu, S_IRUGO | S_IWUSR, show_mtu, store_mtu),
--
1.6.2.5
^ permalink raw reply related
* Re: Splice on blocking TCP sockets again..
From: Eric Dumazet @ 2009-10-02 18:05 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Volker Lendecke, netdev, Volker Lendecke
In-Reply-To: <20091002171029.GG5191@obsidianresearch.com>
Jason Gunthorpe a écrit :
>
> I'd suggest a construct like the following as a compatability
> solution:
>
> struct pollfd pfd = {.fd = tcpfd, events = POLLIN | POLLRDHUP};
> while (..) {
> rc = splice(tcpfd,0,pfd[1],0,count,SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
> if (rc == -1)
> //...
> if (rc == 0) {
> if (pfd.revents & POLLRDHUP)
> // oops, EOF on TCP
>
> /* Might be an old kernel that nonblocks on TCP, have to check
> if this is EOF or do blocking. */
> rc = poll(&pfd,1,-1);
> if (rc == -1)
> //...
> }
>
> rc = splice(pfd[0],0,ofd,0,..., SPLICE_F_MOVE)
> }
>
> Which should add no overhead in the new splice blocks case, and falls
> back gracefully on older kernels..
>
Agreed, thanks for the tip.
Indeed, new kernel will permit a loop with only splice() syscalls, while on an old
kernel, some poll() syscalls might be needed if tcp socket is empty.
^ permalink raw reply
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: David Miller @ 2009-10-02 18:05 UTC (permalink / raw)
To: greg
Cc: linux-fbdev-devel, netdev, philipp.reisner, linux-kernel,
dm-devel, zbr, akpm
In-Reply-To: <20091002180022.GA22229@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Fri, 2 Oct 2009 11:00:22 -0700
> On Fri, Oct 02, 2009 at 10:56:59AM -0700, David Miller wrote:
>> All applied to net-2.6, I'll push this out to Linus later
>> today.
>
> Should it also go to -stable? If so, I can pick it up once it hits
> Linus's tree.
Yes, please take it into -stable.
Greg, I'll also send you a batch of other networking bits
for -stable later this afternoon as well, just FYI...
^ permalink raw reply
* Re: [PATCH] cnic: Fix NETDEV_UP event processing.
From: David Miller @ 2009-10-02 18:03 UTC (permalink / raw)
To: mchan; +Cc: netdev, michaelc, benli
In-Reply-To: <1254464254-32005-1-git-send-email-mchan@broadcom.com>
From: "Michael Chan" <mchan@broadcom.com>
Date: Thu, 1 Oct 2009 23:17:34 -0700
> This fixes the problem of not handling the NETDEV_UP event properly
> during hot-plug or modprobe of bnx2 after cnic. The handling was
> skipped by mistakenly using "else if" to check for the event.
>
> Also update version to 2.0.1.
>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: Benjamin Li <benli@broadcom.com>
Applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: Greg KH @ 2009-10-02 18:00 UTC (permalink / raw)
To: David Miller
Cc: philipp.reisner, linux-kernel, netdev, akpm, dm-devel, zbr,
linux-fbdev-devel
In-Reply-To: <20091002.105659.102583702.davem@davemloft.net>
On Fri, Oct 02, 2009 at 10:56:59AM -0700, David Miller wrote:
> From: Philipp Reisner <philipp.reisner@linbit.com>
> Date: Fri, 2 Oct 2009 14:40:03 +0200
>
> > Affected: All code that uses connector, in kernel and out of mainline
> >
> > The connector, as it is today, does not allow the in kernel receiving
> > parts to do any checks on privileges of a message's sender.
> >
> > I know, there are not many out there that like connector, but as
> > long as it is in the kernel, we have to fix the security issues it has!
> >
> > Please either drop connector, or someone who feels a bit responsible
> > and has our beloved dictator's blessing, PLEASE PLEASE PLEASE take
> > this into your tree, and send the pull request to Linus.
> >
> > Patches 1 to 4 are already Acked-by Evgeny, the connector's maintainer.
> > Patches 5 to 7 are the obvious fixes to the connector user's code.
> >
> > For convenience these patches are also available as git tree:
> > git://git.drbd.org/linux-2.6-drbd.git connector-fix
>
> All applied to net-2.6, I'll push this out to Linus later
> today.
Should it also go to -stable? If so, I can pick it up once it hits
Linus's tree.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] Use sk_mark for routing lookup in more places
From: David Miller @ 2009-10-02 18:00 UTC (permalink / raw)
To: zenczykowski; +Cc: eric.dumazet, atis, panther, netdev
In-Reply-To: <55a4f86e0910021025u7523029av1e4ee917d1fb1ee5@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Fri, 2 Oct 2009 10:25:13 -0700
> Maybe it would make more sense to create some constructor-like
> functions for the flowi struct?
Maybe just an initializer like "FLOWI_SOCK(sk)" or similar.
So you can say:
struct flowi fl = FLOWI_SOCK(sk);
But the thing is we usually want to initialize all of the
details in one go, so we'd need a very messy macro for this
that would take many arguments.
It's important to use an initializer rather than assignments in some
inline function so that GCC can better coalesce many small members
into since large stores to the stack. It doesn't do this as well with
real assignment statements.
^ permalink raw reply
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: David Miller @ 2009-10-02 17:56 UTC (permalink / raw)
To: philipp.reisner
Cc: linux-kernel, netdev, akpm, greg, dm-devel, zbr,
linux-fbdev-devel
In-Reply-To: <1254487211-11810-1-git-send-email-philipp.reisner@linbit.com>
From: Philipp Reisner <philipp.reisner@linbit.com>
Date: Fri, 2 Oct 2009 14:40:03 +0200
> Affected: All code that uses connector, in kernel and out of mainline
>
> The connector, as it is today, does not allow the in kernel receiving
> parts to do any checks on privileges of a message's sender.
>
> I know, there are not many out there that like connector, but as
> long as it is in the kernel, we have to fix the security issues it has!
>
> Please either drop connector, or someone who feels a bit responsible
> and has our beloved dictator's blessing, PLEASE PLEASE PLEASE take
> this into your tree, and send the pull request to Linus.
>
> Patches 1 to 4 are already Acked-by Evgeny, the connector's maintainer.
> Patches 5 to 7 are the obvious fixes to the connector user's code.
>
> For convenience these patches are also available as git tree:
> git://git.drbd.org/linux-2.6-drbd.git connector-fix
All applied to net-2.6, I'll push this out to Linus later
today.
^ permalink raw reply
* Re: [PATCH] make TLLAO option for NA packets configurable
From: Stephen Hemminger @ 2009-10-02 17:53 UTC (permalink / raw)
To: Octavian Purdila; +Cc: David Miller, cratiu, netdev
In-Reply-To: <200910020119.47320.opurdila@ixiacom.com>
On Fri, 2 Oct 2009 01:19:47 +0300
Octavian Purdila <opurdila@ixiacom.com> wrote:
> On Thursday 01 October 2009 22:37:40 you wrote:
> > From: Stephen Hemminger <shemminger@vyatta.com>
> > Date: Thu, 1 Oct 2009 11:56:11 -0700
> >
> > > On Thu, 1 Oct 2009 21:39:32 +0300
> > >
> > > Octavian Purdila <opurdila@ixiacom.com> wrote:
> > >> On Thursday 01 October 2009 21:14:50 you wrote:
> > >> > Probably this should be a per interface property rather than per
> > >> > namespace.
> > >>
> > >> In our case, where we have lots of interfaces active, it would be nice
> > >> to have the per namespace property as well.
> > >
> > > The ipv6 control infrastructure already has that option. If you changed
> > > your patch to use a per-interface control then there would be:
> > >
> > > /proc/sys/net/ipv6/conf/all/force_tllao
> >
> > Right, this would work a lot better.
> >
>
> Here is v3 which also updates Documentation/networking/ip-sysctl.txt.
>
> Thanks,
> tavi
>
>
This is good although I would have shortened the name.
--
^ permalink raw reply
* Re: [PATCH] TCPCT-1: adding a sysctl
From: William Allen Simpson @ 2009-10-02 17:52 UTC (permalink / raw)
To: netdev
In-Reply-To: <4AC61505.8030701@gmail.com>
William Allen Simpson wrote:
> This is a straightforward re-implementation of an earlier patch, that no
> longer applies cleanly, that was reviewed:
>
> http://thread.gmane.org/gmane.linux.network/102586
>
In that thread, David Miller wrote:
"This looks mostly fine to me. I would even advocate not using a config
option for this."
It would make the code look cleaner, and with the sysctl instead, it
would probably be fine. But SYN cookies has both.
Before I go much further, I'd like guidance.
^ permalink raw reply
* Re: 2.6.32-rc1-git2: Reported regressions from 2.6.31
From: Rafael J. Wysocki @ 2009-10-02 17:32 UTC (permalink / raw)
To: Stefan Richter
Cc: Jaswinder Singh Rajput, Linux Kernel Mailing List, Adrian Bunk,
Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
In-Reply-To: <4AC5F975.6060505@s5r6.in-berlin.de>
On Friday 02 October 2009, Stefan Richter wrote:
> Jaswinder Singh Rajput wrote:
> > If you add one more entry say "Suspected commit :" then it will be great
> > and will solve regressions much faster.
>
> Will? Might.
In fact I add the "First-Bad-Commit" annotation where there is a bisection
result or it's possible to fix things by reverting a specific commit.
> > You can request submitter to
> > submit 'suspected commit' by git bisect and also specify git bisect
> > links like : (for more information about git bisect check
> > http://kerneltrap.org/node/11753)
>
> I disagree. A reporter should only be asked to bisect (using git or
> other tools) /if/ a developer determined that bisection may speed up the
> debugging process or is the only remaining option to make progress with
> a bug.
>
> It would be wrong to steal a reporter's valuable time by asking for
> bisection before anybody familiar with the matter even had a first look
> at the report.
Agreed.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] Use sk_mark for routing lookup in more places
From: Maciej Żenczykowski @ 2009-10-02 17:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, atis, panther, netdev
In-Reply-To: <4AC598D7.9080900@gmail.com>
Cool!
As I've already pointed out in a post 2 or so weeks ago, we need the
exact same treatment in a ton of places throughout the code (tcp,
ipv6, decnet, etc...).
Maybe it would make more sense to create some constructor-like
functions for the flowi struct?
On Thu, Oct 1, 2009 at 23:08, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Eric Dumazet a écrit :
>> Here is a followup on this area, thanks.
>>
>> [RFC] af_packet: fill skb->mark at xmit
>>
>> skb->mark may be used by classifiers, so fill it in case user
>> set a SO_MARK option on socket.
>>
>
> Maybe a more generic way to handle this for various protocols
> would be to fill skb->mark in sock_alloc_send_pskb()
>
>
> --
> 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
>
^ permalink raw reply
* Re: Splice on blocking TCP sockets again..
From: Jason Gunthorpe @ 2009-10-02 17:10 UTC (permalink / raw)
To: Volker Lendecke; +Cc: Eric Dumazet, netdev, Volker Lendecke
In-Reply-To: <E1Mssmb-004RJz-Hf@intern.SerNet.DE>
On Wed, Sep 30, 2009 at 08:37:13AM +0200, Volker Lendecke wrote:
> On Tue, Sep 29, 2009 at 06:48:20PM -0600, Jason Gunthorpe wrote:
> > FWIW, it looks like samba has a splice code now, but doesn't enable it
> > due to this issue?
>
> Right. What I've learned from the comments is that splice is
> only usable in multi-threaded programs. One thread is
> reading, one is writing from the other end. I deferred using
> splice until we have the proper architecture to do sync
> syscalls in helper threads to make them virtually async. We
> have some code for that now, but it's not a high priority
> for me at this moment.
So, it looks like thanks to Eric and davem that splice will be changed
so it can be blocking on the TCP and non-blocking on the PIPE.
I'd suggest a construct like the following as a compatability
solution:
struct pollfd pfd = {.fd = tcpfd, events = POLLIN | POLLRDHUP};
while (..) {
rc = splice(tcpfd,0,pfd[1],0,count,SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
if (rc == -1)
//...
if (rc == 0) {
if (pfd.revents & POLLRDHUP)
// oops, EOF on TCP
/* Might be an old kernel that nonblocks on TCP, have to check
if this is EOF or do blocking. */
rc = poll(&pfd,1,-1);
if (rc == -1)
//...
}
rc = splice(pfd[0],0,ofd,0,..., SPLICE_F_MOVE)
}
Which should add no overhead in the new splice blocks case, and falls
back gracefully on older kernels..
Thanks,
Jason
^ permalink raw reply
* Adding to linux-next?
From: Gregory Haskins @ 2009-10-02 17:08 UTC (permalink / raw)
To: linux-next, Stephen Rothwell
Cc: linux-kernel@vger.kernel.org, netdev, David Miller,
alacrityvm-devel@lists.sourceforge.net
[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]
Hello Stephen, linux-next'ers,
I am looking for some guidance on policy/procedure governing inclusion
of a tree to linux-next. For instance: Do I have to be arbitrarily
invited (e.g. by some committee on LKML), or do I explicitly request
consideration? I tried to Google around for answers, and also found the
linux-next wiki, but I was not getting any clear answers.
I have these guest drivers to support IO on top of the AlacrityVM
hypervisor:
http://lkml.org/lkml/2009/8/3/278
The comments have since died down. I realize this can mean anything
from "no objection" to "no interest" ;), but I assume the former unless
someone pipes up.
I believe I addressed the review comments and received an Ack from the
one maintainer of the tree that overlaps with the work (netdev/davem), here:
http://lkml.org/lkml/2009/8/3/505
Since the rest of the work doesn't really fall into any existing
subsystem, and David conceded that the netdev overlap portion should
carry elsewhere, I offer to fill this role myself from within the
AlacrityVM tree itself.
As such, I have taken the driver series and created a new branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/ghaskins/alacrityvm/linux-2.6.git
linux-next
Unlike the original posting, I have excluded the final ethernet patch
since I posted a v3 today (http://lkml.org/lkml/2009/10/2/239) that I
would like to have David re-Ack before including.
Once the driver has been suitably approved by David, and if he still
feels its ok to carry in a tree other than netdev, I will re-add it to
the linux-next branch.
Because I am not really sure of the policies for linux-next, let me
state my intentions of this branch, since I am an unknown in the
maintainership role:
I will only post patches to this branch that:
*) do not fall into an existing maintained subsystem category, unless
the appropriate maintainer has relinquished the patch to carry in my tree.
*) have previously been posted to LKML for suitable review.
IOW: The purpose is not to sneak something in, or subvert a maintained
subsystem. It is purely to carry pieces that have no other home and are
maintained under the AlacrityVM project. You can find more details of
the project here:
http://developer.novell.com/wiki/index.php/AlacrityVM
If this is not acceptable, or I need to follow some other procedure,
please advise me on the proper steps. Perhaps I will update the wiki
FAQ on what I learn from your responses :)
Thank you, and Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [net-2.6 PATCH] e1000e/igb/ixgbe: Don't report an error if devices don't support AER
From: David Miller @ 2009-10-02 17:04 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, elendil
In-Reply-To: <20091002071542.5072.23381.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 02 Oct 2009 00:15:48 -0700
> From: Frans Pop <elendil@planet.nl>
>
> The only error returned by pci_{en,dis}able_pcie_error_reporting() is
> -EIO which simply means that Advanced Error Reporting is not supported.
> There is no need to report that, so remove the error check from e1000e,
> igb and ixgbe.
>
> Signed-off-by: Frans Pop <elendil@planet.nl>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: David Miller @ 2009-10-02 16:57 UTC (permalink / raw)
To: philipp.reisner
Cc: linux-fbdev-devel, greg, linux-kernel, dm-devel, netdev, zbr,
akpm
In-Reply-To: <200910021754.12940.philipp.reisner@linbit.com>
From: Philipp Reisner <philipp.reisner@linbit.com>
Date: Fri, 2 Oct 2009 17:54:12 +0200
> Think of the connector as a layer on top of netlink that allows more
> than a hard coded number of subsystems to use netlink.
There are no such limits in netlink, we have 'genetlink' which allows
an arbitrary number of subsystems to use netlink.
What connector provides over netlink/genetlink is something different
altogether.
^ permalink raw reply
* Re: [PATCH] net: Fix wrong sizeof
From: David Miller @ 2009-10-02 16:54 UTC (permalink / raw)
To: khali; +Cc: linux-kernel, netdev, linux-doc, rdunlap, stable
In-Reply-To: <20091002113038.1dc3d284@hyperion.delvare>
From: Jean Delvare <khali@linux-fr.org>
Date: Fri, 2 Oct 2009 11:30:38 +0200
> Which is why I have always preferred sizeof(struct foo) over
> sizeof(var).
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Randy Dunlap <rdunlap@xenotime.net>
Any time you see "&" in a sizeof() expression, it's almost
certainly a bug. Something for the folks with automated
tools to look for if they haven't already :-)
I'll apply this, thanks.
^ permalink raw reply
* Re: SPLICE_F_NONBLOCK semantics...
From: David Miller @ 2009-10-02 16:45 UTC (permalink / raw)
To: jens.axboe
Cc: torvalds, eric.dumazet, jgunthorpe, vl, opurdila, netdev,
linux-kernel
In-Reply-To: <20091002074754.GE14918@kernel.dk>
From: Jens Axboe <jens.axboe@oracle.com>
Date: Fri, 2 Oct 2009 09:47:54 +0200
> The net patch looks fine and correct to me, feel free to add my acked-by
> if you want.
Thanks Jens.
^ permalink raw reply
* Re: [PATCH 5/8] dm/connector: Only process connector packages from privileged processes
From: Jonathan Brassow @ 2009-10-02 16:40 UTC (permalink / raw)
To: device-mapper development
Cc: linux-fbdev-devel, netdev, LKML, Philipp Reisner, Greg KH,
Evgeniy Polyakov, Andrew Morton, David S. Miller, Alasdair Kergon
In-Reply-To: <1254487211-11810-6-git-send-email-philipp.reisner@linbit.com>
[-- Attachment #1.1: Type: text/plain, Size: 2190 bytes --]
This patch (and "[dm-devel] [PATCH 3/8] connector/dm: Fixed a
compilation warning") will likely collide with an earlier patch (which
agk is pushing) to fix the compilation warning (https://www.redhat.com/archives/dm-devel/2009-September/msg00218.html
), but the fix-up will be trivial.
The dm-log-userspace code checks that incoming messages correspond to
requests that were sent to userspace by way of a sequence number. If
they don't correspond, they are dropped. So, you must be able to
receive the messages from this kernel module (be root) in order to be
able respond with a message that will be accepted. I can't completely
rule out the ability to guess a sequence number, and be able to beat
the log daemon in responding while the window of that sequence
number's validity is open though... If someone could manage to pull
this off with accuracy, they could disrupt the creation of a device,
mimic a log device failure, or cause mirror resynchronization to occur
to a different area that may simultaneously be performing a write
(potential data corruption of a mirror). It would be an impressive
feat to accomplish this, but I very much welcome the patch rather than
test fate.
Reviewed-by: Jonathan Brassow <jbrassow@redhat.com>
brassow
On Oct 2, 2009, at 7:40 AM, Philipp Reisner wrote:
> Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
> ---
> drivers/md/dm-log-userspace-transfer.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/md/dm-log-userspace-transfer.c b/drivers/md/dm-
> log-userspace-transfer.c
> index 1327e1a..54abf9e 100644
> --- a/drivers/md/dm-log-userspace-transfer.c
> +++ b/drivers/md/dm-log-userspace-transfer.c
> @@ -133,6 +133,9 @@ static void cn_ulog_callback(struct cn_msg *msg,
> struct netlink_skb_parms *nsp)
> {
> struct dm_ulog_request *tfr = (struct dm_ulog_request *)(msg + 1);
>
> + if (!cap_raised(nsp->eff_cap, CAP_SYS_ADMIN))
> + return;
> +
> spin_lock(&receiving_list_lock);
> if (msg->len == 0)
> fill_pkg(msg, NULL);
> --
> 1.6.0.4
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
[-- Attachment #1.2: Type: text/html, Size: 3438 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 0/8] SECURITY ISSUE with connector
From: Lars Ellenberg @ 2009-10-02 16:21 UTC (permalink / raw)
To: Greg KH
Cc: linux-fbdev-devel, netdev, Philipp Reisner, linux-kernel,
dm-devel, Evgeniy Polyakov, Andrew Morton, David S. Miller,
Alasdair G Kergon
In-Reply-To: <20091002135859.GA9383@kroah.com>
On Fri, Oct 02, 2009 at 06:58:59AM -0700, Greg KH wrote:
> On Fri, Oct 02, 2009 at 02:40:03PM +0200, Philipp Reisner wrote:
> > Affected: All code that uses connector, in kernel and out of mainline
> >
> > The connector, as it is today, does not allow the in kernel receiving
> > parts to do any checks on privileges of a message's sender.
>
> So, assume I know nothing about the connector architecture, what does
> this mean in a security context?
Arbitrary unprivileged users may craft a netlink message, which gets delivered
through connector to callbacks (registered in kernel with cn_add_callback).
These callbacks will then act on the message, as if it originated from an
"expected" source. But currently there is no mechanism to verify the origin,
even if the callbacks would try to.
> > I know, there are not many out there that like connector, but as
> > long as it is in the kernel, we have to fix the security issues it has!
>
> And what specifically are the security issues?
For the cn_ulog_callback (dm-log-userspace-transfer.c),
someone would be able to fake completion (with or without error code)
of ulog entries, copying arbitrary data into receiving_pkg entries.
/*
* This is the connector callback that delivers data
* that was sent from userspace.
*/
static void cn_ulog_callback(void *data)
{
struct cn_msg *msg = (struct cn_msg *)data;
struct dm_ulog_request *tfr = (struct dm_ulog_request *)(msg + 1);
spin_lock(&receiving_list_lock);
if (msg->len == 0)
fill_pkg(msg, NULL);
else if (msg->len < sizeof(*tfr))
DMERR("Incomplete message received (expected %u, got %u): [%u]",
(unsigned)sizeof(*tfr), msg->len, msg->seq);
else
fill_pkg(NULL, tfr);
spin_unlock(&receiving_list_lock);
}
static int fill_pkg(struct cn_msg *msg, struct dm_ulog_request *tfr)
{
uint32_t rtn_seq = (msg) ? msg->seq : (tfr) ? tfr->seq : 0;
...
} else {
pkg->error = tfr->error;
memcpy(pkg->data, tfr->data, tfr->data_size);
*(pkg->data_size) = tfr->data_size;
}
complete(&pkg->complete);
should make that obvious: if an unprivileged user can deliver arbitrary msg to
cn_ulog_callback, that should at least be disruptive to services that use it.
fix: check origin of message for proper credentials (e.g. CAP_SYS_ADMIN).
what or how much damage a crafted message can do in uvesafb_cn_callback,
I'm not sure. But, if I get the msg->seq right, and get by the first
sanity check, again, arbitrary input is copied into some
kernel object, which will likely at least confuse that subsystem,
maybe do damage, or result in some sort of denial of service.
I just don't know what these uvesafb_ktask do, but I doubt that anyone but root
should be able to manipulate them.
in the case of dst and pohemlfs, it is (re|de) configuration of respective in
kernel objects, possibly exposing arbitrary data content
@Evgeniy - is that statement correct? Does something prevent an
unprivileged user to export arbitrary things via dst?
At least some sort of denial of service should be possible there.
for DRBD, we have of course similar problems as long as we use the connector
in its current form as our configuration choice.
I'm not sure what actual harm can be done by arbitrary calling
w1_reset_select_slave(), or w1_process_command_io(),
but allowing unprivileged users to meddle with arbitrary devices is most likely
not the intended behaviour there, either.
The "obvious" way was to first make the credentials and capabilities of the
message origin available to these callbacks, and then test on "CAP_SYS_ADMIN".
Note that the suggested usage of the connector for _userspace_ tools
is to bind() to some netlink socket, subscribing to apropriate mutlicast
groups, which will usually fail for unprivileged users in netlink_bind()
because of
/* Only superuser is allowed to listen multicasts */
if (nladdr->nl_groups) {
if (!netlink_capable(sock, NL_NONROOT_RECV))
return -EPERM;
err = netlink_realloc_groups(sk);
if (err)
return err;
}
So typical userspace tools will fail when used as non-root.
But if you leave out the bind, you are perfectly able to _send_ arbitrary
messages on that socket, even if you are not able to receive any replies from
connector kernel space in that case.
Cheers,
Lars
^ 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