* Re: [PATCH net-next v3 0/2] net: bridge: add support for backup port
From: David Miller @ 2018-07-23 16:32 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, anuradhak, wkok, bridge, stephen, makita.toshiaki
In-Reply-To: <20180723081659.21986-1-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Mon, 23 Jul 2018 11:16:57 +0300
> This set introduces a new bridge port option that allows any port to have
> any other port (in the same bridge of course) as its backup and traffic
> will be forwarded to the backup port when the primary goes down. This is
> mainly used in MLAG and EVPN setups where we have peerlink path which is
> a backup of many (or even all) ports and is a participating bridge port
> itself. There's more detailed information in patch 02. Patch 01 just
> prepares the port sysfs code for options that take raw value. The main
> issues that this set solves are scalability and fallback latency.
...
Series applied, thanks Nikolay.
^ permalink raw reply
* Re: [net-next v5 3/3] net/tls: Remove redundant array allocation.
From: Dave Watson @ 2018-07-23 16:35 UTC (permalink / raw)
To: David Miller; +Cc: vakul.garg, netdev, borisp, aviadye, Doron Roberts-Kedes
In-Reply-To: <20180721.192532.520509909556885779.davem@davemloft.net>
On 07/21/18 07:25 PM, David Miller wrote:
> From: Vakul Garg <vakul.garg@nxp.com>
> Date: Thu, 19 Jul 2018 21:56:13 +0530
>
> > In function decrypt_skb(), array allocation in case when sgout is NULL
> > is unnecessary. Instead, local variable sgin_arr[] can be used.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>
> Hmmm...
>
> Dave, can you take a look at this? Do you think there might have
> been a reason you felt that you needed to dynamically allocate
> the scatterlists when you COW and skb and do in-place decryption?
>
> I guess this change is ok, nsg can only get smaller when the SKB
> is COW'd.
>
> > memcpy(iv, tls_ctx->rx.iv, TLS_CIPHER_AES_GCM_128_SALT_SIZE);
> > if (!sgout) {
> > nsg = skb_cow_data(skb, 0, &unused) + 1;
> > - sgin = kmalloc_array(nsg, sizeof(*sgin), sk->sk_allocation);
> > sgout = sgin;
> > }
I don't think this patch is safe as-is. sgin_arr is a stack array of
size MAX_SKB_FRAGS (+ overhead), while my read of skb_cow_data is that
it walks the whole chain of skbs from skb->next, and can return any
number of segments. Therefore we need to heap allocate. I think I
copied the IPSEC code here.
For perf though, we could use the stack array if skb_cow_data returns
<= MAX_SKB_FRAGS.
This code is slightly confusing though, since we don't heap allocate
in the zerocopy case - what happens is that skb_to_sgvec returns
-EMSGSIZE, and we fall back to the non-zerocopy case, and return again
to this function, where we then hit the skb_cow_data path and heap
allocate.
^ permalink raw reply
* Re: KASAN: use-after-free Read in rds_cong_queue_updates (2)
From: Santosh Shilimkar @ 2018-07-23 17:38 UTC (permalink / raw)
To: syzbot, davem, linux-kernel, linux-rdma, netdev, rds-devel,
syzkaller-bugs
In-Reply-To: <000000000000cdb5450571adfe40@google.com>
On 7/23/2018 10:30 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: fcf4793e278e tls: check RCV_SHUTDOWN in tls_wait_data
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=1738cb2c400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c0bdc4175608181c
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=470ae97a39f16146af45
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+470ae97a39f16146af45@syzkaller.appspotmail.com
>
dup: syzbot+4c20b3866171ce8441d2@syzkaller.appspotmail.com
^ permalink raw reply
* Re: [PATCH net-next] selftests: forwarding: gre_multipath: Drop IPv6 tests
From: David Miller @ 2018-07-23 16:47 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, shuah, idosch, dsahern
In-Reply-To: <cf0e380baf6a6aa5cf384017e8d69fec79750cfe.1532341813.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Mon, 23 Jul 2018 12:33:08 +0200
> Support for device-only IPv6 multipath next hops was dropped in
> commit 33bd5ac54dc4 ("net/ipv6: Revert attempt to simplify route replace
> and append") and as of commit b5d2d75e079a ("net/ipv6: Do not allow
> device only routes via the multipath API"), attempts to add a next hop
> like that yield an explicit diagnostic.
>
> Correspondingly, drop the IPv6 parts of GRE multipath test that are
> supposed to test that code.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH nf] netfilter: nf_tables: move dumper state alloation into ->start
From: David Miller @ 2018-07-23 16:47 UTC (permalink / raw)
To: fw; +Cc: netfilter-devel, netdev, cscnull
In-Reply-To: <20180723104714.24008-1-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Mon, 23 Jul 2018 12:47:14 +0200
> Shaochun Chen points out we leak dumper filter state allocations
> stored in dump_control->data in case there is an error before netlink sets
> cb_running (after which ->done will be called at some point).
>
> In order to fix this, add .start functions and do the allocations
> there.
>
> ->done is going to clean up, and in case error occurs before
> ->start invocation no cleanups need to be done anymore.
>
> Reported-by: shaochun chen <cscnull@gmail.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls
From: Steve Grubb @ 2018-07-23 16:48 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Paul Moore, cgroups, containers, linux-api, linux-audit,
linux-fsdevel, linux-kernel, netdev, ebiederm, luto, carlos,
dhowells, viro, simo, Eric Paris, serge
In-Reply-To: <20180723151148.hyu4jqy2etp5afpt@madcap2.tricolour.ca>
On Monday, July 23, 2018 11:11:48 AM EDT Richard Guy Briggs wrote:
> On 2018-07-23 09:19, Steve Grubb wrote:
> > On Sunday, July 22, 2018 4:55:10 PM EDT Richard Guy Briggs wrote:
> > > On 2018-07-22 09:32, Steve Grubb wrote:
> > > > On Saturday, July 21, 2018 4:29:30 PM EDT Richard Guy Briggs wrote:
> > > > > > > + * audit_log_contid - report container info
> > > > > > > + * @tsk: task to be recorded
> > > > > > > + * @context: task or local context for record
> > > > > > > + * @op: contid string description
> > > > > > > + */
> > > > > > > +int audit_log_contid(struct task_struct *tsk,
> > > > > > > + struct audit_context *context,
> > > > > > > char
> > > > > > > *op)
> > > > > > > +{
> > > > > > > + struct audit_buffer *ab;
> > > > > > > +
> > > > > > > + if (!audit_contid_set(tsk))
> > > > > > > + return 0;
> > > > > > > + /* Generate AUDIT_CONTAINER record with container ID */
> > > > > > > + ab = audit_log_start(context, GFP_KERNEL,
> > > > > > > AUDIT_CONTAINER);
> > > > > > > + if (!ab)
> > > > > > > + return -ENOMEM;
> > > > > > > + audit_log_format(ab, "op=%s contid=%llu",
> > > > > > > + op, audit_get_contid(tsk));
> > > > > >
> > > > > > Can you explain your reason for including an "op" field in this
> > > > > > record
> > > > > > type? I've been looking at the rest of the patches in this
> > > > > > patchset
> > > > > > and it seems to be used more as an indicator of the record's
> > > > > > generating context rather than any sort of audit container ID
> > > > > > operation.
> > > > >
> > > > > "action" might work, but that's netfilter and numeric... "kind"?
> > > > > Nothing else really seems to fit from a field name, type or lack of
> > > > > searchability perspective.
> > > > >
> > > > > Steve, do you have an opinion?
> > > >
> > > > We only have 1 sample event where we have op=task. What are the other
> > > > possible values?
> > >
> > > For the AUDIT_CONTAINER record we have op= "task", "target" (from the
> > > ptrace and signals patch), "tty".
> > >
> > > For the AUDIT_CONTAINER_ID record we have "op=set".
> >
> > Since the purpose of this record is to log the container id, I think that
> > is all that is needed. We can get the context from the other records in
> > the event. I'd suggest dropping the "op" field.
>
> Ok, the information above it for two different audit container
> identifier records. Which one should drop the "op=" field? Both? Or
> just the AUDIT_CONTAINER record? The AUDIT_CONTAINER_ID record (which
> might be renamed) could use it to distinguish a "set" record from a
> dropped audit container identifier that is no longer registered by any
> task or namespace.
Neither of them need it. All they need to do is state the container that is
being acted upon.
-Steve
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Jason Gunthorpe @ 2018-07-23 16:49 UTC (permalink / raw)
To: Max Gurtovoy
Cc: Steve Wise, 'Sagi Grimberg', 'Leon Romanovsky',
'Doug Ledford', 'RDMA mailing list',
'Saeed Mahameed', 'linux-netdev'
In-Reply-To: <f936d176-c56b-143e-3311-f6df48f633dd@mellanox.com>
On Fri, Jul 20, 2018 at 04:25:32AM +0300, Max Gurtovoy wrote:
>
> >>>[ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
> >>
> >>queue 9 is not mapped (overlap).
> >>please try the bellow:
> >>
> >
> >This seems to work. Here are three mapping cases: each vector on its
> >own cpu, each vector on 1 cpu within the local numa node, and each
> >vector having all cpus in its numa node. The 2nd mapping looks kinda
> >funny, but I think it achieved what you wanted? And all the cases
> >resulted in successful connections.
> >
>
> Thanks for testing this.
> I slightly improved the setting of the left CPUs and actually used Sagi's
> initial proposal.
>
> Sagi,
> please review the attached patch and let me know if I should add your
> signature on it.
> I'll run some perf test early next week on it (meanwhile I run login/logout
> with different num_queues successfully and irq settings).
>
> Steve,
> It will be great if you can apply the attached in your system and send your
> findings.
>
> Regards,
> Max,
So the conlusion to this thread is that Leon's mlx5 patch needs to wait
until this block-mq patch is accepted?
Thanks,
Jason
^ permalink raw reply
* Re: [PATCH mlx5-next] RDMA/mlx5: Don't use cached IRQ affinity mask
From: Max Gurtovoy @ 2018-07-23 16:53 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Steve Wise, 'Sagi Grimberg', 'Leon Romanovsky',
'Doug Ledford', 'RDMA mailing list',
'Saeed Mahameed', 'linux-netdev'
In-Reply-To: <20180723164910.GS31540@mellanox.com>
On 7/23/2018 7:49 PM, Jason Gunthorpe wrote:
> On Fri, Jul 20, 2018 at 04:25:32AM +0300, Max Gurtovoy wrote:
>>
>>>>> [ 2032.194376] nvme nvme0: failed to connect queue: 9 ret=-18
>>>>
>>>> queue 9 is not mapped (overlap).
>>>> please try the bellow:
>>>>
>>>
>>> This seems to work. Here are three mapping cases: each vector on its
>>> own cpu, each vector on 1 cpu within the local numa node, and each
>>> vector having all cpus in its numa node. The 2nd mapping looks kinda
>>> funny, but I think it achieved what you wanted? And all the cases
>>> resulted in successful connections.
>>>
>>
>> Thanks for testing this.
>> I slightly improved the setting of the left CPUs and actually used Sagi's
>> initial proposal.
>>
>> Sagi,
>> please review the attached patch and let me know if I should add your
>> signature on it.
>> I'll run some perf test early next week on it (meanwhile I run login/logout
>> with different num_queues successfully and irq settings).
>>
>> Steve,
>> It will be great if you can apply the attached in your system and send your
>> findings.
>>
>> Regards,
>> Max,
>
> So the conlusion to this thread is that Leon's mlx5 patch needs to wait
> until this block-mq patch is accepted?
Yes, since nvmf is the only user of this function.
Still waiting for comments on the suggested patch :)
>
> Thanks,
> Jason
>
^ permalink raw reply
* Re: [PATCH v4 net-next 1/3] rds: Changing IP address internal representation to struct in6_addr
From: Santosh Shilimkar @ 2018-07-23 16:54 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <fb4069712ff1eca2988a002defa5d1b917f6853b.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> This patch changes the internal representation of an IP address to use
> struct in6_addr. IPv4 address is stored as an IPv4 mapped address.
> All the functions which take an IP address as argument are also
> changed to use struct in6_addr. But RDS socket layer is not modified
> such that it still does not accept IPv6 address from an application.
> And RDS layer does not accept nor initiate IPv6 connections.
>
> v2: Fixed sparse warnings.
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Santosh Shilimkar @ 2018-07-23 16:55 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <4dc7ee44840f6166cec8847aefc2bc51e072a7ac.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> This patch enables RDS to use IPv6 addresses. For RDS/TCP, the
> listener is now an IPv6 endpoint which accepts both IPv4 and IPv6
> connection requests. RDS/RDMA/IB uses a private data (struct
> rds_ib_connect_private) exchange between endpoints at RDS connection
> establishment time to support RDMA. This private data exchange uses a
> 32 bit integer to represent an IP address. This needs to be changed in
> order to support IPv6. A new private data struct
> rds6_ib_connect_private is introduced to handle this. To ensure
> backward compatibility, an IPv6 capable RDS stack uses another RDMA
> listener port (RDS_CM_PORT) to accept IPv6 connection. And it
> continues to use the original RDS_PORT for IPv4 RDS connections. When
> it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to
> send the connection set up request.
>
> v4: Changed port history comments in rds.h (Sowmini Varadhan).
>
> v3: Added support to set up IPv4 connection using mapped address
> (David Miller).
> Added support to set up connection between link local and non-link
> addresses.
> Various review comments from Santosh Shilimkar and Sowmini Varadhan.
>
> v2: Fixed bound and peer address scope mismatched issue.
> Added back rds_connect() IPv6 changes.
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH v4 net-next 3/3] rds: Extend RDS API for IPv6 support
From: Santosh Shilimkar @ 2018-07-23 16:55 UTC (permalink / raw)
To: Ka-Cheong Poon, netdev; +Cc: davem, rds-devel, sowmini.varadhan
In-Reply-To: <98e6f366f2c9cca7ac25f535070a336d633d3d5a.1532318752.git.ka-cheong.poon@oracle.com>
On 7/23/2018 7:16 AM, Ka-Cheong Poon wrote:
> There are many data structures (RDS socket options) used by RDS apps
> which use a 32 bit integer to store IP address. To support IPv6,
> struct in6_addr needs to be used. To ensure backward compatibility, a
> new data structure is introduced for each of those data structures
> which use a 32 bit integer to represent an IP address. And new socket
> options are introduced to use those new structures. This means that
> existing apps should work without a problem with the new RDS module.
> For apps which want to use IPv6, those new data structures and socket
> options can be used. IPv4 mapped address is used to represent IPv4
> address in the new data structures.
>
> v4: Revert changes to SO_RDS_TRANSPORT
>
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> ---
Looks good to me now. Thanks !!
Acked-by: Santosh Shilimkar <sanstosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH net-next 0/5] net/smc: patches 2018-07-23
From: David Miller @ 2018-07-23 17:57 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180723115312.54694-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Mon, 23 Jul 2018 13:53:07 +0200
> here are some small patches for SMC: Just the first patch contains a
> functional change. It allows to differ between the modes SMCR and SMCD
> on s390 when monitoring SMC sockets. The remaining patches are cleanups
> without functional changes.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] wan/fsl_ucc_hdlc: use IS_ERR_VALUE() to check return value of qe_muram_alloc
From: David Miller @ 2018-07-23 18:07 UTC (permalink / raw)
To: yuehaibing; +Cc: qiang.zhao, linux-kernel, netdev, linuxppc-dev
In-Reply-To: <20180723141233.19948-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 23 Jul 2018 22:12:33 +0800
> qe_muram_alloc return a unsigned long integer,which should not
> compared with zero. check it using IS_ERR_VALUE() to fix this.
>
> Fixes: c19b6d246a35 ("drivers/net: support hdlc function for QE-UCC")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v6 3/4] net: vhost: factor out busy polling logic to vhost_net_busy_poll()
From: Tonghao Zhang @ 2018-07-23 17:31 UTC (permalink / raw)
To: toshiaki.makita1
Cc: makita.toshiaki, jasowang, mst, virtualization,
Linux Kernel Network Developers
In-Reply-To: <2b0efbf4-09e2-0ee9-091f-e2d9e10483a1@gmail.com>
On Mon, Jul 23, 2018 at 10:20 PM Toshiaki Makita
<toshiaki.makita1@gmail.com> wrote:
>
> On 18/07/23 (月) 21:43, Tonghao Zhang wrote:
> > On Mon, Jul 23, 2018 at 5:58 PM Toshiaki Makita
> > <makita.toshiaki@lab.ntt.co.jp> wrote:
> >>
> >> On 2018/07/22 3:04, xiangxia.m.yue@gmail.com wrote:
> >>> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>>
> >>> Factor out generic busy polling logic and will be
> >>> used for in tx path in the next patch. And with the patch,
> >>> qemu can set differently the busyloop_timeout for rx queue.
> >>>
> >>> Signed-off-by: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >>> ---
> >> ...
> >>> +static void vhost_net_busy_poll_vq_check(struct vhost_net *net,
> >>> + struct vhost_virtqueue *rvq,
> >>> + struct vhost_virtqueue *tvq,
> >>> + bool rx)
> >>> +{
> >>> + struct socket *sock = rvq->private_data;
> >>> +
> >>> + if (rx) {
> >>> + if (!vhost_vq_avail_empty(&net->dev, tvq)) {
> >>> + vhost_poll_queue(&tvq->poll);
> >>> + } else if (unlikely(vhost_enable_notify(&net->dev, tvq))) {
> >>> + vhost_disable_notify(&net->dev, tvq);
> >>> + vhost_poll_queue(&tvq->poll);
> >>> + }
> >>> + } else if ((sock && sk_has_rx_data(sock->sk)) &&
> >>> + !vhost_vq_avail_empty(&net->dev, rvq)) {
> >>> + vhost_poll_queue(&rvq->poll);
> >>
> >> Now we wait for vq_avail for rx as well, I think you cannot skip
> >> vhost_enable_notify() on tx. Probably you might want to do:
> > I think vhost_enable_notify is needed.
> >
> >> } else if (sock && sk_has_rx_data(sock->sk)) {
> >> if (!vhost_vq_avail_empty(&net->dev, rvq)) {
> >> vhost_poll_queue(&rvq->poll);
> >> } else if (unlikely(vhost_enable_notify(&net->dev, rvq))) {
> >> vhost_disable_notify(&net->dev, rvq);
> >> vhost_poll_queue(&rvq->poll);
> >> }
> >> }
> > As Jason review as before, we only want rx kick when packet is pending at
> > socket but we're out of available buffers. So we just enable notify,
> > but not poll it ?
> >
> > } else if ((sock && sk_has_rx_data(sock->sk)) &&
> > !vhost_vq_avail_empty(&net->dev, rvq)) {
> > vhost_poll_queue(&rvq->poll);
> > else {
> > vhost_enable_notify(&net->dev, rvq);
> > }
>
> When vhost_enable_notify() returns true the avail becomes non-empty
> while we are enabling notify. We may delay the rx process if we don't
> check the return value of vhost_enable_notify().
I got it thanks.
> >> Also it's better to care vhost_net_disable_vq()/vhost_net_enable_vq() on tx?
> > I cant find why it is better, if necessary, we can do it.
>
> The reason is pretty simple... we are busypolling the socket so we don't
> need rx wakeups during it?
OK, but one question, how about rx? do we use the
vhost_net_disable_vq/vhost_net_ensable_vq on rx ?
> --
> Toshiaki Makita
^ permalink raw reply
* [PATCH] net/9p/trans_fd.c: fix race by holding the lock
From: Tomas Bortoli @ 2018-07-23 18:42 UTC (permalink / raw)
To: ericvh, rminnich, lucho
Cc: asmadeus, davem, v9fs-developer, netdev, linux-kernel, syzkaller,
Tomas Bortoli
It may be possible to run p9_fd_cancel() with a deleted req->req_list
and incur in a double del. To fix hold the client->lock while changing
the status, so the other threads will be synchronized.
Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
Reported-by: syzbot+735d926e9d1317c3310c@syzkaller.appspotmail.com
---
net/9p/trans_fd.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 588bf88c3305..f9f96d50d96d 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -197,15 +197,14 @@ static void p9_mux_poll_stop(struct p9_conn *m)
static void p9_conn_cancel(struct p9_conn *m, int err)
{
struct p9_req_t *req, *rtmp;
- unsigned long flags;
LIST_HEAD(cancel_list);
p9_debug(P9_DEBUG_ERROR, "mux %p err %d\n", m, err);
- spin_lock_irqsave(&m->client->lock, flags);
+ spin_lock(&m->client->lock);
if (m->err) {
- spin_unlock_irqrestore(&m->client->lock, flags);
+ spin_unlock(&m->client->lock);
return;
}
@@ -217,7 +216,6 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
list_for_each_entry_safe(req, rtmp, &m->unsent_req_list, req_list) {
list_move(&req->req_list, &cancel_list);
}
- spin_unlock_irqrestore(&m->client->lock, flags);
list_for_each_entry_safe(req, rtmp, &cancel_list, req_list) {
p9_debug(P9_DEBUG_ERROR, "call back req %p\n", req);
@@ -226,6 +224,7 @@ static void p9_conn_cancel(struct p9_conn *m, int err)
req->t_err = err;
p9_client_cb(m->client, req, REQ_STATUS_ERROR);
}
+ spin_unlock(&m->client->lock);
}
static __poll_t
@@ -373,8 +372,9 @@ static void p9_read_work(struct work_struct *work)
if (m->req->status != REQ_STATUS_ERROR)
status = REQ_STATUS_RCVD;
list_del(&m->req->req_list);
- spin_unlock(&m->client->lock);
+ /* update req->status while holding client->lock */
p9_client_cb(m->client, m->req, status);
+ spin_unlock(&m->client->lock);
m->rc.sdata = NULL;
m->rc.offset = 0;
m->rc.capacity = 0;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 bpf 1/3] bpf: btf: Sync uapi btf.h to tools
From: Yonghong Song @ 2018-07-23 17:58 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721182043.1401089-2-kafai@fb.com>
On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> This patch sync the uapi btf.h to tools/
>
> Fixes: 36fc3c8c282c bpf: btf: Clean up BTF_INT_BITS() in uapi btf.h
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/include/uapi/linux/btf.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/include/uapi/linux/btf.h b/tools/include/uapi/linux/btf.h
> index 0b5ddbe135a4..972265f32871 100644
> --- a/tools/include/uapi/linux/btf.h
> +++ b/tools/include/uapi/linux/btf.h
> @@ -76,7 +76,7 @@ struct btf_type {
> */
> #define BTF_INT_ENCODING(VAL) (((VAL) & 0x0f000000) >> 24)
> #define BTF_INT_OFFSET(VAL) (((VAL & 0x00ff0000)) >> 16)
> -#define BTF_INT_BITS(VAL) ((VAL) & 0x0000ffff)
> +#define BTF_INT_BITS(VAL) ((VAL) & 0x000000ff)
>
> /* Attributes stored in the BTF_INT_ENCODING */
> #define BTF_INT_SIGNED (1 << 0)
^ permalink raw reply
* Re: pull-request: can 2018-07-23
From: David Miller @ 2018-07-23 18:02 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180723125843.391-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 23 Jul 2018 14:58:31 +0200
> this is a pull request of 12 patches for net/master.
>
> The patch by Stephane Grosjean for the peak_canfd CAN driver fixes a problem
> with older firmware. The next patch is by Roman Fietze and fixes the setup of
> the CCCR register in the m_can driver. Nicholas Mc Guire's patch for the
> mpc5xxx_can driver adds missing error checking. The two patches by Faiz Abbas
> fix the runtime resume and clean up the probe function in the m_can driver. The
> last 7 patches by Anssi Hannula fix several problem in the xilinx_can driver.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH v2 bpf 2/3] bpf: Replace [u]int32_t and [u]int64_t in libbpf
From: Yonghong Song @ 2018-07-23 18:04 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721182043.1401089-3-kafai@fb.com>
On 7/21/18 11:20 AM, Martin KaFai Lau wrote:
> This patch replaces [u]int32_t and [u]int64_t usage with
> __[su]32 and __[su]64. The same change goes for [u]int16_t
> and [u]int8_t.
>
> Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
> tools/lib/bpf/btf.c | 28 +++++++++++++---------------
> tools/lib/bpf/btf.h | 8 ++++----
> tools/lib/bpf/libbpf.c | 12 ++++++------
> tools/lib/bpf/libbpf.h | 4 ++--
> 4 files changed, 25 insertions(+), 27 deletions(-)
>
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
> index 8c54a4b6f187..ce77b5b57912 100644
> --- a/tools/lib/bpf/btf.c
> +++ b/tools/lib/bpf/btf.c
> @@ -2,7 +2,6 @@
> /* Copyright (c) 2018 Facebook */
>
> #include <stdlib.h>
> -#include <stdint.h>
> #include <string.h>
> #include <unistd.h>
> #include <errno.h>
> @@ -27,13 +26,13 @@ struct btf {
> struct btf_type **types;
> const char *strings;
> void *nohdr_data;
> - uint32_t nr_types;
> - uint32_t types_size;
> - uint32_t data_size;
> + __u32 nr_types;
> + __u32 types_size;
> + __u32 data_size;
> int fd;
> };
>
> -static const char *btf_name_by_offset(const struct btf *btf, uint32_t offset)
> +static const char *btf_name_by_offset(const struct btf *btf, __u32 offset)
> {
> if (offset < btf->hdr->str_len)
> return &btf->strings[offset];
> @@ -151,7 +150,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
>
> while (next_type < end_type) {
> struct btf_type *t = next_type;
> - uint16_t vlen = BTF_INFO_VLEN(t->info);
> + __u16 vlen = BTF_INFO_VLEN(t->info);
> int err;
>
> next_type += sizeof(*t);
> @@ -191,7 +190,7 @@ static int btf_parse_type_sec(struct btf *btf, btf_print_fn_t err_log)
> }
>
> static const struct btf_type *btf_type_by_id(const struct btf *btf,
> - uint32_t type_id)
> + __u32 type_id)
> {
> if (type_id > btf->nr_types)
> return NULL;
> @@ -226,12 +225,12 @@ static int64_t btf_type_size(const struct btf_type *t)
Missing this one:
static int64_t btf_type_size(const struct btf_type *t)
There are a couple of instances of using u32 instead of __u32, better to
use __u32 everywhere in the same file:
u32 expand_by, new_size;
u32 meta_left;
>
> #define MAX_RESOLVE_DEPTH 32
>
> -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id)
> {
> const struct btf_array *array;
> const struct btf_type *t;
> - uint32_t nelems = 1;
> - int64_t size = -1;
> + __u32 nelems = 1;
> + __s64 size = -1;
> int i;
>
> t = btf_type_by_id(btf, type_id);
> @@ -271,9 +270,9 @@ int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id)
> return nelems * size;
> }
>
> -int32_t btf__find_by_name(const struct btf *btf, const char *type_name)
> +__s32 btf__find_by_name(const struct btf *btf, const char *type_name)
> {
> - uint32_t i;
> + __u32 i;
>
> if (!strcmp(type_name, "void"))
> return 0;
> @@ -302,10 +301,9 @@ void btf__free(struct btf *btf)
> free(btf);
> }
>
> -struct btf *btf__new(uint8_t *data, uint32_t size,
> - btf_print_fn_t err_log)
> +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log)
> {
> - uint32_t log_buf_size = 0;
> + __u32 log_buf_size = 0;
> char *log_buf = NULL;
> struct btf *btf;
> int err;
> diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> index 74bb344035bb..ed3a84370ccc 100644
> --- a/tools/lib/bpf/btf.h
> +++ b/tools/lib/bpf/btf.h
> @@ -4,7 +4,7 @@
> #ifndef __BPF_BTF_H
> #define __BPF_BTF_H
>
> -#include <stdint.h>
> +#include <linux/types.h>
>
> #define BTF_ELF_SEC ".BTF"
>
> @@ -14,9 +14,9 @@ typedef int (*btf_print_fn_t)(const char *, ...)
> __attribute__((format(printf, 1, 2)));
>
> void btf__free(struct btf *btf);
> -struct btf *btf__new(uint8_t *data, uint32_t size, btf_print_fn_t err_log);
> -int32_t btf__find_by_name(const struct btf *btf, const char *type_name);
> -int64_t btf__resolve_size(const struct btf *btf, uint32_t type_id);
> +struct btf *btf__new(__u8 *data, __u32 size, btf_print_fn_t err_log);
> +__s32 btf__find_by_name(const struct btf *btf, const char *type_name);
> +__s64 btf__resolve_size(const struct btf *btf, __u32 type_id);
> int btf__fd(const struct btf *btf);
>
> #endif
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index a1e96b5de5ff..6deb4fe4fffe 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -216,8 +216,8 @@ struct bpf_map {
> size_t offset;
> int map_ifindex;
> struct bpf_map_def def;
> - uint32_t btf_key_type_id;
> - uint32_t btf_value_type_id;
> + __u32 btf_key_type_id;
> + __u32 btf_value_type_id;
> void *priv;
> bpf_map_clear_priv_t clear_priv;
> };
> @@ -1016,8 +1016,8 @@ static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> {
> struct bpf_map_def *def = &map->def;
> const size_t max_name = 256;
> - int64_t key_size, value_size;
> - int32_t key_id, value_id;
> + __s64 key_size, value_size;
> + __s32 key_id, value_id;
> char name[max_name];
>
> /* Find key type by name from BTF */
> @@ -2089,12 +2089,12 @@ const char *bpf_map__name(struct bpf_map *map)
> return map ? map->name : NULL;
> }
>
> -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map)
> +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map)
> {
> return map ? map->btf_key_type_id : 0;
> }
>
> -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map)
> +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map)
> {
> return map ? map->btf_value_type_id : 0;
> }
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index 09976531aa74..b33ae02f7d0e 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -244,8 +244,8 @@ bpf_map__next(struct bpf_map *map, struct bpf_object *obj);
> int bpf_map__fd(struct bpf_map *map);
> const struct bpf_map_def *bpf_map__def(struct bpf_map *map);
> const char *bpf_map__name(struct bpf_map *map);
> -uint32_t bpf_map__btf_key_type_id(const struct bpf_map *map);
> -uint32_t bpf_map__btf_value_type_id(const struct bpf_map *map);
> +__u32 bpf_map__btf_key_type_id(const struct bpf_map *map);
> +__u32 bpf_map__btf_value_type_id(const struct bpf_map *map);
>
> typedef void (*bpf_map_clear_priv_t)(struct bpf_map *, void *);
> int bpf_map__set_priv(struct bpf_map *map, void *priv,
>
^ permalink raw reply
* [PATCH 0/5] sh_eth: clean up the TSU register accessors
From: Sergei Shtylyov @ 2018-07-23 18:08 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
Hello!
Here's a set of 5 patches against DaveM's 'net-next.git' repo. They do a final
clean up of the TSU register accessors...
[1/1] sh_eth: uninline sh_eth_tsu_get_offset()
[2/3] sh_eth: make sh_eth_tsu_get_offset() match its name
[3/3] sh_eth: call sh_eth_tsu_get_offset() from TSU register accessors
[4/5] sh_eth: make sh_eth_tsu_write_entry() take 'offset' parameter
[5/5] sh_eth: make sh_eth_tsu_{read|write}_entry() prototypes symmetric
MBR, Sergei
^ permalink raw reply
* [PATCH 1/5] sh_eth: uninline sh_eth_tsu_get_offset()
From: Sergei Shtylyov @ 2018-07-23 18:10 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <24093fd0-1b9b-a211-f988-0272483185d6@cogentembedded.com>
sh_eth_tsu_get_offset() is called several times by the driver, remove
*inline* and move that function from the header to the driver itself
to let gcc decide whether to expand it inline or not...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 5 +++++
drivers/net/ethernet/renesas/sh_eth.h | 6 ------
2 files changed, 5 insertions(+), 6 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -439,6 +439,11 @@ static void sh_eth_modify(struct net_dev
enum_index);
}
+static void *sh_eth_tsu_get_offset(struct sh_eth_private *mdp, int enum_index)
+{
+ return mdp->tsu_addr + mdp->reg_offset[enum_index];
+}
+
static void sh_eth_tsu_write(struct sh_eth_private *mdp, u32 data,
int enum_index)
{
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -558,10 +558,4 @@ struct sh_eth_private {
unsigned wol_enabled:1;
};
-static inline void *sh_eth_tsu_get_offset(struct sh_eth_private *mdp,
- int enum_index)
-{
- return mdp->tsu_addr + mdp->reg_offset[enum_index];
-}
-
#endif /* #ifndef __SH_ETH_H__ */
^ permalink raw reply
* [PATCH 2/5] sh_eth: make sh_eth_tsu_get_offset() match its name
From: Sergei Shtylyov @ 2018-07-23 18:11 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <24093fd0-1b9b-a211-f988-0272483185d6@cogentembedded.com>
sh_eth_tsu_get_offset(), despite its name, returns a TSU register's address,
not its offset. Make this function match its name and return a register's
offset from the TSU registers base address instead.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -439,9 +439,9 @@ static void sh_eth_modify(struct net_dev
enum_index);
}
-static void *sh_eth_tsu_get_offset(struct sh_eth_private *mdp, int enum_index)
+static u16 sh_eth_tsu_get_offset(struct sh_eth_private *mdp, int enum_index)
{
- return mdp->tsu_addr + mdp->reg_offset[enum_index];
+ return mdp->reg_offset[enum_index];
}
static void sh_eth_tsu_write(struct sh_eth_private *mdp, u32 data,
@@ -2712,12 +2712,12 @@ static void sh_eth_tsu_read_entry(void *
static int sh_eth_tsu_find_entry(struct net_device *ndev, const u8 *addr)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
- void *reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
+ u16 reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
int i;
u8 c_addr[ETH_ALEN];
for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES; i++, reg_offset += 8) {
- sh_eth_tsu_read_entry(reg_offset, c_addr);
+ sh_eth_tsu_read_entry(mdp->tsu_addr + reg_offset, c_addr);
if (ether_addr_equal(addr, c_addr))
return i;
}
@@ -2739,7 +2739,7 @@ static int sh_eth_tsu_disable_cam_entry_
int entry)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
- void *reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
+ u16 reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
int ret;
u8 blank[ETH_ALEN];
@@ -2747,7 +2747,9 @@ static int sh_eth_tsu_disable_cam_entry_
~(1 << (31 - entry)), TSU_TEN);
memset(blank, 0, sizeof(blank));
- ret = sh_eth_tsu_write_entry(ndev, reg_offset + entry * 8, blank);
+ ret = sh_eth_tsu_write_entry(ndev,
+ mdp->tsu_addr + reg_offset + entry * 8,
+ blank);
if (ret < 0)
return ret;
return 0;
@@ -2756,7 +2758,7 @@ static int sh_eth_tsu_disable_cam_entry_
static int sh_eth_tsu_add_entry(struct net_device *ndev, const u8 *addr)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
- void *reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
+ u16 reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
int i, ret;
if (!mdp->cd->tsu)
@@ -2768,7 +2770,9 @@ static int sh_eth_tsu_add_entry(struct n
i = sh_eth_tsu_find_empty(ndev);
if (i < 0)
return -ENOMEM;
- ret = sh_eth_tsu_write_entry(ndev, reg_offset + i * 8, addr);
+ ret = sh_eth_tsu_write_entry(ndev,
+ mdp->tsu_addr + reg_offset + i * 8,
+ addr);
if (ret < 0)
return ret;
@@ -2830,15 +2834,15 @@ static int sh_eth_tsu_purge_all(struct n
static void sh_eth_tsu_purge_mcast(struct net_device *ndev)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
+ u16 reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
u8 addr[ETH_ALEN];
- void *reg_offset = sh_eth_tsu_get_offset(mdp, TSU_ADRH0);
int i;
if (!mdp->cd->tsu)
return;
for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES; i++, reg_offset += 8) {
- sh_eth_tsu_read_entry(reg_offset, addr);
+ sh_eth_tsu_read_entry(mdp->tsu_addr + reg_offset, addr);
if (is_multicast_ether_addr(addr))
sh_eth_tsu_del_entry(ndev, addr);
}
^ permalink raw reply
* [PATCH 3/5] sh_eth: call sh_eth_tsu_get_offset() from TSU register accessors
From: Sergei Shtylyov @ 2018-07-23 18:12 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <24093fd0-1b9b-a211-f988-0272483185d6@cogentembedded.com>
With sh_eth_tsu_get_offset() now actually returning TSU register's offset,
we can at last use it in sh_eth_tsu_{read|write}(). Somehow this saves 248
bytes of object code with AArch64 gcc 4.8.5... :-)
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -447,7 +447,7 @@ static u16 sh_eth_tsu_get_offset(struct
static void sh_eth_tsu_write(struct sh_eth_private *mdp, u32 data,
int enum_index)
{
- u16 offset = mdp->reg_offset[enum_index];
+ u16 offset = sh_eth_tsu_get_offset(mdp, enum_index);
if (WARN_ON(offset == SH_ETH_OFFSET_INVALID))
return;
@@ -457,7 +457,7 @@ static void sh_eth_tsu_write(struct sh_e
static u32 sh_eth_tsu_read(struct sh_eth_private *mdp, int enum_index)
{
- u16 offset = mdp->reg_offset[enum_index];
+ u16 offset = sh_eth_tsu_get_offset(mdp, enum_index);
if (WARN_ON(offset == SH_ETH_OFFSET_INVALID))
return ~0U;
^ permalink raw reply
* [PATCH 4/5] sh_eth: make sh_eth_tsu_write_entry() take 'offset' parameter
From: Sergei Shtylyov @ 2018-07-23 18:14 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <24093fd0-1b9b-a211-f988-0272483185d6@cogentembedded.com>
We can add the TSU register base address to a TSU register offset right
in sh_eth_tsu_write_entry(), no need to do it in its callers...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2676,18 +2676,19 @@ static int sh_eth_tsu_busy(struct net_de
return 0;
}
-static int sh_eth_tsu_write_entry(struct net_device *ndev, void *reg,
+static int sh_eth_tsu_write_entry(struct net_device *ndev, u16 offset,
const u8 *addr)
{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
u32 val;
val = addr[0] << 24 | addr[1] << 16 | addr[2] << 8 | addr[3];
- iowrite32(val, reg);
+ iowrite32(val, mdp->tsu_addr + offset);
if (sh_eth_tsu_busy(ndev) < 0)
return -EBUSY;
val = addr[4] << 8 | addr[5];
- iowrite32(val, reg + 4);
+ iowrite32(val, mdp->tsu_addr + offset + 4);
if (sh_eth_tsu_busy(ndev) < 0)
return -EBUSY;
@@ -2747,9 +2748,7 @@ static int sh_eth_tsu_disable_cam_entry_
~(1 << (31 - entry)), TSU_TEN);
memset(blank, 0, sizeof(blank));
- ret = sh_eth_tsu_write_entry(ndev,
- mdp->tsu_addr + reg_offset + entry * 8,
- blank);
+ ret = sh_eth_tsu_write_entry(ndev, reg_offset + entry * 8, blank);
if (ret < 0)
return ret;
return 0;
@@ -2770,9 +2769,7 @@ static int sh_eth_tsu_add_entry(struct n
i = sh_eth_tsu_find_empty(ndev);
if (i < 0)
return -ENOMEM;
- ret = sh_eth_tsu_write_entry(ndev,
- mdp->tsu_addr + reg_offset + i * 8,
- addr);
+ ret = sh_eth_tsu_write_entry(ndev, reg_offset + i * 8, addr);
if (ret < 0)
return ret;
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: David Miller @ 2018-07-23 18:15 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <4dc7ee44840f6166cec8847aefc2bc51e072a7ac.1532318752.git.ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Mon, 23 Jul 2018 07:16:11 -0700
> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>
> inet = inet_sk(new_sock->sk);
>
> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
> + peer_addr = &new_sock->sk->sk_v6_daddr,
> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
Note that comma, instead of a semicolon, at the end of the peer_addr
assignment.
This doesn't even compile.
^ permalink raw reply
* [PATCH 5/5] sh_eth: make sh_eth_tsu_{read|write}_entry() prototypes symmetric
From: Sergei Shtylyov @ 2018-07-23 18:15 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <24093fd0-1b9b-a211-f988-0272483185d6@cogentembedded.com>
sh_eth_tsu_read_entry() is still asymmetric with sh_eth_tsu_write_entry()
WRT their prototypes -- make them symmetric by passing to the former a TSU
register offset instead of its address and also adding the (now necessary)
'ndev' parameter...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -2695,16 +2695,17 @@ static int sh_eth_tsu_write_entry(struct
return 0;
}
-static void sh_eth_tsu_read_entry(void *reg, u8 *addr)
+static void sh_eth_tsu_read_entry(struct net_device *ndev, u16 offset, u8 *addr)
{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
u32 val;
- val = ioread32(reg);
+ val = ioread32(mdp->tsu_addr + offset);
addr[0] = (val >> 24) & 0xff;
addr[1] = (val >> 16) & 0xff;
addr[2] = (val >> 8) & 0xff;
addr[3] = val & 0xff;
- val = ioread32(reg + 4);
+ val = ioread32(mdp->tsu_addr + offset + 4);
addr[4] = (val >> 8) & 0xff;
addr[5] = val & 0xff;
}
@@ -2718,7 +2719,7 @@ static int sh_eth_tsu_find_entry(struct
u8 c_addr[ETH_ALEN];
for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES; i++, reg_offset += 8) {
- sh_eth_tsu_read_entry(mdp->tsu_addr + reg_offset, c_addr);
+ sh_eth_tsu_read_entry(ndev, reg_offset, c_addr);
if (ether_addr_equal(addr, c_addr))
return i;
}
@@ -2839,7 +2840,7 @@ static void sh_eth_tsu_purge_mcast(struc
return;
for (i = 0; i < SH_ETH_TSU_CAM_ENTRIES; i++, reg_offset += 8) {
- sh_eth_tsu_read_entry(mdp->tsu_addr + reg_offset, addr);
+ sh_eth_tsu_read_entry(ndev, reg_offset, addr);
if (is_multicast_ether_addr(addr))
sh_eth_tsu_del_entry(ndev, addr);
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox