Netdev List
 help / color / mirror / Atom feed
* [PATCH v3 1/2] can: m_can: move Message RAM initialization to function
From: Quentin Schulz @ 2017-05-05 11:46 UTC (permalink / raw)
  To: wg, mkl, mario.huettel, socketcan
  Cc: Quentin Schulz, linux-can, netdev, linux-kernel,
	alexandre.belloni, thomas.petazzoni

To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver. This initialization is done in the same function reading the
Device Tree properties.

This patch moves the RAM initialization to a separate function so it can
be called separately from device initialization from Device Tree.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
 drivers/net/can/m_can/m_can.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index bf8fdaeb955e..3f0445440146 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1489,6 +1489,20 @@ static int register_m_can_dev(struct net_device *dev)
 	return register_candev(dev);
 }
 
+static void m_can_init_ram(struct m_can_priv *priv)
+{
+	int end, i, start;
+
+	/* initialize the entire Message RAM in use to avoid possible
+	 * ECC/parity checksum errors when reading an uninitialized buffer
+	 */
+	start = priv->mcfg[MRAM_SIDF].off;
+	end = priv->mcfg[MRAM_TXB].off +
+		priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE;
+	for (i = start; i < end; i += 4)
+		writel(0x0, priv->mram_base + i);
+}
+
 static void m_can_of_parse_mram(struct m_can_priv *priv,
 				const u32 *mram_config_vals)
 {
@@ -1529,15 +1543,7 @@ static void m_can_of_parse_mram(struct m_can_priv *priv,
 		priv->mcfg[MRAM_TXE].off, priv->mcfg[MRAM_TXE].num,
 		priv->mcfg[MRAM_TXB].off, priv->mcfg[MRAM_TXB].num);
 
-	/* initialize the entire Message RAM in use to avoid possible
-	 * ECC/parity checksum errors when reading an uninitialized buffer
-	 */
-	start = priv->mcfg[MRAM_SIDF].off;
-	end = priv->mcfg[MRAM_TXB].off +
-		priv->mcfg[MRAM_TXB].num * TXB_ELEMENT_SIZE;
-	for (i = start; i < end; i += 4)
-		writel(0x0, priv->mram_base + i);
-
+	m_can_init_ram(priv);
 }
 
 static int m_can_plat_probe(struct platform_device *pdev)
-- 
2.11.0

^ permalink raw reply related

* [PATCH v3 2/2] can: m_can: add deep Suspend/Resume support
From: Quentin Schulz @ 2017-05-05 11:46 UTC (permalink / raw)
  To: wg, mkl, mario.huettel, socketcan
  Cc: Quentin Schulz, linux-can, netdev, linux-kernel,
	alexandre.belloni, thomas.petazzoni
In-Reply-To: <20170505114646.1278-1-quentin.schulz@free-electrons.com>

This adds Power Management deep Suspend/Resume support for Bosch M_CAN
chip.

When entering deep sleep, the clocks are gated, the interrupts are
disabled. When resuming from deep sleep, the chip needs to be
reinitialized, the clocks ungated and the interrupts enabled.

Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---

v3:
 - do not close/reopen the can interface (which was previously done when
 calling m_can_close), basically do the same routine as in probe but
 it does not close/open the can device,
 - update commit log,

v2:
 - fix erroneous commit log,

 drivers/net/can/m_can/m_can.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 3f0445440146..0a06690febe2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1672,10 +1672,9 @@ static __maybe_unused int m_can_suspend(struct device *dev)
 	if (netif_running(ndev)) {
 		netif_stop_queue(ndev);
 		netif_device_detach(ndev);
+		m_can_stop(ndev);
 	}
 
-	/* TODO: enter low power */
-
 	priv->can.state = CAN_STATE_SLEEPING;
 
 	return 0;
@@ -1686,11 +1685,23 @@ static __maybe_unused int m_can_resume(struct device *dev)
 	struct net_device *ndev = dev_get_drvdata(dev);
 	struct m_can_priv *priv = netdev_priv(ndev);
 
-	/* TODO: exit low power */
+	m_can_init_ram(priv);
 
 	priv->can.state = CAN_STATE_ERROR_ACTIVE;
 
 	if (netif_running(ndev)) {
+		int ret = clk_prepare_enable(priv->hclk);
+
+		if (ret)
+			return ret;
+
+		ret = clk_prepare_enable(priv->cclk);
+		if (ret) {
+			clk_disable_unprepare(priv->hclk);
+			return ret;
+		}
+
+		m_can_start(ndev);
 		netif_device_attach(ndev);
 		netif_start_queue(ndev);
 	}
-- 
2.11.0


^ permalink raw reply related

* [PATCH] net: alx: handle pci_alloc_irq_vectors return correctly
From: Rakesh Pandit @ 2017-05-05 11:28 UTC (permalink / raw)
  To: Jay Cliburn, Chris Snook
  Cc: David S. Miller, Tobias Regnery, Feng Tang, Eric Dumazet, netdev,
	linux-kernel, Christoph Hellwig

It was introduced while switching to pci_alloc_irq_vectors recently
and fixes:

[   60.527052] alx 0000:03:00.0 enp3s0: Enabling MSI-X interrupts failed!
[   60.529323] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8
[   60.531589] IP: alx_alloc_napis+0xe6/0x1e0 [alx]
[   60.533831] PGD 0
[   60.533833] P4D 0

