* bpf: test_tunnel.sh: BUG: unable to handle kernel NULL pointer dereference
From: Naresh Kamboju @ 2019-02-01 15:30 UTC (permalink / raw)
To: Netdev, open list, open list:KERNEL SELFTEST FRAMEWORK,
Linux-Next Mailing List
Cc: David S. Miller, Valdis Kletnieks, Song Liu, Rafael Tinoco, ast,
Daniel Borkmann
Kernel panic while running bpf: test_tunnel.sh on linux -next
5.0.0-rc4-next-20190129.
selftests: bpf: test_tunnel.sh
[ 273.997647] IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready
[ 274.054068] ip (11458) used greatest stack depth: 11448 bytes left
[ 274.120445] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000000
[ 274.128285] #PF error: [INSTR]
[ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
[ 274.138241] Oops: 0010 [#1] SMP PTI
[ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
5.0.0-rc4-next-20190129 #1
[ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 274.156526] RIP: 0010: (null)
[ 274.160280] Code: Bad RIP value.
[ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.239541] Call Trace:
[ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
[ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
[ 274.250176] gre_fb_xmit+0x330/0x390
[ 274.253754] gre_tap_xmit+0x128/0x180
[ 274.257414] dev_hard_start_xmit+0xb7/0x300
[ 274.261598] sch_direct_xmit+0xf6/0x290
[ 274.265430] __qdisc_run+0x15d/0x5e0
[ 274.269007] __dev_queue_xmit+0x2c5/0xc00
[ 274.273011] ? dev_queue_xmit+0x10/0x20
[ 274.276842] ? eth_header+0x2b/0xc0
[ 274.280326] dev_queue_xmit+0x10/0x20
[ 274.283984] ? dev_queue_xmit+0x10/0x20
[ 274.287813] arp_xmit+0x1a/0xf0
[ 274.290952] arp_send_dst.part.19+0x46/0x60
[ 274.295138] arp_solicit+0x177/0x6b0
[ 274.298708] ? mod_timer+0x18e/0x440
[ 274.302281] neigh_probe+0x57/0x70
[ 274.305684] __neigh_event_send+0x197/0x2d0
[ 274.309862] neigh_resolve_output+0x18c/0x210
[ 274.314212] ip_finish_output2+0x257/0x690
[ 274.318304] ip_finish_output+0x219/0x340
[ 274.322314] ? ip_finish_output+0x219/0x340
[ 274.326493] ip_output+0x76/0x240
[ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
[ 274.334510] ip_local_out+0x3f/0x70
[ 274.337992] ip_send_skb+0x19/0x40
[ 274.341391] ip_push_pending_frames+0x33/0x40
[ 274.345740] raw_sendmsg+0xc15/0x11d0
[ 274.349403] ? __might_fault+0x85/0x90
[ 274.353151] ? _copy_from_user+0x6b/0xa0
[ 274.357070] ? rw_copy_check_uvector+0x54/0x130
[ 274.361604] inet_sendmsg+0x42/0x1c0
[ 274.365179] ? inet_sendmsg+0x42/0x1c0
[ 274.368937] sock_sendmsg+0x3e/0x50
[ 274.372460] ___sys_sendmsg+0x26f/0x2d0
[ 274.376293] ? lock_acquire+0x95/0x190
[ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
[ 274.384307] ? lock_acquire+0x95/0x190
[ 274.388053] ? __audit_syscall_entry+0xdd/0x130
[ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
[ 274.397461] ? __audit_syscall_entry+0xdd/0x130
[ 274.401989] ? trace_hardirqs_on+0x4c/0x100
[ 274.406173] __sys_sendmsg+0x63/0xa0
[ 274.409744] ? __sys_sendmsg+0x63/0xa0
[ 274.413488] __x64_sys_sendmsg+0x1f/0x30
[ 274.417405] do_syscall_64+0x55/0x190
[ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 274.426113] RIP: 0033:0x7ff4ae0e6e87
[ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
24 08
[ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
[ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
[ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
[ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
[ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
[ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
test_bpf]
[ 274.504634] CR2: 0000000000000000
[ 274.507976] ---[ end trace 196d18386545eae1 ]---
[ 274.512588] RIP: 0010: (null)
[ 274.516334] Code: Bad RIP value.
[ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
[ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
[ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
[ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
[ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
[ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
[ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
knlGS:0000000000000000
[ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
[ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
[ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt ]---
[ 274.620387] ------------[ cut here ]------------
The above log is from x86_64 device.
Full test log on arm64.
https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190129/testrun/589455/log
Best regards
Naresh Kamboju
^ permalink raw reply
* Want starting it?
From: Heather @ 2019-02-01 11:52 UTC (permalink / raw)
To: netdev
Do you need to change anything for your photos? we can help you for that.
We can do deep etching or masking, or even clipping path for your photos,
If you need retouching, just let us know.
Hopefully to start something for you soon.
Thanks,
Heather
Aalen
Kaufbeuren
^ permalink raw reply
* Want starting it?
From: Heather @ 2019-02-01 12:18 UTC (permalink / raw)
To: netdev
Do you need to change anything for your photos? we can help you for that.
We can do deep etching or masking, or even clipping path for your photos,
If you need retouching, just let us know.
Hopefully to start something for you soon.
Thanks,
Heather
Herford
Freising
^ permalink raw reply
* Re: [PATCH net] sctp: walk the list of asoc safely
From: Marcelo Ricardo Leitner @ 2019-02-01 14:58 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Vlad Yasevich, Neil Horman, linux-sctp, netdev, vuln
In-Reply-To: <20190201144359.GA9864@kroah.com>
On Fri, Feb 01, 2019 at 03:43:59PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Feb 01, 2019 at 12:20:37PM -0200, Marcelo Ricardo Leitner wrote:
> > On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> > > In sctp_sendmesg(), when walking the list of endpoint associations, the
> > > association can be dropped from the list, making the list corrupt.
> > > Properly handle this by using list_for_each_entry_safe()
> > >
> > > Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg")
> > > Reported-by: Secunia Research <vuln@secunia.com>
> > > Tested-by: Secunia Research <vuln@secunia.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > >
> > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > index f93c3cf9e567..65d6d04546ae 100644
> > > --- a/net/sctp/socket.c
> > > +++ b/net/sctp/socket.c
> > > @@ -2027,7 +2027,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
> > > struct sctp_endpoint *ep = sctp_sk(sk)->ep;
> > > struct sctp_transport *transport = NULL;
> > > struct sctp_sndrcvinfo _sinfo, *sinfo;
> > > - struct sctp_association *asoc;
> > > + struct sctp_association *asoc, *tmp;
> > > struct sctp_cmsgs cmsgs;
> > > union sctp_addr *daddr;
> > > bool new = false;
> > > @@ -2053,7 +2053,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
> >
> > Extending the context here by 1 line:
> > lock_sock(sk);
> > >
> > > /* SCTP_SENDALL process */
> > > if ((sflags & SCTP_SENDALL) && sctp_style(sk, UDP)) {
> > > - list_for_each_entry(asoc, &ep->asocs, asocs) {
> > > + list_for_each_entry_safe(asoc, tmp, &ep->asocs, asocs) {
> >
> > With the socket being locked by here, how can an asoc be removed
> > while the list is being traversed? The socket lock should be
> > protecting from it.
>
> What about when the SCTP_ABORT flag is set with SCTP_SENDALL at the same
> time?
>
> :(
Good point! Thanks.
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
^ permalink raw reply
* Re: [PATCH net] sctp: walk the list of asoc safely
From: Greg Kroah-Hartman @ 2019-02-01 14:43 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vlad Yasevich, Neil Horman, linux-sctp, netdev, vuln
In-Reply-To: <20190201142037.GC10521@localhost.localdomain>
On Fri, Feb 01, 2019 at 12:20:37PM -0200, Marcelo Ricardo Leitner wrote:
> On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> > In sctp_sendmesg(), when walking the list of endpoint associations, the
> > association can be dropped from the list, making the list corrupt.
> > Properly handle this by using list_for_each_entry_safe()
> >
> > Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg")
> > Reported-by: Secunia Research <vuln@secunia.com>
> > Tested-by: Secunia Research <vuln@secunia.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index f93c3cf9e567..65d6d04546ae 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -2027,7 +2027,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
> > struct sctp_endpoint *ep = sctp_sk(sk)->ep;
> > struct sctp_transport *transport = NULL;
> > struct sctp_sndrcvinfo _sinfo, *sinfo;
> > - struct sctp_association *asoc;
> > + struct sctp_association *asoc, *tmp;
> > struct sctp_cmsgs cmsgs;
> > union sctp_addr *daddr;
> > bool new = false;
> > @@ -2053,7 +2053,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
>
> Extending the context here by 1 line:
> lock_sock(sk);
> >
> > /* SCTP_SENDALL process */
> > if ((sflags & SCTP_SENDALL) && sctp_style(sk, UDP)) {
> > - list_for_each_entry(asoc, &ep->asocs, asocs) {
> > + list_for_each_entry_safe(asoc, tmp, &ep->asocs, asocs) {
>
> With the socket being locked by here, how can an asoc be removed
> while the list is being traversed? The socket lock should be
> protecting from it.
What about when the SCTP_ABORT flag is set with SCTP_SENDALL at the same
time?
:(
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Miquel Raynal @ 2019-02-01 14:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <20190201140831.GE30908@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> wrote on Fri, 1 Feb 2019 15:08:31 +0100:
> On Fri, Feb 01, 2019 at 12:01:19PM +0100, Miquel Raynal wrote:
> > Hi Vivien,
> >
> > Vivien Didelot <vivien.didelot@gmail.com> wrote on Wed, 30 Jan 2019
> > 19:46:08 -0500:
> >
> > > Hi Miquèl,
> > >
> > > On Wed, 30 Jan 2019 10:46:06 +0100, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > > > > > Today, there is no S2RAM support for switches. First, I proposed to add
> > > > > > > suspend/resume callbacks to the mv88e6xxx driver - just enough to avoid
> > > > > > > crashing the kernel.
> > > > > >
> > > > > > Then i would suggest the mv88e6xxx refuses the suspend. Actually that
> > > > > > probably is the first correct step. We don't have suspend support, so
> > > > > > stop the suspend happening, so preventing the kernel crash.
> > >
> > > Actually can you show me the crash that is happening?
> >
> > Sure, here it is: http://code.bulix.org/swwb11-569137
> >
> > Actually it is a silent crash but the platform never resumes. I am
> > pretty sure this is due to the kthread_queue_delayed_work() loop which
> > might access registers before it is allowed to do so.
>
> Hi Miquel
>
> That sounds like it is an MDIO driver problem, or at least, a resume
> ordering problem. You need to ensure that the MDIO bus driver is
> resumed before the switch driver. Also, that the switch is suspended
> before the MDIO bus driver is suspended.
I don't think there is an ordering problem. The MDIO bus is suspended
after the switch and resumed before. But if there is no cancellation of
the work thread (which is always automatically restarted) in the suspend
path, soon or later this work will run at a time when the MDIO bus is
still not accessible and will freeze the platform entirely.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH net] sctp: walk the list of asoc safely
From: Marcelo Ricardo Leitner @ 2019-02-01 14:20 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Vlad Yasevich, Neil Horman, linux-sctp, netdev, vuln
In-Reply-To: <20190201141522.GA20785@kroah.com>
On Fri, Feb 01, 2019 at 03:15:22PM +0100, Greg Kroah-Hartman wrote:
> In sctp_sendmesg(), when walking the list of endpoint associations, the
> association can be dropped from the list, making the list corrupt.
> Properly handle this by using list_for_each_entry_safe()
>
> Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg")
> Reported-by: Secunia Research <vuln@secunia.com>
> Tested-by: Secunia Research <vuln@secunia.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index f93c3cf9e567..65d6d04546ae 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2027,7 +2027,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
> struct sctp_endpoint *ep = sctp_sk(sk)->ep;
> struct sctp_transport *transport = NULL;
> struct sctp_sndrcvinfo _sinfo, *sinfo;
> - struct sctp_association *asoc;
> + struct sctp_association *asoc, *tmp;
> struct sctp_cmsgs cmsgs;
> union sctp_addr *daddr;
> bool new = false;
> @@ -2053,7 +2053,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
Extending the context here by 1 line:
lock_sock(sk);
>
> /* SCTP_SENDALL process */
> if ((sflags & SCTP_SENDALL) && sctp_style(sk, UDP)) {
> - list_for_each_entry(asoc, &ep->asocs, asocs) {
> + list_for_each_entry_safe(asoc, tmp, &ep->asocs, asocs) {
With the socket being locked by here, how can an asoc be removed
while the list is being traversed? The socket lock should be
protecting from it.
> err = sctp_sendmsg_check_sflags(asoc, sflags, msg,
> msg_len);
> if (err == 0)
^ permalink raw reply
* [PATCH net] sctp: walk the list of asoc safely
From: Greg Kroah-Hartman @ 2019-02-01 14:15 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner, linux-sctp,
netdev
In sctp_sendmesg(), when walking the list of endpoint associations, the
association can be dropped from the list, making the list corrupt.
Properly handle this by using list_for_each_entry_safe()
Fixes: 4910280503f3 ("sctp: add support for snd flag SCTP_SENDALL process in sendmsg")
Reported-by: Secunia Research <vuln@secunia.com>
Tested-by: Secunia Research <vuln@secunia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index f93c3cf9e567..65d6d04546ae 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2027,7 +2027,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
struct sctp_endpoint *ep = sctp_sk(sk)->ep;
struct sctp_transport *transport = NULL;
struct sctp_sndrcvinfo _sinfo, *sinfo;
- struct sctp_association *asoc;
+ struct sctp_association *asoc, *tmp;
struct sctp_cmsgs cmsgs;
union sctp_addr *daddr;
bool new = false;
@@ -2053,7 +2053,7 @@ static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
/* SCTP_SENDALL process */
if ((sflags & SCTP_SENDALL) && sctp_style(sk, UDP)) {
- list_for_each_entry(asoc, &ep->asocs, asocs) {
+ list_for_each_entry_safe(asoc, tmp, &ep->asocs, asocs) {
err = sctp_sendmsg_check_sflags(asoc, sflags, msg,
msg_len);
if (err == 0)
^ permalink raw reply related
* Re: [PATCH 10/18] smc911x: pass struct device to DMA API functions
From: Robin Murphy @ 2019-02-01 14:14 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel
Cc: iommu
In-Reply-To: <20190201084801.10983-11-hch@lst.de>
On 01/02/2019 08:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips with external DMA
handshaking, rather than actual DMA masters...
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/ethernet/smsc/smc911x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
> index 8355dfbb8ec3..b550e624500d 100644
> --- a/drivers/net/ethernet/smsc/smc911x.c
> +++ b/drivers/net/ethernet/smsc/smc911x.c
> @@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
>
> DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
> BUG_ON(skb == NULL);
> - dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
> + dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
..so while the wrong device is still better than no device at all, this
probably wants lp->txdma->device->dev.
> netif_trans_update(dev);
> dev_kfree_skb_irq(skb);
> lp->current_tx_skb = NULL;
> @@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
>
> DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
> DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
> - dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
> + dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
And equivalently for rxdma here. However, given that this all seems only
relevant to antique ARCH_PXA platforms which are presumably managing to
work as-is, it's probably not worth tinkering too much. I'd just stick a
note in the commit message that we're still only making these
self-consistent with the existing dma_map_single() calls rather than
necessarily correct.
Robin.
> BUG_ON(skb == NULL);
> lp->current_rx_skb = NULL;
> PRINT_PKT(skb->data, skb->len);
>
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: dsa: mv88e6xxx: Save switch rules
From: Andrew Lunn @ 2019-02-01 14:08 UTC (permalink / raw)
To: Miquel Raynal
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
linux-kernel, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai
In-Reply-To: <20190201120119.752e7ed6@xps13>
On Fri, Feb 01, 2019 at 12:01:19PM +0100, Miquel Raynal wrote:
> Hi Vivien,
>
> Vivien Didelot <vivien.didelot@gmail.com> wrote on Wed, 30 Jan 2019
> 19:46:08 -0500:
>
> > Hi Miquèl,
> >
> > On Wed, 30 Jan 2019 10:46:06 +0100, Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > > > > Today, there is no S2RAM support for switches. First, I proposed to add
> > > > > > suspend/resume callbacks to the mv88e6xxx driver - just enough to avoid
> > > > > > crashing the kernel.
> > > > >
> > > > > Then i would suggest the mv88e6xxx refuses the suspend. Actually that
> > > > > probably is the first correct step. We don't have suspend support, so
> > > > > stop the suspend happening, so preventing the kernel crash.
> >
> > Actually can you show me the crash that is happening?
>
> Sure, here it is: http://code.bulix.org/swwb11-569137
>
> Actually it is a silent crash but the platform never resumes. I am
> pretty sure this is due to the kthread_queue_delayed_work() loop which
> might access registers before it is allowed to do so.
Hi Miquel
That sounds like it is an MDIO driver problem, or at least, a resume
ordering problem. You need to ensure that the MDIO bus driver is
resumed before the switch driver. Also, that the switch is suspended
before the MDIO bus driver is suspended.
Andrew
^ permalink raw reply
* Re: bpf memory model. Was: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Paul E. McKenney @ 2019-02-01 14:05 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Will Deacon, Peter Zijlstra, Alexei Starovoitov, davem, daniel,
jakub.kicinski, netdev, kernel-team, mingo, jannh
In-Reply-To: <20190131184749.ic7pwxlxvpd2k7hn@ast-mbp.dhcp.thefacebook.com>
On Thu, Jan 31, 2019 at 10:47:50AM -0800, Alexei Starovoitov wrote:
> On Thu, Jan 31, 2019 at 06:01:56AM -0800, Paul E. McKenney wrote:
> > On Wed, Jan 30, 2019 at 02:57:43PM -0800, Alexei Starovoitov wrote:
> > > On Wed, Jan 30, 2019 at 01:05:36PM -0800, Paul E. McKenney wrote:
> > > > On Wed, Jan 30, 2019 at 11:51:14AM -0800, Alexei Starovoitov wrote:
> > > > > On Wed, Jan 30, 2019 at 10:36:18AM -0800, Paul E. McKenney wrote:
> > > > > > On Wed, Jan 30, 2019 at 06:11:00PM +0000, Will Deacon wrote:
> > > > > > > Hi Alexei,
> > > > > > >
> > > > > > > On Mon, Jan 28, 2019 at 01:56:24PM -0800, Alexei Starovoitov wrote:
> > > > > > > > On Mon, Jan 28, 2019 at 10:24:08AM +0100, Peter Zijlstra wrote:
> > > > > > > > > On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> > > > > > > > > > What I want to avoid is to define the whole execution ordering model upfront.
> > > > > > > > > > We cannot say that BPF ISA is weakly ordered like alpha.
> > > > > > > > > > Most of the bpf progs are written and running on x86. We shouldn't
> > > > > > > > > > twist bpf developer's arm by artificially relaxing memory model.
> > > > > > > > > > BPF memory model is equal to memory model of underlying architecture.
> > > > > > > > > > What we can do is to make it bpf progs a bit more portable with
> > > > > > > > > > smp_rmb instructions, but we must not force weak execution on the developer.
> > > > > > > > >
> > > > > > > > > Well, I agree with only introducing bits you actually need, and my
> > > > > > > > > smp_rmb() example might have been poorly chosen, smp_load_acquire() /
> > > > > > > > > smp_store_release() might have been a far more useful example.
> > > > > > > > >
> > > > > > > > > But I disagree with the last part; we have to pick a model now;
> > > > > > > > > otherwise you'll pain yourself into a corner.
> > > > > > > > >
> > > > > > > > > Also; Alpha isn't very relevant these days; however ARM64 does seem to
> > > > > > > > > be gaining a lot of attention and that is very much a weak architecture.
> > > > > > > > > Adding strongly ordered assumptions to BPF now, will penalize them in
> > > > > > > > > the long run.
> > > > > > > >
> > > > > > > > arm64 is gaining attention just like riscV is gaining it too.
> > > > > > > > BPF jit for arm64 is very solid, while BPF jit for riscV is being worked on.
> > > > > > > > BPF is not picking sides in CPU HW and ISA battles.
> > > > > > >
> > > > > > > It's not about picking a side, it's about providing an abstraction of the
> > > > > > > various CPU architectures out there so that the programmer doesn't need to
> > > > > > > worry about where their program may run. Hell, even if you just said "eBPF
> > > > > > > follows x86 semantics" that would be better than saying nothing (and then we
> > > > > > > could have a discussion about whether x86 semantics are really what you
> > > > > > > want).
> > > > > >
> > > > > > To reinforce this point, the Linux-kernel memory model (tools/memory-model)
> > > > > > is that abstraction for the Linux kernel. Why not just use that for BPF?
> > > > >
> > > > > I already answered this earlier in the thread.
> > > > > tldr: not going to sacrifice performance.
> > > >
> > > > Understood.
> > > >
> > > > But can we at least say that where there are no performance consequences,
> > > > BPF should follow LKMM? You already mentioned smp_load_acquire()
> > > > and smp_store_release(), but the void atomics (e.g., atomic_inc())
> > > > should also work because they don't provide any ordering guarantees.
> > > > The _relaxed(), _release(), and _acquire() variants of the value-returning
> > > > atomics should be just fine as well.
> > > >
> > > > The other value-returning atomics have strong ordering, which is fine
> > > > on many systems, but potentially suboptimal for the weakly ordered ones.
> > > > Though you have to have pretty good locality of reference to be able to
> > > > see the difference, because otherwise cache-miss overhead dominates.
> > > >
> > > > Things like cmpxchg() don't seem to fit BPF because they are normally
> > > > used in spin loops, though there are some non-spinning use cases.
> > > >
> > > > You correctly pointed out that READ_ONCE() and WRITE_ONCE() are suboptimal
> > > > on systems that don't support all sizes of loads, but I bet that there
> > > > are some sizes for which they are just fine across systems, for example,
> > > > pointer size and int size.
> > > >
> > > > Does that help? Or am I missing additional cases where performance
> > > > could be degraded?
> > >
> > > bpf doesn't have smp_load_acquire, atomic_fetch_add, xchg, fence instructions.
> > > They can be added step by step. That's easy.
> > > I believe folks already started working on adding atomic_fetch_add.
> > > What I have problem with is making a statement today that bpf's end
> > > goal is LKMM. Even after adding all sorts of instructions it may
> > > not be practical.
> > > Only when real use case requires adding new instruction we do it.
> > > Do you have a bpf program that needs smp_load_acquire ?
> >
> > We seem to be talking past each other. Let me try again...
> >
> > I believe that if BPF adds a given concurrency feature, it should follow
> > LKMM unless there is some specific problem with its doing so.
> >
> > My paragraphs in my previous email list the concurrency features BPF
> > could follow LKMM without penalty, should BPF choose to add them.
> >
> > Does that help?
>
> yeah. we're talking past each other indeed.
> Doesn't look like that more emails will help.
> Let's resolve it either f2f during next conference or join our bi-weekly
> bpf bluejeans call Wed 11am pacific.
> Reminders and links are on this list
> https://lists.iovisor.org/g/iovisor-dev/messages?p=created,0,,20,2,0,0
There is an instance of this meeting next week, correct?
If so, I could make the instance on Feb 27th, assuming that I have
access to bluejeans.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 03/18] net: caif: pass struct device to DMA API functions
From: Robin Murphy @ 2019-02-01 13:53 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
alsa-devel
Cc: iommu
In-Reply-To: <20190201084801.10983-4-hch@lst.de>
On 01/02/2019 08:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use the proper Kconfig symbol to check for DMA API availability.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
> 1 file changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
> index d28a1398c091..b7f3e263b57c 100644
> --- a/drivers/net/caif/caif_spi.c
> +++ b/drivers/net/caif/caif_spi.c
> @@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
> #define LOW_WATER_MARK 100
> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>
> -#ifdef CONFIG_UML
> +#ifdef CONFIG_HAS_DMA
#ifndef, surely?
Robin.
>
> /*
> * We sometimes use UML for debugging, but it cannot handle
> * dma_alloc_coherent so we have to wrap it.
> */
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
> {
> return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
> }
>
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> + dma_addr_t handle)
> {
> kfree(cpu_addr);
> }
>
> #else
>
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
> {
> - return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
> + return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
> GFP_KERNEL);
> }
>
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> + dma_addr_t handle)
> {
> - dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
> + dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
> }
> -#endif /* CONFIG_UML */
> +#endif /* CONFIG_HAS_DMA */
>
> #ifdef CONFIG_DEBUG_FS
>
> @@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
> }
>
> /* Allocate DMA buffers. */
> - cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
> + cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
> if (!cfspi->xfer.va_tx[0]) {
> res = -ENODEV;
> goto err_dma_alloc_tx_0;
> }
>
> - cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
> + cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
>
> if (!cfspi->xfer.va_rx) {
> res = -ENODEV;
> @@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
> return 0;
>
> err_create_wq:
> - dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> + dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> err_dma_alloc_rx:
> - dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> + dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> err_dma_alloc_tx_0:
> return res;
> }
> @@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
>
> cfspi->ndev = NULL;
> /* Free DMA buffers. */
> - dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> - dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> + dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> + dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> set_bit(SPI_TERMINATE, &cfspi->state);
> wake_up_interruptible(&cfspi->wait);
> destroy_workqueue(cfspi->wq);
>
^ permalink raw reply
* Re: [PATCH 0/1] add MDIO bus multiplexer driven by a regmap device
From: Andrew Lunn @ 2019-02-01 13:48 UTC (permalink / raw)
To: Pankaj Bansal; +Cc: Florian Fainelli, netdev@vger.kernel.org, Varun Sethi
In-Reply-To: <VI1PR0401MB2496E23B983AB083A6A7E4F1F1920@VI1PR0401MB2496.eurprd04.prod.outlook.com>
> This is not a new driver for a device. Which is why there is no compatible field that I have used in these APIs.
> Should I create a new binding document for it ?
Yes, you always need to document the binding.
Andrew
^ permalink raw reply
* Re: [PATCH v2 bpf-next] bpf: add optional memory accounting for maps
From: Martynas @ 2019-02-01 13:40 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, ys114321, ast, daniel, Yonghong Song
In-Reply-To: <20190131120407.3ebaee11@cakuba.hsd1.ca.comcast.net>
On Thu, Jan 31, 2019, at 10:04 PM, Jakub Kicinski wrote:
> On Thu, 31 Jan 2019 10:38:01 +0100, Martynas Pumputis wrote:
> > Previously, memory allocated for a map was not accounted. Therefore,
> > this memory could not be taken into consideration by the cgroups
> > memory controller.
> >
> > This patch introduces the "BPF_F_ACCOUNT_MEM" flag which enables
> > the memory accounting for a map, and it can be set during
> > the map creation ("BPF_MAP_CREATE") in "map_flags".
>
> What should happen for no-prealloc maps?
I wanted to be consistent with "bpf_map_precharge_memlock". So, as such map elements are not charged against RLIMIT_MEMLOCK, I haven't enabled accounting for them (yet).
> Would it make some sense to
> charge the max map size to the user and not each allocation?
Hmm, but that would not reflect a real memory usage, and it could potentially lead to some troubles. E.g. a process with tight cgroup mem limits gets OOM'd because we have pre-charged for what it actually doesn't use.
> Or
> perhaps remember the owner to be able to charge the data path
> allocations which don't happen in process context as well?
In use cases I am aware of all map updates happen within the same context, i.e. in the same cgroup. So, that cgroup becomes the "owner" of the allocations.
Another issue is when we pin a map (regardless whether it was prealloc'd or not). In this case, if a process which created the map
gets restarted and continues to use the map, then it is not being charged. But as long as the process runs in the same cgroup, it should be fine.
^ permalink raw reply
* Re: [PATCH 05/18] macb_main: pass struct device to DMA API functions
From: Nicolas.Ferre @ 2019-02-01 13:34 UTC (permalink / raw)
To: hch, john, vkoul, dmitry.tarnyagin, sudipm.mukherjee, balbi,
linux-mips, linux-kernel, dmaengine, netdev, linux-usb,
linux-fbdev, alsa-devel
Cc: iommu
In-Reply-To: <20190201084801.10983-6-hch@lst.de>
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 2b2882615e8b..61a27963f1d1 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
> /* Store packet information (to free when Tx completed) */
> lp->skb = skb;
> lp->skb_length = skb->len;
> - lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
> - DMA_TO_DEVICE);
> - if (dma_mapping_error(NULL, lp->skb_physaddr)) {
> + lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
> + skb->len, DMA_TO_DEVICE);
> + if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
> dev_kfree_skb_any(skb);
> dev->stats.tx_dropped++;
> netdev_err(dev, "%s: DMA mapping error\n", __func__);
> @@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
> if (lp->skb) {
> dev_kfree_skb_irq(lp->skb);
> lp->skb = NULL;
> - dma_unmap_single(NULL, lp->skb_physaddr,
> + dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
> lp->skb_length, DMA_TO_DEVICE);
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += lp->skb_length;
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [RFC PATCH net-next 1/6 v2] net/sched: Introduce act_ct
From: Marcelo Leitner @ 2019-02-01 13:23 UTC (permalink / raw)
To: Paul Blakey
Cc: Guy Shattah, Aaron Conole, John Hurley, Simon Horman,
Justin Pettit, Gregory Rose, Eelco Chaudron, Flavio Leitner,
Florian Westphal, Jiri Pirko, Rashid Khan, Sushil Kulkarni,
Andy Gospodarek, Roi Dayan, Yossi Kuperman, Or Gerlitz,
Rony Efraim, davem@davemloft.net, netdev
In-Reply-To: <1548748926-23822-2-git-send-email-paulb@mellanox.com>
On Tue, Jan 29, 2019 at 10:02:01AM +0200, Paul Blakey wrote:
...
> diff --git a/include/uapi/linux/tc_act/tc_ct.h b/include/uapi/linux/tc_act/tc_ct.h
> new file mode 100644
> index 0000000..6dbd771
> --- /dev/null
> +++ b/include/uapi/linux/tc_act/tc_ct.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef __UAPI_TC_CT_H
> +#define __UAPI_TC_CT_H
> +
> +#include <linux/types.h>
> +#include <linux/pkt_cls.h>
> +
> +#define TCA_ACT_CT 18
> +
> +struct tc_ct {
> + tc_gen;
> + __u16 zone;
> + __u32 labels[4];
> + __u32 labels_mask[4];
> + __u32 mark;
> + __u32 mark_mask;
> + bool commit;
This is one of the points that our implementations differs. You used a
struct and wrapped it into TCA_CT_PARMS attribute, while I broke it up
into several attributes.
cls_flower and act_bpf, for example, doesn't use structs, but others
do.
Both have pros and cons and I imagine this topic probably was already
discussed but I'm not aware of a recommendation. Do we have one?
> +};
> +
> +enum {
> + TCA_CT_UNSPEC,
> + TCA_CT_PARMS,
> + TCA_CT_TM,
> + TCA_CT_PAD,
> + __TCA_CT_MAX
> +};
> +#define TCA_CT_MAX (__TCA_CT_MAX - 1)
> +
> +#endif /* __UAPI_TC_CT_H */
...
^ permalink raw reply
* Re: [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions
From: Felipe Balbi @ 2019-02-01 13:20 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
In-Reply-To: <20190201084801.10983-14-hch@lst.de>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
Christoph Hellwig <hch@lst.de> writes:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
In case you're taking the entire series:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
From: Felipe Balbi @ 2019-02-01 13:19 UTC (permalink / raw)
To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
Cc: iommu
In-Reply-To: <20190201084801.10983-13-hch@lst.de>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
Christoph Hellwig <hch@lst.de> writes:
> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
> ---
> drivers/usb/gadget/udc/fotg210-udc.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
> index bc6abaea907d..fe9cf415f2f1 100644
> --- a/drivers/usb/gadget/udc/fotg210-udc.c
> +++ b/drivers/usb/gadget/udc/fotg210-udc.c
> @@ -356,10 +356,6 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
> return;
> }
>
> - dma_sync_single_for_device(NULL, d, length,
> - ep->dir_in ? DMA_TO_DEVICE :
> - DMA_FROM_DEVICE);
> -
> fotg210_enable_dma(ep, d, length);
>
> /* check if dma is done */
> --
> 2.20.1
>
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
From: Takashi Iwai @ 2019-02-01 13:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
In-Reply-To: <20190201084801.10983-1-hch@lst.de>
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
>
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various other attributes.
>
> This series contains all easy conversions to pass a struct device,
> besides that there also is some arch code that needs separate handling,
> a driver that should not use the DMA API at all, and one that is
> a complete basket case to be deal with separately.
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: isa: Avoid passing NULL to memory allocators
We used to pass NULL to memory allocators for ISA devices due to
historical reasons. But we prefer rather a proper device object to be
assigned, so let's fix it by replacing snd_dma_isa_data() call with
card->dev reference, and kill snd_dma_isa_data() definition.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 10 +++++-----
include/sound/memalloc.h | 1 -
sound/isa/ad1816a/ad1816a_lib.c | 2 +-
sound/isa/cmi8330.c | 2 +-
sound/isa/es1688/es1688_lib.c | 2 +-
sound/isa/es18xx.c | 2 +-
sound/isa/gus/gus_pcm.c | 4 ++--
sound/isa/sb/sb16_main.c | 2 +-
sound/isa/sb/sb8_main.c | 2 +-
sound/isa/sscape.c | 7 ++++---
sound/isa/wss/wss_lib.c | 2 +-
11 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 7c2f2032d30a..6b154dbb02cc 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -3520,14 +3520,14 @@ allocator will try to get an area as large as possible within the
given size.
The second argument (type) and the third argument (device pointer) are
-dependent on the bus. In the case of the ISA bus, pass
-:c:func:`snd_dma_isa_data()` as the third argument with
+dependent on the bus. For normal devices, pass the device pointer
+(typically identical as ``card->dev``) to the third argument with
``SNDRV_DMA_TYPE_DEV`` type. For the continuous buffer unrelated to the
bus can be pre-allocated with ``SNDRV_DMA_TYPE_CONTINUOUS`` type and the
``snd_dma_continuous_data(GFP_KERNEL)`` device pointer, where
-``GFP_KERNEL`` is the kernel allocation flag to use. For the PCI
-scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with
-``snd_dma_pci_data(pci)`` (see the `Non-Contiguous Buffers`_
+``GFP_KERNEL`` is the kernel allocation flag to use. For the
+scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with the device
+pointer (see the `Non-Contiguous Buffers`_
section).
Once the buffer is pre-allocated, you can use the allocator in the
diff --git a/include/sound/memalloc.h b/include/sound/memalloc.h
index af3fa577fa06..1ac0dd82a916 100644
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -37,7 +37,6 @@ struct snd_dma_device {
};
#define snd_dma_pci_data(pci) (&(pci)->dev)
-#define snd_dma_isa_data() NULL
#define snd_dma_continuous_data(x) ((struct device *)(__force unsigned long)(x))
diff --git a/sound/isa/ad1816a/ad1816a_lib.c b/sound/isa/ad1816a/ad1816a_lib.c
index 61e8c7e524db..94b381a78e9e 100644
--- a/sound/isa/ad1816a/ad1816a_lib.c
+++ b/sound/isa/ad1816a/ad1816a_lib.c
@@ -693,7 +693,7 @@ int snd_ad1816a_pcm(struct snd_ad1816a *chip, int device)
snd_ad1816a_init(chip);
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ chip->card->dev,
64*1024, chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
chip->pcm = pcm;
diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c
index 7e5aa06414c4..1868b73aa49c 100644
--- a/sound/isa/cmi8330.c
+++ b/sound/isa/cmi8330.c
@@ -470,7 +470,7 @@ static int snd_cmi8330_pcm(struct snd_card *card, struct snd_cmi8330 *chip)
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->streams[SNDRV_PCM_STREAM_CAPTURE].ops);
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 128*1024);
chip->pcm = pcm;
diff --git a/sound/isa/es1688/es1688_lib.c b/sound/isa/es1688/es1688_lib.c
index 50cdce0e8946..da341969e650 100644
--- a/sound/isa/es1688/es1688_lib.c
+++ b/sound/isa/es1688/es1688_lib.c
@@ -746,7 +746,7 @@ int snd_es1688_pcm(struct snd_card *card, struct snd_es1688 *chip, int device)
chip->pcm = pcm;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 64*1024);
return 0;
}
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 77aa9a27fb3b..07abc7f7840c 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1717,7 +1717,7 @@ static int snd_es18xx_pcm(struct snd_card *card, int device)
chip->pcm = pcm;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024,
chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
return 0;
diff --git a/sound/isa/gus/gus_pcm.c b/sound/isa/gus/gus_pcm.c
index 131b28997e1d..b9efc6dff45d 100644
--- a/sound/isa/gus/gus_pcm.c
+++ b/sound/isa/gus/gus_pcm.c
@@ -891,7 +891,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)
for (substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream; substream; substream = substream->next)
snd_pcm_lib_preallocate_pages(substream, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, gus->gf1.dma1 > 3 ? 128*1024 : 64*1024);
pcm->info_flags = 0;
@@ -901,7 +901,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)
if (gus->gf1.dma2 == gus->gf1.dma1)
pcm->info_flags |= SNDRV_PCM_INFO_HALF_DUPLEX;
snd_pcm_lib_preallocate_pages(pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream,
- SNDRV_DMA_TYPE_DEV, snd_dma_isa_data(),
+ SNDRV_DMA_TYPE_DEV, card->dev,
64*1024, gus->gf1.dma2 > 3 ? 128*1024 : 64*1024);
}
strcpy(pcm->name, pcm->id);
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
index 981d65d122b6..473ec74ae48c 100644
--- a/sound/isa/sb/sb16_main.c
+++ b/sound/isa/sb/sb16_main.c
@@ -889,7 +889,7 @@ int snd_sb16dsp_pcm(struct snd_sb *chip, int device)
}
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, 128*1024);
return 0;
}
diff --git a/sound/isa/sb/sb8_main.c b/sound/isa/sb/sb8_main.c
index 8288fae90085..97645a732a71 100644
--- a/sound/isa/sb/sb8_main.c
+++ b/sound/isa/sb/sb8_main.c
@@ -610,7 +610,7 @@ int snd_sb8dsp_pcm(struct snd_sb *chip, int device)
if (chip->dma8 > 3 || chip->dma16 >= 0)
max_prealloc = 128 * 1024;
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ card->dev,
64*1024, max_prealloc);
return 0;
diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
index 733adee5afbf..8181db4db019 100644
--- a/sound/isa/sscape.c
+++ b/sound/isa/sscape.c
@@ -167,12 +167,13 @@ static inline struct soundscape *get_card_soundscape(struct snd_card *c)
* I think this means that the memory has to map to
* contiguous pages of physical memory.
*/
-static struct snd_dma_buffer *get_dmabuf(struct snd_dma_buffer *buf,
+static struct snd_dma_buffer *get_dmabuf(struct soundscape *s,
+ struct snd_dma_buffer *buf,
unsigned long size)
{
if (buf) {
if (snd_dma_alloc_pages_fallback(SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ s->chip->card->dev,
size, buf) < 0) {
snd_printk(KERN_ERR "sscape: Failed to allocate "
"%lu bytes for DMA\n",
@@ -443,7 +444,7 @@ static int upload_dma_data(struct soundscape *s, const unsigned char *data,
int ret;
unsigned char val;
- if (!get_dmabuf(&dma, PAGE_ALIGN(32 * 1024)))
+ if (!get_dmabuf(s, &dma, PAGE_ALIGN(32 * 1024)))
return -ENOMEM;
spin_lock_irqsave(&s->lock, flags);
diff --git a/sound/isa/wss/wss_lib.c b/sound/isa/wss/wss_lib.c
index b11ef97bce1b..0dfb8065b403 100644
--- a/sound/isa/wss/wss_lib.c
+++ b/sound/isa/wss/wss_lib.c
@@ -1942,7 +1942,7 @@ int snd_wss_pcm(struct snd_wss *chip, int device)
strcpy(pcm->name, snd_wss_chip_id(chip));
snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- snd_dma_isa_data(),
+ chip->card->dev,
64*1024, chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
chip->pcm = pcm;
--
2.16.4
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 18/18] ALSA: pass struct device to DMA API functions
From: Takashi Iwai @ 2019-02-01 13:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
In-Reply-To: <20190201084801.10983-19-hch@lst.de>
On Fri, 01 Feb 2019 09:48:01 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
> allocation, as we should treat this allocation as a normal kernel one.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
thanks,
Takashi
^ permalink raw reply
* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
From: Takashi Iwai @ 2019-02-01 13:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu
In-Reply-To: <20190201084801.10983-18-hch@lst.de>
On Fri, 01 Feb 2019 09:48:00 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good to me:
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Shall I take this one through sound git tree or all through yours?
thanks,
Takashi
^ permalink raw reply
* Re: [PATCH] wireless: prefix header search paths with $(srctree)/
From: Kalle Valo @ 2019-02-01 12:43 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-wireless, Masahiro Yamada, brcm80211-dev-list.pdl,
Franky Lin, Intel Linux Wireless, Luca Coelho, Johannes Berg,
netdev, Emmanuel Grumbach, Chi-Hsien Lin, Hin-Tak Leung,
Larry Finger, Herton Ronaldo Krzesinski, Hante Meuleman,
Wright Feng, Arend van Spriel, brcm80211-dev-list, linux-kernel,
David S. Miller
In-Reply-To: <1548429480-22137-1-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
>
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
>
> I also removed one header search path in:
>
> drivers/net/wireless/broadcom/brcm80211/brcmutil/Makefile
>
> I was able to compile without it.
>
> [1]: https://patchwork.kernel.org/patch/9632347/
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Acked-by: Luca Coelho <luciano.coelho@intel.com>
Patch applied to wireless-drivers-next.git, thanks.
030b43671ae8 wireless: prefix header search paths with $(srctree)/
--
https://patchwork.kernel.org/patch/10781533/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCHv2 net] sctp: check and update stream->out_curr when allocating stream_out
From: Neil Horman @ 2019-02-01 12:31 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190201003941.GD10665@localhost.localdomain>
On Thu, Jan 31, 2019 at 10:39:41PM -0200, Marcelo Ricardo Leitner wrote:
> On Tue, Jan 29, 2019 at 07:58:07PM +0100, Tuxdriver wrote:
> > I was initially under the impression that with Kent's repost, the radixtree
> > (which is what I think you meant by rhashtables) updates would be merged
>
> Oops! Yep.. I had meant flex_arrays actually.
>
> > imminently, but that doesn't seem to be the case. I'd really like to know
> > what the hold up there is, as that patch seems to have been stalled for
> > months. I hate the notion of breaking the radixtree patch, but if it's
> > status is indeterminate, then, yes, we probably need to go with xins patch
> > for the short term, and let Kent fix it up in due course.
>
> Dave, can you please consider applying this patch? The conflict
> resolution will be easy: just ignore the changes introduced by this
> patch.
>
Dave I concur with Marcelo here. Kent was very active in getting sctp fixed up
to use radixtrees, but now he seems to have gone to ground, and for whatever
reason, no one seems interested in incorporating his patch. Its been languising
for months, so I think we need to take action to secure sctp now until such time
as his genradix changes finally move forward.
Neil
> This is the radixtree converstion:
> https://lwn.net/ml/linux-kernel/20181217131929.11727-1-kent.overstreet@gmail.com/
> Seems that went to a limbo after
> https://lwn.net/ml/linux-kernel/20181217210021.GA7144@kmo-pixel/
> Maybe Kent should have reposted, but he didn't reply either.
>
> My reasoning is below. Just please also notice that this is
> triggerable by users and remotely, as remote peers may request to add
> 'in' streams and that implies in adding 'out' streams on local peer.
> (https://tools.ietf.org/html/rfc6525#section-5.2.6)
>
> >
> > Neil
> >
> > On January 29, 2019 1:06:33 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> >
> > > On Thu, Nov 29, 2018 at 02:42:56PM +0800, Xin Long wrote:
> > > > Now when using stream reconfig to add out streams, stream->out
> > > > will get re-allocated, and all old streams' information will
> > > > be copied to the new ones and the old ones will be freed.
> > > >
> > > > So without stream->out_curr updated, next time when trying to
> > > > send from stream->out_curr stream, a panic would be caused.
> > > >
> > > > This patch is to check and update stream->out_curr when
> > > > allocating stream_out.
> > > >
> > > > v1->v2:
> > > > - define fa_index() to get elem index from stream->out_curr.
> > > >
> > > > Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations")
> > > > Reported-by: Ying Xu <yinxu@redhat.com>
> > > > Reported-by: syzbot+e33a3a138267ca119c7d@syzkaller.appspotmail.com
> > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > >
> > > We are sort of mixing things up here. We have a bug on SCTP stack that
> > > triggers panics. As good practices recommends, the code should be as
> > > generic as possible and the SCTP-only was dropped in favor of a more
> > > generic one, fixing rhashtables instead. Okay. But then we discovered
> > > rhashtables are going away and we are now waiting on a restructing
> > > to fix the panic. That's not good, especially because it cannot and
> > > should not be backported into -stable trees.
> > >
> > > That said, we should not wait for the restructuring to _implicitly_
> > > fix the bug. We should pursuit both fixes here:
> > > - Apply this patch, to fix SCTP stack and allow it to be easily
> > > backportable.
> > > - Apply the generic fix, which is the restructuring, whenever it
> > > actually lands.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Marcelo
> >
> >
> > Sent with AquaMail for Android
> > https://www.mobisystems.com/aqua-mail
> >
> >
>
^ permalink raw reply
* Re: [PATCH] wlcore: clean up an indentation issue
From: Kalle Valo @ 2019-02-01 12:27 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, Tony Lindgren, linux-wireless, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190118231231.31577-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a goto statement that is missing a tab for indentation. Fix this.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Patch applied to wireless-drivers-next.git, thanks.
112ec26fcdc5 wlcore: clean up an indentation issue
--
https://patchwork.kernel.org/patch/10771801/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wireless: remove unneeded semicolon
From: Kalle Valo @ 2019-02-01 12:26 UTC (permalink / raw)
To: YueHaibing
Cc: davem, arend.vanspriel, franky.lin, chi-hsien.lin, pkshih,
linux-kernel, netdev, ath10k, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, YueHaibing
In-Reply-To: <20190118033215.5904-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> remove unneeded semicolon
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
> Acked-by: Steve deRosier <derosier@cal-sierra.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
999eb686aa90 wireless: remove unneeded semicolon
--
https://patchwork.kernel.org/patch/10769393/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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