Netdev List
 help / color / mirror / Atom feed
* [PATCH net 1/2] bpf/verifier: fix bounds calculation on BPF_RSH
From: Edward Cree @ 2017-12-05 19:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <7c4a1470-3cf1-ceae-c99f-6591f1882063@solarflare.com>

Incorrect signed bounds were being computed, although this had no effect
 since the propagation in __reg_deduce_bounds() happened to overwrite them.

Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
 kernel/bpf/verifier.c | 30 ++++++++++++++++--------------
 1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d4593571c404..5bed7f773c87 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2184,20 +2184,22 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
 			mark_reg_unknown(env, regs, insn->dst_reg);
 			break;
 		}
-		/* BPF_RSH is an unsigned shift, so make the appropriate casts */
-		if (dst_reg->smin_value < 0) {
-			if (umin_val) {
-				/* Sign bit will be cleared */
-				dst_reg->smin_value = 0;
-			} else {
-				/* Lost sign bit information */
-				dst_reg->smin_value = S64_MIN;
-				dst_reg->smax_value = S64_MAX;
-			}
-		} else {
-			dst_reg->smin_value =
-				(u64)(dst_reg->smin_value) >> umax_val;
-		}
+		/* BPF_RSH is an unsigned shift.  If the value in dst_reg might
+		 * be negative, then either:
+		 * 1) src_reg might be zero, so the sign bit of the result is
+		 *    unknown, so we lose our signed bounds
+		 * 2) it's known negative, thus the unsigned bounds capture the
+		 *    signed bounds
+		 * 3) the signed bounds cross zero, so they tell us nothing
+		 *    about the result
+		 * If the value in dst_reg is known nonnegative, then again the
+		 * unsigned bounts capture the signed bounds.
+		 * Thus, in all cases it suffices to blow away our signed bounds
+		 * and rely on inferring new ones from the unsigned bounds and
+		 * var_off of the result.
+		 */
+		dst_reg->smin_value = S64_MIN;
+		dst_reg->smax_value = S64_MAX;
 		if (src_known)
 			dst_reg->var_off = tnum_rshift(dst_reg->var_off,
 						       umin_val);

^ permalink raw reply related

* [PATCH net 2/2] selftests/bpf: Add a test for shifts of values that might be negative
From: Edward Cree @ 2017-12-05 19:15 UTC (permalink / raw)
  To: davem; +Cc: netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <7c4a1470-3cf1-ceae-c99f-6591f1882063@solarflare.com>

Signed-off-by: Edward Cree <ecree@solarflare.com>
---
 tools/testing/selftests/bpf/test_align.c | 39 ++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
index 8591c89c0828..24c6757b4c51 100644
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -601,6 +601,45 @@ static struct bpf_align_test tests[] = {
 			{20, "R5=pkt(id=2,off=0,r=4,umin_value=2,umax_value=1082,var_off=(0x2; 0x7fc))"},
 		},
 	},