[   60.540559] Oops: 0002 [#1] SMP
[   60.542759] Modules linked in: ebtables ip6table_filter ip6_tables.....
[   60.549990]  drm_kms_helper drm crc32c_intel alx serio_raw mdio wmi video i2c_hid uas usb_storage
[   60.551404] CPU: 0 PID: 999 Comm: NetworkManager Not tainted 4.11.0+ #1
[   60.552813] Hardware name: Acer Predator G9-591/Mustang_SLS, BIOS V1.10 03/03/2016
[   60.554219] task: ffff8804ae833c00 task.stack: ffffc90003eec000
[   60.555383] RIP: 0010:alx_alloc_napis+0xe6/0x1e0 [alx]
[   60.556615] RSP: 0018:ffffc90003eef660 EFLAGS: 00010286
[   60.557787] RAX: ffff8804962835a0 RBX: ffff8804aee8a8c0 RCX: 0000000000000000
[   60.558987] RDX: 0000000000000060 RSI: 0000000000000000 RDI: ffff880496283600
[   60.559979] RBP: ffffc90003eef688 R08: ffff8804c1c1e7e0 R09: ffff8804962835a0
[   60.560978] R10: ffff8804962835a0 R11: 0000000000000102 R12: 0000000000000000
[   60.561974] R13: 0000000000000000 R14: ffff8804aee8aaf0 R15: ffffffffa0052ea0
[   60.562974] FS:  00007f1cecbc9940(0000) GS:ffff8804c1c00000(0000) knlGS:0000000000000000
[   60.564003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   60.564884] CR2: 00000000000000b8 CR3: 0000000496025000 CR4: 00000000003406f0
[   60.565782] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   60.566676] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   60.567560] Call Trace:
[   60.568500]  __alx_open+0xa2/0x570 [alx]
[   60.569355]  ? notifier_call_chain+0x4a/0x70
[   60.570144]  alx_open+0x17/0x20 [alx]
[   60.570909]  __dev_open+0xc6/0x140
[   60.571682]  ? _raw_spin_unlock_bh+0x1a/0x20
[   60.572469]  __dev_change_flags+0x9d/0x160
[   60.573252]  dev_change_flags+0x29/0x60
[   60.574070]  do_setlink+0x32e/0xc90
[   60.574815]  ? ttwu_do_activate+0x77/0x80
[   60.575544]  ? drm_fb_helper_dirty.isra.17+0xc7/0xe0 [drm_kms_helper]
[   60.576273]  ? drm_fb_helper_cfb_imageblit+0x30/0x40 [drm_kms_helper]
[   60.577004]  ? bit_putcs+0x2f7/0x560
[   60.577729]  ? nla_parse+0x35/0x140
[   60.578518]  rtnl_newlink+0x7d3/0x900
[   60.579280]  ? security_capset+0x30/0x80
[   60.580029]  ? ns_capable_common+0x68/0x80
[   60.580747]  ? ns_capable+0x13/0x20
[   60.581453]  rtnetlink_rcv_msg+0xee/0x220
[   60.582198]  ? rtnl_newlink+0x900/0x900
[   60.582909]  netlink_rcv_skb+0xe7/0x120
[   60.583601]  rtnetlink_rcv+0x28/0x30
[   60.584303]  netlink_unicast+0x18c/0x220
[   60.585002]  netlink_sendmsg+0x2ba/0x3b0
[   60.585703]  sock_sendmsg+0x38/0x50
[   60.586436]  ___sys_sendmsg+0x2b6/0x2d0
[   60.587123]  ? lockref_put_or_lock+0x5e/0x80
[   60.587822]  ? dput+0x155/0x1d0
[   60.588518]  ? mntput+0x24/0x40
[   60.589215]  __sys_sendmsg+0x54/0x90
[   60.589907]  ? __sys_sendmsg+0x54/0x90
[   60.590627]  SyS_sendmsg+0x12/0x20
[   60.591333]  entry_SYSCALL_64_fastpath+0x1a/0xa5
[   60.592021] RIP: 0033:0x7f1ceb44e3b0
[   60.592697] RSP: 002b:00007fffd7f0a2d0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
[   60.593385] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1ceb44e3b0
[   60.594107] RDX: 0000000000000000 RSI: 00007fffd7f0a380 RDI: 000000000000000c
[   60.594798] RBP: 00007fffd7f0a800 R08: 0000000000000000 R09: 0000000000000000
[   60.595502] R10: 0000564ffbae6e20 R11: 0000000000000293 R12: 0000000000000001
[   60.596200] R13: 0000000000000002 R14: 0000000000000010 R15: 00007fffd7f0a4d0
[   60.596899] Code: ed 85 c9 0f 8f ec 00 00 00 48 8b 3d 9d 97 1a e2 ba 50 00 00 00 be c0 80 40 01 4c 8b a3 30 02 00 00 e8 ff e5 1d e1 48 85 c0 74 a3 <49> 89 84 24 b8 00 00 00 48 8b 93 30 02 00 00 48 8b 4b 08 48 89
[   60.597642] RIP: alx_alloc_napis+0xe6/0x1e0 [alx] RSP: ffffc90003eef660
[   60.598427] CR2: 00000000000000b8

Fixes: f3297f68 ("net: alx: switch to pci_alloc_irq_vectors")
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
---
 drivers/net/ethernet/atheros/alx/main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c
index a8c2db8..567ee54 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -838,7 +838,7 @@ static int alx_enable_msix(struct alx_priv *alx)
 
 	err = pci_alloc_irq_vectors(alx->hw.pdev, num_vec, num_vec,
 			PCI_IRQ_MSIX);
