* [PATCH net-next] net/ncsi: support unaligned payload size in NC-SI cmd handler
From: Ben Wei @ 2019-09-02 2:46 UTC (permalink / raw)
To: Ben Wei, David Miller, sam@mendozajonas.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
Cc: Ben Wei
Update NC-SI command handler (both standard and OEM) to take into
account of payload paddings in allocating skb (in case of payload
size is not 32-bit aligned).
The checksum field follows payload field, without taking payload
padding into account can cause checksum being truncated, leading to
dropped packets.
Signed-off-by: Ben Wei <benwei@fb.com>
---
net/ncsi/ncsi-cmd.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
index 0187e65176c0..42636ed3cf3a 100644
--- a/net/ncsi/ncsi-cmd.c
+++ b/net/ncsi/ncsi-cmd.c
@@ -213,17 +213,22 @@ static int ncsi_cmd_handler_oem(struct sk_buff *skb,
{
struct ncsi_cmd_oem_pkt *cmd;
unsigned int len;
+ /* NC-SI spec requires payload to be padded with 0
+ * to 32-bit boundary before the checksum field.
+ * Ensure the padding bytes are accounted for in
+ * skb allocation
+ */
+ unsigned short payload = ALIGN(nca->payload, 4);
len = sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
+ if (payload < 26)
len += 26;
else
- len += nca->payload;
+ len += payload;
cmd = skb_put_zero(skb, len);
memcpy(&cmd->mfr_id, nca->data, nca->payload);
ncsi_cmd_build_header(&cmd->cmd.common, nca);
-
return 0;
}
@@ -272,6 +277,7 @@ static struct ncsi_request *ncsi_alloc_command(struct ncsi_cmd_arg *nca)
struct net_device *dev = nd->dev;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+ int payload;
int len = hlen + tlen;
struct sk_buff *skb;
struct ncsi_request *nr;
@@ -281,14 +287,17 @@ static struct ncsi_request *ncsi_alloc_command(struct ncsi_cmd_arg *nca)
return NULL;
/* NCSI command packet has 16-bytes header, payload, 4 bytes checksum.
+ * Payload needs padding so that the checksum field follwoing payload is
+ * aligned to 32bit boundary.
* The packet needs padding if its payload is less than 26 bytes to
* meet 64 bytes minimal ethernet frame length.
*/
len += sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
+ payload = ALIGN(nca->payload, 4);
+ if (payload < 26)
len += 26;
else
- len += nca->payload;
+ len += payload;
/* Allocate skb */
skb = alloc_skb(len, GFP_ATOMIC);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)
From: Lorenzo Colitti @ 2019-09-02 2:12 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: Maciej Żenczykowski, David S . Miller, Linux NetDev,
David Ahern
In-Reply-To: <CAHo-Ooy_g-7eZvBSbKR2eaQW3_Bk+fik5YaYAgN60GjmAU=ADA@mail.gmail.com>
On Mon, Sep 2, 2019 at 2:55 AM Maciej Żenczykowski
<zenczykowski@gmail.com> wrote:
> It's not immediately clear to me what is the better approach as I'm
> not immediately certain what RTF_ADDRCONF truly means.
> However the in kernel header file comment does explicitly mention this
> being used to flag routes derived from RA's, and very clearly ::1/128
> is not RA generated, so I *think* the correct fix is to return to the
> old way the kernel used to do things and not flag with ADDRCONF...
AIUI, "addrconf" has always meant stateless address autoconfiguration
as per RFC 4862, i.e., addresses autoconfigured when getting an RA, or
autoconfigured based on adding the link-local prefix. Looking at 5.1
(the most recent release before c7a1ce397ada which you're fixing here)
confirms this interpretation, because RTF_ADDRCONF is only used by:
- addrconf_prefix_rcv: receiving a PIO from an RA
- rt6_add_route_info: receiving an RIO from an RA
- rt6_add_dflt_router, rt6_get_dflt_router: receiving the default
router from an RA
- __rt6_purge_dflt_routers: removing all routes received from RAs,
when enabling forwarding (i.e., switching from being a host to being a
router)
So, if I'm reading c7a1ce397ada right, I would say it's incorrect.
That patch changes things so that RTF_ADDRCONF is set for pretty much
all routes created by adding IPv6 addresses. That includes not only
IPv6 addresses created by RAs, which has always been the case, but
also IPv6 addresses created manually from userspace, or the loopback
address, and even multicast and anycast addresses created by
IPV6_JOIN_GROUP and IPV6_JOIN_ANYCAST. That's userspace-visible
breakage and should be reverted.
Not sure if this patch is the right fix, though, because it breaks
things in the opposite direction: even routes created by an IPv6
address added by receiving an RA will no longer have RTF_ADDRCONF.
Perhaps add something like this as well?
struct fib6_info *addrconf_f6i_alloc(struct net *net, struct inet6_dev *idev,
- const struct in6_addr *addr, bool anycast,
- const struct in6_addr *addr, u8 flags,
gfp_t gfp_flags);
flags would be RTF_ANYCAST iff the code previously called with true,
and RTF_ADDRCONF if called by a function that is adding an IPv6
address coming from an RA.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: phy: realtek: add support for the 2.5Gbps PHY in RTL8125
From: Florian Fainelli @ 2019-09-02 2:07 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <94cc3fe3-98ed-d8d2-2444-84bf3eae0c5e@gmail.com>
On 8/8/2019 1:24 PM, Heiner Kallweit wrote:
> On 08.08.2019 22:20, Andrew Lunn wrote:
>>> I have a contact in Realtek who provided the information about
>>> the vendor-specific registers used in the patch. I also asked for
>>> a method to auto-detect 2.5Gbps support but have no feedback so far.
>>> What may contribute to the problem is that also the integrated 1Gbps
>>> PHY's (all with the same PHY ID) differ significantly from each other,
>>> depending on the network chip version.
>>
>> Hi Heiner
>>
>> Some of the PHYs embedded in Marvell switches have an OUI, but no
>> product ID. We work around this brokenness by trapping the reads to
>> the ID registers in the MDIO bus controller driver and inserting the
>> switch product ID. The Marvell PHY driver then recognises these IDs
>> and does the right thing.
>>
>> Maybe you can do something similar here?
>>
> Yes, this would be an idea. Let me check.
Since this is an integrated PHY you could have the MAC driver pass a
specific phydev->dev_flag bit that indicates that this is RTL8215, since
I am assuming that PCI IDs for those different chipsets do have to be
allocated, right?
--
Florian
^ permalink raw reply
* linux-next: manual merge of the afs tree with the net tree
From: Stephen Rothwell @ 2019-09-02 0:31 UTC (permalink / raw)
To: David Howells, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
Hi all,
Today's linux-next merge of the afs tree got conflicts in:
include/trace/events/rxrpc.h
net/rxrpc/ar-internal.h
net/rxrpc/call_object.c
net/rxrpc/conn_client.c
net/rxrpc/input.c
net/rxrpc/recvmsg.c
net/rxrpc/skbuff.c
between various commits from the net tree and similar commits from the
afs tree.
I fixed it up (I just dropped the afs tree for today) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
It looks like the afs tree has older versions fo some commits in the
net tree ... plus some more.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* kernel panic: stack is corrupted in lock_release (2)
From: syzbot @ 2019-09-01 23:27 UTC (permalink / raw)
To: linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: dd7078f0 enetc: Add missing call to 'pci_free_irq_vectors(..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=115fe0fa600000
kernel config: https://syzkaller.appspot.com/x/.config?x=2a6a2b9826fdadf9
dashboard link: https://syzkaller.appspot.com/bug?extid=97deee97cf14574b96d0
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f7c2fe600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+97deee97cf14574b96d0@syzkaller.appspotmail.com
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
lock_release+0x866/0x960 kernel/locking/lockdep.c:4435
CPU: 0 PID: 9965 Comm: syz-executor.0 Not tainted 5.3.0-rc6+ #182
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: kernel panic: stack is corrupted in __lock_acquire (4)
From: syzbot @ 2019-09-01 22:48 UTC (permalink / raw)
To: linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <0000000000009b3b80058af452ae@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 38320f69 Merge branch 'Minor-cleanup-in-devlink'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13d74356600000
kernel config: https://syzkaller.appspot.com/x/.config?x=1bbf70b6300045af
dashboard link: https://syzkaller.appspot.com/bug?extid=83979935eb6304f8cd46
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1008b232600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+83979935eb6304f8cd46@syzkaller.appspotmail.com
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
__lock_acquire+0x36fa/0x4c30 kernel/locking/lockdep.c:3907
CPU: 0 PID: 8662 Comm: syz-executor.4 Not tainted 5.3.0-rc6+ #153
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
Kernel Offset: disabled
Rebooting in 86400 seconds..
^ permalink raw reply
* Re: [PATCH 0/4 net-next] flow_offload: update mangle action representation
From: Jakub Kicinski @ 2019-09-01 20:47 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, netdev, vishal, saeedm, jiri
In-Reply-To: <20190831142217.bvxx3vc6wpsmnxpe@salvia>
On Sat, 31 Aug 2019 16:22:17 +0200, Pablo Neira Ayuso wrote:
> On Fri, Aug 30, 2019 at 03:33:51PM -0700, Jakub Kicinski wrote:
> > On Fri, 30 Aug 2019 11:07:10 +0200, Pablo Neira Ayuso wrote:
> > > > > * The front-end coalesces consecutive pedit actions into one single
> > > > > word, so drivers can mangle IPv6 and ethernet address fields in one
> > > > > single go.
> > > >
> > > > You still only coalesce up to 16 bytes, no?
> > >
> > > You only have to rise FLOW_ACTION_MANGLE_MAXLEN coming in this patch
> > > if you need more. I don't know of any packet field larger than 16
> > > bytes. If there is a use-case for this, it should be easy to rise that
> > > definition.
> >
> > Please see the definitions of:
> >
> > struct nfp_fl_set_eth
> > struct nfp_fl_set_ip4_addrs
> > struct nfp_fl_set_ip4_ttl_tos
> > struct nfp_fl_set_ipv6_tc_hl_fl
> > struct nfp_fl_set_ipv6_addr
> > struct nfp_fl_set_tport
> >
> > These are the programming primitives for header rewrites in the NFP.
> > Since each of those contains more than just one field, we'll have to
> > keep all the field coalescing logic in the driver, even if you coalesce
> > while fields (i.e. IPv6 addresses).
>
> nfp has been updated in this patch series to deal with the new mangle
> representation.
It has been updated to handle the trivial coalescing.
> > Perhaps it's not a serious blocker for the series, but it'd be nice if
> > rewrite action grouping was handled in the core. Since you're already
> > poking at that code..
>
> Rewrite action grouping is already handled from the core front-end in
> this patch series.
If you did what I'm asking the functions nfp_fl_check_mangle_start()
and nfp_fl_check_mangle_end() would no longer exist. They were not
really needed before you "common flow API" changes.
Your reply makes limited amount of sense to me. Pleas read the code and
what I wrote, if you think I'm asking for too much just say that, I'd
accept that.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2019-09-01 20:45 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix some length checks during OGM processing in batman-adv, from
Sven Eckelmann.
2) Fix regression that caused netfilter conntrack sysctls to not be per-netns
any more. From Florian Westphal.
3) Use after free in netpoll, from Feng Sun.
4) Guard destruction of pfifo_fast per-cpu qdisc stats with
qdisc_is_percpu_stats(), from Davide Caratti. Similar bug
is fixed in pfifo_fast_enqueue().
5) Fix memory leak in mld_del_delrec(), from Eric Dumazet.
6) Handle neigh events on internal ports correctly in nfp, from John
Hurley.
7) Clear SKB timestamp in NF flow table code so that it does not
confuse fq scheduler. From Florian Westphal.
8) taprio destroy can crash if it is invoked in a failure path of
taprio_init(), because the list head isn't setup properly yet
and the list del is unconditional. Perform the list add earlier
to address this. From Vladimir Oltean.
9) Make sure to reapply vlan filters on device up, in aquantia driver.
From Dmitry Bogdanov.
10) sgiseeq driver releases DMA memory using free_page() instead of
dma_free_attrs(). From Christophe JAILLET.
Please pull, thanks a lot!
The following changes since commit 9e8312f5e160ade069e131d54ab8652cf0e86e1a:
Merge tag 'nfs-for-5.3-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2019-08-27 13:22:57 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
for you to fetch changes up to e1e54ec7fb55501c33b117c111cb0a045b8eded2:
net: seeq: Fix the function used to release some memory in an error handling path (2019-09-01 12:10:11 -0700)
----------------------------------------------------------------
Chen-Yu Tsai (1):
net: stmmac: dwmac-rk: Don't fail if phy regulator is absent
Christophe JAILLET (2):
enetc: Add missing call to 'pci_free_irq_vectors()' in probe and remove functions
net: seeq: Fix the function used to release some memory in an error handling path
Cong Wang (1):
net_sched: fix a NULL pointer deref in ipt action
David Howells (8):
rxrpc: Improve jumbo packet counting
rxrpc: Use info in skbuff instead of reparsing a jumbo packet
rxrpc: Pass the input handler's data skb reference to the Rx ring
rxrpc: Abstract out rxtx ring cleanup
rxrpc: Add a private skb flag to indicate transmission-phase skbs
rxrpc: Use the tx-phase skb flag to simplify tracing
rxrpc: Use skb_unshare() rather than skb_cow_data()
rxrpc: Fix lack of conn cleanup when local endpoint is cleaned up [ver #2]
David S. Miller (11):
Merge branch 'macb-Update-ethernet-compatible-string-for-SiFive-FU540'
Merge branch 'r8152-fix-side-effect'
Merge branch 'nfp-flower-fix-bugs-in-merge-tunnel-encap-code'
Merge tag 'mac80211-for-davem-2019-08-29' of git://git.kernel.org/.../jberg/mac80211
Merge tag 'rxrpc-fixes-20190827' of git://git.kernel.org/.../dhowells/linux-fs
Merge git://git.kernel.org/.../bpf/bpf
Merge git://git.kernel.org/.../pablo/nf
Merge tag 'batadv-net-for-davem-20190830' of git://git.open-mesh.org/linux-merge
Merge branch 'Fix-issues-in-tc-taprio-and-tc-cbs'
Merge branch 'net-aquantia-fixes-on-vlan-filters-and-other-conditions'
Merge branch 'net-dsa-microchip-add-KSZ8563-support'
Davide Caratti (3):
net/sched: pfifo_fast: fix wrong dereference when qdisc is reset
net/sched: pfifo_fast: fix wrong dereference in pfifo_fast_enqueue
tc-testing: don't hardcode 'ip' in nsPlugin.py
Denis Kenzior (2):
mac80211: Don't memset RXCB prior to PAE intercept
mac80211: Correctly set noencrypt for PAE frames
Dmitry Bogdanov (4):
net: aquantia: fix removal of vlan 0
net: aquantia: fix limit of vlan filters
net: aquantia: reapply vlan filters on up
net: aquantia: fix out of memory condition on rx side
Eric Dumazet (2):
tcp: remove empty skb from write queue in error cases
mld: fix memory leak in mld_del_delrec()
Feng Sun (1):
net: fix skb use after free in netpoll
Florian Westphal (2):
netfilter: conntrack: make sysctls per-namespace again
netfilter: nf_flow_table: clear skb tstamp before xmit
George McCollister (1):
net: dsa: microchip: fill regmap_config name
Greg Rose (1):
openvswitch: Properly set L4 keys on "later" IP fragments
Hayes Wang (2):
Revert "r8152: napi hangup fix after disconnect"
r8152: remove calling netif_napi_del
Igor Russkikh (1):
net: aquantia: linkstate irq should be oneshot
Jiong Wang (1):
nfp: bpf: fix latency bug when updating stack index register
John Hurley (2):
nfp: flower: prevent ingress block binds on internal ports
nfp: flower: handle neighbour events on internal ports
Justin Pettit (1):
openvswitch: Clear the L4 portion of the key for "later" fragments.
Ka-Cheong Poon (1):
net/rds: Fix info leak in rds6_inc_info_copy()
Luca Coelho (1):
iwlwifi: pcie: handle switching killer Qu B0 NICs to C0
Marco Hartmann (1):
Add genphy_c45_config_aneg() function to phy-c45.c
Naveen N. Rao (1):
bpf: handle 32-bit zext during constant blinding
Razvan Stefanescu (2):
dt-bindings: net: dsa: document additional Microchip KSZ8563 switch
net: dsa: microchip: add KSZ8563 compatibility string
Ryan M. Collins (1):
net: bcmgenet: use ethtool_op_get_ts_info()
Sven Eckelmann (2):
batman-adv: Only read OGM tvlv_len after buffer len check
batman-adv: Only read OGM2 tvlv_len after buffer len check
Takashi Iwai (1):
sky2: Disable MSI on yet another ASUS boards (P6Xxxx)
Thomas Falcon (1):
ibmvnic: Do not process reset during or after device removal
Thomas Jarosch (1):
netfilter: nf_conntrack_ftp: Fix debug output
Todd Seidelmann (1):
netfilter: xt_physdev: Fix spurious error message in physdev_mt_check
Vlad Buslov (1):
net: sched: act_sample: fix psample group handling on overwrite
Vladimir Oltean (4):
net: dsa: tag_8021q: Future-proof the reserved fields in the custom VID
taprio: Fix kernel panic in taprio_destroy
taprio: Set default link speed to 10 Mbps in taprio_set_picos_per_byte
net/sched: cbs: Set default link speed to 10 Mbps in cbs_set_port_rate
Willem de Bruijn (1):
tcp: inherit timestamp on mtu probe
Yash Shah (2):
macb: bindings doc: update sifive fu540-c000 binding
macb: Update compatibility string for SiFive FU540-C000
YueHaibing (1):
amd-xgbe: Fix error path in xgbe_mod_init()
wenxu (1):
netfilter: nft_meta_bridge: Fix get NFT_META_BRI_IIFVPROTO in network byteorder
Documentation/devicetree/bindings/net/dsa/ksz.txt | 1 +
Documentation/devicetree/bindings/net/macb.txt | 4 +-
drivers/net/dsa/microchip/ksz9477_spi.c | 1 +
drivers/net/dsa/microchip/ksz_common.h | 1 +
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 10 ++-
drivers/net/ethernet/aquantia/atlantic/aq_filters.c | 5 +-
drivers/net/ethernet/aquantia/atlantic/aq_main.c | 4 ++
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 2 +-
drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 3 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 1 +
drivers/net/ethernet/cadence/macb_main.c | 2 +-
drivers/net/ethernet/freescale/enetc/enetc_ptp.c | 5 +-
drivers/net/ethernet/ibm/ibmvnic.c | 6 +-
drivers/net/ethernet/marvell/sky2.c | 7 +++
drivers/net/ethernet/netronome/nfp/bpf/jit.c | 17 +++--
drivers/net/ethernet/netronome/nfp/flower/offload.c | 7 ++-
drivers/net/ethernet/netronome/nfp/flower/tunnel_conf.c | 8 +--
drivers/net/ethernet/seeq/sgiseeq.c | 7 ++-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-
drivers/net/phy/phy-c45.c | 26 ++++++++
drivers/net/phy/phy.c | 2 +-
drivers/net/usb/r8152.c | 5 +-
drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 24 ++++++++
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 2 +
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 4 ++
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 7 +--
include/linux/phy.h | 1 +
include/net/act_api.h | 4 +-
include/net/psample.h | 1 +
include/trace/events/rxrpc.h | 59 +++++++++---------
kernel/bpf/core.c | 8 ++-
net/batman-adv/bat_iv_ogm.c | 20 +++---
net/batman-adv/bat_v_ogm.c | 18 ++++--
net/bridge/netfilter/nft_meta_bridge.c | 2 +-
net/core/netpoll.c | 6 +-
net/dsa/tag_8021q.c | 2 +
net/ipv4/tcp.c | 30 ++++++---
net/ipv4/tcp_output.c | 3 +-
net/ipv6/mcast.c | 5 +-
net/mac80211/rx.c | 6 +-
net/netfilter/nf_conntrack_ftp.c | 2 +-
net/netfilter/nf_conntrack_standalone.c | 5 ++
net/netfilter/nf_flow_table_ip.c | 3 +-
net/netfilter/xt_physdev.c | 6 +-
net/openvswitch/conntrack.c | 5 ++
net/openvswitch/flow.c | 160 +++++++++++++++++++++++++++--------------------
net/openvswitch/flow.h | 1 +
net/psample/psample.c | 2 +-
net/rds/recv.c | 5 +-
net/rxrpc/af_rxrpc.c | 3 -
net/rxrpc/ar-internal.h | 17 +++--
net/rxrpc/call_event.c | 8 +--
net/rxrpc/call_object.c | 33 +++++-----
net/rxrpc/conn_client.c | 44 +++++++++++++
net/rxrpc/conn_event.c | 6 +-
net/rxrpc/conn_object.c | 2 +-
net/rxrpc/input.c | 304 +++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------
net/rxrpc/local_event.c | 4 +-
net/rxrpc/local_object.c | 5 +-
net/rxrpc/output.c | 6 +-
net/rxrpc/peer_event.c | 10 +--
net/rxrpc/protocol.h | 9 +++
net/rxrpc/recvmsg.c | 47 ++++++++------
net/rxrpc/rxkad.c | 32 +++-------
net/rxrpc/sendmsg.c | 13 ++--
net/rxrpc/skbuff.c | 40 ++++++++----
net/sched/act_bpf.c | 2 +-
net/sched/act_connmark.c | 2 +-
net/sched/act_csum.c | 2 +-
net/sched/act_ct.c | 2 +-
net/sched/act_ctinfo.c | 2 +-
net/sched/act_gact.c | 2 +-
net/sched/act_ife.c | 2 +-
net/sched/act_ipt.c | 11 ++--
net/sched/act_mirred.c | 2 +-
net/sched/act_mpls.c | 2 +-
net/sched/act_nat.c | 2 +-
net/sched/act_pedit.c | 2 +-
net/sched/act_police.c | 2 +-
net/sched/act_sample.c | 8 ++-
net/sched/act_simple.c | 2 +-
net/sched/act_skbedit.c | 2 +-
net/sched/act_skbmod.c | 2 +-
net/sched/act_tunnel_key.c | 2 +-
net/sched/act_vlan.c | 2 +-
net/sched/sch_cbs.c | 19 +++---
net/sched/sch_generic.c | 19 ++++--
net/sched/sch_taprio.c | 31 +++++-----
tools/testing/selftests/tc-testing/plugin-lib/nsPlugin.py | 22 +++----
89 files changed, 761 insertions(+), 487 deletions(-)
^ permalink raw reply
* Re: BUG_ON in skb_segment, after bpf_skb_change_proto was applied
From: Willem de Bruijn @ 2019-09-01 20:05 UTC (permalink / raw)
To: Shmulik Ladkani
Cc: Daniel Borkmann, Eric Dumazet, netdev, Alexander Duyck,
Alexei Starovoitov, Yonghong Song, Steffen Klassert,
Shmulik Ladkani, eyal
In-Reply-To: <20190829152241.73734206@pixies>
On Thu, Aug 29, 2019 at 8:22 AM Shmulik Ladkani
<shmulik.ladkani@gmail.com> wrote:
>
> On Tue, 27 Aug 2019 14:10:35 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> > Given first point above wrt hitting rarely, it would be good to first get a
> > better understanding for writing a reproducer. Back then Yonghong added one
> > to the BPF kernel test suite [0], so it would be desirable to extend it for
> > the case you're hitting. Given NAT64 use-case is needed and used by multiple
> > parties, we should try to (fully) fix it generically.
> >
>
> Thanks Daniel.
>
> Managed to write a reproducer which mimics the skb we see on prodction,
> that hits the exact same BUG_ON.
>
> Submitted as a separate RFC PATCH to bpf-next.
Thanks for the reproducer.
One quick fix is to disable sg and thus revert to copying in this
case. Not ideal, but better than a kernel splat:
@@ -3714,6 +3714,9 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
sg = !!(features & NETIF_F_SG);
csum = !!can_checksum_protocol(features, proto);
+ if (list_skb && skb_headlen(list_skb) && !list_skb->head_frag)
+ sg = false;
+
It could perhaps be refined to avoid in the special case where
skb_headlen(list_skb) == len and nskb aligned to start of list_skb.
And needs looking into effect on GSO_BY_FRAGS.
I also looked into trying to convert a kmalloc'ed skb->head into a
headfrag. But even if possible, that conversion is non-trivial and
easy to have bugs of its own.
@@ -3849,8 +3885,8 @@ struct sk_buff *skb_segment(struct sk_buff *head_skb,
if (!skb_headlen(list_skb)) {
BUG_ON(!nfrags);
} else {
- BUG_ON(!list_skb->head_frag);
-
+ BUG_ON(!list_skb->head_frag &&
+
!skb_to_headfrag(list_skb, GFP_ATOMIC));
^ permalink raw reply
* Re: [PATCH v6 net-next 14/19] ionic: Add initial ethtool support
From: Andrew Lunn @ 2019-09-01 19:52 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Shannon Nelson, netdev, davem
In-Reply-To: <20190830151641.0aec4a3e@cakuba.netronome.com>
On Fri, Aug 30, 2019 at 03:16:41PM -0700, Jakub Kicinski wrote:
> On Fri, 30 Aug 2019 14:25:12 -0700, Shannon Nelson wrote:
> > On 8/29/19 4:10 PM, Jakub Kicinski wrote:
> > > On Thu, 29 Aug 2019 11:27:15 -0700, Shannon Nelson wrote:
> > >> +static int ionic_get_module_eeprom(struct net_device *netdev,
> > >> + struct ethtool_eeprom *ee,
> > >> + u8 *data)
> > >> +{
> > >> + struct ionic_lif *lif = netdev_priv(netdev);
> > >> + struct ionic_dev *idev = &lif->ionic->idev;
> > >> + struct ionic_xcvr_status *xcvr;
> > >> + char tbuf[sizeof(xcvr->sprom)];
> > >> + int count = 10;
> > >> + u32 len;
> > >> +
> > >> + /* The NIC keeps the module prom up-to-date in the DMA space
> > >> + * so we can simply copy the module bytes into the data buffer.
> > >> + */
> > >> + xcvr = &idev->port_info->status.xcvr;
> > >> + len = min_t(u32, sizeof(xcvr->sprom), ee->len);
> > >> +
> > >> + do {
> > >> + memcpy(data, xcvr->sprom, len);
> > >> + memcpy(tbuf, xcvr->sprom, len);
> > >> +
> > >> + /* Let's make sure we got a consistent copy */
> > >> + if (!memcmp(data, tbuf, len))
> > >> + break;
> > >> +
> > >> + } while (--count);
> > > Should this return an error if the image was never consistent?
> >
> > Sure, how about -EBUSY?
>
> Or EAGAIN ? Not sure
ETIMEOUT?
EAGAIN would suggest it is a temporary problem. But if this fails
after 10 attempts, i would guess it is not a temporary problem, the
firmware is in deep trouble, or the SFP is loose in its cage, about to
fall out.
Andrew
^ permalink raw reply
* Re: [PATCH 2/2] Fix a NULL-ptr-deref bug in ath10k_usb_alloc_urb_from_pipe
From: Hui Peng @ 2019-09-01 19:45 UTC (permalink / raw)
To: Guenter Roeck
Cc: kvalo, davem, Mathias Payer, ath10k, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20190831213139.GA32507@roeck-us.net>
On 8/31/19 5:31 PM, Guenter Roeck wrote:
> Hi,
>
> On Sat, Aug 03, 2019 at 08:31:01PM -0400, Hui Peng wrote:
>> The `ar_usb` field of `ath10k_usb_pipe_usb_pipe` objects
>> are initialized to point to the containing `ath10k_usb` object
>> according to endpoint descriptors read from the device side, as shown
>> below in `ath10k_usb_setup_pipe_resources`:
>>
>> for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
>> endpoint = &iface_desc->endpoint[i].desc;
>>
>> // get the address from endpoint descriptor
>> pipe_num = ath10k_usb_get_logical_pipe_num(ar_usb,
>> endpoint->bEndpointAddress,
>> &urbcount);
>> ......
>> // select the pipe object
>> pipe = &ar_usb->pipes[pipe_num];
>>
>> // initialize the ar_usb field
>> pipe->ar_usb = ar_usb;
>> }
>>
>> The driver assumes that the addresses reported in endpoint
>> descriptors from device side to be complete. If a device is
>> malicious and does not report complete addresses, it may trigger
>> NULL-ptr-deref `ath10k_usb_alloc_urb_from_pipe` and
>> `ath10k_usb_free_urb_to_pipe`.
>>
>> This patch fixes the bug by preventing potential NULL-ptr-deref.
>>
>> Signed-off-by: Hui Peng <benquike@gmail.com>
>> Reported-by: Hui Peng <benquike@gmail.com>
>> Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
> This patch fixes CVE-2019-15099, which has CVSS scores of 7.5 (CVSS 3.0)
> and 7.8 (CVSS 2.0). Yet, I don't find it in the upstream kernel or in Linux
> next.
>
> Is the patch going to be applied to the upstream kernel anytime soon ? If
> not, is there reason to believe that its severity may not be as high as the
> CVSS score indicates ?
The score was assigned by MITRE.
Same as previous ones, it is under review, once passed, it will be applied.
> Thanks,
> Guenter
>
>> ---
>> drivers/net/wireless/ath/ath10k/usb.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/usb.c b/drivers/net/wireless/ath/ath10k/usb.c
>> index e1420f67f776..14d86627b47f 100644
>> --- a/drivers/net/wireless/ath/ath10k/usb.c
>> +++ b/drivers/net/wireless/ath/ath10k/usb.c
>> @@ -38,6 +38,10 @@ ath10k_usb_alloc_urb_from_pipe(struct ath10k_usb_pipe *pipe)
>> struct ath10k_urb_context *urb_context = NULL;
>> unsigned long flags;
>>
>> + /* bail if this pipe is not initialized */
>> + if (!pipe->ar_usb)
>> + return NULL;
>> +
>> spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
>> if (!list_empty(&pipe->urb_list_head)) {
>> urb_context = list_first_entry(&pipe->urb_list_head,
>> @@ -55,6 +59,10 @@ static void ath10k_usb_free_urb_to_pipe(struct ath10k_usb_pipe *pipe,
>> {
>> unsigned long flags;
>>
>> + /* bail if this pipe is not initialized */
>> + if (!pipe->ar_usb)
>> + return NULL;
>> +
>> spin_lock_irqsave(&pipe->ar_usb->cs_lock, flags);
>>
>> pipe->urb_cnt++;
>> --
>> 2.22.0
>>
^ permalink raw reply
* Re: [PATCH net-next 00/10] net: dsa: mv88e6xxx: centralize SERDES IRQ handling
From: David Miller @ 2019-09-01 19:25 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, marek.behun, f.fainelli, andrew
In-Reply-To: <20190831201836.19957-1-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Sat, 31 Aug 2019 16:18:26 -0400
> Following Marek's work on the abstraction of the SERDES lanes mapping, this
> series trades the .serdes_irq_setup and .serdes_irq_free callbacks for new
> .serdes_irq_mapping, .serdes_irq_enable and .serdes_irq_status operations.
>
> This has the benefit to limit the various SERDES implementations to simple
> register accesses only; centralize the IRQ handling and mutex locking logic;
> as well as reducing boilerplate in the driver.
Looks good, series applied.
^ permalink raw reply
* Re: [PATCH net-next] net: hns3: remove set but not used variable 'qos'
From: David Miller @ 2019-09-01 19:13 UTC (permalink / raw)
To: yuehaibing
Cc: yisen.zhuang, salil.mehta, linyunsheng, liuzhongzhu,
huangguangbin2, lipeng321, tanhuazhong, shenjian15, netdev,
kernel-janitors, hulkci
In-Reply-To: <20190831122911.181336-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 31 Aug 2019 12:29:11 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c: In function 'hclge_restore_vlan_table':
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c:8016:18: warning:
> variable 'qos' set but not used [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: 70a214903da9 ("net: hns3: reduce the parameters of some functions")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH][next] net: hns3: remove redundant assignment to pointer reg_info
From: David Miller @ 2019-09-01 19:12 UTC (permalink / raw)
To: colin.king
Cc: yisen.zhuang, salil.mehta, tanhuazhong, liuzhongzhu, netdev,
kernel-janitors, linux-kernel
In-Reply-To: <20190831072949.7505-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 31 Aug 2019 08:29:49 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer reg_info is being initialized with a value that is never read and
> is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: seeq: Fix the function used to release some memory in an error handling path
From: David Miller @ 2019-09-01 19:11 UTC (permalink / raw)
To: christophe.jaillet
Cc: yuehaibing, tglx, gregkh, tbogendoerfer, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <20190831071751.1479-1-christophe.jaillet@wanadoo.fr>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat, 31 Aug 2019 09:17:51 +0200
> In commit 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv"),
> a call to 'get_zeroed_page()' has been turned into a call to
> 'dma_alloc_coherent()'. Only the remove function has been updated to turn
> the corresponding 'free_page()' into 'dma_free_attrs()'.
> The error hndling path of the probe function has not been updated.
>
> Fix it now.
>
> Rename the corresponding label to something more in line.
>
> Fixes: 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Applied.
> If 'dma_alloc_coherent()' fails, maybe the message in printk could be
> improved. The comment above may also not be relevant.
Memory allocation failures already give a stack backtrack down deep in the
memory allocators, therefore printing messages at allocation call sites
are veboten.
^ permalink raw reply
* RT and PTP system timestamping
From: Vladimir Oltean @ 2019-09-01 19:02 UTC (permalink / raw)
To: netdev, linux-rt-users, linux-spi
Cc: Richard Cochran, Miroslav Lichvar, Hubert Feurstein
Hello people of netdev, linux-rt-users and linux-spi,
Apologies in advance for asking a question about something I know nothing about.
I am playing with a device driver of a SPI-controlled PTP timer. For
my particular application it is important that the value of the PTP
timer can be retrieved with an accuracy bound of less than +/- 400 ns.
Currently that job has been served by the PTP_SYS_OFFSET_EXTENDED [1]
ioctl (which allows for the timer's and the system's time to be
correlated) plus some hacks in the SPI core and drivers which were
submitted for review [2].
In the future I would like to evaluate RT on the device I am playing
with. There are a few dependency patches in flight and I'm not
actually clear what my current evaluation options as of now are, so I
think I'll just have to wait until 5.4-rt.
But at least I need to consider the RT friendliness of the solution I
am proposing. The gist of it (in the current version) is: put the
controller in poll mode, disable local IRQs and preemption on the
local CPU (via a spin_lock_irqsave), then surround the transfer of the
SPI byte I'm interested in with (basically) calls to
ktime_get_real_ts64.
Of course, this approach is completely incompatible with RT:
- In RT, spin_lock_irqsave does not disable IRQs and preemption. But
without those disabled, the PTP system timestamps are basically
throw-away - they should capture the most precise "before" and "after"
time of when the SPI slave device has received byte N of the transfer
(that is when it's snapshotting its timer internally). It's true that
the PTP_SYS_OFFSET_EXTENDED ioctl has a n_samples argument which can
be used in a sort of "pick shortest readout time" fashion, but there
is no guarantee that there will always be even 1 out of X readouts
that complete atomically with no preemption.
- Forcing the disabling of interrupts and preemption creates the
opportunity for unbounded latency for the other threads in the system.
- Disabling interrupts to record the before-and-after time for a TX
event would also be a contradiction in terms for SPI controllers that
don't do polling, i.e. DMA-based.
- In RT, there is no hardirq context at all given to a SPI controller driver.
The above constraints mean that the problem of timestamping byte N of
a SPI transfer is intractable from within the SPI controller driver
itself, at least with RT, as far as I can tell.
Ensuring the atomicness of one system clock readout with the SPI
transfer is hard enough I think, doing it for both the "pre" and the
"post" times is even more so. There have been discussions about only
taking one of the 2 timestamps, and deducing the other as being a
constant offset far. That is something I may be open to experiment
with, as long as there's least one place which can be timestamped,
that has a known offset relative to the hardware event (e.g. the
hardirq context - then the "pre" time can be backtraced).
I noticed the record_irq_time() function call in kernel/irq/handle.c
[3] and I do wonder whether it can be used for driver consumption?
I don't love the idea of moving the driver back to interrupt mode
though, but it's the only way I see currently. The other reason why I
put it in poll mode is that 50% of the time spent for a transfer is
simply wasted doing other stuff (an IRQ gets raised after each
transferred byte). This is secondary however.
I am looking forward to comments that will hopefully put me on the right path.
Regards,
-Vladimir
[1]: https://www.spinics.net/lists/netdev/msg532765.html
[2]: https://www.spinics.net/lists/netdev/msg593404.html
[3]: https://lwn.net/Articles/691297/
^ permalink raw reply
* Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity.
From: Andrew Lunn @ 2019-09-01 18:48 UTC (permalink / raw)
To: Ido Schimmel
Cc: David Miller, jiri, horatiu.vultur, alexandre.belloni,
UNGLinuxDriver, allan.nielsen, ivecera, f.fainelli, netdev,
linux-kernel
In-Reply-To: <20190831204705.GA28380@splinter>
On Sat, Aug 31, 2019 at 11:47:05PM +0300, Ido Schimmel wrote:
> On Sat, Aug 31, 2019 at 09:35:56PM +0200, Andrew Lunn wrote:
> > > Also, what happens when I'm running these application without putting
> > > the interface in promisc mode? On an offloaded interface I would not be
> > > able to even capture packets addressed to my interface's MAC address.
> >
> > Sorry for rejoining the discussion late. I've been travelling and i'm
> > now 3/4 of the way to Lisbon.
>
> Hi Andrew,
>
> Have fun!
>
> > That statement i don't get.
>
> What about the other statements?
>
> > If the frame has the MAC address of the interface, it has to be
> > delivered to the CPU.
>
> So every packet that needs to be routed should be delivered to the CPU?
> Definitely not.
>
> > And so pcap will see it when running on the interface. I can pretty
> > much guarantee every DSA driver does that.
>
> I assume because you currently only consider L2 forwarding.
Yes, that is what i missed. The vast majority of switches which Linux
supports are L2. All the switches i deal with are L2. So i did not
think about L3. My bad.
> > But to address the bigger picture. My understanding is that we want to
> > model offloading as a mechanism to accelerate what Linux can already
> > do. The user should not have to care about these accelerators. The
> > interface should work like a normal Linux interface. I can put an IP
> > address on it and ping a peer. I can run a dhcp client and get an IP
> > address from a dhcp server. I can add the interface to a bridge, and
> > packets will get bridged. I as a user should not need to care if this
> > is done in software, or accelerated by offloading it. I can add a
> > route, and if the accelerate knows about L3, it can accelerate that as
> > well. If not, the kernel will route it.
>
> Yep, and this is how it's all working today.
So for a L3 switch, frames which match the MAC address, and one of the
many global scope IP addresses on any interface, get delivered to the
CPU, when the accelerator is L3 capable. If the IP address does not
match, it gets routed in hardware, if there is an appropriate router,
otherwise it get passed to the CPU, so the CPU can route it out an
interface which is not part of the switch.
> Look, this again boils down to what promisc mode means with regards to
> hardware offload. You want it to mean punt all traffic to the CPU? Fine.
> Does not seem like anyone will be switching sides anyway, so lets move
> forward. But the current approach is not good. Each driver needs to have
> this special case logic and the semantics of promisc mode change not
> only with regards to the value of the promisc counter, but also with
> regards to the interface's uppers. This is highly fragile and confusing.
Yes, i agree. We want one function, in the core, which handles all the
different uppers. Maybe 2, if we need to consider L2 and L3 switches
differently.
Andrew
^ permalink raw reply
* Re: [PATCH] netlabel: remove redundant assignment to pointer iter
From: David Miller @ 2019-09-01 18:45 UTC (permalink / raw)
To: colin.king
Cc: paul, netdev, linux-security-module, kernel-janitors,
linux-kernel
In-Reply-To: <20190901155205.16877-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sun, 1 Sep 2019 16:52:05 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer iter is being initialized with a value that is never read and
> is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net] isdn/capi: check message length in capi_write()
From: David Miller @ 2019-09-01 18:44 UTC (permalink / raw)
To: ebiggers; +Cc: netdev, isdn, syzkaller-bugs
In-Reply-To: <20190901143239.13828-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@kernel.org>
Date: Sun, 1 Sep 2019 09:32:39 -0500
> From: Eric Biggers <ebiggers@google.com>
>
> syzbot reported:
>
> BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
> CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2
> 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+0x173/0x1d0 lib/dump_stack.c:113
> kmsan_report+0x12e/0x2a0 mm/kmsan/kmsan.c:613
> __msan_warning+0x82/0xf0 mm/kmsan/kmsan_instr.c:313
> capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700
> do_loop_readv_writev fs/read_write.c:703 [inline]
> do_iter_write+0x83e/0xd80 fs/read_write.c:961
> vfs_writev fs/read_write.c:1004 [inline]
> do_writev+0x397/0x840 fs/read_write.c:1039
> __do_sys_writev fs/read_write.c:1112 [inline]
> __se_sys_writev+0x9b/0xb0 fs/read_write.c:1109
> __x64_sys_writev+0x4a/0x70 fs/read_write.c:1109
> do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
> entry_SYSCALL_64_after_hwframe+0x63/0xe7
> [...]
>
> The problem is that capi_write() is reading past the end of the message.
> Fix it by checking the message's length in the needed places.
>
> Reported-and-tested-by: syzbot+0849c524d9c634f5ae66@syzkaller.appspotmail.com
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> drivers/isdn/capi/capi.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/isdn/capi/capi.c b/drivers/isdn/capi/capi.c
> index 3c3ad42f22bf..a016d8c3c410 100644
> --- a/drivers/isdn/capi/capi.c
> +++ b/drivers/isdn/capi/capi.c
> @@ -688,6 +688,9 @@ capi_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos
> if (!cdev->ap.applid)
> return -ENODEV;
>
> + if (count < CAPIMSG_BASELEN)
> + return -EINVAL;
> +
> skb = alloc_skb(count, GFP_USER);
> if (!skb)
> return -ENOMEM;
This is fine.
> @@ -698,7 +701,8 @@ capi_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos
> }
> mlen = CAPIMSG_LEN(skb->data);
> if (CAPIMSG_CMD(skb->data) == CAPI_DATA_B3_REQ) {
> - if ((size_t)(mlen + CAPIMSG_DATALEN(skb->data)) != count) {
> + if (count < 18 ||
...
> + if (count < 12) {
These magic constants, on the other hand, are not.
^ permalink raw reply
* Re: [PATCH net-next] r8169: don't set bit RxVlan on RTL8125
From: David Miller @ 2019-09-01 18:37 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <84b91849-0ea6-5f76-150e-bee20a2a4d5c@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun, 1 Sep 2019 10:42:44 +0200
> RTL8125 uses a different register for VLAN offloading config,
> therefore don't set bit RxVlan.
>
> Fixes: f1bce4ad2f1c ("r8169: add support for RTL8125")
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] netlabel: remove redundant assignment to pointer iter
From: Paul Moore @ 2019-09-01 18:23 UTC (permalink / raw)
To: Colin King
Cc: David S . Miller, netdev, linux-security-module, kernel-janitors,
linux-kernel
In-Reply-To: <20190901155205.16877-1-colin.king@canonical.com>
On Sun, Sep 1, 2019 at 11:52 AM Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer iter is being initialized with a value that is never read and
> is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/netlabel/netlabel_kapi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Paul Moore <paul@paul-moore.com>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 2b0ef55cf89e..409a3ae47ce2 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -607,7 +607,7 @@ static struct netlbl_lsm_catmap *_netlbl_catmap_getnode(
> */
> int netlbl_catmap_walk(struct netlbl_lsm_catmap *catmap, u32 offset)
> {
> - struct netlbl_lsm_catmap *iter = catmap;
> + struct netlbl_lsm_catmap *iter;
> u32 idx;
> u32 bit;
> NETLBL_CATMAP_MAPTYPE bitmap;
> --
> 2.20.1
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH] netlabel: remove redundant assignment to pointer iter
From: Paul Moore @ 2019-09-01 18:22 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Colin King, David S . Miller, netdev, linux-security-module,
kernel-janitors, linux-kernel
In-Reply-To: <de0cd774-8fce-d69a-8ea4-3c7b2ee3a918@wanadoo.fr>
On Sun, Sep 1, 2019 at 1:16 PM Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Le 01/09/2019 à 18:04, Paul Moore a écrit :
>
> On Sun, Sep 1, 2019 at 11:52 AM Colin King <colin.king@canonical.com> wrote:
>
> From: Colin Ian King <colin.king@canonical.com>
>
> Pointer iter is being initialized with a value that is never read and
> is being re-assigned a little later on. The assignment is redundant
> and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> net/netlabel/netlabel_kapi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> This patch doesn't seem correct to me, at least not in current form.
> At the top of _netlbl_catmap_getnode() is a check to see if iter is
> NULL (as well as a few other checks on iter after that); this patch
> would break that code.
>
> Perhaps we can get rid of the iter/catmap assignment when we define
> iter, but I don't think this patch is the right way to do it.
>
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 2b0ef55cf89e..409a3ae47ce2 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -607,7 +607,7 @@ static struct netlbl_lsm_catmap *_netlbl_catmap_getnode(
> */
> int netlbl_catmap_walk(struct netlbl_lsm_catmap *catmap, u32 offset)
> {
> - struct netlbl_lsm_catmap *iter = catmap;
> + struct netlbl_lsm_catmap *iter;
> u32 idx;
> u32 bit;
> NETLBL_CATMAP_MAPTYPE bitmap;
> --
> 2.20.1
>
> 'iter' is reassigned a value between the declaration and the NULL test, so removing the fist initialisation looks good to me.
This is what I get when I try to review patches quickly while doing
other things on the weekend <sigh> ... yes, you are correct, I was
looking at _netlbl_catmap_getnode() and not netlbl_catmap_walk(); my
apologies.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: WARNING in __mark_chain_precision (2)
From: syzbot @ 2019-09-01 18:23 UTC (permalink / raw)
To: allison, arvid.brodin, ast, bpf, clang-built-linux, daniel, davem,
gregkh, hawk, jakub.kicinski, jic23, john.fastabend, kafai,
knaack.h, kstewart, lars, linus.walleij, linux-iio, linux-kernel,
mchehab+samsung, netdev, nicolas.ferre, paulmck, pmeerw, rfontana,
songliubraving, syzkaller-bugs, tglx, torvalds, yhs
In-Reply-To: <000000000000b7a14105913fcca8@google.com>
syzbot has bisected this bug to:
commit e786741ff1b52769b044b7f4407f39cd13ee5d2d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Jul 11 22:36:02 2019 +0000
Merge tag 'staging-5.3-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11958f12600000
start commit: 47ee6e86 selftests/bpf: remove wrong nhoff in flow dissect..
git tree: bpf-next
final crash: https://syzkaller.appspot.com/x/report.txt?x=13958f12600000
console output: https://syzkaller.appspot.com/x/log.txt?x=15958f12600000
kernel config: https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
dashboard link: https://syzkaller.appspot.com/bug?extid=c8d66267fd2b5955287e
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10d26ebc600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=127805ca600000
Reported-by: syzbot+c8d66267fd2b5955287e@syzkaller.appspotmail.com
Fixes: e786741ff1b5 ("Merge tag 'staging-5.3-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH V5 0/9] Fixes for vhost metadata acceleration
From: Michael S. Tsirkin @ 2019-09-01 18:02 UTC (permalink / raw)
To: Jason Wang; +Cc: kvm, virtualization, netdev, linux-kernel, linux-mm, jgg
In-Reply-To: <9325de4b-1d79-eb19-306e-e7a8fa8cc1a5@redhat.com>
On Tue, Aug 20, 2019 at 10:29:32AM +0800, Jason Wang wrote:
>
> On 2019/8/20 上午5:08, Michael S. Tsirkin wrote:
> > On Tue, Aug 13, 2019 at 04:12:49PM +0800, Jason Wang wrote:
> > > On 2019/8/12 下午5:49, Michael S. Tsirkin wrote:
> > > > On Mon, Aug 12, 2019 at 10:44:51AM +0800, Jason Wang wrote:
> > > > > On 2019/8/11 上午1:52, Michael S. Tsirkin wrote:
> > > > > > On Fri, Aug 09, 2019 at 01:48:42AM -0400, Jason Wang wrote:
> > > > > > > Hi all:
> > > > > > >
> > > > > > > This series try to fix several issues introduced by meta data
> > > > > > > accelreation series. Please review.
> > > > > > >
> > > > > > > Changes from V4:
> > > > > > > - switch to use spinlock synchronize MMU notifier with accessors
> > > > > > >
> > > > > > > Changes from V3:
> > > > > > > - remove the unnecessary patch
> > > > > > >
> > > > > > > Changes from V2:
> > > > > > > - use seqlck helper to synchronize MMU notifier with vhost worker
> > > > > > >
> > > > > > > Changes from V1:
> > > > > > > - try not use RCU to syncrhonize MMU notifier with vhost worker
> > > > > > > - set dirty pages after no readers
> > > > > > > - return -EAGAIN only when we find the range is overlapped with
> > > > > > > metadata
> > > > > > >
> > > > > > > Jason Wang (9):
> > > > > > > vhost: don't set uaddr for invalid address
> > > > > > > vhost: validate MMU notifier registration
> > > > > > > vhost: fix vhost map leak
> > > > > > > vhost: reset invalidate_count in vhost_set_vring_num_addr()
> > > > > > > vhost: mark dirty pages during map uninit
> > > > > > > vhost: don't do synchronize_rcu() in vhost_uninit_vq_maps()
> > > > > > > vhost: do not use RCU to synchronize MMU notifier with worker
> > > > > > > vhost: correctly set dirty pages in MMU notifiers callback
> > > > > > > vhost: do not return -EAGAIN for non blocking invalidation too early
> > > > > > >
> > > > > > > drivers/vhost/vhost.c | 202 +++++++++++++++++++++++++-----------------
> > > > > > > drivers/vhost/vhost.h | 6 +-
> > > > > > > 2 files changed, 122 insertions(+), 86 deletions(-)
> > > > > > This generally looks more solid.
> > > > > >
> > > > > > But this amounts to a significant overhaul of the code.
> > > > > >
> > > > > > At this point how about we revert 7f466032dc9e5a61217f22ea34b2df932786bbfc
> > > > > > for this release, and then re-apply a corrected version
> > > > > > for the next one?
> > > > > If possible, consider we've actually disabled the feature. How about just
> > > > > queued those patches for next release?
> > > > >
> > > > > Thanks
> > > > Sorry if I was unclear. My idea is that
> > > > 1. I revert the disabled code
> > > > 2. You send a patch readding it with all the fixes squashed
> > > > 3. Maybe optimizations on top right away?
> > > > 4. We queue *that* for next and see what happens.
> > > >
> > > > And the advantage over the patchy approach is that the current patches
> > > > are hard to review. E.g. it's not reasonable to ask RCU guys to review
> > > > the whole of vhost for RCU usage but it's much more reasonable to ask
> > > > about a specific patch.
> > >
> > > Ok. Then I agree to revert.
> > >
> > > Thanks
> > Great, so please send the following:
> > - revert
> > - squashed and fixed patch
>
>
> Just to confirm, do you want me to send a single series or two?
>
> Thanks
>
One is fine.
--
MST
^ permalink raw reply
* Re: [PATCH] net-ipv6: fix excessive RTF_ADDRCONF flag on ::1/128 local route (and others)
From: Maciej Żenczykowski @ 2019-09-01 17:55 UTC (permalink / raw)
To: Maciej Żenczykowski, David S . Miller; +Cc: Linux NetDev, David Ahern
In-Reply-To: <20190901174759.257032-1-zenczykowski@gmail.com>
Some background:
This was found due to bad interactions with one of the few remaining
Android common kernel networking patches.
(The one that makes it possible for RA's to create routes in interface
specific tables)
The cleanup portion of it scours all tables and deletes all relevant
ADDRCONF routes, which in 5.2-rc1+ now includes ::1/128 and thus
terribly breaks things (in the Android Kernel Networking tests).
However, it *is* a userspace visible change in behaviour (since it's
visible via the above /proc file),
so one could argue for the above patch (or something similar).
The Android patch *could* also probably be adjusted to handle this
case (and thus prevent the breakage).
It's not immediately clear to me what is the better approach as I'm
not immediately certain what RTF_ADDRCONF truly means.
However the in kernel header file comment does explicitly mention this
being used to flag routes derived from RA's, and very clearly ::1/128
is not RA generated, so I *think* the correct fix is to return to the
old way the kernel used to do things and not flag with ADDRCONF...
Opinions?
^ 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