* Re: [PATCH net-next] net: phy: realtek: add missing entry for RTL8211C to mdio_device_id table
From: David Miller @ 2018-07-16 20:36 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <8308f8ec-364d-736d-72e5-b0678cf4d6e4@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 12 Jul 2018 21:45:08 +0200
> Add missing entry for RTL8211C to mdio_device_id table.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Fixes: cf87915cb9f8 ("net: phy: realtek: add support for RTL8211C")
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: phy: add functionality to speed down PHY when waiting for WoL packet
From: David Miller @ 2018-07-16 20:35 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <960fde9d-3a1a-3976-7f93-3d8835fd8c42@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Thu, 12 Jul 2018 21:30:19 +0200
> Some network drivers include functionality to speed down the PHY when
> suspending and just waiting for a WoL packet because this saves energy.
>
> This patch is based on our recent discussion about factoring out this
> functionality to phylib. First user will be the r8169 driver.
>
> v2:
> - add warning comment to phy_speed_down regarding usage of sync = false
> - remove sync parameter from phy_speed_up
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] selftests: tls: add selftests for TLS sockets
From: David Miller @ 2018-07-16 20:33 UTC (permalink / raw)
To: davejwatson; +Cc: borisp, netdev, aviadye, daniel, vakul.garg
In-Reply-To: <20180712175920.GA44742@macbook-pro-6.local.dhcp.thefacebook.com>
From: Dave Watson <davejwatson@fb.com>
Date: Thu, 12 Jul 2018 10:59:20 -0700
> Add selftests for tls socket. Tests various iov and message options,
> poll blocking and nonblocking behavior, partial message sends / receives,
> and control message data. Tests should pass regardless of if TLS
> is enabled in the kernel or not, and print a warning message if not.
>
> Signed-off-by: Dave Watson <davejwatson@fb.com>
This is great, thanks Dave!
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 3/3] ravb: fix byte order for TX descriptor tag field lower bits
From: Geert Uytterhoeven @ 2018-07-16 20:32 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Niklas Söderlund, netdev, Linux-Renesas
In-Reply-To: <177386eb-037b-57f8-6c40-027e09db67f9@cogentembedded.com>
Hi Sergei,
On Mon, Jul 16, 2018 at 10:22 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> On 07/16/2018 10:52 PM, Sergei Shtylyov wrote:
> >> The wrong helper is used to swap the bytes when adding the lower bits of
> >> the TX descriptors tag field in the shared ds_tagl variable. The
> >> variable contains the DS[11:0] field and then the TAG[3:0] bits.
> >>
> >> The mistake was highlighted by the sparse warning:
> >>
> >> ravb_main.c:1622:31: left side has type restricted __le16
> >> ravb_main.c:1622:31: right side has type unsigned short
> >> ravb_main.c:1622:31: warning: invalid assignment: |=
> >> ravb_main.c:1622:34: warning: cast to restricted __le16
> >
> > Again, it's good that it's not a real bug! :-)
>
> Wait! It seems to be, according to your subject. I hope you understand that
Niklas' patch fixes the sparse warning.
> cpu_to_le16() and le16_to_cpu() do the same thing?
While they do the same thing, they don't take the same parameter types,
nor return the same types.
E.g. cpu_to_le16() takes a u16 and returns an __le16, le16_to_cpu() takes
an __le16, and returns a u16.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net] tls: Stricter error checking in zerocopy sendmsg path
From: David Miller @ 2018-07-16 20:32 UTC (permalink / raw)
To: davejwatson; +Cc: borisp, netdev, aviadye, daniel, doronrk, vakul.garg
In-Reply-To: <20180712150343.GA19138@macbook-pro-6.local.dhcp.thefacebook.com>
From: Dave Watson <davejwatson@fb.com>
Date: Thu, 12 Jul 2018 08:03:43 -0700
> In the zerocopy sendmsg() path, there are error checks to revert
> the zerocopy if we get any error code. syzkaller has discovered
> that tls_push_record can return -ECONNRESET, which is fatal, and
> happens after the point at which it is safe to revert the iter,
> as we've already passed the memory to do_tcp_sendpages.
>
> Previously this code could return -ENOMEM and we would want to
> revert the iter, but AFAIK this no longer returns ENOMEM after
> a447da7d004 ("tls: fix waitall behavior in tls_sw_recvmsg"),
> so we fail for all error codes.
>
> Reported-by: syzbot+c226690f7b3126c5ee04@syzkaller.appspotmail.com
> Reported-by: syzbot+709f2810a6a05f11d4d3@syzkaller.appspotmail.com
> Signed-off-by: Dave Watson <davejwatson@fb.com>
> Fixes: 3c4d7559159b ("tls: kernel TLS support")
Applied and queued up for -stable, thanks Dave.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/7] Make /sys/class/net per net namespace objects belong to container
From: David Miller @ 2018-07-16 20:58 UTC (permalink / raw)
To: tyhicks
Cc: gregkh, tj, stephen, dmitry.torokhov, ebiederm, linux-kernel,
netdev, bridge, containers
In-Reply-To: <1531497949-1766-1-git-send-email-tyhicks@canonical.com>
From: Tyler Hicks <tyhicks@canonical.com>
Date: Fri, 13 Jul 2018 16:05:42 +0000
> Eric had previously provided feedback that he didn't favor these changes
> affecting all layers of the stack and that most of the changes could
> remain local to drivers/base/core.c. That feedback is certainly sensible
> but I wanted to send out v2 of the patch set without making that large
> of a change since quite a bit of time has passed and the bridge changes
> in the last patch of this set shows that not all of the changes will be
> local to drivers/base/core.c. I'm happy to make the changes if the
> original request still stands.
I'd like to give Eric an opportunity to review this and give feedback
before applying.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/3] ravb: fix byte order for TX descriptor tag field lower bits
From: Sergei Shtylyov @ 2018-07-16 20:22 UTC (permalink / raw)
To: Niklas Söderlund, netdev; +Cc: linux-renesas-soc
In-Reply-To: <fa8eec6c-fb0b-cb44-a891-e09d5b738672@cogentembedded.com>
On 07/16/2018 10:52 PM, Sergei Shtylyov wrote:
>> The wrong helper is used to swap the bytes when adding the lower bits of
>> the TX descriptors tag field in the shared ds_tagl variable. The
>> variable contains the DS[11:0] field and then the TAG[3:0] bits.
>>
>> The mistake was highlighted by the sparse warning:
>>
>> ravb_main.c:1622:31: left side has type restricted __le16
>> ravb_main.c:1622:31: right side has type unsigned short
>> ravb_main.c:1622:31: warning: invalid assignment: |=
>> ravb_main.c:1622:34: warning: cast to restricted __le16
>
> Again, it's good that it's not a real bug! :-)
Wait! It seems to be, according to your subject. I hope you understand that
cpu_to_le16() and le16_to_cpu() do the same thing?
>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> [...]
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] net: mscc: simplify retrieving the tag type from the frame header
From: David Miller @ 2018-07-16 20:44 UTC (permalink / raw)
To: antoine.tenart
Cc: f.fainelli, andrew, netdev, linux-kernel, thomas.petazzoni,
alexandre.belloni, quentin.schulz, allan.nielsen
In-Reply-To: <20180713145757.3574-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 13 Jul 2018 16:57:57 +0200
> The tag type in the frame extraction header is only a bit wide. There's
> no need to use GENMASK when retrieving the information. This patch
> simplify the code by dropping GENMASK and using BIT instead.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ethernet: stmmac: fix documentation warning
From: David Miller @ 2018-07-16 20:43 UTC (permalink / raw)
To: clabbe; +Cc: alexandre.torgue, peppe.cavallaro, linux-kernel, netdev
In-Reply-To: <1531482615-12905-1-git-send-email-clabbe@baylibre.com>
From: Corentin Labbe <clabbe@baylibre.com>
Date: Fri, 13 Jul 2018 11:50:15 +0000
> This patch remove the following documentation warning
> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:103: warning: Excess function parameter 'priv' description in 'stmmac_axi_setup'
> It was introduced in commit afea03656add7 ("stmmac: rework DMA bus setting and introduce new platform AXI structure")
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: dwmac-sun8i: fix typo descrive => describe
From: David Miller @ 2018-07-16 20:43 UTC (permalink / raw)
To: clabbe-rdvid1DuHRBWk0Htik3J/w
Cc: alexandre.torgue-qxv4g6HH51o,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
peppe.cavallaro-qxv4g6HH51o, wens-jdAy2FN1RRM,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <1531482522-10824-1-git-send-email-clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
From: Corentin Labbe <clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Date: Fri, 13 Jul 2018 11:48:42 +0000
> This patch fix a typo in the word Describe
> Signed-off-by: Corentin Labbe <clabbe-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnxt_en: remove redundant debug register dma mem allocation
From: David Miller @ 2018-07-16 20:38 UTC (permalink / raw)
To: yuehaibing; +Cc: michael.chan, linux-kernel, netdev
In-Reply-To: <20180713030204.884-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 13 Jul 2018 11:02:04 +0800
> hwrm_dbg_resp_addr and hwrm_dbg_resp_dma_addr are never used
> and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2] net: usb: hso: use swap macro in hso_kick_transmit
From: David Miller @ 2018-07-16 20:35 UTC (permalink / raw)
To: gustavo; +Cc: linux-usb, netdev, linux-kernel
In-Reply-To: <20180712194320.GA26098@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Thu, 12 Jul 2018 14:43:20 -0500
> Make use of the swap macro and remove unnecessary variable *temp*.
> This makes the code easier to read and maintain. Also, slightly
> refactor some code due to the removal of *temp*.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> Changes in v2:
> - Check serial->tx_data instead of temp.
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] bonding: Fix a typo in bonxing.txt
From: David Miller @ 2018-07-16 20:32 UTC (permalink / raw)
To: standby24x7; +Cc: corbet, netdev, j.vosburgh, vfalico, andy, linux-kernel
In-Reply-To: <20180712160517.7382-1-standby24x7@gmail.com>
From: Masanari Iida <standby24x7@gmail.com>
Date: Fri, 13 Jul 2018 01:05:17 +0900
> This patch fixes a spelling typo in bonding.txt
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Applied with Subject typo fixed.
^ permalink raw reply
* [net-next:master 717/734] drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
From: kbuild test robot @ 2018-07-16 20:00 UTC (permalink / raw)
To: Boris Pismenny; +Cc: kbuild-all, netdev
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 568a74d491124c720e604ed3265722f969a5fb38
commit: afd3baaa938ce85dc738cd9279716cdb684cc707 [717/734] net/mlx5e: TLS, add software statistics
reproduce:
# apt-get install sparse
git checkout afd3baaa938ce85dc738cd9279716cdb684cc707
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
>> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:173:21: sparse: cast to restricted __be64
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:174:52: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int [unsigned] [usertype] handle @@ got ed int [unsigned] [usertype] handle @@
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:174:52: expected unsigned int [unsigned] [usertype] handle
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:174:52: got restricted __be32 [usertype] handle
vim +173 drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c
162
163 static void mlx5e_tls_resync_rx(struct net_device *netdev, struct sock *sk,
164 u32 seq, u64 rcd_sn)
165 {
166 struct tls_context *tls_ctx = tls_get_ctx(sk);
167 struct mlx5e_priv *priv = netdev_priv(netdev);
168 struct mlx5e_tls_offload_context_rx *rx_ctx;
169
170 rx_ctx = mlx5e_get_tls_rx_context(tls_ctx);
171
172 netdev_info(netdev, "resyncing seq %d rcd %lld\n", seq,
> 173 be64_to_cpu(rcd_sn));
174 mlx5_accel_tls_resync_rx(priv->mdev, rx_ctx->handle, seq, rcd_sn);
175 atomic64_inc(&priv->tls->sw_stats.rx_tls_resync_reply);
176 }
177
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH resend -next] lib/rhashtable: consider param->min_size when setting initial table size
From: Davidlohr Bueso @ 2018-07-16 20:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: akpm, tgraf, linux-kernel, Davidlohr Bueso, netdev
In-Reply-To: <20180716000046.yscgnpr256qhm2qg@gondor.apana.org.au>
rhashtable_init() currently does not take into account the user-passed
min_size parameter unless param->nelem_hint is set as well. As such,
the default size (number of buckets) will always be HASH_DEFAULT_SIZE
even if the smallest allowed size is larger than that. Remediate this
by unconditionally calling into rounded_hashtable_size() and handling
things accordingly.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
---
Resending per Herbert's request with Cc to netdev.
lib/rhashtable.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 62d3a976614e..310e29b51507 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -953,8 +953,16 @@ EXPORT_SYMBOL_GPL(rhashtable_walk_stop);
static size_t rounded_hashtable_size(const struct rhashtable_params *params)
{
- return max(roundup_pow_of_two(params->nelem_hint * 4 / 3),
- (unsigned long)params->min_size);
+ size_t retsize;
+
+ if (params->nelem_hint)
+ retsize = max(roundup_pow_of_two(params->nelem_hint * 4 / 3),
+ (unsigned long)params->min_size);
+ else
+ retsize = max(HASH_DEFAULT_SIZE,
+ (unsigned long)params->min_size);
+
+ return retsize;
}
static u32 rhashtable_jhash2(const void *key, u32 length, u32 seed)
@@ -1010,8 +1018,6 @@ int rhashtable_init(struct rhashtable *ht,
struct bucket_table *tbl;
size_t size;
- size = HASH_DEFAULT_SIZE;
-
if ((!params->key_len && !params->obj_hashfn) ||
(params->obj_hashfn && !params->obj_cmpfn))
return -EINVAL;
@@ -1035,8 +1041,7 @@ int rhashtable_init(struct rhashtable *ht,
ht->p.min_size = max_t(u16, ht->p.min_size, HASH_MIN_SIZE);
- if (params->nelem_hint)
- size = rounded_hashtable_size(&ht->p);
+ size = rounded_hashtable_size(&ht->p);
if (params->locks_mul)
ht->p.locks_mul = roundup_pow_of_two(params->locks_mul);
--
2.16.4
^ permalink raw reply related
* Re: [RFC] Add BPF_SYNCHRONIZE bpf(2) command
From: Joel Fernandes @ 2018-07-16 20:23 UTC (permalink / raw)
To: Daniel Colascione
Cc: Alexei Starovoitov, Lorenzo Colitti, Chenbo Feng,
Mathieu Desnoyers, Joel Fernandes, Alexei Starovoitov, lkml,
Tim Murray, Daniel Borkmann, netdev
In-Reply-To: <CAKOZuetwbE2HSa7vfVoVYwSqfz0ZcNWO93Y=pcJ-q4uEWHSuNg@mail.gmail.com>
On Mon, Jul 16, 2018 at 08:29:47AM -0700, Daniel Colascione wrote:
> On Sat, Jul 14, 2018 at 11:18 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
> > On Tue, Jul 10, 2018 at 08:40:19PM -0700, Alexei Starovoitov wrote:
> > [..]
> >> > The kernel program might do:
> >> >
> >> > =====
> >> > const int current_map_key = 1;
> >> > void *current_map = bpf_map_lookup_elem(outer_map, ¤t_map_key);
> >> >
> >> > int stats_key = 42;
> >> > uint64_t *stats_value = bpf_map_lookup_elem(current_map, &stats_key);
> >> > __sync_fetch_and_add(&stats_value, 1);
> >> > =====
> >> >
> >> > If a userspace does:
> >> >
> >> > 1. Write new fd to outer_map[1].
> >> > 2. Call BPF_SYNC_MAP_ACCESS.
> >> > 3. Start deleting everything in the old map.
> >> >
> >> > How can we guarantee that the __sync_fetch_and_add will not add to the
> >> > old map?
> >>
> >> without any changes to the kernel sys_membarrier will work.
> >> And that's what folks use already.
> >> BPF_SYNC_MAP_ACCESS implemented via synchronize_rcu() will work
> >> as well whether in the current implementation where rcu_lock/unlock
> >> is done outside of the program and in the future when
> >> rcu_lock/unlock are called by the program itself.
> >
> > Cool Alexei and Lorenzo, sounds great to me. Daniel want to send a follow up
> > patch with BPF_SYNC_MAP_ACCESS changes then?
>
> Will do. Mind if I just mine this thread for the doc comment?
Do you mean the changelog? Yes I believe you could use the discussion in this
thread for the rationale as Alexei described.
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH 3/3] ravb: fix byte order for TX descriptor tag field lower bits
From: Sergei Shtylyov @ 2018-07-16 19:52 UTC (permalink / raw)
To: Niklas Söderlund, netdev; +Cc: linux-renesas-soc
In-Reply-To: <20180716121927.21918-4-niklas.soderlund+renesas@ragnatech.se>
On 07/16/2018 03:19 PM, Niklas Söderlund wrote:
> The wrong helper is used to swap the bytes when adding the lower bits of
> the TX descriptors tag field in the shared ds_tagl variable. The
> variable contains the DS[11:0] field and then the TAG[3:0] bits.
>
> The mistake was highlighted by the sparse warning:
>
> ravb_main.c:1622:31: left side has type restricted __le16
> ravb_main.c:1622:31: right side has type unsigned short
> ravb_main.c:1622:31: warning: invalid assignment: |=
> ravb_main.c:1622:34: warning: cast to restricted __le16
Again, it's good that it's not a real bug! :-)
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* photos
From: Simon Dike @ 2018-07-16 13:17 UTC (permalink / raw)
To: netdev
We can process 400+ images per day.
If you need any image editing, please let us know.
Photos cut out;
Photos clipping path;
Photos masking;
Photo shadow creation;
Photos retouching;
Beauty Model retouching on skin, face, body;
Glamour retouching;
Products retouching.
We can give you testing for your photos.
Turnaround time is fast
Thanks,
Simon
^ permalink raw reply
* Re: [PATCH 2/3] ravb: fix warning about memcpy length
From: Sergei Shtylyov @ 2018-07-16 19:18 UTC (permalink / raw)
To: Niklas Söderlund, netdev; +Cc: linux-renesas-soc
In-Reply-To: <20180716121927.21918-3-niklas.soderlund+renesas@ragnatech.se>
On 07/16/2018 03:19 PM, Niklas Söderlund wrote:
> This fixes sparse warning:
>
> ravb_main.c:1257 ravb_get_strings() error: memcpy() '*ravb_gstrings_stats' too small (32 vs 960)
It's good that's not a real bug! :-)
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/3] ravb: fix shadowing of symbol 'stats' in ravb_get_ethtool_stats()
From: Sergei Shtylyov @ 2018-07-16 19:08 UTC (permalink / raw)
To: Niklas Söderlund, netdev; +Cc: linux-renesas-soc
In-Reply-To: <20180716121927.21918-2-niklas.soderlund+renesas@ragnatech.se>
On 07/16/2018 03:19 PM, Niklas Söderlund wrote:
> Inside a loop in ravb_get_ethtool_stats() a variable 'stats' is declared
> resulting in the argument also named 'stats' to be shadowed. Fix this
> warning by renaming the unused argument 'stats' to 'estats'.
>
> This fixes the sparse warning:
>
> ravb_main.c:1225:36: originally declared here
> ravb_main.c:1233:41: warning: symbol 'stats' shadows an earlier one
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[...]
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
MBR, Sergei
^ permalink raw reply
* RE: tc mqprio offload command error
From: Chopra, Manish @ 2018-07-16 18:46 UTC (permalink / raw)
To: Jesus Sanchez-Palencia, Alexander Duyck
Cc: Stephen Hemminger, David Miller, Jiri Pirko,
netdev@vger.kernel.org
In-Reply-To: <48e85e30-ab4c-fa07-463e-d10ac14327d3@intel.com>
> -----Original Message-----
> From: Jesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
> Sent: Monday, July 16, 2018 11:28 PM
> To: Alexander Duyck <alexander.duyck@gmail.com>; Chopra, Manish
> <Manish.Chopra@cavium.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; David Miller
> <davem@davemloft.net>; Jiri Pirko <jiri@resnulli.us>;
> netdev@vger.kernel.org
> Subject: Re: tc mqprio offload command error
>
> External Email
>
> Hi,
>
>
> On 07/16/2018 10:20 AM, Alexander Duyck wrote:
> > On Sun, Jul 15, 2018 at 6:30 PM, Chopra, Manish
> > <Manish.Chopra@cavium.com> wrote:
> >> Hello Folks,
> >>
> >> I am trying to set below command to try mqprio offload on 4.18 kernel. It
> is throwing the flowing error.
> >>
> >> # tc qdisc add dev eth0 root mqprio num_tc 2 map 1 1 1 1 0 0 0 0
> >> RTNETLINK answers: Numerical result out of range
> >>
> >> I can't really make out what's wrong with the above command, since this
> works fine with other OS kernels.
> >> Any thoughts if it is something broken on upstream kernel ?
> >>
> >> Thanks,
> >> Manish
> >
> > You might need to specify the traffic class for the 8 remaining
> > priorities. The full map size is 16 entries, not just 8. The default
> > value for the last 4 mapping entries is TC 3 which would be out of
> > range if you only have 2 TCs specified.
>
>
> In addition to that, you might hit the same bug we brought up [1] a while
> ago.
> If that is the case, a fix was just proposed here [2]. Note that other qdiscs
> might be broken as well, but we could only spot the issue with mqprio and
> netem so far.
>
> [1] https://patchwork.ozlabs.org/patch/867860/#1893405
> [2] https://patchwork.ozlabs.org/patch/944565/
>
>
Issue is same with all of 16 prio-tc map supplied -
# tc qdisc add dev eth0 root mqprio num_tc 4 map 1 1 1 1 0 0 0 0 2 2 2 2 3 3 3 3
RTNETLINK answers: Numerical result out of range
Thanks Jesus, I will try the fix[2] and see.
Regards
-Manish
^ permalink raw reply
* Re: [PATCH net v2] KEYS: DNS: fix parsing multiple options
From: David Miller @ 2018-07-16 18:22 UTC (permalink / raw)
To: ebiggers3; +Cc: netdev, keyrings, dhowells, wang840925, ebiggers
In-Reply-To: <20180711174629.2700-1-ebiggers3@gmail.com>
From: Eric Biggers <ebiggers3@gmail.com>
Date: Wed, 11 Jul 2018 10:46:29 -0700
> From: Eric Biggers <ebiggers@google.com>
>
> My recent fix for dns_resolver_preparse() printing very long strings was
> incomplete, as shown by syzbot which still managed to hit the
> WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
>
> precision 50001 too large
> WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
>
> The bug this time isn't just a printing bug, but also a logical error
> when multiple options ("#"-separated strings) are given in the key
> payload. Specifically, when separating an option string into name and
> value, if there is no value then the name is incorrectly considered to
> end at the end of the key payload, rather than the end of the current
> option. This bypasses validation of the option length, and also means
> that specifying multiple options is broken -- which presumably has gone
> unnoticed as there is currently only one valid option anyway.
>
> A similar problem also applied to option values, as the kstrtoul() when
> parsing the "dnserror" option will read past the end of the current
> option and into the next option.
>
> Fix these bugs by correctly computing the length of the option name and
> by copying the option value, null-terminated, into a temporary buffer.
>
> Reproducer for the WARN_ONCE() that syzbot hit:
>
> perl -e 'print "#A#", "\0" x 50000' | keyctl padd dns_resolver desc @s
>
> Reproducer for "dnserror" option being parsed incorrectly (expected
> behavior is to fail when seeing the unknown option "foo", actual
> behavior was to read the dnserror value as "1#foo" and fail there):
>
> perl -e 'print "#dnserror=1#foo\0"' | keyctl padd dns_resolver desc @s
>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>
> Changed since v1:
> - Also fix parsing the option values, not just option names.
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCHv2 net 0/2] multicast: init as INCLUDE when join SSM INCLUDE group
From: David Miller @ 2018-07-16 18:20 UTC (permalink / raw)
To: liuhangbin
Cc: netdev, sbrivio, pabeni, daniel, xiyou.wangcong,
hideaki.yoshifuji, fbl
In-Reply-To: <1531233687-28744-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Tue, 10 Jul 2018 22:41:25 +0800
> Based on RFC3376 5.1 and RFC3810 6.1, we should init as INCLUDE when join SSM
> INCLUDE group. In my first version I only clear the group change record. But
> this is not enough as when a new group join, it will init as EXCLUDE and
> trigger an filter mode change in ip/ip6_mc_add_src(), which will clear all
> source addresses' sf_crcount. This will prevent early joined address sending
> state change records if multi source addresses joined at the same time.
>
> In this v2 patchset, I fixed it by directly initializing the mode to INCLUDE
> for SSM JOIN_SOURCE_GROUP. I also split the original patch into two separated
> patches for IPv4 and IPv6.
>
> Test: test by myself and customer.
Series applied, thanks!
^ permalink raw reply
* Re: tc mqprio offload command error
From: Jesus Sanchez-Palencia @ 2018-07-16 17:57 UTC (permalink / raw)
To: Alexander Duyck, Chopra, Manish
Cc: Stephen Hemminger, David Miller, Jiri Pirko,
netdev@vger.kernel.org
In-Reply-To: <CAKgT0UfdckbsMDM3-uF4gOCumvDmFx6eWFuJx9_oKKUyEVApCA@mail.gmail.com>
Hi,
On 07/16/2018 10:20 AM, Alexander Duyck wrote:
> On Sun, Jul 15, 2018 at 6:30 PM, Chopra, Manish
> <Manish.Chopra@cavium.com> wrote:
>> Hello Folks,
>>
>> I am trying to set below command to try mqprio offload on 4.18 kernel. It is throwing the flowing error.
>>
>> # tc qdisc add dev eth0 root mqprio num_tc 2 map 1 1 1 1 0 0 0 0
>> RTNETLINK answers: Numerical result out of range
>>
>> I can't really make out what's wrong with the above command, since this works fine with other OS kernels.
>> Any thoughts if it is something broken on upstream kernel ?
>>
>> Thanks,
>> Manish
>
> You might need to specify the traffic class for the 8 remaining
> priorities. The full map size is 16 entries, not just 8. The default
> value for the last 4 mapping entries is TC 3 which would be out of
> range if you only have 2 TCs specified.
In addition to that, you might hit the same bug we brought up [1] a while ago.
If that is the case, a fix was just proposed here [2]. Note that other qdiscs
might be broken as well, but we could only spot the issue with mqprio and netem
so far.
[1] https://patchwork.ozlabs.org/patch/867860/#1893405
[2] https://patchwork.ozlabs.org/patch/944565/
Regards,
Jesus
>
> - Alex
>
^ permalink raw reply
* Re: [PATCH net-next 0/2] docs: Fix failover build warnings
From: David Miller @ 2018-07-16 18:28 UTC (permalink / raw)
To: me; +Cc: sridhar.samudrala, linux-doc, netdev, linux-kernel
In-Reply-To: <20180711214250.19039-1-me@tobin.cc>
From: "Tobin C. Harding" <me@tobin.cc>
Date: Thu, 12 Jul 2018 07:42:48 +1000
> This is my first patch set to net-next. Please shout loud and clear if
> I've botched anything.
>
> Recently failover and net_failover modules were added to the mainline.
> Documentation was included in rst format but they were not added to the
> toctree in `networking/index.rst`. Also building docs for net_failover
> is currently emitting a few warnings.
>
> Patch 1 adds failover and net_failover to the index toctree
> Patch 2 fixes the build warnings for net_failover
>
> I haven't been super active on netdev list so if there is some reason I
> missed why these files are not in the index please do say so.
>
> Has there been any discussion on preferred order for the toctree index
> list? I just added them to the bottom of the list.
Series applied, thanks.
^ 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