-	if (err) {
+	if (err < 0) {
 		netdev_warn(alx->dev, "Enabling MSI-X interrupts failed!\n");
 		return err;
 	}
@@ -904,7 +904,7 @@ static int alx_init_intr(struct alx_priv *alx)
 
 	ret = pci_alloc_irq_vectors(alx->hw.pdev, 1, 1,
 			PCI_IRQ_MSI | PCI_IRQ_LEGACY);
-	if (ret)
+	if (ret < 0)
 		return ret;
 
 	alx->num_vec = 1;
-- 
2.9.3

^ permalink raw reply related

* RE: Question about SOCK_SEQPACKET
From: David Laight @ 2017-05-05 11:21 UTC (permalink / raw)
  To: 'Steven Whitehouse', Sowmini Varadhan
  Cc: Sam Kumar, linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <e413b04e-b441-604c-f605-c5a28389d064@redhat.com>

From: Steven Whitehouse
> Sent: 05 May 2017 11:34
...
> Just before the part that you've quoted, the description for
> SOCK_SEQPACKET says:
> "The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and
> is also connection-oriented. The only difference between these types is
> that record boundaries are maintained using the SOCK_SEQPACKET type. A
> record can be sent using one or more output operations and received
> using one or more input operations, but a single operation never
> transfers parts of more than one record."

Right SOCK_SEQPACKET is for protocols like ISO transport.
There is no limit on the length of a 'record'.
I've written file transfer programs that put the entire file
data into a single 'record'. The receiver disconnected on
receipt of the 'end of record'.

The socket man pages could easily be wrong - they are very IP-centric.
Remember ISO transport use declined when Unix became more popular
back in the mid 1980s. Unix sockets have never really been used for
it - the address information needed just doesn't match that IP
(especially IPv4).

	David

^ permalink raw reply

* Re: Question about SOCK_SEQPACKET
From: Steven Whitehouse @ 2017-05-05 10:34 UTC (permalink / raw)
  To: Sowmini Varadhan; +Cc: Sam Kumar, linux-kernel, netdev@vger.kernel.org
In-Reply-To: <20170505100926.GD1547@oracle.com>

Hi,


On 05/05/17 11:09, Sowmini Varadhan wrote:
> On (05/05/17 10:45), Steven Whitehouse wrote:
>> I do wonder if the man page for recvmsg is wrong, or at least a bit
>> confusing. SOCK_SEQPACKET is stream based not message based - it just
>> happens to have EOR markers in the stream. There is no reason that the whole
>> message needs to be returned in a single read, and in fact that would be
>> impossible if the sender didn't insert any EOR markers but kept sending data
>> beyond the size that the socket could buffer.
>>
>> I notice that man 7 socket says SOCK_SEQPACKET is for datagrams of fixed
>> maximum length which is definitely wrong, as is the statement that a
>> consumer has to read an entire packet with each system call.
> Which man page do you think is wrong here? The POSIX definition is here
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/recvmsg.html
>
> The description in
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.html
>
> says, "It is protocol-specific whether a maximum record size is imposed."
> In my machine (Ubuntu 4.4.0-72, and it is in socket(2), not socket(7), btw)
> doesnt have any references to max length, but I'm not sure I'd boldly assert
> "definitely wrong" about the requirement of having to read entire
> packet in a system call (see POSIX man page)
>
> --Sowmini
>
Just before the part that you've quoted, the description for 
SOCK_SEQPACKET says:
"The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and 
is also connection-oriented. The only difference between these types is 
that record boundaries are maintained using the SOCK_SEQPACKET type. A 
record can be sent using one or more output operations and received 
using one or more input operations, but a single operation never 
transfers parts of more than one record."

The man page for socket says SOCK_SEQPACKET "Provides  a sequenced,  
reliable,  two-way connection-based data transmission path  for  
datagrams  of  fixed maximum  length" which is not true, because while 
there may be a length restriction, it is quite possible that there is 
not a length restriction (as per DECnet). It also says "a  consumer  is  
required  to read an entire packet with each input system call" which is 
also contradicted by POSIX which says that a record can be "received 
using one or more input operations". So both statements in the man page 
are wrong, I think.

I have to say that I'd not spotted the POSIX recvmsg wording before, 
which says "For message-based sockets, such as SOCK_DGRAM and 
SOCK_SEQPACKET, the entire message shall be read in a single operation" 
however that does contradict the earlier wording, where it explicitly 
says that multiple receive operations per record are ok for 
SOCK_SEQPACKET - at least if we assume that record == message in this 
case. Also, if this restriction was true (one message per recvmsg call) 
then MSG_EOR would never be needed on receive, since every recvmsg would 
be a single message/record only, and that same document does say that 
MSG_EOR can be set on receive for protocols which support it,

Steve.

^ permalink raw reply

* RE: SSE instructions for fast packet copy?
From: David Laight @ 2017-05-05 10:14 UTC (permalink / raw)
  To: 'Tom Herbert', Linux Kernel Network Developers
In-Reply-To: <CALx6S34r6Q_wCKqzv5YjKJyuETyYmY1y=M7uDYiLfpnXzqbheg@mail.gmail.com>

From: Tom Herbert
> Sent: 05 May 2017 06:51
> To: Linux Kernel Network Developers
> Subject: SSE instructions for fast packet copy?
> 
> Hi,
> 
> I am thinking about the possibility of using SSE in kernel for
> speeding up the kernel memcpy particularly for copy to userspace
> emeory, and maybe even using the string instructions (like if we
> supported regex in something like eBPF). AFAIK we don't use SSE in
> kernel because of xmm register state needing to be saved across
> context switch. However, if we start busy-polling a CPU in kernel on
> network queues then there might not be any context switches to worry
> about. In this model we'd want to enable SSE per CPU.
> 
> Has this ever been tried before? Is this at all feasible? :-) Is it
> possible to enable SSE for kernel for just one CPU? (I found CPUID
> will return SSE supported, but don't see how to enable other than
> -msse for compiling).

Not even worth thinking about.
With recent intel cpus 'rep movsb' is optimised in the hardware
(for cached memory) and will run as fast as any other copy.

(There is a related fubar that memcopytoio() is implemented
as memcpy() and then as 'rep movsb' so generates repeated
byte accesses to io memory.)

I'm pretty sure the FP registers are 'lazy saved'.
The cpu's sse registers (the entire FP register set) might
contain life values for a process that is running on a different cpu.
If that process executes an FP instruction it will fault and an IPI
issued to get the registers written to the processes fp save area
from where they can be loaded.
Any use of the sse registers would have to interact correctly
with that IPI code.

	David


^ permalink raw reply

* Re: [PATCH 0/9] net: thunderx: Adds XDP support
From: Sunil Kovvuri @ 2017-05-05 10:10 UTC (permalink / raw)
  To: Rami Rosen; +Cc: Sunil Goutham, LAKML, Netdev, LKML, David Miller
In-Reply-To: <CAKoUArku6tRuV=Y3fteY-R6eHM4daq-0ct6w1_unjkGA+yPTFQ@mail.gmail.com>

On Thu, May 4, 2017 at 2:09 AM, Rami Rosen <roszenrami@gmail.com> wrote:
> Thanks, Sunil.
>
>>with network stack: 0.32 Mpps
>>with XDP (XDP_TX): 3 Mpps
>>and XDP_DROP: 3.8 Mpps
>
> Interesting; May I ask - which packet size did you use ?

Packet size is 64bytes.

Thanks,
Sunil.

>
> Regards,
> Rami Rosen

^ permalink raw reply

* Re: Question about SOCK_SEQPACKET
From: Sowmini Varadhan @ 2017-05-05 10:09 UTC (permalink / raw)
  To: Steven Whitehouse; +Cc: Sam Kumar, linux-kernel, netdev@vger.kernel.org
In-Reply-To: <af19f11a-1bc3-bb8f-faf6-65c11b632bbf@redhat.com>

On (05/05/17 10:45), Steven Whitehouse wrote:
> 
> I do wonder if the man page for recvmsg is wrong, or at least a bit
> confusing. SOCK_SEQPACKET is stream based not message based - it just
> happens to have EOR markers in the stream. There is no reason that the whole
> message needs to be returned in a single read, and in fact that would be
> impossible if the sender didn't insert any EOR markers but kept sending data
> beyond the size that the socket could buffer.
> 
> I notice that man 7 socket says SOCK_SEQPACKET is for datagrams of fixed
> maximum length which is definitely wrong, as is the statement that a
> consumer has to read an entire packet with each system call.

Which man page do you think is wrong here? The POSIX definition is here

http://pubs.opengroup.org/onlinepubs/009695399/functions/recvmsg.html