+	{
+		.descr = "unknown shift negative",
+		/* This isn't really a test of the alignment code, rather of the
+		 * signed min/max value handling, but it makes use of the
+		 * register-state-extracting code in do_test_single(), which
+		 * test_verifier.c doesn't have.
+		 */
+		.insns = {
+			LOAD_UNKNOWN(BPF_REG_3),
+			BPF_ALU64_IMM(BPF_SUB, BPF_REG_3, 0xff),
+			BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
+			LOAD_UNKNOWN(BPF_REG_4),
+			BPF_ALU64_IMM(BPF_SUB, BPF_REG_4, 0xff),
+			BPF_MOV64_REG(BPF_REG_5, BPF_REG_4),
+			BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
+			BPF_ALU64_IMM(BPF_SUB, BPF_REG_5, 1),
+			BPF_ALU64_IMM(BPF_RSH, BPF_REG_5, 1),
+			BPF_MOV64_IMM(BPF_REG_0, 0),
+			BPF_EXIT_INSN(),
+		},
+		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
+		.matches = {
+			{7, "R0=pkt(id=0,off=8,r=8,imm=0)"},
+			{7, "R3=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
+			{8, "R3=inv(id=0,smin_value=-255,smax_value=0)"},
+			/* All the verifier knows is, it's even.  While we could
+			 * conclude something tighter (the sign bit does not
+			 * change), the verifier doesn't bother right now.
+			 */
+			{9, "R3=inv(id=0,smax_value=9223372036854775806,umax_value=18446744073709551614,var_off=(0x0; 0xfffffffffffffffe))"},
+			{16, "R3=pkt_end(id=0,off=0,imm=0)"},
+			{16, "R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
+			{17, "R4=inv(id=0,smin_value=-255,smax_value=0)"},
+			/* both 0 and 0x7f...fff are possible */
+			{19, "R4=inv(id=0,umax_value=9223372036854775807,var_off=(0x0; 0x7fffffffffffffff))"},
+			{20, "R5=inv(id=0,umin_value=18446744073709551360,var_off=(0xffffffffffffff00; 0xff))"},
+			{21, "R5=inv(id=0,umin_value=9223372036854775680,umax_value=9223372036854775807,var_off=(0x7fffffffffffff80; 0x7f))"},
+		},
+	},
 };
 
 static int probe_filter_length(const struct bpf_insn *fp)

^ permalink raw reply related

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Peter Zijlstra @ 2017-12-05 19:17 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Paul E. McKenney, linux-kernel, mingo, jiangshanlai, dipankar,
	akpm, mathieu.desnoyers, josh, tglx, rostedt, dhowells, edumazet,
	fweisbec, oleg, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20171205204928-mutt-send-email-mst@kernel.org>

On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:

> I don't see WRITE_ONCE inserting any barriers, release or
> write.

Correct, never claimed there was.

Just saying that:

	obj = READ_ONCE(*foo);
	val = READ_ONCE(obj->val);

Never needs a barrier (except on Alpha and we want to make that go
away). Simply because a CPU needs to complete the load of @obj before it
can compute the address &obj->val. Thus the second load _must_ come
after the first load and we get LOAD-LOAD ordering.

Alpha messing that up is a royal pain, and Alpha not being an
active/living architecture is just not worth the pain of keeping this in
the generic model.

^ permalink raw reply

* Re: [e1000_shutdown] e1000 0000:00:03.0: disabling already-disabled device
From: Tushar Dave @ 2017-12-05 19:19 UTC (permalink / raw)
  To: Fengguang Wu
  Cc: intel-wired-lan, Jeff Kirsher, Linus Torvalds, David S. Miller,
	Sasha Neftin, Dima Ruinskiy, Raanan Avargil, Jacob Keller,
	Thomas Gleixner, Konstantin Khlebnikov, Bernd Faust,
	stephen hemminger, netdev, linux-kernel, lkp
In-Reply-To: <20171204113357.ccc3anyrl3pn7yuj@wfg-t540p.sh.intel.com>



On 12/04/2017 05:03 PM, Fengguang Wu wrote:
> Hi Tushar,
> 
> On Tue, Nov 28, 2017 at 01:01:23AM +0530, Tushar Dave wrote:
>>
>>
>> On 11/23/2017 04:43 AM, Fengguang Wu wrote:
>>> On Wed, Nov 22, 2017 at 03:40:52AM +0530, Tushar Dave wrote:
>>>>
>>>>
>>>> On 11/21/2017 06:11 PM, Fengguang Wu wrote:
>>>>> Hello,
>>>>>
>>>>> FYI this happens in mainline kernel 4.14.0-01330-g3c07399.
>>>>> It happens since 4.13 .
>>>>>
>>>>> It occurs in 3 out of 162 boots.
>>>>>
>>>>>
>>>>> [   44.637743] advantechwdt: Unexpected close, not stopping watchdog!
>>>>> [   44.997548] input: ImExPS/2 Generic Explorer Mouse as
>>>>> /devices/platform/i8042/serio1/input/input6
>>>>> [   45.013419] e1000 0000:00:03.0: disabling already-disabled device
>>>>> [   45.013447] ------------[ cut here ]------------
>>>>> [   45.014868] WARNING: CPU: 1 PID: 71 at drivers/pci/pci.c:1641
>>>>> pci_disable_device+0xa1/0x105:
>>>>>                         pci_disable_device at drivers/pci/pci.c:1640
>>>>> [   45.016171] CPU: 1 PID: 71 Comm: rcu_perf_shutdo Not tainted
>>>>> 4.14.0-01330-g3c07399 #1
>>>>> [   45.017197] task: ffff88011bee9e40 task.stack: ffffc90000860000
>>>>> [   45.017987] RIP: 0010:pci_disable_device+0xa1/0x105:
>>>>>                         pci_disable_device at drivers/pci/pci.c:1640
>>>>> [   45.018603] RSP: 0000:ffffc90000863e30 EFLAGS: 00010286
>>>>> [   45.019282] RAX: 0000000000000035 RBX: ffff88013a230008 RCX:
>>>>> 0000000000000000
>>>>> [   45.020182] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
>>>>> 0000000000000203
>>>>> [   45.021084] RBP: ffff88013a3f31e8 R08: 0000000000000001 R09:
>>>>> 0000000000000000
>>>>> [   45.021986] R10: ffffffff827ec29c R11: 0000000000000002 R12:
>>>>> 0000000000000001
>>>>> [   45.022946] R13: ffff88013a230008 R14: ffff880117802b20 R15:
>>>>> ffffc90000863e8f
>>>>> [   45.023842] FS:  0000000000000000(0000) GS:ffff88013fd00000(0000)
>>>>> knlGS:0000000000000000
>>>>> [   45.024863] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> [   45.025583] CR2: ffffc900006d4000 CR3: 000000000220f000 CR4:
>>>>> 00000000000006a0
>>>>> [   45.026478] Call Trace:
>>>>> [   45.026811]  __e1000_shutdown+0x1d4/0x1e2:
>>>>>                         __e1000_shutdown at
>>>>> drivers/net/ethernet/intel/e1000/e1000_main.c:5162
>>>>> [   45.027344]  ? rcu_perf_cleanup+0x2a1/0x2a1:
>>>>>                         rcu_perf_shutdown at kernel/rcu/rcuperf.c:627
>>>>> [   45.027883]  e1000_shutdown+0x14/0x3a:
>>>>>                         e1000_shutdown at
>>>>> drivers/net/ethernet/intel/e1000/e1000_main.c:5235
>>>>> [   45.028351]  device_shutdown+0x110/0x1aa:
>>>>>                         device_shutdown at drivers/base/core.c:2807
>>>>> [   45.028858]  kernel_power_off+0x31/0x64:
>>>>>                         kernel_power_off at kernel/reboot.c:260
>>>>> [   45.029343]  rcu_perf_shutdown+0x9b/0xa7:
>>>>>                         rcu_perf_shutdown at kernel/rcu/rcuperf.c:637
>>>>> [   45.029852]  ? __wake_up_common_lock+0xa2/0xa2:
>>>>>                         autoremove_wake_function at
>>>>> kernel/sched/wait.c:376
>>>>> [   45.030414]  kthread+0x126/0x12e:
>>>>>                         kthread at kernel/kthread.c:233
>>>>> [   45.030834]  ? __kthread_bind_mask+0x8e/0x8e:
>>>>>                         kthread at kernel/kthread.c:190
>>>>> [   45.031399]  ? ret_from_fork+0x1f/0x30:
>>>>>                         ret_from_fork at arch/x86/entry/entry_64.S:443
>>>>> [   45.031883]  ? kernel_init+0xa/0xf5:
>>>>>                         kernel_init at init/main.c:997
>>>>> [   45.032325]  ret_from_fork+0x1f/0x30:
>>>>>                         ret_from_fork at arch/x86/entry/entry_64.S:443
>>>>> [   45.032777] Code: 00 48 85 ed 75 07 48 8b ab a8 00 00 00 48 8d bb
>>>>> 98 00 00 00 e8 aa d1 11 00 48 89 ea 48 89 c6 48 c7 c7 d8 e4 0b 82 e8
>>>>> 55 7d da ff <0f> ff b9 01 00 00 00 31 d2 be 01 00 00 00 48 c7 c7 f0
>>>>> b1 61 82
>>>>> [   45.035222] ---[ end trace c257137b1b1976ef ]---
>>>>> [   45.037838] ACPI: Preparing to enter system sleep state S5
>>>>>
>>>>> Attached the full dmesg, kconfig and reproduce scripts.
>>>> Looks like e1000 pci/pxi-x device is already suspended. And therefore
>>>> call to e1000_suspend() -> __e1000_shutdown() -> pci_disable_device()
>>>> already had disabled the device.
>>>> Disabling device again by e1000_shutdown handler during system shutdown
>>>> causes warning at drivers/pci/pci.c:1641.
>>>>
>>>> I think function __e1000_shutdown should just return if device is
>>>> already suspended!
>>>>
>>>> I don't have e1000 hardware to test right now. So if this seems logical
>>>> to others I will send a patch.
>>>
>>> Tushar, it happens on QEMU boot testing, so do not rely on e1000 HW.
>>> Unless you'd like to prevent regressions on real HW.
>>>
>>> The original report attached a reproduce script to run the QEMU test.
>>> Or you may send me the patch for testing.
>> Fengguang,
>>
>> Would you please try this patch and test. The patch is compile tested
>> only. The patch is similar to how ixgbe handled the issue.
>> Thanks.
>>
>> e1000: fix disabling already-disabled warning
>>
>> This patch adds check so that driver does not disable already
>> disabled device.
> 
> It works! I tried 100 boots and the "e1000 0000:00:03.0: disabling
> already-disabled device" error no longer show up.
> 
> Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Fengguang,

Thanks for testing. I will send patch soon.

-Tushar
> 
> Thanks,
> Fengguang
> 
>> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com>
>> ---
>>  drivers/net/ethernet/intel/e1000/e1000.h      |  3 ++-
>>  drivers/net/ethernet/intel/e1000/e1000_main.c | 23 
>> ++++++++++++++++++-----
>>  2 files changed, 20 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000/e1000.h
>> b/drivers/net/ethernet/intel/e1000/e1000.h
>> index d7bdea7..8fd2458 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000.h
>> +++ b/drivers/net/ethernet/intel/e1000/e1000.h
>> @@ -331,7 +331,8 @@ struct e1000_adapter {
>>  enum e1000_state_t {
>>      __E1000_TESTING,
>>      __E1000_RESETTING,
>> -    __E1000_DOWN
>> +    __E1000_DOWN,
>> +    __E1000_DISABLED
>>  };
>>
>>  #undef pr_fmt
>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> index 1982f79..a7de31d 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> @@ -945,7 +945,7 @@ static int e1000_init_hw_struct(struct e1000_adapter
>> *adapter,
>>  static int e1000_probe(struct pci_dev *pdev, const struct
>> pci_device_id *ent)
>>  {
>>      struct net_device *netdev;
>> -    struct e1000_adapter *adapter;
>> +    struct e1000_adapter *adapter = NULL;
>>      struct e1000_hw *hw;
>>
>>      static int cards_found;
>> @@ -955,6 +955,7 @@ static int e1000_probe(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>>      u16 tmp = 0;
>>      u16 eeprom_apme_mask = E1000_EEPROM_APME;
>>      int bars, need_ioport;
>> +    bool disable_dev = false;
>>
>>      /* do not allocate ioport bars when not needed */
>>      need_ioport = e1000_is_need_ioport(pdev);
>> @@ -1259,11 +1260,13 @@ static int e1000_probe(struct pci_dev *pdev,
>> const struct pci_device_id *ent)
>>      iounmap(hw->ce4100_gbe_mdio_base_virt);
>>      iounmap(hw->hw_addr);
>>  err_ioremap:
>> +    disable_dev = !test_and_set_bit(__E1000_DISABLED, &adapter->flags);
>>      free_netdev(netdev);
>>  err_alloc_etherdev:
>>      pci_release_selected_regions(pdev, bars);
>>  err_pci_reg:
>> -    pci_disable_device(pdev);
>> +    if (!adapter || disable_dev)
>> +        pci_disable_device(pdev);
>>      return err;
>>  }
>>
>> @@ -1281,6 +1284,7 @@ static void e1000_remove(struct pci_dev *pdev)
>>      struct net_device *netdev = pci_get_drvdata(pdev);
>>      struct e1000_adapter *adapter = netdev_priv(netdev);
>>      struct e1000_hw *hw = &adapter->hw;
>> +    bool disable_dev;
>>
>>      e1000_down_and_stop(adapter);
>>      e1000_release_manageability(adapter);
>> @@ -1299,9 +1303,11 @@ static void e1000_remove(struct pci_dev *pdev)
>>          iounmap(hw->flash_address);
>>      pci_release_selected_regions(pdev, adapter->bars);
>>
>> +    disable_dev = !test_and_set_bit(__E1000_DISABLED, &adapter->flags);
>>      free_netdev(netdev);
>>
>> -    pci_disable_device(pdev);
>> +    if (disable_dev)
>> +        pci_disable_device(pdev);
>>  }
>>
>>  /**
>> @@ -5156,7 +5162,8 @@ static int __e1000_shutdown(struct pci_dev *pdev,
>> bool *enable_wake)
>>      if (netif_running(netdev))
>>          e1000_free_irq(adapter);
>>
>> -    pci_disable_device(pdev);
>> +    if (!test_and_set_bit(__E1000_DISABLED, &adapter->flags))
>> +        pci_disable_device(pdev);
>>
>>      return 0;
>>  }
>> @@ -5200,6 +5207,8 @@ static int e1000_resume(struct pci_dev *pdev)
>>          pr_err("Cannot enable PCI device from suspend\n");
>>          return err;
>>      }
>> +    smp_mb__before_atomic();
>> +    clear_bit(__E1000_DISABLED, &adapter->flags);
>>      pci_set_master(pdev);
>>
>>      pci_enable_wake(pdev, PCI_D3hot, 0);
>> @@ -5274,7 +5283,9 @@ static pci_ers_result_t
>> e1000_io_error_detected(struct pci_dev *pdev,
>>
>>      if (netif_running(netdev))
>>          e1000_down(adapter);
>> -    pci_disable_device(pdev);
>> +
>> +    if (!test_and_set_bit(__E1000_DISABLED, &adapter->flags))
>> +        pci_disable_device(pdev);
>>
>>      /* Request a slot slot reset. */
>>      return PCI_ERS_RESULT_NEED_RESET;
>> @@ -5302,6 +5313,8 @@ static pci_ers_result_t e1000_io_slot_reset(struct
>> pci_dev *pdev)
>>          pr_err("Cannot re-enable PCI device after reset.\n");
>>          return PCI_ERS_RESULT_DISCONNECT;
>>      }
>> +    smp_mb__before_atomic();
>> +    clear_bit(__E1000_DISABLED, &adapter->flags);
>>      pci_set_master(pdev);
>>
>>      pci_enable_wake(pdev, PCI_D3hot, 0);
>> -- 
>> 1.8.3.1
>>
>>
>> -Tushar
>>>
>>> Thanks,
>>> Fengguang
>>>
>>
> 

^ permalink raw reply

* Re: [RFC] virtio-net: help live migrate SR-IOV devices
From: Michael S. Tsirkin @ 2017-12-05 19:20 UTC (permalink / raw)
  To: achiad shochat
  Cc: Alexander Duyck, Stephen Hemminger, Jakub Kicinski,
	Hannes Frederic Sowa, Sridhar Samudrala, netdev, virtualization,
	Achiad, Peter Waskiewicz Jr, Singhai, Anjali, Shannon Nelson,
	Andy Gospodarek, Or Gerlitz
In-Reply-To: <CAEHy93Kw-GePsraaAkVZNbOwt=rDPMVjmwuU22004LHCAoSSFA@mail.gmail.com>

On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote:
> Then we'll have a single solution for both netvsc and virtio (and any
> other PV device).
> And we could handle the VF DMA dirt issue agnostically.

For the record, I won't block patches adding this kist to virtio
on the basis that they must be generic. It's not a lot
of code, implementation can come first, prettify later.

But we do need to have a discussion about how devices are paired.
I am not sure using just MAC works. E.g. some passthrough
devices don't give host ability to set the MAC.
Are these worth worrying about?

-- 
MST

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Michael S. Tsirkin @ 2017-12-05 19:24 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: tglx, kvm, fweisbec, jiangshanlai, linux-kernel, rostedt, josh,
	dhowells, edumazet, netdev, mathieu.desnoyers, oleg, dipankar,
	akpm, Paul E. McKenney, virtualization, mingo
In-Reply-To: <20171205191733.GQ3165@worktop.lehotels.local>

On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> 
> > I don't see WRITE_ONCE inserting any barriers, release or
> > write.
> 
> Correct, never claimed there was.
> 
> Just saying that:
> 
> 	obj = READ_ONCE(*foo);
> 	val = READ_ONCE(obj->val);
> 
> Never needs a barrier (except on Alpha and we want to make that go
> away). Simply because a CPU needs to complete the load of @obj before it
> can compute the address &obj->val. Thus the second load _must_ come
> after the first load and we get LOAD-LOAD ordering.
> 
> Alpha messing that up is a royal pain, and Alpha not being an
> active/living architecture is just not worth the pain of keeping this in
> the generic model.
> 

Right. What I am saying is that for writes you need

WRITE_ONCE(obj->val, 1);
smp_wmb();
WRITE_ONCE(*foo, obj);

and this barrier is no longer paired with anything until
you realize there's a dependency barrier within READ_ONCE.

Barrier pairing was a useful tool to check code validity,
maybe there are other, better tools now.


-- 
MST

^ permalink raw reply

* [PATCH] ptr_ring: add barriers
From: Michael S. Tsirkin @ 2017-12-05 19:29 UTC (permalink / raw)
  To: linux-kernel; +Cc: George Cherian, netdev, virtualization, edumazet, davem

Users of ptr_ring expect that it's safe to give the
data structure a pointer and have it be available
to consumers, but that actually requires an smb_wmb
or a stronger barrier.

In absence of such barriers and on architectures that reorder writes,
consumer might read an un=initialized value from an skb pointer stored
in the skb array.  This was observed causing crashes.

To fix, add memory barriers.  The barrier we use is a wmb, the
assumption being that producers do not need to read the value so we do
not need to order these reads.

Reported-by: George Cherian <george.cherian@cavium.com>
Suggested-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---

George, could you pls report whether this patch fixes
the issue for you?

This seems to be needed in stable as well.




 include/linux/ptr_ring.h | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 37b4bb2..6866df4 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -101,12 +101,18 @@ static inline bool ptr_ring_full_bh(struct ptr_ring *r)
 
 /* Note: callers invoking this in a loop must use a compiler barrier,
  * for example cpu_relax(). Callers must hold producer_lock.
+ * Callers are responsible for making sure pointer that is being queued
+ * points to a valid data.
  */
 static inline int __ptr_ring_produce(struct ptr_ring *r, void *ptr)
 {
 	if (unlikely(!r->size) || r->queue[r->producer])
 		return -ENOSPC;
 
+	/* Make sure the pointer we are storing points to a valid data. */
+	/* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
+	smp_wmb();
+
 	r->queue[r->producer++] = ptr;
 	if (unlikely(r->producer >= r->size))
 		r->producer = 0;
@@ -275,6 +281,9 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
 	if (ptr)
 		__ptr_ring_discard_one(r);
 
+	/* Make sure anyone accessing data through the pointer is up to date. */
+	/* Pairs with smp_wmb in __ptr_ring_produce. */
+	smp_read_barrier_depends();
 	return ptr;
 }
 
-- 
MST

^ permalink raw reply related

* Re: [PATCH net-next 0/4] Introduce NETIF_F_GRO_HW
From: David Miller @ 2017-12-05 19:31 UTC (permalink / raw)
  To: michael.chan; +Cc: netdev
In-Reply-To: <1512385967-32339-1-git-send-email-michael.chan@broadcom.com>

From: Michael Chan <michael.chan@broadcom.com>
Date: Mon,  4 Dec 2017 06:12:43 -0500

> Introduce NETIF_F_GRO_HW feature flag and convert drivers that support
> hardware GRO to use the flag.

So I think we should continue ahead with NETIF_F_GRO_HW.

LRO, even if it were in some way more appropriate, has so many stigmas
attached to it.  And if you look around the internet, articles say to
turn it off for this reason or that due to the information loss LRO
creates.

The only thing unresolved is how to manage the situation where a
bond or bridge has a mixture of LRO and GRO_HW devices attached,
and Michael said he would look into it.

Thanks.

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Paul E. McKenney @ 2017-12-05 19:33 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: tglx, kvm, Peter Zijlstra, fweisbec, jiangshanlai, linux-kernel,
	rostedt, josh, dhowells, edumazet, netdev, mathieu.desnoyers,
	oleg, dipankar, akpm, virtualization, mingo
In-Reply-To: <20171205212053-mutt-send-email-mst@kernel.org>

On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> > 
> > > I don't see WRITE_ONCE inserting any barriers, release or
> > > write.
> > 
> > Correct, never claimed there was.
> > 
> > Just saying that:
> > 
> > 	obj = READ_ONCE(*foo);
> > 	val = READ_ONCE(obj->val);
> > 
> > Never needs a barrier (except on Alpha and we want to make that go
> > away). Simply because a CPU needs to complete the load of @obj before it
> > can compute the address &obj->val. Thus the second load _must_ come
> > after the first load and we get LOAD-LOAD ordering.
> > 
> > Alpha messing that up is a royal pain, and Alpha not being an
> > active/living architecture is just not worth the pain of keeping this in
> > the generic model.
> > 
> 
> Right. What I am saying is that for writes you need
> 
> WRITE_ONCE(obj->val, 1);
> smp_wmb();
> WRITE_ONCE(*foo, obj);

I believe Peter was instead suggesting:

WRITE_ONCE(obj->val, 1);
smp_store_release(foo, obj);

> and this barrier is no longer paired with anything until
> you realize there's a dependency barrier within READ_ONCE.
> 
> Barrier pairing was a useful tool to check code validity,
> maybe there are other, better tools now.

There are quite a few people who say that smp_store_release() is
easier for the tools to analyze than is smp_wmb().  My experience with
smp_read_barrier_depends() and rcu_dereference() leads me to believe
that they are correct.

							Thanx, Paul

^ permalink raw reply

* Re: [PATCH net 1/2] bpf/verifier: fix bounds calculation on BPF_RSH
From: Jann Horn @ 2017-12-05 19:35 UTC (permalink / raw)
  To: Edward Cree
  Cc: davem, Network Development, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <f5041e0a-85d9-6b14-a052-59bae94a5f63@solarflare.com>

On Tue, Dec 5, 2017 at 8:15 PM, Edward Cree <ecree@solarflare.com> wrote:
> Incorrect signed bounds were being computed, although this had no effect
>  since the propagation in __reg_deduce_bounds() happened to overwrite them.
>
> Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
> Reported-by: Jann Horn <jannh@google.com>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
>  kernel/bpf/verifier.c | 30 ++++++++++++++++--------------
>  1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d4593571c404..5bed7f773c87 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -2184,20 +2184,22 @@ static int adjust_scalar_min_max_vals(struct bpf_verifier_env *env,
>                         mark_reg_unknown(env, regs, insn->dst_reg);
>                         break;
>                 }
> -               /* BPF_RSH is an unsigned shift, so make the appropriate casts */
> -               if (dst_reg->smin_value < 0) {
> -                       if (umin_val) {
> -                               /* Sign bit will be cleared */
> -                               dst_reg->smin_value = 0;
> -                       } else {
> -                               /* Lost sign bit information */
> -                               dst_reg->smin_value = S64_MIN;
> -                               dst_reg->smax_value = S64_MAX;
> -                       }
> -               } else {
> -                       dst_reg->smin_value =
> -                               (u64)(dst_reg->smin_value) >> umax_val;
> -               }
> +               /* BPF_RSH is an unsigned shift.  If the value in dst_reg might
> +                * be negative, then either:
> +                * 1) src_reg might be zero, so the sign bit of the result is
> +                *    unknown, so we lose our signed bounds
> +                * 2) it's known negative, thus the unsigned bounds capture the
> +                *    signed bounds
> +                * 3) the signed bounds cross zero, so they tell us nothing
> +                *    about the result
> +                * If the value in dst_reg is known nonnegative, then again the
> +                * unsigned bounts capture the signed bounds.
> +                * Thus, in all cases it suffices to blow away our signed bounds
> +                * and rely on inferring new ones from the unsigned bounds and
> +                * var_off of the result.
> +                */
> +               dst_reg->smin_value = S64_MIN;
> +               dst_reg->smax_value = S64_MAX;
>                 if (src_known)
>                         dst_reg->var_off = tnum_rshift(dst_reg->var_off,
>                                                        umin_val);
>

Reviewed-by: Jann Horn <jannh@google.com>

^ permalink raw reply

* Re: Linux ECN Handling
From: Steve Ibanez @ 2017-12-05 19:36 UTC (permalink / raw)
  To: Neal Cardwell
  Cc: Eric Dumazet, Yuchung Cheng, Daniel Borkmann, Netdev,
	Florian Westphal, Mohammad Alizadeh, Lawrence Brakmo
In-Reply-To: <CADVnQynzhKngDM20YA-bGsLGq8k_5ikU3w0YDpdg8Pk5eMsssw@mail.gmail.com>

Hi Neal,

I've included a link to small trace of 13 packets which is different
from the screenshot I attached in my last email, but shows the same
sequence of events. It's a bit hard to read the tcptrace due to the
300ms timeout, so I figured this was the best approach.

slice.pcap: https://drive.google.com/open?id=1hYXbUClHGbQv1hWG1HZWDO2WYf30N6G8

Thanks for the help!
-Steve

On Tue, Dec 5, 2017 at 7:23 AM, Neal Cardwell <ncardwell@google.com> wrote:
> On Tue, Dec 5, 2017 at 12:22 AM, Steve Ibanez <sibanez@stanford.edu> wrote:
>> Hi Neal,
>>
>> Happy to help out :) And thanks for the tip!
>>
>> I was able to track down where the missing bytes that you pointed out
>> are being lost. It turns out the destination host seems to be
>> misbehaving. I performed a packet capture at the destination host
>> interface (a snapshot of the trace is attached). I see the following
>> sequence of events when a timeout occurs (note that I have NIC
>> offloading enabled so wireshark captures packets larger than the MTU):
>>
>> 1. The destination receives a data packet of length X with seqNo = Y
>> from the src with the CWR bit set and does not send back a
>> corresponding ACK.
>> 2. The source times out and sends a retransmission packet of length Z
>> (where Z < X) with seqNo = Y
>> 3. The destination sends back an ACK with AckNo = Y + X
>>
>> So in other words, the packet which the destination host does not
>> initially ACK (causing the timeout) does not actually get lost because
>> after receiving the retransmission the AckNo moves forward all the way
>> past the bytes in the initial unACKed CWR packet. In the attached
>> screenshot, I've marked the unACKed CWR packet with a red box.
>>
>> Have you seen this behavior before? And do you know what might be
>> causing the destination host not to ACK the CWR packet? In most cases
>> the CWR marked packets are ACKed properly, it's just occasionally they
>> are not.
>
> Thanks for the detailed report!
>
> I have not heard of an incoming CWR causing the receiver to fail to
> ACK. And in re-reading the code, I don't see an obvious way in which a
> CWR bit should cause the receiver to fail to ACK.
>
> That screen shot is a bit hard to parse. Would you be able to post a
> tcpdump .pcap of that particular section, or post a screen shot of a
> time-sequence plot of that section?
>
> To extract that segment and take screen shot, you could use something like:
>
>   editcap -A "2017-12-04 11:22:27"  -B "2017-12-04 11:22:30"  all.pcap
> slice.pcap
>   tcptrace -S -xy -zy slice.pcap
>   xplot.org a2b_tsg.xpl &
>   # take screenshot
>
> Or, alternatively, would you be able to post the slice.pcap on a web
> server or public drive?
>
> thanks,
> neal

