* Re: [PATCH] drivers/isdn/sc/init.c: Fix warning:passing argument 1 of ‘readl’ makes pointer from integer without a cast
From: David Miller @ 2011-09-03 2:28 UTC (permalink / raw)
To: harvey.huawei.yang; +Cc: isdn, linux-kernel, netdev
In-Reply-To: <1315015339-2501-1-git-send-email-harvey.huawei.yang@gmail.com>
From: Harvey Yang <harvey.huawei.yang@gmail.com>
Date: Sat, 3 Sep 2011 10:02:19 +0800
> drivers/isdn/sc/init.c:487: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
We should fix this by adding random casts to every readl() call,
instead we should fix the fundamental data types being passed
in.
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Ang Way Chuang @ 2011-09-03 2:15 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Nicolas de Pesloüan, David S. Miller, netdev, Achmad Basuki
In-Reply-To: <20110902151100.327af0bf@nehalam.ftrdhcpuser.net>
On 03/09/11 07:11, Stephen Hemminger wrote:
> On Fri, 02 Sep 2011 23:39:03 +0200
> Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>
>> Le 02/09/2011 19:22, Stephen Hemminger a écrit :
>>> This resolves a regression seen by some users of bridging.
>>> Some users use the bridge like a dummy device.
>>> They expect to be able to put an IPv6 address on the device
>>> with no ports attached during boot.
>>>
>>> Note: the bridge still will reflect the state of ports in the
>>> bridge if there are any added.
Guilty as charged :) It's a valid use case in libvirtd. Thanks for the patch. I've tried your patch.
It doesn't work. There is still no carrier. Thing still break. The whole of commit
1faa4356a including the part where liveports is used to toggle carrier has to be reverted. Otherwise, it doesn't work.
I've tried that on my machine.
>> Doesn't this jeopardize the behavior introduced in 1faa4356a3bd89ea11fb92752d897cff3a20ec0e
>> "bridge: control carrier based on ports online"?
>>
>> If the user starts the DHCP client before adding the first port to the bridge, the DHCP client will
>> have a carrier and start the autoconfiguration process. This was the old behavior, but you fixed it.
>>
>> Nicolas.
>>
> There is no perfect solution.
> If DHCP works then IPv6 breaks?
A more ideal solution in this case is to add the option to enabling carrier on sysfs and modify libvirtd
to turn on the carrier if IPv6 is enabled. But it will still break the existing configuration until everyone
upgrade to the latest libvirtd and kernel. Since there is no other complain from other user with this setup,
I guess nobody actually assigns IPv6 to libvirtd network device at this moment (partly because virt-manager
doesn't expose that functionality yet??).
> --
> 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
* [PATCH] drivers/isdn/sc/init.c: Fix warning:passing argument 1 of ‘readl’ makes pointer from integer without a cast
From: Harvey Yang @ 2011-09-03 2:02 UTC (permalink / raw)
To: Karsten Keil; +Cc: linux-kernel, netdev, Harvey Yang
drivers/isdn/sc/init.c:487: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
/home/harvey/Projects/linux-kernel/linux-2.6/arch/x86/include/asm/io.h:55: note: expected ‘const volatile void *’ but argument is of type ‘long unsigned int’
drivers/isdn/sc/init.c:497: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
/home/harvey/Projects/linux-kernel/linux-2.6/arch/x86/include/asm/io.h:55: note: expected ‘const volatile void *’ but argument is of type ‘long unsigned int’
drivers/isdn/sc/init.c:507: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
/home/harvey/Projects/linux-kernel/linux-2.6/arch/x86/include/asm/io.h:55: note: expected ‘const volatile void *’ but argument is of type ‘long unsigned int’
Signed-off-by: Harvey Yang <harvey.huawei.yang@gmail.com>
---
drivers/isdn/sc/init.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/isdn/sc/init.c b/drivers/isdn/sc/init.c
index ca710ab..d3db30d 100644
--- a/drivers/isdn/sc/init.c
+++ b/drivers/isdn/sc/init.c
@@ -484,7 +484,7 @@ static int identify_board(unsigned long rambase, unsigned int iobase)
*/
outb(PRI_BASEPG_VAL, pgport);
msleep_interruptible(1000);
- sig = readl(rambase + SIG_OFFSET);
+ sig = readl((const volatile void *)(rambase + SIG_OFFSET));
pr_debug("Looking for a signature, got 0x%lx\n", sig);
if(sig == SIGNATURE)
return PRI_BOARD;
@@ -494,7 +494,7 @@ static int identify_board(unsigned long rambase, unsigned int iobase)
*/
outb(BRI_BASEPG_VAL, pgport);
msleep_interruptible(1000);
- sig = readl(rambase + SIG_OFFSET);
+ sig = readl((const volatile void *)(rambase + SIG_OFFSET));
pr_debug("Looking for a signature, got 0x%lx\n", sig);
if(sig == SIGNATURE)
return BRI_BOARD;
@@ -504,7 +504,7 @@ static int identify_board(unsigned long rambase, unsigned int iobase)
/*
* Try to spot a card
*/
- sig = readl(rambase + SIG_OFFSET);
+ sig = readl((const volatile void *)(rambase + SIG_OFFSET));
pr_debug("Looking for a signature, got 0x%lx\n", sig);
if(sig != SIGNATURE)
return -1;
--
1.7.2.5
^ permalink raw reply related
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Michał Mirosław @ 2011-09-03 1:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Wyborny, Carolyn, David Miller, netdev@vger.kernel.org
In-Reply-To: <1314999272.3419.19.camel@bwh-desktop>
W dniu 2 września 2011 23:34 użytkownik Ben Hutchings
<bhutchings@solarflare.com> napisał:
> On Fri, 2011-09-02 at 23:22 +0200, Michał Mirosław wrote:
>> W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
>> <mirqus@gmail.com> napisał:
>> > 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>> >>>-----Original Message-----
>> >>>From: David Miller [mailto:davem@davemloft.net]
>> >>>Sent: Friday, September 02, 2011 1:55 PM
>> >>>To: Wyborny, Carolyn
>> >>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>> >>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>> >>>ethtool application.
>> >>>
>> >>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>> >>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>> >>>
>> >>>> This patch completes the user space implementation of the private
>> >>>> flags inteface in ethtool. Using -b/-B options.
>> >>>>
>> >>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>> >>>
>> >>>The only use case you show here is something generic which other
>> >>>chips have, Energy Efficient Ethernet.
>> >>>
>> >>>Making an attribute private which is present widely amonst various
>> >>>networking chips makes no sense at all.
>> >>>
>> >>>It deserved a generic ethtool flag.
>> >>
>> >> Fair enough on this particular feature, but does that negate the implementation suggestion altogether? I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
>> > I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
>> > semantics allow easy expanding to handle device-private flags without
>> > changing anything on userspace side.
>>
>> BTW, After pending Intel drivers get converted to ndo_set_features and
>> netdev->features get extended to 64 bits, it would also be possible to
>> use some of the unused bits there for device/driver-private flags
>> almost "for free".
> I don't really like the idea of mixing common feature flags with
> driver-specific flags. It's likely to lead to confusion if you mix
> devices with different drivers in a bridge or a bond.
I assume that device-specific flags won't ever be included in
vlan_features not be transferred in other ways to bridge or bonding.
If this holds, then it doesn't really matter how the flags are stored
and if they are included in features. I'll make a PoC implementation
to show the idea only after the feature cleanup is done, as otherwise
I would have yet another idea hanging in the queue.
Rough sketch is that there would be some number of bits in features
left after all global ones that drivers would present to userspace by
appending feature names to the string set returned for
ETH_SS_FEATURES. Those names would need to have common prefix like
'priv-' or maybe driver name prepended, and be documented as not
something that shoud be regarded as stable.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: missing [PATCH 01/15]
From: Serge E. Hallyn @ 2011-09-03 1:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: akpm, segooon, linux-kernel, netdev, containers, dhowells,
rdunlap
In-Reply-To: <m11uvyld2d.fsf_-_@fess.ebiederm.org>
Quoting Eric W. Biederman (ebiederm@xmission.com):
>
>
> Was this blank email supposed to be patch 01/15?
Nope, that was <grr> a git-send-email misfire. Sorry about that. The
patch #1 did go through, here: https://lkml.org/lkml/2011/9/2/314
I'm appending it here again too for easier feedback.
thanks,
-serge
Subject: [PATCH 01/15] add Documentation/namespaces/user_namespace.txt (v3)
Quoting David Howells (dhowells@redhat.com):
> Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> > > +Any task in or resource belonging to the initial user namespace will, to this
> > > +new task, appear to belong to UID and GID -1 - which is usually known as
> >
> > that extra hyphen is confusing. how about:
> >
> > to UID and GID -1, which is
>
> 'which are'.
>
> David
This will hold some info about the design. Currently it contains
future todos, issues and questions.
Changelog:
jul 26: incorporate feedback from David Howells.
jul 29: incorporate feedback from Randy Dunlap.
Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Randy Dunlap <rdunlap@xenotime.net>
---
Documentation/namespaces/user_namespace.txt | 107 +++++++++++++++++++++++++++
1 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 Documentation/namespaces/user_namespace.txt
diff --git a/Documentation/namespaces/user_namespace.txt b/Documentation/namespaces/user_namespace.txt
new file mode 100644
index 0000000..b0bc480
--- /dev/null
+++ b/Documentation/namespaces/user_namespace.txt
@@ -0,0 +1,107 @@
+Description
+===========
+
+Traditionally, each task is owned by a user ID (UID) and belongs to one or more
+groups (GID). Both are simple numeric IDs, though userspace usually translates
+them to names. The user namespace allows tasks to have different views of the
+UIDs and GIDs associated with tasks and other resources. (See 'UID mapping'
+below for more.)
+
+The user namespace is a simple hierarchical one. The system starts with all
+tasks belonging to the initial user namespace. A task creates a new user
+namespace by passing the CLONE_NEWUSER flag to clone(2). This requires the
+creating task to have the CAP_SETUID, CAP_SETGID, and CAP_CHOWN capabilities,
+but it does not need to be running as root. The clone(2) call will result in a
+new task which to itself appears to be running as UID and GID 0, but to its
+creator seems to have the creator's credentials.
+
+To this new task, any resource belonging to the initial user namespace will
+appear to belong to user and group 'nobody', which are UID and GID -1.
+Permission to open such files will be granted according to world access
+permissions. UID comparisons and group membership checks will return false,
+and privilege will be denied.
+
+When a task belonging to (for example) userid 500 in the initial user namespace
+creates a new user namespace, even though the new task will see itself as
+belonging to UID 0, any task in the initial user namespace will see it as
+belonging to UID 500. Therefore, UID 500 in the initial user namespace will be
+able to kill the new task. Files created by the new user will (eventually) be
+seen by tasks in its own user namespace as belonging to UID 0, but to tasks in
+the initial user namespace as belonging to UID 500.
+
+Note that this userid mapping for the VFS is not yet implemented, though the
+lkml and containers mailing list archives will show several previous
+prototypes. In the end, those got hung up waiting on the concept of targeted
+capabilities to be developed, which, thanks to the insight of Eric Biederman,
+they finally did.
+
+Relationship between the User namespace and other namespaces
+============================================================
+
+Other namespaces, such as UTS and network, are owned by a user namespace. When
+such a namespace is created, it is assigned to the user namespace of the task
+by which it was created. Therefore, attempts to exercise privilege to
+resources in, for instance, a particular network namespace, can be properly
+validated by checking whether the caller has the needed privilege (i.e.
+CAP_NET_ADMIN) targeted to the user namespace which owns the network namespace.
+This is done using the ns_capable() function.
+
+As an example, if a new task is cloned with a private user namespace but
+no private network namespace, then the task's network namespace is owned
+by the parent user namespace. The new task has no privilege to the
+parent user namespace, so it will not be able to create or configure
+network devices. If, instead, the task were cloned with both private
+user and network namespaces, then the private network namespace is owned
+by the private user namespace, and so root in the new user namespace
+will have privilege targeted to the network namespace. It will be able
+to create and configure network devices.
+
+UID Mapping
+===========
+The current plan (see 'flexible UID mapping' at
+https://wiki.ubuntu.com/UserNamespace) is:
+
+The UID/GID stored on disk will be that in the init_user_ns. Most likely
+UID/GID in other namespaces will be stored in xattrs. But Eric was advocating
+(a few years ago) leaving the details up to filesystems while providing a lib/
+stock implementation. See the thread around here:
+http://www.mail-archive.com/devel@openvz.org/msg09331.html
+
+
+Working notes
+=============
+Capability checks for actions related to syslog must be against the
+init_user_ns until syslog is containerized.
+
+Same is true for reboot and power, control groups, devices, and time.
+
+Perf actions (kernel/event/core.c for instance) will always be constrained to
+init_user_ns.
+
+Q:
+Is accounting considered properly containerized with respect to pidns? (it
+appears to be). If so, then we can change the capable() check in
+kernel/acct.c to 'ns_capable(current_pid_ns()->user_ns, CAP_PACCT)'
+
+Q:
+For things like nice and schedaffinity, we could allow root in a container to
+control those, and leave only cgroups to constrain the container. I'm not sure
+whether that is right, or whether it violates admin expectations.
+
+I deferred some of commoncap.c. I'm punting on xattr stuff as they take
+dentries, not inodes.
+
+For drivers/tty/tty_io.c and drivers/tty/vt/vt.c, we'll want to (for some of
+them) target the capability checks at the user_ns owning the tty. That will
+have to wait until we get userns owning files straightened out.
+
+We need to figure out how to label devices. Should we just toss a user_ns
+right into struct device?
+
+capable(CAP_MAC_ADMIN) checks are always to be against init_user_ns, unless
+some day LSMs were to be containerized, near zero chance.
+
+inode_owner_or_capable() should probably take an optional ns and cap parameter.
+If cap is 0, then CAP_FOWNER is checked. If ns is NULL, we derive the ns from
+inode. But if ns is provided, then callers who need to derive
+inode_userns(inode) anyway can save a few cycles.
--
1.7.5.4
^ permalink raw reply related
* Re: [next] unix stream crashes
From: Tim Chen @ 2011-09-02 23:55 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Jiri Slaby, David S. Miller, ML netdev, LKML, Sedat Dilek,
Stephen Rothwell
In-Reply-To: <6805.1314979936@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
On Fri, 2011-09-02 at 12:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 01 Sep 2011 18:40:45 PDT, Tim Chen said:
>
> > Yes, Jiri's log does indicate that something went wrong when releasing
> > the skb, most likely due to changes in the pid and credentials ref
> > count. Unfortunately, I cannot duplicate the problem on my system. Any
> > info on your system to help me debug will be appreciated. I'll try to
> > take another look at the patch tomorrow.
>
> Dell Latitude E6500, Core2 T8700 processor, x86_64 kernel, a slightly mangled
> Fedora Rawhide userspace. I'd not be surprised if there's an idiocyncratic
> setting in my .config that makes the bug crawl out of the woodwork on my box,
> so I'm attaching the .config in case it provides some enlightenment.
>
> If you want me to try a debugging or test patch, let me know...
Valdis,
I've tried your config on a few different machines but I'm still not
able to reproduce the problem. Can you help me narrow things down?
Please revert my original patch. I've separated my original changes
into two parts. Try apply only the recv_scm.patch attached and try to
boot. Then apply only the send_scm.patch without the rcv_scm.patch and
repeat. Let me know which patch causes the boot problem.
I'll like to isolate the problem to either the send path or receive
path. My suspicion is the error handling portion of the send path is not
quite right but I haven't yet found any issues after reviewing the
patch.
Thanks.
Tim
[-- Attachment #2: scm_recv.patch --]
[-- Type: text/x-patch, Size: 1858 bytes --]
diff --git a/include/net/scm.h b/include/net/scm.h
index 745460f..68e1e48 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -53,6 +53,14 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
cred_to_ucred(pid, cred, &scm->creds);
}
+static __inline__ void scm_set_cred_noref(struct scm_cookie *scm,
+ struct pid *pid, const struct cred *cred)
+{
+ scm->pid = pid;
+ scm->cred = cred;
+ cred_to_ucred(pid, cred, &scm->creds);
+}
+
static __inline__ void scm_destroy_cred(struct scm_cookie *scm)
{
put_pid(scm->pid);
@@ -108,15 +125,14 @@ static __inline__ void scm_recv(struct socket *sock, struct msghdr *msg,
if (!msg->msg_control) {
if (test_bit(SOCK_PASSCRED, &sock->flags) || scm->fp)
msg->msg_flags |= MSG_CTRUNC;
- scm_destroy(scm);
+ if (scm && scm->fp)
+ __scm_destroy(scm);
return;
}
if (test_bit(SOCK_PASSCRED, &sock->flags))
put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm->creds), &scm->creds);
- scm_destroy_cred(scm);
-
scm_passec(sock, msg, scm);
if (!scm->fp)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..e6d9d10 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1777,7 +1789,7 @@ static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock,
siocb->scm = &tmp_scm;
memset(&tmp_scm, 0, sizeof(tmp_scm));
}
- scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
+ scm_set_cred_noref(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
unix_set_secdata(siocb->scm, skb);
if (!(flags & MSG_PEEK)) {
@@ -1939,7 +1951,8 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock,
}
} else {
/* Copy credentials */
- scm_set_cred(siocb->scm, UNIXCB(skb).pid, UNIXCB(skb).cred);
+ scm_set_cred_noref(siocb->scm, UNIXCB(skb).pid,
+ UNIXCB(skb).cred);
check_creds = 1;
}
[-- Attachment #3: scm_send.patch --]
[-- Type: text/x-patch, Size: 3783 bytes --]
diff --git a/include/net/scm.h b/include/net/scm.h
index 745460f..68e1e48 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -70,6 +78,15 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
__scm_destroy(scm);
}
+static __inline__ void scm_release(struct scm_cookie *scm)
+{
+ /* keep ref on pid and cred */
+ scm->pid = NULL;
+ scm->cred = NULL;
+ if (scm->fp)
+ __scm_destroy(scm);
+}
+
static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
struct scm_cookie *scm)
{
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..e6d9d10 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1378,11 +1378,17 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
return max_level;
}
-static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
+static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb,
+ bool send_fds, bool ref)
{
int err = 0;
- UNIXCB(skb).pid = get_pid(scm->pid);
- UNIXCB(skb).cred = get_cred(scm->cred);
+ if (ref) {
+ UNIXCB(skb).pid = get_pid(scm->pid);
+ UNIXCB(skb).cred = get_cred(scm->cred);
+ } else {
+ UNIXCB(skb).pid = scm->pid;
+ UNIXCB(skb).cred = scm->cred;
+ }
UNIXCB(skb).fp = NULL;
if (scm->fp && send_fds)
err = unix_attach_fds(scm, skb);
@@ -1407,7 +1413,7 @@ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock,
int namelen = 0; /* fake GCC */
int err;
unsigned hash;
- struct sk_buff *skb;
+ struct sk_buff *skb = NULL;
long timeo;
struct scm_cookie tmp_scm;
int max_level;
@@ -1448,7 +1454,7 @@ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (skb == NULL)
goto out;
- err = unix_scm_to_skb(siocb->scm, skb, true);
+ err = unix_scm_to_skb(siocb->scm, skb, true, false);
if (err < 0)
goto out_free;
max_level = err + 1;
@@ -1544,7 +1550,7 @@ restart:
unix_state_unlock(other);
other->sk_data_ready(other, len);
sock_put(other);
- scm_destroy(siocb->scm);
+ scm_release(siocb->scm);
return len;
out_unlock:
@@ -1554,7 +1560,8 @@ out_free:
out:
if (other)
sock_put(other);
- scm_destroy(siocb->scm);
+ if (skb == NULL)
+ scm_destroy(siocb->scm);
return err;
}
@@ -1566,7 +1573,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
struct sock *sk = sock->sk;
struct sock *other = NULL;
int err, size;
- struct sk_buff *skb;
+ struct sk_buff *skb = NULL;
int sent = 0;
struct scm_cookie tmp_scm;
bool fds_sent = false;
@@ -1631,11 +1638,11 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
size = min_t(int, size, skb_tailroom(skb));
- /* Only send the fds in the first buffer */
- err = unix_scm_to_skb(siocb->scm, skb, !fds_sent);
+ /* Only send the fds and no ref to pid in the first buffer */
+ err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, fds_sent);
if (err < 0) {
kfree_skb(skb);
- goto out_err;
+ goto out;
}
max_level = err + 1;
fds_sent = true;
@@ -1643,7 +1650,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
if (err) {
kfree_skb(skb);
- goto out_err;
+ goto out;
}
unix_state_lock(other);
@@ -1660,7 +1667,10 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
sent += size;
}
- scm_destroy(siocb->scm);
+ if (skb)
+ scm_release(siocb->scm);
+ else
+ scm_destroy(siocb->scm);
siocb->scm = NULL;
return sent;
@@ -1673,7 +1683,9 @@ pipe_err:
send_sig(SIGPIPE, current, 0);
err = -EPIPE;
out_err:
- scm_destroy(siocb->scm);
+ if (skb == NULL)
+ scm_destroy(siocb->scm);
+out:
siocb->scm = NULL;
return sent ? : err;
}
^ permalink raw reply related
* missing [PATCH 01/15]
From: Eric W. Biederman @ 2011-09-02 23:49 UTC (permalink / raw)
To: Serge Hallyn
Cc: akpm, segooon, linux-kernel, netdev, containers, dhowells,
rdunlap
In-Reply-To: <1314993400-6910-3-git-send-email-serge@hallyn.com>
Was this blank email supposed to be patch 01/15?
Eric
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Stephen Hemminger @ 2011-09-02 22:11 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David S. Miller, netdev
In-Reply-To: <4E614CF7.7030700@gmail.com>
On Fri, 02 Sep 2011 23:39:03 +0200
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
> Le 02/09/2011 19:22, Stephen Hemminger a écrit :
> > This resolves a regression seen by some users of bridging.
> > Some users use the bridge like a dummy device.
> > They expect to be able to put an IPv6 address on the device
> > with no ports attached during boot.
> >
> > Note: the bridge still will reflect the state of ports in the
> > bridge if there are any added.
>
> Doesn't this jeopardize the behavior introduced in 1faa4356a3bd89ea11fb92752d897cff3a20ec0e
> "bridge: control carrier based on ports online"?
>
> If the user starts the DHCP client before adding the first port to the bridge, the DHCP client will
> have a carrier and start the autoconfiguration process. This was the old behavior, but you fixed it.
>
> Nicolas.
>
There is no perfect solution.
If DHCP works then IPv6 breaks?
^ permalink raw reply
* Re: BQL crap and wireless
From: Luis R. Rodriguez @ 2011-09-02 22:03 UTC (permalink / raw)
To: John W. Linville
Cc: Jim Gettys, Andrew McGregor, Adrian Chadd, Tom Herbert, Dave Taht,
linux-wireless, Matt Smith, Kevin Hayes, Derek Smithies,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110901141304.GA2580-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
On Thu, Sep 1, 2011 at 7:13 AM, John W. Linville <linville-2XuSBdqkA4SvXiR4WA35Jg@public.gmane.orgm> wrote:
> On Wed, Aug 31, 2011 at 01:50:48PM -0700, Luis R. Rodriguez wrote:
>> On Wed, Aug 31, 2011 at 6:28 AM, Jim Gettys <jg-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org> wrote:
>
>> > such as wireless, or even possibly modern broadband with
>> > PowerBoost, classic RED or similar algorithms that do not take the
>> > buffer drain rate cannot possibly hack it properly.
>>
>> Understood, just curious if anyone has tried a Minstrel approach.
>
> FWIW, eBDP and the related algorithms from Tianji Li's paper are
> philosophically similar to minstrel.
Oh look at that, awesome!!!
> They depend on measuring recent
> conditions and modifying the current queue length accordingly.
>
> http://www.hamilton.ie/tianji_li/buffersizing.pdf
>
> The hack I added in debloat-testing is based on my understanding
> of eBDP. It timestamps the SKBs when they are handed to the driver
> for Tx and then checks the timestamp when the SKB is orphaned. It is
> a bit crude and is an abuse of the skb_orphan API.
Neat!
> Also while it
> accounts for the 802.11e queues separately, it doesn't account for
> 802.11n aggregation.
I see..
> Still, it seems to improve latency w/o hugely
> impacting throughput in at least some environments -- YMMV!
Sweet dude. For aggregation it seems the way to go is to get some
helpers as Andrew has suggested. Andrew, can you elaborate a little on
that? If feasible, then maybe then we can add it to the TODO list
page:
http://wireless.kernel.org/en/developers/todo-list
and when one of us gets to it, we get cranking on it.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: BQL crap and wireless
From: Luis R. Rodriguez @ 2011-09-02 21:59 UTC (permalink / raw)
To: Jim Gettys
Cc: Andrew McGregor, Adrian Chadd, Tom Herbert, Dave Taht,
linux-wireless, Matt Smith, Kevin Hayes, Derek Smithies,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4E5FA74D.5000705-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>
BTW Jim, as you may have found out after sending this reply, vger
hates HTML e-mails so your e-mail only got to those on the CC list but
not to the list. I'm replying below, but since I'm now using ASCII
text the look of the e-mail will look like poo, I'll try to trim it
somehow as I did find valuable information you provided there. I also
make some suggestions below.
On Thu, Sep 1, 2011 at 8:39 AM, Jim Gettys <jg-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org> wrote:
> On 08/31/2011 04:50 PM, Luis R. Rodriguez wrote:
>
> On Wed, Aug 31, 2011 at 6:28 AM, Jim Gettys <jg-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org> wrote:
>
> On 08/30/2011 05:47 PM, Andrew McGregor wrote:
>
> On 31/08/2011, at 1:58 AM, Jim Gettys wrote:
>
> On 08/29/2011 11:42 PM, Adrian Chadd wrote:
>
> On 30 August 2011 11:34, Tom Herbert <therbert-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> C(P) is going to be quite variable - a full frame retransmit of a 4ms
> long aggregate frame is SUM(exponential backoff, grab the air,
> preamble, header, 4ms, etc. for each pass.)
>
> It's not clear to me that doing heroic measures to compute the cost is
> going to be worthwhile due to the rate at which the costs can change on
> wireless; just getting into the rough ballpark may be enough. But
> buffering algorithms and AQM algorithms are going to need an estimate of
> the *time* it will take to transmit data, more than # of bytes or packets.
>
> That's not heroic measures; mac80211 needs all the code to calculate these
> times anyway, it's just a matter of collecting together some things we
> already know and calling the right function.
>
>
> Fine; if it's easy, accurate is better (presuming the costs get
> recalculated when circumstances change). We also will need the amount of
> data being transmitted; it is the rate of transmission (the rate at
> which the buffers are draining) that we'll likely need.
>
> Here's what I've gleaned from reading "RED in a different light", Van
> Jacobson's Mitre talk and several conversations with Kathleen Nichols
> and Van: AQM algorithms that can handle variable bandwidth environments
> will need to be able to know the rate at which buffers empty. It's the
> direction they are going with their experiments on a "RED light" algorithm.
>
> The fundamental insight as to why classic RED can't work in the wireless
> environment is that the instantaneous queue length has little actual
> information in it.
> Classic RED is tuned using the queue length as its
> basic parameter. Their belief as to algorithms that will work is that
> the need to keep track of the running queue length *minimum over time*;
> you want to keep the buffers small on a longer term basis (so they both
> can absorb transients, which is their reason for existence, while
> keeping the latency typically low).
More details explained by Jim:
> TCP will fill any buffer just before the bottleneck in a path. And, of
> course, other traffic transients can help fill the buffers too. This is a
> natural consequence of it trying to figure out how fast it can run.
>
> Remember, TCP's job is to figure out just how fast it can go, so in its
> congestion avoidance phase, it increases the rate at which it transmits
> slowly (typical congestion avoidance algorithms will add one packet/ack to
> the bottleneck buffer). This is why in my traces you can find
> at:
> http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/
> you see something that sort of looks like a TCP sawtooth, but not: with
> periodicity of order 10 seconds (given the amount of buffering in that
> modem).
>
> What's happening is that as the buffer fills, the acks come back slower and
> slower
Wait, why is that though?
> (so the buffer fills somewhat more slowly) with time. But as they
> fill, not only do you get additional latency, but the buffers become less
> and less effective at doing what they are intended for: smoothing transients
> of higher rate incoming packets.
Is this bufferbloat or TCP not taking into consideration possible
variations in latency?
> So I ended up with 1.2 seconds of latency on my cable modem.
Jeesh.
> Depending on
> how much buffering is in the device, you get different amounts of latency
> under load. So at the provisioned bandwidth of those tests, my cable modem
> has at least 10x the "classic" BDP amount of buffering.
And for readers BDP is:
http://en.wikipedia.org/wiki/TCP_tuning#Bandwidth-delay_product_.28BDP.29
The max in-flight possible unacknowledged data in transit.
Just curious -- why would they have 10x the amount of BDP??
> Eventually, the bloated buffer does fill, (which might be a megabyte in
> size, btw, on some cable modems), and you get packet loss.
Why is that though?
> But well before this should have occurred, TCP Cubic has decided the path
> may have changed, and goes into a more aggressive search for a new operating
> point (so you see something that starts like a TCP sawtooth, but then
> switches back to something that looks more like slow start). This causes a
> long period bursty oscillation; the bursts are when multiple packet drops
> are occurring (because the TCP is hammering at the cable modem at way too
> high a speed for a short period).
Got it.
> Buffer bloat has therefore managed to destroy congestion avoidance
> entirely. Sigh... It also does a number on slow start, as the amount of
> buffering is way more than it should be and it takes several sets of packet
> loss before TCP even starts congestion avoidance.
So an observable trait is we likely can see some packet loss during
the shifts in throughput? Is that accurate?
For 802.11 this could be a lot of things -- some new noise,
interference, etc, but for Ethernet I'm curious what would cause this
assuming we ware blaming the fact that a lot of buffers are queued, is
the issue that the time it takes to flush out buffers surpasses some
timer on the OS to actually transmit the frames?
> On some home routers, the buffering is even more extreme; so whenever your
> bottleneck is in your home router (easy to do in my house as I have chimneys
> and lots of walls) the buffers in the home router become the problem.
>
> So I caught my home router of that era (it was a DIR 825, IIRC) with 8
> seconds of latency one evening.
Shit.
> The additional major challenge we
> face that core routers do not is the highly variable traffic of mixed
> mice and elephants. What actually works only time will tell.
Just FYI for 802.11 we have some effort to help us classify management
frames further into different access categories, typically we just
always use AC_VO to transmit management frames but the work undergoing
in 802.11ae Prioritization of Management frames allows us to assign
different ACs to different types of management frames, and the AP can
actually define these rules. People interested in this problem should
look at that and try out the defined default QoS management frame
profile and see if that helps. That is -- something like this might be
good for the bufferbloat experimental work -- but get it upstream,
don't fork ;)
> All this was well understood in the 1990's. Most of us *thought* the
> problem was solved by AQM algorithms such as RED. I was noddingly aware of
> AQM in the 1990's as I was working on HTTP in the IETF in that era, and AQM
> and buffer management in core routers was a very hot topic then.
>
> But the buffer management problem wasn't actually solved, and that result
> never got properly published, for the reasons I went into in:
>
> http://gettys.wordpress.com/2010/12/17/red-in-a-different-light/
>
> The field has languished since, and the problems that variable bandwidth
> present went unrecognised.
Then I stated:
> Thank you for elaborating on this, it helps to further dissect the
> issues. When mixing them together it makes the task harder to address.
> As for 802.11 we'd just need to worry about management frames. Dave
> and Andrew had also pointed out issues with multicast and the low
> rates used for them in comparison to unicast transmissions.
And you said:
> What matters for bufferbloat is how much payload gets moved per unit time:
> that is what is accumulating in the OS packet buffers.
>
>
> So in an environment in which the rate of transmission is highly
> variable,
I had interjected with:
> Not only that, remember we have different possible topologies
> depending on the type of 802.11 service used, IBSS, the typical AP-STA
> environment, Mesh, P2P (AP-STA really), and now with 802.11ad we get
> PBSS. What counts here is we may have variable rate of transmission to
> different possible peers, as such the queue length will depend on all
> of the expected transmissions.
and you had continued with:
> such as wireless, or even possibly modern broadband with
> PowerBoost, classic RED or similar algorithms that do not take the
> buffer drain rate cannot possibly hack it properly.
I had said:
> Understood, just curious if anyone has tried a Minstrel approach.
>
> Lets try to document all of this here:
>
> http://wireless.kernel.org/en/developers/bufferbloat
Then you ended with:
> Please do. Or work on the material in the bufferbloat.net wiki. I'm now
> too close to the problem to be good at explaining it any better than I try
> to here and in my other writings. Thomas Jefferson writing is *hard*.
>
> Probably best is that generic descriptions go into the bufferbloat.net wiki,
> and linux specific stuff on kernel.org; but I don't honestly care all that
> much where it is so long as it does get written down, along with the
> importance of Minstrel like algorithms in dealing with the variable
> bandwidth problem (which isn't in any of the material in my blog or
> bufferbloat.net, having not understood the problem there myself at all
> before a month or two ago when Andrew McGregor explained to me in detail
> what Minstrel is and does and why it needs to exist).
Sure, will work on this.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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 1/2] bridge: leave carrier on for empty bridge
From: Nicolas de Pesloüan @ 2011-09-02 21:39 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110902172247.396753508@vyatta.com>
Le 02/09/2011 19:22, Stephen Hemminger a écrit :
> This resolves a regression seen by some users of bridging.
> Some users use the bridge like a dummy device.
> They expect to be able to put an IPv6 address on the device
> with no ports attached during boot.
>
> Note: the bridge still will reflect the state of ports in the
> bridge if there are any added.
Doesn't this jeopardize the behavior introduced in 1faa4356a3bd89ea11fb92752d897cff3a20ec0e
"bridge: control carrier based on ports online"?
If the user starts the DHCP client before adding the first port to the bridge, the DHCP client will
have a carrier and start the autoconfiguration process. This was the old behavior, but you fixed it.
Nicolas.
^ permalink raw reply
* RE: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Ben Hutchings @ 2011-09-02 21:36 UTC (permalink / raw)
To: Wyborny, Carolyn
Cc: davem@davemloft.net, netdev@vger.kernel.org,
Michał Mirosław
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318F0173FF8650@orsmsx508.amr.corp.intel.com>
On Fri, 2011-09-02 at 14:33 -0700, Wyborny, Carolyn wrote:
>
> >-----Original Message-----
> >From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> >Sent: Friday, September 02, 2011 2:27 PM
> >To: Wyborny, Carolyn
> >Cc: davem@davemloft.net; netdev@vger.kernel.org
> >Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
> >ethtool application.
> >
> >On Fri, 2011-09-02 at 13:50 -0700, Carolyn Wyborny wrote:
> >> This patch completes the user space implementation of the private
> >> flags inteface in ethtool. Using -b/-B options.
> >[...]
> >
> >Private flags are supposed to be named (string set ETH_SS_PRIV_FLAGS).
> >ethtool should only support getting and setting flags by name, not
> >number. That way people can actually remember what the flags do and
> >their scripts won't break when the driver changes flag numbers.
> >
> >Ben.
> >
> >--
> >Ben Hutchings, Staff Engineer, Solarflare
> >Not speaking for my employer; that's the marketing department's job.
> >They asked us to note that Solarflare product names are trademarked.
>
> Ok, makes sense. Do you want a private flags implementation or do you
> agree with Michal on extending ETHTOOL_[GS]FEATURES?
I'm happy to add support for private flags identified by name.
(And I still haven't worked out with Michal how we're going to handle
the new features interface in ethtool. :-/)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* RE: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Wyborny, Carolyn @ 2011-09-02 21:35 UTC (permalink / raw)
To: Ben Hutchings, Michał Mirosław
Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <1314999272.3419.19.camel@bwh-desktop>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Friday, September 02, 2011 2:35 PM
>To: Michał Mirosław
>Cc: Wyborny, Carolyn; David Miller; netdev@vger.kernel.org
>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>ethtool application.
>
>On Fri, 2011-09-02 at 23:22 +0200, Michał Mirosław wrote:
>> W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
>> <mirqus@gmail.com> napisał:
>> > 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>> >>>-----Original Message-----
>> >>>From: David Miller [mailto:davem@davemloft.net]
>> >>>Sent: Friday, September 02, 2011 1:55 PM
>> >>>To: Wyborny, Carolyn
>> >>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>> >>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface
>for
>> >>>ethtool application.
>> >>>
>> >>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>> >>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>> >>>
>> >>>> This patch completes the user space implementation of the private
>> >>>> flags inteface in ethtool. Using -b/-B options.
>> >>>>
>> >>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>> >>>
>> >>>The only use case you show here is something generic which other
>> >>>chips have, Energy Efficient Ethernet.
>> >>>
>> >>>Making an attribute private which is present widely amonst various
>> >>>networking chips makes no sense at all.
>> >>>
>> >>>It deserved a generic ethtool flag.
>> >>
>> >> Fair enough on this particular feature, but does that negate the
>implementation suggestion altogether? I can send an updated feature
>implementation for the use case using DMA Coalescing if that will help.
>> > I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
>> > semantics allow easy expanding to handle device-private flags
>without
>> > changing anything on userspace side.
>>
>> BTW, After pending Intel drivers get converted to ndo_set_features and
>> netdev->features get extended to 64 bits, it would also be possible to
>> use some of the unused bits there for device/driver-private flags
>> almost "for free".
>
>I don't really like the idea of mixing common feature flags with
>driver-specific flags. It's likely to lead to confusion if you mix
>devices with different drivers in a bridge or a bond.
>
>Ben.
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
Ok, I'll keep working on it per your previous feedback.
Thanks,
Carolyn
^ permalink raw reply
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Ben Hutchings @ 2011-09-02 21:34 UTC (permalink / raw)
To: Michał Mirosław
Cc: Wyborny, Carolyn, David Miller, netdev@vger.kernel.org
In-Reply-To: <CAHXqBF+9iP6tOmtiaXopGvLyBZvpXmLz05aHj1MrQ2RnAiGGLA@mail.gmail.com>
On Fri, 2011-09-02 at 23:22 +0200, Michał Mirosław wrote:
> W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
> <mirqus@gmail.com> napisał:
> > 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
> >>>-----Original Message-----
> >>>From: David Miller [mailto:davem@davemloft.net]
> >>>Sent: Friday, September 02, 2011 1:55 PM
> >>>To: Wyborny, Carolyn
> >>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
> >>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
> >>>ethtool application.
> >>>
> >>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
> >>>Date: Fri, 2 Sep 2011 13:50:30 -0700
> >>>
> >>>> This patch completes the user space implementation of the private
> >>>> flags inteface in ethtool. Using -b/-B options.
> >>>>
> >>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> >>>
> >>>The only use case you show here is something generic which other
> >>>chips have, Energy Efficient Ethernet.
> >>>
> >>>Making an attribute private which is present widely amonst various
> >>>networking chips makes no sense at all.
> >>>
> >>>It deserved a generic ethtool flag.
> >>
> >> Fair enough on this particular feature, but does that negate the implementation suggestion altogether? I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
> > I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
> > semantics allow easy expanding to handle device-private flags without
> > changing anything on userspace side.
>
> BTW, After pending Intel drivers get converted to ndo_set_features and
> netdev->features get extended to 64 bits, it would also be possible to
> use some of the unused bits there for device/driver-private flags
> almost "for free".
I don't really like the idea of mixing common feature flags with
driver-specific flags. It's likely to lead to confusion if you mix
devices with different drivers in a bridge or a bond.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* RE: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Wyborny, Carolyn @ 2011-09-02 21:33 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1314998831.3419.12.camel@bwh-desktop>
>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>Sent: Friday, September 02, 2011 2:27 PM
>To: Wyborny, Carolyn
>Cc: davem@davemloft.net; netdev@vger.kernel.org
>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>ethtool application.
>
>On Fri, 2011-09-02 at 13:50 -0700, Carolyn Wyborny wrote:
>> This patch completes the user space implementation of the private
>> flags inteface in ethtool. Using -b/-B options.
>[...]
>
>Private flags are supposed to be named (string set ETH_SS_PRIV_FLAGS).
>ethtool should only support getting and setting flags by name, not
>number. That way people can actually remember what the flags do and
>their scripts won't break when the driver changes flag numbers.
>
>Ben.
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
Ok, makes sense. Do you want a private flags implementation or do you agree with Michal on extending ETHTOOL_[GS]FEATURES?
Thanks,
Carolyn
^ permalink raw reply
* Re: [RFC, 2/2] igb: Implementation of ethtool priv_flags for igb driver.
From: Ben Hutchings @ 2011-09-02 21:31 UTC (permalink / raw)
To: Carolyn Wyborny; +Cc: davem, netdev
In-Reply-To: <1314996631-4773-2-git-send-email-carolyn.wyborny@intel.com>
On Fri, 2011-09-02 at 13:50 -0700, Carolyn Wyborny wrote:
> This patch adds igb driver support for the ethtool private flags
> interface. Two features are initially configured for private flags
> support as an example for use with the implementation in ethtoool
> application.
>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> ---
> drivers/net/ethernet/intel/igb/igb.h | 2 +
> drivers/net/ethernet/intel/igb/igb_ethtool.c | 28 ++++++++++++++++++++++++++
> drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> 3 files changed, 31 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
> index bb47ed1..a8be3eb 100644
> --- a/drivers/net/ethernet/intel/igb/igb.h
> +++ b/drivers/net/ethernet/intel/igb/igb.h
> @@ -360,6 +360,7 @@ struct igb_adapter {
> u32 rss_queues;
> u32 wvbr;
> int node;
> + u32 pflags;
> };
>
> #define IGB_FLAG_HAS_MSI (1 << 0)
> @@ -367,6 +368,7 @@ struct igb_adapter {
> #define IGB_FLAG_QUAD_PORT_A (1 << 2)
> #define IGB_FLAG_QUEUE_PAIRS (1 << 3)
> #define IGB_FLAG_DMAC (1 << 4)
> +#define IGB_FLAG_EEE (1 << 5)
>
> /* DMA Coalescing defines */
> #define IGB_MIN_TXPBSIZE 20408
> diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> index 64fb4ef..3a251c7 100644
> --- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
> +++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
> @@ -696,6 +696,9 @@ static void igb_get_drvinfo(struct net_device *netdev,
> drvinfo->testinfo_len = IGB_TEST_LEN;
> drvinfo->regdump_len = igb_get_regs_len(netdev);
> drvinfo->eedump_len = igb_get_eeprom_len(netdev);
> +#ifdef ETHTOOL_GPFLAGS
That macro is always defined,
> + drvinfo->n_priv_flags = 2;
This is not enough. You need to support ETH_SS_PRIV_FLAGS in the
get_sset_count and get_strings operations.
> +#endif
> }
>
> static void igb_get_ringparam(struct net_device *netdev,
> @@ -2171,6 +2174,29 @@ static void igb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
> }
> }
>
> +static int igb_set_pflags(struct net_device *netdev, u32 data)
> +{
> + u32 supported_flags = IGB_FLAG_EEE;
> + struct igb_adapter *adapter = netdev_priv(netdev);
> +
> + if (data & supported_flags) {
[...]
If the number of flags is 2, then the supported flags must be numbered
(1 << 0) and (1 << 1).
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* RE: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Wyborny, Carolyn @ 2011-09-02 21:29 UTC (permalink / raw)
To: Michał Mirosław
Cc: David Miller, bhutchings@solarflare.com, netdev@vger.kernel.org
In-Reply-To: <CAHXqBF+9iP6tOmtiaXopGvLyBZvpXmLz05aHj1MrQ2RnAiGGLA@mail.gmail.com>
>-----Original Message-----
>From: Michał Mirosław [mailto:mirqus@gmail.com]
>Sent: Friday, September 02, 2011 2:22 PM
>To: Wyborny, Carolyn
>Cc: David Miller; bhutchings@solarflare.com; netdev@vger.kernel.org
>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>ethtool application.
>
>W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
><mirqus@gmail.com> napisał:
>> 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>>>>-----Original Message-----
>>>>From: David Miller [mailto:davem@davemloft.net]
>>>>Sent: Friday, September 02, 2011 1:55 PM
>>>>To: Wyborny, Carolyn
>>>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>>>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface
>for
>>>>ethtool application.
>>>>
>>>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>>>>
>>>>> This patch completes the user space implementation of the private
>>>>> flags inteface in ethtool. Using -b/-B options.
>>>>>
>>>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>>>
>>>>The only use case you show here is something generic which other
>>>>chips have, Energy Efficient Ethernet.
>>>>
>>>>Making an attribute private which is present widely amonst various
>>>>networking chips makes no sense at all.
>>>>
>>>>It deserved a generic ethtool flag.
>>>
>>> Fair enough on this particular feature, but does that negate the
>implementation suggestion altogether? I can send an updated feature
>implementation for the use case using DMA Coalescing if that will help.
>> I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
>> semantics allow easy expanding to handle device-private flags without
>> changing anything on userspace side.
>
>BTW, After pending Intel drivers get converted to ndo_set_features and
>netdev->features get extended to 64 bits, it would also be possible to
>use some of the unused bits there for device/driver-private flags
>almost "for free".
>
>Best Regards,
>Michał Mirosław
That seems reasonable as then there would be room for them, but is it going to be OK to use those unused bits or are they going to be intended for generic features and not device specific ones?
Is the intent then to not ever use the priv_flags partial implementation?
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Ben Hutchings @ 2011-09-02 21:27 UTC (permalink / raw)
To: Carolyn Wyborny; +Cc: davem, netdev
In-Reply-To: <1314996631-4773-1-git-send-email-carolyn.wyborny@intel.com>
On Fri, 2011-09-02 at 13:50 -0700, Carolyn Wyborny wrote:
> This patch completes the user space implementation of the private
> flags inteface in ethtool. Using -b/-B options.
[...]
Private flags are supposed to be named (string set ETH_SS_PRIV_FLAGS).
ethtool should only support getting and setting flags by name, not
number. That way people can actually remember what the flags do and
their scripts won't break when the driver changes flag numbers.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Ben Hutchings @ 2011-09-02 21:23 UTC (permalink / raw)
To: David Miller; +Cc: carolyn.wyborny, netdev
In-Reply-To: <20110902.165524.1076389492712310664.davem@davemloft.net>
On Fri, 2011-09-02 at 16:55 -0400, David Miller wrote:
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Date: Fri, 2 Sep 2011 13:50:30 -0700
>
> > This patch completes the user space implementation of the private
> > flags inteface in ethtool. Using -b/-B options.
> >
> > Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
> The only use case you show here is something generic which other
> chips have, Energy Efficient Ethernet.
>
> Making an attribute private which is present widely amonst various
> networking chips makes no sense at all.
>
> It deserved a generic ethtool flag.
I agree.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
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
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Michał Mirosław @ 2011-09-02 21:22 UTC (permalink / raw)
To: Wyborny, Carolyn
Cc: David Miller, bhutchings@solarflare.com, netdev@vger.kernel.org
In-Reply-To: <CAHXqBFKU2m6s1fQzZpJRvvR2HatJpXjWXv84=ZYD5E6OPFfUmQ@mail.gmail.com>
W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
<mirqus@gmail.com> napisał:
> 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>>>-----Original Message-----
>>>From: David Miller [mailto:davem@davemloft.net]
>>>Sent: Friday, September 02, 2011 1:55 PM
>>>To: Wyborny, Carolyn
>>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>>>ethtool application.
>>>
>>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>>>
>>>> This patch completes the user space implementation of the private
>>>> flags inteface in ethtool. Using -b/-B options.
>>>>
>>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>>
>>>The only use case you show here is something generic which other
>>>chips have, Energy Efficient Ethernet.
>>>
>>>Making an attribute private which is present widely amonst various
>>>networking chips makes no sense at all.
>>>
>>>It deserved a generic ethtool flag.
>>
>> Fair enough on this particular feature, but does that negate the implementation suggestion altogether? I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
> I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
> semantics allow easy expanding to handle device-private flags without
> changing anything on userspace side.
BTW, After pending Intel drivers get converted to ndo_set_features and
netdev->features get extended to 64 bits, it would also be possible to
use some of the unused bits there for device/driver-private flags
almost "for free".
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Michał Mirosław @ 2011-09-02 21:17 UTC (permalink / raw)
To: Wyborny, Carolyn
Cc: David Miller, bhutchings@solarflare.com, netdev@vger.kernel.org
In-Reply-To: <EDC0E76513226749BFBC9C3FB031318F0173FF8607@orsmsx508.amr.corp.intel.com>
2011/9/2 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>>-----Original Message-----
>>From: David Miller [mailto:davem@davemloft.net]
>>Sent: Friday, September 02, 2011 1:55 PM
>>To: Wyborny, Carolyn
>>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>>ethtool application.
>>
>>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>>
>>> This patch completes the user space implementation of the private
>>> flags inteface in ethtool. Using -b/-B options.
>>>
>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>>
>>The only use case you show here is something generic which other
>>chips have, Energy Efficient Ethernet.
>>
>>Making an attribute private which is present widely amonst various
>>networking chips makes no sense at all.
>>
>>It deserved a generic ethtool flag.
>
> Fair enough on this particular feature, but does that negate the implementation suggestion altogether? I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
semantics allow easy expanding to handle device-private flags without
changing anything on userspace side.
Best Regards,
Michał Mirosław
^ permalink raw reply
* RE: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Wyborny, Carolyn @ 2011-09-02 21:11 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings@solarflare.com, netdev@vger.kernel.org
In-Reply-To: <20110902.165524.1076389492712310664.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Friday, September 02, 2011 1:55 PM
>To: Wyborny, Carolyn
>Cc: bhutchings@solarflare.com; netdev@vger.kernel.org
>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>ethtool application.
>
>From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>Date: Fri, 2 Sep 2011 13:50:30 -0700
>
>> This patch completes the user space implementation of the private
>> flags inteface in ethtool. Using -b/-B options.
>>
>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
>The only use case you show here is something generic which other
>chips have, Energy Efficient Ethernet.
>
>Making an attribute private which is present widely amonst various
>networking chips makes no sense at all.
>
>It deserved a generic ethtool flag.
Fair enough on this particular feature, but does that negate the implementation suggestion altogether? I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
^ permalink raw reply
* Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: David Miller @ 2011-09-02 20:55 UTC (permalink / raw)
To: carolyn.wyborny; +Cc: bhutchings, netdev
In-Reply-To: <1314996631-4773-1-git-send-email-carolyn.wyborny@intel.com>
From: Carolyn Wyborny <carolyn.wyborny@intel.com>
Date: Fri, 2 Sep 2011 13:50:30 -0700
> This patch completes the user space implementation of the private
> flags inteface in ethtool. Using -b/-B options.
>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
The only use case you show here is something generic which other
chips have, Energy Efficient Ethernet.
Making an attribute private which is present widely amonst various
networking chips makes no sense at all.
It deserved a generic ethtool flag.
^ permalink raw reply
* [RFC, 2/2] igb: Implementation of ethtool priv_flags for igb driver.
From: Carolyn Wyborny @ 2011-09-02 20:50 UTC (permalink / raw)
To: bhutchings, davem; +Cc: netdev
In-Reply-To: <1314996631-4773-1-git-send-email-carolyn.wyborny@intel.com>
This patch adds igb driver support for the ethtool private flags
interface. Two features are initially configured for private flags
support as an example for use with the implementation in ethtoool
application.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
---
drivers/net/ethernet/intel/igb/igb.h | 2 +
drivers/net/ethernet/intel/igb/igb_ethtool.c | 28 ++++++++++++++++++++++++++
drivers/net/ethernet/intel/igb/igb_main.c | 1 +
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index bb47ed1..a8be3eb 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -360,6 +360,7 @@ struct igb_adapter {
u32 rss_queues;
u32 wvbr;
int node;
+ u32 pflags;
};
#define IGB_FLAG_HAS_MSI (1 << 0)
@@ -367,6 +368,7 @@ struct igb_adapter {
#define IGB_FLAG_QUAD_PORT_A (1 << 2)
#define IGB_FLAG_QUEUE_PAIRS (1 << 3)
#define IGB_FLAG_DMAC (1 << 4)
+#define IGB_FLAG_EEE (1 << 5)
/* DMA Coalescing defines */
#define IGB_MIN_TXPBSIZE 20408
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 64fb4ef..3a251c7 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -696,6 +696,9 @@ static void igb_get_drvinfo(struct net_device *netdev,
drvinfo->testinfo_len = IGB_TEST_LEN;
drvinfo->regdump_len = igb_get_regs_len(netdev);
drvinfo->eedump_len = igb_get_eeprom_len(netdev);
+#ifdef ETHTOOL_GPFLAGS
+ drvinfo->n_priv_flags = 2;
+#endif
}
static void igb_get_ringparam(struct net_device *netdev,
@@ -2171,6 +2174,29 @@ static void igb_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
}
}
+static int igb_set_pflags(struct net_device *netdev, u32 data)
+{
+ u32 supported_flags = IGB_FLAG_EEE;
+ struct igb_adapter *adapter = netdev_priv(netdev);
+
+ if (data & supported_flags) {
+ adapter->pflags = data;
+ } else {
+ printk(KERN_INFO, "set_pflags:flag not supported..");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static u32 igb_get_pflags(struct net_device *netdev)
+{
+ struct igb_adapter *adapter = netdev_priv(netdev);
+
+ return adapter->pflags;
+
+}
+
static const struct ethtool_ops igb_ethtool_ops = {
.get_settings = igb_get_settings,
.set_settings = igb_set_settings,
@@ -2197,6 +2223,8 @@ static const struct ethtool_ops igb_ethtool_ops = {
.get_ethtool_stats = igb_get_ethtool_stats,
.get_coalesce = igb_get_coalesce,
.set_coalesce = igb_set_coalesce,
+ .get_priv_flags = igb_get_pflags,
+ .set_priv_flags = igb_set_pflags,
};
void igb_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 289861c..a534f32 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2175,6 +2175,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
switch (hw->mac.type) {
case e1000_i350:
igb_set_eee_i350(hw);
+ adapter->pflags |= IGB_FLAG_EEE;
break;
default:
break;
--
1.7.4.4
^ permalink raw reply related
* [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.
From: Carolyn Wyborny @ 2011-09-02 20:50 UTC (permalink / raw)
To: bhutchings, davem; +Cc: netdev
This patch completes the user space implementation of the private
flags inteface in ethtool. Using -b/-B options.
Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
---
ethtool.8.in | 16 +++++++++
ethtool.c | 98 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 113 insertions(+), 1 deletions(-)
diff --git a/ethtool.8.in b/ethtool.8.in
index 7a0bd43..ebcb233 100644
--- a/ethtool.8.in
+++ b/ethtool.8.in
@@ -134,6 +134,13 @@ ethtool \- query or control network driver and hardware settings
.B2 rx on off
.B2 tx on off
.HP
+.B ethtool \-b|\-\-show\-priv\-flags
+.I ethX
+.HP
+.B ethtool \-B|\-\-set\-priv\-flags
+.I ethX
+.BN bit
+.HP
.B ethtool \-c|\-\-show\-coalesce
.I ethX
.HP
@@ -342,6 +349,15 @@ Specifies whether RX pause should be enabled.
.A2 tx on off
Specifies whether TX pause should be enabled.
.TP
+.B \-b \-\-show\-priv_flags
+Queries the specified network device for private flags set.
+.TP
+.B \-B \-\-set\-priv_flags
+Changes the private flags of the specified network device.
+.TP
+.BI bit \ N
+Sets the specific bit number in the private flagsg field.
+.TP
.B \-c \-\-show\-coalesce
Queries the specified network device for coalescing information.
.TP
diff --git a/ethtool.c b/ethtool.c
index 943dfb7..4702d04 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -99,6 +99,8 @@ static int do_flash(int fd, struct ifreq *ifr);
static int do_permaddr(int fd, struct ifreq *ifr);
static int do_getfwdump(int fd, struct ifreq *ifr);
static int do_setfwdump(int fd, struct ifreq *ifr);
+static int do_gpflags(int fd, struct ifreq *ifr);
+static int do_spflags(int fd, struct ifreq *ifr);
static int send_ioctl(int fd, struct ifreq *ifr);
@@ -133,6 +135,8 @@ static enum {
MODE_PERMADDR,
MODE_SET_DUMP,
MODE_GET_DUMP,
+ MODE_GET_PFLAGS,
+ MODE_SET_PFLAGS,
} mode = MODE_GSET;
static struct option {
@@ -157,6 +161,9 @@ static struct option {
" [ autoneg on|off ]\n"
" [ rx on|off ]\n"
" [ tx on|off ]\n" },
+ { "-b", "--show-pflags", MODE_GET_PFLAGS, "Show private flags set." },
+ { "-B", "--set-pflags", MODE_SET_PFLAGS, "Set private flags.",
+ " [value N | bit N]\n" },
{ "-c", "--show-coalesce", MODE_GCOALESCE, "Show coalesce options" },
{ "-C", "--coalesce", MODE_SCOALESCE, "Set coalesce options",
" [adaptive-rx on|off]\n"
@@ -405,6 +412,11 @@ static int rx_class_rule_del = -1;
static int rx_class_rule_added = 0;
static struct ethtool_rx_flow_spec rx_rule_fs;
+static u32 priv_flags;
+static int priv_flags_changed;
+static u32 priv_flags_val_wanted;
+static u8 priv_flags_bit_wanted;
+
static enum {
ONLINE=0,
OFFLINE,
@@ -552,6 +564,10 @@ static struct cmdline_info cmdline_msglvl[] = {
NETIF_MSG_WOL, &msglvl_mask },
};
+static struct cmdline_info cmdline_pflags[] = {
+ { "value", CMDL_U32, &priv_flags_val_wanted, &priv_flags },
+};
+
static long long
get_int_range(char *str, int base, long long min, long long max)
{
@@ -800,7 +816,9 @@ static void parse_cmdline(int argc, char **argp)
(mode == MODE_FLASHDEV) ||
(mode == MODE_PERMADDR) ||
(mode == MODE_SET_DUMP) ||
- (mode == MODE_GET_DUMP)) {
+ (mode == MODE_GET_DUMP) ||
+ (mode == MODE_GET_PFLAGS) ||
+ (mode == MODE_SET_PFLAGS)) {
devname = argp[i];
break;
}
@@ -884,6 +902,28 @@ static void parse_cmdline(int argc, char **argp)
i = argc;
break;
}
+ if (mode == MODE_SET_PFLAGS) {
+ if (!strcmp(argp[i], "value")) {
+ priv_flags_changed = 1;
+ i++;
+ if (i >= argc)
+ exit_bad_args();
+ priv_flags_val_wanted =
+ get_u32(argp[i], 0);
+ } else if (!strcmp(argp[i], "bit")) {
+ priv_flags_changed = 1;
+ i++;
+ if (i >= argc)
+ exit_bad_args();
+ priv_flags_bit_wanted =
+ get_int(argp[i], 0);
+ priv_flags_val_wanted =
+ (1 >> priv_flags_bit_wanted);
+ } else
+ exit_bad_args();
+ i = argc;
+ break;
+ }
if (mode == MODE_SCLSRULE) {
if (!strcmp(argp[i], "flow-type")) {
i += 1;
@@ -1957,6 +1997,10 @@ static int doit(void)
return do_getfwdump(fd, &ifr);
} else if (mode == MODE_SET_DUMP) {
return do_setfwdump(fd, &ifr);
+ } else if (mode == MODE_GET_PFLAGS) {
+ return do_gpflags(fd, &ifr);
+ } else if (mode == MODE_SET_PFLAGS) {
+ return do_spflags(fd, &ifr);
}
return 69;
@@ -3346,6 +3390,58 @@ static int do_setfwdump(int fd, struct ifreq *ifr)
return 0;
}
+static int do_gpflags(int fd, struct ifreq *ifr)
+{
+ int err;
+ struct ethtool_value eval;
+
+ eval.cmd = ETHTOOL_GPFLAGS;
+ ifr->ifr_data = (caddr_t)&eval;
+ err = send_ioctl(fd, ifr);
+ if (err) {
+ perror("Cannot get device private flags");
+ } else {
+ fprintf(stdout, " Current flags set: 0x%08x (%d)\n"
+ " ",
+ eval.data, eval.data);
+ print_flags(cmdline_pflags, ARRAY_SIZE(cmdline_pflags),
+ eval.data);
+ fprintf(stdout, "\n");
+ }
+ return err;
+}
+
+static int do_spflags(int fd, struct ifreq *ifr)
+{
+ struct ethtool_value eval;
+ int err, changed = 0;
+ eval.cmd = ETHTOOL_GPFLAGS;
+ ifr->ifr_data = (caddr_t)&eval;
+ err = send_ioctl(fd, ifr);
+ if (err) {
+ perror("Cannot get device private flags");
+ return err;
+ }
+
+ priv_flags = eval.data;
+ do_generic_set(cmdline_pflags, ARRAY_SIZE(cmdline_pflags),
+ &changed);
+ if (!changed) {
+ fprintf(stderr, "No private flags have changed, aborting\n");
+ return 1;
+ } else {
+ eval.cmd = ETHTOOL_SPFLAGS;
+ eval.data = priv_flags_val_wanted;
+ ifr->ifr_data = (caddr_t)&eval;
+ err = send_ioctl(fd, ifr);
+ if (err) {
+ perror("Cannot set device private flags.\n");
+ return err;
+ }
+ return 0;
+ }
+}
+
static int send_ioctl(int fd, struct ifreq *ifr)
{
return ioctl(fd, SIOCETHTOOL, ifr);
--
1.7.4.4
^ permalink raw reply related
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