The description in

http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_10.html

says, "It is protocol-specific whether a maximum record size is imposed."
In my machine (Ubuntu 4.4.0-72, and it is in socket(2), not socket(7), btw)
doesnt have any references to max length, but I'm not sure I'd boldly assert
"definitely wrong" about the requirement of having to read entire
packet in a system call (see POSIX man page)

--Sowmini

^ permalink raw reply

* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Amir Goldstein @ 2017-05-05 10:02 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Andy Shevchenko, Dan Williams, Linux ACPI, tpmdd-devel, intel-gfx,
	nouveau, linux-input, iommu, linux-mmc, Netdev, linux-pci,
	USB list, alsa-devel, linux-kernel@vger.kernel.org,
	Rafael J . Wysocki, Mika Westerberg, Borislav Petkov,
	Jarkko Sakkinen, Jani Nikula, Ben Skeggs, Benj
In-Reply-To: <20170505095739.GB6762@lst.de>

On Fri, May 5, 2017 at 12:57 PM, Christoph Hellwig <hch@lst.de> wrote:
> On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
>> To complete the picture for folks not cc'ed on my patches,
>> xfs use case suggests there is also justification for the additional helpers:
>>
>> uuid_is_null() / uuid_equal()
>> guid_is_null() / guid_equal()
>
> The is_null is useful and I bet we'll find other instances. I'm
> not sure _equals really adds much value over the existing _cmp
> helpers, but on the other hand they are so trivial that we might as
> well add them.

Exactly. The fact that not only xfs used the same helper name
(drivers/md/md.c) suggests that it useful.

>
> The other thing XFS has is uuid_copy.

Andy already listed uuid_copy.

^ permalink raw reply

* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Christoph Hellwig @ 2017-05-05  9:57 UTC (permalink / raw)
  To: Amir Goldstein
  Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
	Jarkko Sakkinen, Adrian Hunter, Benjamin Tissoires,
	Christoph Hellwig, Joerg Roedel, Linux ACPI, tpmdd-devel,
	Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
	Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
	Bjorn Helgaas, Dan Williams, Andy Shevchenko
In-Reply-To: <CAOQ4uxjErce01+xyDnM=nCJS+avQ4g6hQVvH3fVotj7Ws2moCQ@mail.gmail.com>

On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote:
> To complete the picture for folks not cc'ed on my patches,
> xfs use case suggests there is also justification for the additional helpers:
> 
> uuid_is_null() / uuid_equal()
> guid_is_null() / guid_equal()

The is_null is useful and I bet we'll find other instances.  I'm
not sure _equals really adds much value over the existing _cmp
helpers, but on the other hand they are so trivial that we might as
well add them.

The other thing XFS has is uuid_copy.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Amir Goldstein @ 2017-05-05  9:50 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Dan Williams, Linux ACPI, tpmdd-devel, intel-gfx, nouveau,
	linux-input, iommu, linux-mmc, Netdev, linux-pci, USB list,
	alsa-devel, linux-kernel@vger.kernel.org, Rafael J . Wysocki,
	Mika Westerberg, Borislav Petkov, Jarkko Sakkinen, Jani Nikula,
	Ben Skeggs, Benjamin Tissoires, Joerg
In-Reply-To: <1493976265.30052.21.camel@linux.intel.com>

On Fri, May 5, 2017 at 12:24 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
[...]
>> I think with this semantic change, our proposals can reach common
>> grounds
>> and satisfy a wider group of users (i.e. filesystem developers).
>>
>> Christoph also suggested a similar treatment to typedef guid_t to
>> struct uuid_le.
>> I don't know the use cases enough to comment on that.
>
> We may go this way. But I wouldn't prevent current users of uuid_le to
> continue using it without conversion (it may be done case by case after
> we settle an API)
>
> So, summarize what Christoph said it will look like
>
> typedef uuid_be uuid_t;
> typedef uuid_le guid_t
>
> uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
> guid_cmp() / guid_copy() / guid_to_bin() / etc
>
> Correct? Christoph?
>

That looks right to me.

To complete the picture for folks not cc'ed on my patches,
xfs use case suggests there is also justification for the additional helpers:

uuid_is_null() / uuid_equal()
guid_is_null() / guid_equal()

Cheers,
Amir.

^ permalink raw reply

* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Joe Perches @ 2017-05-05  9:47 UTC (permalink / raw)
  To: Johannes Berg; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493977157.2500.2.camel@sipsolutions.net>

On Fri, 2017-05-05 at 11:39 +0200, Johannes Berg wrote:
> On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> > On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > > o Use explicit casts to proper types instead of casts to (void *)
> > > >   and have the compiler do the implicit cast
> > > 
> > > I see no advantage in this, why? All it does is make the code
> > > longer,
> > > and if anything changes, you have to change it in multiple places
> > > now.
> > 
> > It makes use of the casted to types consistent within net/mac80211
> > 
> > Here are the current uses.  I changed iface .c to match the others.
> 
> Well, OK. I'd rather change the others I guess, don't really see the
> point.
> 
> > $ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
> > net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
> > net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
> > net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
> > net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
> > net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> > net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> > net/mac80211/agg-rx.c:	rx_agg = (struct ieee80211_rx_agg *) &skb->cb;
> 
> It's really just these three that are related to the iface.c ones
> anyway.
> 
> > net/mac80211/mlme.c:	struct ieee80211_rx_status *rx_status = (void *) skb->cb;
> > net/mac80211/mlme.c:	rx_status = (struct ieee80211_rx_status *) skb->cb;
> > 
> 
> These should be using IEEE80211_SKB_RXCB(skb) :)

patches welcome... :)

^ permalink raw reply

* Re: Question about SOCK_SEQPACKET
From: Steven Whitehouse @ 2017-05-05  9:45 UTC (permalink / raw)
  To: Sam Kumar, linux-kernel, netdev@vger.kernel.org
In-Reply-To: <CAGtMfeCt95bj3-J5+TNb5gxVJUBDrgRjMXqMz-3jk9cOh0Z=tA@mail.gmail.com>

Hi,


On 05/05/17 06:18, Sam Kumar wrote:
> Hello,
> I have recently had occasion to use SOCK_SEQPACKET sockets on Linux,
> and noticed some odd behavior. When using sendmsg and recvmsg with
> these sockets, it seems that the "end-of-record" flag (MSG_EOR) is not
> being propagated correctly.
It depends which protocol you are using as to whether that is true. 
SOCK_SEQPACKET is supposed to be identical to SOCK_STREAM except for the 
record separators. That is true for DECnet (but whether DECnet is still 
functional is another thing!) and not true for ax.25 which uses 
SOCK_SEQPACKET incorrectly. For AF_UNIX that you are using I'm not quite 
sure what would be expected.