^ permalink raw reply

* Re: [patch net 0/2] RED qdisc fixes
From: David Miller @ 2017-12-05 19:37 UTC (permalink / raw)
  To: nogahf; +Cc: netdev, jhs, xiyou.wangcong, jiri, mlxsw
In-Reply-To: <1512387071-35193-1-git-send-email-nogahf@mellanox.com>

From: Nogah Frankel <nogahf@mellanox.com>
Date: Mon,  4 Dec 2017 13:31:09 +0200

> Add some input validation checks to RED qdisc.

Series applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH][next] netdevsim: make functions nsim_bpf_create_prog and nsim_bpf_destroy_prog static
From: David Miller @ 2017-12-05 19:38 UTC (permalink / raw)
  To: colin.king; +Cc: jakub.kicinski, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20171204125609.5931-1-colin.king@canonical.com>

From: Colin King <colin.king@canonical.com>
Date: Mon,  4 Dec 2017 12:56:09 +0000

> From: Colin Ian King <colin.king@canonical.com>
> 
> Functions nsim_bpf_create_prog and nsim_bpf_destroy_prog are local to the
> source and do not need to be in global scope, so make them static.
> 
> Cleans up sparse warnings:
> symbol 'nsim_bpf_create_prog' was not declared. Should it be static?
> symbol 'nsim_bpf_destroy_prog' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Applied, thanks.

^ permalink raw reply

* Re: Uninitialized value in __sk_nulls_add_node_rcu()
From: Craig Gallek @ 2017-12-05 19:39 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Eric Dumazet, Alexander Potapenko, David Miller, Networking

On Tue, Dec 5, 2017 at 9:18 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2017-12-05 at 06:15 -0800, Eric Dumazet wrote:
>>
>> +     hlist_nulls_add_head_rcu(&sk->sk_nulss_node, list);
>
> Typo here, this needs sk_nulls_node of course.
>

Thanks Eric, this looks good to me.  The tail insertion is still
required in udp_lib_get_port for the second layer hash, but not here.
fwiw, reuseport_dualstack in the selftests directory verifies this
behavior.  I tried it with your patch (it still passes) and removing
the udp_lib_get_port path (to make sure it breaks when it should).

Craig

^ permalink raw reply

* Re: [PATCH net 2/2] selftests/bpf: Add a test for shifts of values that might be negative
From: Alexei Starovoitov @ 2017-12-05 19:40 UTC (permalink / raw)
  To: Edward Cree; +Cc: davem, netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <2ed58e2e-40b7-a57b-a784-33d441b13a42@solarflare.com>

On Tue, Dec 05, 2017 at 07:15:57PM +0000, Edward Cree wrote:
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
>  tools/testing/selftests/bpf/test_align.c | 39 ++++++++++++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
> index 8591c89c0828..24c6757b4c51 100644
> --- a/tools/testing/selftests/bpf/test_align.c
> +++ b/tools/testing/selftests/bpf/test_align.c
> @@ -601,6 +601,45 @@ static struct bpf_align_test tests[] = {
>  			{20, "R5=pkt(id=2,off=0,r=4,umin_value=2,umax_value=1082,var_off=(0x2; 0x7fc))"},
>  		},
>  	},
> +	{
> +		.descr = "unknown shift negative",
> +		/* This isn't really a test of the alignment code, rather of the
> +		 * signed min/max value handling, but it makes use of the
> +		 * register-state-extracting code in do_test_single(), which
> +		 * test_verifier.c doesn't have.
> +		 */
> +		.insns = {
> +			LOAD_UNKNOWN(BPF_REG_3),
> +			BPF_ALU64_IMM(BPF_SUB, BPF_REG_3, 0xff),
> +			BPF_ALU64_IMM(BPF_LSH, BPF_REG_3, 1),
> +			LOAD_UNKNOWN(BPF_REG_4),
> +			BPF_ALU64_IMM(BPF_SUB, BPF_REG_4, 0xff),
> +			BPF_MOV64_REG(BPF_REG_5, BPF_REG_4),
> +			BPF_ALU64_IMM(BPF_RSH, BPF_REG_4, 1),
> +			BPF_ALU64_IMM(BPF_SUB, BPF_REG_5, 1),
> +			BPF_ALU64_IMM(BPF_RSH, BPF_REG_5, 1),
> +			BPF_MOV64_IMM(BPF_REG_0, 0),
> +			BPF_EXIT_INSN(),
> +		},
> +		.prog_type = BPF_PROG_TYPE_SCHED_CLS,
> +		.matches = {
> +			{7, "R0=pkt(id=0,off=8,r=8,imm=0)"},
> +			{7, "R3=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
> +			{8, "R3=inv(id=0,smin_value=-255,smax_value=0)"},
> +			/* All the verifier knows is, it's even.  While we could
> +			 * conclude something tighter (the sign bit does not
> +			 * change), the verifier doesn't bother right now.
> +			 */
> +			{9, "R3=inv(id=0,smax_value=9223372036854775806,umax_value=18446744073709551614,var_off=(0x0; 0xfffffffffffffffe))"},
> +			{16, "R3=pkt_end(id=0,off=0,imm=0)"},
> +			{16, "R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff))"},
> +			{17, "R4=inv(id=0,smin_value=-255,smax_value=0)"},
> +			/* both 0 and 0x7f...fff are possible */
> +			{19, "R4=inv(id=0,umax_value=9223372036854775807,var_off=(0x0; 0x7fffffffffffffff))"},
> +			{20, "R5=inv(id=0,umin_value=18446744073709551360,var_off=(0xffffffffffffff00; 0xff))"},
> +			{21, "R5=inv(id=0,umin_value=9223372036854775680,umax_value=9223372036854775807,var_off=(0x7fffffffffffff80; 0x7f))"},

hmm. it doesn't quite look right here and in this form it
already conflicts with net-next.
I would prefer to take only patch 1 into bpf->net and once
bpf->net->linus->net-next merge happens to add the test there.

^ permalink raw reply

* Re: [PATCH 0/2] net: sh_eth: DMA mapping API fixes
From: David Miller @ 2017-12-05 19:42 UTC (permalink / raw)
  To: thomas.petazzoni
  Cc: sergei.shtylyov, niklas.soderlund+renesas, geert+renesas,
	horms+renesas, netdev, linux-renesas-soc
In-Reply-To: <20171204133327.3505-1-thomas.petazzoni@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Mon,  4 Dec 2017 14:33:25 +0100

> Here are two patches that fix how the sh_eth driver is using the DMA
> mapping API: a bogus struct device is used in some places, or a NULL
> struct device is used.

Series applied.

^ permalink raw reply

* Re: [PATCH 0/2] net: sh_eth: add support for SH7786 and big-endian
From: David Miller @ 2017-12-05 19:44 UTC (permalink / raw)
  To: thomas.petazzoni
  Cc: sergei.shtylyov, niklas.soderlund+renesas, geert+renesas,
	horms+renesas, netdev, linux-renesas-soc
In-Reply-To: <20171204141744.18599-1-thomas.petazzoni@free-electrons.com>

From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Mon,  4 Dec 2017 15:17:42 +0100

> I've recently been working on an SH7786 based platform, which uses the
> sh_eth network controller. One peculiarity of my setup is that the CPU
> is configured big-endian (even though little-endian is more
> traditional in the Linux SuperH world), and the sh_eth driver was not
> ready for this.
> 
> The first patch simply adds the sh_eth_cpu_data structure that
> describes the SH7786 controller.
> 
> The second patch fixes the driver for big-endian operation. However,
> I'd like this patch to be carefully reviewed by Sergei Shtylyov who
> already did some endianness related changes in this driver. Indeed, my
> change is based on the assumption that the DMA descriptors are in the
> native endianness of the CPU.

Sergei, please let me know when you've re-reviewed this series now
that you have documentation in hand...

Thanks.

^ permalink raw reply

* Re: [PATCH net 1/2] bpf/verifier: fix bounds calculation on BPF_RSH
From: Alexei Starovoitov @ 2017-12-05 19:44 UTC (permalink / raw)
  To: Edward Cree; +Cc: davem, netdev, Jann Horn, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <f5041e0a-85d9-6b14-a052-59bae94a5f63@solarflare.com>

On Tue, Dec 05, 2017 at 07:15:18PM +0000, Edward Cree wrote:
> Incorrect signed bounds were being computed, although this had no effect
>  since the propagation in __reg_deduce_bounds() happened to overwrite them.
> 
> Fixes: b03c9f9fdc37 ("bpf/verifier: track signed and unsigned min/max values")
> Reported-by: Jann Horn <jannh@google.com>
> Signed-off-by: Edward Cree <ecree@solarflare.com>

Acked-by: Alexei Starovoitov <ast@kernel.org>

^ permalink raw reply

* Re: [RFC][PATCHES] sock_alloc_file() cleanups and fixes
From: David Miller @ 2017-12-05 19:44 UTC (permalink / raw)
  To: viro; +Cc: netdev
In-Reply-To: <20171204164100.GS21978@ZenIV.linux.org.uk>

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: Mon, 4 Dec 2017 16:41:01 +0000

> On Mon, Dec 04, 2017 at 10:35:24AM -0500, David Miller wrote:
>> From: Al Viro <viro@ZenIV.linux.org.uk>
>> Date: Fri, 1 Dec 2017 00:20:27 +0000
>> 
>> > 	1) massage sys_socketpair() (should be a pure cleanup)
>> > 	2) fix and clean up kcm_clone() (-stable fodder)
>> > 	3) switch sock_alloc_file() to new calling conventions.
>> > 
>> > 	It got some local testing, but it certainly needs more review.
>> > Diffstat for the entire thing is
>> 
>> Series looks great to me:
>> 
>> Acked-by: David S. Miller <davem@davemloft.net>
> 
> How do you prefer it to be handled?  KCM one should go into everything
> since 4.6 (with trivial modifications in 4.11 and 4.12 - both had
> massaged the place around the call of kcm_clone() a bit, but this fix
> overwrites the entire area and that can be dropped into earlier
> kernels without any problems).  I've put that into vfs.git#net-fixes
> and have the other two in vfs.git#for-davem on top of that, with
> you merging the latter into net-next.git and the former - into net.git.
> Is that OK with you, or would you prefer some other way of handling
> that kind of stuff?

