* Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)
From: Jian-Hong Pan @ 2018-08-05 12:49 UTC (permalink / raw)
To: Andreas Färber
Cc: Ben Whitten, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jiri Pirko,
Marcel Holtmann, David S. Miller, Matthias Brugger, Janus Piwek,
Michael Röder, Dollar Chen, Ken Yu, Konstantin Böhm,
Jan Jongboom, contact-GpjyyWaKhplWk0Htik3J/w@public.gmane.org,
Brian Ray
In-Reply-To: <6dda350b-66ab-b5ab-41ed-319b27e4e28c-l3A5Bk7waGM@public.gmane.org>
Hi Andreas,
2018-08-03 16:44 GMT+08:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
> Hi Jian-Hong,
>
> Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan:
>> 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten-xJ1y+ldTOs21Z/+hSey0Gg@public.gmane.org>:
>>>> 1) PF_LORA/AF_LORA and associated identifiers are
>>>> proposed to represent
>>>> this technology. While for an SX1276 [...] it
>>>> might work to
>>>> layer LoRaWAN as a protocol option for PF_LORA and
>> add
>>>> LoRaWAN address
>>>> fields to the union in my sockaddr_lora, how would that
>>>> work for devices
>>>> that only support LoRaWAN but not pure LoRa? Do we
>>>> need both AF_LORA and
>>>> AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>>>> ARPHRD_LORAWAN?
> [...]
>>>> Meanwhile my attempt to play with netlink during SUSE
>>>> Hackweek has been
>>>> going slow and I could use some guidance or a volunteer to
>>>> contribute: I
>>>> have a bare skeleton of registration, commands, attributes
>>>> and multicast
>>>> groups, but no plan yet how to connect that to the actual
>>>> drivers to
>>>> query or apply the settings...
>>>
>>> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.
>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
>>>> nux-lora.git/tree/net/lora/netlink.c?h=lora-next
>>
>> Is this the repository used for the LoRa subsystem now?!!!
>> If it is, than great!
>
> Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes
> spotted by kbuild bot) plus a new serdev driver for another module and
> ongoing work by Ben and me for refactoring SX1301. It's monitored by the
> 0-day test service (kbuild bot).
>
> As this patchset was an RFC and does not have any Acked-bys from
> maintainers, the tree does not have a for-next branch integrated into
> linux-next on basis of 4.18-rc1, but instead (like my personal GitHub
> tree before) has a lora-next branch that rebases as patch queue on top
> of linux-next for now.
>
> The intent is to allow collaboration on getting things into a state that
> I can later submit a clean (squashed) RFC v2 for review, with all issues
> raised for this v1 addressed.
>
> For contributing patches to my linux-lora.git I suggest to use
> --subject-prefix="PATCH lora-next" to distinguish from net-next.
> And I just realize I should add a MAINTAINERS entry in my tree to make
> sure patches CC me, too. (I do monitor netdev for patches with subject
> "lora", but chances are someone might omit that.)
>
>> As the previous mails, I am trying to implement the LoRaWAN
>> specification as the soft MAC as the MAC layer over LoRa PHY.
>> This is the the talk about LoRaWAN class module I gave in Netdev Conf
>> https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem
>>
>> The expectation is:
>>
>> socket APIs:
>> send and receive the data
>> ------------------------------------------------------------
>> LoRaWAN class module implements MAC:
>> append the header/footer, encryption/decryption, timing slot and MAC commands
>> ------------------------------------------------------------
>> LoRa device drivers:
>> send and receive the messages for MAC layer
>> ------------------------------------------------------------
>> LoRa devices
>
> Thanks for sharing your slides. We seem to be in alignment for the
> abstract concept above. The devil is in the implementation details. ^.-
>
>> Is it possible that combine the LoRaWAN class module I implemented?
>
> Yes, as stated in this cover letter, I would love if you could help
> merge your LoRaWAN implementation with my driver framework. Comparing
> 802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and
> then is a fairly independent module, with you as maintainer.
>
>> I start from the simplest class A end device's behavior, especially
>> the timing slot.
>> Also the encryption/decryption for uplink/downlink data messages.
>> I can send it as patches.
>>
>> However, I have 2 problems right now.
>> 1. Which Address and Protocol Family should we use? PF_LORA or PF_LORAWAN?
>
> That was one of the questions I raised above. I now think we need both.
> I'm not yet too deep into LoRaWAN, but from the AT command interfaces
> I've seen there's confirmed and unconfirmed transmission modes that with
> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
> a way of doing both on a single PF_LORA SOCK_LORAWAN socket?
>
>> 2. To test the LoRaWAN class module, adding more procedures in LoRa
>> device drivers to register as a LoRaWAN device is needed.
>
> No, I don't think so. There are (at least) two types of devices, LoRaWAN
> and LoRa devices. The SX1276 is a pure LoRa device and thus should only
> expose a LoRa network device. It'll be the task of the maclorawan module
> to translate between the two layers, not the business of the device
> driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet,
> PF_INET and PF_INET6 don't need separate devices either, both use eth0.
>
> What I do think we need is your struct lora_hw, maybe renamed to
> lora_phy. That could be the missing piece for registration of the device
> drivers with nllora module?
> Note that similarly we'll also need an nllorawan module that needs to
> work both with your maclorawan and with some of my device drivers that
> implement the MAC in an MCU.
Let me think these twice.
> Additionally I've been looking into socket options at PF_LORA dgram
> layer for some radio options, but discarded that again for lack of
> precedence. Basically I wondered whether we could allow to choose SF,
> bandwidth, etc. on socket level and then apply those settings before
> sending one packet rather than expecting a global netlink operation that
> affects all sockets for that interface.
According to the LoRaWAN Regional Parameters, we should have the APIs
to set the SF, frequency, bandwidth ...
The idea is: LoRaWAN class module gets the region of this device and
the device's abilities. Then LoRaWAN class module calls the callback
functions to set the related parameters: SF, frequency, bandwidth ...
And of course, the setting actions only happen in the idle, standby or
stop status.
1. Interface is being startup.
2. Requested by MAC command.
But let start from simple case and add more features and complexity in
the future.
By the way, I am rearranging the module's code and try to make it
could be patches.
Regards,
Jian-Hong Pan
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Robert P. J. Day @ 2018-08-05 10:43 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Linux kernel ntedev mailing list
In-Reply-To: <20180805011121.GA19202@lunn.ch>
On Sun, 5 Aug 2018, Andrew Lunn wrote:
> On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote:
> >
> > i'll try to keep this (relatively) short as there may be a
> > simple answer to this, or it could just be a stupid question --
> > sort of related to previous question (thank you, florian).
> >
> > currently messing with networking device involving FPGA and some
> > quad-port transceivers, and noticed that, when one unplugs or
> > plugs a device into one of the ports, there is no change in the
> > contents of the corresponding sysfs files
> > /sys/class/net/<ifname>/carrier (or operstate, for that matter,
> > which might be related to this as well).
>
> Hi Robert
>
> As other have pointed out, ndo_change_carrier is not what you want
> here.
i think i see that now ... based on the really adamant comment in
netdevice.h:
"Devices that determine carrier state from physical hardware
properties (eg network cables) or protocol-dependent mechanisms (eg
USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this
function."
the impression i got was that implementing that routine for a physical
device would actually cause problems, but it seems only that it would
be a strange thing to do, but wouldn't necessarily cause problems if
you chose not to take advantage of it. which brings me back to one of
my original questions -- why *would* someone implement it? as some
sort of debugging feature? in any event, i'm convinced that that's not
where the problem lies.
> You should have a PHY device of some sort. Either a traditional
> copper PHY, or an SFP module. There should be a driver for this PHY.
> This could be one of those in drivers/net/phy. Or it could be
> firmware running, running on a little microcontroller inside your
> FPGA?
in my case, it's properly in drivers/net/phy, so at least that part
is normal. back to investigating ...
rday
^ permalink raw reply
* Re: Linux kernel error stack
From: Florian Westphal @ 2018-08-05 9:48 UTC (permalink / raw)
To: Satish Patel; +Cc: netdev
In-Reply-To: <CAPgF-foR5RL3hoOdO9q0rFUWjyoFj4hmr_jtkbXztrRO-JURFA@mail.gmail.com>
Satish Patel <satish.txt@gmail.com> wrote:
> I am installing openstack and as you know i have lots of bridges and
> vlan interface on my Linux CentOS 7.5
>
> I was getting following error stack on 3.10 kernel and found this is
> kernel bug which required kernel upgrade so now i have upgraded my
> kernel to 4.17.12 but i am still seeing same kernel stack error on my
> dmesg
>
> I have disable TSO, LRO, SG & GSO on my NIC but still getting error
> just wanted to understand what is this and why it popping up
Get rid of CHECKSUM target in the iptables rules.
This thing was added 8 years ago to work around dhcp bugs, I don't
think its use is needed anymore.
Try removing it and see that all VMs can still retrieve IP address
via DHCP.
I'm curious as to the rules, normally CHECKSUM target should be
limited to -p udp --dport bootp; its bad idea to feed it normal
packets, its expensive to do this in software rather than have device
do the checksumming.
As for fix, I'm tempted to send patch to make checksum target
eval a no-op & add deprecation warning on init...
Other "fix" is to
diff --git a/net/netfilter/xt_CHECKSUM.c b/net/netfilter/xt_CHECKSUM.c
index 9f4151ec3e06..23a17dda604d 100644
--- a/net/netfilter/xt_CHECKSUM.c
+++ b/net/netfilter/xt_CHECKSUM.c
@@ -25,8 +25,12 @@ MODULE_ALIAS("ip6t_CHECKSUM");
static unsigned int
checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
{
- if (skb->ip_summed == CHECKSUM_PARTIAL)
- skb_checksum_help(skb);
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ if (skb_shinfo(skb)->gso_size)
+ skb->ip_summed = CHECKSUM_NONE;
+ else
+ skb_checksum_help(skb);
+ }
return XT_CONTINUE;
}
(unfortunately, the target isn't restricted to POSTROUTING, sigh).
^ permalink raw reply related
* Re: [PATCH] RDS is not Radio Data System
From: Sowmini Varadhan @ 2018-08-05 11:24 UTC (permalink / raw)
To: Pavel Machek
Cc: arnd, gthelen, jgg, santosh.shilimkar, kernel list, Netdev list
In-Reply-To: <20180805103756.GA24849@amd>
On (08/05/18 12:37), Pavel Machek wrote:
>
> Was it?
RDS was added in 2.6.30: see https://kernelnewbies.org/Linux_2_6_30
Recent RDS commits may have triggered the observation you note below
(you may have had it disabled by default until now)
> Because this was first time kernel asked that question... when I was
> testing -next. Is this related?
> Can you apply the patch, or do you want me to send it to davem?
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
please feel free to send the patch and add me as
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
--Sowmini
^ permalink raw reply
* Re: [PATCH] RDS is not Radio Data System
From: Pavel Machek @ 2018-08-05 10:37 UTC (permalink / raw)
To: Sowmini Varadhan, arnd, gthelen, jgg
Cc: santosh.shilimkar, kernel list, Netdev list
In-Reply-To: <20180805101945.GA4056@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
On Sun 2018-08-05 06:19:45, Sowmini Varadhan wrote:
> On (08/05/18 08:59), Pavel Machek wrote:
> > Getting prompt "The RDS Protocol" (RDS) is not too helpful, and it is
> > easily confused with Radio Data System (which we may want to support
> > in kernel, too).
> >
> > I wonder if option should be named NET_RDS, instead?
>
> RDS has been around for a while now (since 2.6). How will you
> rename proposal manage backward compatibility? Why can't you call
> your new option CONFIG_RADIO or similar instead?
>
> Are we going to rename NFS* to NET_NFS* because someone decided
> to reuse the NFS acronym?
Was it?
Because this was first time kernel asked that question... when I was
testing -next. Is this related?
commit 533d1daea8d8a389b37207ad7b50c4e750969231
IB: Revert "remove redundant INFINIBAND kconfig dependencies"
> > And this sounds like a good idea:
> > - tristate "The RDS Protocol"
> > + tristate "The Reliable Datagram Sockets (RDS) Protocol"
>
> surn that sounds fine.
Can you apply the patch, or do you want me to send it to davem?
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH net-next v2] tcp: propagate gso_segs to the new skb built in tcp collapse
From: Yafang Shao @ 2018-08-05 10:25 UTC (permalink / raw)
To: edumazet, davem; +Cc: netdev, linux-kernel, Yafang Shao
The gso_segs of the new built SKB in tcp collapse is inited to 0,
that makes us hard to know the accurate segments number of this new SKB.
We'd better propagate the gso_segs of the collapsed SKB to the new built
one, so when this SKB is dropped (for example when doing tcp prune) the
sk_drops will be added to the correct value.
If the collapsed SKB is fully copied to the new built one, we just add its
gso_segs to the new SKB.
While if the collapsed SKB is partially copied to the new built SKB,
we have to caculate how many segments are copied.
Furthemore, we have to reset the gso_segs of this SKB if is is partially
copied, so in the next round when the left segments are copied it could
propagate the correct value.
Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
net/ipv4/tcp_input.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 715d541..72d4fc8 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4915,12 +4915,23 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
/* Copy data, releasing collapsed skbs. */
while (copy > 0) {
- int offset = start - TCP_SKB_CB(skb)->seq;
int size = TCP_SKB_CB(skb)->end_seq - start;
+ int offset = start - TCP_SKB_CB(skb)->seq;
BUG_ON(offset < 0);
if (size > 0) {
size = min(copy, size);
+ if (copy >= size) {
+ skb_shinfo(nskb)->gso_segs +=
+ max_t(u16, 1, skb_shinfo(skb)->gso_segs);
+ } else {
+ skb_shinfo(nskb)->gso_segs +=
+ DIV_ROUND_UP(copy, skb_shinfo(skb)->gso_size);
+ skb_shinfo(skb)->gso_segs =
+ DIV_ROUND_UP(size - copy, skb_shinfo(skb)->gso_size);
+ size = copy;
+ }
+
if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
BUG();
TCP_SKB_CB(nskb)->end_seq += size;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] RDS is not Radio Data System
From: Sowmini Varadhan @ 2018-08-05 10:19 UTC (permalink / raw)
To: Pavel Machek; +Cc: santosh.shilimkar, kernel list, Netdev list
In-Reply-To: <20180805065920.GA8968@amd>
On (08/05/18 08:59), Pavel Machek wrote:
> Getting prompt "The RDS Protocol" (RDS) is not too helpful, and it is
> easily confused with Radio Data System (which we may want to support
> in kernel, too).
>
> I wonder if option should be named NET_RDS, instead?
RDS has been around for a while now (since 2.6). How will you
rename proposal manage backward compatibility? Why can't you call
your new option CONFIG_RADIO or similar instead?
Are we going to rename NFS* to NET_NFS* because someone decided
to reuse the NFS acronym?
> And this sounds like a good idea:
> - tristate "The RDS Protocol"
> + tristate "The Reliable Datagram Sockets (RDS) Protocol"
surn that sounds fine.
--Sowmini
^ permalink raw reply
* Re: KCM - recvmsg() mangles packets?
From: Dominique Martinet @ 2018-08-05 6:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <20180804020806.GA32338@nautica>
Dominique Martinet wrote on Sat, Aug 04, 2018:
> I talked too fast, I can get this to fail on later packets e.g.
> Got 18, expected 31 on 452nd message: 453453453453453453; flags: 80
>
> The content is 453 in a loop so this really is the 453rd packet...
>
> But being slower e.g. doing that usleep after every single packets and I
> could let the loop run until 100k without a hintch.
>
>
> There really has to be something wrong, I just can't tell what from
> looking at the code with my naive eyes.
I've spent a few hours debugging this weekend, I'm still not confident I
understand how this all works but it's a bit better than Friday.
I've tried updating kcm_recvmsg()'s use of kcm_wait_data() to use
skb_dequeue() instead of skb_peek(), with the idea that if the skb is
off the list it would have less chance to be messed with, and that
didn't seem to change anything so I was probably looking at the wrong
place.
So I went one step up to how we split the packet and the interface with
strparser and added an extra check of the protocol in kcm_rcv_strparser.
If I understand correctly, with stm = strp_msg(skb), stm->full_len
contains the output of the bpf progran and must match something like
this in the network byte-order version:
ntohl(*((u32 *)(skb->data + stm->offset)))
(I'm not sure about offset, since we pass the full skb to parse message,
wouldn't it look at the start of the buffer everytime? Well, offset
seems to be 0 everytime the first time that check fails so I can
probably ignore that for now...)
Just like the test program, that extra check seems to work but will fail
everytime the test program detects and error, although the data I can
see does not always match what the program sees, the packet would seem
to already be incorrect when it is added to the kcm queue... So there
must be something happening to the skb between parse_msg() and rcv_msg()
in __strp_recv() ...?
>From what I can see it's looking at a cloned skb so the headers are
private but the data is shared, but it looks like the tcp socket (csock
in kcm_attach) is properly locked at this time, so I'm not sure what
could corrupt the buffer.
I'll keep looking at this a bit more but any help is appreciated,
Thanks,
--
Dominique Martinet | Asmadeus
^ permalink raw reply
* pull request: bluetooth-next 2018-08-05
From: Johan Hedberg @ 2018-08-05 6:14 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 7167 bytes --]
Hi Dave,
Here's the main bluetooth-next pull request for the 4.19 kernel.
- Added support for Bluetooth Advertising Extensions
- Added vendor driver support to hci_h5 HCI driver
- Added serdev support to hci_h5 driver
- Added support for Qualcomm wcn3990 controller
- Added support for RTL8723BS and RTL8723DS controllers
- btusb: Added new ID for Realtek 8723DE
- Several other smaller fixes & cleanups
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit ab8565af68001ac5f9331daa311938ead3eb5636:
Merge branch 'IP-listification-follow-ups' (2018-07-06 11:19:08 +0900)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to 6c3711ec64fd23a9abc8aaf59a9429569a6282df:
Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV (2018-08-04 23:23:32 +0200)
----------------------------------------------------------------
Amit K Bag (1):
Bluetooth: btusb: Release RF resource on BT shutdown
Ankit Navik (2):
Bluetooth: Store Resolv list size
Bluetooth: Add HCI command for clear Resolv list
Balakrishna Godavarthi (7):
dt-bindings: net: bluetooth: Add device tree bindings for QTI chip wcn3990
Bluetooth: btqca: Rename ROME specific functions to generic functions
Bluetooth: btqca: Redefine qca_uart_setup() to generic function.
Bluetooth: hci_qca: Add wrapper functions for setting UART speed
Bluetooth: hci_qca: Enable 3.2 Mbps operating speed.
Bluetooth: btqca: Add wcn3990 firmware download support.
Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990
Corentin Labbe (1):
Bluetooth: remove unused bt-nokia-h4p.h header
Hans de Goede (4):
Bluetooth: btrtl: Use rtl_dev_err and rtl_dev_info
Bluetooth: btrtl: Add support for a config filename postfix
Bluetooth: hci_h5: Add support for serdev enumerated devices
Bluetooth: hci_h5: Add support for enable and device-wake GPIOs
Jaganath Kanakkassery (21):
Bluetooth: Introduce helpers for LE set scan start and complete
Bluetooth: Use extended scanning if controller supports
Bluetooth: Process extended ADV report event
Bluetooth: Introduce helpers for le conn status and complete
Bluetooth: Use extended LE Connection if supported
Bluetooth: Define PHY flags in hdev and set 1M as default
Bluetooth: Add defines for BREDR pkt_type and LE PHYs
Bluetooth: Implement Get PHY Configuration mgmt command
Bluetooth: Implement Set PHY Confguration command
Bluetooth: Implement PHY changed event
Bluetooth: Set Scan PHYs based on selected PHYs by user
Bluetooth: Handle extended ADV PDU types
Bluetooth: Use selected PHYs in extended connect
Bluetooth: Read no of adv sets during init
Bluetooth: Impmlement extended adv enable
Bluetooth: Use Set ext adv/scan rsp data if controller supports
Bluetooth: Implement disable and removal of adv instance
Bluetooth: Use ext adv for directed adv
Bluetooth: Implement Set ADV set random address
Bluetooth: Handle ADv set terminated event
Bluetooth: Implement secondary advertising on different PHYs
Jeremy Cline (2):
Bluetooth: hci_h5: Add vendor setup, open, and close callbacks
Bluetooth: hci_h5: Add support for the RTL8723BS
Jia-Ju Bai (7):
bluetooth: bfusb: Replace GFP_ATOMIC with GFP_KERNEL in bfusb_send_frame()
bluetooth: bluecard_cs: Replace GFP_ATOMIC with GFP_KERNEL in bluecard_hci_set_baud_rate()
bluetooth: bpa10x: Replace GFP_ATOMIC with GFP_KERNEL in bpa10x_send_frame()
bluetooth: btmrvl_sdio: Replace GFP_ATOMIC with GFP_KERNEL in btmrvl_sdio_card_to_host()
bluetooth: btusb: Replace GFP_ATOMIC with GFP_KERNEL in inject_cmd_complete()
bluetooth: hci_intel: Replace GFP_ATOMIC with GFP_KERNEL in inject_cmd_complete()
bluetooth: hci_qca: Replace GFP_ATOMIC with GFP_KERNEL
Jian-Hong Pan (1):
Bluetooth: Add a new Realtek 8723DE ID 0bda:b009
Johan Hedberg (1):
Bluetooth: h5: Fix missing dependency on BT_HCIUART_SERDEV
Marcel Holtmann (2):
Bluetooth: hidp: Fix handling of strncpy for hid->name information
Bluetooth: btusb: Use bt_dev_err for Intel firmware loading errors
Mark Salyzyn (1):
Bluetooth: hidp: buffer overflow in hidp_process_report
Martin Blumenstingl (4):
Bluetooth: btrtl: add MODULE_FIRMWARE declarations
Bluetooth: btrtl: split the device initialization into smaller parts
Bluetooth: btrtl: add support for retrieving the UART settings
Bluetooth: btrtl: add support for the RTL8723BS and RTL8723DS chips
Michael Scott (1):
6lowpan: iphc: reset mac_header after decompress to fix panic
Philipp Puschmann (1):
Bluetooth: Use lock_sock_nested in bt_accept_enqueue
Sean Wang (1):
Bluetooth: Add new quirk for non-persistent setup settings
Sebastian Andrzej Siewior (1):
Bluetooth: btusb: use irqsave() in URB's complete callback
Sudip Mukherjee (1):
Bluetooth: avoid killing an already killed socket
.../devicetree/bindings/net/qualcomm-bluetooth.txt | 29 +-
drivers/bluetooth/Kconfig | 1 +
drivers/bluetooth/bfusb.c | 2 +-
drivers/bluetooth/bluecard_cs.c | 2 +-
drivers/bluetooth/bpa10x.c | 6 +-
drivers/bluetooth/btmrvl_sdio.c | 2 +-
drivers/bluetooth/btqca.c | 117 ++--
drivers/bluetooth/btqca.h | 22 +-
drivers/bluetooth/btrtl.c | 512 ++++++++++++-----
drivers/bluetooth/btrtl.h | 53 ++
drivers/bluetooth/btusb.c | 116 ++--
drivers/bluetooth/hci_h5.c | 202 ++++++-
drivers/bluetooth/hci_intel.c | 2 +-
drivers/bluetooth/hci_qca.c | 490 ++++++++++++++--
include/linux/platform_data/bt-nokia-h4p.h | 38 --
include/net/bluetooth/hci.h | 219 ++++++++
include/net/bluetooth/hci_core.h | 34 ++
include/net/bluetooth/mgmt.h | 55 ++
net/6lowpan/iphc.c | 1 +
net/bluetooth/af_bluetooth.c | 2 +-
net/bluetooth/hci_conn.c | 189 +++++--
net/bluetooth/hci_core.c | 105 +++-
net/bluetooth/hci_debugfs.c | 19 +
net/bluetooth/hci_event.c | 554 +++++++++++++++---
net/bluetooth/hci_request.c | 616 ++++++++++++++++++---
net/bluetooth/hci_request.h | 8 +
net/bluetooth/hidp/core.c | 6 +-
net/bluetooth/mgmt.c | 405 +++++++++++++-
net/bluetooth/sco.c | 3 +-
29 files changed, 3236 insertions(+), 574 deletions(-)
delete mode 100644 include/linux/platform_data/bt-nokia-h4p.h
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH net-next 3/3] mlxsw: spectrum: Configure MC-aware mode on mlxsw ports
From: Ido Schimmel @ 2018-08-05 6:03 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180805060308.7862-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
In order to give unicast traffic precedence over BUM traffic, configure
multicast-aware mode on all ports.
Under multicast-aware regime, when assigning traffic class to a packet,
the switch doesn't merely take the value prescribed by the QTCT
register. For BUM traffic, it instead assigns that value plus 8.
ETS elements for TCs 8..15 thus need to be configured as well. Extend
mlxsw_sp_port_ets_init() so that it maps each of them to the same
subgroup as their corresponding TC from the range 0..7, such that TCs X
and X+8 map to the same subgroup.
The existing code configures TCs with strict priority. So far this was
immaterial, because each TC had its own subgroup. Now that two TCs share
a subgroup it becomes important. TCs are prioritized in order of 7, 6,
..., 0, 15, 14, ..., 8: the higher TCs used for BUM traffic end up being
deprioritized. Since that's what's needed, keep that configuration as it
is, and configure the new TCs likewise.
Finally in mlxsw_sp_port_create(), invoke configuration of QTCTM to
enable MC-aware mode on each port.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum.c | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 42312ff57b7e..e0aa0e5c65b2 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2760,6 +2760,13 @@ static int mlxsw_sp_port_ets_init(struct mlxsw_sp_port *mlxsw_sp_port)
false, 0);
if (err)
return err;
+
+ err = mlxsw_sp_port_ets_set(mlxsw_sp_port,
+ MLXSW_REG_QEEC_HIERARCY_TC,
+ i + 8, i,
+ false, 0);
+ if (err)
+ return err;
}
/* Make sure the max shaper is disabled in all hierarchies that
@@ -2797,6 +2804,16 @@ static int mlxsw_sp_port_ets_init(struct mlxsw_sp_port *mlxsw_sp_port)
return 0;
}
+static int mlxsw_sp_port_tc_mc_mode_set(struct mlxsw_sp_port *mlxsw_sp_port,
+ bool enable)
+{
+ struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
+ char qtctm_pl[MLXSW_REG_QTCTM_LEN];
+
+ mlxsw_reg_qtctm_pack(qtctm_pl, mlxsw_sp_port->local_port, enable);
+ return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(qtctm), qtctm_pl);
+}
+
static int mlxsw_sp_port_create(struct mlxsw_sp *mlxsw_sp, u8 local_port,
bool split, u8 module, u8 width, u8 lane)
{
@@ -2925,6 +2942,13 @@ static int mlxsw_sp_port_create(struct mlxsw_sp *mlxsw_sp, u8 local_port,
goto err_port_ets_init;
}
+ err = mlxsw_sp_port_tc_mc_mode_set(mlxsw_sp_port, true);
+ if (err) {
+ dev_err(mlxsw_sp->bus_info->dev, "Port %d: Failed to initialize TC MC mode\n",
+ mlxsw_sp_port->local_port);
+ goto err_port_tc_mc_mode;
+ }
+
/* ETS and buffers must be initialized before DCB. */
err = mlxsw_sp_port_dcb_init(mlxsw_sp_port);
if (err) {
@@ -2981,6 +3005,8 @@ static int mlxsw_sp_port_create(struct mlxsw_sp *mlxsw_sp, u8 local_port,
err_port_fids_init:
mlxsw_sp_port_dcb_fini(mlxsw_sp_port);
err_port_dcb_init:
+ mlxsw_sp_port_tc_mc_mode_set(mlxsw_sp_port, false);
+err_port_tc_mc_mode:
err_port_ets_init:
err_port_buffers_init:
err_port_admin_status_set:
@@ -3015,6 +3041,7 @@ static void mlxsw_sp_port_remove(struct mlxsw_sp *mlxsw_sp, u8 local_port)
mlxsw_sp_tc_qdisc_fini(mlxsw_sp_port);
mlxsw_sp_port_fids_fini(mlxsw_sp_port);
mlxsw_sp_port_dcb_fini(mlxsw_sp_port);
+ mlxsw_sp_port_tc_mc_mode_set(mlxsw_sp_port, false);
mlxsw_sp_port_swid_set(mlxsw_sp_port, MLXSW_PORT_SWID_DISABLED_PORT);
mlxsw_sp_port_module_unmap(mlxsw_sp_port);
kfree(mlxsw_sp_port->sample);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 2/3] mlxsw: spectrum: Fix a typo
From: Ido Schimmel @ 2018-08-05 6:03 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180805060308.7862-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index b509e8c030ce..42312ff57b7e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2762,7 +2762,7 @@ static int mlxsw_sp_port_ets_init(struct mlxsw_sp_port *mlxsw_sp_port)
return err;
}
- /* Make sure the max shaper is disabled in all hierarcies that
+ /* Make sure the max shaper is disabled in all hierarchies that
* support it.
*/
err = mlxsw_sp_port_ets_maxrate_set(mlxsw_sp_port,
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 1/3] mlxsw: reg: Add QoS Switch Traffic Class Table is Multicast-Aware Register
From: Ido Schimmel @ 2018-08-05 6:03 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
In-Reply-To: <20180805060308.7862-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
This register configures if the Switch Priority to Traffic Class mapping
is based on Multicast packet indication. If so, then multicast packets
will get a Traffic Class that is plus (cap_max_tclass_data/2) the value
configured by QTCT.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/reg.h | 37 +++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/reg.h b/drivers/net/ethernet/mellanox/mlxsw/reg.h
index e2e2f897e98e..6e8b619b769b 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/reg.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/reg.h
@@ -3509,6 +3509,42 @@ mlxsw_reg_qpdpm_dscp_pack(char *payload, unsigned short dscp, u8 prio)
mlxsw_reg_qpdpm_dscp_entry_prio_set(payload, dscp, prio);
}
+/* QTCTM - QoS Switch Traffic Class Table is Multicast-Aware Register
+ * ------------------------------------------------------------------
+ * This register configures if the Switch Priority to Traffic Class mapping is
+ * based on Multicast packet indication. If so, then multicast packets will get
+ * a Traffic Class that is plus (cap_max_tclass_data/2) the value configured by
+ * QTCT.
+ * By default, Switch Priority to Traffic Class mapping is not based on
+ * Multicast packet indication.
+ */
+#define MLXSW_REG_QTCTM_ID 0x401A
+#define MLXSW_REG_QTCTM_LEN 0x08
+
+MLXSW_REG_DEFINE(qtctm, MLXSW_REG_QTCTM_ID, MLXSW_REG_QTCTM_LEN);
+
+/* reg_qtctm_local_port
+ * Local port number.
+ * No support for CPU port.
+ * Access: Index
+ */
+MLXSW_ITEM32(reg, qtctm, local_port, 0x00, 16, 8);
+
+/* reg_qtctm_mc
+ * Multicast Mode
+ * Whether Switch Priority to Traffic Class mapping is based on Multicast packet
+ * indication (default is 0, not based on Multicast packet indication).
+ */
+MLXSW_ITEM32(reg, qtctm, mc, 0x04, 0, 1);
+
+static inline void
+mlxsw_reg_qtctm_pack(char *payload, u8 local_port, bool mc)
+{
+ MLXSW_REG_ZERO(qtctm, payload);
+ mlxsw_reg_qtctm_local_port_set(payload, local_port);
+ mlxsw_reg_qtctm_mc_set(payload, mc);
+}
+
/* PMLP - Ports Module to Local Port Register
* ------------------------------------------
* Configures the assignment of modules to local ports.
@@ -8726,6 +8762,7 @@ static const struct mlxsw_reg_info *mlxsw_reg_infos[] = {
MLXSW_REG(qrwe),
MLXSW_REG(qpdsm),
MLXSW_REG(qpdpm),
+ MLXSW_REG(qtctm),
MLXSW_REG(pmlp),
MLXSW_REG(pmtu),
MLXSW_REG(ptys),
--
2.17.1
^ permalink raw reply related
* [PATCH net-next 0/3] mlxsw: Enable MC-aware mode for mlxsw ports
From: Ido Schimmel @ 2018-08-05 6:03 UTC (permalink / raw)
To: netdev; +Cc: davem, jiri, petrm, mlxsw, Ido Schimmel
Petr says:
Due to an issue in Spectrum chips, when unicast traffic shares the same
queue as BUM traffic, and there is a congestion, the BUM traffic is
admitted to the queue anyway, thus pushing out all UC traffic. In order
to give unicast traffic precedence over BUM traffic, configure
multicast-aware mode on all ports.
Under multicast-aware regime, when assigning traffic class to a packet,
the switch doesn't merely take the value prescribed by the QTCT
register. For BUM traffic, it instead assigns that value plus 8. That
limits the number of available TCs, but since mlxsw currently only uses
the lower eight anyway, it is no real loss.
The two TCs (UC and MC one) are then mapped to the same subgroup and
strictly prioritized so that UC traffic is preferred in case of
congestion.
In patch #1, introduce a new register, QTCTM, which enables the
multicast-aware mode.
In patch #2, fix a typo in related code.
In patch #3, set up TCs and QTCTM to enable multicast-aware mode.
Petr Machata (3):
mlxsw: reg: Add QoS Switch Traffic Class Table is Multicast-Aware
Register
mlxsw: spectrum: Fix a typo
mlxsw: spectrum: Configure MC-aware mode on mlxsw ports
drivers/net/ethernet/mellanox/mlxsw/reg.h | 37 +++++++++++++++++++
.../net/ethernet/mellanox/mlxsw/spectrum.c | 29 ++++++++++++++-
2 files changed, 65 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* Re: WARNING: ODEBUG bug in rfcomm_dlc_free
From: syzbot @ 2018-08-05 5:59 UTC (permalink / raw)
To: davem, johan.hedberg, keescook, linux-bluetooth, linux-kernel,
marcel, netdev, syzkaller-bugs
In-Reply-To: <00000000000086f39e057245c3ac@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 116b181bb646 Add linux-next specific files for 20180803
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1010268c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b4f38be7c2c519d5
dashboard link: https://syzkaller.appspot.com/bug?extid=1f6d4ad860c650c2f215
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=101200e2400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=121d3bdc400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1f6d4ad860c650c2f215@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
urandom_read: 1 callbacks suppressed
random: sshd: uninitialized urandom read (32 bytes read)
------------[ cut here ]------------
ODEBUG: free active (active state 0) object type: timer_list hint:
rfcomm_dlc_timeout+0x0/0x70 include/linux/list.h:64
WARNING: CPU: 0 PID: 4267 at lib/debugobjects.c:329
debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4267 Comm: syz-executor929 Not tainted
4.18.0-rc7-next-20180803+ #31
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
panic+0x238/0x4e7 kernel/panic.c:184
__warn.cold.8+0x163/0x1ba kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:996
RIP: 0010:debug_print_object+0x16a/0x210 lib/debugobjects.c:326
Code: 3a 87 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 92 00 00 00 48 8b 14 dd
60 a8 3a 87 4c 89 f6 48 c7 c7 00 9e 3a 87 e8 26 70 e2 fd <0f> 0b 83 05 09
33 26 05 01 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f
RSP: 0018:ffff8801b686f648 EFLAGS: 00010086
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff816366f1 RDI: 0000000000000001
RBP: ffff8801b686f688 R08: ffff8801cb852380 R09: ffffed003b603ec2
R10: ffffed003b603ec2 R11: ffff8801db01f617 R12: 0000000000000001
R13: ffffffff87f9d1c0 R14: ffffffff873aa2a0 R15: ffffffff816988b0
__debug_check_no_obj_freed lib/debugobjects.c:786 [inline]
debug_check_no_obj_freed+0x3b2/0x595 lib/debugobjects.c:818
kfree+0xc7/0x260 mm/slab.c:3812
rfcomm_dlc_free+0x1e/0x30 net/bluetooth/rfcomm/core.c:328
rfcomm_dlc_put include/net/bluetooth/rfcomm.h:258 [inline]
__rfcomm_create_dev net/bluetooth/rfcomm/tty.c:417 [inline]
rfcomm_create_dev net/bluetooth/rfcomm/tty.c:486 [inline]
rfcomm_dev_ioctl+0x1dfe/0x2240 net/bluetooth/rfcomm/tty.c:588
rfcomm_sock_ioctl+0x89/0xb0 net/bluetooth/rfcomm/sock.c:902
sock_do_ioctl+0xe4/0x3e0 net/socket.c:950
sock_ioctl+0x30d/0x680 net/socket.c:1074
vfs_ioctl fs/ioctl.c:46 [inline]
file_ioctl fs/ioctl.c:501 [inline]
do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
__do_sys_ioctl fs/ioctl.c:709 [inline]
__se_sys_ioctl fs/ioctl.c:707 [inline]
__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4406d9
Code: e8 2c af 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 3b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff697e60e8 EFLAGS: 00000213 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004406d9
RDX: 0000000020000000 RSI: 00000000400452c8 RDI: 0000000000000003
RBP: 0000000000000000 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000013d1880 R11: 0000000000000213 R12: 0000000000009731
R13: 0000000000401c30 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2018-08-05 7:47 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Handle frames in error situations properly in AF_XDP, from Jakub
Kicinski.
2) tcp_mmap test case only tests ipv6 due to a thinko, fix from
Maninder Singh.
3) Session refcnt fix in l2tp_ppp, from Guillaume Nault.
4) Fix regression in netlink bind handling of multicast
gruops, from Dmitry Safonov.
Please pull, thanks a lot!
The following changes since commit e30cb13c5a09ff5f043a6570c32e49b063bea6a1:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-08-02 10:12:02 -0700)
are available in the Git repository at:
gitolite@ra.kernel.org:/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 91874ecf32e41b5d86a4cb9d60e0bee50d828058:
netlink: Don't shift on 64 for ngroups (2018-08-04 17:52:51 -0700)
----------------------------------------------------------------
Colin Ian King (1):
drivers: net: lmc: fix case value for target abort error
David S. Miller (2):
Merge branch 'mlxsw-Fix-ACL-actions-error-condition-handling'
Merge git://git.kernel.org/.../bpf/bpf
Dmitry Safonov (1):
netlink: Don't shift on 64 for ngroups
Guillaume Nault (1):
l2tp: fix missing refcount drop in pppol2tp_tunnel_ioctl()
Jakub Kicinski (1):
net: xsk: don't return frames via the allocator on error
Maninder Singh (1):
selftest/net: fix protocol family to work for IPv4.
Mathieu Xhonneux (1):
selftests/bpf: update test_lwt_seg6local.sh according to iproute2
Nir Dotan (4):
mlxsw: core_acl_flex_actions: Return error for conflicting actions
mlxsw: core_acl_flex_actions: Remove redundant resource destruction
mlxsw: core_acl_flex_actions: Remove redundant counter destruction
mlxsw: core_acl_flex_actions: Remove redundant mirror resource destruction
Ursula Braun (1):
net/smc: no cursor update send in state SMC_INIT
Yonghong Song (1):
tools/bpftool: fix a percpu_array map dump problem
drivers/net/ethernet/mellanox/mlxsw/core_acl_flex_actions.c | 51 +++++++++++++++++++++++++++++----------------------
drivers/net/wan/lmc/lmc_main.c | 2 +-
net/l2tp/l2tp_ppp.c | 13 +++++++++----
net/netlink/af_netlink.c | 4 ++--
net/smc/smc_cdc.c | 3 ++-
net/xdp/xsk.c | 4 +---
tools/bpf/bpftool/map.c | 14 +++++++++-----
tools/testing/selftests/bpf/test_lwt_seg6local.sh | 6 +++---
tools/testing/selftests/net/tcp_mmap.c | 2 +-
9 files changed, 57 insertions(+), 42 deletions(-)
^ permalink raw reply
* [PATCH] RDS is not Radio Data System
From: Pavel Machek @ 2018-08-05 6:59 UTC (permalink / raw)
To: ka-cheong.poon, santosh.shilimkar, kernel list, Netdev list; +Cc: Netdev list
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Hi!
Getting prompt "The RDS Protocol" (RDS) is not too helpful, and it is
easily confused with Radio Data System (which we may want to support
in kernel, too).
I wonder if option should be named NET_RDS, instead?
And this sounds like a good idea:
(Plus, we normally have "module will be called foobar" and if unsure
say X. What happened to those?)
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 41f7556..2738f14 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -1,6 +1,6 @@
config RDS
- tristate "The RDS Protocol"
+ tristate "The Reliable Datagram Sockets (RDS) Protocol"
depends on INET
---help---
The RDS (Reliable Datagram Sockets) protocol provides reliable,
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* rmnet_data multicast support
From: Harsha Chenji @ 2018-08-05 1:52 UTC (permalink / raw)
To: netdev
Hi all,
We are using the rmnet_data interface on a Google Pixel phone
connected to our LTE network.
The aim is to send/receive multicast traffic (224.0.0.1) over this
point-to-point, NOARP link between the phone and (effectively) the LTE
EPC which acts as the IP router for the phone. Since there is no
Ethernet/MAC addresses in LTE user traffic, this is a Layer 3
multicast so things should work. Note that we are not using eMBMS
which is part of the LTE spec, this is just IP layer point-to-point
multicast (the LTE base station will not send this packet to all
connected phones unless it's over eMBMS).
The OS/kernel is lineageos 15.1, here is the source:
https://github.com/LineageOS/android_kernel_google_marlin .
However, despite enabling IFF_BROADCAST, IFF_MULTICAST and IFF_NOARP
flags at the time of netdev creation in the rmnet driver, we still
cannot receive any multicast traffic. I can see the packets being
transmitted by the EPC to the phone over wireshark. But when I run
tcpdump on the phone (even after ifconfig promisc mode), nothing shows
up!
Could I know how to debug/troubleshoot this situation? Is the MSM
chipset somehow dropping multicast traffic internally before it
reaches the kernel? rmnet_data_debug is compiled into the kernel,
maybe it can help debug - how do I enable it at runtime? Should I add
rmnet_data.dump_rx_pkt to the kernel bootargs?
Thanks for your time and help,
Harsha
sailfish:/ # cat /proc/net/igmp
Idx Device : Count Querier Group Users Timer Reporter
1 lo : 1 V3
010000E0 1 0:00000000 0
3 dummy0 : 1 V3
010000E0 1 0:00000000 0
5 rmnet_ipa0: 1 V3
010000E0 1 0:00000000 0
6 rmnet_data0: 1 V3
010000E0 1 0:00000000 0
23 wlan0 : 1 V3
010000E0 1 0:00000000 0
24 p2p0 : 1 V3
010000E0 1 0:00000000 0
$ adb shell ip maddress
1: lo
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
2: bond0
link 33:33:00:00:00:01
inet6 ff02::1
inet6 ff01::1
3: dummy0
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
4: sit0
inet6 ff02::1
inet6 ff01::1
5: rmnet_ipa0:
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
6: rmnet_data0:
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
7: rmnet_data1
inet6 ff02::1
inet6 ff01::1
8: rmnet_data2
inet6 ff02::1
inet6 ff01::1
9: rmnet_data3
inet6 ff02::1
inet6 ff01::1
10: rmnet_data4
inet6 ff02::1
inet6 ff01::1
11: rmnet_data5
inet6 ff02::1
inet6 ff01::1
12: rmnet_data6
inet6 ff02::1
inet6 ff01::1
13: rmnet_data7
inet6 ff02::1
inet6 ff01::1
14: r_rmnet_data0
inet6 ff02::1
inet6 ff01::1
15: r_rmnet_data1
inet6 ff02::1
inet6 ff01::1
16: r_rmnet_data2
inet6 ff02::1
inet6 ff01::1
17: r_rmnet_data3
inet6 ff02::1
inet6 ff01::1
18: r_rmnet_data4
inet6 ff02::1
inet6 ff01::1
19: r_rmnet_data5
inet6 ff02::1
inet6 ff01::1
20: r_rmnet_data6
inet6 ff02::1
inet6 ff01::1
21: r_rmnet_data7
inet6 ff02::1
inet6 ff01::1
22: r_rmnet_data8
inet6 ff02::1
inet6 ff01::1
23: wlan0
link 01:00:5e:00:00:01
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
24: p2p0
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet 224.0.0.1
inet6 ff02::1
inet6 ff01::1
^ permalink raw reply
* Linux kernel error stack
From: Satish Patel @ 2018-08-05 1:24 UTC (permalink / raw)
To: netdev
Folks,
I am installing openstack and as you know i have lots of bridges and
vlan interface on my Linux CentOS 7.5
I was getting following error stack on 3.10 kernel and found this is
kernel bug which required kernel upgrade so now i have upgraded my
kernel to 4.17.12 but i am still seeing same kernel stack error on my
dmesg
I have disable TSO, LRO, SG & GSO on my NIC but still getting error
just wanted to understand what is this and why it popping up
[ 8177.718745] ------------[ cut here ]------------
[ 8177.718748] lxcbr0: caps=(0x00000801ffc070a8, 0x0000000000000000)
len=7292 data_len=7240 gso_size=1448 gso_type=1 ip_summed=3
[ 8177.718756] WARNING: CPU: 21 PID: 139 at net/core/dev.c:2662
skb_warn_bad_offload+0xd8/0xef
[ 8177.718757] Modules linked in: ebtable_filter ebtable_nat tcp_diag
udp_diag inet_diag unix_diag btrfs xor zstd_decompress zstd_compress
xxhash raid6_pq loop iptable_raw veth bonding ip6table_mangle
xt_CHECKSUM rpcrdma sunrpc ib_isert iscsi_target_mod ib_iser ib_srpt
target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_uverbs
ib_umad rdma_cm ib_cm iw_cm sb_edac x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd cryptd
glue_helper intel_cstate intel_rapl_perf iTCO_wdt iTCO_vendor_support
ocrdma ib_core joydev input_leds pcspkr ipmi_si hpwdt be2iscsi lpc_ich
ipmi_devintf sg hpilo mfd_core ipmi_msghandler video acpi_power_meter
iscsi_boot_sysfs ioatdma shpchp dca pcc_cpufreq xfs sd_mod mgag200
[ 8177.718807] i2c_algo_bit serio_raw drm_kms_helper syscopyarea
sysfillrect sysimgblt fb_sys_fops ttm drm hpsa scsi_transport_sas
be2net dm_mirror dm_region_hash dm_log vhost_net tun tap vhost
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_vs iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_mangle
iptable_filter ipt_REJECT nf_reject_ipv4 ipt_MASQUERADE
nf_nat_masquerade_ipv4 nf_nat nf_conntrack libcrc32c crc32c_intel
ip6table_filter ip6_tables ebtables dm_snapshot dm_bufio dm_multipath
dm_mod 8021q garp mrp ip_tables
[ 8177.718833] CPU: 21 PID: 139 Comm: ksoftirqd/21 Tainted: G W
4.17.12-1.el7.elrepo.x86_64 #1
[ 8177.718833] Hardware name: HP ProLiant BL460c Gen8, BIOS I31 06/01/2015
[ 8177.718835] RIP: 0010:skb_warn_bad_offload+0xd8/0xef
[ 8177.718836] RSP: 0000:ffffc90003797470 EFLAGS: 00010282
[ 8177.718837] RAX: 0000000000000000 RBX: ffff8807aaa09c00 RCX: 0000000000000006
[ 8177.718838] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff88042f8d69d0
[ 8177.718840] RBP: ffffc900037974a0 R08: 0000000000000000 R09: 0000000000000d96
[ 8177.718840] R10: 0000000000000003 R11: 0000000000000d95 R12: ffff88082a035000
[ 8177.718841] R13: 0000000000000003 R14: ffff8807aaa09c00 R15: ffffffffa0004618
[ 8177.718843] FS: 0000000000000000(0000) GS:ffff88042f8c0000(0000)
knlGS:0000000000000000
[ 8177.718844] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8177.718845] CR2: 000055ac69aea158 CR3: 000000000220a001 CR4: 00000000001606e0
[ 8177.718846] Call Trace:
[ 8177.718849] skb_checksum_help+0x1a5/0x1c0
[ 8177.718851] checksum_tg+0x22/0x29 [xt_CHECKSUM]
[ 8177.718854] ipt_do_table+0x2e7/0x630 [ip_tables]
[ 8177.718858] ? br_dev_queue_push_xmit+0x170/0x170
[ 8177.718860] ? br_forward+0x92/0xa0
[ 8177.718862] ? br_dev_xmit+0x23f/0x3c0
[ 8177.718865] iptable_mangle_hook+0x37/0xf0 [iptable_mangle]
[ 8177.718868] nf_hook_slow+0x42/0xc0
[ 8177.718870] ip_output+0xd0/0xe0
[ 8177.718873] ? ip_fragment.constprop.49+0x80/0x80
[ 8177.718875] ip_forward_finish+0x49/0x70
[ 8177.718877] ip_forward+0x388/0x470
[ 8177.718880] ? pskb_trim_rcsum.part.11+0x4c/0x4c
[ 8177.718882] ip_rcv_finish+0x120/0x400
[ 8177.718885] ip_sabotage_in+0x35/0x40
[ 8177.718888] nf_hook_slow+0x42/0xc0
[ 8177.718890] ip_rcv+0x32f/0x410
[ 8177.718892] ? inet_del_offload+0x40/0x40
[ 8177.718895] __netif_receive_skb_core+0x401/0xb10
[ 8177.718896] ? poll_idle+0x90/0x9a
[ 8177.718898] ? ebt_do_table+0x663/0x73a [ebtables]
[ 8177.718901] __netif_receive_skb+0x18/0x60
[ 8177.718903] netif_receive_skb_internal+0x45/0xf0
[ 8177.718904] netif_receive_skb+0x1c/0x70
[ 8177.718906] br_netif_receive_skb+0x28/0x60
[ 8177.718909] br_pass_frame_up+0xcd/0x160
[ 8177.718913] ? __br_handle_local_finish+0xa0/0xa0
[ 8177.718915] br_handle_frame_finish+0x23a/0x450
[ 8177.718917] ? br_pass_frame_up+0x160/0x160
[ 8177.718919] br_nf_hook_thresh+0xdf/0xf0
[ 8177.718922] ? br_pass_frame_up+0x160/0x160
[ 8177.718924] br_nf_pre_routing_finish+0x1a1/0x380
[ 8177.718926] ? br_pass_frame_up+0x160/0x160
[ 8177.718928] ? nf_nat_ipv4_in+0x2e/0x80 [nf_nat_ipv4]
[ 8177.718930] ? iptable_nat_ipv4_in+0x15/0x20 [iptable_nat]
[ 8177.718932] br_nf_pre_routing+0x2d6/0x3f0
[ 8177.718934] ? br_nf_forward_arp+0x270/0x270
[ 8177.718936] nf_hook_slow+0x42/0xc0
[ 8177.718939] br_handle_frame+0x1ef/0x300
[ 8177.718941] ? br_pass_frame_up+0x160/0x160
[ 8177.718945] __netif_receive_skb_core+0x20d/0xb10
[ 8177.718947] ? dev_gro_receive+0x2ca/0x5a0
[ 8177.718949] __netif_receive_skb+0x18/0x60
[ 8177.718950] netif_receive_skb_internal+0x45/0xf0
[ 8177.718953] ? tcp4_gro_complete+0x86/0x90
[ 8177.718954] napi_gro_complete+0x73/0x90
[ 8177.718955] napi_gro_flush+0x5f/0x80
[ 8177.718957] napi_complete_done+0x96/0xe0
[ 8177.718960] be_poll+0x1b3/0x320 [be2net]
[ 8177.718962] net_rx_action+0x289/0x3f0
^ permalink raw reply
* Re: consequences of setting net_device_ops ndo_change_carrier()?
From: Andrew Lunn @ 2018-08-05 1:11 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux kernel ntedev mailing list
In-Reply-To: <alpine.LFD.2.21.1808040646290.25800@localhost.localdomain>
On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote:
>
> i'll try to keep this (relatively) short as there may be a simple
> answer to this, or it could just be a stupid question -- sort of
> related to previous question (thank you, florian).
>
> currently messing with networking device involving FPGA and some
> quad-port transceivers, and noticed that, when one unplugs or plugs a
> device into one of the ports, there is no change in the contents of
> the corresponding sysfs files /sys/class/net/<ifname>/carrier (or
> operstate, for that matter, which might be related to this as well).
Hi Robert
As other have pointed out, ndo_change_carrier is not what you want
here.
You should have a PHY device of some sort. Either a traditional copper
PHY, or an SFP module. There should be a driver for this PHY. This
could be one of those in drivers/net/phy. Or it could be firmware
running, running on a little microcontroller inside your FPGA?
Assuming you are using a Linux phy driver, it will keep an eye on the
state of the Link. If the cable is unplugged, the other end downs its
interface, etc. it will notice the change in state. The core phy code,
aka. phylib, will then call netif_carrier_off() and it will call the
MAC callback which was registers when the MAC driver called one of the
phy_connect() variants. The same happens when the link goes up. If you
are using an SFP module, it is a little but more complex, and you
should look at phylink.
If you have firmware managing the PHY, (not recommended, goes against
the principals of open source, nobody can help you debug it, or fix
it, costs you more in the long run, blah, blah, blah), the MAC driver
should be informed, probably by an interrupt and a status
register. The MAC driver should then call netif_carrier_off|on as
needed.
Andrew
^ permalink raw reply
* Re: pull-request: bpf 2018-08-05
From: David Miller @ 2018-08-05 0:53 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <20180805002611.19611-1-daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 5 Aug 2018 02:26:11 +0200
> The following pull-request contains BPF updates for your *net* tree.
>
> The main changes are:
>
> 1) Fix bpftool percpu_array dump by using correct roundup to next
> multiple of 8 for the value size, from Yonghong.
>
> 2) Fix in AF_XDP's __xsk_rcv_zc() to not returning frames back to
> allocator since driver will recycle frame anyway in case of an
> error, from Jakub.
>
> 3) Fix up BPF test_lwt_seg6local test cases to final iproute2
> syntax, from Mathieu.
>
> Please consider pulling these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next] virtio-net: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-08-05 2:42 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, David S. Miller
Cc: virtualization, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1402059 ("Missing break in switch")
Addresses-Coverity-ID: 1402060 ("Missing break in switch")
Addresses-Coverity-ID: 1402061 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/virtio_net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 14f661c..62311dd 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -697,6 +697,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
goto xdp_xmit;
default:
bpf_warn_invalid_xdp_action(act);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(vi->dev, xdp_prog, act);
case XDP_DROP:
@@ -876,8 +877,10 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
goto xdp_xmit;
default:
bpf_warn_invalid_xdp_action(act);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(vi->dev, xdp_prog, act);
+ /* fall through */
case XDP_DROP:
if (unlikely(xdp_page != page))
__free_pages(xdp_page, 0);
--
2.7.4
^ permalink raw reply related
* [PATCHv2] netlink: Don't shift on 64 for ngroups
From: Dmitry Safonov @ 2018-08-05 0:35 UTC (permalink / raw)
To: linux-kernel
Cc: Dmitry Safonov, Nathan Chancellor, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, stable
It's legal to have 64 groups for netlink_sock.
As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.
The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.
Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
v2:
sizeof() is in bytes
net/netlink/af_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7d860a22e5fb..d6ff4d409437 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1011,8 +1011,8 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
if (nlk->ngroups == 0)
groups = 0;
- else
- groups &= (1ULL << nlk->ngroups) - 1;
+ else if (nlk->ngroups < 8*sizeof(groups))
+ groups &= (1UL << nlk->ngroups) - 1;
bound = nlk->bound;
if (bound) {
--
2.13.6
^ permalink raw reply related
* pull-request: bpf 2018-08-05
From: Daniel Borkmann @ 2018-08-05 0:26 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fix bpftool percpu_array dump by using correct roundup to next
multiple of 8 for the value size, from Yonghong.
2) Fix in AF_XDP's __xsk_rcv_zc() to not returning frames back to
allocator since driver will recycle frame anyway in case of an
error, from Jakub.
3) Fix up BPF test_lwt_seg6local test cases to final iproute2
syntax, from Mathieu.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 61f4b23769f0cc72ae62c9a81cf08f0397d40da8:
netlink: Don't shift with UB on nlk->ngroups (2018-07-30 12:42:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 8c85cbdf371f9ddf256ecc5d9548b26ee8fcfe2f:
selftests/bpf: update test_lwt_seg6local.sh according to iproute2 (2018-08-03 10:19:33 +0200)
----------------------------------------------------------------
Jakub Kicinski (1):
net: xsk: don't return frames via the allocator on error
Mathieu Xhonneux (1):
selftests/bpf: update test_lwt_seg6local.sh according to iproute2
Yonghong Song (1):
tools/bpftool: fix a percpu_array map dump problem
net/xdp/xsk.c | 4 +---
tools/bpf/bpftool/map.c | 14 +++++++++-----
tools/testing/selftests/bpf/test_lwt_seg6local.sh | 6 +++---
3 files changed, 13 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] netlink: Don't shift on 64 for ngroups
From: Dmitry Safonov @ 2018-08-04 23:55 UTC (permalink / raw)
To: linux-kernel
Cc: Dmitry Safonov, Nathan Chancellor, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, stable
It's legal to have 64 groups for netlink_sock.
As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.
The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.
Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Dmitry Safonov <dima@arista.com>
---
net/netlink/af_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 7d860a22e5fb..e44edadfad20 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1011,8 +1011,8 @@ static int netlink_bind(struct socket *sock, struct sockaddr *addr,
if (nlk->ngroups == 0)
groups = 0;
- else
- groups &= (1ULL << nlk->ngroups) - 1;
+ else if (nlk->ngroups < sizeof(long unsigned int))
+ groups &= (1UL << nlk->ngroups) - 1;
bound = nlk->bound;
if (bound) {
--
2.13.6
^ permalink raw reply related
* Re: [PATCHv2] netlink: Don't shift on 64 for ngroups
From: David Miller @ 2018-08-05 0:53 UTC (permalink / raw)
To: dima
Cc: linux-kernel, natechancellor, herbert, steffen.klassert, netdev,
stable
In-Reply-To: <20180805003553.11104-1-dima@arista.com>
From: Dmitry Safonov <dima@arista.com>
Date: Sun, 5 Aug 2018 01:35:53 +0100
> It's legal to have 64 groups for netlink_sock.
>
> As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
> only to first 32 groups.
>
> The check for correctness of .bind() userspace supplied parameter
> is done by applying mask made from ngroups shift. Which broke Android
> as they have 64 groups and the shift for mask resulted in an overflow.
>
> Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups")
> Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Dmitry Safonov <dima@arista.com>
Applied and queued up for -stable.
^ 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