> The man page for recvmsg(2) states:
>> The  msg_flags  field  in the msghdr is set on return of recvmsg().  It
>>         can contain several flags:
>>
>>         MSG_EOR
>>                indicates end-of-record; the data returned  completed  a  record
>>                (generally used with sockets of type SOCK_SEQPACKET).
>>
> The man page for recvmsg(3) states:
>> For
>>        message-based  sockets,  such as SOCK_DGRAM and SOCK_SEQPACKET, the entire
>>        message shall be read in a single operation.
>
>
> This leads me to believe that MSG_EOR should be set in the msghdr
> struct whenever recvmsg() returns data. However, I am not observing
> this flag ever being set, whether or not I set the MSG_EOR when
> sending the messages.
>
> If it helps you can take a look at the code I'm using. It is at
> https://github.com/samkumar/seqpacket-test/, commit
> 2a7dbc1f94bafce6950ee726bdd54da96945d083 (HEAD of master at the time
> of writing). Look at server.c and client.c (don't bother with
> goclient.go).
>
> The reason that I need to check MSG_EOR is that I need to distinguish
> between EOF and messages of length 0. For SOCK_STREAM sockets, a
> return value of 0 unambiguously means EOF, and for SOCK_DGRAM sockets
> a return value of 0 unambiguously means that a datagram of length 0
> was received.
>
> Because SOCK_SEQPACKET is both connection-based and message-oriented,
> a return value of 0 is ambiguous. Based on my reading of the man
> pages, reading the MSG_EOR bit would let me disambiguate between EOF
> and a zero-length datagram, because MSG_EOR would be set for a
> zero-length datagram, but would not be set for EOF.
>
> If someone could please help me understand MSG_EOR, and how to
> distinguish between EOF and zero-length messages in a SOCK_SEQPACKET
> connection, I would definitely appreciate it!
>
> Thanks,
> Sam Kumar
That would be my expectation of how it should work - if you ignore 
MSG_EOR on recvmsg then what you get is identical to a SOCK_STREAM, and 
that every call to recvmsg will return data from (at most) a single 
message, with MSG_EOR set if the end of that message has been reached. 
That is what POSIX says should happen anyway.

I do wonder if the man page for recvmsg is wrong, or at least a bit 
confusing. SOCK_SEQPACKET is stream based not message based - it just 
happens to have EOR markers in the stream. There is no reason that the 
whole message needs to be returned in a single read, and in fact that 
would be impossible if the sender didn't insert any EOR markers but kept 
sending data beyond the size that the socket could buffer.

I notice that man 7 socket says SOCK_SEQPACKET is for datagrams of fixed 
maximum length which is definitely wrong, as is the statement that a 
consumer has to read an entire packet with each system call.

Also it is probably better to ask this question on netdev where it is 
likely to get more attention from the net developers, so I'm copying my 
reply there too,

Steve.

^ permalink raw reply

* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Johannes Berg @ 2017-05-05  9:39 UTC (permalink / raw)
  To: Joe Perches; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493976873.31950.15.camel@perches.com>

On Fri, 2017-05-05 at 02:34 -0700, Joe Perches wrote:
> On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > > o Use explicit casts to proper types instead of casts to (void *)
> > >   and have the compiler do the implicit cast
> > 
> > I see no advantage in this, why? All it does is make the code
> > longer,
> > and if anything changes, you have to change it in multiple places
> > now.
> 
> It makes use of the casted to types consistent within net/mac80211
> 
> Here are the current uses.  I changed iface .c to match the others.

Well, OK. I'd rather change the others I guess, don't really see the
point.

> $ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
> net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
> net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
> net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
> net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
> net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
> net/mac80211/agg-rx.c:	rx_agg = (struct ieee80211_rx_agg *) &skb->cb;

It's really just these three that are related to the iface.c ones
anyway.

> net/mac80211/mlme.c:	struct ieee80211_rx_status *rx_status = (void *) skb->cb;
> net/mac80211/mlme.c:	rx_status = (struct ieee80211_rx_status *) skb->cb;
> 

These should be using IEEE80211_SKB_RXCB(skb) :)

johannes

^ permalink raw reply

* Re: [PATCH v2 net] tcp: randomize timestamps on syncookies
From: Florian Westphal @ 2017-05-05  9:36 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Florian Westphal, David Miller, netdev, Yuchung Cheng
In-Reply-To: <1493950957.7796.36.camel@edumazet-glaptop3.roam.corp.google.com>

Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
> 
> Whole point of randomization was to hide server uptime, but an attacker
> can simply start a syn flood and TCP generates 'old style' timestamps,
> directly revealing server jiffies value.
> 
> Also, TSval sent by the server to a particular remote address vary
> depending on syncookies being sent or not, potentially triggering PAWS
> drops for innocent clients.
> 
> Lets implement proper randomization, including for SYNcookies.


Thanks a lot Eric, this works for me (I also tested ipv6 this time ;) )

Minor nit:
net/ipv4/tcp_ipv4.c:154:6: warning: unused variable 'seq' [-Wunused-variable]

Other than this:
Reviewed-by: Florian Westphal <fw@strlen.de>
Tested-by: Florian Westphal <fw@strlen.de>

^ permalink raw reply

* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Joe Perches @ 2017-05-05  9:34 UTC (permalink / raw)
  To: Johannes Berg; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <1493975178.2500.0.camel@sipsolutions.net>

On Fri, 2017-05-05 at 11:06 +0200, Johannes Berg wrote:
> > o Use explicit casts to proper types instead of casts to (void *)
> >   and have the compiler do the implicit cast
> 
> I see no advantage in this, why? All it does is make the code longer,
> and if anything changes, you have to change it in multiple places now.

It makes use of the casted to types consistent within net/mac80211

Here are the current uses.  I changed iface .c to match the others.

$ grep -P --include=*.[ch] "\((\w++\s*){1,2}\s*\*\).*skb->cb" net/mac80211
net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
net/mac80211/iface.c:			ra_tid = (void *)&skb->cb;
net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
net/mac80211/iface.c:			rx_agg = (void *)&skb->cb;
net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
net/mac80211/agg-tx.c:	ra_tid = (struct ieee80211_ra_tid *) &skb->cb;
net/mac80211/mlme.c:	struct ieee80211_rx_status *rx_status = (void *) skb->cb;
net/mac80211/mlme.c:	rx_status = (struct ieee80211_rx_status *) skb->cb;
net/mac80211/agg-rx.c:	rx_agg = (struct ieee80211_rx_agg *) &skb->cb;