Why don't you resubmit this to netdev as a non-RFC, I'll queue it up to
'net' and -stable as well.

Thanks Al.

^ permalink raw reply

* Re: pull-request: ieee802154-next 2017-12-04
From: David Miller @ 2017-12-05 19:45 UTC (permalink / raw)
  To: stefan; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20171204165111.29240-1-stefan@osg.samsung.com>

From: Stefan Schmidt <stefan@osg.samsung.com>
Date: Mon,  4 Dec 2017 17:51:11 +0100

> Some update from ieee802154 to *net-next*
> 
> Jian-Hong Pan updated our docs to match the APIs in code.
> Michael Hennerichs enhanced the adf7242 driver to work with adf7241
> devices and reworked the IRQ and packet handling in the driver.

Pulled, thanks.

^ permalink raw reply

* Re: [PATCH net-next 0/5] net: dsa: use per-port upstream port
From: David Miller @ 2017-12-05 19:47 UTC (permalink / raw)
  To: vivien.didelot; +Cc: netdev, linux-kernel, kernel, f.fainelli, andrew
In-Reply-To: <20171204173457.14873-1-vivien.didelot@savoirfairelinux.com>

From: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Date: Mon,  4 Dec 2017 12:34:52 -0500

> An upstream port is a local switch port used to reach a CPU port.
> 
> DSA still considers a unique CPU port in the whole switch fabric and
> thus return a unique upstream port for a given switch. This is wrong in
> a multiple CPU ports environment.
> 
> We are now switching to using the dedicated CPU port assigned to each
> port in order to get rid of the deprecated unique tree CPU port.
> 
> This patchset makes the dsa_upstream_port() helper take a port argument
> and goes one step closer complete support for multiple CPU ports.

