* Re: Question about ip_defrag
From: Florian Westphal @ 2017-08-29 13:46 UTC (permalink / raw)
To: liujian (CE)
Cc: Florian Westphal, Jesper Dangaard Brouer, netdev@vger.kernel.org,
Wangkefeng (Kevin), weiyongjun (A)
In-Reply-To: <4F88C5DDA1E80143B232E89585ACE27D018F4850@DGGEMA502-MBX.china.huawei.com>
liujian (CE) <liujian56@huawei.com> wrote:
[ trimming cc list ]
> Now, I have not the real environment.
> I use iperf generate fragment packets;
> and I always change NIC rx irq's affinity cpu, to make sure frag_mem_limit reach to thresh.
> my test machine, CPU num is 384.
Oh well, that explains it.
> > > + if (frag_mem_limit(nf) > nf->low_thresh) {
> > > inet_frag_schedule_worker(f);
> > > + update_frag_mem_limit(nf, SKB_TRUESIZE(1500) * 16);
> > > + }
You need to reduce this to a lower value.
Your cpu count * batch_value needs to be less than
low_thresh to avoid problems.
Wtih 384 cpus its close to 12 mbyte...
Perhaps do this:
update_frag_mem_limit(nf, 2 * 1024*1024 / NR_CPUS);
However, I think its better to revert the percpu counter change and
move back to a single atomic_t count.
^ permalink raw reply
* Re: [PATCH net-next v2] bridge: fdb add and delete tracepoints
From: Andrew Lunn @ 2017-08-29 13:36 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: davem, netdev, nikolay, f.fainelli, bridge
In-Reply-To: <1503980568-35240-1-git-send-email-roopa@cumulusnetworks.com>
On Mon, Aug 28, 2017 at 09:22:48PM -0700, Roopa Prabhu wrote:
> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
> A few useful tracepoints to trace bridge forwarding
> database updates.
Hi Roopa
Once accepted, it would be nice to add mdb tracepoints as well. I
expect the implementation would be very similar.
Andrew
^ permalink raw reply
* RE: [RFC PATCH] net: limit maximum number of packets to mark with xmit_more
From: David Laight @ 2017-08-29 13:35 UTC (permalink / raw)
To: 'Jakub Kicinski', Jacob Keller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20170825153418.53864810@cakuba>
From: Jakub Kicinski
> Sent: 25 August 2017 20:34
>
> On Fri, 25 Aug 2017 08:24:49 -0700, Jacob Keller wrote:
> > Under some circumstances, such as with many stacked devices, it is
> > possible that dev_hard_start_xmit will bundle many packets together, and
> > mark them all with xmit_more.
>
> Excuse my ignorance but what are those stacked devices? Could they
> perhaps be fixed somehow? My intuition was that long xmit_more
> sequences can only happen if NIC and/or BQL are back pressuring, and
> therefore we shouldn't be seeing a long xmit_more "train" arriving at
> an empty device ring...
I also suspect that the packets could be coming from multiple sources.
So getting the sources to limit the number of packets with XMIT_MORE
set won't really solve any problem.
At some point the driver for the physical device will have to give it
a kick to start the transmits.
On the systems I've got (desktop x86) PCIe writes aren't really very
expensive.
Reads are a different matter entirely (2us into our fpga target).
David.
^ permalink raw reply
* Re: XDP redirect measurements, gotchas and tracepoints
From: Jesper Dangaard Brouer @ 2017-08-29 13:26 UTC (permalink / raw)
To: Alexander Duyck
Cc: Andy Gospodarek, Michael Chan, John Fastabend, Duyck, Alexander H,
pstaszewski@itcare.pl, netdev@vger.kernel.org,
xdp-newbies@vger.kernel.org, borkmann@iogearbox.net, brouer
In-Reply-To: <CAKgT0UeZ5Wn+8qY8kbBef5weORwGAXjq6Qp7jtB1bscmjY_oYw@mail.gmail.com>
On Mon, 28 Aug 2017 09:11:25 -0700 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> My advice would be to not over complicate this. My big concern with
> all this buffer recycling is what happens the first time somebody
> introduces something like mirroring? Are you going to copy the data to
> a new page which would be quite expensive or just have to introduce
> reference counts? You are going to have to deal with stuff like
> reference counts eventually so you might as well bite that bullet now.
> My advice would be to not bother with optimizing for performance right
> now and instead focus on just getting functionality. The approach we
> took in ixgbe for the transmit path should work for almost any other
> driver since all you are looking at is having to free the page
> reference which takes care of reference counting already.
This return API is not about optimizing performance right now. It is
actually about allowing us to change the underlying memory model per RX
queue for XDP.
If a RX-ring is use for both SKBs and XDP, then the refcnt model is
still enforced. Although a driver using the 1-packet-per-page model,
should be able to reuse refcnt==1 pages when returned from XDP.
If a RX-ring is _ONLY_ used for XDP, then the driver have freedom to
implement another memory model, with the return-API. We need to
experiment with the most optimal memory model. The 1-packet-per-page
model is actually not the fastest, because of PCI-e bottlenecks. With
HW support for packing descriptors and packets over the PCI-e bus, much
higher rates can be achieved. Mellanox mlx5-Lx already have the needed HW
support. And companies like NetCope also have 100G HW that does
similar tricks, and they even have a whitepaper[1][2] how they are
faster than DPDK with their NDP (Netcope Data Plane) API.
We do need the ability/flexibility to change the RX memory model, to
take advantage of this new NIC hardware.
[1] https://www.netcope.com/en/resources/improving-dpdk-performance
[2] https://www.netcope.com/en/company/press-center/press-releases/read-new-netcope-whitepaper-on-dpdk-acceleration
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Antoine Tenart @ 2017-08-29 13:12 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Antoine Tenart, davem, andrew, jason, sebastian.hesselbarth,
gregory.clement, thomas.petazzoni, nadavh, linux, linux-kernel,
mw, stefanc, miquel.raynal, netdev
In-Reply-To: <d1d5212d-aa39-0b49-afb8-cc45d57717c0@ti.com>
[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]
Hi Kishon,
On Tue, Aug 29, 2017 at 05:55:06PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
> > On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
> >> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> >>> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> >>> + /* lane 0 */
> >>> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> >>> + /* lane 1 */
> >>> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> >>> + /* lane 2 */
> >>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> >>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> >>> + /* lane 3 */
> >>> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> >>> + /* lane 4 */
> >>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> >>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> >>> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> >>> + /* lane 5 */
> >>> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> >>> +};
> >>
> >> IMHO all the lane and mode configuration should come from dt. That would make
> >> it more reusable when comphy is configured differently.
> >
> > These connexions between engines and the comphy lanes are inside the
> > SoC. They won't change for a given SoC, and the actual configuration is
> > at the board level to know what is connected to the output of a given
> > lane, which is already described into the dt (the lane phandle).
> >
> > So I think we can keep this inside the driver, and we'll had other
> > tables if the same comphy is ever used in another SoC.
> >
> > What do you think?
>
> I'd like to avoid adding tables for every SoC. These are configuration details
> and can come from dt.
Actually this is per CP design, not SoC (this one is used in both 7k and
8k SoCs from Marvell, and probably others). I'm still not convinced this
is a good idea to put this into the dt. First of all we would end up with
something like (and this is only for a single lane, out of *6*):
cpm_comphy: phy@phy@120000 {
compatible = "marvell,comphy-cp110";
reg = <0x120000 0x6000>;
marvell,system-controller = <&cpm_syscon0>;
#address-cells = <1>;
#size-cells = <0>;
cpm_comphy0: phy@0 {
reg = <0>;
#phy-cells = <1>;
mode@0 {
phy-mode = PHY_MODE_SGMII;
selector = <0x1>;
pipe-selector = <0x0>;
port = <0>;
};
mode@1 {
phy-mode = PHY_MODE_HS_SGMII;
selector = <0x1>;
pipe-selector = <0x0>;
port = <0>;
};
mode@2 {
phy-mode = PHY_MODE_RXAUI;
selector = <0x2>;
pipe-selector = <0x0>;
port = <0>;
};
mode@3 {
phy-mode = PHY_MODE_10GKR;
selector = <0x2>;
pipe-selector = <0x0>;
port = <0>;
};
mode@4 {
phy-mode = PHY_MODE_SATA;
selector = <0x4>;
pipe-selector = <0x0>;
port = <1>;
};
mode@5 {
phy-mode = PHY_MODE_USB;
selector = <0x0>;
pipe-selector = <0x1>;
port = <2>;
};
mode@6 {
phy-mode = PHY_MODE_USB;
selector = <0x0>;
pipe-selector = <0x2>;
port = <0>;
};
... + PCIe, other ports ...
};
cpm_comphy1: phy@1 {
...
};
...
};
And this "configuration" makes us think the comphy driver would be
somehow generic with only these parameters to update when using a
different CP. In reality we do have one other comphy in another CP, and
it requires more than just updating the above parameters: the init
functions also are SoC specific. So the table used in the patch proposed
only is a small part of this "configuration". In fact it's not a
configuration at all, but only a mode-to-bit indirection, used in the
comphy init functions.
What is proposed instead, is very close to what actually changes a lot,
and what a designer can change: the CP internals are described in the
driver as these won't change (and if they do in a future CP design, a
lot more effort would be needed than just updating the table), and the
actual lane connexions on the board are configured through the dt, which
is board specific.
Finally we do not have (yet) any example of this IP being reused as-is.
So we have no idea what other changes than the ones described above will
be needed. But for sure not only the mode and lane configurations.
Thanks,
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH ] net: frag: print frag_mem_limit value in sockstat proc file
From: liujian56 @ 2017-08-29 13:05 UTC (permalink / raw)
To: davem; +Cc: kuznet, yoshfuji, brouer, fw, netdev, liujian56
From: liujian <liujian56@huawei.com>
>From 6d7b857d5( net: use lib/percpu_counter API for fragmentation mem
accounting),
frag_mem_limit and sum_frag_mem_limit have different value if there are
multiple NIC RX CPU.
Print frag_mem_limit value, then we can get more debug info.
Signed-off-by: liujian <liujian56@huawei.com>
---
net/ipv4/proc.c | 3 ++-
net/ipv6/proc.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 43eb6567..370cda1 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -73,7 +73,8 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, "RAW: inuse %d\n",
sock_prot_inuse_get(net, &raw_prot));
frag_mem = ip_frag_mem(net);
- seq_printf(seq, "FRAG: inuse %u memory %u\n", !!frag_mem, frag_mem);
+ seq_printf(seq, "FRAG: inuse %u memory %u current mem_limit %d\n",
+ !!frag_mem, frag_mem, frag_mem_limit(&net->ipv4.frags));
return 0;
}
diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index e88bcb8..00680bc 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -48,7 +48,8 @@ static int sockstat6_seq_show(struct seq_file *seq, void *v)
sock_prot_inuse_get(net, &udplitev6_prot));
seq_printf(seq, "RAW6: inuse %d\n",
sock_prot_inuse_get(net, &rawv6_prot));
- seq_printf(seq, "FRAG6: inuse %u memory %u\n", !!frag_mem, frag_mem);
+ seq_printf(seq, "FRAG6: inuse %u memory %u current mem_limit %d\n",
+ !!frag_mem, frag_mem, frag_mem_limit(&net->ipv6.frags));
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* RE: Question about ip_defrag
From: liujian (CE) @ 2017-08-29 13:01 UTC (permalink / raw)
To: liujian (CE), Florian Westphal
Cc: Jesper Dangaard Brouer, davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, elena.reshetova@intel.com,
edumazet@google.com, netdev@vger.kernel.org, Wangkefeng (Kevin),
weiyongjun (A)
In-Reply-To: <20170828140032.GB12926@breakpoint.cc>
Best Regards,
liujian
> -----Original Message-----
> From: liujian (CE)
> Sent: Tuesday, August 29, 2017 3:39 PM
> To: 'Florian Westphal'
> Cc: Jesper Dangaard Brouer; davem@davemloft.net; kuznet@ms2.inr.ac.ru;
> yoshfuji@linux-ipv6.org; elena.reshetova@intel.com; edumazet@google.com;
> netdev@vger.kernel.org; Wangkefeng (Kevin); weiyongjun (A)
> Subject: RE: Question about ip_defrag
>
>
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org
> > [mailto:netdev-owner@vger.kernel.org]
> > On Behalf Of Florian Westphal
> > Sent: Monday, August 28, 2017 10:01 PM
> > To: liujian (CE)
> > Cc: Jesper Dangaard Brouer; davem@davemloft.net; kuznet@ms2.inr.ac.ru;
> > yoshfuji@linux-ipv6.org; elena.reshetova@intel.com;
> > edumazet@google.com; netdev@vger.kernel.org; Wangkefeng (Kevin);
> > weiyongjun (A)
> > Subject: Re: Question about ip_defrag
> >
> > liujian (CE) <liujian56@huawei.com> wrote:
> > > Hi
> > >
> > > I checked our 3.10 kernel, we had backported all percpu_counter bug
> > > fix in
> > lib/percpu_counter.c and include/linux/percpu_counter.h.
> > > And I check 4.13-rc6, also has the issue if NIC's rx cpu num big enough.
> > >
> > > > > > > the issue:
> > > > > > > Ip_defrag fail caused by frag_mem_limit reached
> > 4M(frags.high_thresh).
> > > > > > > At this moment,sum_frag_mem_limit is about 10K.
> > >
> > > So should we change ipfrag high/low thresh to a reasonable value ?
> > > And if it is, is there a standard to change the value?
> >
> > Each cpu can have frag_percpu_counter_batch bytes rest doesn't know
> > about so with 64 cpus that is ~8 mbyte.
> >
> > possible solutions:
> > 1. reduce frag_percpu_counter_batch to 16k or so 2. make both low and
> > high thresh depend on NR_CPUS
> >
> Thank you for your reply.
>
> > liujian, does this change help in any way?
>
> I will have a try.
Now, I have not the real environment.
I use iperf generate fragment packets;
and I always change NIC rx irq's affinity cpu, to make sure frag_mem_limit reach to thresh.
my test machine, CPU num is 384.
As above , test the patch , seemingly , there is no improving...
Check /proc/net/snmp, there is no significant difference.
maybe we should find a good test method!
root@RH8100-V3:/proc/net# cat sockstat
sockets: used 1386
TCP: inuse 3 orphan 0 tw 0 alloc 4 mem 1
UDP: inuse 44 mem 42
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 1 memory 34336, 3144424.
> > diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> > --- a/net/ipv4/inet_fragment.c
> > +++ b/net/ipv4/inet_fragment.c
> > @@ -123,6 +123,17 @@ static bool inet_fragq_should_evict(const struct
> > inet_frag_queue *q)
> > frag_mem_limit(q->net) >= q->net->low_thresh; }
> >
> > +/* ->mem batch size is huge, this can cause severe discrepancies
> > + * between actual value (sum of pcpu values) and the global estimate.
> > + *
> > + * Use a smaller batch to give an opportunity for the global estimate
> > + * to more accurately reflect current state.
> > + */
> > +static void update_frag_mem_limit(struct netns_frags *nf, unsigned
> > +int
> > +batch) {
> > + percpu_counter_add_batch(&nf->mem, 0, batch); }
> > +
> > static unsigned int
> > inet_evict_bucket(struct inet_frags *f, struct inet_frag_bucket *hb)
> > { @@
> > -146,8 +157,12 @@ inet_evict_bucket(struct inet_frags *f, struct
> > inet_frag_bucket *hb)
> >
> > spin_unlock(&hb->chain_lock);
> >
> > - hlist_for_each_entry_safe(fq, n, &expired, list_evictor)
> > + hlist_for_each_entry_safe(fq, n, &expired, list_evictor) {
> > + struct netns_frags *nf = fq->net;
> > +
> > f->frag_expire((unsigned long) fq);
> > + update_frag_mem_limit(nf, 1);
>
> > + }
> >
> > return evicted;
> > }
> > @@ -396,8 +411,10 @@ struct inet_frag_queue *inet_frag_find(struct
> > netns_frags *nf,
> > struct inet_frag_queue *q;
> > int depth = 0;
> >
> > - if (frag_mem_limit(nf) > nf->low_thresh)
> > + if (frag_mem_limit(nf) > nf->low_thresh) {
> > inet_frag_schedule_worker(f);
> > + update_frag_mem_limit(nf, SKB_TRUESIZE(1500) * 16);
> > + }
> >
> > hash &= (INETFRAGS_HASHSZ - 1);
> > hb = &f->hash[hash];
> > @@ -416,6 +433,8 @@ struct inet_frag_queue *inet_frag_find(struct
> > netns_frags *nf,
> > if (depth <= INETFRAGS_MAXDEPTH)
> > return inet_frag_create(nf, f, key);
> >
> > + update_frag_mem_limit(nf, 1);
> > +
> > if (inet_frag_may_rebuild(f)) {
> > if (!f->rebuild)
> > f->rebuild = true;
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] net: dsa: add generic debugfs interface
From: Andrew Lunn @ 2017-08-29 12:50 UTC (permalink / raw)
To: Jiri Pirko
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Florian Fainelli, Egil Hjelmeland, John Crispin, Woojung Huh,
Sean Wang, Nikita Yushchenko, Chris Healy, mlxsw
In-Reply-To: <20170829062523.GA1977@nanopsycho.orion>
On Tue, Aug 29, 2017 at 08:25:23AM +0200, Jiri Pirko wrote:
> Mon, Aug 28, 2017 at 10:08:34PM CEST, andrew@lunn.ch wrote:
> >> I see this overlaps a lot with DPIPE. Why won't you use that to expose
> >> your hw state?
> >
> >We took a look at dpipe and i talked to you about using it for this
> >sort of thing at netconf/netdev. But dpipe has issues displaying the
> >sort of information we have. I never figured out how to do two
> >dimensional tables. The output of the dpipe command is pretty
> >unreadable. A lot of the information being dumped here is not about
> >the data pipe, etc.
>
> So improve it. No problem. Also, we extend it to support what you neede.
Will i did try to do this back in March. And i failed.
Lets start with stats. Vivien gives an example on the cover letter:
# pr -mt switch0/port{5,6}/stats
in_good_octets : 0 in_good_octets : 13824
in_bad_octets : 0 in_bad_octets : 0
in_unicast : 0 in_unicast : 0
in_broadcasts : 0 in_broadcasts : 216
in_multicasts : 0 in_multicasts : 0
in_pause : 0 in_pause : 0
in_undersize : 0 in_undersize : 0
This is what i tried to implement using dpipe. It is a simple two
dimensional table. First column is a string, second a u64. In debugfs
we have such a table per port. That fits with the hierarchy that each
port is a directory in debugfs. But it could also be implemented as
one table with N+1 columns, for N switch ports.
How about you, or one of your team, implement that. It should be able
to use the dsa_loop driver, which is a simple dummy switch. But it
does have statistics counters for all ports. Florian or I can help you
get it running if needed.
This branch contains some of the basic plumbing code from my previous
attempt:
https://github.com/lunn/linux.git v4.11-rc4-net-next-dpipe
Andrew
^ permalink raw reply
* Attention Dear Friend,
From: Mr.Robert Koffi @ 2017-08-29 12:39 UTC (permalink / raw)
Attention Dear Friend,
Compliment of the day to you, I sent you a mail a couple of day ago
about a transaction and haven't heard from you since then.The message
was to solicit your partnership to transfer the sum of ($14 million
US dollars) deposited by my late client how have the same last name
with you from the same country.I shall send you more information and
procedures when I receive a positive response from you.
I look forward to hearing from you.
Yours sincerely,
Mr Robert Koffi
^ permalink raw reply
* Re: [PATCH net] ipv6: do not set sk_destruct in IPV6_ADDRFORM sockopt
From: Paolo Abeni @ 2017-08-29 12:33 UTC (permalink / raw)
To: Xin Long, network dev; +Cc: davem, chunwang, syzkaller
In-Reply-To: <4cfe77b4a829c0d6134b842fe2ea7c41b6b210ff.1503888301.git.lucien.xin@gmail.com>
On Mon, 2017-08-28 at 10:45 +0800, Xin Long wrote:
> ChunYu found a kernel warn_on during syzkaller fuzzing:
>
> [40226.038539] WARNING: CPU: 5 PID: 23720 at net/ipv4/af_inet.c:152 inet_sock_destruct+0x78d/0x9a0
> [40226.144849] Call Trace:
> [40226.147590] <IRQ>
> [40226.149859] dump_stack+0xe2/0x186
> [40226.176546] __warn+0x1a4/0x1e0
> [40226.180066] warn_slowpath_null+0x31/0x40
> [40226.184555] inet_sock_destruct+0x78d/0x9a0
> [40226.246355] __sk_destruct+0xfa/0x8c0
> [40226.290612] rcu_process_callbacks+0xaa0/0x18a0
> [40226.336816] __do_softirq+0x241/0x75e
> [40226.367758] irq_exit+0x1f6/0x220
> [40226.371458] smp_apic_timer_interrupt+0x7b/0xa0
> [40226.376507] apic_timer_interrupt+0x93/0xa0
>
> The warn_on happned when sk->sk_rmem_alloc wasn't 0 in inet_sock_destruct.
> As after commit f970bd9e3a06 ("udp: implement memory accounting helpers"),
> udp has changed to use udp_destruct_sock as sk_destruct where it would
> udp_rmem_release all rmem.
>
> But IPV6_ADDRFORM sockopt sets sk_destruct with inet_sock_destruct after
> changing family to PF_INET. If rmem is not 0 at that time, and there is
> no place to release rmem before calling inet_sock_destruct, the warn_on
> will be triggered.
>
> This patch is to fix it by not setting sk_destruct in IPV6_ADDRFORM sockopt
> any more. As IPV6_ADDRFORM sockopt only works for tcp and udp. TCP sock has
> already set it's sk_destruct with inet_sock_destruct and UDP has set with
> udp_destruct_sock since they're created.
>
> Fixes: f970bd9e3a06 ("udp: implement memory accounting helpers")
> Reported-by: ChunYu Wang <chunwang@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> net/ipv6/ipv6_sockglue.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 02d795f..a5e466d 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -242,7 +242,6 @@ static int do_ipv6_setsockopt(struct sock *sk, int level, int optname,
> pktopt = xchg(&np->pktoptions, NULL);
> kfree_skb(pktopt);
>
> - sk->sk_destruct = inet_sock_destruct;
> /*
> * ... and add it to the refcnt debug socks count
> * in the new family. -acme
That assignment looks like a relic from ancient past... the patch LGTM,
Thanks Xin to fix this.
Acked-by: Paolo Abeni <pabeni@redhat.com>
^ permalink raw reply
* [PATCH net-next 7/7] rxrpc: Allow failed client calls to be retried
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Allow a client call that failed on network error to be retried, provided
that the Tx queue still holds DATA packet 1. This allows an operation to
be submitted to another server or another address for the same server
without having to repackage and re-encrypt the data so far processed.
Two new functions are provided:
(1) rxrpc_kernel_check_call() - This is used to find out the completion
state of a call to guess whether it can be retried and whether it
should be retried.
(2) rxrpc_kernel_retry_call() - Disconnect the call from its current
connection, reset the state and submit it as a new client call to a
new address. The new address need not match the previous address.
A call may be retried even if all the data hasn't been loaded into it yet;
a partially constructed will be retained at the same point it was at when
an error condition was detected. msg_data_left() can be used to find out
how much data was packaged before the error occurred.
Signed-off-by: David Howells <dhowells@redhat.com>
---
Documentation/networking/rxrpc.txt | 45 ++++++++++++++++
include/net/af_rxrpc.h | 16 ++++++
net/rxrpc/af_rxrpc.c | 69 ++++++++++++++++++++++++
net/rxrpc/ar-internal.h | 19 ++-----
net/rxrpc/call_object.c | 102 ++++++++++++++++++++++++++++++++++--
net/rxrpc/conn_client.c | 17 +++++-
net/rxrpc/sendmsg.c | 24 +++++---
7 files changed, 261 insertions(+), 31 deletions(-)
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 92a3c3bd5ac3..810620153a44 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -975,6 +975,51 @@ The kernel interface functions are as follows:
size should be set when the call is begun. tx_total_len may not be less
than zero.
+ (*) Check to see the completion state of a call so that the caller can assess
+ whether it needs to be retried.
+
+ enum rxrpc_call_completion {
+ RXRPC_CALL_SUCCEEDED,
+ RXRPC_CALL_REMOTELY_ABORTED,
+ RXRPC_CALL_LOCALLY_ABORTED,
+ RXRPC_CALL_LOCAL_ERROR,
+ RXRPC_CALL_NETWORK_ERROR,
+ };
+
+ int rxrpc_kernel_check_call(struct socket *sock, struct rxrpc_call *call,
+ enum rxrpc_call_completion *_compl,
+ u32 *_abort_code);
+
+ On return, -EINPROGRESS will be returned if the call is still ongoing; if
+ it is finished, *_compl will be set to indicate the manner of completion,
+ *_abort_code will be set to any abort code that occurred. 0 will be
+ returned on a successful completion, -ECONNABORTED will be returned if the
+ client failed due to a remote abort and anything else will return an
+ appropriate error code.
+
+ The caller should look at this information to decide if it's worth
+ retrying the call.
+
+ (*) Retry a client call.
+
+ int rxrpc_kernel_retry_call(struct socket *sock,
+ struct rxrpc_call *call,
+ struct sockaddr_rxrpc *srx,
+ struct key *key);
+
+ This attempts to partially reinitialise a call and submit it again whilst
+ reusing the original call's Tx queue to avoid the need to repackage and
+ re-encrypt the data to be sent. call indicates the call to retry, srx the
+ new address to send it to and key the encryption key to use for signing or
+ encrypting the packets.
+
+ For this to work, the first Tx data packet must still be in the transmit
+ queue, and currently this is only permitted for local and network errors
+ and the call must not have been aborted. Any partially constructed Tx
+ packet is left as is and can continue being filled afterwards.
+
+ It returns 0 if the call was requeued and an error otherwise.
+
=======================
CONFIGURABLE PARAMETERS
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index 07a47ee6f783..3ac79150291f 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -19,6 +19,18 @@ struct sock;
struct socket;
struct rxrpc_call;
+/*
+ * Call completion condition (state == RXRPC_CALL_COMPLETE).
+ */
+enum rxrpc_call_completion {
+ RXRPC_CALL_SUCCEEDED, /* - Normal termination */
+ RXRPC_CALL_REMOTELY_ABORTED, /* - call aborted by peer */
+ RXRPC_CALL_LOCALLY_ABORTED, /* - call aborted locally on error or close */
+ RXRPC_CALL_LOCAL_ERROR, /* - call failed due to local error */
+ RXRPC_CALL_NETWORK_ERROR, /* - call terminated by network error */
+ NR__RXRPC_CALL_COMPLETIONS
+};
+
typedef void (*rxrpc_notify_rx_t)(struct sock *, struct rxrpc_call *,
unsigned long);
typedef void (*rxrpc_notify_end_tx_t)(struct sock *, struct rxrpc_call *,
@@ -51,5 +63,9 @@ void rxrpc_kernel_get_peer(struct socket *, struct rxrpc_call *,
int rxrpc_kernel_charge_accept(struct socket *, rxrpc_notify_rx_t,
rxrpc_user_attach_call_t, unsigned long, gfp_t);
void rxrpc_kernel_set_tx_length(struct socket *, struct rxrpc_call *, s64);
+int rxrpc_kernel_retry_call(struct socket *, struct rxrpc_call *,
+ struct sockaddr_rxrpc *, struct key *);
+int rxrpc_kernel_check_call(struct socket *, struct rxrpc_call *,
+ enum rxrpc_call_completion *, u32 *);
#endif /* _NET_RXRPC_H */
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 31e97f714ca9..fb17552fd292 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -337,6 +337,75 @@ void rxrpc_kernel_end_call(struct socket *sock, struct rxrpc_call *call)
EXPORT_SYMBOL(rxrpc_kernel_end_call);
/**
+ * rxrpc_kernel_check_call - Check a call's state
+ * @sock: The socket the call is on
+ * @call: The call to check
+ * @_compl: Where to store the completion state
+ * @_abort_code: Where to store any abort code
+ *
+ * Allow a kernel service to query the state of a call and find out the manner
+ * of its termination if it has completed. Returns -EINPROGRESS if the call is
+ * still going, 0 if the call finished successfully, -ECONNABORTED if the call
+ * was aborted and an appropriate error if the call failed in some other way.
+ */
+int rxrpc_kernel_check_call(struct socket *sock, struct rxrpc_call *call,
+ enum rxrpc_call_completion *_compl, u32 *_abort_code)
+{
+ if (call->state != RXRPC_CALL_COMPLETE)
+ return -EINPROGRESS;
+ smp_rmb();
+ *_compl = call->completion;
+ *_abort_code = call->abort_code;
+ return call->error;
+}
+EXPORT_SYMBOL(rxrpc_kernel_check_call);
+
+/**
+ * rxrpc_kernel_retry_call - Allow a kernel service to retry a call
+ * @sock: The socket the call is on
+ * @call: The call to retry
+ * @srx: The address of the peer to contact
+ * @key: The security context to use (defaults to socket setting)
+ *
+ * Allow a kernel service to try resending a client call that failed due to a
+ * network error to a new address. The Tx queue is maintained intact, thereby
+ * relieving the need to re-encrypt any request data that has already been
+ * buffered.
+ */
+int rxrpc_kernel_retry_call(struct socket *sock, struct rxrpc_call *call,
+ struct sockaddr_rxrpc *srx, struct key *key)
+{
+ struct rxrpc_conn_parameters cp;
+ struct rxrpc_sock *rx = rxrpc_sk(sock->sk);
+ int ret;
+
+ _enter("%d{%d}", call->debug_id, atomic_read(&call->usage));
+
+ if (!key)
+ key = rx->key;
+ if (key && !key->payload.data[0])
+ key = NULL; /* a no-security key */
+
+ memset(&cp, 0, sizeof(cp));
+ cp.local = rx->local;
+ cp.key = key;
+ cp.security_level = 0;
+ cp.exclusive = false;
+ cp.service_id = srx->srx_service;
+
+ mutex_lock(&call->user_mutex);
+
+ ret = rxrpc_prepare_call_for_retry(rx, call);
+ if (ret == 0)
+ ret = rxrpc_retry_client_call(rx, call, &cp, srx, GFP_KERNEL);
+
+ mutex_unlock(&call->user_mutex);
+ _leave(" = %d", ret);
+ return ret;
+}
+EXPORT_SYMBOL(rxrpc_kernel_retry_call);
+
+/**
* rxrpc_kernel_new_call_notification - Get notifications of new calls
* @sock: The socket to intercept received messages on
* @notify_new_call: Function to be called when new calls appear
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 227e24794055..ea5600b747cc 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -445,6 +445,7 @@ enum rxrpc_call_flag {
RXRPC_CALL_EXPOSED, /* The call was exposed to the world */
RXRPC_CALL_RX_LAST, /* Received the last packet (at rxtx_top) */
RXRPC_CALL_TX_LAST, /* Last packet in Tx buffer (at rxtx_top) */
+ RXRPC_CALL_TX_LASTQ, /* Last packet has been queued */
RXRPC_CALL_SEND_PING, /* A ping will need to be sent */
RXRPC_CALL_PINGING, /* Ping in process */
RXRPC_CALL_RETRANS_TIMEOUT, /* Retransmission due to timeout occurred */
@@ -482,18 +483,6 @@ enum rxrpc_call_state {
};
/*
- * Call completion condition (state == RXRPC_CALL_COMPLETE).
- */
-enum rxrpc_call_completion {
- RXRPC_CALL_SUCCEEDED, /* - Normal termination */
- RXRPC_CALL_REMOTELY_ABORTED, /* - call aborted by peer */
- RXRPC_CALL_LOCALLY_ABORTED, /* - call aborted locally on error or close */
- RXRPC_CALL_LOCAL_ERROR, /* - call failed due to local error */
- RXRPC_CALL_NETWORK_ERROR, /* - call terminated by network error */
- NR__RXRPC_CALL_COMPLETIONS
-};
-
-/*
* Call Tx congestion management modes.
*/
enum rxrpc_congest_mode {
@@ -687,9 +676,15 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *,
struct rxrpc_conn_parameters *,
struct sockaddr_rxrpc *,
unsigned long, s64, gfp_t);
+int rxrpc_retry_client_call(struct rxrpc_sock *,
+ struct rxrpc_call *,
+ struct rxrpc_conn_parameters *,
+ struct sockaddr_rxrpc *,
+ gfp_t);
void rxrpc_incoming_call(struct rxrpc_sock *, struct rxrpc_call *,
struct sk_buff *);
void rxrpc_release_call(struct rxrpc_sock *, struct rxrpc_call *);
+int rxrpc_prepare_call_for_retry(struct rxrpc_sock *, struct rxrpc_call *);
void rxrpc_release_calls_on_socket(struct rxrpc_sock *);
bool __rxrpc_queue_call(struct rxrpc_call *);
bool rxrpc_queue_call(struct rxrpc_call *);
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index d7809a0620b4..fcdd6555a820 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -269,11 +269,6 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
trace_rxrpc_call(call, rxrpc_call_connected, atomic_read(&call->usage),
here, NULL);
- spin_lock_bh(&call->conn->params.peer->lock);
- hlist_add_head(&call->error_link,
- &call->conn->params.peer->error_targets);
- spin_unlock_bh(&call->conn->params.peer->lock);
-
rxrpc_start_call_timer(call);
_net("CALL new %d on CONN %d", call->debug_id, call->conn->debug_id);
@@ -304,6 +299,48 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
}
/*
+ * Retry a call to a new address. It is expected that the Tx queue of the call
+ * will contain data previously packaged for an old call.
+ */
+int rxrpc_retry_client_call(struct rxrpc_sock *rx,
+ struct rxrpc_call *call,
+ struct rxrpc_conn_parameters *cp,
+ struct sockaddr_rxrpc *srx,
+ gfp_t gfp)
+{
+ const void *here = __builtin_return_address(0);
+ int ret;
+
+ /* Set up or get a connection record and set the protocol parameters,
+ * including channel number and call ID.
+ */
+ ret = rxrpc_connect_call(call, cp, srx, gfp);
+ if (ret < 0)
+ goto error;
+
+ trace_rxrpc_call(call, rxrpc_call_connected, atomic_read(&call->usage),
+ here, NULL);
+
+ rxrpc_start_call_timer(call);
+
+ _net("CALL new %d on CONN %d", call->debug_id, call->conn->debug_id);
+
+ if (!test_and_set_bit(RXRPC_CALL_EV_RESEND, &call->events))
+ rxrpc_queue_call(call);
+
+ _leave(" = 0");
+ return 0;
+
+error:
+ rxrpc_set_call_completion(call, RXRPC_CALL_LOCAL_ERROR,
+ RX_CALL_DEAD, ret);
+ trace_rxrpc_call(call, rxrpc_call_error, atomic_read(&call->usage),
+ here, ERR_PTR(ret));
+ _leave(" = %d", ret);
+ return ret;
+}
+
+/*
* Set up an incoming call. call->conn points to the connection.
* This is called in BH context and isn't allowed to fail.
*/
@@ -471,6 +508,61 @@ void rxrpc_release_call(struct rxrpc_sock *rx, struct rxrpc_call *call)
}
/*
+ * Prepare a kernel service call for retry.
+ */
+int rxrpc_prepare_call_for_retry(struct rxrpc_sock *rx, struct rxrpc_call *call)
+{
+ const void *here = __builtin_return_address(0);
+ int i;
+ u8 last = 0;
+
+ _enter("{%d,%d}", call->debug_id, atomic_read(&call->usage));
+
+ trace_rxrpc_call(call, rxrpc_call_release, atomic_read(&call->usage),
+ here, (const void *)call->flags);
+
+ ASSERTCMP(call->state, ==, RXRPC_CALL_COMPLETE);
+ ASSERTCMP(call->completion, !=, RXRPC_CALL_REMOTELY_ABORTED);
+ ASSERTCMP(call->completion, !=, RXRPC_CALL_LOCALLY_ABORTED);
+ ASSERT(list_empty(&call->recvmsg_link));
+
+ del_timer_sync(&call->timer);
+
+ _debug("RELEASE CALL %p (%d CONN %p)", call, call->debug_id, call->conn);
+
+ if (call->conn)
+ rxrpc_disconnect_call(call);
+
+ if (rxrpc_is_service_call(call) ||
+ !call->tx_phase ||
+ call->tx_hard_ack != 0 ||
+ call->rx_hard_ack != 0 ||
+ call->rx_top != 0)
+ return -EINVAL;
+
+ call->state = RXRPC_CALL_UNINITIALISED;
+ call->completion = RXRPC_CALL_SUCCEEDED;
+ call->call_id = 0;
+ call->cid = 0;
+ call->cong_cwnd = 0;
+ call->cong_extra = 0;
+ call->cong_ssthresh = 0;
+ call->cong_mode = 0;
+ call->cong_dup_acks = 0;
+ call->cong_cumul_acks = 0;
+ call->acks_lowest_nak = 0;
+
+ for (i = 0; i < RXRPC_RXTX_BUFF_SIZE; i++) {
+ last |= call->rxtx_annotations[i];
+ call->rxtx_annotations[i] &= RXRPC_TX_ANNO_LAST;
+ call->rxtx_annotations[i] |= RXRPC_TX_ANNO_RETRANS;
+ }
+
+ _leave(" = 0");
+ return 0;
+}
+
+/*
* release all the calls associated with a socket
*/
void rxrpc_release_calls_on_socket(struct rxrpc_sock *rx)
diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
index eb2157680399..5f9624bd311c 100644
--- a/net/rxrpc/conn_client.c
+++ b/net/rxrpc/conn_client.c
@@ -555,7 +555,10 @@ static void rxrpc_activate_one_channel(struct rxrpc_connection *conn,
trace_rxrpc_client(conn, channel, rxrpc_client_chan_activate);
write_lock_bh(&call->state_lock);
- call->state = RXRPC_CALL_CLIENT_SEND_REQUEST;
+ if (!test_bit(RXRPC_CALL_TX_LASTQ, &call->flags))
+ call->state = RXRPC_CALL_CLIENT_SEND_REQUEST;
+ else
+ call->state = RXRPC_CALL_CLIENT_AWAIT_REPLY;
write_unlock_bh(&call->state_lock);
rxrpc_see_call(call);
@@ -688,15 +691,23 @@ int rxrpc_connect_call(struct rxrpc_call *call,
ret = rxrpc_get_client_conn(call, cp, srx, gfp);
if (ret < 0)
- return ret;
+ goto out;
rxrpc_animate_client_conn(rxnet, call->conn);
rxrpc_activate_channels(call->conn);
ret = rxrpc_wait_for_channel(call, gfp);
- if (ret < 0)
+ if (ret < 0) {
rxrpc_disconnect_client_call(call);
+ goto out;
+ }
+
+ spin_lock_bh(&call->conn->params.peer->lock);
+ hlist_add_head(&call->error_link,
+ &call->conn->params.peer->error_targets);
+ spin_unlock_bh(&call->conn->params.peer->lock);
+out:
_leave(" = %d", ret);
return ret;
}
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 344fdce89823..9ea6f972767e 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -128,8 +128,10 @@ static void rxrpc_queue_packet(struct rxrpc_sock *rx, struct rxrpc_call *call,
ASSERTCMP(seq, ==, call->tx_top + 1);
- if (last)
+ if (last) {
annotation |= RXRPC_TX_ANNO_LAST;
+ set_bit(RXRPC_CALL_TX_LASTQ, &call->flags);
+ }
/* We have to set the timestamp before queueing as the retransmit
* algorithm can see the packet as soon as we queue it.
@@ -326,11 +328,6 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
call->tx_total_len -= copy;
}
- /* check for the far side aborting the call or a network error
- * occurring */
- if (call->state == RXRPC_CALL_COMPLETE)
- goto call_terminated;
-
/* add the packet to the send queue if it's now full */
if (sp->remain <= 0 ||
(msg_data_left(msg) == 0 && !more)) {
@@ -370,6 +367,16 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
notify_end_tx);
skb = NULL;
}
+
+ /* Check for the far side aborting the call or a network error
+ * occurring. If this happens, save any packet that was under
+ * construction so that in the case of a network error, the
+ * call can be retried or redirected.
+ */
+ if (call->state == RXRPC_CALL_COMPLETE) {
+ ret = call->error;
+ goto out;
+ }
} while (msg_data_left(msg) > 0);
success:
@@ -379,11 +386,6 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
_leave(" = %d", ret);
return ret;
-call_terminated:
- rxrpc_free_skb(skb, rxrpc_skb_tx_freed);
- _leave(" = %d", call->error);
- return call->error;
-
maybe_error:
if (copied)
goto success;
^ permalink raw reply related
* [PATCH net-next 6/7] rxrpc: Add notification of end-of-Tx phase
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Add a callback to rxrpc_kernel_send_data() so that a kernel service can get
a notification that the AF_RXRPC call has transitioned out the Tx phase and
is now waiting for a reply or a final ACK.
This is called from AF_RXRPC with the call state lock held so the
notification is guaranteed to come before any reply is passed back.
Further, modify the AFS filesystem to make use of this so that we don't have
to change the afs_call state before sending the last bit of data.
Signed-off-by: David Howells <dhowells@redhat.com>
---
Documentation/networking/rxrpc.txt | 12 +++++++++
fs/afs/rxrpc.c | 46 +++++++++++++++++++++++++++---------
include/net/af_rxrpc.h | 5 +++-
net/rxrpc/sendmsg.c | 34 +++++++++++++++++++++------
4 files changed, 77 insertions(+), 20 deletions(-)
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 8c70ba5dee4d..92a3c3bd5ac3 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -818,10 +818,15 @@ The kernel interface functions are as follows:
(*) Send data through a call.
+ typedef void (*rxrpc_notify_end_tx_t)(struct sock *sk,
+ unsigned long user_call_ID,
+ struct sk_buff *skb);
+
int rxrpc_kernel_send_data(struct socket *sock,
struct rxrpc_call *call,
struct msghdr *msg,
- size_t len);
+ size_t len,
+ rxrpc_notify_end_tx_t notify_end_rx);
This is used to supply either the request part of a client call or the
reply part of a server call. msg.msg_iovlen and msg.msg_iov specify the
@@ -832,6 +837,11 @@ The kernel interface functions are as follows:
The msg must not specify a destination address, control data or any flags
other than MSG_MORE. len is the total amount of data to transmit.
+ notify_end_rx can be NULL or it can be used to specify a function to be
+ called when the call changes state to end the Tx phase. This function is
+ called with the call-state spinlock held to prevent any reply or final ACK
+ from being delivered first.
+
(*) Receive data from a call.
int rxrpc_kernel_recv_data(struct socket *sock,
diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c
index 10743043d431..0bf191f0dbaf 100644
--- a/fs/afs/rxrpc.c
+++ b/fs/afs/rxrpc.c
@@ -292,6 +292,19 @@ static void afs_load_bvec(struct afs_call *call, struct msghdr *msg,
}
/*
+ * Advance the AFS call state when the RxRPC call ends the transmit phase.
+ */
+static void afs_notify_end_request_tx(struct sock *sock,
+ struct rxrpc_call *rxcall,
+ unsigned long call_user_ID)
+{
+ struct afs_call *call = (struct afs_call *)call_user_ID;
+
+ if (call->state == AFS_CALL_REQUESTING)
+ call->state = AFS_CALL_AWAIT_REPLY;
+}
+
+/*
* attach the data from a bunch of pages on an inode to a call
*/
static int afs_send_pages(struct afs_call *call, struct msghdr *msg)
@@ -310,14 +323,8 @@ static int afs_send_pages(struct afs_call *call, struct msghdr *msg)
bytes = msg->msg_iter.count;
nr = msg->msg_iter.nr_segs;
- /* Have to change the state *before* sending the last
- * packet as RxRPC might give us the reply before it
- * returns from sending the request.
- */
- if (first + nr - 1 >= last)
- call->state = AFS_CALL_AWAIT_REPLY;
- ret = rxrpc_kernel_send_data(afs_socket, call->rxcall,
- msg, bytes);
+ ret = rxrpc_kernel_send_data(afs_socket, call->rxcall, msg,
+ bytes, afs_notify_end_request_tx);
for (loop = 0; loop < nr; loop++)
put_page(bv[loop].bv_page);
if (ret < 0)
@@ -409,7 +416,8 @@ int afs_make_call(struct in_addr *addr, struct afs_call *call, gfp_t gfp,
if (!call->send_pages)
call->state = AFS_CALL_AWAIT_REPLY;
ret = rxrpc_kernel_send_data(afs_socket, rxcall,
- &msg, call->request_size);
+ &msg, call->request_size,
+ afs_notify_end_request_tx);
if (ret < 0)
goto error_do_abort;
@@ -741,6 +749,20 @@ static int afs_deliver_cm_op_id(struct afs_call *call)
}
/*
+ * Advance the AFS call state when an RxRPC service call ends the transmit
+ * phase.
+ */
+static void afs_notify_end_reply_tx(struct sock *sock,
+ struct rxrpc_call *rxcall,
+ unsigned long call_user_ID)
+{
+ struct afs_call *call = (struct afs_call *)call_user_ID;
+
+ if (call->state == AFS_CALL_REPLYING)
+ call->state = AFS_CALL_AWAIT_ACK;
+}
+
+/*
* send an empty reply
*/
void afs_send_empty_reply(struct afs_call *call)
@@ -759,7 +781,8 @@ void afs_send_empty_reply(struct afs_call *call)
msg.msg_flags = 0;
call->state = AFS_CALL_AWAIT_ACK;
- switch (rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, 0)) {
+ switch (rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, 0,
+ afs_notify_end_reply_tx)) {
case 0:
_leave(" [replied]");
return;
@@ -797,7 +820,8 @@ void afs_send_simple_reply(struct afs_call *call, const void *buf, size_t len)
msg.msg_flags = 0;
call->state = AFS_CALL_AWAIT_ACK;
- n = rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, len);
+ n = rxrpc_kernel_send_data(afs_socket, call->rxcall, &msg, len,
+ afs_notify_end_reply_tx);
if (n >= 0) {
/* Success */
_leave(" [replied]");
diff --git a/include/net/af_rxrpc.h b/include/net/af_rxrpc.h
index c172709787af..07a47ee6f783 100644
--- a/include/net/af_rxrpc.h
+++ b/include/net/af_rxrpc.h
@@ -21,6 +21,8 @@ struct rxrpc_call;
typedef void (*rxrpc_notify_rx_t)(struct sock *, struct rxrpc_call *,
unsigned long);
+typedef void (*rxrpc_notify_end_tx_t)(struct sock *, struct rxrpc_call *,
+ unsigned long);
typedef void (*rxrpc_notify_new_call_t)(struct sock *, struct rxrpc_call *,
unsigned long);
typedef void (*rxrpc_discard_new_call_t)(struct rxrpc_call *, unsigned long);
@@ -37,7 +39,8 @@ struct rxrpc_call *rxrpc_kernel_begin_call(struct socket *,
gfp_t,
rxrpc_notify_rx_t);
int rxrpc_kernel_send_data(struct socket *, struct rxrpc_call *,
- struct msghdr *, size_t);
+ struct msghdr *, size_t,
+ rxrpc_notify_end_tx_t);
int rxrpc_kernel_recv_data(struct socket *, struct rxrpc_call *,
void *, size_t, size_t *, bool, u32 *);
bool rxrpc_kernel_abort_call(struct socket *, struct rxrpc_call *,
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index bc7f0241d92b..344fdce89823 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -101,11 +101,23 @@ static inline void rxrpc_instant_resend(struct rxrpc_call *call, int ix)
}
/*
+ * Notify the owner of the call that the transmit phase is ended and the last
+ * packet has been queued.
+ */
+static void rxrpc_notify_end_tx(struct rxrpc_sock *rx, struct rxrpc_call *call,
+ rxrpc_notify_end_tx_t notify_end_tx)
+{
+ if (notify_end_tx)
+ notify_end_tx(&rx->sk, call, call->user_call_ID);
+}
+
+/*
* Queue a DATA packet for transmission, set the resend timeout and send the
* packet immediately
*/
-static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
- bool last)
+static void rxrpc_queue_packet(struct rxrpc_sock *rx, struct rxrpc_call *call,
+ struct sk_buff *skb, bool last,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
rxrpc_seq_t seq = sp->hdr.seq;
@@ -141,6 +153,7 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
switch (call->state) {
case RXRPC_CALL_CLIENT_SEND_REQUEST:
call->state = RXRPC_CALL_CLIENT_AWAIT_REPLY;
+ rxrpc_notify_end_tx(rx, call, notify_end_tx);
break;
case RXRPC_CALL_SERVER_ACK_REQUEST:
call->state = RXRPC_CALL_SERVER_SEND_REPLY;
@@ -153,6 +166,7 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
break;
case RXRPC_CALL_SERVER_SEND_REPLY:
call->state = RXRPC_CALL_SERVER_AWAIT_ACK;
+ rxrpc_notify_end_tx(rx, call, notify_end_tx);
break;
default:
break;
@@ -189,7 +203,8 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, struct sk_buff *skb,
*/
static int rxrpc_send_data(struct rxrpc_sock *rx,
struct rxrpc_call *call,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
struct rxrpc_skb_priv *sp;
struct sk_buff *skb;
@@ -350,7 +365,9 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
if (ret < 0)
goto out;
- rxrpc_queue_packet(call, skb, !msg_data_left(msg) && !more);
+ rxrpc_queue_packet(rx, call, skb,
+ !msg_data_left(msg) && !more,
+ notify_end_tx);
skb = NULL;
}
} while (msg_data_left(msg) > 0);
@@ -611,7 +628,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
/* Reply phase not begun or not complete for service call. */
ret = -EPROTO;
} else {
- ret = rxrpc_send_data(rx, call, msg, len);
+ ret = rxrpc_send_data(rx, call, msg, len, NULL);
}
mutex_unlock(&call->user_mutex);
@@ -631,6 +648,7 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
* @call: The call to send data through
* @msg: The data to send
* @len: The amount of data to send
+ * @notify_end_tx: Notification that the last packet is queued.
*
* Allow a kernel service to send data on a call. The call must be in an state
* appropriate to sending data. No control data should be supplied in @msg,
@@ -638,7 +656,8 @@ int rxrpc_do_sendmsg(struct rxrpc_sock *rx, struct msghdr *msg, size_t len)
* more data to come, otherwise this data will end the transmission phase.
*/
int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
- struct msghdr *msg, size_t len)
+ struct msghdr *msg, size_t len,
+ rxrpc_notify_end_tx_t notify_end_tx)
{
int ret;
@@ -656,7 +675,8 @@ int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
case RXRPC_CALL_CLIENT_SEND_REQUEST:
case RXRPC_CALL_SERVER_ACK_REQUEST:
case RXRPC_CALL_SERVER_SEND_REPLY:
- ret = rxrpc_send_data(rxrpc_sk(sock->sk), call, msg, len);
+ ret = rxrpc_send_data(rxrpc_sk(sock->sk), call, msg, len,
+ notify_end_tx);
break;
case RXRPC_CALL_COMPLETE:
read_lock_bh(&call->state_lock);
^ permalink raw reply related
* [PATCH net-next 5/7] rxrpc: Remove some excess whitespace
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Remove indentation from some blank lines.
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/af_rxrpc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index a2ad4482376f..31e97f714ca9 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -591,13 +591,13 @@ static int rxrpc_getsockopt(struct socket *sock, int level, int optname,
char __user *optval, int __user *_optlen)
{
int optlen;
-
+
if (level != SOL_RXRPC)
return -EOPNOTSUPP;
if (get_user(optlen, _optlen))
return -EFAULT;
-
+
switch (optname) {
case RXRPC_SUPPORTED_CMSG:
if (optlen < sizeof(int))
@@ -606,7 +606,7 @@ static int rxrpc_getsockopt(struct socket *sock, int level, int optname,
put_user(sizeof(int), _optlen))
return -EFAULT;
return 0;
-
+
default:
return -EOPNOTSUPP;
}
^ permalink raw reply related
* [PATCH net-next 4/7] rxrpc: Don't negate call->error before returning it
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
call->error is stored as 0 or a negative error code. Don't negate this
value (ie. make it positive) before returning it from a kernel function
(though it should still be negated before passing to userspace through a
control message).
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/sendmsg.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index b0d2cda6ec0a..bc7f0241d92b 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -61,7 +61,7 @@ static int rxrpc_wait_for_tx_window(struct rxrpc_sock *rx,
call->cong_cwnd + call->cong_extra))
break;
if (call->state >= RXRPC_CALL_COMPLETE) {
- ret = -call->error;
+ ret = call->error;
break;
}
if (signal_pending(current)) {
@@ -364,8 +364,8 @@ static int rxrpc_send_data(struct rxrpc_sock *rx,
call_terminated:
rxrpc_free_skb(skb, rxrpc_skb_tx_freed);
- _leave(" = %d", -call->error);
- return -call->error;
+ _leave(" = %d", call->error);
+ return call->error;
maybe_error:
if (copied)
@@ -660,7 +660,7 @@ int rxrpc_kernel_send_data(struct socket *sock, struct rxrpc_call *call,
break;
case RXRPC_CALL_COMPLETE:
read_lock_bh(&call->state_lock);
- ret = -call->error;
+ ret = call->error;
read_unlock_bh(&call->state_lock);
break;
default:
^ permalink raw reply related
* [PATCH net-next 3/7] rxrpc: Fix IPv6 support
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
Fix IPv6 support in AF_RXRPC in the following ways:
(1) When extracting the address from a received IPv4 packet, if the local
transport socket is open for IPv6 then fill out the sockaddr_rxrpc
struct for an IPv4-mapped-to-IPv6 AF_INET6 transport address instead
of an AF_INET one.
(2) When sending CHALLENGE or RESPONSE packets, the transport length needs
to be set from the sockaddr_rxrpc::transport_len field rather than
sizeof() on the IPv4 transport address.
(3) When processing an IPv4 ICMP packet received by an IPv6 socket, set up
the address correctly before searching for the affected peer.
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/ar-internal.h | 4 ++--
net/rxrpc/call_accept.c | 2 +-
net/rxrpc/conn_object.c | 2 +-
net/rxrpc/local_event.c | 2 +-
net/rxrpc/output.c | 2 +-
net/rxrpc/peer_event.c | 6 ++++--
net/rxrpc/rxkad.c | 8 ++++----
net/rxrpc/utils.c | 23 +++++++++++++++++------
8 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 8cac66774de1..227e24794055 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -830,7 +830,6 @@ void rxrpc_process_connection(struct work_struct *);
*/
extern unsigned int rxrpc_connection_expiry;
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *, struct sk_buff *);
struct rxrpc_connection *rxrpc_alloc_connection(gfp_t);
struct rxrpc_connection *rxrpc_find_connection_rcu(struct rxrpc_local *,
struct sk_buff *);
@@ -1060,7 +1059,8 @@ static inline void rxrpc_sysctl_exit(void) {}
/*
* utils.c
*/
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *, struct sk_buff *);
+int rxrpc_extract_addr_from_skb(struct rxrpc_local *, struct sockaddr_rxrpc *,
+ struct sk_buff *);
static inline bool before(u32 seq1, u32 seq2)
{
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index ec3383f97d4c..cbd1701e813a 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -277,7 +277,7 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx,
* anticipation - and to save on stack space.
*/
xpeer = b->peer_backlog[peer_tail];
- if (rxrpc_extract_addr_from_skb(&xpeer->srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &xpeer->srx, skb) < 0)
return NULL;
peer = rxrpc_lookup_incoming_peer(local, xpeer);
diff --git a/net/rxrpc/conn_object.c b/net/rxrpc/conn_object.c
index 929b50d5afe8..fe575798592f 100644
--- a/net/rxrpc/conn_object.c
+++ b/net/rxrpc/conn_object.c
@@ -72,7 +72,7 @@ struct rxrpc_connection *rxrpc_find_connection_rcu(struct rxrpc_local *local,
_enter(",%x", sp->hdr.cid & RXRPC_CIDMASK);
- if (rxrpc_extract_addr_from_skb(&srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) < 0)
goto not_found;
k.epoch = sp->hdr.epoch;
diff --git a/net/rxrpc/local_event.c b/net/rxrpc/local_event.c
index 540d3955c1bc..93b5d910b4a1 100644
--- a/net/rxrpc/local_event.c
+++ b/net/rxrpc/local_event.c
@@ -39,7 +39,7 @@ static void rxrpc_send_version_request(struct rxrpc_local *local,
_enter("");
- if (rxrpc_extract_addr_from_skb(&srx, skb) < 0)
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) < 0)
return;
msg.msg_name = &srx.transport;
diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
index 5bd2d0fa4a03..71e6f713fbe7 100644
--- a/net/rxrpc/output.c
+++ b/net/rxrpc/output.c
@@ -444,7 +444,7 @@ void rxrpc_reject_packets(struct rxrpc_local *local)
rxrpc_see_skb(skb, rxrpc_skb_rx_seen);
sp = rxrpc_skb(skb);
- if (rxrpc_extract_addr_from_skb(&srx, skb) == 0) {
+ if (rxrpc_extract_addr_from_skb(local, &srx, skb) == 0) {
msg.msg_namelen = srx.transport_len;
code = htonl(skb->priority);
diff --git a/net/rxrpc/peer_event.c b/net/rxrpc/peer_event.c
index 1ed9c0c2e94f..7f749505e699 100644
--- a/net/rxrpc/peer_event.c
+++ b/net/rxrpc/peer_event.c
@@ -37,6 +37,7 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
memset(&srx, 0, sizeof(srx));
srx.transport_type = local->srx.transport_type;
+ srx.transport_len = local->srx.transport_len;
srx.transport.family = local->srx.transport.family;
/* Can we see an ICMP4 packet on an ICMP6 listening socket? and vice
@@ -45,7 +46,6 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
switch (srx.transport.family) {
case AF_INET:
srx.transport.sin.sin_port = serr->port;
- srx.transport_len = sizeof(struct sockaddr_in);
switch (serr->ee.ee_origin) {
case SO_EE_ORIGIN_ICMP:
_net("Rx ICMP");
@@ -69,7 +69,6 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
#ifdef CONFIG_AF_RXRPC_IPV6
case AF_INET6:
srx.transport.sin6.sin6_port = serr->port;
- srx.transport_len = sizeof(struct sockaddr_in6);
switch (serr->ee.ee_origin) {
case SO_EE_ORIGIN_ICMP6:
_net("Rx ICMP6");
@@ -79,6 +78,9 @@ static struct rxrpc_peer *rxrpc_lookup_peer_icmp_rcu(struct rxrpc_local *local,
break;
case SO_EE_ORIGIN_ICMP:
_net("Rx ICMP on v6 sock");
+ srx.transport.sin6.sin6_addr.s6_addr32[0] = 0;
+ srx.transport.sin6.sin6_addr.s6_addr32[1] = 0;
+ srx.transport.sin6.sin6_addr.s6_addr32[2] = htonl(0xffff);
memcpy(srx.transport.sin6.sin6_addr.s6_addr + 12,
skb_network_header(skb) + serr->addr_offset,
sizeof(struct in_addr));
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 34c86d2bcae5..c38b3a1de56c 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -634,8 +634,8 @@ static int rxkad_issue_challenge(struct rxrpc_connection *conn)
challenge.min_level = htonl(0);
challenge.__padding = 0;
- msg.msg_name = &conn->params.peer->srx.transport.sin;
- msg.msg_namelen = sizeof(conn->params.peer->srx.transport.sin);
+ msg.msg_name = &conn->params.peer->srx.transport;
+ msg.msg_namelen = conn->params.peer->srx.transport_len;
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_flags = 0;
@@ -689,8 +689,8 @@ static int rxkad_send_response(struct rxrpc_connection *conn,
_enter("");
- msg.msg_name = &conn->params.peer->srx.transport.sin;
- msg.msg_namelen = sizeof(conn->params.peer->srx.transport.sin);
+ msg.msg_name = &conn->params.peer->srx.transport;
+ msg.msg_namelen = conn->params.peer->srx.transport_len;
msg.msg_control = NULL;
msg.msg_controllen = 0;
msg.msg_flags = 0;
diff --git a/net/rxrpc/utils.c b/net/rxrpc/utils.c
index ff7af71c4b49..e801171fa351 100644
--- a/net/rxrpc/utils.c
+++ b/net/rxrpc/utils.c
@@ -17,17 +17,28 @@
/*
* Fill out a peer address from a socket buffer containing a packet.
*/
-int rxrpc_extract_addr_from_skb(struct sockaddr_rxrpc *srx, struct sk_buff *skb)
+int rxrpc_extract_addr_from_skb(struct rxrpc_local *local,
+ struct sockaddr_rxrpc *srx,
+ struct sk_buff *skb)
{
memset(srx, 0, sizeof(*srx));
switch (ntohs(skb->protocol)) {
case ETH_P_IP:
- srx->transport_type = SOCK_DGRAM;
- srx->transport_len = sizeof(srx->transport.sin);
- srx->transport.sin.sin_family = AF_INET;
- srx->transport.sin.sin_port = udp_hdr(skb)->source;
- srx->transport.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
+ if (local->srx.transport.family == AF_INET6) {
+ srx->transport_type = SOCK_DGRAM;
+ srx->transport_len = sizeof(srx->transport.sin6);
+ srx->transport.sin6.sin6_family = AF_INET6;
+ srx->transport.sin6.sin6_port = udp_hdr(skb)->source;
+ srx->transport.sin6.sin6_addr.s6_addr32[2] = htonl(0xffff);
+ srx->transport.sin6.sin6_addr.s6_addr32[3] = ip_hdr(skb)->saddr;
+ } else {
+ srx->transport_type = SOCK_DGRAM;
+ srx->transport_len = sizeof(srx->transport.sin);
+ srx->transport.sin.sin_family = AF_INET;
+ srx->transport.sin.sin_port = udp_hdr(skb)->source;
+ srx->transport.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
+ }
return 0;
#ifdef CONFIG_AF_RXRPC_IPV6
^ permalink raw reply related
* [PATCH net-next 2/7] rxrpc: Use correct timestamp from Kerberos 5 ticket
From: David Howells @ 2017-08-29 12:27 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
When an XDR-encoded Kerberos 5 ticket is added as an rxrpc-type key, the
expiry time should be drawn from the k5 part of the token union (which was
what was filled in), rather than the kad part of the union.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
---
net/rxrpc/key.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index e2d36619b53a..e7f6b8823eb6 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -536,7 +536,7 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ expiry = rxrpc_u32_to_time64(token->k5->endtime);
if (expiry < prep->expiry)
prep->expiry = expiry;
^ permalink raw reply related
* [PATCH net-next 1/7] net: rxrpc: Replace time_t type with time64_t type
From: David Howells @ 2017-08-29 12:26 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <150400960745.21371.15455867950162722742.stgit@warthog.procyon.org.uk>
From: Baolin Wang <baolin.wang@linaro.org>
Since the 'expiry' variable of 'struct key_preparsed_payload' has been
changed to 'time64_t' type, which is year 2038 safe on 32bits system.
In net/rxrpc subsystem, we need convert 'u32' type to 'time64_t' type
when copying ticket expires time to 'prep->expiry', then this patch
introduces two helper functions to help convert 'u32' to 'time64_t'
type.
This patch also uses ktime_get_real_seconds() to get current time instead
of get_seconds() which is not year 2038 safe on 32bits system.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/keys/rxrpc-type.h | 23 +++++++++++++++++++++++
net/rxrpc/ar-internal.h | 2 +-
net/rxrpc/key.c | 22 ++++++++++++++--------
net/rxrpc/rxkad.c | 14 +++++++-------
4 files changed, 45 insertions(+), 16 deletions(-)
diff --git a/include/keys/rxrpc-type.h b/include/keys/rxrpc-type.h
index 5de0673f333b..8cf829dbf20e 100644
--- a/include/keys/rxrpc-type.h
+++ b/include/keys/rxrpc-type.h
@@ -127,4 +127,27 @@ struct rxrpc_key_data_v1 {
#define AFSTOKEN_K5_ADDRESSES_MAX 16 /* max K5 addresses */
#define AFSTOKEN_K5_AUTHDATA_MAX 16 /* max K5 pieces of auth data */
+/*
+ * Truncate a time64_t to the range from 1970 to 2106 as in the network
+ * protocol.
+ */
+static inline u32 rxrpc_time64_to_u32(time64_t time)
+{
+ if (time < 0)
+ return 0;
+
+ if (time > UINT_MAX)
+ return UINT_MAX;
+
+ return (u32)time;
+}
+
+/*
+ * Extend u32 back to time64_t using the same 1970-2106 range.
+ */
+static inline time64_t rxrpc_u32_to_time64(u32 time)
+{
+ return (time64_t)time;
+}
+
#endif /* _KEYS_RXRPC_TYPE_H */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 8c0db9b3e4ab..8cac66774de1 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -894,7 +894,7 @@ extern struct key_type key_type_rxrpc_s;
int rxrpc_request_key(struct rxrpc_sock *, char __user *, int);
int rxrpc_server_keyring(struct rxrpc_sock *, char __user *, int);
-int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time_t,
+int rxrpc_get_server_data_key(struct rxrpc_connection *, const void *, time64_t,
u32);
/*
diff --git a/net/rxrpc/key.c b/net/rxrpc/key.c
index 54369225766e..e2d36619b53a 100644
--- a/net/rxrpc/key.c
+++ b/net/rxrpc/key.c
@@ -92,6 +92,7 @@ static int rxrpc_preparse_xdr_rxkad(struct key_preparsed_payload *prep,
const __be32 *xdr, unsigned int toklen)
{
struct rxrpc_key_token *token, **pptoken;
+ time64_t expiry;
size_t plen;
u32 tktlen;
@@ -158,8 +159,9 @@ static int rxrpc_preparse_xdr_rxkad(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
_leave(" = 0");
return 0;
@@ -433,6 +435,7 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
struct rxrpc_key_token *token, **pptoken;
struct rxk5_key *rxk5;
const __be32 *end_xdr = xdr + (toklen >> 2);
+ time64_t expiry;
int ret;
_enter(",{%x,%x,%x,%x},%u",
@@ -533,8 +536,9 @@ static int rxrpc_preparse_xdr_rxk5(struct key_preparsed_payload *prep,
pptoken = &(*pptoken)->next)
continue;
*pptoken = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
_leave(" = 0");
return 0;
@@ -691,6 +695,7 @@ static int rxrpc_preparse(struct key_preparsed_payload *prep)
{
const struct rxrpc_key_data_v1 *v1;
struct rxrpc_key_token *token, **pp;
+ time64_t expiry;
size_t plen;
u32 kver;
int ret;
@@ -777,8 +782,9 @@ static int rxrpc_preparse(struct key_preparsed_payload *prep)
while (*pp)
pp = &(*pp)->next;
*pp = token;
- if (token->kad->expiry < prep->expiry)
- prep->expiry = token->kad->expiry;
+ expiry = rxrpc_u32_to_time64(token->kad->expiry);
+ if (expiry < prep->expiry)
+ prep->expiry = expiry;
token = NULL;
ret = 0;
@@ -955,7 +961,7 @@ int rxrpc_server_keyring(struct rxrpc_sock *rx, char __user *optval,
*/
int rxrpc_get_server_data_key(struct rxrpc_connection *conn,
const void *session_key,
- time_t expiry,
+ time64_t expiry,
u32 kvno)
{
const struct cred *cred = current_cred();
@@ -982,7 +988,7 @@ int rxrpc_get_server_data_key(struct rxrpc_connection *conn,
data.kver = 1;
data.v1.security_index = RXRPC_SECURITY_RXKAD;
data.v1.ticket_length = 0;
- data.v1.expiry = expiry;
+ data.v1.expiry = rxrpc_time64_to_u32(expiry);
data.v1.kvno = 0;
memcpy(&data.v1.session_key, session_key, sizeof(data.v1.session_key));
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index 46d1a1f0b55b..34c86d2bcae5 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -854,7 +854,7 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
struct sk_buff *skb,
void *ticket, size_t ticket_len,
struct rxrpc_crypt *_session_key,
- time_t *_expiry,
+ time64_t *_expiry,
u32 *_abort_code)
{
struct skcipher_request *req;
@@ -864,7 +864,7 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
struct in_addr addr;
unsigned int life;
const char *eproto;
- time_t issue, now;
+ time64_t issue, now;
bool little_endian;
int ret;
u32 abort_code;
@@ -960,15 +960,15 @@ static int rxkad_decrypt_ticket(struct rxrpc_connection *conn,
if (little_endian) {
__le32 stamp;
memcpy(&stamp, p, 4);
- issue = le32_to_cpu(stamp);
+ issue = rxrpc_u32_to_time64(le32_to_cpu(stamp));
} else {
__be32 stamp;
memcpy(&stamp, p, 4);
- issue = be32_to_cpu(stamp);
+ issue = rxrpc_u32_to_time64(be32_to_cpu(stamp));
}
p += 4;
- now = get_seconds();
- _debug("KIV ISSUE: %lx [%lx]", issue, now);
+ now = ktime_get_real_seconds();
+ _debug("KIV ISSUE: %llx [%llx]", issue, now);
/* check the ticket is in date */
if (issue > now) {
@@ -1053,7 +1053,7 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
struct rxrpc_crypt session_key;
const char *eproto;
- time_t expiry;
+ time64_t expiry;
void *ticket;
u32 abort_code, version, kvno, ticket_len, level;
__be32 csum;
^ permalink raw reply related
* [PATCH net-next 0/7] rxrpc: Miscellany
From: David Howells @ 2017-08-29 12:26 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Here are a number of patches that make some changes/fixes and add a couple
of extensions to AF_RXRPC for kernel services to use. The changes and
fixes are:
(1) Use time64_t rather than u32 outside of protocol or
UAPI-representative structures.
(2) Use the correct time stamp when loading a key from an XDR-encoded
Kerberos 5 key.
(3) Fix IPv6 support.
(4) Fix some places where the error code is being incorrectly made
positive before returning.
(5) Remove some white space.
And the extensions:
(6) Add an end-of-Tx phase notification, thereby allowing kAFS to
transition the state on its own call record at the correct point,
rather than having to do it in advance and risk non-completion of the
call in the wrong state.
(7) Allow a kernel client call to be retried if it fails on a network
error, thereby making it possible for kAFS to iterate over a number of
IP addresses without having to reload the Tx queue and re-encrypt data
each time.
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-next
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-next-20170829
David
---
Baolin Wang (1):
net: rxrpc: Replace time_t type with time64_t type
David Howells (6):
rxrpc: Use correct timestamp from Kerberos 5 ticket
rxrpc: Fix IPv6 support
rxrpc: Don't negate call->error before returning it
rxrpc: Remove some excess whitespace
rxrpc: Add notification of end-of-Tx phase
rxrpc: Allow failed client calls to be retried
Documentation/networking/rxrpc.txt | 57 ++++++++++++++++++++
fs/afs/rxrpc.c | 46 ++++++++++++----
include/keys/rxrpc-type.h | 23 ++++++++
include/net/af_rxrpc.h | 21 +++++++
net/rxrpc/af_rxrpc.c | 75 +++++++++++++++++++++++++-
net/rxrpc/ar-internal.h | 25 ++++-----
net/rxrpc/call_accept.c | 2 -
net/rxrpc/call_object.c | 102 ++++++++++++++++++++++++++++++++++--
net/rxrpc/conn_client.c | 17 +++++-
net/rxrpc/conn_object.c | 2 -
net/rxrpc/key.c | 22 +++++---
net/rxrpc/local_event.c | 2 -
net/rxrpc/output.c | 2 -
net/rxrpc/peer_event.c | 6 +-
net/rxrpc/rxkad.c | 22 ++++----
net/rxrpc/sendmsg.c | 62 +++++++++++++++-------
net/rxrpc/utils.c | 23 ++++++--
17 files changed, 419 insertions(+), 90 deletions(-)
^ permalink raw reply
* Re: [PATCH] DSA support for Micrel KSZ8895
From: Andrew Lunn @ 2017-08-29 12:26 UTC (permalink / raw)
To: Pavel Machek
Cc: Maxim Uvarov, Woojung.Huh, nathan.leigh.conrad, Vivien Didelot,
Florian Fainelli, netdev, linux-kernel, Tristram.Ha
In-Reply-To: <20170829074130.GA31303@amd>
> But the MDIO emaulation code is from their driver, after lots of
> deletions.
Is this driver supposed to run on lots of different OSs? That would
explain why they ignored the Linux MDIO and PHY layers.
If possible, please make use of the Linux infrastructure.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver
From: Kishon Vijay Abraham I @ 2017-08-29 12:25 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, andrew, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170829112340.GB31552@kwain>
Hi,
On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
>>>
>>> +config PHY_MVEBU_CP110_COMPHY
>>> + tristate "Marvell CP110 comphy driver"
>>> + depends on ARCH_MVEBU && OF
>>
>> (ARCH_MVEBU || COMPILE_TEST) above..
>
> Sure, I'll update.
>
>>> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
>>> + /* lane 0 */
>>> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
>>> + /* lane 1 */
>>> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
>>> + /* lane 2 */
>>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
>>> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
>>> + /* lane 3 */
>>> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
>>> + /* lane 4 */
>>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
>>> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
>>> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
>>> + /* lane 5 */
>>> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
>>> +};
>>
>> IMHO all the lane and mode configuration should come from dt. That would make
>> it more reusable when comphy is configured differently.
>
> These connexions between engines and the comphy lanes are inside the
> SoC. They won't change for a given SoC, and the actual configuration is
> at the board level to know what is connected to the output of a given
> lane, which is already described into the dt (the lane phandle).
>
> So I think we can keep this inside the driver, and we'll had other
> tables if the same comphy is ever used in another SoC.
>
> What do you think?
I'd like to avoid adding tables for every SoC. These are configuration details
and can come from dt.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH net-next v3 01/13] phy: add sgmii and 10gkr modes to the phy_mode enum
From: Kishon Vijay Abraham I @ 2017-08-29 12:21 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, andrew, jason, sebastian.hesselbarth, gregory.clement,
thomas.petazzoni, nadavh, linux, linux-kernel, mw, stefanc,
miquel.raynal, netdev
In-Reply-To: <20170829112717.GC31552@kwain>
Hi,
On Tuesday 29 August 2017 04:57 PM, Antoine Tenart wrote:
> Hi Kishon,
>
> On Tue, Aug 29, 2017 at 04:08:29PM +0530, Kishon Vijay Abraham I wrote:
>> On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
>>> This patch adds more generic PHY modes to the phy_mode enum, to
>>> allow configuring generic PHYs to the SGMII and/or the 10GKR mode
>>> by using the set_mode callback.
>>>
>>> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
>>
>> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> Does this means the generic PHY patches of this series can go through
> the net-next tree (once all the comments are taken into account)?
yeah.. I'm already done with my pull request for 4.14 to Greg KH. As long as it
doesn't cause any conflicts to Linus, it should be okay to merge it in net-next.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 0/4] irda: move it to drivers/staging so we can delete it
From: Geert Uytterhoeven @ 2017-08-29 12:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Stefano Brivio, driverdevel, Samuel Ortiz,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
David S. Miller
In-Reply-To: <20170829112805.GB14571@kroah.com>
Hi Greg,
On Tue, Aug 29, 2017 at 1:28 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Aug 29, 2017 at 01:11:31PM +0200, Stefano Brivio wrote:
>> On Tue, 29 Aug 2017 12:59:00 +0200
>> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Sun, Aug 27, 2017 at 5:03 PM, Greg Kroah-Hartman
>> > <gregkh@linuxfoundation.org> wrote:
>> > > The IRDA code has long been obsolete and broken. So, to keep people
>> > > from trying to use it, and to prevent people from having to maintain it,
>> > > let's move it to drivers/staging/ so that we can delete it entirely from
>> > > the kernel in a few releases.
>> >
>> > (diving into an early boot crash)
>> >
>> > Have you tried running this? ;-)
>> >
>> > irda_init() and net_dev_init() are both subsys_initcall()s.
>> > But the former now runs before the latter, leading to:
>> >
>> > Unable to handle kernel NULL pointer dereference at virtual address 00000004
>>
>> Should be fixed by https://patchwork.ozlabs.org/patch/807006/
>> ("[net-next] staging: irda: force to be a kernel module") I guess...
>
> Yup, that's the fix for this issue.
>
> Geert, does that fix the problem for you?
Thanks, that patch fixes the crash, obviously.
It does mean you can no longer have IrDA in a non-modular kernel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Adam Ford @ 2017-08-29 12:02 UTC (permalink / raw)
To: Sekhar Nori; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <f0f5e11f-cd7a-cb86-58b5-8ce44cdbc032@ti.com>
On Tue, Aug 29, 2017 at 6:42 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
>> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>>> <grygorii.strashko@ti.com> wrote:
>>>>>> Cc: Sekhar
>>>>>>
>>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>>
>>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>>
>>>>>>> The function appears to lookup varions boards using
>>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>>> what's shown in the da850 device tree.
>>>>>>>
>>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>>
>>>>>>
>>>>>> Not sure if MAC address can be read from Control module.
>>>>>> May be Sekhar can say more?
>>>>>
>>>>> My understanding is that the MAC address is programmed by Logic PD
>>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>>> env variables. Looking at the partition info listed in the
>>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>>
>>> This code is present in U-Boot sources at
>>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>>> its usage in misc_init_r().
>>>
>>>>> there might be a way to just pass cmdline parameter from the
>>>>> bootloader to the kernel to accept the MAC address.
>>>>>
>>>>>>
>>>>>>>
>>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>>> driver so it doesn't generate a random MAC?
>>>>>>
>>>>>>
>>>>>> "local-mac-address" dt porp
>>>>>
>>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>>> device tree.
>>>>
>>>> That piece of code exists somewhere in u-boot already. Note how
>>>
>>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>>
>>>> we are populating the mac address for USB Ethernet drivers in
>>>> u-boot and then the Ethernet driver code parses it. See commit
>>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>>> the device tree") for some more information.
>>>>
>>>> I think u-boot needs the ethernet alias for finding the interface.
>>>
>>> That's exactly what was missing. I have sent a patch for fixing that and
>>> copied you there.
>>
>> Thanks for doing that.
>>
>>>
>>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>>> v4.13 itself.
>>
>> I will test it. Do need to run some instruction or do something
>> special in U-Boot to pass this in the proper place for the kernel to
>> pull it? Tony's patch reference showed
>> command for fdt set, but I am not sure I fully understand the
>> parameters that went along with that.
>
> Nope, just applying the patch and booting the with the new dtb should
> result in the random mac address going away.
Unfortunately, I am not seeing any change with the patch (at least
with Kernel 4.12.9 from stable).
netconsole: network logging started
davinci_emac davinci_emac.1: incompatible machine/device type for
reading mac address
davinci_emac davinci_emac.1: using random MAC addr: ee:74:c3:3a:15:be
Looking at the source for cpsw-common.c function ti_cm_get_macid()
doesn't have a case for the ti,davinci-dm6467-emac so I wonder if
there might be more to it.
adam
>
> Thanks,
> Sekhar
^ permalink raw reply
* Attention Dear Friend,
From: Mr.Robert Koffi @ 2017-08-29 11:49 UTC (permalink / raw)
Attention Dear Friend,
Compliment of the day to you, I sent you a mail a couple of day ago
about a transaction and haven't heard from you since then.The message
was to solicit your partnership to transfer the sum of ($14 million
US dollars) deposited by my late client how have the same last name
with you from the same country.I shall send you more information and
procedures when I receive a positive response from you.
I look forward to hearing from you.
Yours sincerely,
Mr Robert Koffi
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-08-29 11:42 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <CAHCN7x+-wymsqw96mt7Du=Huxh5rq=Rj9GidWPLXptJSW7taEA@mail.gmail.com>
On Tuesday 29 August 2017 03:53 PM, Adam Ford wrote:
> On Tue, Aug 29, 2017 at 3:23 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Tuesday 29 August 2017 02:42 AM, Tony Lindgren wrote:
>>> * Adam Ford <aford173@gmail.com> [170828 13:33]:
>>>> On Mon, Aug 28, 2017 at 1:54 PM, Grygorii Strashko
>>>> <grygorii.strashko@ti.com> wrote:
>>>>> Cc: Sekhar
>>>>>
>>>>> On 08/28/2017 10:32 AM, Adam Ford wrote:
>>>>>>
>>>>>> The davinvi_emac MAC address seems to attempt a call to
>>>>>> ti_cm_get_macid in cpsw-common.c but it returns the message
>>>>>> 'davinci_emac davinci_emac.1: incompatible machine/device type for
>>>>>> reading mac address ' and then generates a random MAC address.
>>>>>>
>>>>>> The function appears to lookup varions boards using
>>>>>> 'of_machine_is_compaible' and supports dm8148, am33xx, am3517, dm816,
>>>>>> am4372 and dra7. I don't see the ti,davinci-dm6467-emac which is
>>>>>> what's shown in the da850 device tree.
>>>>>>
>>>>>> Is there a patch somewhere for supporting the da850-evm?
>>>>>
>>>>>
>>>>> Not sure if MAC address can be read from Control module.
>>>>> May be Sekhar can say more?
>>>>
>>>> My understanding is that the MAC address is programmed by Logic PD
>>>> into the SPI flash. The Bootloader reads this from either SPI or its
>>>> env variables. Looking at the partition info listed in the
>>>> da850-evm.dts file, it appears as if they've reserved space for it.
>>>> Unfortunately, I don't see any code that reads it out. I was hoping
>>
>> This code is present in U-Boot sources at
>> board/davinci/da8xxevm/da850evm.c. See the function get_mac_addr() and
>> its usage in misc_init_r().
>>
>>>> there might be a way to just pass cmdline parameter from the
>>>> bootloader to the kernel to accept the MAC address.
>>>>
>>>>>
>>>>>>
>>>>>> If not, is there a way to pass the MAC address from U-Boot to the
>>>>>> driver so it doesn't generate a random MAC?
>>>>>
>>>>>
>>>>> "local-mac-address" dt porp
>>>>
>>>> The downside here, is that we'd have to have the Bootloader modify the
>>>> device tree.
>>>
>>> That piece of code exists somewhere in u-boot already. Note how
>>
>> Yes, it is fdt_fixup_ethernet() and its usage is in common/image-fdt.c.
>>
>>> we are populating the mac address for USB Ethernet drivers in
>>> u-boot and then the Ethernet driver code parses it. See commit
>>> 055d31de7158 ("ARM: omap3: beagleboard-xm: dt: Add ethernet to
>>> the device tree") for some more information.
>>>
>>> I think u-boot needs the ethernet alias for finding the interface.
>>
>> That's exactly what was missing. I have sent a patch for fixing that and
>> copied you there.
>
> Thanks for doing that.
>
>>
>> Adam, if I can get your Tested-by, I will make an attempt to send it for
>> v4.13 itself.
>
> I will test it. Do need to run some instruction or do something
> special in U-Boot to pass this in the proper place for the kernel to
> pull it? Tony's patch reference showed
> command for fdt set, but I am not sure I fully understand the
> parameters that went along with that.
Nope, just applying the patch and booting the with the new dtb should
result in the random mac address going away.
Thanks,
Sekhar
^ 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