* Re: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree
From: Ben Hutchings @ 2014-01-19 15:34 UTC (permalink / raw)
To: Matthew Garrett; +Cc: netdev, devicetree, linux-kernel, kishon
In-Reply-To: <1389999459-9483-1-git-send-email-matthew.garrett@nebula.com>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Fri, 2014-01-17 at 17:57 -0500, Matthew Garrett wrote:
> Some hardware may be broken in interesting and board-specific ways, such
> that various bits of functionality don't work. This patch provides a
> mechanism for overriding mii registers during init based on the contents of
> the device tree data, allowing board-specific fixups without having to
> pollute generic code.
[...]
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -23,6 +23,21 @@ Optional Properties:
> assume clause 22. The compatible list may also contain other
> elements.
>
> +The following properties may be added to either the phy node or the parent
> +ethernet device. If not present, the hardware defaults will be used.
> +
> +- phy-mii-advertise-10half: 1 to advertise half-duplex 10MBit, 0 to disable
> +- phy-mii-advertise-10full: 1 to advertise full-duplex 10MBit, 0 to disable
> +- phy-mii-advertise-100half: 1 to advertise half-duplex 100MBit, 0 to disable
> +- phy-mii-advertise-100full: 1 to advertise full-duplex 100MBit, 0 to disable
> +- phy-mii-advertise-100base4: 1 to advertise 100base4, 0 to disable
> +- phy-mii-advertise-1000half: 1 to advertise half-duplex 1000MBit, 0 to disable
> +- phy-mii-advertise-1000full: 1 to advertise full-duplex 1000MBit, 0 to disable
Are these really all needed? Apparently there is a standard 'max-speed'
property on Ethernet devices already, which I think is probably
sufficient to express the actual restrictions of some boards.
> +- phy-mii-manual-master: 1 to enable manual master/slave configuration, 0
> + to disable manual master/slave configuration
[...]
Although the standard calls this 'manual', if it's set in the DT it
won't really be a manual setting. The description should probably
clarify that.
I think the name should include 'master-slave' or 'clock-role' rather
than just 'master', as currently it suggests only the master role can be
forced.
Ben.
--
Ben Hutchings
friends: People who know you well, but like you anyway.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH v4 net-next 3/3] ipv6: add flowlabel_consistency sysctl
From: Hannes Frederic Sowa @ 2014-01-19 15:24 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-3-git-send-email-florent.fourcot@enst-bretagne.fr>
On Fri, Jan 17, 2014 at 05:15:05PM +0100, Florent Fourcot wrote:
> With the introduction of IPV6_FL_F_REFLECT, there is no guarantee of
> flow label unicity. This patch introduces a new sysctl to protect the old
> behaviour, enable by default.
>
> Changelog of V3:
> * rename ip6_flowlabel_consistency to flowlabel_consistency
> * use net_info_ratelimited()
> * checkpatch cleanups
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Also ok, thanks!
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH V4 net-next 2/3] ipv6: add a flag to get the flow label used remotly
From: Hannes Frederic Sowa @ 2014-01-19 15:23 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-2-git-send-email-florent.fourcot@enst-bretagne.fr>
On Fri, Jan 17, 2014 at 05:15:04PM +0100, Florent Fourcot wrote:
> This information is already available via IPV6_FLOWINFO
> of IPV6_2292PKTOPTIONS, and them a filtering to get the flow label
> information. But it is probably logical and easier for users to add this
> here, and to control both sent/received flow label values with the
> IPV6_FLOWLABEL_MGR option.
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Looks good.
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
^ permalink raw reply
* Re: [PATCH V4 net-next 1/3] ipv6: add the IPV6_FL_F_REFLECT flag to IPV6_FL_A_GET
From: Hannes Frederic Sowa @ 2014-01-19 14:57 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1389975305-12477-1-git-send-email-florent.fourcot@enst-bretagne.fr>
On Fri, Jan 17, 2014 at 05:15:03PM +0100, Florent Fourcot wrote:
> With this option, the socket will reply with the flow label value read
> on received packets.
>
> The goal is to have a connection with the same flow label in both
> direction of the communication.
>
> Changelog of V4:
> * Do not erase the flow label on the listening socket. Use pktopts to
> store the received value
This approach looks good!
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v3 1/3] random32: add prandom_u32_max and convert open coded users
From: Tilman Schmidt @ 2014-01-19 13:41 UTC (permalink / raw)
To: Daniel Borkmann
Cc: davem, hannes, netdev, Jakub Zawadzki, Eric Dumazet, linux-kernel
In-Reply-To: <1390088431-28657-2-git-send-email-dborkman@redhat.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 19.01.2014 00:40, schrieb Daniel Borkmann:
> @@ -38,6 +37,23 @@ struct rnd_state { u32 prandom_u32_state(struct
> rnd_state *state); void prandom_bytes_state(struct rnd_state
> *state, void *buf, int nbytes);
>
> +/** + * prandom_u32_max - returns a pseduo-random number in
> interval [0, ep_ro) + * @ep_ro: right open interval endpoint + * +
> * Returns a pseduo-random number that is in interval [0, ep_ro).
> Note + * that the result depends on PRNG being well distributed in
> [0, ~0U] + * u32 space. Here we use maximally equidistributed
> combined Tausworthe + * generator, that is, prandom_u32(). This is
> useful when requesting a + * random index of an array containing
> ep_ro elements, for example. + * + * Returns: pseduo-random number
> in interval [0, ep_ro) + */
The word "pseudo" is consistently mistyped as "pseduo" in this comment.
(Three occurrences.) You may want to correct this before it gets merged.
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLb1hAACgkQQ3+did9BuFt4gACeMe9m893fMIapXiZ/AC7BERai
E/cAmgI6r1Uf1EE8reLA6nqd3T/FGWt6
=5qOJ
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH net v2] tcp: delete redundant calls of tcp_mtup_init()
From: Weiping Pan @ 2014-01-19 12:44 UTC (permalink / raw)
To: davem, netdev; +Cc: Weiping Pan
In-Reply-To: <20140114.164105.524133214769947013.davem@davemloft.net>
As tcp_rcv_state_process() has already calls tcp_mtup_init() for non-fastopen
sock, we can delete the redundant calls of tcp_mtup_init() in
tcp_{v4,v6}_syn_recv_sock().
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
net/ipv4/tcp_ipv4.c | 1 -
net/ipv6/tcp_ipv6.c | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 0672139..4176606 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1668,7 +1668,6 @@ struct sock *tcp_v4_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
}
sk_setup_caps(newsk, dst);
- tcp_mtup_init(newsk);
tcp_sync_mss(newsk, dst_mtu(dst));
newtp->advmss = dst_metric_advmss(dst);
if (tcp_sk(sk)->rx_opt.user_mss &&
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index f67033b..c5b0e1f 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1230,7 +1230,6 @@ static struct sock * tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
inet_csk(newsk)->icsk_ext_hdr_len = (newnp->opt->opt_nflen +
newnp->opt->opt_flen);
- tcp_mtup_init(newsk);
tcp_sync_mss(newsk, dst_mtu(dst));
newtp->advmss = dst_metric_advmss(dst);
if (tcp_sk(sk)->rx_opt.user_mss &&
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next] packet: fix a couple of cppcheck warnings
From: Daniel Borkmann @ 2014-01-19 10:46 UTC (permalink / raw)
To: davem; +Cc: netdev
Doesn't bring much, but also doesn't hurt us to fix 'em:
1) In tpacket_rcv() flush dcache page we can restirct the scope
for start and end and remove one layer of indent.
2) In tpacket_destruct_skb() we can restirct the scope for ph.
3) In alloc_one_pg_vec_page() we can remove the NULL assignment
and change spacing a bit.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/packet/af_packet.c | 37 +++++++++++++++----------------------
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 12f2f72..aecae1b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -2009,19 +2009,20 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
sll->sll_ifindex = dev->ifindex;
smp_mb();
+
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE == 1
- {
+ if (po->tp_version <= TPACKET_V2) {
u8 *start, *end;
- if (po->tp_version <= TPACKET_V2) {
- end = (u8 *)PAGE_ALIGN((unsigned long)h.raw
- + macoff + snaplen);
- for (start = h.raw; start < end; start += PAGE_SIZE)
- flush_dcache_page(pgv_to_page(start));
- }
- smp_wmb();
+ end = (u8 *) PAGE_ALIGN((unsigned long) h.raw +
+ macoff + snaplen);
+
+ for (start = h.raw; start < end; start += PAGE_SIZE)
+ flush_dcache_page(pgv_to_page(start));
}
+ smp_wmb();
#endif
+
if (po->tp_version <= TPACKET_V2)
__packet_set_status(po, h.raw, status);
else
@@ -2050,9 +2051,9 @@ ring_is_full:
static void tpacket_destruct_skb(struct sk_buff *skb)
{
struct packet_sock *po = pkt_sk(skb->sk);
- void *ph;
if (likely(po->tx_ring.pg_vec)) {
+ void *ph;
__u32 ts;
ph = skb_shinfo(skb)->destructor_arg;
@@ -3648,34 +3649,26 @@ static void free_pg_vec(struct pgv *pg_vec, unsigned int order,
static char *alloc_one_pg_vec_page(unsigned long order)
{
- char *buffer = NULL;
+ char *buffer;
gfp_t gfp_flags = GFP_KERNEL | __GFP_COMP |
__GFP_ZERO | __GFP_NOWARN | __GFP_NORETRY;
buffer = (char *) __get_free_pages(gfp_flags, order);
-
if (buffer)
return buffer;
- /*
- * __get_free_pages failed, fall back to vmalloc
- */
+ /* __get_free_pages failed, fall back to vmalloc */
buffer = vzalloc((1 << order) * PAGE_SIZE);
-
if (buffer)
return buffer;
- /*
- * vmalloc failed, lets dig into swap here
- */
+ /* vmalloc failed, lets dig into swap here */
gfp_flags &= ~__GFP_NORETRY;
- buffer = (char *)__get_free_pages(gfp_flags, order);
+ buffer = (char *) __get_free_pages(gfp_flags, order);
if (buffer)
return buffer;
- /*
- * complete and utter failure
- */
+ /* complete and utter failure */
return NULL;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net] net: core: orphan frags before queuing to slow qdisc
From: Michael S. Tsirkin @ 2014-01-19 9:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jason Wang, davem, netdev, linux-kernel
In-Reply-To: <1389968897.31367.489.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Jan 17, 2014 at 06:28:17AM -0800, Eric Dumazet wrote:
> On Fri, 2014-01-17 at 17:42 +0800, Jason Wang wrote:
> > Many qdiscs can queue a packet for a long time, this will lead an issue
> > with zerocopy skb. It means the frags will not be orphaned in an expected
> > short time, this breaks the assumption that virtio-net will transmit the
> > packet in time.
> >
> > So if guest packets were queued through such kind of qdisc and hit the
> > limitation of the max pending packets for virtio/vhost. All packets that
> > go to another destination from guest will also be blocked.
> >
> > A case for reproducing the issue:
> >
> > - Boot two VMs and connect them to the same bridge kvmbr.
> > - Setup tbf with a very low rate/burst on eth0 which is a port of kvmbr.
> > - Let VM1 send lots of packets thorugh eth0
> > - After a while, VM1 is unable to send any packets out since the number of
> > pending packets (queued to tbf) were exceeds the limitation of vhost/virito
>
> So whats the problem ? If the limit is low, you cannot sent packets.
I think this isn't the main problem.
Say VM1 is using tap1 and VM2 uses tap2, all connected to
same bridge.
Set up tbf on tap2 and have VM1 send packets to VM2.
VM1 will get blocked and won't be able to talk to
host or eth0 for a long while, even though the path
from VM1 to host is idle.
The problem should appear with both zerocopy or with
TUNSETSNDBUF used to set sndbuf to a finite value.
> Solution : increase the limit, or tell the vm to lower its rate.
The issue is that different links can have different policies.
A VM that's unable to talk to host
even though the path from this VM to the host is
completely idle because some other VM's RX -
which it used to talk to in the past - is throttled violates
the principle of least surprise.
>
> Oh wait, are you bitten because you did some prior skb_orphan() to allow
> the vm to send unlimited number of skbs ???
I think it's because the limit on number
of skbs per VM is INT_MAX by default, in any case -
for compatibility reasons.
Further, e.g. QEMU also had to stop using
TUNSETSNDBUF because of these issues.
It would be nice to fix this, yes.
> >
> > Solve this issue by orphaning the frags before queuing it to a slow qdisc (the
> > one without TCQ_F_CAN_BYPASS).
>
> Why orphaning the frags only solves the problem ? A skb without zerocopy
> frags should also be blocked for a while.
I agree that if we want to fix behaviour for limited sndbuf,
we have to orphan everything queued on tbf,
possibly only if it's limit is set very low.
Do you think it's reasonable?
>
> Seriously, lets admit this zero copy stuff is utterly broken.
>
zero copy is simply newer, we didn't have compatibility to
worry about so we set a finite limit there by default.
As you point out the problem isn't specific to zero copy,
it's happening whenever we try to limit # of skbs.
So do you think the idea of limiting skbs is utterly
broken, and we should just let it rip as fast as it can?
> TCQ_F_CAN_BYPASS is not enough. Some NIC have separate queues with
> strict priorities.
>
> It seems to me that you are pushing to use FIFO (the only qdisc setting
> TCQ_F_CAN_BYPASS), by adding yet another test in fast path (I do not
> know how we can still call it a fast path), while we already have smart
> qdisc to avoid the inherent HOL and unfairness problems of FIFO.
TCQ_F_CAN_BYPASS doesn't look like a good idea to me either.
I think the biggest problem is with tbf because it's not
work-conserving, so a link can get
throttled even in system which is mostly idle.
> >
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> > net/core/dev.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 0ce469e..1209774 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -2700,6 +2700,12 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> > contended = qdisc_is_running(q);
> > if (unlikely(contended))
> > spin_lock(&q->busylock);
> > + if (!(q->flags & TCQ_F_CAN_BYPASS) &&
> > + unlikely(skb_orphan_frags(skb, GFP_ATOMIC))) {
> > + kfree_skb(skb);
> > + rc = NET_XMIT_DROP;
> > + goto out;
> > + }
>
> Are you aware that copying stuff takes time ?
>
> If yes, why is it done after taking the busylock spinlock ?
>
> >
> > spin_lock(root_lock);
> > if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
> > @@ -2739,6 +2745,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> > }
> > }
> > spin_unlock(root_lock);
> > +out:
> > if (unlikely(contended))
> > spin_unlock(&q->busylock);
> > return rc;
>
>
^ permalink raw reply
* Re: [PATCH linux-next] net: batman-adv: use "__packed __aligned(2)" for each structure instead of "__packed(2)" region
From: Chen Gang @ 2014-01-19 9:51 UTC (permalink / raw)
To: Antonio Quartulli
Cc: James Hogan, David Miller, mareklindner, sw, b.a.t.m.a.n, netdev,
linux-kernel@vger.kernel.org, linux-metag, Dan Carpenter, Greg KH
In-Reply-To: <52DB9B39.9090502@meshcoding.com>
On 01/19/2014 05:30 PM, Antonio Quartulli wrote:
> On 19/01/14 02:10, James Hogan wrote:
>>
>> It appears that the following gcc patch adds support for #pragma pack:
>> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01115.html
>>
>> I gave it a quick spin on metag gcc (which is unfortunately stuck on an old
>> version) and it seems to fix my simple test case so that #pragma pack(2)
>> becomes equivalent to __packed __aligned(2) (for sizeof and __alignof__).
>>
>
> Then I personally think that it is better to fix metag gcc instead of
> changing the kernel.
>
> Actually there are many different spots where "#pragma pack" is used.
> batman-adv is just the only one having compile time checks for structure
> sizes.
>
What Antonio said sounds reasonable to me.
>>
>> However, the __packed and __aligned are linux specific macros to abstract
>> compiler details, whereas #pragma pack appears to be a compiler-specific WIN32
>> style equivalent to GCC's __attribute__((packed)) and
>> __attribute__((aligned(2))) (these are what __packed and __aligned use in
>> compiler-gcc.h).
>>
>> Therefore I believe using the Linux abstractions is still more correct here.
>
> If you really think so, I'd suggest to grep in the kernel and catch all
> the other occurrences of "#pragma pack" and change them all (assuming
> that using __attribute__((aligned(2))) is the way to go).
>
Thanks.
--
Chen Gang
Open, share and attitude like air, water and life which God blessed
^ permalink raw reply
* Re: [PATCH linux-next] net: batman-adv: use "__packed __aligned(2)" for each structure instead of "__packed(2)" region
From: Antonio Quartulli @ 2014-01-19 9:30 UTC (permalink / raw)
To: James Hogan
Cc: mareklindner-rVWd3aGhH2z5bpWLKbzFeg, netdev,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-metag-u79uwXL29TY76Z2rM5mHXA, David Miller, Chen Gang
In-Reply-To: <4915262.qEFumRrH4p@radagast>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On 19/01/14 02:10, James Hogan wrote:
>
> It appears that the following gcc patch adds support for #pragma pack:
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01115.html
>
> I gave it a quick spin on metag gcc (which is unfortunately stuck on an old
> version) and it seems to fix my simple test case so that #pragma pack(2)
> becomes equivalent to __packed __aligned(2) (for sizeof and __alignof__).
>
Then I personally think that it is better to fix metag gcc instead of
changing the kernel.
Actually there are many different spots where "#pragma pack" is used.
batman-adv is just the only one having compile time checks for structure
sizes.
>
> However, the __packed and __aligned are linux specific macros to abstract
> compiler details, whereas #pragma pack appears to be a compiler-specific WIN32
> style equivalent to GCC's __attribute__((packed)) and
> __attribute__((aligned(2))) (these are what __packed and __aligned use in
> compiler-gcc.h).
>
> Therefore I believe using the Linux abstractions is still more correct here.
If you really think so, I'd suggest to grep in the kernel and catch all
the other occurrences of "#pragma pack" and change them all (assuming
that using __attribute__((aligned(2))) is the way to go).
Cheers,
--
Antonio Quartulli
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net] net: core: orphan frags before queuing to slow qdisc
From: Michael S. Tsirkin @ 2014-01-19 9:21 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1389951734-13234-1-git-send-email-jasowang@redhat.com>
On Fri, Jan 17, 2014 at 05:42:14PM +0800, Jason Wang wrote:
> Many qdiscs can queue a packet for a long time, this will lead an issue
> with zerocopy skb. It means the frags will not be orphaned in an expected
> short time, this breaks the assumption that virtio-net will transmit the
> packet in time.
>
> So if guest packets were queued through such kind of qdisc and hit the
> limitation of the max pending packets for virtio/vhost. All packets that
> go to another destination from guest will also be blocked.
>
> A case for reproducing the issue:
>
> - Boot two VMs and connect them to the same bridge kvmbr.
> - Setup tbf with a very low rate/burst on eth0 which is a port of kvmbr.
> - Let VM1 send lots of packets thorugh eth0
> - After a while, VM1 is unable to send any packets out since the number of
> pending packets (queued to tbf) were exceeds the limitation of vhost/virito
>
> Solve this issue by orphaning the frags before queuing it to a slow qdisc (the
> one without TCQ_F_CAN_BYPASS).
This seems too aggressive to me.
The issue is that packet can stay queued indefinitely long.
So I think we should only do this for tbf.
>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> net/core/dev.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0ce469e..1209774 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2700,6 +2700,12 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> contended = qdisc_is_running(q);
> if (unlikely(contended))
> spin_lock(&q->busylock);
> + if (!(q->flags & TCQ_F_CAN_BYPASS) &&
> + unlikely(skb_orphan_frags(skb, GFP_ATOMIC))) {
> + kfree_skb(skb);
> + rc = NET_XMIT_DROP;
> + goto out;
> + }
>
> spin_lock(root_lock);
> if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
> @@ -2739,6 +2745,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
> }
> }
> spin_unlock(root_lock);
> +out:
> if (unlikely(contended))
> spin_unlock(&q->busylock);
> return rc;
> --
> 1.8.3.2
^ permalink raw reply
* [PATCH v2] ipv4: remove the useless argument from ip_tunnel_hash()
From: Duan Jiong @ 2014-01-19 8:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Since commit c544193214("GRE: Refactor GRE tunneling code")
introduced function ip_tunnel_hash(), the argument itn is no
longer in use, so remove it.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
v2: specify the commit's summary line in parens
net/ipv4/ip_tunnel.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index d3929a6..6f5a347 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -61,8 +61,7 @@
#include <net/ip6_route.h>
#endif
-static unsigned int ip_tunnel_hash(struct ip_tunnel_net *itn,
- __be32 key, __be32 remote)
+static unsigned int ip_tunnel_hash(__be32 key, __be32 remote)
{
return hash_32((__force u32)key ^ (__force u32)remote,
IP_TNL_HASH_BITS);
@@ -204,7 +203,7 @@ struct ip_tunnel *ip_tunnel_lookup(struct ip_tunnel_net *itn,
struct ip_tunnel *t, *cand = NULL;
struct hlist_head *head;
- hash = ip_tunnel_hash(itn, key, remote);
+ hash = ip_tunnel_hash(key, remote);
head = &itn->tunnels[hash];
hlist_for_each_entry_rcu(t, head, hash_node) {
@@ -236,7 +235,7 @@ struct ip_tunnel *ip_tunnel_lookup(struct ip_tunnel_net *itn,
cand = t;
}
- hash = ip_tunnel_hash(itn, key, 0);
+ hash = ip_tunnel_hash(key, 0);
head = &itn->tunnels[hash];
hlist_for_each_entry_rcu(t, head, hash_node) {
@@ -292,7 +291,7 @@ static struct hlist_head *ip_bucket(struct ip_tunnel_net *itn,
else
remote = 0;
- h = ip_tunnel_hash(itn, parms->i_key, remote);
+ h = ip_tunnel_hash(parms->i_key, remote);
return &itn->tunnels[h];
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] net: gre: don't pull skb if dealing with icmp message
From: Duan Jiong @ 2014-01-19 8:35 UTC (permalink / raw)
To: David Miller; +Cc: Daniel Borkmann, netdev
When dealing with icmp messages, the skb->data points the
ip header that triggered the sending of the icmp message.
In gre_cisco_err(), the parse_gre_header() is called, and the
iptunnel_pull_header() is called to pull the skb at the end of
the parse_gre_header(). Unfortunately, the ipgre_err still needs
the skb->data points the ip header following the icmp layer,
and those ip addresses in ip header will be used to look up
tunnel by ip_tunnel_lookup().
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
---
net/ipv4/gre_demux.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/gre_demux.c b/net/ipv4/gre_demux.c
index 5893e99..35bfba4 100644
--- a/net/ipv4/gre_demux.c
+++ b/net/ipv4/gre_demux.c
@@ -116,7 +116,7 @@ static __sum16 check_checksum(struct sk_buff *skb)
}
static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
- bool *csum_err)
+ bool *csum_err, bool in_err)
{
unsigned int ip_hlen = ip_hdrlen(skb);
const struct gre_base_hdr *greh;
@@ -160,6 +160,9 @@ static int parse_gre_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
} else
tpi->seq = 0;
+ if (in_err)
+ return 0;
+
/* WCCP version 1 and 2 protocol decoding.
* - Change protocol to IP
* - When dealing with WCCPv2, Skip extra 4 bytes in GRE header
@@ -182,7 +185,7 @@ static int gre_cisco_rcv(struct sk_buff *skb)
int i;
bool csum_err = false;
- if (parse_gre_header(skb, &tpi, &csum_err) < 0)
+ if (parse_gre_header(skb, &tpi, &csum_err, false) < 0)
goto drop;
rcu_read_lock();
@@ -229,7 +232,7 @@ static void gre_cisco_err(struct sk_buff *skb, u32 info)
bool csum_err = false;
int i;
- if (parse_gre_header(skb, &tpi, &csum_err)) {
+ if (parse_gre_header(skb, &tpi, &csum_err, true)) {
if (!csum_err) /* ignore csum errors. */
return;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [ PATCH net-next] qlcnic: fix sparse warnings
From: David Miller @ 2014-01-19 7:09 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20140118172113.16adb69f@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sat, 18 Jan 2014 17:21:13 -0800
> From: Fengguang Wu <fengguang.wu@intel.com>
>
> Previous patch changed prototypes, but forgot functions.
>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
>
> ---
> qlcnic_83xx_hw.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-18 13:41:07.000000000 -0800
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-18 17:13:08.640658697 -0800
> @@ -2066,7 +2066,7 @@ void qlcnic_83xx_change_l2_filter(struct
> qlcnic_83xx_sre_macaddr_change(adapter, mac, vlan_id, QLCNIC_MAC_ADD);
> }
>
> -void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
> +static void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
> u8 type, struct qlcnic_cmd_args *cmd)
Please adjust argument indentation, this goes for the whole patch.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: be friend with drop monitor
From: David Miller @ 2014-01-19 7:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1390098469.27806.3.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 18 Jan 2014 18:27:49 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Replace some dev_kfree_skb() with kfree_skb() calls when
> we drop one skb, this might help bug tracking.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: add build-time checks for msg->msg_name size
From: David Miller @ 2014-01-19 7:04 UTC (permalink / raw)
To: steffen; +Cc: netdev, hannes
In-Reply-To: <20140117215314.GC7562@noise.didjital.de>
From: Steffen Hurrle <steffen@hurrle.net>
Date: Fri, 17 Jan 2014 22:53:15 +0100
> This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
> handler msg_name and msg_namelen logic").
>
> DECLARE_SOCKADDR validates that the structure we use for writing the
> name information to is not larger than the buffer which is reserved
> for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
> consistently in sendmsg code paths.
>
> Signed-off-by: Steffen Hurrle <steffen@hurrle.net>
> Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Looks great, applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next] bonding: move the netdev_add_tso_features() to bonding module
From: Ding Tianhong @ 2014-01-19 5:34 UTC (permalink / raw)
To: Eric Dumazet, Veaceslav Falico
Cc: Jay Vosburgh, Eric Dumazet, David S. Miller, Netdev
In-Reply-To: <1390064923.31367.531.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014/1/19 1:08, Eric Dumazet wrote:
> On Sat, 2014-01-18 at 12:48 +0100, Veaceslav Falico wrote:
>> On Sat, Jan 18, 2014 at 04:31:33PM +0800, Ding Tianhong wrote:
>>> The function netdev_add_tso_features() was only be used for bonding,
>>> so no need to export it in netdevice.h, move it to bonding module.
>>
>> Eric added it for a reason - like, other drivers might use it. Do you know
>> if team, bridge, vlan etc. might use it?
>
> A helper can be used once, this is fine. A car can have 4 seats, and can
> even be used with no passenger.
>
> I am quite bored by patches that break clean layering for wrong reasons.
>
>
> static inline netdev_features_t netdev_add_tso_features(netdev_features_t features,
> netdev_features_t mask)
> {
> return netdev_increment_features(features, NETIF_F_ALL_TSO, mask);
> }
>
> There is _nothing_ in this helper that implies it should be private to bonding.
>
>
yep, it is look so fool that my patch said, thanks for reminding me.
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v3] net: introduce SO_BPF_EXTENSIONS
From: David Miller @ 2014-01-19 3:09 UTC (permalink / raw)
To: msekleta; +Cc: netdev
In-Reply-To: <1389974985-21160-1-git-send-email-msekleta@redhat.com>
From: Michal Sekletar <msekleta@redhat.com>
Date: Fri, 17 Jan 2014 17:09:45 +0100
> For user space packet capturing libraries such as libpcap, there's
> currently only one way to check which BPF extensions are supported
> by the kernel, that is, commit aa1113d9f85d ("net: filter: return
> -EINVAL if BPF_S_ANC* operation is not supported"). For querying all
> extensions at once this might be rather inconvenient.
>
> Therefore, this patch introduces a new option which can be used as
> an argument for getsockopt(), and allows one to obtain information
> about which BPF extensions are supported by the current kernel.
>
> As David Miller suggests, we do not need to define any bits right
> now and status quo can just return 0 in order to state that this
> versions supports SKF_AD_PROTOCOL up to SKF_AD_PAY_OFFSET. Later
> additions to BPF extensions need to add their bits to the
> bpf_tell_extensions() function, as documented in the comment.
>
> Signed-off-by: Michal Sekletar <msekleta@redhat.com>
> Cc: David Miller <davem@davemloft.net>
> Reviewed-by: Daniel Borkmann <dborkman@redhat.com>
Applied, thanks.
^ permalink raw reply
* [PATCH net-next] ipv4: be friend with drop monitor
From: Eric Dumazet @ 2014-01-19 2:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Replace some dev_kfree_skb() with kfree_skb() calls when
we drop one skb, this might help bug tracking.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ip_gre.c | 4 ++--
net/ipv4/ip_tunnel.c | 4 ++--
net/ipv4/ip_vti.c | 2 +-
net/ipv4/ipip.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index e560ef34cf4b..e7a92fdb36f6 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -278,7 +278,7 @@ static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
free_skb:
- dev_kfree_skb(skb);
+ kfree_skb(skb);
out:
dev->stats.tx_dropped++;
return NETDEV_TX_OK;
@@ -301,7 +301,7 @@ static netdev_tx_t gre_tap_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
free_skb:
- dev_kfree_skb(skb);
+ kfree_skb(skb);
out:
dev->stats.tx_dropped++;
return NETDEV_TX_OK;
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 432c28ab3197..83ede2e7ca42 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -716,7 +716,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
if (skb_cow_head(skb, dev->needed_headroom)) {
dev->stats.tx_dropped++;
- dev_kfree_skb(skb);
+ kfree_skb(skb);
return;
}
@@ -732,7 +732,7 @@ tx_error_icmp:
#endif
tx_error:
dev->stats.tx_errors++;
- dev_kfree_skb(skb);
+ kfree_skb(skb);
}
EXPORT_SYMBOL_GPL(ip_tunnel_xmit);
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 0783200ad8d2..48eafae51769 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -162,7 +162,7 @@ tx_error_icmp:
dst_link_failure(skb);
tx_error:
dev->stats.tx_errors++;
- dev_kfree_skb(skb);
+ kfree_skb(skb);
return NETDEV_TX_OK;
}
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index fe3e9f7f1f0b..812b18351462 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -228,7 +228,7 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
tx_error:
- dev_kfree_skb(skb);
+ kfree_skb(skb);
out:
dev->stats.tx_errors++;
return NETDEV_TX_OK;
^ permalink raw reply related
* Re: [PATCH net-next] net: vxlan: do not use vxlan_net before checking event type
From: Eric Dumazet @ 2014-01-19 2:01 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpXd_MCiD26cCGzMzamK+Uz3jm5-LOns1Pud-1j2GYXhQw@mail.gmail.com>
On Sat, 2014-01-18 at 15:38 -0800, Cong Wang wrote:
> Cc'ing netdev back...
>
> On Sat, Jan 18, 2014 at 11:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Daniel did the right thing and David agreed.
> >
> > And I agreed.
>
> If you mean the code, I don't even want to argue from the beginning.
>
> If you mean the author of the patch, it is obviously wrong.
>
> >
> > So if you want to fight, feel free, but its going to be really hard.
> >
>
> I see.
>
> Next time, I will pick up your patch, change a very minor issue,
> and *steal* it as mine (a.k.a ignoring From:). So that in the changelog
> your patch will become mine.
>
> You don't mind, since you already agreed above...
You failed to the test I did with you.
By adding netdev back to a mail I sent privately, you violated one very
elementary rule of communication.
This is a huge mistake.
I will never send you again a private mail.
^ permalink raw reply
* [ PATCH net-next] qlcnic: fix sparse warnings
From: Stephen Hemminger @ 2014-01-19 1:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Fengguang Wu <fengguang.wu@intel.com>
Previous patch changed prototypes, but forgot functions.
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
---
qlcnic_83xx_hw.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-18 13:41:07.000000000 -0800
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c 2014-01-18 17:13:08.640658697 -0800
@@ -2066,7 +2066,7 @@ void qlcnic_83xx_change_l2_filter(struct
qlcnic_83xx_sre_macaddr_change(adapter, mac, vlan_id, QLCNIC_MAC_ADD);
}
-void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
+static void qlcnic_83xx_configure_mac(struct qlcnic_adapter *adapter, u8 *mac,
u8 type, struct qlcnic_cmd_args *cmd)
{
switch (type) {
@@ -2170,7 +2170,7 @@ static void qlcnic_83xx_handle_link_aen(
qlcnic_advert_link_change(adapter, link_status);
}
-irqreturn_t qlcnic_83xx_handle_aen(int irq, void *data)
+static irqreturn_t qlcnic_83xx_handle_aen(int irq, void *data)
{
struct qlcnic_adapter *adapter = data;
struct qlcnic_mailbox *mbx;
@@ -3517,7 +3517,7 @@ int qlcnic_83xx_flash_test(struct qlcnic
return 0;
}
-int qlcnic_83xx_shutdown(struct pci_dev *pdev)
+static int qlcnic_83xx_shutdown(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
struct net_device *netdev = adapter->netdev;
@@ -3892,7 +3892,7 @@ int qlcnic_83xx_init_mailbox_work(struct
return 0;
}
-pci_ers_result_t qlcnic_83xx_io_error_detected(struct pci_dev *pdev,
+static pci_ers_result_t qlcnic_83xx_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
@@ -3914,7 +3914,7 @@ pci_ers_result_t qlcnic_83xx_io_error_de
return PCI_ERS_RESULT_NEED_RESET;
}
-pci_ers_result_t qlcnic_83xx_io_slot_reset(struct pci_dev *pdev)
+static pci_ers_result_t qlcnic_83xx_io_slot_reset(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
int err = 0;
@@ -3937,7 +3937,7 @@ disconnect:
return PCI_ERS_RESULT_DISCONNECT;
}
-void qlcnic_83xx_io_resume(struct pci_dev *pdev)
+static void qlcnic_83xx_io_resume(struct pci_dev *pdev)
{
struct qlcnic_adapter *adapter = pci_get_drvdata(pdev);
^ permalink raw reply
* Re: [PATCH linux-next] net: batman-adv: use "__packed __aligned(2)" for each structure instead of "__packed(2)" region
From: James Hogan @ 2014-01-19 1:10 UTC (permalink / raw)
To: Antonio Quartulli
Cc: Chen Gang, David Miller, mareklindner, sw, b.a.t.m.a.n, netdev,
linux-kernel@vger.kernel.org, linux-metag
In-Reply-To: <52DA7B9E.4040202@meshcoding.com>
[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]
On Saturday 18 January 2014 14:03:26 Antonio Quartulli wrote:
> On 18/01/14 12:31, Chen Gang wrote:
> > Unfortunately, not all compilers assumes the structures within a pack
> > region also need be packed (e.g. metag), so need add a pack explicitly
> > to satisfy all compilers.
> >
> > The related error (under metag with allmodconfig):
> > MODPOST 2952 modules
> >
> > ERROR: "__compiletime_assert_431" [net/batman-adv/batman-adv.ko]
> > undefined!
> > ERROR: "__compiletime_assert_432" [net/batman-adv/batman-adv.ko]
> > undefined!
> > ERROR: "__compiletime_assert_429" [net/batman-adv/batman-adv.ko]
> > undefined!
> > ERROR: "__compiletime_assert_428" [net/batman-adv/batman-adv.ko]
> > undefined!
> > ERROR: "__compiletime_assert_423" [net/batman-adv/batman-adv.ko]
> > undefined!
> >
> > Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>
> David, what do you think about this change?
>
>
> Can "__packed __aligned(2)" generate a different structure padding than
> "#pragma pack(2)" ?
>
> I am not really sure about the difference between the two. But if we
> have the possibility that the padding may change then this patch should
> go into net, otherwise we will have a protocol compatibility problem
> between 3.13 and 3.14.
(Chen: sorry I didn't twig what you were referring to before about #pragma
pack not working)
It appears that the following gcc patch adds support for #pragma pack:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01115.html
I gave it a quick spin on metag gcc (which is unfortunately stuck on an old
version) and it seems to fix my simple test case so that #pragma pack(2)
becomes equivalent to __packed __aligned(2) (for sizeof and __alignof__).
However, the __packed and __aligned are linux specific macros to abstract
compiler details, whereas #pragma pack appears to be a compiler-specific WIN32
style equivalent to GCC's __attribute__((packed)) and
__attribute__((aligned(2))) (these are what __packed and __aligned use in
compiler-gcc.h).
Therefore I believe using the Linux abstractions is still more correct here.
Cheers
James
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: do not use vxlan_net before checking event type
From: Cong Wang @ 2014-01-19 0:50 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Eric W. Biederman, Jesse Brandeburg
In-Reply-To: <52DB1E19.5040909@redhat.com>
On Sat, Jan 18, 2014 at 4:36 PM, Daniel Borkmann <dborkman@redhat.com> wrote:
>
> Cong, I truly do __not__ care who is what or who isn't. I do care
> that the code is fine. Sure, next time I'll ask, or better, just
> give feedback; sorry for how this went, it was not my intention.
Apologies accepted. Let's build a better community!
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: do not use vxlan_net before checking event type
From: Daniel Borkmann @ 2014-01-19 0:36 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Eric W. Biederman, Jesse Brandeburg
In-Reply-To: <CAM_iQpU6LW2a=kfryrvbZvUQ_+T_9n0dnoxEw_0G_J9hQfNHSQ@mail.gmail.com>
On 01/19/2014 12:48 AM, Cong Wang wrote:
> I do understand you want to be the author, next time, just tell me
> before you do, I will let you be whatever you want (if I can).
> That's all.
>
> REPEAT: I don't mind who fixes it, I DO mind you did it without
> asking me first.
Cong, I truly do __not__ care who is what or who isn't. I do care
that the code is fine. Sure, next time I'll ask, or better, just
give feedback; sorry for how this went, it was not my intention.
^ permalink raw reply
* Re: [PATCH net-next] net: vxlan: do not use vxlan_net before checking event type
From: Cong Wang @ 2014-01-18 23:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Eric Dumazet, David Miller, Linux Kernel Network Developers,
Eric W. Biederman, Jesse Brandeburg
In-Reply-To: <CAM_iQpWymPmN1yBFW9XQv71ZxeGACMuR_TrXNOmFgj3o7+v+zA@mail.gmail.com>
On Sat, Jan 18, 2014 at 3:32 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sat, Jan 18, 2014 at 11:47 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> I do care that this gets fixed asap! Clearly, it seems it was an honest
>> mistake to do so.
>
> Why??? Even for stable, you don't have to be hurry. That's all.
Our community builds on trust and corporations.
You just break it by being rush for a getting a patch for your
own behalf and potentially being irrespective to me and others.
Even patches for stable don't worth this...
Corporation is much more important than just rushing for
being the author of the patch.
I do understand you want to be the author, next time, just tell me
before you do, I will let you be whatever you want (if I can).
That's all.
REPEAT: I don't mind who fixes it, I DO mind you did it without
asking me first.
^ 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