Please adhere to reverse-christmas-tree for variable declarations in
these changes.

I know it can be a pain when there are inter-variable dependencies
wrt. assignments, but just move it below the declaration and into a
real statement.

Thanks.

^ permalink raw reply

* Re: [PATCH v2 net-next 0/5] rhashtable: New features in walk and bucket
From: David Miller @ 2017-12-05 19:47 UTC (permalink / raw)
  To: tom; +Cc: netdev, herbert, rohit
In-Reply-To: <20171204183145.3277-1-tom@quantonium.net>

From: Tom Herbert <tom@quantonium.net>
Date: Mon,  4 Dec 2017 10:31:40 -0800

> This patch contains some changes to related rhashtable:
> 
> - Above allow rhashtable_walk_start to return void
> - Add a functon to peek at the next entry during a walk
> - Abstract out function to compute a has for a table
> - A library function to alloc a spinlocks bucket array
> - Call the above function for rhashtable locks allocation
> 
> Tested: Exercised using various operations on an ILA xlat
> table.
> 
> v2:
>  - Apply feedback from Herbert. Don't change semantics of resize
>    event reporting and -EAGAIN, just simplify API for callers that
>    ignore those.
>  - Add end_of_table in iter to reliably tell when the iterator has
>    reached to the eno.

I'll allow Herbert time to think about this some more as he requested
in comments against the first version of this series.

