* Re: [PATCH] include/linux/socket.h: Fix comment
From: David Miller @ 2014-11-05 20:52 UTC (permalink / raw)
To: linux; +Cc: netdev, linux-kernel
In-Reply-To: <1415220267-20044-1-git-send-email-linux@rasmusvillemoes.dk>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date: Wed, 5 Nov 2014 21:44:27 +0100
> File descriptors are always closed on exit :-)
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: dsa: slave: Fix autoneg for phys on switch MDIO bus
From: Florian Fainelli @ 2014-11-05 20:53 UTC (permalink / raw)
To: Andrew Lunn, davem; +Cc: netdev
In-Reply-To: <1415213248-29037-1-git-send-email-andrew@lunn.ch>
On 11/05/2014 10:47 AM, Andrew Lunn wrote:
> When the ports phys are connected to the switches internal MDIO bus,
> we need to connect the phy to the slave netdev, otherwise
> auto-negotiation etc, does not work.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
>
> Hi Florian
>
> Is this the right fix?
>
> What i found is that ports on mv88E6171 we coming up as 10/half. If i
> forced a renegotiation with ethtool -r lan0, the phy would then goto
> 1000/full.
>
> The code for phys on internal switch MDIO buses never connect the phy
> to the device, only phys listed in DT get connected via
> of_phy_connect(). By connecting the phy, the state machine is active
> and does an autoneg when the slave interface is opened.
This looks fine to me, I think we might want to revisit/nuke the code at
the end of dsa_slave_create since it:
- is racy: netif_carrier_off() is called before register_netdev()
- is double racy: we should be bound to a PHY before calling
register_netdev() otherwise there could be MDIO accesses done to that
PHY without an actual PHY being registered
>
> net/dsa/slave.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 6d1817449c36..ab03e00ffe8f 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -489,11 +489,14 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
> /* We could not connect to a designated PHY, so use the switch internal
> * MDIO bus instead
> */
> - if (!p->phy)
> + if (!p->phy) {
> p->phy = ds->slave_mii_bus->phy_map[p->port];
> - else
> + phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
> + p->phy_interface);
> + } else {
> pr_info("attached PHY at address %d [%s]\n",
> p->phy->addr, p->phy->drv->name);
> + }
> }
>
> int dsa_slave_suspend(struct net_device *slave_dev)
>
^ permalink raw reply
* Re: [PATCH net v2] vxlan: Do not reuse sockets for a different address family
From: David Miller @ 2014-11-05 20:59 UTC (permalink / raw)
To: mleitner; +Cc: netdev, stephen, sergei.shtylyov
In-Reply-To: <e7e226e9bef6f03ac249bc8e5ebf0938944ace3c.1415120464.git.mleitner@redhat.com>
From: Marcelo Ricardo Leitner <mleitner@redhat.com>
Date: Tue, 4 Nov 2014 15:03:20 -0200
> @@ -281,7 +281,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, __be16 port)
> struct vxlan_sock *vs;
>
> hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
> - if (inet_sk(vs->sock->sk)->inet_sport == port)
> + if (inet_sk(vs->sock->sk)->inet_sport == port &&
> + inet_sk(vs->sock->sk)->sk.sk_family == family)
You didn't even compile this.
You're in the penalty box, and I'm ignoring your patches for at least
a week, this is really unacceptable for an upstream patch submission.
Sorry.
^ permalink raw reply
* Re: [PATCH] drivers: net: ethernet: xilinx: xilinx_emaclite: revert the original commit "1db3ddff1602edf2390b7667dcbaa0f71512e3ea"
From: David Miller @ 2014-11-05 21:01 UTC (permalink / raw)
To: michal.simek
Cc: gang.chen.5i5j, soren.brinkmann, sthokal, manuel.schoelling,
f.fainelli, paul.gortmaker, ebiederm, netdev, linux-kernel
In-Reply-To: <a39951cc744047679d13b23e76c97347@BN1BFFO11FD022.protection.gbl>
From: Michal Simek <michal.simek@xilinx.com>
Date: Wed, 5 Nov 2014 08:19:41 +0100
> On 11/04/2014 03:43 PM, Chen Gang wrote:
>> Microblaze is a fpga soft core, it can be customized easily, which may
>> cause many various hardware version strings.
>>
>> So the original fix patch based on hard-coded compatible version strings
>> is not a good idea (although it is correct for current issue). For it,
>> there will be a new solving way soon (which based on the device tree).
>>
>> The original issue is related with qemu, so can only change the hardware
>> version string in qemu for it, then keep the original driver no touch (
>> qemu is for virtualization which has much easier life than real world).
>>
>>
>> Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
>> ---
>> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 1 -
>> 1 file changed, 1 deletion(-)
>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: Al Viro @ 2014-11-05 21:07 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141105.155054.2198151263164321219.davem@davemloft.net>
On Wed, Nov 05, 2014 at 03:50:54PM -0500, David Miller wrote:
> I think we can get away with it if, as you say, we don't export a 'msghdr'
> from any uapi headers.
OK. I'm about halfway through the review of struct msghdr instances in the
current tree right now, will post user_msghdr patch once I'm done. Already
found a dumb bug in o2net_send_tcp_msg() while doing that - broken by me
back in 3.15 ;-/ Will send a fix to Linus in an hour or so...
> And indeed, double checking, it's purely a linux/socket.h thing.
>
> If this patch is OK, mind if I toss it into net-next Al?
Sure, no problem - AFAICS, the only real difference from rebase of April one
I've quoted upthread is that you add include of socket.h into skbuff.h; the
rest of the differences is pure whitespace noise.
Ping me when you put it there, OK? I'll rebase the rest of old stuff on
top of it (similar helpers, mostly).
^ permalink raw reply
* Re: [net-next.git 0/3 (v2)] stmmac: review driver Koptions
From: David Miller @ 2014-11-05 21:15 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1415112574-21321-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Tue, 4 Nov 2014 15:49:31 +0100
> Recently many Koption options have been added to have new glue logic on several
> platforms.
>
> The main goal behind this work is to guarantee that the driver built
> fine on all the branches where it is present independently of which
> glue logic is selected.
>
> IMHO, it is better to remove all the not necessary Koption(s) that can hide
> build problems when something changes in the driver and especially when
> the DT compatibility allows us to manage all the platform data.
>
> I compiled the driver w/o any issue on net-next Git for:
>
> x86, arm and sh4.
>
> In case of there are build problems on some repos now it will be
> easy to catch them and cherry-pick patches from mainstream.
>
> For sure, do not hesitate to contact me in case of issue.
>
> Also this set removes STMMAC_DEBUG_FS and BUS_MODE_DA. The latter is useless
> and the former can be replaced by DEBUG_FS (always to make safe the build).
>
> V2: patch-set re-based on top of the latest updates for net-next
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH (net.git) 0/5] stmmac: review and fix lock and atomicity
From: David Miller @ 2014-11-05 21:24 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1415117289-7733-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Tue, 4 Nov 2014 17:08:04 +0100
> Recently some issues have been reported for the driver for locking mechanism
> and atomicity.
>
> In fact, enabling DEBUG support to prove lock and to verify if sleeping while
> atomic context some warnings occur at runtime. I have reproduced all on STi
> platforms.
>
> Concerning the tx path, I had provided a patch time ago but
> I discarded the idea to completely remove locks; in this patch-set we can have
> some useful fixes instead of.
>
> This patch-set is to fix the atomicity in the PM stuff where I tried to collect
> all the points and advice reported in the past weeks.
> As final result, on my side no warnings and no problem when suspend/resume the
> driver on STi boxes.
>
> I also added a patch that fixes the locks for the EEE.
> As pointed in some thread there was a design problem behind the eee
> initialization and I have tried to fix that before.
> As final result no issues when proving locks too.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] vxlan: Do not reuse sockets for a different address family
From: Marcelo Ricardo Leitner @ 2014-11-05 21:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stephen, sergei.shtylyov
In-Reply-To: <20141105.155913.297158120451064287.davem@davemloft.net>
On 05-11-2014 18:59, David Miller wrote:
> From: Marcelo Ricardo Leitner <mleitner@redhat.com>
> Date: Tue, 4 Nov 2014 15:03:20 -0200
>
>> @@ -281,7 +281,8 @@ static struct vxlan_sock *vxlan_find_sock(struct net *net, __be16 port)
>> struct vxlan_sock *vs;
>>
>> hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
>> - if (inet_sk(vs->sock->sk)->inet_sport == port)
>> + if (inet_sk(vs->sock->sk)->inet_sport == port &&
>> + inet_sk(vs->sock->sk)->sk.sk_family == family)
>
> You didn't even compile this.
This patch was part of a bigger change and I really thought I had tested it by
itself, but clearly I was wrong, sorry.
(I changed the port hash to include the family in the key, and that's how that
variable got there.)
> You're in the penalty box, and I'm ignoring your patches for at least
> a week, this is really unacceptable for an upstream patch submission.
>
> Sorry.
Ack, sorry again. It was twice in a bad day, but my bad. Won't happen again.
Marcelo
^ permalink raw reply
* Re: [PATCH net v4] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
From: Daniel Borkmann @ 2014-11-05 21:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, lw1a2.jing, netdev, Eric Dumazet, Hannes Frederic Sowa,
David L Stevens
In-Reply-To: <1415220449.13896.15.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/05/2014 09:47 PM, Eric Dumazet wrote:
...
> Thanks for your patience ;)
No problem, thanks for the feedback, Eric!
^ permalink raw reply
* Re: [PATCH net 0/5] Implement ndo_gso_check() for vxlan nics
From: Or Gerlitz @ 2014-11-05 21:32 UTC (permalink / raw)
To: Tom Herbert
Cc: Joe Stringer, Linux Netdev List, sathya.perla, Jeff Kirsher,
linux.nics, Amir Vadai, shahed.shaikh, dept-gelinuxnicdev,
Linux Kernel
In-Reply-To: <CA+mtBx_BOmV+tOtio48M+xRatK79B31LoGnf4uvFJAbxYqOt_w@mail.gmail.com>
On Wed, Nov 5, 2014 at 8:00 PM, Tom Herbert <therbert@google.com> wrote:
> On Wed, Nov 5, 2014 at 9:50 AM, Joe Stringer <joestringer@nicira.com> wrote:
>>
>> On 5 November 2014 04:38, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>
>>> On Tue, Nov 4, 2014 at 11:56 PM, Joe Stringer <joestringer@nicira.com> wrote:
>>> > Most NICs that report NETIF_F_GSO_UDP_TUNNEL support VXLAN, and not other
>>> > UDP-based encapsulation protocols where the format and size of the header may
>>> > differ. This patch series implements ndo_gso_check() for these NICs,
>>> > restricting the GSO handling to something that looks and smells like VXLAN.
>>> >
>>> > Implementation shamelessly stolen from Tom Herbert (with minor fixups):
>>> > http://thread.gmane.org/gmane.linux.network/332428/focus=333111
>>>
>>>
>>> Hi Joe,
>>>
>>> 1st, thanks for picking this task...2nd, for drivers that currently
>>> support only pure VXLAN, I don't see the point
>>> to replicate the helper suggested by Tom (good catch on the size check
>>> to be 16 and not 12) four times and who know how more in the future.
>>> Let's just have one generic helper and make the mlx4/be/fm10k/benet
>>> drivers to have it as their ndo, OK?
>>
>>
>> Thanks for taking a look.
>>
>> I had debated whether to do this or not as the actual support on each NIC may differ, and each implementation may morph over time to match these capabilities better. Obviously the vendors will know better than me on this, so I'm posing this series to prod them for more information. At this point I've had just one maintainer come back and confirm that this helper is a good fit for their hardware, so I'd like to confirm that multiple drivers will use a ndo_gso_check_vxlan_helper() function before I go and create it.
>
>
> Thanks for implementing this fix!
>
> Personally, I would rather not have the helper. This is already a
> small number of drivers, and each driver owner should consider what
> limitations are of their device and try to enable to allow the maximum
> number of use cases possible. I'm also hoping that new devices will
> implement the more generic mechanism so that VXLAN is just one
> supported protocol.
but fact is that the proposed patch series has the --same-- helper for
four drivers, so why not start with a that limited helper which would
be picked up by these drivers and we'll take it from there.
^ permalink raw reply
* Re: [PATCH net 0/5] Implement ndo_gso_check() for vxlan nics
From: David Miller @ 2014-11-05 21:38 UTC (permalink / raw)
To: gerlitz.or
Cc: therbert, joestringer, netdev, sathya.perla, jeffrey.t.kirsher,
linux.nics, amirv, shahed.shaikh, Dept-GELinuxNICDev,
linux-kernel
In-Reply-To: <CAJ3xEMhxabp1EKbFPfvoZEFt=CQKFNcNrURGMX=7miDwmK9Y-A@mail.gmail.com>
From: Or Gerlitz <gerlitz.or@gmail.com>
Date: Wed, 5 Nov 2014 23:32:44 +0200
> but fact is that the proposed patch series has the --same-- helper for
> four drivers, so why not start with a that limited helper which would
> be picked up by these drivers and we'll take it from there.
I'm in favor of the helper, duplication is error prone.
And in fact, any differences a driver ends up needing might be
integratable into the helper.
^ permalink raw reply
* Re: [patch net-next] sched: fix act file names in header comment
From: Cong Wang @ 2014-11-05 21:38 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, David Miller, Jamal Hadi Salim
In-Reply-To: <1415217111-9803-1-git-send-email-jiri@resnulli.us>
On Wed, Nov 5, 2014 at 11:51 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> diff --git a/net/sched/act_gact.c b/net/sched/act_gact.c
> index d6bcbd9..7fffc22 100644
> --- a/net/sched/act_gact.c
> +++ b/net/sched/act_gact.c
> @@ -1,5 +1,5 @@
> /*
> - * net/sched/gact.c Generic actions
> + * net/sched/act_gact.c Generic actions
Or maybe just remove the file name from the comment?
I have no strong opinions here.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] gue: Remote checksum offload
From: David Miller @ 2014-11-05 21:44 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1415120817-2105-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 4 Nov 2014 09:06:50 -0800
> This patch set implements remote checksum offload for
> GUE, which is a mechanism that provides checksum offload of
> encapsulated packets using rudimentary offload capabilities found in
> most Network Interface Card (NIC) devices.
Series applied, thanks for doing this work Tom.
^ permalink raw reply
* Re: [PATCH net-next 1/2] ethtool: Support for configurable RSS hash function
From: Ben Hutchings @ 2014-11-05 21:51 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Or Gerlitz, Eyal Perry, Yevgeny Petrilin
In-Reply-To: <1415188769-19593-2-git-send-email-amirv@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 7383 bytes --]
On Wed, 2014-11-05 at 13:59 +0200, Amir Vadai wrote:
> From: Eyal Perry <eyalpe@mellanox.com>
>
> This patch adds an RSS hash functions string-set, and two
> ethtool-options for set/get current RSS hash function. User-kernel API is done
> through the new hfunc mask field in the ethtool_rxfh struct. A bit set
> in the hfunc is corresponding to an index in the string-set.
>
> Signed-off-by: Eyal Perry <eyalpe@mellanox.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
> ---
> include/linux/ethtool.h | 28 ++++++++++++++++++++++++
> include/uapi/linux/ethtool.h | 6 ++++-
> net/core/ethtool.c | 52 ++++++++++++++++++++++++++++++--------------
> 3 files changed, 69 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index c1a2d60..61003b1 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -59,6 +59,29 @@ enum ethtool_phys_id_state {
> ETHTOOL_ID_OFF
> };
>
> +enum {
> + RSS_HASH_TOP_BIT, /* Configurable RSS hash function - Toeplitz */
> + RSS_HASH_XOR_BIT, /* Configurable RSS hash function - Xor */
> +
> + /*
> + * Add your fresh new hash function bits above and remember to update
> + * rss_hash_func_strings[] below
> + */
> + RSS_HASH_FUNCS_COUNT
> +};
> +
> +#define __RSS_HASH_BIT(bit) ((u32)1 << (bit))
> +#define __RSS_HASH(name) __RSS_HASH_BIT(RSS_HASH_##name##_BIT)
> +
> +#define RSS_HASH_TOP __RSS_HASH(TOP)
> +#define RSS_HASH_XOR __RSS_HASH(XOR)
I think #define RSS_HASH_UNKNOWN 0 might also be useful.
And I think all of these names should get an ETH_ prefix.
> +static const char
> +rss_hash_func_strings[RSS_HASH_FUNCS_COUNT][ETH_GSTRING_LEN] = {
> + [RSS_HASH_TOP_BIT] = "toeplitz",
> + [RSS_HASH_XOR_BIT] = "xor",
> +};
This belongs in net/core/ethtool.c.
> struct net_device;
>
> /* Some generic methods drivers may use in their ethtool_ops */
> @@ -158,6 +181,9 @@ static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
> * Returns zero if not supported for this specific device.
> * @get_rxfh_indir_size: Get the size of the RX flow hash indirection table.
> * Returns zero if not supported for this specific device.
> + * @get_rxfh_func: Get the hardware RX flow hash function.
> + * @set_rxfh_func: Set the hardware RX flow hash function. Returns a negative
> + * error code or zero.
> * @get_rxfh: Get the contents of the RX flow hash indirection table and hash
> * key.
> * Will only be called if one or both of @get_rxfh_indir_size and
> @@ -241,6 +267,8 @@ struct ethtool_ops {
> int (*reset)(struct net_device *, u32 *);
> u32 (*get_rxfh_key_size)(struct net_device *);
> u32 (*get_rxfh_indir_size)(struct net_device *);
> + u32 (*get_rxfh_func)(struct net_device *);
> + int (*set_rxfh_func)(struct net_device *, u32);
Why not another parameter to get_rxfh/set_rxfh? I know it's a pain to
update all the implementations, but changing algorithm potentially
changes the supported indirection table and key lengths. They have to
be validated together.
> int (*get_rxfh)(struct net_device *, u32 *indir, u8 *key);
> int (*set_rxfh)(struct net_device *, const u32 *indir,
> const u8 *key);
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index eb2095b..eb91da4 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -534,6 +534,7 @@ struct ethtool_pauseparam {
> * @ETH_SS_NTUPLE_FILTERS: Previously used with %ETHTOOL_GRXNTUPLE;
> * now deprecated
> * @ETH_SS_FEATURES: Device feature names
> + * @ETH_SS_RSS_HASH_FUNCS: RSS hush function names
> */
> enum ethtool_stringset {
> ETH_SS_TEST = 0,
> @@ -541,6 +542,7 @@ enum ethtool_stringset {
> ETH_SS_PRIV_FLAGS,
> ETH_SS_NTUPLE_FILTERS,
> ETH_SS_FEATURES,
> + ETH_SS_RSS_HASH_FUNCS,
> };
>
> /**
> @@ -900,7 +902,9 @@ struct ethtool_rxfh {
> __u32 rss_context;
> __u32 indir_size;
> __u32 key_size;
> - __u32 rsvd[2];
> + __u8 hfunc;
Missing kernel-doc. This needs to be very clear about what the valid
values are.
> + __u8 rsvd8[3];
> + __u32 rsvd32;
> __u32 rss_config[0];
> };
> #define ETH_RXFH_INDIR_NO_CHANGE 0xffffffff
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index 06dfb29..4791c17 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -185,6 +185,9 @@ static int __ethtool_get_sset_count(struct net_device *dev, int sset)
> if (sset == ETH_SS_FEATURES)
> return ARRAY_SIZE(netdev_features_strings);
>
> + if (sset == ETH_SS_RSS_HASH_FUNCS)
> + return ARRAY_SIZE(rss_hash_func_strings);
> +
> if (ops->get_sset_count && ops->get_strings)
> return ops->get_sset_count(dev, sset);
> else
[...]
> @@ -760,32 +769,43 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
> const struct ethtool_ops *ops = dev->ethtool_ops;
> struct ethtool_rxnfc rx_rings;
> struct ethtool_rxfh rxfh;
> - u32 dev_indir_size = 0, dev_key_size = 0, i;
> + u32 dev_indir_size = 0, dev_key_size = 0, dev_hfunc = 0, i;
> u32 *indir = NULL, indir_bytes = 0;
> u8 *hkey = NULL;
> u8 *rss_config;
> u32 rss_cfg_offset = offsetof(struct ethtool_rxfh, rss_config[0]);
>
> - if (!(ops->get_rxfh_indir_size || ops->get_rxfh_key_size) ||
> - !ops->get_rxnfc || !ops->set_rxfh)
> + if (!(ops->get_rxfh_indir_size || ops->get_rxfh_key_size ||
> + ops->get_rxfh_func) || !ops->get_rxnfc || !ops->set_rxfh)
> return -EOPNOTSUPP;
>
> + if (ops->get_rxfh_func)
> + dev_hfunc = ops->get_rxfh_func(dev);
> if (ops->get_rxfh_indir_size)
> dev_indir_size = ops->get_rxfh_indir_size(dev);
> if (ops->get_rxfh_key_size)
> dev_key_size = dev->ethtool_ops->get_rxfh_key_size(dev);
> - if ((dev_key_size + dev_indir_size) == 0)
> + if ((dev_key_size + dev_indir_size + dev_hfunc) == 0)
> return -EOPNOTSUPP;
>
> if (copy_from_user(&rxfh, useraddr, sizeof(rxfh)))
> return -EFAULT;
>
> /* Check that reserved fields are 0 for now */
> - if (rxfh.rss_context || rxfh.rsvd[0] || rxfh.rsvd[1])
> + if (rxfh.rss_context || rxfh.rsvd8[0] || rxfh.rsvd8[1] ||
> + rxfh.rsvd8[2] || rxfh.rsvd32)
> return -EINVAL;
>
> + if (rxfh.hfunc != dev_hfunc) {
> + if (!ops->set_rxfh_func)
> + return -EOPNOTSUPP;
> + ret = ops->set_rxfh_func(dev, rxfh.hfunc);
> + if (ret)
> + return ret;
> + }
> +
> /* If either indir or hash key is valid, proceed further.
> - * It is not valid to request that both be unchanged.
> + * Must request at least one change: indir size, hash key or function.
> */
> if ((rxfh.indir_size &&
> rxfh.indir_size != ETH_RXFH_INDIR_NO_CHANGE &&
> @@ -793,7 +813,7 @@ static noinline_for_stack int ethtool_set_rxfh(struct net_device *dev,
> (rxfh.key_size && (rxfh.key_size != dev_key_size)) ||
> (rxfh.indir_size == ETH_RXFH_INDIR_NO_CHANGE &&
> rxfh.key_size == 0))
> - return -EINVAL;
> + return rxfh.hfunc ? 0 : -EINVAL;
Shouldn't the condition be rxfh.hfunc != dev_hfunc ?
Ben.
> if (rxfh.indir_size != ETH_RXFH_INDIR_NO_CHANGE)
> indir_bytes = dev_indir_size * sizeof(indir[0]);
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] inet: Add skb_copy_datagram_iter
From: David Miller @ 2014-11-05 21:57 UTC (permalink / raw)
To: viro; +Cc: herbert, netdev, linux-kernel, bcrl
In-Reply-To: <20141105210745.GT7996@ZenIV.linux.org.uk>
From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Wed, 5 Nov 2014 21:07:45 +0000
> Ping me when you put it there, OK? I'll rebase the rest of old stuff on
> top of it (similar helpers, mostly).
I just pushed it into net-next, thanks Al.
^ permalink raw reply
* Re: mlx4+vxlan offload breaks gre tunnels
From: Tom Herbert @ 2014-11-05 21:59 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Florian Westphal, Linux Netdev List, Jesse Gross, Amir Vadai
In-Reply-To: <545A4DB7.5010603@mellanox.com>
On Wed, Nov 5, 2014 at 8:17 AM, Or Gerlitz <ogerlitz@mellanox.com> wrote:
> On 11/5/2014 5:04 PM, Florian Westphal wrote:
>>
>> tl,dr: all tcp packets sent via gre tunnel have broken tcp csum if vxlan
>> offload
>> is enabled with mlx4 driver.
>>
>> Given following config on tx-side:
>> dev=enp3s0
>> ip addr add dev $dev 192.168.23.1/24
>> ip link set $dev up
>> ip link add mygre type gretap remote 192.168.23.2 local 192.168.23.1
>> ip addr add dev mygre 192.168.42.1/24
>> ip link set gre0 up
>> ip link set mygre up
>>
>> and
>>
>> options mlx4_core log_num_mgm_entry_size=-1 debug_level=1
>> port_type_array=2,2
>>
>> in
>> /etc/modprobe.d/mlx4.conf
>>
>> all tcp packets sent to destinations over the gre tunnel have bogus tcp
>> checksums (and are tossed on rx side when stack validates tcp checksum).
>>
>> net-next head is commit 30349bdbc4da5ecf0efa25556e3caff9c9b8c5f7 .
>>
>> What makes things work for me:
>> either
>>
>> options mlx4_core 1 debug_level=1 port_type_array=2,2
>>
>> (ie. no MLX4_TUNNEL_OFFLOAD_MODE_VXLAN)
>>
>> or not setting NETIF_F_IP_CSUM in enc_features:
>>
>> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
>> @@ -2579,10 +2579,12 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev,
>> int port,
>> dev->priv_flags |= IFF_UNICAST_FLT;
>> if (mdev->dev->caps.tunnel_offload_mode ==
>> MLX4_TUNNEL_OFFLOAD_MODE_VXLAN) {
>> - dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
>> + dev->hw_enc_features |= NETIF_F_RXCSUM |
>> NETIF_F_TSO |
>> NETIF_F_GSO_UDP_TUNNEL;
>>
>> I am not sure if its right fix, but to my eyes this basically looks like
>> mlx4 is telling stack that it can handle tcp checksum offload within
>> tunnels, and that doesn't seem to be the case for all types (e.g. gre).
>>
>> Could someone who understand the enc_features specifics better confirm
>> that
>> above patch is correct (or provide a better/proper fix)?
>
>
> Yep, I can see now the problem. It comes into play with ConnectX3-pro NICs
> that support VXLAN offloads (but not with ConnectX3 NIC which don't) when
> you enable the offloads support on the CX3-pro.
>
> The problem originates from the fact that we can't advertize something like
> "the HW can offload the inner checksum of UDP/VXLAN encapsulated (but not
> for GRE)", e.g in a similar manner that exists in the GSO space, where you
> have NETIF_F_GSO _YYY for each yyy in {UDP, SIT, GRE, etc} tunneling scheme.
>
> I think the best effort we can do now is
>
> 1. come up with something such as the below patch for 3.18 which is
> back-ward portable for -stable kernels, it will only arm the hw offloads if
> the OS tells us there's VXLAN in action
>
> 2. come up with proper kernel APIs to let NICs advertize which encap
> schemes they can actually offload the inner checksum, Tom... your work which
> now runs over netdev.
>
Possibly #3: add ndo_gso_check to detect nested tunneling. In this
case it would see that gso_type has both SKB_GSO_GRE and
SKB_GSO_UDP_TUNNEL set.
> Tom/Jesse- thoughts? are you +1-ing the below approach?
>
> Or.
>
> tested to work with the following which is a bit different, tell me if it
> works for you
>
> # node A - with mlx4_en address192.168.31.18
> ip tunnel add gre1 mode gre local 192.168.31.18 remote 192.168.31.17 ttl 255
> ifconfig gre1 10.10.10.18/24 up
> ifconfig gre1 mtu 1450
>
> # node B - with mlx4_en address192.168.31.17
> ip tunnel add gre1 mode gre local 192.168.31.17 remote 192.168.31.18 ttl 255
> ifconfig gre1 10.10.10.17/24 up
> ifconfig gre1 mtu 1450
>
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index 0efbae9..7753833 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -2292,6 +2292,12 @@ static void mlx4_en_add_vxlan_offloads(struct
> work_struct *work)
> out:
> if (ret)
> en_err(priv, "failed setting L2 tunnel configuration ret
> %d\n", ret);
> +
> + /* set offloads */
> + priv->dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> + NETIF_F_TSO | NETIF_F_GSO_UDP_TUNNEL;
> + priv->dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
> + priv->dev->features |= NETIF_F_GSO_UDP_TUNNEL;
> }
>
> static void mlx4_en_del_vxlan_offloads(struct work_struct *work)
> @@ -2299,6 +2305,10 @@ static void mlx4_en_del_vxlan_offloads(struct
> work_struct *work)
> int ret;
> struct mlx4_en_priv *priv = container_of(work, struct mlx4_en_priv,
> vxlan_del_task);
> + /* unset offloads */
> + priv->dev->hw_enc_features = 0;
> + priv->dev->hw_features &= ~NETIF_F_GSO_UDP_TUNNEL;
> + priv->dev->features &= ~NETIF_F_GSO_UDP_TUNNEL;
>
> ret = mlx4_SET_PORT_VXLAN(priv->mdev->dev, priv->port,
> VXLAN_STEER_BY_OUTER_MAC, 0);
> @@ -2578,13 +2588,6 @@ int mlx4_en_init_netdev(struct mlx4_en_dev *mdev, int
> port,
> if (mdev->dev->caps.steering_mode != MLX4_STEERING_MODE_A0)
> dev->priv_flags |= IFF_UNICAST_FLT;
>
> - if (mdev->dev->caps.tunnel_offload_mode ==
> MLX4_TUNNEL_OFFLOAD_MODE_VXLAN) {
> - dev->hw_enc_features |= NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> - NETIF_F_TSO |
> NETIF_F_GSO_UDP_TUNNEL;
> - dev->hw_features |= NETIF_F_GSO_UDP_TUNNEL;
> - dev->features |= NETIF_F_GSO_UDP_TUNNEL;
> - }
> -
> mdev->pndev[port] = dev;
>
> netif_carrier_off(dev);
>
^ permalink raw reply
* Re: [PATCH v2 net] tcp: zero retrans_stamp if all retrans were acked
From: David Miller @ 2014-11-05 22:00 UTC (permalink / raw)
To: ncardwell; +Cc: mleitner, netdev, ycheng, edumazet
In-Reply-To: <CADVnQymMioK0USNpaOF2Kb4+zMTDrjJ7r=5Bu51LbirVQPnzyw@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Tue, 4 Nov 2014 15:10:31 -0500
> On Tue, Nov 4, 2014 at 2:15 PM, Marcelo Ricardo Leitner
> <mleitner@redhat.com> wrote:
> ...
>> Therefore, now we clear retrans_stamp as soon as all data during the
>> loss window is fully acked.
>>
>> Reported-by: Ueki Kohei
>> Cc: Neal Cardwell <ncardwell@google.com>
>> Cc: Yuchung Cheng <ycheng@google.com>
>> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
>> ---
>>
>> Notes:
>> v1->v2: fixed compilation issue noticed by Neal
>>
>> net/ipv4/tcp_input.c | 60 +++++++++++++++++++++++++++-------------------------
>> 1 file changed, 31 insertions(+), 29 deletions(-)
>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Tested-by: Neal Cardwell <ncardwell@google.com>
>
> Code looks fine, and it passes Yuchung's packetdrill test case for this.
>
> Thanks for finding and fixing this, Marcelo.
Applied, thanks everyone.
^ permalink raw reply
* Re: [Patch net-next] ipv6: move INET6_MATCH() to include/net/inet6_hashtables.h
From: David Miller @ 2014-11-05 22:00 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <1415127587-29030-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue, 4 Nov 2014 10:59:47 -0800
> It is only used in net/ipv6/inet6_hashtables.c.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v4] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
From: Cong Wang @ 2014-11-05 22:11 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, lw1a2.jing, netdev, Eric Dumazet,
Hannes Frederic Sowa, David L Stevens
In-Reply-To: <1415215658-10054-1-git-send-email-dborkman@redhat.com>
On Wed, Nov 5, 2014 at 11:27 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> -static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
> +static struct sk_buff *mld_newpack(struct inet6_dev *idev, unsigned int mtu)
For net-next, you probably want to get rid of the 'mtu' parameter,
since all callers use dev->mtu. :)
^ permalink raw reply
* Re: [PATCH] bridge: include in6.h in if_bridge.h for struct in6_addr
From: David Miller @ 2014-11-05 22:13 UTC (permalink / raw)
To: gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
carlos-H+wXaHxf7aLQT0dZR+AlfA, eblake-H+wXaHxf7aLQT0dZR+AlfA,
galak-sgV2jX0FEOL9JmXXK+q4OQ, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1415128881-30183-1-git-send-email-gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Gregory Fong <gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Tue, 4 Nov 2014 11:21:21 -0800
> if_bridge.h uses struct in6_addr ip6, but wasn't including the in6.h
> header. Thomas Backlund originally sent a patch to do this, but this
> revealed a redefinition issue: https://lkml.org/lkml/2013/1/13/116
>
> The redefinition issue should have been fixed by the following Linux
> commits:
> ee262ad827f89e2dc7851ec2986953b5b125c6bc inet: defines IPPROTO_* needed for module alias generation
> cfd280c91253cc28e4919e349fa7a813b63e71e8 net: sync some IP headers with glibc
>
> and the following glibc commit:
> 6c82a2f8d7c8e21e39237225c819f182ae438db3 Coordinate IPv6 definitions for Linux and glibc
>
> so actually include the header now.
>
> Reported-by: Colin Guthrie <colin-odJJhXpcy38dnm+yROfE0A@public.gmane.org>
> Reported-by: Christiaan Welvaart <cjw-CllfUmslCRwdbCeoMzGj59i2O/JbrIOy@public.gmane.org>
> Reported-by: Thomas Backlund <tmb-odJJhXpcy38dnm+yROfE0A@public.gmane.org>
> Cc: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Cong Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Signed-off-by: Gregory Fong <gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied, thank you.
^ permalink raw reply
* Re: Convert net_msg_warn, NETDEBUG, & LIMIT_NETDEBUG?
From: David Miller @ 2014-11-05 22:16 UTC (permalink / raw)
To: realty; +Cc: netdev
In-Reply-To: <1415134000.23168.7.camel@perches.com>
From: Joe Perches <realty@perches.com>
Date: Tue, 04 Nov 2014 12:46:40 -0800
> net_msg_warn is a sysctl used to control the printk
> of a bundle of mostly ipv4/ipv6 logging messages.
>
> Does anyone use it?
...
> Should those KERN_DEBUG uses be converted to
> net_dbg_ratelimited so that these uses could be
> controlled via dynamic_debug instead of the
> net_msg_warn sysctl?
...
I will respond to this by saying that, generally speaking, I'd
rather we move away from local debugging facility and controls
and towards the generic ones.
Definitely kill the allocation failure debug stuff, that's obviously
superfluous and bogus.
It may be the case that we're stuck with the net_msg_warn sysctl
for the stuff that isn't obviously extraneous and removable like
the allocation failure cases.
Why don't we work on these one at a time and see what's left after
all the adjustments/deletions?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 05/13] ethtool,net/mlx4_en: Add 100M, 20G, 56G speeds ethtool reporting support
From: Ben Hutchings @ 2014-11-05 22:38 UTC (permalink / raw)
To: Amir Vadai
Cc: David S. Miller, netdev, Yevgeny Petrilin, Or Gerlitz,
Saeed Mahameed
In-Reply-To: <1414402667-8841-6-git-send-email-amirv@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]
On Mon, 2014-10-27 at 11:37 +0200, Amir Vadai wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
>
> Added 100M, 20G and 56G ethtool speed reporting support.
> Update mlx4_en_test_speed self test with the new speeds.
>
> Defined new link speeds in include/uapi/linux/ethtool.h:
> +#define SPEED_20000 20000
> +#define SPEED_40000 40000
> +#define SPEED_56000 56000
>
> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> Signed-off-by: Amir Vadai <amirv@mellanox.com>
[...]
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -1213,6 +1213,10 @@ enum ethtool_sfeatures_retval_bits {
> #define SUPPORTED_40000baseCR4_Full (1 << 24)
> #define SUPPORTED_40000baseSR4_Full (1 << 25)
> #define SUPPORTED_40000baseLR4_Full (1 << 26)
> +#define SUPPORTED_56000baseKR4_Full (1 << 27)
> +#define SUPPORTED_56000baseCR4_Full (1 << 28)
> +#define SUPPORTED_56000baseSR4_Full (1 << 29)
> +#define SUPPORTED_56000baseLR4_Full (1 << 30)
>
> #define ADVERTISED_10baseT_Half (1 << 0)
> #define ADVERTISED_10baseT_Full (1 << 1)
> @@ -1241,6 +1245,10 @@ enum ethtool_sfeatures_retval_bits {
> #define ADVERTISED_40000baseCR4_Full (1 << 24)
> #define ADVERTISED_40000baseSR4_Full (1 << 25)
> #define ADVERTISED_40000baseLR4_Full (1 << 26)
> +#define ADVERTISED_56000baseKR4_Full (1 << 27)
> +#define ADVERTISED_56000baseCR4_Full (1 << 28)
> +#define ADVERTISED_56000baseSR4_Full (1 << 29)
> +#define ADVERTISED_56000baseLR4_Full (1 << 30)
Can these modes be auto-negotiated? If not then they don't need
advertised/supported bits.
> /* The following are all involved in forcing a particular link
> * mode for the device for setting things. When getting the
> @@ -1248,12 +1256,16 @@ enum ethtool_sfeatures_retval_bits {
> * it was forced up into this mode or autonegotiated.
> */
>
> -/* The forced speed, 10Mb, 100Mb, gigabit, 2.5Gb, 10GbE. */
> +/* The forced speed, 10Mb, 100Mb, gigabit, [2.5|10|20|40|56]GbE. */
> #define SPEED_10 10
> #define SPEED_100 100
> #define SPEED_1000 1000
> #define SPEED_2500 2500
> #define SPEED_10000 10000
> +#define SPEED_20000 20000
> +#define SPEED_40000 40000
> +#define SPEED_56000 56000
We shouldn't add new SPEED macros. The speed is just a number of Mbit/s
and we don't need to enumerate the possible values.
Ben.
> #define SPEED_UNKNOWN -1
>
> /* Duplex, half or full. */
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* [PATCH net-next] net; ipv[46] - Remove 2 unnecessary NETDEBUG OOM messages
From: Joe Perches @ 2014-11-05 22:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141105.171623.1142237070388305283.davem@davemloft.net>
These messages aren't useful as there's a generic dump_stack()
on OOM.
Neaten the comment and if test above the OOM by separating the
assign in if into an allocation then if test.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/ipv4/ip_output.c | 8 +++-----
net/ipv6/ip6_output.c | 10 ++++------
2 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index bc6471d..4a929ad 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -662,12 +662,10 @@ slow_path:
if (len < left) {
len &= ~7;
}
- /*
- * Allocate buffer.
- */
- if ((skb2 = alloc_skb(len+hlen+ll_rs, GFP_ATOMIC)) == NULL) {
- NETDEBUG(KERN_INFO "IP: frag: no memory for new fragment!\n");
+ /* Allocate buffer */
+ skb2 = alloc_skb(len + hlen + ll_rs, GFP_ATOMIC);
+ if (!skb2) {
err = -ENOMEM;
goto fail;
}
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8e950c2..916d2a1 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -747,13 +747,11 @@ slow_path:
if (len < left) {
len &= ~7;
}
- /*
- * Allocate buffer.
- */
- if ((frag = alloc_skb(len + hlen + sizeof(struct frag_hdr) +
- hroom + troom, GFP_ATOMIC)) == NULL) {
- NETDEBUG(KERN_INFO "IPv6: frag: no memory for new fragment!\n");
+ /* Allocate buffer */
+ frag = alloc_skb(len + hlen + sizeof(struct frag_hdr) +
+ hroom + troom, GFP_ATOMIC);
+ if (!frag) {
IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
IPSTATS_MIB_FRAGFAILS);
err = -ENOMEM;
^ permalink raw reply related
* Re: [PATCH net v4] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
From: Daniel Borkmann @ 2014-11-05 22:46 UTC (permalink / raw)
To: Cong Wang
Cc: David Miller, lw1a2.jing, netdev, Eric Dumazet,
Hannes Frederic Sowa, David L Stevens
In-Reply-To: <CAHA+R7NKPvhut_K+xgtyJqd=a8Y=dfU80e8C7Jo1qgTdg=2ubg@mail.gmail.com>
On 11/05/2014 11:11 PM, Cong Wang wrote:
> On Wed, Nov 5, 2014 at 11:27 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> -static struct sk_buff *mld_newpack(struct inet6_dev *idev, int size)
>> +static struct sk_buff *mld_newpack(struct inet6_dev *idev, unsigned int mtu)
>
> For net-next, you probably want to get rid of the 'mtu' parameter,
> since all callers use dev->mtu. :)
Yeah, feel free. ;) Probably for the longer term it might make sense to
look into ways to refactor and unify some of the more generic portions of
the IGMP/MLD code.
^ permalink raw reply
* Re: [GIT net-next] Open vSwitch
From: Pravin Shelar @ 2014-11-05 22:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141105.151047.1621156460688575485.davem@davemloft.net>
On Wed, Nov 5, 2014 at 12:10 PM, David Miller <davem@davemloft.net> wrote:
>
> Please do not submit your patches such that the email Date: field is
> the commit's date. You're not posting these on Nov. 4th, yet that
> is the Date: field on all of the individual patch emails.
>
> I want them to be the date at the time you post the patch to the mailing
> list.
>
> Otherwise the ordering in patchwork is not cronological wrt. the list's
> postings and this makes my work more difficult than it needs to be.
>
Sorry about the Date field. NTP stopped working on my machine thats
why the date got messed up.
^ 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