^ permalink raw reply

* Re: [PATCH v1] ACPI: Switch to use generic UUID API
From: Andy Shevchenko @ 2017-05-05  9:24 UTC (permalink / raw)
  To: Amir Goldstein, Dan Williams
  Cc: alsa-devel, Heikki Krogerus, Liam Girdwood, linux-pci,
	Jarkko Sakkinen, Adrian Hunter, Benjamin Tissoires,
	Christoph Hellwig, Joerg Roedel, Linux ACPI, tpmdd-devel,
	Ben Skeggs, nouveau, linux-mmc, Zhang Rui, Borislav Petkov,
	Yisen Zhuang, Mathias Nyman, intel-gfx, linux-input, Mark Brown,
	Bjorn Helgaas, Mika Westerberg, Felipe Balbi, Ne
In-Reply-To: <CAOQ4uxjha8_2_HwgdgBN=G-vNytAW5Gk155E9z8OWyFiGNEZVw@mail.gmail.com>

On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote:
> On Fri, May 5, 2017 at 9:20 AM, Dan Williams <dan.j.williams@intel.com
> > wrote:
> > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:


> > >         for (i = 0; i < NFIT_UUID_MAX; i++)
> > > -               if (memcmp(to_nfit_uuid(i), spa->range_guid, 16)
> > > == 0)
> > > +               if (!uuid_le_cmp_pp(to_nfit_uuid(i), (uuid_le
> > > *)spa->range_guid))
> > 
> > What is _cmp_pp? Why not _compare?

Dan, it's a typo. In this patch it should be just ..._cmp(), which is
already a part of API.

> > 
> 
> I second that.
> 
> Andy,

Amir, just to be clear. This patch can be applied without any addons to
an existing API. Above is just a typo due to rebase in my tree. I will
replace it to just uuid_le_cmp().

> I much rather that you sort out uuid helpers in a way that will
> satisfy the filesystem
> needs (just provide the helpers don't need to convert filesystems
> code).

> The only reason I took a swing at hoisting the xfs uuid helpers is
> because it didn't
> seem like your proposal was going to be posted soon or wasn't going to
> satisfy
> the filesystems use case.

> 
> My opinion now, is that your suggestion is probably much closer to the
> real deal
> than mine.
> 
> IMO, you should acknowledge that the common use case for filesystems
> is
> to handle an opaque char[16] which most likely holds a uuid_be and you
> should provide 'neutral' helpers to satisfy this use case.
> 
> The simplest would be to typedef uuid_t to struct uuid_be and to name
> 'neutral'
> helpers' uuid_cmp/uuid_copy(uuid_t *, uuid_t *), similar to my
> proposal.

> I think with this semantic change, our proposals can reach common
> grounds
> and satisfy a wider group of users (i.e. filesystem developers).
> 
> Christoph also suggested a similar treatment to typedef guid_t to
> struct uuid_le.
> I don't know the use cases enough to comment on that.

We may go this way. But I wouldn't prevent current users of uuid_le to
continue using it without conversion (it may be done case by case after
we settle an API)

So, summarize what Christoph said it will look like

typedef uuid_be uuid_t;
typedef uuid_le guid_t

uuid_cmp() / uuid_copy() / uuid_to_bin() / etc
guid_cmp() / guid_copy() / guid_to_bin() / etc

Correct? Christoph?

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: net/key: slab-out-of-bounds in pfkey_compile_policy
From: Steffen Klassert @ 2017-05-05  9:11 UTC (permalink / raw)
  To: Andrey Konovalov; +Cc: Herbert Xu, David S. Miller, netdev, LKML
In-Reply-To: <CAAeHK+xqxvEWMXS9sDNi2seUqFzJkijKJhivB8JDehpCJvBAaw@mail.gmail.com>

On Tue, May 02, 2017 at 06:45:03PM +0200, Andrey Konovalov wrote:
> Hi,
> 
> I've got the following error report while fuzzing the kernel with syzkaller.
> 
> On commit d3b5d35290d729a2518af00feca867385a1b08fa (4.11).
> 
> A reproducer and .config are attached.
> 
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in pfkey_compile_policy+0x8e6/0xd40 at
> addr ffff88006701f798
> Read of size 1280 by task a.out/4181


This bug was introduced twelve years ago...

This patch is based just on code review, I don't have an option to
function test this. But I see that we now exit with -EINVAL before the
memcpy that causes the slab-out-of-bounds when using your reproducer,
so it should at least fix the bug.

Subject: [PATCH RFC] af_key: Fix slab-out-of-bounds in pfkey_compile_policy.

The sadb_x_sec_len is stored in the unit 'byte divided by eight'.
So we have to multiply this value by eight before we can do
size checks. Otherwise we may get a slab-out-of-bounds when
we memcpy the user sec_ctx.

Fixes: df71837d502 ("[LSM-IPSec]: Security association restriction.")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
 net/key/af_key.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/key/af_key.c b/net/key/af_key.c
index c1950bb..512dc43 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3285,7 +3285,7 @@ static struct xfrm_policy *pfkey_compile_policy(struct sock *sk, int opt,
 		p += pol->sadb_x_policy_len*8;
 		sec_ctx = (struct sadb_x_sec_ctx *)p;
 		if (len < pol->sadb_x_policy_len*8 +
-		    sec_ctx->sadb_x_sec_len) {
+		    sec_ctx->sadb_x_sec_len*8) {
 			*dir = -EINVAL;
 			goto out;
 		}
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH] mac80211: Create ieee80211_if_process_skb from ieee80211_iface_work
From: Johannes Berg @ 2017-05-05  9:06 UTC (permalink / raw)
  To: Joe Perches; +Cc: David S. Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <401d68b9015dc036589c99a26ef4664000cc821e.1493919003.git.joe@perches.com>


> o Use explicit casts to proper types instead of casts to (void *)
>   and have the compiler do the implicit cast

I see no advantage in this, why? All it does is make the code longer,
and if anything changes, you have to change it in multiple places now.

johannes

^ permalink raw reply

* how to insert new option header into ipv6 hop by hop for tx
From: JANARDHANACHARI KELLA @ 2017-05-05  8:40 UTC (permalink / raw)
  To: netdev

Hi,

i wish to insert a new option like pad1, padn and rpl option into hop
by hop option payload of ipv6 transmission. how can insert into the
ipv6 module? can i get suggestion?


Thanks & Regards

-- 

Janardhanachari Kella
E-mail: janardhanachari.kella@smartron.com

^ permalink raw reply

* [tip:x86/urgent] x86/asm: Don't use RBP as a temporary register in csum_partial_copy_generic()
From: tip-bot for Josh Poimboeuf @ 2017-05-05  8:10 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: linux-kernel, jpoimboe, nhorman, syzkaller, netdev, kcc,
	marcelo.leitner, edumazet, torvalds, andreyknvl, mingo,
	xiyou.wangcong, peterz, davem, dvyukov, tglx, vyasevich, hpa
In-Reply-To: <4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com>

Commit-ID:  42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Gitweb:     http://git.kernel.org/tip/42fc6c6cb1662ba2fa727dd01c9473c63be4e3b6
Author:     Josh Poimboeuf <jpoimboe@redhat.com>
AuthorDate: Thu, 4 May 2017 09:51:40 -0500
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Fri, 5 May 2017 07:59:24 +0200

x86/asm: Don't use RBP as a temporary register in csum_partial_copy_generic()

Andrey Konovalov reported the following warning while fuzzing the kernel
with syzkaller:

  WARNING: kernel stack regs at ffff8800686869f8 in a.out:4933 has bad 'bp' value c3fc855a10167ec0

The unwinder dump revealed that RBP had a bad value when an interrupt
occurred in csum_partial_copy_generic().

That function saves RBP on the stack and then overwrites it, using it as
a scratch register.  That's problematic because it breaks stack traces
if an interrupt occurs in the middle of the function.

Replace the usage of RBP with another callee-saved register (R15) so
stack traces are no longer affected.

Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: David S . Miller <davem@davemloft.net>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Kostya Serebryany <kcc@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Neil Horman <nhorman@tuxdriver.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Cc: linux-sctp@vger.kernel.org
Cc: netdev <netdev@vger.kernel.org>
Cc: syzkaller <syzkaller@googlegroups.com>
Link: http://lkml.kernel.org/r/4b03a961efda5ec9bfe46b7b9c9ad72d1efad343.1493909486.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/lib/csum-copy_64.S | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/lib/csum-copy_64.S b/arch/x86/lib/csum-copy_64.S
index 7e48807..45a53df 100644
--- a/arch/x86/lib/csum-copy_64.S
+++ b/arch/x86/lib/csum-copy_64.S
@@ -55,7 +55,7 @@ ENTRY(csum_partial_copy_generic)
 	movq  %r12, 3*8(%rsp)
 	movq  %r14, 4*8(%rsp)
 	movq  %r13, 5*8(%rsp)
-	movq  %rbp, 6*8(%rsp)
+	movq  %r15, 6*8(%rsp)
 
 	movq  %r8, (%rsp)
 	movq  %r9, 1*8(%rsp)
@@ -74,7 +74,7 @@ ENTRY(csum_partial_copy_generic)
 	/* main loop. clear in 64 byte blocks */
 	/* r9: zero, r8: temp2, rbx: temp1, rax: sum, rcx: saved length */
 	/* r11:	temp3, rdx: temp4, r12 loopcnt */
-	/* r10:	temp5, rbp: temp6, r14 temp7, r13 temp8 */
+	/* r10:	temp5, r15: temp6, r14 temp7, r13 temp8 */
 	.p2align 4
 .Lloop:
 	source
@@ -89,7 +89,7 @@ ENTRY(csum_partial_copy_generic)
 	source
 	movq  32(%rdi), %r10
 	source
-	movq  40(%rdi), %rbp
+	movq  40(%rdi), %r15
 	source
 	movq  48(%rdi), %r14
 	source
@@ -103,7 +103,7 @@ ENTRY(csum_partial_copy_generic)
 	adcq  %r11, %rax
 	adcq  %rdx, %rax
 	adcq  %r10, %rax
-	adcq  %rbp, %rax
+	adcq  %r15, %rax
 	adcq  %r14, %rax
 	adcq  %r13, %rax
 
@@ -121,7 +121,7 @@ ENTRY(csum_partial_copy_generic)
 	dest
 	movq %r10, 32(%rsi)
 	dest
-	movq %rbp, 40(%rsi)
+	movq %r15, 40(%rsi)
 	dest
 	movq %r14, 48(%rsi)
 	dest
@@ -203,7 +203,7 @@ ENTRY(csum_partial_copy_generic)
 	movq 3*8(%rsp), %r12
 	movq 4*8(%rsp), %r14
 	movq 5*8(%rsp), %r13
-	movq 6*8(%rsp), %rbp
+	movq 6*8(%rsp), %r15
 	addq $7*8, %rsp
 	ret
 

^ permalink raw reply related

* Re: struct ip vs struct iphdr
From: Oleg @ 2017-05-05  8:02 UTC (permalink / raw)
  To: Girish Moodalbail; +Cc: netdev
In-Reply-To: <d56b2182-3c81-5c52-5d77-8be128088e1b@oracle.com>

On Thu, May 04, 2017 at 10:08:46AM -0700, Girish Moodalbail wrote:
> Also, see this:
> 
> http://stackoverflow.com/questions/42840636/difference-between-struct-ip-and-struct-iphdr

  I saw this. But the answer say that struct ip and struct iphdr defined in
different places. However i see struct iphdr together with struct ip in
my netinet/ip.h. So, i thought that this answer may be inexact or incorrect.

  Thanks!

-- 
Олег Неманов (Oleg Nemanov)

^ permalink raw reply

* Re: [Unstrung-hackers] [RFC net-next] ipv6: ext_header: add function to handle RPL extension header option 0x63
From: Andreas Bardoutsos @ 2017-05-05  7:55 UTC (permalink / raw)
  To: JANARDHANACHARI KELLA
  Cc: Jiri Pirko, Michael Richardson, netdev, netdev-owner,
	linux-bluetooth, linux-wpan, unstrung-hackers
In-Reply-To: <CAAK7Ti9iFFqM7vMyveNfaNeCi6PmAGptXdTYgEzh2gsMptqi4w@mail.gmail.com>

Yes I think we have faced the same problem,communication with RPL 
supporting devices was failing otherwise.Your patch is also more 
complete since it also implements #ifdef .About the comment,yes I have 
run checkpatch twice with no errors,but ok :)

Στις 2017-05-05 08:59, JANARDHANACHARI KELLA έγραψε:
> I was inserted this patch manually. It was working. on 4.9 kernel.
> 
> check this bellow link for your ref.
> 
> https://github.com/mwasilak/bluetooth-next/commit/f29c632ef6a6a1777815c97fd2f326faccc704f7
> [2]
> 
> On Thu, May 4, 2017 at 9:30 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> 
>> Thu, May 04, 2017 at 05:17:18PM CEST, bardoutsos@ceid.upatras.gr
>> wrote:
>>> Signed-off-by: Andreas Bardoutsos <bardoutsos@ceid.upatras.gr>
>>> ---
>>> Hi all!
>>> 
>>> I have added a dump function(always return true) to recognise RPL
>> extension
>>> header(RFC6553)
>>> Otherwise packet was dropped by kernel resulting in failing
>> communication in
>>> RPL DAG's between
>>> linux running border routers and devices in the graph.For example
>>> communication
>>> with contiki OS running devices was previously impossible.
>>> 
>>> include/uapi/linux/in6.h | 1 +
>>> net/ipv6/exthdrs.c | 13 +++++++++++++
>>> 2 files changed, 14 insertions(+)
>>> 
>>> diff --git a/include/uapi/linux/in6.h b/include/uapi/linux/in6.h
>>> index 46444f8fbee4..5cc12d309dfe 100644
>>> --- a/include/uapi/linux/in6.h
>>> +++ b/include/uapi/linux/in6.h
>>> @@ -146,6 +146,7 @@ struct in6_flowlabel_req {
>>> #define IPV6_TLV_CALIPSO 7 /* RFC 5570 */
>>> #define IPV6_TLV_JUMBO 194
>>> #define IPV6_TLV_HAO 201 /* home address option */
>>> +#define IPV6_TLV_RPL 99 /* RFC 6553 */
>>> 
>>> /*
>>> * IPV6 socket options
>>> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
>>> index b636f1da9aec..82ed60d3180e 100644
>>> --- a/net/ipv6/exthdrs.c
>>> +++ b/net/ipv6/exthdrs.c
>>> @@ -785,6 +785,15 @@ static bool ipv6_hop_calipso(struct sk_buff
>> *skb, int
>>> optoff)
>>> return false;
>>> }
>>> 
>>> +/* RPL RFC 6553 */
>>> +
>>> +static bool ipv6_hop_rpl(struct sk_buff *skb, int optoff)
>>> +{
>>> + /*Dump function which always return true
>>> + *when rpl option is detected*/
>> 
>> This is definitelly wrong formatting of comment. Did you run
>> checkpatch?
>> 
>>> + return true;
>>> +}
>>> +
>>> static const struct tlvtype_proc tlvprochopopt_lst[] = {
>>> {
>>> .type = IPV6_TLV_ROUTERALERT,
>>> @@ -798,6 +807,10 @@ static const struct tlvtype_proc
>> tlvprochopopt_lst[] = {
>>> .type = IPV6_TLV_CALIPSO,
>>> .func = ipv6_hop_calipso,
>>> },
>>> + {
>>> + .type = IPV6_TLV_RPL,
>>> + .func = ipv6_hop_rpl,
>>> + },
>>> { -1, }
>>> };
>>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-wpan" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> [1]
> 
> --
> 
> Sincerely Your's
> 
> Janardhanachari Kella
> 
> Contact:+91-9908469599
> E-mail: eni.chari@gmail.com
> 
> 
> Links:
> ------
> [1] http://vger.kernel.org/majordomo-info.html
> [2]
> https://github.com/mwasilak/bluetooth-next/commit/f29c632ef6a6a1777815c97fd2f326faccc704f7
> 
> _______________________________________________
> Unstrung-hackers mailing list
> Unstrung-hackers@lists.sandelman.ca
> https://lists.sandelman.ca/mailman/listinfo/unstrung-hackers

^ permalink raw reply

* Re: struct ip vs struct iphdr
From: Oleg @ 2017-05-05  7:48 UTC (permalink / raw)
  To: Sowmini Varadhan; +Cc: netdev
In-Reply-To: <20170504165248.GI7300@oracle.com>

On Thu, May 04, 2017 at 12:52:48PM -0400, Sowmini Varadhan wrote:
> BSD vs linux?
> 
> struct ip is a BSD-ism, intended to be used if you were porting
> some BSD app.

  Thanks!

-- 
Олег Неманов (Oleg Nemanov)

^ permalink raw reply

* Re: [PATCH] iproute2: hide devices starting with period by default
From: Nicolas Dichtel @ 2017-05-05  7:42 UTC (permalink / raw)
  To: David Ahern, Florian Fainelli; +Cc: David Miller, stephen, netdev
In-Reply-To: <01aa60dc-8bf2-3207-1abe-158100f52960@gmail.com>

Le 04/05/2017 à 21:47, David Ahern a écrit :
> On 5/4/17 1:10 PM, Florian Fainelli wrote:
>> On 05/04/2017 09:37 AM, David Ahern wrote:
>>> On 5/4/17 9:15 AM, Nicolas Dichtel wrote:
>>>> Le 24/02/2017 à 16:52, David Ahern a écrit :
>>>>> On 2/23/17 8:12 PM, David Miller wrote:
>>>>>> This really need to be a fundamental facility, so that it transparently
>>>>>> works for NetworkManager, router daemons, everything.  Not just iproute2
>>>>>> and "ls".
>>>>>
>>>>> I'll rebase my patch and send out as RFC.
>>>>>
>>>> David, did you finally send those patches?
>>>>
>>>
>>> No, but for a few reasons.
>>>
>>> It is easy to hide devices in a dump:
>>>
>>> https://github.com/dsahern/linux/commit/48a80a00eac284e58bae04af10a5a932dd7aee00
>>>
>>>
>>> But I think those devices should also not exist in sysfs or procfs which
>>> overlaps what I would like to see for lightweight netdevices:
>>>
>>> https://github.com/dsahern/linux/commit/70574be699cf252e77f71e3df11192438689f976
>>
>> Interesting that does indeed solve the same problems as the L2 only
>> patch set intended. I am not exactly sure if hiding the devices from
>> procfs/sysfs would be appropriate in my case (dumb L2 only switch that
>> only does 802.1q for instance), but why not.
>>
>>
>>>
>>>
>>> and to be complete, hidden devices should not be allowed to have a
>>> network address or transmit packets which is the L2 only intent from
>>> Florian:
>>>     https://www.spinics.net/lists/netdev/msg340808.html
>>>
>>
>> Do you plan on submitting the LWT patch set at some point?
> 
> Definitely. Maybe I can find some time this weekend.
> 
Ok, thank you for the details.

I agree with Jiri that the name should be something different than lwt.


Regards,
Nicolas

^ 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