Thanks.

^ permalink raw reply

* Re: [PATCH 1/2] net: sh_eth: add support for SH7786
From: Sergei Shtylyov @ 2017-12-05 19:49 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: David S. Miller, Niklas Söderlund, Geert Uytterhoeven,
	Simon Horman, netdev, linux-renesas-soc
In-Reply-To: <c334c622-9381-3bb5-eced-9a2ea6485fbd@cogentembedded.com>

On 12/05/2017 10:04 PM, Sergei Shtylyov wrote:

>>>> This commit adds the sh_eth_cpu_data structure that describes the
>>>> SH7786 variant of the IP.
>>>
>>>      The manual seems to be unavailable, so I have to trust you. :-)
>>
>> Yes, sadly. However, if you tell me what to double check, I'd be happy
>> to do so.
> 
>     I have the manual now, will check against it...
>     DaveM, I'm retracting my ACK for the time being.

    Starting to look into the manual, the current patch is wrong. SH7786 SoC 
was probably the 1st one to use what we thought was R-Car specific register 
layout. Definite NAK on this version.

>> Thanks!
>>
>> Thomas

MBR, Sergei

^ permalink raw reply

* Re: [PATCH tip/core/rcu 21/21] drivers/vhost: Remove now-redundant read_barrier_depends()
From: Michael S. Tsirkin @ 2017-12-05 19:51 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Peter Zijlstra, linux-kernel, mingo, jiangshanlai, dipankar, akpm,
	mathieu.desnoyers, josh, tglx, rostedt, dhowells, edumazet,
	fweisbec, oleg, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20171205193339.GP7829@linux.vnet.ibm.com>

On Tue, Dec 05, 2017 at 11:33:39AM -0800, Paul E. McKenney wrote:
> On Tue, Dec 05, 2017 at 09:24:21PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 05, 2017 at 08:17:33PM +0100, Peter Zijlstra wrote:
> > > On Tue, Dec 05, 2017 at 08:57:46PM +0200, Michael S. Tsirkin wrote:
> > > 
> > > > I don't see WRITE_ONCE inserting any barriers, release or
> > > > write.
> > > 
> > > Correct, never claimed there was.
> > > 
> > > Just saying that:
> > > 
> > > 	obj = READ_ONCE(*foo);
> > > 	val = READ_ONCE(obj->val);
> > > 
> > > Never needs a barrier (except on Alpha and we want to make that go
> > > away). Simply because a CPU needs to complete the load of @obj before it
> > > can compute the address &obj->val. Thus the second load _must_ come
> > > after the first load and we get LOAD-LOAD ordering.
> > > 
> > > Alpha messing that up is a royal pain, and Alpha not being an
> > > active/living architecture is just not worth the pain of keeping this in
> > > the generic model.
> > > 
> > 
> > Right. What I am saying is that for writes you need
> > 
> > WRITE_ONCE(obj->val, 1);
> > smp_wmb();
> > WRITE_ONCE(*foo, obj);
> 
> I believe Peter was instead suggesting:
> 
> WRITE_ONCE(obj->val, 1);
> smp_store_release(foo, obj);

Isn't that more expensive though?


> > and this barrier is no longer paired with anything until
> > you realize there's a dependency barrier within READ_ONCE.
> > 
> > Barrier pairing was a useful tool to check code validity,
> > maybe there are other, better tools now.
> 
> There are quite a few people who say that smp_store_release() is
> easier for the tools to analyze than is smp_wmb().  My experience with
> smp_read_barrier_depends() and rcu_dereference() leads me to believe
> that they are correct.
> 
> 							Thanx, Paul

OK, but smp_store_release is still not paired with anything since we
rely on READ_ONCE to include the implicit dpendendency barrier.

-- 
MST

^ permalink raw reply

* Re: [Intel-wired-lan] [next-queue 09/10] ixgbe: ipsec offload stats
From: Alexander Duyck @ 2017-12-05 19:53 UTC (permalink / raw)
  To: Shannon Nelson
  Cc: intel-wired-lan, Jeff Kirsher, Steffen Klassert, Sowmini Varadhan,
	Netdev
In-Reply-To: <1512452116-14795-10-git-send-email-shannon.nelson@oracle.com>

On Mon, Dec 4, 2017 at 9:35 PM, Shannon Nelson
<shannon.nelson@oracle.com> wrote:
> Add a simple statistic to count the ipsec offloads.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h         |  1 +
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 28 ++++++++++++++----------
>  drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c   |  3 +++
>  3 files changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index 68097fe..bb66c85 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -265,6 +265,7 @@ struct ixgbe_rx_buffer {
>  struct ixgbe_queue_stats {
>         u64 packets;
>         u64 bytes;
> +       u64 ipsec_offloads;
>  };
>
>  struct ixgbe_tx_queue_stats {
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> index c3e7a81..dddbc74 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
> @@ -1233,34 +1233,34 @@ static void ixgbe_get_ethtool_stats(struct net_device *netdev,
>         for (j = 0; j < netdev->num_tx_queues; j++) {
>                 ring = adapter->tx_ring[j];
>                 if (!ring) {
> -                       data[i] = 0;
> -                       data[i+1] = 0;
> -                       i += 2;
> +                       data[i++] = 0;
> +                       data[i++] = 0;
> +                       data[i++] = 0;
>                         continue;
>                 }
>
>                 do {
>                         start = u64_stats_fetch_begin_irq(&ring->syncp);
> -                       data[i]   = ring->stats.packets;
> -                       data[i+1] = ring->stats.bytes;
> +                       data[i++] = ring->stats.packets;
> +                       data[i++] = ring->stats.bytes;
> +                       data[i++] = ring->stats.ipsec_offloads;
>                 } while (u64_stats_fetch_retry_irq(&ring->syncp, start));
> -               i += 2;
>         }
>         for (j = 0; j < IXGBE_NUM_RX_QUEUES; j++) {
>                 ring = adapter->rx_ring[j];
>                 if (!ring) {
> -                       data[i] = 0;
> -                       data[i+1] = 0;
> -                       i += 2;
> +                       data[i++] = 0;
> +                       data[i++] = 0;
> +                       data[i++] = 0;
>                         continue;
>                 }
>
>                 do {
>                         start = u64_stats_fetch_begin_irq(&ring->syncp);
> -                       data[i]   = ring->stats.packets;
> -                       data[i+1] = ring->stats.bytes;
> +                       data[i++] = ring->stats.packets;
> +                       data[i++] = ring->stats.bytes;
> +                       data[i++] = ring->stats.ipsec_offloads;
>                 } while (u64_stats_fetch_retry_irq(&ring->syncp, start));
> -               i += 2;
>         }
>
>         for (j = 0; j < IXGBE_MAX_PACKET_BUFFERS; j++) {
> @@ -1297,12 +1297,16 @@ static void ixgbe_get_strings(struct net_device *netdev, u32 stringset,
>                         p += ETH_GSTRING_LEN;
>                         sprintf(p, "tx_queue_%u_bytes", i);
>                         p += ETH_GSTRING_LEN;
> +                       sprintf(p, "tx_queue_%u_ipsec_offloads", i);
> +                       p += ETH_GSTRING_LEN;
>                 }
>                 for (i = 0; i < IXGBE_NUM_RX_QUEUES; i++) {
>                         sprintf(p, "rx_queue_%u_packets", i);
>                         p += ETH_GSTRING_LEN;
>                         sprintf(p, "rx_queue_%u_bytes", i);
>                         p += ETH_GSTRING_LEN;
> +                       sprintf(p, "rx_queue_%u_ipsec_offloads", i);
> +                       p += ETH_GSTRING_LEN;
>                 }
>                 for (i = 0; i < IXGBE_MAX_PACKET_BUFFERS; i++) {
>                         sprintf(p, "tx_pb_%u_pxon", i);

I probably wouldn't bother reporting this per ring. It might make more
sense to handle this as an adapter statistic.

> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> index 2a0dd7a..d1220bf 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
> @@ -782,6 +782,7 @@ int ixgbe_ipsec_tx(struct ixgbe_ring *tx_ring, struct sk_buff *skb,
>         if (tsa->encrypt)
>                 itd->flags |= IXGBE_ADVTXD_TUCMD_IPSEC_ENCRYPT_EN;
>
> +       tx_ring->stats.ipsec_offloads++;
>         return 1;

Instead of doing this here you may want to make it a part of the Tx
clean-up path. You should still have the flag bit set so you could
test a test for the IPSEC flag bit and if it is set on the tx_buffer
following the transmit you could then increment it there.

>  }
>
> @@ -843,6 +844,8 @@ void ixgbe_ipsec_rx(struct ixgbe_ring *rx_ring,
>         xo = xfrm_offload(skb);
>         xo->flags = CRYPTO_DONE;
>         xo->status = CRYPTO_SUCCESS;
> +
> +       rx_ring->stats.ipsec_offloads++;
>  }
>
>  /**
> --
> 2.7.4
>
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox