* Re: nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Justin Bronder @ 2016-12-20 19:13 UTC (permalink / raw)
To: Mark Greer
Cc: Geoff Lansberry, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaret Cantu
In-Reply-To: <20161220185905.GA5867-luAo+O/VEmrlveNOaEYElw@public.gmane.org>
On 20/12/16 11:59 -0700, Mark Greer wrote:
> On Tue, Dec 20, 2016 at 11:16:32AM -0500, Geoff Lansberry wrote:
> > From: Jaret Cantu <jaret.cantu-jEh4hwF5bVhBDgjK7y7TUQ@public.gmane.org>
> >
> > Repeated polling attempts cause a NULL dereference error to occur.
> > This is because the state of the trf7970a is currently reading but
> > another request has been made to send a command before it has finished.
>
> How is this happening? Was trf7970a_abort_cmd() called and it didn't
> work right? Was it not called at all and there is a bug in the digital
> layer? More details please.
>
> > The solution is to properly kill the waiting reading (workqueue)
> > before failing on the send.
>
> If the bug is in the calling code, then that is what should get fixed.
> This seems to be a hack to work-around a digital layer bug.
One of our uses of NFC is to begin polling to read a tag and then stop polling
(in order to save power) until we know via user interaction that we need to poll
again. This is typically many minutes later so the power saving is pretty
significant. However, it's possible that a user will remove the tag before
reading has completed. We also detect this case and stop polling. I can go
more into this if necessary but that is what exposed a panic.
You can reproduce using neard and python, in our testing it was very likely to
occur in 10-100 iterations of the following.:
#!/usr/bin/python
import time
import dbus
bus = dbus.SystemBus()
nfc0 = bus.get_object('org.neard', '/org/neard/nfc0')
props = dbus.Interface(nfc0, 'org.freedesktop.DBus.Properties')
try:
props.Set('org.neard.Adapter', 'Powered', dbus.Boolean(1))
except:
pass
adapter = dbus.Interface(nfc0, 'org.neard.Adapter')
for i in range(1000):
adapter.StartPollLoop('Initiator')
time.sleep(0.1)
adapter.StopPollLoop()
print(i)
I believe the last time we tested this was around the 4.1 release.
--
Justin Bronder
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] net: hix5hd2_gmac: keep the compatible string not changed
From: David Miller @ 2016-12-20 19:13 UTC (permalink / raw)
To: lidongpo
Cc: robh+dt, mark.rutland, linux, yisen.zhuang, salil.mehta, arnd,
andrew, xuejiancheng, benjamin.chenhao, caizhiyong, netdev,
devicetree, linux-kernel
In-Reply-To: <1482199769-106501-1-git-send-email-lidongpo@hisilicon.com>
From: Dongpo Li <lidongpo@hisilicon.com>
Date: Tue, 20 Dec 2016 10:09:27 +0800
> This patch series fix the patch:
> d0fb6ba75dc0 ("net: hix5hd2_gmac: add generic compatible string")
>
> The SoC hix5hd2 compatible string has the suffix "-gmac" and
> we should not change its compatible string.
> So we should name all the compatible string with the suffix "-gmac".
> Creating a new name suffix "-gemac" is unnecessary.
Series applied.
^ permalink raw reply
* Re: [PATCH net] openvswitch: Add a missing break statement.
From: David Miller @ 2016-12-20 19:08 UTC (permalink / raw)
To: jarno; +Cc: netdev, jbenc, pshelar
In-Reply-To: <1482195993-97937-1-git-send-email-jarno@ovn.org>
From: Jarno Rajahalme <jarno@ovn.org>
Date: Mon, 19 Dec 2016 17:06:33 -0800
> Add a break statement to prevent fall-through from
> OVS_KEY_ATTR_ETHERNET to OVS_KEY_ATTR_TUNNEL. Without the break
> actions setting ethernet addresses fail to validate with log messages
> complaining about invalid tunnel attributes.
>
> Fixes: 0a6410fbde ("openvswitch: netlink: support L3 packets")
> Signed-off-by: Jarno Rajahalme <jarno@ovn.org>
> Acked-by: Pravin B Shelar <pshelar@ovn.org>
> Acked-by: Jiri Benc <jbenc@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/2] net: netcp: ethss: fix 10gbe host port tx pri map configuration
From: David Miller @ 2016-12-20 19:08 UTC (permalink / raw)
To: m-karicheri2; +Cc: netdev, linux-kernel
In-Reply-To: <1482188157-24490-2-git-send-email-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Mon, 19 Dec 2016 17:55:57 -0500
> From: WingMan Kwok <w-kwok2@ti.com>
>
> This patch adds the missing 10gbe host port tx priority map
> configurations.
>
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/2] net: netcp: ethss: fix errors in ethtool ops
From: David Miller @ 2016-12-20 19:08 UTC (permalink / raw)
To: m-karicheri2; +Cc: netdev, linux-kernel
In-Reply-To: <1482188157-24490-1-git-send-email-m-karicheri2@ti.com>
From: Murali Karicheri <m-karicheri2@ti.com>
Date: Mon, 19 Dec 2016 17:55:56 -0500
> From: WingMan Kwok <w-kwok2@ti.com>
>
> In ethtool ops, it needs to retrieve the corresponding
> ethss module (gbe or xgbe) from the net_device structure.
> Prior to this patch, the retrieving procedure only
> checks for the gbe module. This patch fixes the issue
> by checking the xgbe module if the net_device structure
> does not correspond to the gbe module.
>
> Signed-off-by: WingMan Kwok <w-kwok2@ti.com>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Applied.
^ permalink raw reply
* Re: [PATCH net v4 0/4] fsl/fman: fixes for ARM
From: David Miller @ 2016-12-20 19:00 UTC (permalink / raw)
To: madalin.bucur; +Cc: netdev, linuxppc-dev, linux-kernel, scott.wood
In-Reply-To: <1482180166-10677-1-git-send-email-madalin.bucur@nxp.com>
From: Madalin Bucur <madalin.bucur@nxp.com>
Date: Mon, 19 Dec 2016 22:42:42 +0200
> The patch set fixes advertised speeds for QSGMII interfaces, disables
> A007273 erratum workaround on non-PowerPC platforms where it does not
> apply, enables compilation on ARM64 and addresses a probing issue on
> non PPC platforms.
>
> Changes from v3: removed redundant comment, added ack by Scott
> Changes from v2: merged fsl/fman changes to avoid a point of failure
> Changes from v1: unifying probing on all supported platforms
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-20 18:59 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin,
Jaret Cantu
In-Reply-To: <1482250592-4268-3-git-send-email-glansberry@gmail.com>
On Tue, Dec 20, 2016 at 11:16:32AM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu@timesys.com>
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.
How is this happening? Was trf7970a_abort_cmd() called and it didn't
work right? Was it not called at all and there is a bug in the digital
layer? More details please.
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
If the bug is in the calling code, then that is what should get fixed.
This seems to be a hack to work-around a digital layer bug.
Mark
--
^ permalink raw reply
* Re: Soft lockup in tc_classify
From: Shahar Klein @ 2016-12-20 6:22 UTC (permalink / raw)
To: Cong Wang
Cc: shahark, Or Gerlitz, Daniel Borkmann, Linux Netdev List,
Roi Dayan, David Miller, Jiri Pirko, John Fastabend,
Hadar Hen Zion
In-Reply-To: <CAM_iQpXUQYvvXonEXe0czd4osL5YxZ+G5B-PUddautcHnGOtQw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]
On 12/19/2016 7:58 PM, Cong Wang wrote:
> Hello,
>
> On Mon, Dec 19, 2016 at 8:39 AM, Shahar Klein <shahark@mellanox.com> wrote:
>>
>>
>> On 12/13/2016 12:51 AM, Cong Wang wrote:
>>>
>>> On Mon, Dec 12, 2016 at 1:18 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>>>
>>>> On Mon, Dec 12, 2016 at 3:28 PM, Daniel Borkmann <daniel@iogearbox.net>
>>>> wrote:
>>>>
>>>>> Note that there's still the RCU fix missing for the deletion race that
>>>>> Cong will still send out, but you say that the only thing you do is to
>>>>> add a single rule, but no other operation in involved during that test?
>>>>
>>>>
>>>> What's missing to have the deletion race fixed? making a patch or
>>>> testing to a patch which was sent?
>>>
>>>
>>> If you think it would help for this problem, here is my patch rebased
>>> on the latest net-next.
>>>
>>> Again, I don't see how it could help this case yet, especially I don't
>>> see how we could have a loop in this singly linked list.
>>>
>>
>> I've applied cong's patch and hit a different lockup(full log attached):
>
>
> Are you sure this is really different? For me, it is still inside the loop
> in tc_classify(), with only a slightly different offset.
>
>
>>
>> Daniel suggested I'll add a print:
>> case RTM_DELTFILTER:
>> - err = tp->ops->delete(tp, fh);
>> + printk(KERN_ERR "DEBUGG:SK %s:%d\n", __func__, __LINE__);
>> + err = tp->ops->delete(tp, fh, &last);
>> if (err == 0) {
>>
>> and I couldn't see this print in the output.....
>
> Hmm, that is odd, if this never prints, then my patch should not make any
> difference.
>
> There are still two other cases where we could change tp->next, so do you
> mind to add two more printk's for debugging?
>
> Attached is the delta patch.
>
> Thanks!
>
I've added a slightly different debug print:
@@ -368,11 +375,12 @@ static int tc_ctl_tfilter(struct sk_buff *skb,
struct nlmsghdr *n)
if (tp_created) {
RCU_INIT_POINTER(tp->next,
rtnl_dereference(*back));
rcu_assign_pointer(*back, tp);
+ printk(KERN_ERR "DEBUGG:SK add/change filter by: %pf
tp=%p tp->next=%p\n", tp->ops->get, tp, tp->next);
}
tfilter_notify(net, skb, n, tp, fh, RTM_NEWTFILTER, false);
full output attached:
[ 283.290271] Mirror/redirect action on
[ 283.305031] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9432d704df60 tp->next= (null)
[ 283.322563] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d240 tp->next= (null)
[ 283.359997] GACT probability on
[ 283.365923] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d3c0 tp->next=ffff9436e718d240
[ 283.378725] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.391310] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.403923] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.416542] DEBUGG:SK add/change filter by: fl_get [cls_flower]
tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 308.538571] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s!
[swapper/0:0]
Thanks
Shahar
[-- Attachment #2: tp_p_debug.log --]
[-- Type: text/plain, Size: 18431 bytes --]
[ 283.290271] Mirror/redirect action on
[ 283.305031] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9432d704df60 tp->next= (null)
[ 283.322563] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d240 tp->next= (null)
[ 283.359997] GACT probability on
[ 283.365923] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d3c0 tp->next=ffff9436e718d240
[ 283.378725] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.391310] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.403923] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 283.416542] DEBUGG:SK add/change filter by: fl_get [cls_flower] tp=ffff9436e718d3c0 tp->next=ffff9436e718d3c0
[ 308.538571] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [swapper/0:0]
[ 308.547322] Modules linked in: act_gact act_mirred openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 vfio_pci vfio_virqfd vfio_iommu_type1 vfio cls_flower mlx5_ib mlx5_core devlink sch_ingress nfsv3 nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun ebtable_filter ebtables ip6table_filter ip6_tables netconsole rpcrdma bridge ib_isert stp iscsi_target_mod llc ib_iser libiscsi scsi_transport_iscsi ib_srpt ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp kvm_intel kvm igb irqbypass joydev ipmi_ssif crct10dif_pclmul crc32_pclmul iTCO_wdt crc32c_intel ptp ipmi_si iTCO_vendor_support pcspkr ghash_clmulni_intel wmi pps_core i2c_algo_bit ipmi_msghandler mei_me i2c_i801 ioatdma tpm_tis mei shpchp i2c_smbus dca tpm_tis_core lpc_ich tpm nfsd target_core_mod auth_rpcgss nfs_acl lockd grace sunrpc isci libsas serio_raw scsi_transport_sas [last unloaded: devlink]
[ 308.668291] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0+ #31
[ 308.675337] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 308.683060] task: ffffffff94e0e500 task.stack: ffffffff94e00000
[ 308.690012] RIP: 0010:fl_classify+0xb/0x2b0 [cls_flower]
[ 308.696275] RSP: 0018:ffff9432efa03c20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 308.705396] RAX: 0000000000000008 RBX: ffff9432b59c4100 RCX: 0000000000000000
[ 308.713704] RDX: ffff9432efa03c98 RSI: ffff9436e718d3c0 RDI: ffff9432b59c4100
[ 308.722099] RBP: ffff9432efa03c28 R08: 000000000000270f R09: 0000000000000000
[ 308.730409] R10: 0000000000000000 R11: 0000000000000004 R12: ffff9432efa03c98
[ 308.738713] R13: 0000000000000008 R14: ffff9436e718d3c0 R15: 0000000000000001
[ 308.747013] FS: 0000000000000000(0000) GS:ffff9432efa00000(0000) knlGS:0000000000000000
[ 308.756625] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 308.763378] CR2: 00007f5415f67914 CR3: 00000005fde07000 CR4: 00000000000426f0
[ 308.771684] Call Trace:
[ 308.774739] <IRQ>
[ 308.777311] tc_classify+0x78/0x120
[ 308.781549] __netif_receive_skb_core+0x623/0xa00
[ 308.787141] ? udp4_gro_receive+0x10b/0x2d0
[ 308.792143] __netif_receive_skb+0x18/0x60
[ 308.797048] netif_receive_skb_internal+0x40/0xb0
[ 308.802637] napi_gro_receive+0xcd/0x120
[ 308.807462] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 308.814123] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 308.820015] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 308.825818] net_rx_action+0x260/0x3c0
[ 308.830334] __do_softirq+0xc9/0x28c
[ 308.834658] irq_exit+0xd7/0xe0
[ 308.838492] do_IRQ+0x51/0xd0
[ 308.842132] common_interrupt+0x93/0x93
[ 308.846747] RIP: 0010:cpuidle_enter_state+0xe1/0x260
[ 308.852624] RSP: 0018:ffffffff94e03dc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffa2
[ 308.861766] RAX: ffff9432efa19600 RBX: ffff9432efa23600 RCX: 000000000000001f
[ 308.870077] RDX: 0000000000000000 RSI: ffff9432efa16cd8 RDI: 0000000000000000
[ 308.878379] RBP: ffffffff94e03e00 R08: 0000000000000001 R09: cccccccccccccccd
[ 308.886690] R10: 0000000000000000 R11: 0000000000000008 R12: 0000000000000001
[ 308.895000] R13: 0000000000000000 R14: ffffffff94ec79a0 R15: 00000041fab01c8d
[ 308.903306] </IRQ>
[ 308.905978] ? cpuidle_enter_state+0xc0/0x260
[ 308.911173] cpuidle_enter+0x17/0x20
[ 308.915498] call_cpuidle+0x23/0x40
[ 308.919721] do_idle+0x172/0x200
[ 308.923656] cpu_startup_entry+0x71/0x80
[ 308.928370] rest_init+0x77/0x80
[ 308.932304] start_kernel+0x4a6/0x4c7
[ 308.936723] ? set_init_arg+0x55/0x55
[ 308.941141] ? early_idt_handler_array+0x120/0x120
[ 308.946823] x86_64_start_reservations+0x24/0x26
[ 308.952314] x86_64_start_kernel+0x14c/0x16f
[ 308.957418] start_cpu+0x5/0x14
[ 308.961242] Code: a8 4c 89 fe 48 8b 4d c8 48 8d 14 07 4c 89 e7 e8 2c fe ff ff e9 14 ff ff ff 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 <41> 56 41 55 41 54 53 48 81 ec 28 01 00 00 65 48 8b 04 25 28 00
[ 308.989075] Kernel panic - not syncing: softlockup: hung tasks
[ 308.995924] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L 4.9.0+ #31
[ 309.010442] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 309.018160] Call Trace:
[ 309.021211] <IRQ>
[ 309.023776] dump_stack+0x63/0x8c
[ 309.027807] panic+0xeb/0x239
[ 309.031449] watchdog_timer_fn+0x1e5/0x1f0
[ 309.036354] ? watchdog+0x40/0x40
[ 309.040386] __hrtimer_run_queues+0xee/0x270
[ 309.045486] hrtimer_interrupt+0xa8/0x190
[ 309.050293] local_apic_timer_interrupt+0x35/0x60
[ 309.055880] smp_apic_timer_interrupt+0x38/0x50
[ 309.061272] apic_timer_interrupt+0x93/0xa0
[ 309.066272] RIP: 0010:fl_classify+0xb/0x2b0 [cls_flower]
[ 309.072538] RSP: 0018:ffff9432efa03c20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 309.081686] RAX: 0000000000000008 RBX: ffff9432b59c4100 RCX: 0000000000000000
[ 309.089994] RDX: ffff9432efa03c98 RSI: ffff9436e718d3c0 RDI: ffff9432b59c4100
[ 309.098297] RBP: ffff9432efa03c28 R08: 000000000000270f R09: 0000000000000000
[ 309.106603] R10: 0000000000000000 R11: 0000000000000004 R12: ffff9432efa03c98
[ 309.114914] R13: 0000000000000008 R14: ffff9436e718d3c0 R15: 0000000000000001
[ 309.123229] tc_classify+0x78/0x120
[ 309.127452] __netif_receive_skb_core+0x623/0xa00
[ 309.133031] ? udp4_gro_receive+0x10b/0x2d0
[ 309.138033] __netif_receive_skb+0x18/0x60
[ 309.142949] netif_receive_skb_internal+0x40/0xb0
[ 309.148534] napi_gro_receive+0xcd/0x120
[ 309.153259] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 309.159918] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 309.165823] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 309.171608] net_rx_action+0x260/0x3c0
[ 309.176238] __do_softirq+0xc9/0x28c
[ 309.180563] irq_exit+0xd7/0xe0
[ 309.184395] do_IRQ+0x51/0xd0
[ 309.188035] common_interrupt+0x93/0x93
[ 309.192651] RIP: 0010:cpuidle_enter_state+0xe1/0x260
[ 309.198527] RSP: 0018:ffffffff94e03dc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffa2
[ 309.207651] RAX: ffff9432efa19600 RBX: ffff9432efa23600 RCX: 000000000000001f
[ 309.215959] RDX: 0000000000000000 RSI: ffff9432efa16cd8 RDI: 0000000000000000
[ 309.224268] RBP: ffffffff94e03e00 R08: 0000000000000001 R09: cccccccccccccccd
[ 309.232573] R10: 0000000000000000 R11: 0000000000000008 R12: 0000000000000001
[ 309.240881] R13: 0000000000000000 R14: ffffffff94ec79a0 R15: 00000041fab01c8d
[ 309.249187] </IRQ>
[ 309.251858] ? cpuidle_enter_state+0xc0/0x260
[ 309.257057] cpuidle_enter+0x17/0x20
[ 309.261382] call_cpuidle+0x23/0x40
[ 309.265635] do_idle+0x172/0x200
[ 309.269604] cpu_startup_entry+0x71/0x80
[ 309.274314] rest_init+0x77/0x80
[ 309.278247] start_kernel+0x4a6/0x4c7
[ 309.282668] ? set_init_arg+0x55/0x55
[ 309.287089] ? early_idt_handler_array+0x120/0x120
[ 309.292771] x86_64_start_reservations+0x24/0x26
[ 309.298262] x86_64_start_kernel+0x14c/0x16f
[ 309.303361] start_cpu+0x5/0x14
[ 309.307245] Kernel Offset: 0x13000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 310.573997] ---[ end Kernel panic - not syncing: softlockup: hung tasks
[ 310.581734] ------------[ cut here ]------------
[ 310.587236] unchecked MSR access error: WRMSR to 0x83f (tried to write 0x00000000000000f6) at rIP: 0xffffffff94065c14 (native_write_msr+0x4/0x30)
[ 310.602404] Call Trace:
[ 310.605472] <IRQ>
[ 310.608066] ? native_apic_msr_write+0x30/0x40
[ 310.613371] x2apic_send_IPI_self+0x1d/0x20
[ 310.618390] arch_irq_work_raise+0x28/0x40
[ 310.623309] irq_work_queue+0x6e/0x80
[ 310.627724] wake_up_klogd+0x34/0x40
[ 310.632045] console_unlock+0x4dc/0x540
[ 310.636659] vprintk_emit+0x2eb/0x4b0
[ 310.641091] ? native_smp_send_reschedule+0x3f/0x50
[ 310.646871] vprintk_default+0x29/0x40
[ 310.651393] printk+0x5d/0x74
[ 310.655034] ? native_smp_send_reschedule+0x3f/0x50
[ 310.660807] __warn+0x3b/0xf0
[ 310.664450] warn_slowpath_null+0x1d/0x20
[ 310.669262] native_smp_send_reschedule+0x3f/0x50
[ 310.674849] try_to_wake_up+0x312/0x390
[ 310.679456] default_wake_function+0x12/0x20
[ 310.684560] __wake_up_common+0x55/0x90
[ 310.689170] __wake_up_locked+0x13/0x20
[ 310.693788] ep_poll_callback+0xbb/0x240
[ 310.698493] __wake_up_common+0x55/0x90
[ 310.703101] __wake_up+0x39/0x50
[ 310.707028] wake_up_klogd_work_func+0x40/0x60
[ 310.712316] irq_work_run_list+0x4d/0x70
[ 310.717022] irq_work_run+0x2c/0x40
[ 310.721243] smp_irq_work_interrupt+0x2e/0x40
[ 310.726443] irq_work_interrupt+0x93/0xa0
[ 310.731253] RIP: 0010:panic+0x1f5/0x239
[ 310.735876] RSP: 0018:ffff9432efa039e8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff09
[ 310.744995] RAX: 000000000000003b RBX: 0000000000000000 RCX: 0000000000000006
[ 310.753294] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffff9432efa0e060
[ 310.761594] RBP: ffff9432efa03a58 R08: 0000000000000674 R09: ffff942e800bb3e0
[ 310.769900] R10: 00000000000000ef R11: 0000000000000198 R12: ffffffff94c4a4a9
[ 310.778199] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9432efa03b78
[ 310.786505] ? panic+0x1f1/0x239
[ 310.790444] watchdog_timer_fn+0x1e5/0x1f0
[ 310.795353] ? watchdog+0x40/0x40
[ 310.799401] __hrtimer_run_queues+0xee/0x270
[ 310.804501] hrtimer_interrupt+0xa8/0x190
[ 310.809318] local_apic_timer_interrupt+0x35/0x60
[ 310.814895] smp_apic_timer_interrupt+0x38/0x50
[ 310.820282] apic_timer_interrupt+0x93/0xa0
[ 310.825287] RIP: 0010:fl_classify+0xb/0x2b0 [cls_flower]
[ 310.831554] RSP: 0018:ffff9432efa03c20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 310.840693] RAX: 0000000000000008 RBX: ffff9432b59c4100 RCX: 0000000000000000
[ 310.849007] RDX: ffff9432efa03c98 RSI: ffff9436e718d3c0 RDI: ffff9432b59c4100
[ 310.857402] RBP: ffff9432efa03c28 R08: 000000000000270f R09: 0000000000000000
[ 310.865712] R10: 0000000000000000 R11: 0000000000000004 R12: ffff9432efa03c98
[ 310.874020] R13: 0000000000000008 R14: ffff9436e718d3c0 R15: 0000000000000001
[ 310.882337] tc_classify+0x78/0x120
[ 310.886568] __netif_receive_skb_core+0x623/0xa00
[ 310.892157] ? udp4_gro_receive+0x10b/0x2d0
[ 310.897151] __netif_receive_skb+0x18/0x60
[ 310.902057] netif_receive_skb_internal+0x40/0xb0
[ 310.907643] napi_gro_receive+0xcd/0x120
[ 310.912370] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 310.919031] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 310.924924] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 310.930808] net_rx_action+0x260/0x3c0
[ 310.935319] __do_softirq+0xc9/0x28c
[ 310.939658] irq_exit+0xd7/0xe0
[ 310.943485] do_IRQ+0x51/0xd0
[ 310.947124] common_interrupt+0x93/0x93
[ 310.951748] RIP: 0010:cpuidle_enter_state+0xe1/0x260
[ 310.957616] RSP: 0018:ffffffff94e03dc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffa2
[ 310.966743] RAX: ffff9432efa19600 RBX: ffff9432efa23600 RCX: 000000000000001f
[ 310.975044] RDX: 0000000000000000 RSI: ffff9432efa16cd8 RDI: 0000000000000000
[ 310.983349] RBP: ffffffff94e03e00 R08: 0000000000000001 R09: cccccccccccccccd
[ 310.991654] R10: 0000000000000000 R11: 0000000000000008 R12: 0000000000000001
[ 310.999952] R13: 0000000000000000 R14: ffffffff94ec79a0 R15: 00000041fab01c8d
[ 311.008254] </IRQ>
[ 311.010926] ? cpuidle_enter_state+0xc0/0x260
[ 311.016122] cpuidle_enter+0x17/0x20
[ 311.020430] call_cpuidle+0x23/0x40
[ 311.024658] do_idle+0x172/0x200
[ 311.028583] cpu_startup_entry+0x71/0x80
[ 311.033295] rest_init+0x77/0x80
[ 311.037233] start_kernel+0x4a6/0x4c7
[ 311.041646] ? set_init_arg+0x55/0x55
[ 311.046068] ? early_idt_handler_array+0x120/0x120
[ 311.051752] x86_64_start_reservations+0x24/0x26
[ 311.057238] x86_64_start_kernel+0x14c/0x16f
[ 311.062339] start_cpu+0x5/0x14
[ 311.066180] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/smp.c:127 native_smp_send_reschedule+0x3f/0x50
[ 311.076956] Modules linked in: act_gact act_mirred openvswitch nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 vfio_pci vfio_virqfd vfio_iommu_type1 vfio cls_flower mlx5_ib mlx5_core devlink sch_ingress nfsv3 nfs fscache xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat libcrc32c nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun ebtable_filter ebtables ip6table_filter ip6_tables netconsole rpcrdma bridge ib_isert stp iscsi_target_mod llc ib_iser libiscsi scsi_transport_iscsi ib_srpt ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_core intel_rapl sb_edac edac_core x86_pkg_temp_thermal coretemp kvm_intel kvm igb irqbypass joydev ipmi_ssif crct10dif_pclmul crc32_pclmul iTCO_wdt crc32c_intel ptp ipmi_si iTCO_vendor_support pcspkr ghash_clmulni_intel wmi pps_core i2c_algo_bit ipmi_msghandler mei_me i2c_i801 ioatdma tpm_tis mei shpchp i2c_smbus dca tpm_tis_core lpc_ich tpm nfsd target_core_mod auth_rpcgss nfs_acl lockd grace sunrpc isci libsas serio_raw scsi_transport_sas [last unloaded: devlink]
[ 311.198587] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G L 4.9.0+ #31
[ 311.207253] Hardware name: Supermicro X9DRW/X9DRW, BIOS 3.0a 08/08/2013
[ 311.214983] Call Trace:
[ 311.218051] <IRQ>
[ 311.220626] dump_stack+0x63/0x8c
[ 311.224657] __warn+0xd1/0xf0
[ 311.228298] warn_slowpath_null+0x1d/0x20
[ 311.233116] native_smp_send_reschedule+0x3f/0x50
[ 311.238702] try_to_wake_up+0x312/0x390
[ 311.243318] default_wake_function+0x12/0x20
[ 311.248418] __wake_up_common+0x55/0x90
[ 311.253034] __wake_up_locked+0x13/0x20
[ 311.257641] ep_poll_callback+0xbb/0x240
[ 311.262346] __wake_up_common+0x55/0x90
[ 311.272771] __wake_up+0x39/0x50
[ 311.276697] wake_up_klogd_work_func+0x40/0x60
[ 311.281986] irq_work_run_list+0x4d/0x70
[ 311.286681] irq_work_run+0x2c/0x40
[ 311.290899] smp_irq_work_interrupt+0x2e/0x40
[ 311.296090] irq_work_interrupt+0x93/0xa0
[ 311.300900] RIP: 0010:panic+0x1f5/0x239
[ 311.305508] RSP: 0018:ffff9432efa039e8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff09
[ 311.314630] RAX: 000000000000003b RBX: 0000000000000000 RCX: 0000000000000006
[ 311.322936] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffff9432efa0e060
[ 311.331245] RBP: ffff9432efa03a58 R08: 0000000000000674 R09: ffff942e800bb3e0
[ 311.339543] R10: 00000000000000ef R11: 0000000000000198 R12: ffffffff94c4a4a9
[ 311.347855] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9432efa03b78
[ 311.356167] ? panic+0x1f1/0x239
[ 311.360106] watchdog_timer_fn+0x1e5/0x1f0
[ 311.365004] ? watchdog+0x40/0x40
[ 311.369035] __hrtimer_run_queues+0xee/0x270
[ 311.374132] hrtimer_interrupt+0xa8/0x190
[ 311.378935] local_apic_timer_interrupt+0x35/0x60
[ 311.384511] smp_apic_timer_interrupt+0x38/0x50
[ 311.389897] apic_timer_interrupt+0x93/0xa0
[ 311.394892] RIP: 0010:fl_classify+0xb/0x2b0 [cls_flower]
[ 311.401151] RSP: 0018:ffff9432efa03c20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff10
[ 311.410270] RAX: 0000000000000008 RBX: ffff9432b59c4100 RCX: 0000000000000000
[ 311.418580] RDX: ffff9432efa03c98 RSI: ffff9436e718d3c0 RDI: ffff9432b59c4100
[ 311.426967] RBP: ffff9432efa03c28 R08: 000000000000270f R09: 0000000000000000
[ 311.435278] R10: 0000000000000000 R11: 0000000000000004 R12: ffff9432efa03c98
[ 311.443584] R13: 0000000000000008 R14: ffff9436e718d3c0 R15: 0000000000000001
[ 311.451889] tc_classify+0x78/0x120
[ 311.456105] __netif_receive_skb_core+0x623/0xa00
[ 311.461683] ? udp4_gro_receive+0x10b/0x2d0
[ 311.466687] __netif_receive_skb+0x18/0x60
[ 311.471593] netif_receive_skb_internal+0x40/0xb0
[ 311.477186] napi_gro_receive+0xcd/0x120
[ 311.481900] mlx5e_handle_rx_cqe_rep+0x61b/0x890 [mlx5_core]
[ 311.488555] mlx5e_poll_rx_cq+0x83/0x840 [mlx5_core]
[ 311.494451] mlx5e_napi_poll+0x89/0x480 [mlx5_core]
[ 311.500233] net_rx_action+0x260/0x3c0
[ 311.504751] __do_softirq+0xc9/0x28c
[ 311.509075] irq_exit+0xd7/0xe0
[ 311.512901] do_IRQ+0x51/0xd0
[ 311.516529] common_interrupt+0x93/0x93
[ 311.521143] RIP: 0010:cpuidle_enter_state+0xe1/0x260
[ 311.527011] RSP: 0018:ffffffff94e03dc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffa2
[ 311.536123] RAX: ffff9432efa19600 RBX: ffff9432efa23600 RCX: 000000000000001f
[ 311.544430] RDX: 0000000000000000 RSI: ffff9432efa16cd8 RDI: 0000000000000000
[ 311.552760] RBP: ffffffff94e03e00 R08: 0000000000000001 R09: cccccccccccccccd
[ 311.561087] R10: 0000000000000000 R11: 0000000000000008 R12: 0000000000000001
[ 311.569396] R13: 0000000000000000 R14: ffffffff94ec79a0 R15: 00000041fab01c8d
[ 311.577714] </IRQ>
[ 311.580393] ? cpuidle_enter_state+0xc0/0x260
[ 311.585591] cpuidle_enter+0x17/0x20
[ 311.589913] call_cpuidle+0x23/0x40
[ 311.594136] do_idle+0x172/0x200
[ 311.598069] cpu_startup_entry+0x71/0x80
[ 311.602782] rest_init+0x77/0x80
[ 311.606713] start_kernel+0x4a6/0x4c7
[ 311.611134] ? set_init_arg+0x55/0x55
[ 311.615547] ? early_idt_handler_array+0x120/0x120
[ 311.621231] x86_64_start_reservations+0x24/0x26
[ 311.626717] x86_64_start_kernel+0x14c/0x16f
[ 311.631810] start_cpu+0x5/0x14
[ 311.635648] ---[ end trace c2fd08dd3d93dab3 ]---
^ permalink raw reply
* Re: [PATCH net 0/3] Fix integration of eee-broken-modes
From: David Miller @ 2016-12-20 18:51 UTC (permalink / raw)
To: jbrunet
Cc: netdev, devicetree, f.fainelli, carlo, khilman,
martin.blumenstingl, neolynx, andrew, narmstrong, linux-amlogic,
linux-arm-kernel, linux-kernel, julia.lawall, yegorslists,
afaerber
In-Reply-To: <1482159938-13239-1-git-send-email-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Mon, 19 Dec 2016 16:05:35 +0100
> The purpose of this series is to fix the integration of the ethernet phy
> property "eee-broken-modes" [0]
>
> The v3 of this series has been merged, missing a fix (error reported by
> kbuild robot) available in the v4 [1]
>
> More importantly, Florian opposed adding a DT property mapping a device
> register this directly [2]. The concern was that the property could be
> abused to implement platform configuration policy. After discussing it,
> I think we agreed that such information about the HW (defect) should appear
> in the platform DT. However, the preferred way is to add a boolean property
> for each EEE broken mode.
>
> [0]: http://lkml.kernel.org/r/1480326409-25419-1-git-send-email-jbrunet@baylibre.com
> [1]: http://lkml.kernel.org/r/1480348229-25672-1-git-send-email-jbrunet@baylibre.com
> [2]: http://lkml.kernel.org/r/e14a3b0c-dc34-be14-48b3-518a0ad0c080@gmail.com
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH perf/core REBASE 3/5] tools lib bpf: Add bpf_prog_{attach,detach}
From: Joe Stringer @ 2016-12-20 18:50 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: LKML, netdev, Wang Nan, ast, Daniel Borkmann
In-Reply-To: <20161220143217.GC32756@kernel.org>
On 20 December 2016 at 06:32, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Tue, Dec 20, 2016 at 11:18:51AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Dec 14, 2016 at 02:43:40PM -0800, Joe Stringer escreveu:
>> > Commit d8c5b17f2bc0 ("samples: bpf: add userspace example for attaching
>> > eBPF programs to cgroups") added these functions to samples/libbpf, but
>> > during this merge all of the samples libbpf functionality is shifting to
>> > tools/lib/bpf. Shift these functions there.
>> >
>> > Signed-off-by: Joe Stringer <joe@ovn.org>
>> > ---
>> > Arnaldo, this is a new patch you didn't previously review which I've
>> > prepared due to the conflict with net-next. I figured it's better to try
>> > to get samples/bpf properly switched over this window rather than defer the
>> > problem and end up having to deal with another merge problem next time
>> > around. I hope that is fine for you. If not, this patch onwards will need
>> > to be dropped
>> >
>> > It's a simple copy/paste/delete with a minor change for sys_bpf() vs
>> > syscall().
>> > ---
>> > samples/bpf/libbpf.c | 21 ---------------------
>> > samples/bpf/libbpf.h | 3 ---
>> > tools/lib/bpf/bpf.c | 21 +++++++++++++++++++++
>> > tools/lib/bpf/bpf.h | 3 +++
>> > 4 files changed, 24 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
>> > index 3391225ad7e9..d9af876b4a2c 100644
>> > --- a/samples/bpf/libbpf.c
>> > +++ b/samples/bpf/libbpf.c
>> > @@ -11,27 +11,6 @@
>> > #include <arpa/inet.h>
>> > #include "libbpf.h"
>> >
>> > -int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
>> > -{
>> > - union bpf_attr attr = {
>> > - .target_fd = target_fd,
>> > - .attach_bpf_fd = prog_fd,
>> > - .attach_type = type,
>> > - };
>> > -
>> > - return syscall(__NR_bpf, BPF_PROG_ATTACH, &attr, sizeof(attr));
>>
>> This one makes it fail for CentOS 5 and 6, others may fail as well,
>> still building, investigating...
>
> Ok, fixed it by making it follow the model of the other sys_bpf wrappers
> setting up that bpf_attr union wrt initializing unamed struct members:
>
> int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
> {
> - union bpf_attr attr = {
> - .target_fd = target_fd,
> - .attach_bpf_fd = prog_fd,
> - .attach_type = type,
> - };
> + union bpf_attr attr;
> +
> + bzero(&attr, sizeof(attr));
> + attr.target_fd = target_fd;
> + attr.attach_bpf_fd = prog_fd;
> + attr.attach_type = type;
>
> return sys_bpf(BPF_PROG_ATTACH, &attr, sizeof(attr));
> }
Ah, I just shifted these across originally so the delta would be
minimal but now I know why this code is like this. Thanks.
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Andy Lutomirski @ 2016-12-20 18:49 UTC (permalink / raw)
To: Daniel Mack
Cc: Alexei Starovoitov, Andy Lutomirski, Mickaël Salaün,
Kees Cook, Jann Horn, Tejun Heo, David Ahern, David S. Miller,
Thomas Graf, Michael Kerrisk, Peter Zijlstra, Linux API,
linux-kernel@vger.kernel.org, Network Development
In-Reply-To: <9e378fb1-23ff-a239-d915-3d9aa26a999e@zonque.org>
On Tue, Dec 20, 2016 at 10:36 AM, Daniel Mack <daniel@zonque.org> wrote:
> Hi,
>
> On 12/20/2016 06:23 PM, Andy Lutomirski wrote:
>> On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack <daniel@zonque.org> wrote:
>
>> To clarify, since this thread has gotten excessively long and twisted,
>> I think it's important that, for hooks attached to a cgroup, you be
>> able to tell in a generic way whether something is plugged into the
>> hook. The natural way to see a cgroup's configuration is to read from
>> cgroupfs, so I think that reading from cgroupfs should show you that a
>> BPF program is attached and also give enough information that, once
>> bpf programs become dumpable, you can dump the program (using the
>> bpf() syscall or whatever).
>
> [...]
>
>> There isn't a big semantic difference between
>> 'open("/cgroup/NAME/some.control.file", O_WRONLY); ioctl(...,
>> CGROUP_ATTACH_BPF, ...)' and 'open("/cgroup/NAME/some.control.file",
>> O_WRONLY); bpf(BPF_PROG_ATTACH, ...);'. There is, however, a semantic
>> difference when you do open("/cgroup/NAME", O_RDONLY | O_DIRECTORY)
>> because the permission check is much weaker.
>
> Okay, if you have such a control file, you can of course do something
> like that. When we discussed things back then with Tejun however, we
> concluded that a controller that is not completely controllable through
> control knobs that can be written and read via cat is meaningless.
> That's why this has become a 'hidden' cgroup feature.
>
> With your proposed API, you'd first go to the bpf(2) syscall in order to
> get a prog fd, and then come back to some sort of cgroup API to put the
> fd in there. That's quite a mix and match, which is why we considered
> the API cleaner in its current form, as everything that is related to
> bpf is encapsulated behind a single syscall.
You already have to do bpf() to get a prog fd, then open() to get a
cgroup fd, then bpf() or ioctl() to attach, so this isn't much
different, and its exactly the same number of syscalls.
>
>> My preference would be to do an ioctl on a new
>> /cgroup/NAME/network_hooks.inet_ingress file. Reading that file tells
>> you whether something is attached and hopefully also gives enough
>> information (a hash of the BPF program, perhaps) to dump the actual
>> program using future bpf() interfaces. write() and ioctl() can be
>> used to configure it as appropriate.
>
> So am I reading this right? You're proposing to add ioctl() hooks to
> kernfs/cgroupfs? That would open more possibilities of course, but I'm
> not sure where that rabbit hole leads us eventually.
Indeed. I already have a test patch to add ioctl() to kernfs. Adding
it to cgroupfs shouldn't be much more complicated.
>
>> Another option that I like less would be to have a
>> /cgroup/NAME/cgroup.bpf that lists all the active hooks along with
>> their contents. You would do an ioctl() on that to program a hook and
>> you could read it to see what's there.
>
> Yes, read() could, in theory, give you similar information than ioctl(),
> but in human-readable form.
>
>> FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too.
>> It doesn't make a semantic difference, except that I dislike
>> BPF_PROG_DETACH because that particular command isn't BPF-specific at
>> all.
>
> Well, I think it is; it pops the bpf program from a target and drops the
> reference on it. It's not much code, but it's certainly bpf-specific.
I mean the interface isn't bpf-specific. If there was something that
wasn't bpf attached to the target, you'd still want an API to detach
it.
>
>>>> So if I set up a cgroup that's monitored and call it /cgroup/a and
>>>> enable delegation and if the program running there wants to do its own
>>>> monitoring in /cgroup/a/b (via delegation), then you really want the
>>>> outer monitor to silently drop events coming from /cgroup/a/b?
>>>
>>> That's a fair point, and we've discussed it as well. The issue is, as
>>> Alexei already pointed out, that we do not want to traverse the tree up
>>> to the root for nested cgroups due to the runtime costs in the
>>> networking fast-path. After all, we're running the bpf program for each
>>> packet in flight. Hence, we opted for the approach to only look at the
>>> leaf node for now, with the ability to open it up further in the future
>>> using flags during attach etc.
>>
>> Careful here! You don't look only at the leaf node for now. You do a
>> fancy traversal and choose the nearest node that has a hook set up.
>
> But we do the 'complex' operation at attach time or when a cgroup is
> created, both of which are slow-path operations. In the fast-path, we
> only look at the leaf, which may or may not have an effective program
> installed. And that's of course much cheaper then doing the traversing
> for each packet.
You would never traverse the full hierarchy for each packet. You'd
have a linked list of programs that are attached, kind of like how
there's an "effective" array right now. I sent out pseudocode earlier
in the thread.
>
>> mkdir /cgroup/foo
>> BPF_PROG_ATTACH(some program to foo)
>> mkdir /cgroup/foo/bar
>> chown -R some_user /cgroup/foo/bar
>>
>> If the kernel only looked at the leaf, then the program that did the
>> above would not expect that the program would constrain
>> /cgroup/foo/bar's activity. But, as it stands, the program *would*
>> expect /cgroup/foo/bar to be constrained, except that, whenever the
>> capable() check changes to ns_capable() (which will happen eventually
>> one way or another), then the bad guy can create /cgroup/foo/bar/baz,
>> install a new no-op hook there, and break the security assumption.
>>
>> IOW, I think that totally non-recursive hooks are okay from a security
>> perspective, albeit rather strange, but the current design is not okay
>> from a security perspective.
>
> We locked down the ability to override any of these programs with
> CAP_NET_ADMIN, which is also what it takes to flush iptables, right?
> What's the difference?
For iptables, it's ns_capable() now, and there have been a number of
holes in it. For cgroup, it's going to turn in to ns_capable() sooner
or later, and it would be nice to be ready for it.
--Andy
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Daniel Mack @ 2016-12-20 18:36 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alexei Starovoitov, Andy Lutomirski, Mickaël Salaün,
Kees Cook, Jann Horn, Tejun Heo, David Ahern, David S. Miller,
Thomas Graf, Michael Kerrisk, Peter Zijlstra, Linux API,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
In-Reply-To: <CALCETrXyp2ddf4HRsEoN=qEwTBaezOUX2XWj6nxPcbc4t13svw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 12/20/2016 06:23 PM, Andy Lutomirski wrote:
> On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org> wrote:
> To clarify, since this thread has gotten excessively long and twisted,
> I think it's important that, for hooks attached to a cgroup, you be
> able to tell in a generic way whether something is plugged into the
> hook. The natural way to see a cgroup's configuration is to read from
> cgroupfs, so I think that reading from cgroupfs should show you that a
> BPF program is attached and also give enough information that, once
> bpf programs become dumpable, you can dump the program (using the
> bpf() syscall or whatever).
[...]
> There isn't a big semantic difference between
> 'open("/cgroup/NAME/some.control.file", O_WRONLY); ioctl(...,
> CGROUP_ATTACH_BPF, ...)' and 'open("/cgroup/NAME/some.control.file",
> O_WRONLY); bpf(BPF_PROG_ATTACH, ...);'. There is, however, a semantic
> difference when you do open("/cgroup/NAME", O_RDONLY | O_DIRECTORY)
> because the permission check is much weaker.
Okay, if you have such a control file, you can of course do something
like that. When we discussed things back then with Tejun however, we
concluded that a controller that is not completely controllable through
control knobs that can be written and read via cat is meaningless.
That's why this has become a 'hidden' cgroup feature.
With your proposed API, you'd first go to the bpf(2) syscall in order to
get a prog fd, and then come back to some sort of cgroup API to put the
fd in there. That's quite a mix and match, which is why we considered
the API cleaner in its current form, as everything that is related to
bpf is encapsulated behind a single syscall.
> My preference would be to do an ioctl on a new
> /cgroup/NAME/network_hooks.inet_ingress file. Reading that file tells
> you whether something is attached and hopefully also gives enough
> information (a hash of the BPF program, perhaps) to dump the actual
> program using future bpf() interfaces. write() and ioctl() can be
> used to configure it as appropriate.
So am I reading this right? You're proposing to add ioctl() hooks to
kernfs/cgroupfs? That would open more possibilities of course, but I'm
not sure where that rabbit hole leads us eventually.
> Another option that I like less would be to have a
> /cgroup/NAME/cgroup.bpf that lists all the active hooks along with
> their contents. You would do an ioctl() on that to program a hook and
> you could read it to see what's there.
Yes, read() could, in theory, give you similar information than ioctl(),
but in human-readable form.
> FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too.
> It doesn't make a semantic difference, except that I dislike
> BPF_PROG_DETACH because that particular command isn't BPF-specific at
> all.
Well, I think it is; it pops the bpf program from a target and drops the
reference on it. It's not much code, but it's certainly bpf-specific.
>>> So if I set up a cgroup that's monitored and call it /cgroup/a and
>>> enable delegation and if the program running there wants to do its own
>>> monitoring in /cgroup/a/b (via delegation), then you really want the
>>> outer monitor to silently drop events coming from /cgroup/a/b?
>>
>> That's a fair point, and we've discussed it as well. The issue is, as
>> Alexei already pointed out, that we do not want to traverse the tree up
>> to the root for nested cgroups due to the runtime costs in the
>> networking fast-path. After all, we're running the bpf program for each
>> packet in flight. Hence, we opted for the approach to only look at the
>> leaf node for now, with the ability to open it up further in the future
>> using flags during attach etc.
>
> Careful here! You don't look only at the leaf node for now. You do a
> fancy traversal and choose the nearest node that has a hook set up.
But we do the 'complex' operation at attach time or when a cgroup is
created, both of which are slow-path operations. In the fast-path, we
only look at the leaf, which may or may not have an effective program
installed. And that's of course much cheaper then doing the traversing
for each packet.
> mkdir /cgroup/foo
> BPF_PROG_ATTACH(some program to foo)
> mkdir /cgroup/foo/bar
> chown -R some_user /cgroup/foo/bar
>
> If the kernel only looked at the leaf, then the program that did the
> above would not expect that the program would constrain
> /cgroup/foo/bar's activity. But, as it stands, the program *would*
> expect /cgroup/foo/bar to be constrained, except that, whenever the
> capable() check changes to ns_capable() (which will happen eventually
> one way or another), then the bad guy can create /cgroup/foo/bar/baz,
> install a new no-op hook there, and break the security assumption.
>
> IOW, I think that totally non-recursive hooks are okay from a security
> perspective, albeit rather strange, but the current design is not okay
> from a security perspective.
We locked down the ability to override any of these programs with
CAP_NET_ADMIN, which is also what it takes to flush iptables, right?
What's the difference?
> So here's a fleshed-out possible version that's a bit of a compromise
> after sleeping on this. There's plenty of room to tweak this.
>
> Each cgroup gets a new file cgroup.hooks. Reading it shows a list of
> active hooks. (A hook can be a string like "network.inet_ingress".)
>
> You can write a command like "-network.inet_ingress off" to it to
> disable network.inet_ingress. You can write a command like
> "+network.inet_ingress" to it to enable the network.inet_ingress hook.
>
> When a hook (e.g. network.inet_ingress) is enabled, a new file appears
> in the cgroup called "hooks.network.inet_ingress"). You can read it
> to get an indication of what is currently installed in that slot. You
> can write "none" to it to cause nothing to be installed in that slot.
> (This replaces BPF_PROG_DETACH.). You can open it for write and use
> bpf() or perhaps ioctl() to attach a bpf program. Maybe you can also
> use bpf() to dump the bpf program, but, regardless, if a bpf program
> is there, read() will return some string that contains "bpf" and maybe
> some other useful information.
I can see where you're going, but I don't know yet if if I like this
approach better, given that you would still need a binary interface at
least at attach time, and that such an interface would use a resource
returned from bpf(2). The ability to read from control files in order to
see what's going on is nice though.
I'd like to have Tejun's and Alexei's opinion on this - as I said, I had
something like that (albeit much simpler) in one of my very early
drafts, but we consented to do the hookup the other way around, for
stated reasons.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Mark Greer @ 2016-12-20 18:35 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt, mark.rutland, netdev, devicetree,
linux-kernel, Justin Bronder
In-Reply-To: <CAO7Z3WLYMZ3rRGKpksYnRksbC=A1WNog913UJFiPsAT7ymOnaw@mail.gmail.com>
On Tue, Dec 20, 2016 at 01:29:13PM -0500, Geoff Lansberry wrote:
> On Tue, Dec 20, 2016 at 1:11 PM, Mark Greer <mgreer@animalcreek.com> wrote:
> > Hi Geoff.
> >
> > Please put the version in your subjects when submitting anything but the
> > initial version of a patch (e.g., [PATCH v2 1/3]).
> >
> > Which series do you want reviewed?
> >
> > Mark
> > --
> Sorry about the double posting, I had forgotten to erase the patches I
> generated while rebasing and checking, and I'll have to figure out how
> to add that v2 line to the automatically generated subject line if I
> end up submitting another round.
Hint: -v <n> option of 'git format-patch'
> Please review the three most recent patches, which have the send time
> of 17:16.
Okay, thank.
Mark
^ permalink raw reply
* Re: mlx4: Bug in XDP_TX + 16 rx-queues
From: Martin KaFai Lau @ 2016-12-20 18:31 UTC (permalink / raw)
To: Tariq Toukan
Cc: Tariq Toukan, Saeed Mahameed, netdev@vger.kernel.org,
Alexei Starovoitov
In-Reply-To: <a586ecb7-e290-8c70-714b-2eea0b94c7fb@gmail.com>
On Tue, Dec 20, 2016 at 02:02:05PM +0200, Tariq Toukan wrote:
> Thanks Martin, nice catch!
>
>
> On 20/12/2016 1:37 AM, Martin KaFai Lau wrote:
> >Hi Tariq,
> >
> >On Sat, Dec 17, 2016 at 02:18:03AM -0800, Martin KaFai Lau wrote:
> >>Hi All,
> >>
> >>I have been debugging with XDP_TX and 16 rx-queues.
> >>
> >>1) When 16 rx-queues is used and an XDP prog is doing XDP_TX,
> >>it seems that the packet cannot be XDP_TX out if the pkt
> >>is received from some particular CPUs (/rx-queues).
> >>
> >>2) If 8 rx-queues is used, it does not have problem.
> >>
> >>3) The 16 rx-queues problem also went away after reverting these
> >>two patches:
> >>15fca2c8eb41 net/mlx4_en: Add ethtool statistics for XDP cases
> >>67f8b1dcb9ee net/mlx4_en: Refactor the XDP forwarding rings scheme
> >>
> >After taking a closer look at 67f8b1dcb9ee ("net/mlx4_en: Refactor the XDP forwarding rings scheme")
> >and armed with the fact that '>8 rx-queues does not work', I have
> >made the attached change that fixed the issue.
> >
> >Making change in mlx4_en_fill_qp_context() could be an easier fix
> >but I think this change will be easier for discussion purpose.
> >
> >I don't want to lie that I know anything about how this variable
> >works in CX3. If this change makes sense, I can cook up a diff.
> >Otherwise, can you shed some light on what could be happening
> >and hopefully can lead to a diff?
> >
> >Thanks
> >--Martin
> >
> >
> >diff --git i/drivers/net/ethernet/mellanox/mlx4/en_netdev.c w/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> >index bcd955339058..b3bfb987e493 100644
> >--- i/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> >+++ w/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> >@@ -1638,10 +1638,10 @@ int mlx4_en_start_port(struct net_device *dev)
> >
> > /* Configure tx cq's and rings */
> > for (t = 0 ; t < MLX4_EN_NUM_TX_TYPES; t++) {
> >- u8 num_tx_rings_p_up = t == TX ? priv->num_tx_rings_p_up : 1;
> The bug lies in this line.
> Number of rings per UP in case of TX_XDP should be priv->tx_ring_num[TX_XDP
> ], not 1.
> Please try the following fix.
> I can prepare and send it once the window opens again.
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> index bcd955339058..edbe200ac2fa 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
> @@ -1638,7 +1638,8 @@ int mlx4_en_start_port(struct net_device *dev)
>
> /* Configure tx cq's and rings */
> for (t = 0 ; t < MLX4_EN_NUM_TX_TYPES; t++) {
> - u8 num_tx_rings_p_up = t == TX ? priv->num_tx_rings_p_up :
> 1;
> + u8 num_tx_rings_p_up = t == TX ?
> + priv->num_tx_rings_p_up : priv->tx_ring_num[t];
>
> for (i = 0; i < priv->tx_ring_num[t]; i++) {
> /* Configure cq */
>
Thanks for confirming the bug is related to the user_prio argument.
I have some questions:
1. Just to confirm the intention of the change. Your change is essentially
always passing 0 to the user_prio parameter for the TX_XDP type by
doing (i / priv->tx_ring_num[t])? If yes, would it be clearer to
always pass 0 instead?
And yes, it also works in our test. Please post an offical patch
if it is the fix.
2. Can you explain a little on how does the user_prio affect
the tx behavior? e.g. What is the difference between
different user_prio like 0, 1, 2...etc?
3. Mostly a follow up on (2).
In mlx4_en_get_profile(), num_tx_rings_p_up (of the struct mlx4_en_profile)
depends on mlx4_low_memory_profile() and number of cpu. Does these
similar bounds apply to the 'u8 num_tx_rings_p_up' here for
TX_XDP type?
Thanks,
Martin
> >-
> > for (i = 0; i < priv->tx_ring_num[t]; i++) {
> > /* Configure cq */
> >+ int user_prio;
> >+
> > cq = priv->tx_cq[t][i];
> > err = mlx4_en_activate_cq(priv, cq, i);
> > if (err) {
> >@@ -1660,9 +1660,14 @@ int mlx4_en_start_port(struct net_device *dev)
> >
> > /* Configure ring */
> > tx_ring = priv->tx_ring[t][i];
> >+ if (t != TX_XDP)
> >+ user_prio = i / priv->num_tx_rings_p_up;
> >+ else
> >+ user_prio = i & 0x07;
> >+
> > err = mlx4_en_activate_tx_ring(priv, tx_ring,
> > cq->mcq.cqn,
> >- i / num_tx_rings_p_up);
> >+ user_prio);
> > if (err) {
> > en_err(priv, "Failed allocating Tx ring\n");
> > mlx4_en_deactivate_cq(priv, cq);
> Regards,
> Tariq Toukan.
^ permalink raw reply
* Re: [PATCH net-next 1/1] driver: ipvlan: Define common functions to decrease duplicated codes used to add or del IP address
From: David Miller @ 2016-12-20 18:30 UTC (permalink / raw)
To: fgao; +Cc: maheshb, edumazet, netdev, gfree.wind
In-Reply-To: <1482110645-1853-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Mon, 19 Dec 2016 09:24:05 +0800
> It is sent again because the first email is sent during net-next closing.
It is still closed, and will not open again for at least one week.
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-20 18:29 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Justin Bronder
In-Reply-To: <20161220181157.GB30273-luAo+O/VEmrlveNOaEYElw@public.gmane.org>
On Tue, Dec 20, 2016 at 1:11 PM, Mark Greer <mgreer-luAo+O/VEmrlveNOaEYElw@public.gmane.org> wrote:
> Hi Geoff.
>
> Please put the version in your subjects when submitting anything but the
> initial version of a patch (e.g., [PATCH v2 1/3]).
>
> Which series do you want reviewed?
>
> Mark
> --
Sorry about the double posting, I had forgotten to erase the patches I
generated while rebasing and checking, and I'll have to figure out how
to add that v2 line to the automatically generated subject line if I
end up submitting another round.
Please review the three most recent patches, which have the send time
of 17:16.
Best Regards,
Geoff
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kernel/bpf/verifier.c: 4 * possible unintended fallthrough ?
From: Josef Bacik @ 2016-12-20 18:28 UTC (permalink / raw)
To: David Binderman
Cc: Alexei Starovoitov, ast@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR08MB10228EE1E2FA0EBFEA78DE919C900@VI1PR08MB1022.eurprd08.prod.outlook .com>
On Tue, Dec 20, 2016 at 11:34 AM, David Binderman <dcb314@hotmail.com>
wrote:
>
> Hello there,
>
>> From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
>> I've tried 4.9 and 5.2 and don't see this warning.
>
> As expected - I used a development version of gcc.
> Latest released version is 6.2
>
>> Is this 6.x gcc?
>
> 7.0 would be more accurate.
>
>> I suspect it will have such warnings all over the kernel.
>
> Indeed it has hundreds, but the subject under discussion is file
> kernel/bpf/verifier.c.
>
> I am still not sure if I have found a fallthrough bug or not.
You haven't, this is intended so is a useless warning. Thanks,
Josef
^ permalink raw reply
* Re: ipv6: handle -EFAULT from skb_copy_bits
From: David Miller @ 2016-12-20 18:28 UTC (permalink / raw)
To: davej; +Cc: netdev
In-Reply-To: <20161220181728.dd2cynjwrceruwcu@codemonkey.org.uk>
From: Dave Jones <davej@codemonkey.org.uk>
Date: Tue, 20 Dec 2016 13:17:28 -0500
> On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote:
> > From: Dave Jones <davej@codemonkey.org.uk>
> > Date: Mon, 19 Dec 2016 19:40:13 -0500
> >
> > > On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote:
> > >
> > > > Unfortunately, this made no difference. I spent some time today trying
> > > > to make a better reproducer, but failed. I'll revisit again tomorrow.
> > > >
> > > > Maybe I need >1 process/thread to trigger this. That would explain why
> > > > I can trigger it with Trinity.
> > >
> > > scratch that last part, I finally just repro'd it with a single process.
> >
> > Thanks for the info, I'll try to think about this some more.
>
> I threw in some debug printks right before that BUG_ON.
> it's always this:
>
> skb->len=31 skb->data_len=0 offset:30 total_len:9
>
> Shouldn't we have kicked out data_len=0 skb's somewhere before we got this far ?
skb->data_len is just the length of any non-linear data in the SKB.
This has to do with the SKB buffer layout and geometry, not whether
the packet is "fragmented" in the protocol sense.
So no, this isn't a criteria for packets being filtered out by this
point.
Can you try to capture what sk->sk_socket->type and
inet_sk(sk)->hdrincl are set to at the time of the crash?
Thanks.
^ permalink raw reply
* Re: ipv6: handle -EFAULT from skb_copy_bits
From: Dave Jones @ 2016-12-20 18:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20161219.203623.119653805184192345.davem@davemloft.net>
On Mon, Dec 19, 2016 at 08:36:23PM -0500, David Miller wrote:
> From: Dave Jones <davej@codemonkey.org.uk>
> Date: Mon, 19 Dec 2016 19:40:13 -0500
>
> > On Mon, Dec 19, 2016 at 07:31:44PM -0500, Dave Jones wrote:
> >
> > > Unfortunately, this made no difference. I spent some time today trying
> > > to make a better reproducer, but failed. I'll revisit again tomorrow.
> > >
> > > Maybe I need >1 process/thread to trigger this. That would explain why
> > > I can trigger it with Trinity.
> >
> > scratch that last part, I finally just repro'd it with a single process.
>
> Thanks for the info, I'll try to think about this some more.
I threw in some debug printks right before that BUG_ON.
it's always this:
skb->len=31 skb->data_len=0 offset:30 total_len:9
Shouldn't we have kicked out data_len=0 skb's somewhere before we got this far ?
Dave
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Mark Greer @ 2016-12-20 18:11 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <1482250592-4268-1-git-send-email-glansberry@gmail.com>
Hi Geoff.
Please put the version in your subjects when submitting anything but the
initial version of a patch (e.g., [PATCH v2 1/3]).
Which series do you want reviewed?
Mark
--
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Jones Desougi @ 2016-12-20 17:58 UTC (permalink / raw)
To: Geoff Lansberry, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: lauro.venancio-430g2QfJUUCGglJvpFV4uA,
aloisio.almeida-430g2QfJUUCGglJvpFV4uA,
sameo-VuQAYsv1563Yd54FQh9/CA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mgreer-luAo+O/VEmrlveNOaEYElw, justin-R+k406RtEhcAvxtiuMwx3w
In-Reply-To: <1482250592-4268-1-git-send-email-glansberry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2016-12-20 17:16, Geoff Lansberry wrote:
> From: Geoff Lansberry <geoff-R+k406RtEhcAvxtiuMwx3w@public.gmane.org>
>
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the optional 27.12MHz clock.
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++
> drivers/nfc/trf7970a.c | 50 +++++++++++++++++-----
> 2 files changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> index 32b35a0..e262ac1 100644
> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
> @@ -21,6 +21,8 @@ Optional SoC Specific Properties:
> - t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
> where an extra byte is returned by Read Multiple Block commands issued
> to Type 5 tags.
> +- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz
> +
You're adding an empty line here that is removed in the next patch.
>
> Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>
> @@ -43,6 +45,8 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
> irq-status-read-quirk;
> en2-rf-quirk;
> t5t-rmb-extra-byte-quirk;
> + vdd_io_1v8;
This does not belong here, and so no need to remove in the next patch.
> + clock-frequency = <27120000>;
> status = "okay";
> };
> };
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 26c9dbb..4e051e9 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -124,6 +124,9 @@
> NFC_PROTO_ISO15693_MASK | NFC_PROTO_NFC_DEP_MASK)
>
> #define TRF7970A_AUTOSUSPEND_DELAY 30000 /* 30 seconds */
> +#define TRF7970A_13MHZ_CLOCK_FREQUENCY 13560000
> +#define TRF7970A_27MHZ_CLOCK_FREQUENCY 27120000
> +
>
> #define TRF7970A_RX_SKB_ALLOC_SIZE 256
>
> @@ -1056,12 +1059,11 @@ static int trf7970a_init(struct trf7970a *trf)
>
> trf->chip_status_ctrl &= ~TRF7970A_CHIP_STATUS_RF_ON;
>
> - ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL, 0);
> + ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL,
> + trf->modulator_sys_clk_ctrl);
> if (ret)
> goto err_out;
>
> - trf->modulator_sys_clk_ctrl = 0;
> -
> ret = trf7970a_write(trf, TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS,
> TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLH_96 |
> TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLL_32);
> @@ -1181,27 +1183,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
> switch (tech) {
> case NFC_DIGITAL_RF_TECH_106A:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_OOK;
> trf->guard_time = TRF7970A_GUARD_TIME_NFCA;
> break;
> case NFC_DIGITAL_RF_TECH_106B:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443B_106;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_ASK10;
> trf->guard_time = TRF7970A_GUARD_TIME_NFCB;
> break;
> case NFC_DIGITAL_RF_TECH_212F:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_212;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_ASK10;
> trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
> break;
> case NFC_DIGITAL_RF_TECH_424F:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_424;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_ASK10;
> trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
> break;
> case NFC_DIGITAL_RF_TECH_ISO15693:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_15693_SGL_1OF4_2648;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_OOK;
> trf->guard_time = TRF7970A_GUARD_TIME_15693;
> break;
> default:
> @@ -1571,17 +1583,23 @@ static int trf7970a_tg_config_rf_tech(struct trf7970a *trf, int tech)
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
> TRF7970A_ISO_CTRL_NFC_CE |
> TRF7970A_ISO_CTRL_NFC_CE_14443A;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_OOK;
> break;
> case NFC_DIGITAL_RF_TECH_212F:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
> TRF7970A_ISO_CTRL_NFC_NFCF_212;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_ASK10;
> break;
> case NFC_DIGITAL_RF_TECH_424F:
> trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
> TRF7970A_ISO_CTRL_NFC_NFCF_424;
> - trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
> + trf->modulator_sys_clk_ctrl =
> + (trf->modulator_sys_clk_ctrl & 0xF8) |
> + TRF7970A_MODULATOR_DEPTH_ASK10;
> break;
> default:
> dev_dbg(trf->dev, "Unsupported rf technology: %d\n", tech);
> @@ -1987,6 +2005,7 @@ static int trf7970a_probe(struct spi_device *spi)
> struct device_node *np = spi->dev.of_node;
> struct trf7970a *trf;
> int uvolts, autosuspend_delay, ret;
> + u32 clk_freq = 13560000;
Use TRF7970A_13MHZ_CLOCK_FREQUENCY here?
>
> if (!np) {
> dev_err(&spi->dev, "No Device Tree entry\n");
> @@ -2043,6 +2062,15 @@ static int trf7970a_probe(struct spi_device *spi)
> return ret;
> }
>
> + of_property_read_u32(np, "clock-frequency", &clk_freq);
> + if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
> + (clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY)) {
Two comparisons with 27MHz, missing 13MHz.
> + dev_err(trf->dev,
> + "clock-frequency (%u Hz) unsupported\n",
> + clk_freq);
> + return -EINVAL;
> + }
> +
> if (of_property_read_bool(np, "en2-rf-quirk"))
> trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ethernet: sfc: Add Kconfig entry for vendor Solarflare
From: Edward Cree @ 2016-12-20 17:29 UTC (permalink / raw)
To: Tobias Klauser, netdev; +Cc: linux-net-drivers, bkenward
In-Reply-To: <20161220133826.1478-1-tklauser@distanz.ch>
On 20/12/16 13:38, Tobias Klauser wrote:
> Since commit
>
> 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
>
> there are two drivers for Solarflare devices, but both still show up
> directly beneath "Ethernet driver support" in the Kconfig. Follow the
> pattern of other vendors and group them beneath an own vendor Kconfig
> entry for Solarflare.
>
> Cc: Edward Cree <ecree@solarflare.com>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Edward Cree <ecree@solarflare.com>
^ permalink raw reply
* Re: Potential issues (security and otherwise) with the current cgroup-bpf API
From: Andy Lutomirski @ 2016-12-20 17:23 UTC (permalink / raw)
To: Daniel Mack
Cc: Alexei Starovoitov, Andy Lutomirski, Mickaël Salaün,
Kees Cook, Jann Horn, Tejun Heo, David Ahern, David S. Miller,
Thomas Graf, Michael Kerrisk, Peter Zijlstra, Linux API,
linux-kernel@vger.kernel.org, Network Development
In-Reply-To: <bdc18fe4-f90d-49f0-d0a6-a28f87335df2@zonque.org>
On Tue, Dec 20, 2016 at 2:21 AM, Daniel Mack <daniel@zonque.org> wrote:
> Hi,
>
> On 12/20/2016 04:50 AM, Andy Lutomirski wrote:
>> You mean BPF_CGROUP_RUN_PROG_INET_SOCK(sk)? There is nothing bpf
>> specfic about the hook except that the name of this macro has "BPF" in
>> it. There is nothing whatsoever that's bpf-specific about the context
>> -- sk is not bpf-specific at all.
>>
>> The only thing bpf-specific about it is that it currently only invokes
>> bpf programs. That could easily change.
>
> I'm not sure if I follow. The code as it currently stands only supports
> attaching bpf programs to cgroups which have been created using
> BPF_PROG_LOAD. If cgroups would support other program types in the
> future, then they would need to be stored in different data types
> anyway, and the bpf syscall multiplexer would be the wrong entry point
> to access them anyway.
To clarify, since this thread has gotten excessively long and twisted,
I think it's important that, for hooks attached to a cgroup, you be
able to tell in a generic way whether something is plugged into the
hook. The natural way to see a cgroup's configuration is to read from
cgroupfs, so I think that reading from cgroupfs should show you that a
BPF program is attached and also give enough information that, once
bpf programs become dumpable, you can dump the program (using the
bpf() syscall or whatever).
Obviously the interface to *attach* a BPF program to a hook will need
to be at least a little bit BPF-specific. But there's nothing
particularly BPF-specific about detaching, and if a control file were
to exist, writing "detach" or "none" to it seems natural.
>
> Whether we add bpf-specific code to the cgroup file parsers or
> cgroup-specific code to the bpf layer does not make much of a semantic
> difference, does it? As a matter of fact, my very first implementation
> of this patch set implemented a cgroup controller that would allow
> writing strings like "ing
>
> b) make it possible to extend the functionality in the future by adding
> flags to the command struct etc.
>
> And I hoped we achieved that after discussing it for so long.
>
>> How about slowing down a wee bit and trying to come up with cgroup
>> hook semantics that work for all of these use cases?
>
> I'm all for discussing things, but I don't this was done in a rush.
>
> I do agree though that adding functionality to cgroups that is not
> limited to resource control is a delicate thing to do, which is why I
> cc'ed cgroups@ in my patches. I should have also added linux-api@ I
> guess, sorry I missed that.
>ress 5" to its control file, where 5 is the fd
> number that came out of BPF_PROG_LOAD. The main reason we decided to
> ditch that was that echoing fd numbers into a text file seemed way worse
> than going through a proper syscall layer with it, and ioctls are
> unavailable on pseudo-fs.
There isn't a big semantic difference between
'open("/cgroup/NAME/some.control.file", O_WRONLY); ioctl(...,
CGROUP_ATTACH_BPF, ...)' and 'open("/cgroup/NAME/some.control.file",
O_WRONLY); bpf(BPF_PROG_ATTACH, ...);'. There is, however, a semantic
difference when you do open("/cgroup/NAME", O_RDONLY | O_DIRECTORY)
because the permission check is much weaker.
The reason I suggest ioctl() and not write() is that write() MUST NOT
make its behavior depend on the caller's credentials, file table, etc.
Imagine what would happen if you did 'sudo -u eviltext
>/cgroup/NAME/control.file'. (This particular mistake has been
repeated many times in the kernel, in drivers, networking, namespaces,
core code, etc, and it's resulted in a big pile of privilege
escalation bugs.) So write("bpf:<actual BPF instructions>") is safe
(but unusably awkward, I think), whereas write("bpf:fd 5") is unsafe.
>
> The idea was rather to allow attaching bpf programs to other things than
> just cgroups as well, which is why we called the member of 'union
> bpf_attr' 'target_fd', and a cgroup is just one type a target here.
I would make that a separate operation. If someone adds the ability
to attach an ebpf program to, say, seccomp (I'm quite sure this will
happen eventually), it should be attached using seccomp(), not bpf(),
for example). The people writing seccomp filters will thank you for
making the syscall in question reflect what object (the cgroup, for
example) is being modified.
>
>>> i'm assuming 'baadf00d' is bpf program fd expressed a text string?
>>> and kernel needs to parse above? will you allow capital and lower
>>> case for 'bpf:' ? and mixed case too? spaces and tabs allowed or not?
>>> can program fd expressed as decimal or hex or both?
>>> how do you return the error? as a text string for user space
>>> to parse?
>>
>> No. The kernel does not parse it because you cannot write this to the
>> file. You set a bpf filter with ioctl and pass an fd.
>
> An ioctl on what file, exactly?
There are at least two plausible models.
My preference would be to do an ioctl on a new
/cgroup/NAME/network_hooks.inet_ingress file. Reading that file tells
you whether something is attached and hopefully also gives enough
information (a hash of the BPF program, perhaps) to dump the actual
program using future bpf() interfaces. write() and ioctl() can be
used to configure it as appropriate.
Another option that I like less would be to have a
/cgroup/NAME/cgroup.bpf that lists all the active hooks along with
their contents. You would do an ioctl() on that to program a hook and
you could read it to see what's there.
FWIW, everywhere I say ioctl(), the bpf() syscall would be okay, too.
It doesn't make a semantic difference, except that I dislike
BPF_PROG_DETACH because that particular command isn't BPF-specific at
all.
>
>> If you *read*
>> the file, you get the same bpf program hash that fdinfo on the bpf
>> object would show -- this is for debugging and (eventually) CRIU.
>
> We need a debugging facility at some point, I agree to that. As the code
> currently stands, that would rather need to go into the bpf(2) syscall
> though, as setting a program through bpf(2) and reading it through
> cgroupfs is really nasty.
But knowing that you have to call bpf() to tell whether bpf hooks are
installed in a cgroup is nasty. Everything else uses ls and cat --
why should BPF be special here?
>> So if I set up a cgroup that's monitored and call it /cgroup/a and
>> enable delegation and if the program running there wants to do its own
>> monitoring in /cgroup/a/b (via delegation), then you really want the
>> outer monitor to silently drop events coming from /cgroup/a/b?
>
> That's a fair point, and we've discussed it as well. The issue is, as
> Alexei already pointed out, that we do not want to traverse the tree up
> to the root for nested cgroups due to the runtime costs in the
> networking fast-path. After all, we're running the bpf program for each
> packet in flight. Hence, we opted for the approach to only look at the
> leaf node for now, with the ability to open it up further in the future
> using flags during attach etc.
Careful here! You don't look only at the leaf node for now. You do a
fancy traversal and choose the nearest node that has a hook set up.
This gives you almost all the complexity of evaluating all of the
installed hooks with none of the benefit. It also is, IMO, much more
dangerous than only looking at the leaf node. Consider:
mkdir /cgroup/foo
BPF_PROG_ATTACH(some program to foo)
mkdir /cgroup/foo/bar
chown -R some_user /cgroup/foo/bar
If the kernel only looked at the leaf, then the program that did the
above would not expect that the program would constrain
/cgroup/foo/bar's activity. But, as it stands, the program *would*
expect /cgroup/foo/bar to be constrained, except that, whenever the
capable() check changes to ns_capable() (which will happen eventually
one way or another), then the bad guy can create /cgroup/foo/bar/baz,
install a new no-op hook there, and break the security assumption.
IOW, I think that totally non-recursive hooks are okay from a security
perspective, albeit rather strange, but the current design is not okay
from a security perspective.
>
>> The current approach to bpf hooks will bite you down the road. David
>> Ahern is already proposing using it for something that is not tracing
>> at all, and someone will want that in a container, and there will be a
>> problem.
>
> Hmm, I thought we've sorted out the concerns about that by making sure
> that we
>
> a) lock-down the API sufficiently so it doesn't cause any security
> issues in its current form, and
This argument is why iptables + userns has become a security mess, for
example. Designing an API assuming that the bad guys will never be
permitted to use it causes quite a bit of pain when, a few years
later, bad guys are permitted to use it.
>> I think my proposal is quite close to workable.
>
> So let's talk about how to proceed. I've seen different bits of your
> proposal in different mails, and I think a summary of it would help the
> discussion.
So here's a fleshed-out possible version that's a bit of a compromise
after sleeping on this. There's plenty of room to tweak this.
Each cgroup gets a new file cgroup.hooks. Reading it shows a list of
active hooks. (A hook can be a string like "network.inet_ingress".)
You can write a command like "-network.inet_ingress off" to it to
disable network.inet_ingress. You can write a command like
"+network.inet_ingress" to it to enable the network.inet_ingress hook.
When a hook (e.g. network.inet_ingress) is enabled, a new file appears
in the cgroup called "hooks.network.inet_ingress"). You can read it
to get an indication of what is currently installed in that slot. You
can write "none" to it to cause nothing to be installed in that slot.
(This replaces BPF_PROG_DETACH.). You can open it for write and use
bpf() or perhaps ioctl() to attach a bpf program. Maybe you can also
use bpf() to dump the bpf program, but, regardless, if a bpf program
is there, read() will return some string that contains "bpf" and maybe
some other useful information.
If a SELinux policy wants to lock down the netowrk.inet_ingress hook,
it uses existing mechanisms to label the hooks.network.inet_ingress
file when it appears and to restrict opening it for write.
I think this is all quite straightforward to implement and will result
in clean code. I could probably make some decent progress toward it
over the next couple days.
--Andy
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Tony Lindgren @ 2016-12-20 17:21 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend Van Spriel, Pali Rohár, Daniel Wagner,
Luis R. Rodriguez, Tom Gundersen, Johannes Berg, Ming Lei,
Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, linux-wireless, Network Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <87bmw6ttim.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
* Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> [161220 09:12]:
> Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> writes:
>
> > * Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> [161220 03:47]:
> >> Arend Van Spriel <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> >>
> >> > On 18-12-2016 13:09, Pali Rohár wrote:
> >> >
> >> >> File wl1251-nvs.bin is provided by linux-firmware package and contains
> >> >> default data which should be overriden by model specific calibrated
> >> >> data.
> >> >
> >> > Ah. Someone thought it was a good idea to provide the "one ring to rule
> >> > them all". Nice.
> >>
> >> Yes, that was a bad idea. wl1251-nvs.bin in linux-firmware.git should be
> >> renamed to wl1251-nvs.bin.example, or something like that, as it should
> >> be only installed to a real system only if there's no real calibration
> >> data available (only for developers to use, not real users).
> >
> > Makes sense to me. Note that with the recent changes to wlcore, we can
> > now easily provide board specific calibration firmware simply by adding a
> > new compatible value. So for n900, we could have something like
> > compatible = "ti,wl1251-n900" and have it point to n900 specific calibration
> > file wl1251-nvs-n900.bin. Of course this won't help with the mac address,
> > or any of the device specific data..
> >
> > That is assuming the calibration values are the same for each similar
> > device and don't have to be generated for each device. And naturally wl1251
> > needs simlar changes done to make use of devices specific calibration files.
>
> No, these are unique per each sold device. Every N900 was calibrated at
> the factory and they all have different calibration data which is stored
> to the flash. So when N900 boots (and in _every_ boot) it has to load
> the calibration data from the flash and provide it to the wl1251 driver
> somehow.
Urgh, OK. So much for that idea then.
Thanks,
Tony
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Kalle Valo @ 2016-12-20 17:11 UTC (permalink / raw)
To: Tony Lindgren
Cc: Arend Van Spriel, Pali Rohár, Daniel Wagner,
Luis R. Rodriguez, Tom Gundersen, Johannes Berg, Ming Lei,
Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, linux-wireless, Network Development
In-Reply-To: <20161220165658.GI4920@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kalle Valo <kvalo@codeaurora.org> [161220 03:47]:
>> Arend Van Spriel <arend.vanspriel@broadcom.com> writes:
>>
>> > On 18-12-2016 13:09, Pali Rohár wrote:
>> >
>> >> File wl1251-nvs.bin is provided by linux-firmware package and contains
>> >> default data which should be overriden by model specific calibrated
>> >> data.
>> >
>> > Ah. Someone thought it was a good idea to provide the "one ring to rule
>> > them all". Nice.
>>
>> Yes, that was a bad idea. wl1251-nvs.bin in linux-firmware.git should be
>> renamed to wl1251-nvs.bin.example, or something like that, as it should
>> be only installed to a real system only if there's no real calibration
>> data available (only for developers to use, not real users).
>
> Makes sense to me. Note that with the recent changes to wlcore, we can
> now easily provide board specific calibration firmware simply by adding a
> new compatible value. So for n900, we could have something like
> compatible = "ti,wl1251-n900" and have it point to n900 specific calibration
> file wl1251-nvs-n900.bin. Of course this won't help with the mac address,
> or any of the device specific data..
>
> That is assuming the calibration values are the same for each similar
> device and don't have to be generated for each device. And naturally wl1251
> needs simlar changes done to make use of devices specific calibration files.
No, these are unique per each sold device. Every N900 was calibrated at
the factory and they all have different calibration data which is stored
to the flash. So when N900 boots (and in _every_ boot) it has to load
the calibration data from the flash and provide it to the wl1251 driver
somehow.
--
Kalle Valo
^ 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