Re: [PATCH net V2] cxgb4: fix thermal zone build error

[Randy Dunlap]

On 11/15/18 2:06 AM, Ganesh Goudar wrote:
> with CONFIG_THERMAL=m and cxgb4 as built-in build fails, and
> 'commit e70a57fa59bb ("cxgb4: fix thermal configuration dependencies")'
> tries to fix it but when cxgb4i is made built-in build fails again,
> use IS_REACHABLE instead of IS_ENABLED to fix the issue.
> 
> Fixes: e70a57fa59bb (cxgb4: fix thermal configuration dependencies)
> Reported-by: Randy Dunlap 
> Signed-off-by: Ganesh Goudar 

Acked-by: Randy Dunlap 

Thanks.

> ---
> V2: Fixing spelling mistake and avoid preprocessor conditionals.
> ---
>  drivers/net/ethernet/chelsio/Kconfig| 1 -
>  drivers/net/ethernet/chelsio/cxgb4/Makefile | 4 +---
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++--
>  3 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/chelsio/Kconfig 
> b/drivers/net/ethernet/chelsio/Kconfig
> index 75c1c5e..e2cdfa7 100644
> --- a/drivers/net/ethernet/chelsio/Kconfig
> +++ b/drivers/net/ethernet/chelsio/Kconfig
> @@ -67,7 +67,6 @@ config CHELSIO_T3
>  config CHELSIO_T4
>   tristate "Chelsio Communications T4/T5/T6 Ethernet support"
>   depends on PCI && (IPV6 || IPV6=n)
> - depends on THERMAL || !THERMAL
>   select FW_LOADER
>   select MDIO
>   select ZLIB_DEFLATE
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile 
> b/drivers/net/ethernet/chelsio/cxgb4/Makefile
> index 78e5d17..91d8a88 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
> +++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
> @@ -12,6 +12,4 @@ cxgb4-objs := cxgb4_main.o l2t.o smt.o t4_hw.o sge.o 
> clip_tbl.o cxgb4_ethtool.o
>  cxgb4-$(CONFIG_CHELSIO_T4_DCB) +=  cxgb4_dcb.o
>  cxgb4-$(CONFIG_CHELSIO_T4_FCOE) +=  cxgb4_fcoe.o
>  cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
> -ifdef CONFIG_THERMAL
> -cxgb4-objs += cxgb4_thermal.o
> -endif
> +cxgb4-$(CONFIG_THERMAL) += cxgb4_thermal.o
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 05a4692..d49db46 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -5863,7 +5863,7 @@ static int init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   if (!is_t4(adapter->params.chip))
>   cxgb4_ptp_init(adapter);
>  
> - if (IS_ENABLED(CONFIG_THERMAL) &&
> + if (IS_REACHABLE(CONFIG_THERMAL) &&
>   !is_t4(adapter->params.chip) && (adapter->flags & FW_OK))
>   cxgb4_thermal_init(adapter);
>  
> @@ -5932,7 +5932,7 @@ static void remove_one(struct pci_dev *pdev)
>  
>   if (!is_t4(adapter->params.chip))
>   cxgb4_ptp_stop(adapter);
> - if (IS_ENABLED(CONFIG_THERMAL))
> + if (IS_REACHABLE(CONFIG_THERMAL))
>   cxgb4_thermal_remove(adapter);
>  
>   /* If we allocated filters, free up state associated with any
> 


-- 
~Randy

Re: [PATCH] add an initial version of snmp_counter.rst

[Randy Dunlap]

On 11/9/18 10:13 AM, yupeng wrote:
> The snmp_counter.rst run a set of simple experiments, explains the
> meaning of snmp counters depend on the experiments' results. This is
> an initial version, only covers a small part of the snmp counters.
> 
> Signed-off-by: yupeng 
> ---
>  Documentation/networking/index.rst|   1 +
>  Documentation/networking/snmp_counter.rst | 963 ++
>  2 files changed, 964 insertions(+)
>  create mode 100644 Documentation/networking/snmp_counter.rst

Hi,

> diff --git a/Documentation/networking/snmp_counter.rst 
> b/Documentation/networking/snmp_counter.rst
> new file mode 100644
> index ..2939c5acf675
> --- /dev/null
> +++ b/Documentation/networking/snmp_counter.rst
> @@ -0,0 +1,963 @@
> +
> +snmp counter tutorial
> +

First, I would change (almost) all occurrences of "snmp" to "SNMP", unless
it refers to a variable or struct or function etc. (something in C language)
or to the name of this file (document).

> +
> +This document explains the meaning of snmp counters. For understanding
> +their meanings better, this document doesn't explain the counters one
> +by one, but creates a set of experiments, and explains the counters
> +depend on the experiments' results. The experiments are on one or two

   depending on

> +virtual machines. Except for the test commands we use in the experiments,
> +the virtual machines have no other network traffic. We use the 'nstat'
> +command to get the values of snmp counters, before every test, we run

 counters;

> +'nstat -n' to update the history, so the 'nstat' output would only
> +show the changes of the snmp counters. For more information about
> +nstat, please refer:
> +
> +http://man7.org/linux/man-pages/man8/nstat.8.html
> +
> +icmp ping
> +

s/icmp/ICMP/

> +
> +Run the ping command against the public dns server 8.8.8.8::
> +
> +  nstatuser@nstat-a:~$ ping 8.8.8.8 -c 1
> +  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> +  64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=17.8 ms
> +
> +  --- 8.8.8.8 ping statistics ---
> +  1 packets transmitted, 1 received, 0% packet loss, time 0ms
> +  rtt min/avg/max/mdev = 17.875/17.875/17.875/0.000 ms
> +
> +The nstayt result::

   nstat

> +
> +  nstatuser@nstat-a:~$ nstat
> +  #kernel
> +  IpInReceives1  0.0
> +  IpInDelivers1  0.0
> +  IpOutRequests   1  0.0
> +  IcmpInMsgs  1  0.0
> +  IcmpInEchoReps  1  0.0
> +  IcmpOutMsgs 1  0.0
> +  IcmpOutEchos1  0.0
> +  IcmpMsgInType0  1  0.0
> +  IcmpMsgOutType8 1  0.0
> +  IpExtInOctets   84 0.0
> +  IpExtOutOctets  84 0.0
> +  IpExtInNoECTPkts1  0.0
> +
> +The nstat output could be divided into two part: one with the 'Ext'
> +keyword, another without the 'Ext' keyword. If the counter name
> +doesn't have 'Ext', it is defined by one of snmp rfc, if it has 'Ext',

 by one of the SNMP RFCs; it is has

> +it is a kernel extent counter. Below we explain them one by one.
> +
> +The rfc defined counters
> +--
s/rfc/RFC/

> +
> +* IpInReceives
> +The total number of input datagrams received from interfaces,
> +including those received in error.
> +
> +https://tools.ietf.org/html/rfc1213#page-26
> +
> +* IpInDelivers
> +The total number of input datagrams successfully delivered to IP
> +user-protocols (including ICMP).
> +
> +https://tools.ietf.org/html/rfc1213#page-28
> +
> +* IpOutRequests
> +The total number of IP datagrams which local IP user-protocols
> +(including ICMP) supplied to IP in requests for transmission.  Note
> +that this counter does not include any datagrams counted in
> +ipForwDatagrams.
> +
> +https://tools.ietf.org/html/rfc1213#page-28
> +
> +* IcmpInMsgs
> +The total number of ICMP messages which the entity received.  Note
> +that this counter includes all those counted by icmpInErrors.
> +
> +https://tools.ietf.org/html/rfc1213#page-41
> +
> +* IcmpInEchoReps
> +The number of ICMP Echo Reply messages received.
> +
> +https://tools.ietf.org/html/rfc1213#page-42
> +
> +* IcmpOutMsgs
> +The total number of ICMP messages which this entity attempted to send.
> +Note that this counter includes all those counted by icmpOutErrors.
> +
> +https://tools.ietf.org/html/rfc1213#page-43
> +
> +* IcmpOutEchos
> +The number of ICMP Echo (request) messages sent.
> +
> +https://tools.ietf.org/html/rfc1213#page-45
> +
> +IcmpMsgInType0 and IcmpMsgOutType8 are not defined by any snmp related

 SNMP-related

> +RFCs, 

Re: [PATCH net-next] net: core: change bool members of struct net_device to bitfield members

[Randy Dunlap]

On 10/8/18 1:00 PM, Heiner Kallweit wrote:
> bool is good as parameter type or function return type, but if used
> for struct members it consumes more memory than needed.
> Changing the bool members of struct net_device to bitfield members
> allows to decrease the memory footprint of this struct.
> 
> Signed-off-by: Heiner Kallweit 
> ---
>  include/linux/netdevice.h | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 76603ee13..3d7b8df2e 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1651,10 +1651,6 @@ enum netdev_priv_flags {
>   *   @dev_port:  Used to differentiate devices that share
>   *   the same function
>   *   @addr_list_lock:XXX: need comments on this one
> - *   @uc_promisc:Counter that indicates promiscuous mode
> - *   has been enabled due to the need to listen to
> - *   additional unicast addresses in a device that
> - *   does not implement ndo_set_rx_mode()
>   *   @uc:unicast mac addresses
>   *   @mc:multicast mac addresses
>   *   @dev_addrs: list of device hw addresses
> @@ -1714,11 +1710,9 @@ enum netdev_priv_flags {
>   *   @link_watch_list:   XXX: need comments on this one
>   *
>   *   @reg_state: Register/unregister state machine
> - *   @dismantle: Device is going to be freed
>   *   @rtnl_link_state:   This enum represents the phases of creating
>   *   a new link
>   *
> - *   @needs_free_netdev: Should unregister perform free_netdev?
>   *   @priv_destructor:   Called from unregister
>   *   @npinfo:XXX: need comments on this one
>   *   @nd_net:Network namespace this network device is inside
> @@ -1758,6 +1752,15 @@ enum netdev_priv_flags {
>   *   @qdisc_tx_busylock: lockdep class annotating Qdisc->busylock spinlock
>   *   @qdisc_running_key: lockdep class annotating Qdisc->running seqcount
>   *
> + *   @uc_promisc:Counter that indicates promiscuous mode
> + *   has been enabled due to the need to listen to
> + *   additional unicast addresses in a device that
> + *   does not implement ndo_set_rx_mode()

Hi,

I see that all you did is copy/paste that text (above), but I wouldn't call
a single bit a [1-bit] Counter.

thanks,
-- 
~Randy

Re: [PATCH bpf-next] flow_dissector: fix build failure without CONFIG_NET

[Randy Dunlap]

On 9/18/18 1:20 PM, Willem de Bruijn wrote:
> From: Willem de Bruijn 
> 
> If boolean CONFIG_BPF_SYSCALL is enabled, kernel/bpf/syscall.c will
> call flow_dissector functions from net/core/flow_dissector.c.
> 
> This causes this build failure if CONFIG_NET is disabled:
> 
> kernel/bpf/syscall.o: In function `__x64_sys_bpf':
> syscall.c:(.text+0x3278): undefined reference to
> `skb_flow_dissector_bpf_prog_attach'
> syscall.c:(.text+0x3310): undefined reference to
> `skb_flow_dissector_bpf_prog_detach'
> kernel/bpf/syscall.o:(.rodata+0x3f0): undefined reference to
> `flow_dissector_prog_ops'
> kernel/bpf/verifier.o:(.rodata+0x250): undefined reference to
> `flow_dissector_verifier_ops'
> 
> Analogous to other optional BPF program types in syscall.c, add stubs
> if the relevant functions are not compiled and move the BPF_PROG_TYPE
> definition in the #ifdef CONFIG_NET block.
> 
> Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook")
> Reported-by: Randy Dunlap 
> Signed-off-by: Willem de Bruijn 

Works for me.  Thanks.

Acked-by: Randy Dunlap  # build-tested


> ---
>  include/linux/bpf_types.h |  2 +-
>  include/linux/skbuff.h| 13 +
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
> index 22083712dd18..c9bd6fb765b0 100644
> --- a/include/linux/bpf_types.h
> +++ b/include/linux/bpf_types.h
> @@ -16,6 +16,7 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_LWT_SEG6LOCAL, lwt_seg6local)
>  BPF_PROG_TYPE(BPF_PROG_TYPE_SOCK_OPS, sock_ops)
>  BPF_PROG_TYPE(BPF_PROG_TYPE_SK_SKB, sk_skb)
>  BPF_PROG_TYPE(BPF_PROG_TYPE_SK_MSG, sk_msg)
> +BPF_PROG_TYPE(BPF_PROG_TYPE_FLOW_DISSECTOR, flow_dissector)
>  #endif
>  #ifdef CONFIG_BPF_EVENTS
>  BPF_PROG_TYPE(BPF_PROG_TYPE_KPROBE, kprobe)
> @@ -32,7 +33,6 @@ BPF_PROG_TYPE(BPF_PROG_TYPE_LIRC_MODE2, lirc_mode2)
>  #ifdef CONFIG_INET
>  BPF_PROG_TYPE(BPF_PROG_TYPE_SK_REUSEPORT, sk_reuseport)
>  #endif
> -BPF_PROG_TYPE(BPF_PROG_TYPE_FLOW_DISSECTOR, flow_dissector)
>  
>  BPF_MAP_TYPE(BPF_MAP_TYPE_ARRAY, array_map_ops)
>  BPF_MAP_TYPE(BPF_MAP_TYPE_PERCPU_ARRAY, percpu_array_map_ops)
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index ce0e863f02a2..76be85ea392a 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -1194,10 +1194,23 @@ void skb_flow_dissector_init(struct flow_dissector 
> *flow_dissector,
>const struct flow_dissector_key *key,
>unsigned int key_count);
>  
> +#ifdef CONFIG_NET
>  int skb_flow_dissector_bpf_prog_attach(const union bpf_attr *attr,
>  struct bpf_prog *prog);
>  
>  int skb_flow_dissector_bpf_prog_detach(const union bpf_attr *attr);
> +#else
> +static inline int skb_flow_dissector_bpf_prog_attach(const union bpf_attr 
> *attr,
> +  struct bpf_prog *prog)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int skb_flow_dissector_bpf_prog_detach(const union bpf_attr 
> *attr)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif
>  
>  bool __skb_flow_dissect(const struct sk_buff *skb,
>   struct flow_dissector *flow_dissector,
> 


-- 
~Randy

Re: linux-next: Tree for Jul 25 (netfilter)

[Randy Dunlap]

On 07/24/2018 11:44 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180724:
> 

on i386:

net/ipv4/netfilter/nft_chain_nat_ipv4.o: In function `nft_nat_do_chain':
nft_chain_nat_ipv4.c:(.text+0x67): undefined reference to `nft_do_chain'
net/ipv4/netfilter/nft_chain_nat_ipv4.o: In function `nft_chain_nat_exit':
nft_chain_nat_ipv4.c:(.exit.text+0x9): undefined reference to 
`nft_unregister_chain_type'
net/ipv4/netfilter/nft_chain_nat_ipv4.o: In function `nft_chain_nat_init':
nft_chain_nat_ipv4.c:(.init.text+0x9): undefined reference to 
`nft_register_chain_type'


Reported-by: Randy Dunlap 

Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.18.0-rc6 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 4.8.5
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40805
CONFIG_CLANG_VERSION=0
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_IRQ_TIME_ACCOUNTING=y
# CONFIG_CPU_ISOLATION is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
# CONFIG_POSIX_TIMERS is not set
# CONFIG_PRINTK is not set
# CONFIG_BUG is not set
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
# CONFIG_SIGNALFD is not set
# CONFIG_TIMERFD is not set
# CONFIG_EVENTFD is not set
# CONFIG_SHMEM is not set
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
# CONFIG_MEMBARRIER is not set
CONFIG_KA

[PATCH v2] tcp: identify cryptic messages as TCP seq # bugs

[Randy Dunlap]

From: Randy Dunlap 

Attempt to make cryptic TCP seq number error messages clearer by
(1) identifying the source of the message as "TCP", (2) identifying the
errors as "seq # bug", and (3) grouping the field identifiers and values
by separating them with commas.

E.g., the following message is changed from:

recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90

to:

TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 73BCB9AA, fl 0
WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 tcp_recvmsg+0x694/0xba0

Suggested-by: 積丹尼 Dan Jacobson 
Signed-off-by: Randy Dunlap 
---
v2: drop __func__ because it duplicates part of the error message.

 net/ipv4/tcp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20180717.orig/net/ipv4/tcp.c
+++ linux-next-20180717/net/ipv4/tcp.c
@@ -1994,7 +1994,7 @@ int tcp_recvmsg(struct sock *sk, struct
 * shouldn't happen.
 */
if (WARN(before(*seq, TCP_SKB_CB(skb)->seq),
-"recvmsg bug: copied %X seq %X rcvnxt %X fl 
%X\n",
+"TCP recvmsg seq # bug: copied %X, seq %X, 
rcvnxt %X, fl %X\n",
 *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt,
 flags))
break;
@@ -2009,7 +2009,7 @@ int tcp_recvmsg(struct sock *sk, struct
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto found_fin_ok;
WARN(!(flags & MSG_PEEK),
-"recvmsg bug 2: copied %X seq %X rcvnxt %X fl 
%X\n",
+"TCP recvmsg seq # bug 2: copied %X, seq %X, 
rcvnxt %X, fl %X\n",
 *seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
}
 

Re: [PATCH net-next] TCP: make seq # error messages more readable

[Randy Dunlap]

On 07/13/2018 06:38 AM, Eric Dumazet wrote:
> 
> 
> On 07/12/2018 05:48 PM, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> Attempt to make cryptic TCP seq number error messages clearer by
>> (1) adding the function name, (2) identifying the errors as "seq # bug",
>> and (3) grouping the field identifiers and values by separating them
>> with commas.
>>
>> E.g., the following message is changed from:
>>
>> recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
>> WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 
>> tcp_recvmsg+0x649/0xb90
>>
>> to:
>>
>> tcp_recvmsg: TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 
>> 73BCB9AA, fl 0
>> WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 
>> tcp_recvmsg+0x694/0xba0
>>
> 
> Hi Randy
> 
> It is not clear what this patch improves.
> Do we really to mention tcp twice ?

I will gladly drop the __func__: string.  Doing so would change this:

recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0

to:

TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 73BCB9AA, fl 0


The (new) message identifies that it is TCP and that it is a sequence # bug.
Both of those are helpful in my view, whereas the original message isn't
helpful at all.


> 
> Thanks.


-- 
~Randy

[PATCH net-next] TCP: make seq # error messages more readable

[Randy Dunlap]

From: Randy Dunlap 

Attempt to make cryptic TCP seq number error messages clearer by
(1) adding the function name, (2) identifying the errors as "seq # bug",
and (3) grouping the field identifiers and values by separating them
with commas.

E.g., the following message is changed from:

recvmsg bug 2: copied 73BCB6CD seq 70F17CBE rcvnxt 73BCB9AA fl 0
WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:1881 tcp_recvmsg+0x649/0xb90

to:

tcp_recvmsg: TCP recvmsg seq # bug 2: copied 73BCB6CD, seq 70F17CBE, rcvnxt 
73BCB9AA, fl 0
WARNING: CPU: 2 PID: 1501 at /linux/net/ipv4/tcp.c:2011 tcp_recvmsg+0x694/0xba0

Suggested-by: 積丹尼 Dan Jacobson 
Signed-off-by: Randy Dunlap 
---
 net/ipv4/tcp.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

--- linux-next-20180712.orig/net/ipv4/tcp.c
+++ linux-next-20180712/net/ipv4/tcp.c
@@ -1994,9 +1994,9 @@ int tcp_recvmsg(struct sock *sk, struct
 * shouldn't happen.
 */
if (WARN(before(*seq, TCP_SKB_CB(skb)->seq),
-"recvmsg bug: copied %X seq %X rcvnxt %X fl 
%X\n",
-*seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt,
-flags))
+"%s: TCP recvmsg seq # bug: copied %X, seq %X, 
rcvnxt %X, fl %X\n",
+__func__, *seq,
+TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags))
break;
 
offset = *seq - TCP_SKB_CB(skb)->seq;
@@ -2009,8 +2009,9 @@ int tcp_recvmsg(struct sock *sk, struct
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN)
goto found_fin_ok;
WARN(!(flags & MSG_PEEK),
-"recvmsg bug 2: copied %X seq %X rcvnxt %X fl 
%X\n",
-*seq, TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
+"%s: TCP recvmsg seq # bug 2: copied %X, seq %X, 
rcvnxt %X, fl %X\n",
+__func__, *seq,
+TCP_SKB_CB(skb)->seq, tp->rcv_nxt, flags);
}
 
/* Well, if we have backlog, try to process it now yet. */

[PATCH] isdn/capi: fix defined but not used warnings

[Randy Dunlap]

From: Randy Dunlap 

Fix build warnings in drivers/isdn/capi/ when CONFIG_PROC_FS is not
enabled by marking the unused functions as __maybe_unused.

../drivers/isdn/capi/capi.c:1324:12: warning: 'capi20_proc_show' defined but 
not used [-Wunused-function]
../drivers/isdn/capi/capi.c:1347:12: warning: 'capi20ncci_proc_show' defined 
but not used [-Wunused-function]
../drivers/isdn/capi/capidrv.c:2454:12: warning: 'capidrv_proc_show' defined 
but not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Karsten Keil 
Cc: isdn4li...@listserv.isdn4linux.de (subscribers-only)
Cc: netdev@vger.kernel.org
---
 drivers/isdn/capi/capi.c|5 +++--
 drivers/isdn/capi/capidrv.c |3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

--- linux-next-20180706.orig/drivers/isdn/capi/capi.c
+++ linux-next-20180706/drivers/isdn/capi/capi.c
@@ -9,6 +9,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1321,7 +1322,7 @@ static inline void capinc_tty_exit(void)
  * /proc/capi/capi20:
  *  minor applid nrecvctlpkt nrecvdatapkt nsendctlpkt nsenddatapkt
  */
-static int capi20_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused capi20_proc_show(struct seq_file *m, void *v)
 {
struct capidev *cdev;
struct list_head *l;
@@ -1344,7 +1345,7 @@ static int capi20_proc_show(struct seq_f
  * /proc/capi/capi20ncci:
  *  applid ncci
  */
-static int capi20ncci_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused capi20ncci_proc_show(struct seq_file *m, void *v)
 {
struct capidev *cdev;
struct capincci *np;
--- linux-next-20180706.orig/drivers/isdn/capi/capidrv.c
+++ linux-next-20180706/drivers/isdn/capi/capidrv.c
@@ -9,6 +9,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -2451,7 +2452,7 @@ lower_callback(struct notifier_block *nb
  * /proc/capi/capidrv:
  * nrecvctlpkt nrecvdatapkt nsendctlpkt nsenddatapkt
  */
-static int capidrv_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused capidrv_proc_show(struct seq_file *m, void *v)
 {
seq_printf(m, "%lu %lu %lu %lu\n",
   global.ap.nrecvctlpkt,

[PATCH] connector: fix defined but not used warning

[Randy Dunlap]

From: Randy Dunlap 

Fix a build warning in connector.c when CONFIG_PROC_FS is not enabled
by marking the unused function as __maybe_unused.

../drivers/connector/connector.c:242:12: warning: 'cn_proc_show' defined but 
not used [-Wunused-function]

Signed-off-by: Randy Dunlap 
Cc: Evgeniy Polyakov 
Cc: netdev@vger.kernel.org
---
 drivers/connector/connector.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20180706.orig/drivers/connector/connector.c
+++ linux-next-20180706/drivers/connector/connector.c
@@ -19,6 +19,7 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -239,7 +240,7 @@ void cn_del_callback(struct cb_id *id)
 }
 EXPORT_SYMBOL_GPL(cn_del_callback);
 
-static int cn_proc_show(struct seq_file *m, void *v)
+static int __maybe_unused cn_proc_show(struct seq_file *m, void *v)
 {
struct cn_queue_dev *dev = cdev.cbdev;
struct cn_callback_entry *cbq;

Re: mmotm 2018-05-25-14-52 uploaded (drivers/net/ethernet/ti/davinci_mdio.c)

[Randy Dunlap]

[forgot to add netdev]

On 05/25/2018 04:14 PM, Randy Dunlap wrote:
> On 05/25/2018 02:52 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-05-25-14-52 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>> more than once a week.
> 
> on x86_64:
> # CONFIG_OF is not set
> 
>   CC  drivers/net/ethernet/ti/davinci_cpdma.o
> ../drivers/net/ethernet/ti/davinci_mdio.c: In function 'davinci_mdio_probe':
> ../drivers/net/ethernet/ti/davinci_mdio.c:380:3: error: implicit declaration 
> of function 'davinci_mdio_probe_dt' [-Werror=implicit-function-declaration]
>ret = davinci_mdio_probe_dt(>pdata, pdev);
> 
> 
> 
>>
>> You will need quilt to apply these patches to the latest Linus release (4.x
>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>> http://ozlabs.org/~akpm/mmotm/series
>>
>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>> followed by the base kernel version against which this patch series is to
>> be applied.
>>
>> This tree is partially included in linux-next.  To see which patches are
>> included in linux-next, consult the `series' file.  Only the patches
>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>> linux-next.
>>
>> A git tree which contains the memory management portion of this tree is
>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> by Michal Hocko.  It contains the patches which are between the
>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>
>>
>> A full copy of the full kernel tree with the linux-next and mmotm patches
>> already applied is available through git within an hour of the mmotm
>> release.  Individual mmotm releases are tagged.  The master branch always
>> points to the latest release, so it's constantly rebasing.
>>
>> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/
>>
>> To develop on top of mmotm git:
>>
>>   $ git remote add mmotm 
>> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>>   $ git remote update mmotm
>>   $ git checkout -b topic mmotm/master
>>   
>>   $ git send-email mmotm/master.. [...]
>>
>> To rebase a branch with older patches to a new mmotm release:
>>
>>   $ git remote update mmotm
>>   $ git rebase --onto mmotm/master  topic
>>
>>
>>
>>
>> The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
>> contains daily snapshots of the -mm tree.  It is updated more frequently
>> than mmotm, and is untested.
>>
>> A git copy of this tree is available at
>>
>>  http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/
>>
>> and use of this tree is similar to
>> http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.
>>
>>
>> This mmotm tree contains the following patches against 4.17-rc6:
>> (patches marked "*" will be included in linux-next)
>>
> 
> 


-- 
~Randy

Re: [PATCH v1 1/4] media: rc: introduce BPF_PROG_IR_DECODER

[Randy Dunlap]

On 05/14/2018 02:10 PM, Sean Young wrote:
> Add support for BPF_PROG_IR_DECODER. This type of BPF program can call

Kconfig file below uses IR_BPF_DECODER instead of the symbol name above.

and then patch 3 says a third choice:
The context provided to a BPF_PROG_RAWIR_DECODER is a struct ir_raw_event;

> rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
> that the last key should be repeated.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/Kconfig  |  8 +++
>  drivers/media/rc/Makefile |  1 +
>  drivers/media/rc/ir-bpf-decoder.c | 93 +++
>  include/linux/bpf_types.h |  3 +
>  include/uapi/linux/bpf.h  | 16 +-
>  5 files changed, 120 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/rc/ir-bpf-decoder.c
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index eb2c3b6eca7f..10ad6167d87c 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -120,6 +120,14 @@ config IR_IMON_DECODER
>  remote control and you would like to use it with a raw IR
>  receiver, or if you wish to use an encoder to transmit this IR.
>  
> +config IR_BPF_DECODER
> + bool "Enable IR raw decoder using BPF"
> + depends on BPF_SYSCALL
> + depends on RC_CORE=y
> + help
> +Enable this option to make it possible to load custom IR
> +decoders written in BPF.
> +
>  endif #RC_DECODERS
>  
>  menuconfig RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 2e1c87066f6c..12e1118430d0 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -5,6 +5,7 @@ obj-y += keymaps/
>  obj-$(CONFIG_RC_CORE) += rc-core.o
>  rc-core-y := rc-main.o rc-ir-raw.o
>  rc-core-$(CONFIG_LIRC) += lirc_dev.o
> +rc-core-$(CONFIG_IR_BPF_DECODER) += ir-bpf-decoder.o


-- 
~Randy

Re: [net 1/1] net/mlx5: Fix build break when CONFIG_SMP=n

[Randy Dunlap]

On 05/14/2018 03:38 PM, Saeed Mahameed wrote:
> Avoid using the kernel's irq_descriptor and return IRQ vector affinity
> directly from the driver.
> 
> This fixes the following build break when CONFIG_SMP=n
> 
> include/linux/mlx5/driver.h: In function ‘mlx5_get_vector_affinity_hint’:
> include/linux/mlx5/driver.h:1299:13: error:
> ‘struct irq_desc’ has no member named ‘affinity_hint’
> 
> Fixes: 6082d9c9c94a ("net/mlx5: Fix mlx5_get_vector_affinity function")
> Signed-off-by: Saeed Mahameed <sae...@mellanox.com>
> CC: Randy Dunlap <rdun...@infradead.org>
> CC: Guenter Roeck <li...@roeck-us.net>
> CC: Thomas Gleixner <t...@linutronix.de>
> Tested-by: Israel Rukshin <isra...@mellanox.com>

Reported-by: kbuild test robot <l...@intel.com>
Reported-by: Randy Dunlap <rdun...@infradead.org>
Tested-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
> 
> For -stable v4.14
> 
>  include/linux/mlx5/driver.h | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
> index 2a156c5dfadd..d703774982ca 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -1286,17 +1286,7 @@ enum {
>  static inline const struct cpumask *
>  mlx5_get_vector_affinity_hint(struct mlx5_core_dev *dev, int vector)
>  {
> - struct irq_desc *desc;
> - unsigned int irq;
> - int eqn;
> - int err;
> -
> - err = mlx5_vector2eqn(dev, vector, , );
> - if (err)
> - return NULL;
> -
> - desc = irq_to_desc(irq);
> - return desc->affinity_hint;
> + return dev->priv.irq_info[vector].mask;
>  }
>  
>  #endif /* MLX5_DRIVER_H */
> 


-- 
~Randy

Re: linux-next: Tree for May 9 (mlx5)

[Randy Dunlap]

On 05/09/2018 04:21 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180508:
> 

on x86_64:
# CONFIG_SMP is not set

In file included from ../drivers/net/ethernet/mellanox/mlx5/core/main.c:43:0:
../include/linux/mlx5/driver.h: In function 'mlx5_get_vector_affinity_hint':
../include/linux/mlx5/driver.h:1299:13: error: 'struct irq_desc' has no member 
named 'affinity_hint'
  return desc->affinity_hint;
 ^


-- 
~Randy

Re: [PATCH] net/9p: correct some comment errors in 9p file system code

[Randy Dunlap]

On 05/07/2018 06:49 PM, Sun Lianwen wrote:
> There are follow comment errors:
> 1 The function name is wrong in p9_release_pages() comment.
> 2 The function name and variable name is wrong in p9_poll_workfn() comment.
> 3 There is no variable dm_mr and lkey in struct p9_trans_rdma.
> 4 The function name is wrong in rdma_create_trans() comment.
> 5 There is no variable initialized in struct virtio_chan.
> 6 The variable name is wrong in p9_virtio_zc_request() comment.
> 
> Signed-off-by: Sun Lianwen <sunlw.f...@cn.fujitsu.com>
> Reviewed-by: Randy Dunlap <rdun...@infradead.org>

Uh, you aren't supposed to add that (line above) until or unless I offer it.
See Documentation/process/submitting-patches.rst for details.


> ---
>  net/9p/trans_common.c | 2 +-
>  net/9p/trans_fd.c | 4 ++--
>  net/9p/trans_rdma.c   | 4 +---
>  net/9p/trans_virtio.c | 5 ++---
>  4 files changed, 6 insertions(+), 9 deletions(-)




Reviewed-by: Randy Dunlap <rdun...@infradead.org>

thanks,
-- 
~Randy

Re: [PATCH] net/9p: correct some comment errors in 9p file system code

[Randy Dunlap]

On 05/07/2018 05:45 PM, Sun Lianwen wrote:
> There are follow comment errors:
> 1 The function name is wrong in p9_release_pages() comment.
> 2 The function name and variable name is wrong in p9_poll_workfn() comment.
> 3 There is no variable dm_mr and lkey in struct p9_trans_rdma.
> 4 The function name is wrong in rdma_create_trans() comment.
> 5 There is no variable initialized in struct virtio_chan.
> 6 The variable name is wrong in p9_virtio_zc_request() comment.
> 
> Signed-off-by: Sun Lianwen 
> ---
>  net/9p/trans_common.c | 2 +-
>  net/9p/trans_fd.c | 4 ++--
>  net/9p/trans_rdma.c   | 4 +---
>  net/9p/trans_virtio.c | 5 ++---
>  4 files changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
> index 6d8e3031978f..88c71c0e95df 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -632,7 +630,7 @@ static int p9_rdma_bind_privport(struct p9_trans_rdma 
> *rdma)
>  }
>  
>  /**
> - * trans_create_rdma - Transport method for creating atransport instance
> + * rdma_create_trans - Transport method for creating atransport instance

a transport

>   * @client: client instance
>   * @addr: IP address string
>   * @args: Mount options string


-- 
~Randy

Re: [PATCH net-next v10 2/4] net: Introduce generic failover module

[Randy Dunlap]

Hi,

On 05/07/2018 03:10 PM, Sridhar Samudrala wrote:
> 
> Signed-off-by: Sridhar Samudrala 
> ---
>  MAINTAINERS|7 +
>  include/linux/netdevice.h  |   16 +
>  include/net/net_failover.h |   52 +++
>  net/Kconfig|   10 +
>  net/core/Makefile  |1 +
>  net/core/net_failover.c| 1044 
> 
>  6 files changed, 1130 insertions(+)
>  create mode 100644 include/net/net_failover.h
>  create mode 100644 net/core/net_failover.c


> diff --git a/net/Kconfig b/net/Kconfig
> index b62089fb1332..0540856676de 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -429,6 +429,16 @@ config MAY_USE_DEVLINK
>  config PAGE_POOL
> bool
>  
> +config NET_FAILOVER
> + tristate "Failover interface"
> + default m

Need some justification for default m (as opposed to n).

> + help
> +   This provides a generic interface for paravirtual drivers to listen
> +   for netdev register/unregister/link change events from pci ethernet

 PCI

> +   devices with the same MAC and takeover their datapath. This also
> +   enables live migration of a VM with direct attached VF by failing
> +   over to the paravirtual datapath when the VF is unplugged.
> +
>  endif   # if NET
>  
>  # Used by archs to tell that they support BPF JIT compiler plus which 
> flavour.

> diff --git a/net/core/net_failover.c b/net/core/net_failover.c
> new file mode 100644
> index ..8d60e74e3034
> --- /dev/null
> +++ b/net/core/net_failover.c
> @@ -0,0 +1,1044 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, Intel Corporation. */
> +
> +/* A common module to handle registrations and notifications for paravirtual
> + * drivers to enable accelerated datapath and support VF live migration.
> + *
> + * The notifier and event handling code is based on netvsc driver and 
> failover
> + * netdev management routines are based on bond/team driver.
> + *
> + */


> +/**
> + * net_failover_create - Create and register a failover instance
> + *
> + * @dev: standby netdev

* @standby_dev: standby netdev

> + *
> + * Creates a failover netdev and registers a failover instance for a standby
> + * netdev. Used by paravirtual drivers that use 3-netdev model.
> + * The failover netdev acts as a master device and controls 2 slave devices -
> + * the original standby netdev and a VF netdev with the same MAC gets
> + * registered as primary netdev.
> + *
> + * Return: pointer to failover instance
> + */
> +struct net_failover *net_failover_create(struct net_device *standby_dev)
> +{
> + struct device *dev = standby_dev->dev.parent;
> + struct net_device *failover_dev;
> + struct net_failover *failover;
> + int err;
> +
> + /* Alloc at least 2 queues, for now we are going with 16 assuming
> +  * that VF devices being enslaved won't have too many queues.
> +  */
> + failover_dev = alloc_etherdev_mq(sizeof(struct net_failover_info), 16);
> + if (!failover_dev) {
> + dev_err(dev, "Unable to allocate failover_netdev!\n");
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + dev_net_set(failover_dev, dev_net(standby_dev));
> + SET_NETDEV_DEV(failover_dev, dev);
> +
> + failover_dev->netdev_ops = _dev_ops;
> + failover_dev->ethtool_ops = _ethtool_ops;
> +
> + /* Initialize the device options */
> + failover_dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + failover_dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> +IFF_TX_SKB_SHARING);
> +
> + /* don't acquire failover netdev's netif_tx_lock when transmitting */
> + failover_dev->features |= NETIF_F_LLTX;
> +
> + /* Don't allow failover devices to change network namespaces. */
> + failover_dev->features |= NETIF_F_NETNS_LOCAL;
> +
> + failover_dev->hw_features = FAILOVER_VLAN_FEATURES |
> + NETIF_F_HW_VLAN_CTAG_TX |
> + NETIF_F_HW_VLAN_CTAG_RX |
> + NETIF_F_HW_VLAN_CTAG_FILTER;
> +
> + failover_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL;
> + failover_dev->features |= failover_dev->hw_features;
> +
> + memcpy(failover_dev->dev_addr, standby_dev->dev_addr,
> +failover_dev->addr_len);
> +
> + failover_dev->min_mtu = standby_dev->min_mtu;
> + failover_dev->max_mtu = standby_dev->max_mtu;
> +
> + err = register_netdev(failover_dev);
> + if (err) {
> + dev_err(dev, "Unable to register failover_dev!\n");
> + goto err_register_netdev;
> + }
> +
> + netif_carrier_off(failover_dev);
> +
> + failover = net_failover_register(failover_dev, NULL);
> + if (IS_ERR(failover))
> + goto err_failover_register;
> +
> + return failover;
> +
> +err_failover_register:
> + 

Re: [PATCH bpf-next] xsk: fix 64-bit division

[Randy Dunlap]

On 05/07/2018 10:43 AM, Björn Töpel wrote:
> From: Björn Töpel <bjorn.to...@intel.com>
> 
> i386 builds report:
>   net/xdp/xdp_umem.o: In function `xdp_umem_reg':
>   xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3'
> 
> This fix uses div_u64 instead of the GCC built-in.
> 
> Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt")
> Signed-off-by: Björn Töpel <bjorn.to...@intel.com>

I don't know why the subject says xsk (instead of xdp), but anyway:

Reported-by: Randy Dunlap <rdun...@infradead.org>
Tested-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  net/xdp/xdp_umem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 881dfdefe235..2b47a1dd7c6c 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -209,7 +209,7 @@ int xdp_umem_reg(struct xdp_umem *umem, struct 
> xdp_umem_reg *mr)
>   if ((addr + size) < addr)
>   return -EINVAL;
>  
> - nframes = size / frame_size;
> + nframes = (unsigned int)div_u64(size, frame_size);
>   if (nframes == 0 || nframes > UINT_MAX)
>   return -EINVAL;
>  
> 


-- 
~Randy

Re: linux-next: Tree for May 7 (net/xdp)

[Randy Dunlap]

On 05/06/2018 10:31 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20180504:
> 

on i386:

net/xdp/xdp_umem.o: In function `xdp_umem_reg':
xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3'


-- 
~Randy

Re: [PATCH] atm: zatm: Fix potential Spectre v1

[Randy Dunlap]

On 05/03/2018 11:17 AM, Gustavo A. R. Silva wrote:
> pool can be indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
> 
> This issue was detected with the help of Smatch:
> 
> drivers/atm/zatm.c:1462 zatm_ioctl() warn: potential spectre issue
> 'zatm_dev->pool_info' (local cap)
> 
> Fix this by sanitizing pool before using it to index
> zatm_dev->pool_info
> 
> Notice that given that speculation windows are large, the policy is
> to kill the speculation on the first load and not worry if it can be
> completed with a dependent load/store [1].
> 
> [1] https://marc.info/?l=linux-kernel=152449131114778=2

Hi,

Just for (my) info:  all of these types of patches are to prevent
what is loaded in cache when the index is out of range, right?
Not some random pool_info[random], but pool_info[valid, i.e., 0].

Since the value of pool is already sanity checked and -EINVAL is
returned when it's out of range.

Thanks.

> Cc: sta...@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/atm/zatm.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/atm/zatm.c b/drivers/atm/zatm.c
> index 1ef67db..9c9a229 100644
> --- a/drivers/atm/zatm.c
> +++ b/drivers/atm/zatm.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "uPD98401.h"
>  #include "uPD98402.h"
> @@ -1458,6 +1459,8 @@ static int zatm_ioctl(struct atm_dev *dev,unsigned int 
> cmd,void __user *arg)
>   return -EFAULT;
>   if (pool < 0 || pool > ZATM_LAST_POOL)
>   return -EINVAL;
> + pool = array_index_nospec(pool,
> +   ZATM_LAST_POOL + 1);
>   spin_lock_irqsave(_dev->lock, flags);
>   info = zatm_dev->pool_info[pool];
>   if (cmd == ZATM_GETPOOLZ) {
> 


-- 
~Randy

Re: [net-next] ipv6: sr: Add documentation for seg_flowlabel sysctl

[Randy Dunlap]

On 04/27/2018 03:35 AM, Ahmed Abdelsalam wrote:
> This patch adds a documentation for seg_flowlabel sysctl into
> Documentation/networking/ip-sysctl.txt
> 
> Signed-off-by: Ahmed Abdelsalam 
> ---
>  Documentation/networking/ip-sysctl.txt | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/networking/ip-sysctl.txt 
> b/Documentation/networking/ip-sysctl.txt
> index 5dc1a04..7528f71 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1428,6 +1428,19 @@ ip6frag_low_thresh - INTEGER
>  ip6frag_time - INTEGER
>   Time in seconds to keep an IPv6 fragment in memory.
>  
> +IPv6 Segment Routing:
> +
> +seg6_flowlabel - INTEGER
> + Controls the behaviour of computing the flowlabel of outer
> + IPv6 header in case of SR T.encaps
> +
> + -1 set flowlabel to zero.
> + 0 copy flowlabel from Inner paceket in case of Inner IPv6

packet

> + (Set flowlabel to 0 in case IPv4/L2)
> + 1 Compute the flowlabel using seg6_make_flowlabel()
> +
> + Default is 0.
> +
>  conf/default/*:
>   Change the interface-specific default settings.
>  
> 


-- 
~Randy

Re: [PATCH] fault-injection: reorder config entries

[Randy Dunlap]

On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
> This patch reorders Kconfig entries, so that menuconfig displays proper 
> indentation.
> 
> Signed-off-by: Mikulas Patocka <mpato...@redhat.com>

Acked-by: Randy Dunlap <rdun...@infradead.org>
Tested-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  lib/Kconfig.debug |   36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> Index: linux-2.6/lib/Kconfig.debug
> ===
> --- linux-2.6.orig/lib/Kconfig.debug  2018-04-16 21:08:36.0 +0200
> +++ linux-2.6/lib/Kconfig.debug   2018-04-25 15:56:16.0 +0200
> @@ -1503,6 +1503,10 @@ config NETDEV_NOTIFIER_ERROR_INJECT
>  
> If unsure, say N.
>  
> +config FUNCTION_ERROR_INJECTION
> + def_bool y
> + depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
> +
>  config FAULT_INJECTION
>   bool "Fault-injection framework"
>   depends on DEBUG_KERNEL
> @@ -1510,10 +1514,6 @@ config FAULT_INJECTION
> Provide fault-injection framework.
> For more details, see Documentation/fault-injection/.
>  
> -config FUNCTION_ERROR_INJECTION
> - def_bool y
> - depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
> -
>  config FAILSLAB
>   bool "Fault-injection capability for kmalloc"
>   depends on FAULT_INJECTION
> @@ -1544,16 +1544,6 @@ config FAIL_IO_TIMEOUT
> Only works with drivers that use the generic timeout handling,
> for others it wont do anything.
>  
> -config FAIL_MMC_REQUEST
> - bool "Fault-injection capability for MMC IO"
> - depends on FAULT_INJECTION_DEBUG_FS && MMC
> - help
> -   Provide fault-injection capability for MMC IO.
> -   This will make the mmc core return data errors. This is
> -   useful to test the error handling in the mmc block device
> -   and to test how the mmc host driver handles retries from
> -   the block device.
> -
>  config FAIL_FUTEX
>   bool "Fault-injection capability for futexes"
>   select DEBUG_FS
> @@ -1561,6 +1551,12 @@ config FAIL_FUTEX
>   help
> Provide fault-injection capability for futexes.
>  
> +config FAULT_INJECTION_DEBUG_FS
> + bool "Debugfs entries for fault-injection capabilities"
> + depends on FAULT_INJECTION && SYSFS && DEBUG_FS
> + help
> +   Enable configuration of fault-injection capabilities via debugfs.
> +
>  config FAIL_FUNCTION
>   bool "Fault-injection capability for functions"
>   depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
> @@ -1571,11 +1567,15 @@ config FAIL_FUNCTION
> an error value and have to handle it. This is useful to test the
> error handling in various subsystems.
>  
> -config FAULT_INJECTION_DEBUG_FS
> - bool "Debugfs entries for fault-injection capabilities"
> - depends on FAULT_INJECTION && SYSFS && DEBUG_FS
> +config FAIL_MMC_REQUEST
> + bool "Fault-injection capability for MMC IO"
> + depends on FAULT_INJECTION_DEBUG_FS && MMC
>   help
> -   Enable configuration of fault-injection capabilities via debugfs.
> +   Provide fault-injection capability for MMC IO.
> +   This will make the mmc core return data errors. This is
> +   useful to test the error handling in the mmc block device
> +   and to test how the mmc host driver handles retries from
> +   the block device.
>  
>  config FAULT_INJECTION_STACKTRACE_FILTER
>   bool "stacktrace filter for fault-injection capabilities"
> 


-- 
~Randy

Re: [PATCH v5] fault-injection: introduce kvmalloc fallback options

[Randy Dunlap]

On 04/25/2018 01:57 PM, Mikulas Patocka wrote:
> 
> 
> On Wed, 25 Apr 2018, Randy Dunlap wrote:
> 
>> On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
>>>
>>>
>>> From: Mikulas Patocka <mpato...@redhat.com>
>>> Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options
>>>
>>> This patch introduces a fault-injection option "kvmalloc_fallback". This
>>> option makes kvmalloc randomly fall back to vmalloc.
>>>
>>> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then
>>
>>   Unfortunately,
> 
> OK - here I fixed the typos:
> 
> 
> From: Mikulas Patocka <mpato...@redhat.com>
> Subject: [PATCH] fault-injection: introduce kvmalloc fallback options
> 
> This patch introduces a fault-injection option "kvmalloc_fallback". This
> option makes kvmalloc randomly fall back to vmalloc.
> 
> Unfortunately, some kernel code has bugs - it uses kvmalloc and then
> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code. This options helps to test for these bugs.
> 
> The patch introduces a config option FAIL_KVMALLOC_FALLBACK_PROBABILITY.
> It can be enabled in distribution debug kernels, so that kvmalloc abuse
> can be tested by the users. The default can be overridden with
> "kvmalloc_fallback" parameter or in /sys/kernel/debug/kvmalloc_fallback/.
> 
> Signed-off-by: Mikulas Patocka <mpato...@redhat.com>
> 
> ---
>  Documentation/fault-injection/fault-injection.txt |7 +
>  include/linux/fault-inject.h  |9 +++---
>  kernel/futex.c|2 -
>  lib/Kconfig.debug |   15 +++
>  mm/failslab.c         |2 -
>  mm/page_alloc.c   |2 -
>  mm/util.c |   30 
> ++
>  7 files changed, 60 insertions(+), 7 deletions(-)

Acked-by: Randy Dunlap <rdun...@infradead.org> # Documentation and Kconfig only

thanks.
-- 
~Randy

Re: [PATCH v4] fault-injection: introduce kvmalloc fallback options

[Randy Dunlap]

On 04/25/2018 01:02 PM, Mikulas Patocka wrote:
> 
> 
> From: Mikulas Patocka 
> Subject: [PATCH v4] fault-injection: introduce kvmalloc fallback options
> 
> This patch introduces a fault-injection option "kvmalloc_fallback". This
> option makes kvmalloc randomly fall back to vmalloc.
> 
> Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then

  Unfortunately,

> uses DMA-API on the returned memory or frees it with kfree. Such bugs were
> found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific
> code. This options helps to test for these bugs.
> 
> The patch introduces a config option FAIL_KVMALLOC_FALLBACK_PROBABILITY.
> It can be enabled in distribution debug kernels, so that kvmalloc abuse
> can be tested by the users. The default can be overriden with

 overridden

> "kvmalloc_fallback" parameter or in /sys/kernel/debug/kvmalloc_fallback/.
> 
> Signed-off-by: Mikulas Patocka 
> 
> ---
>  Documentation/fault-injection/fault-injection.txt |7 +
>  include/linux/fault-inject.h  |9 +++---
>  kernel/futex.c|2 -
>  lib/Kconfig.debug |   15 +++
>  mm/failslab.c |2 -
>  mm/page_alloc.c   |2 -
>  mm/util.c |   30 
> ++
>  7 files changed, 60 insertions(+), 7 deletions(-)
> 
> Index: linux-2.6/Documentation/fault-injection/fault-injection.txt
> ===
> --- linux-2.6.orig/Documentation/fault-injection/fault-injection.txt  
> 2018-04-16 21:08:34.0 +0200
> +++ linux-2.6/Documentation/fault-injection/fault-injection.txt   
> 2018-04-25 21:36:36.0 +0200
> @@ -15,6 +15,12 @@ o fail_page_alloc
>  
>injects page allocation failures. (alloc_pages(), get_free_pages(), ...)
>  
> +o kvmalloc_faillback

 kvmalloc_fallback

> +
> +  makes the function kvmalloc randonly fall back to vmalloc. This could be 
> used

 randomly

> +  to detects bugs such as using DMA-API on the result of kvmalloc or freeing
> +  the result of kvmalloc with free.
> +
>  o fail_futex
>  
>injects futex deadlock and uaddr fault errors.
> @@ -167,6 +173,7 @@ use the boot option:
>  
>   failslab=
>   fail_page_alloc=
> + kvmalloc_faillback=

kvmalloc_fallback=

>   fail_make_request=
>   fail_futex=
>   mmc_core.fail_request=,,,

> Index: linux-2.6/lib/Kconfig.debug
> ===
> --- linux-2.6.orig/lib/Kconfig.debug  2018-04-25 15:56:16.0 +0200
> +++ linux-2.6/lib/Kconfig.debug   2018-04-25 21:39:45.0 +0200
> @@ -1527,6 +1527,21 @@ config FAIL_PAGE_ALLOC
>   help
> Provide fault-injection capability for alloc_pages().
>  
> +config FAIL_KVMALLOC_FALLBACK_PROBABILITY
> + int "Default kvmalloc fallback probability"
> + depends on FAULT_INJECTION
> + range 0 100
> + default "0"
> + help
> +   This option will make kvmalloc randomly fall back to vmalloc.
> +   Normally, kvmalloc falls back to vmalloc only rarely, if memory
> +   is fragmented.
> +
> +   This option helps to detect hard-to-reproduce driver bugs, for
> +   example using DMA API on the result of kvmalloc.
> +
> +   The default may be overriden with the kvmalloc_faillback parameter.

 overridden kvmalloc_fallback

> +
>  config FAIL_MAKE_REQUEST
>   bool "Fault-injection capability for disk IO"
>   depends on FAULT_INJECTION && BLOCK

-- 
~Randy

[PATCH] netfilter: fix nf_tables filter chain type build

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix build errors due to a missing Kconfig dependency term.
Fixes these build errors:

net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_nat_do_chain':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:37: undefined reference to 
`nft_do_chain'
net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_exit':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:94: undefined reference to 
`nft_unregister_chain_type'
net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_init':
net/ipv6/netfilter/nft_chain_nat_ipv6.c:87: undefined reference to 
`nft_register_chain_type'

Fixes: 02c7b25e5f54 ("netfilter: nf_tables: build-in filter chain type")

Reported-by: kbuild test robot <l...@intel.com>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Pablo Neira Ayuso <pa...@netfilter.org>
Cc: Jozsef Kadlecsik <kad...@blackhole.kfki.hu>
Cc: Florian Westphal <f...@strlen.de>
Cc: netfilter-de...@vger.kernel.org
Cc: coret...@netfilter.org
---
 net/ipv6/netfilter/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180419.orig/net/ipv6/netfilter/Kconfig
+++ linux-next-20180419/net/ipv6/netfilter/Kconfig
@@ -108,7 +108,7 @@ config NF_NAT_IPV6
 if NF_NAT_IPV6
 
 config NFT_CHAIN_NAT_IPV6
-   depends on NF_TABLES_IPV6
+   depends on NF_TABLES_IPV6 && NF_TABLES
tristate "IPv6 nf_tables nat chain support"
help
  This option enables the "nat" chain for IPv6 in nf_tables. This

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

[Randy Dunlap]

On 04/20/18 13:01, Alexander Duyck wrote:
> On Fri, Apr 20, 2018 at 10:23 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>> On 04/20/18 09:28, Alexander Duyck wrote:
>>> This series is meant to add support for SR-IOV on devices when the VFs are
>>> not managed by the kernel. Examples of recent patches attempting to do this
>>> include:
>>> virto - https://patchwork.kernel.org/patch/10241225/
>>> pci-stub - https://patchwork.kernel.org/patch/10109935/
>>> vfio - https://patchwork.kernel.org/patch/10103353/
>>> uio - https://patchwork.kernel.org/patch/9974031/
>>
>> Hi,
>>
>> Somewhere in this patch series it would be nice to tell us what the heck
>> a "PF" is.  :)
>>
>> Thanks.
> 
> Sorry, I was kind of operating on the assumption of everyone
> understanding SR-IOV nomenclature.

Yes, I understood that. :)

> A "PF" is a PCIe Physical Function. When you bring up a PCIe device
> that supports SR-IOV it is the device that is there to begin with.
> 
> A "VF" is a PCIe Virtual Function. You could think of as a logical
> device that is spawned from the physical function using a combination
> of hardware configuration via the SR-IOV block in the PCIe extended
> configuration space and kernel/driver features.
> 
> There are also a number of online resources you could use to research
> SR-IOV further. Hope that helps to clarify some of this.
> 
> Thanks.

Thank you.


-- 
~Randy

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

[Randy Dunlap]

On 04/20/18 09:28, Alexander Duyck wrote:
> This series is meant to add support for SR-IOV on devices when the VFs are
> not managed by the kernel. Examples of recent patches attempting to do this
> include:
> virto - https://patchwork.kernel.org/patch/10241225/
> pci-stub - https://patchwork.kernel.org/patch/10109935/
> vfio - https://patchwork.kernel.org/patch/10103353/
> uio - https://patchwork.kernel.org/patch/9974031/

Hi,

Somewhere in this patch series it would be nice to tell us what the heck
a "PF" is.  :)

Thanks.

> Since this is quickly blowing up into a multi-driver problem it is probably
> best to implement this solution as generically as possible.
> 
> This series is an attempt to do that. What we do with this patch set is
> provide a generic framework to enable SR-IOV in the case that the PF driver
> doesn't support managing the VFs itself.
> 
> I based my patch set originally on the patch by Mark Rustad but there isn't
> much left after going through and cleaning out the bits that were no longer
> needed, and after incorporating the feedback from David Miller. At this point
> the only items to be fully reused was his patch description which is now
> present in patch 3 of the set.
> 
> This solution is limited in scope to just adding support for devices that
> provide no functionality for SR-IOV other than allocating the VFs by
> calling pci_enable_sriov. Previous sets had included patches for VFIO, but
> for now I am dropping that as the scope of that work is larger then I
> think I can take on at this time.
> 
> v2: Reduced scope back to just virtio_pci and vfio-pci
> Broke into 3 patch set from single patch
> Changed autoprobe behavior to always set when num_vfs is set non-zero
> v3: Updated Documentation to clarify when sriov_unmanaged_autoprobe is used
> Wrapped vfio_pci_sriov_configure to fix build errors w/o SR-IOV in kernel
> v4: Dropped vfio-pci patch
> Added ena and nvme to drivers now using pci_sriov_configure_unmanaged
> Dropped pci_disable_sriov call in virtio_pci to be consistent with ena
> v5: Dropped sriov_unmanaged_autoprobe and pci_sriov_conifgure_unmanaged
> Added new patch that enables pci_sriov_configure_simple
> Updated drivers to use pci_sriov_configure_simple
> v6: Defined pci_sriov_configure_simple as NULL when SR-IOV is not enabled
> Updated drivers to drop "#ifdef" checks for IOV
> Added pci-pf-stub as place for PF-only drivers to add support
> v7: Dropped pci_id table explanation from pci-pf-stub driver
> Updated pci_sriov_configure_simple to drop need for err value
> Fixed comment explaining why pci_sriov_configure_simple is NULL
> v8: Dropped virtio from the set, support to be added later after TC approval
> 
> Cc: Mark Rustad 
> Cc: Maximilian Heyne 
> Cc: Liang-Min Wang 
> Cc: David Woodhouse 
> 
> ---
> 
> Alexander Duyck (4):
>   pci: Add pci_sriov_configure_simple for PFs that don't manage VF 
> resources
>   ena: Migrate over to unmanaged SR-IOV support
>   nvme: Migrate over to unmanaged SR-IOV support
>   pci-pf-stub: Add PF driver stub for PFs that function only to enable VFs
> 
> 
>  drivers/net/ethernet/amazon/ena/ena_netdev.c |   28 -
>  drivers/nvme/host/pci.c  |   20 --
>  drivers/pci/Kconfig  |   12 ++
>  drivers/pci/Makefile |2 +
>  drivers/pci/iov.c|   31 +++
>  drivers/pci/pci-pf-stub.c|   54 
> ++
>  include/linux/pci.h  |3 +
>  include/linux/pci_ids.h  |2 +
>  8 files changed, 106 insertions(+), 46 deletions(-)
>  create mode 100644 drivers/pci/pci-pf-stub.c
> 
> --
> 

-- 
~Randy

[PATCH] textsearch: fix kernel-doc warnings and add kernel-api section

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Make lib/textsearch.c usable as kernel-doc.
Add textsearch() function family to kernel-api documentation.
Fix kernel-doc warnings in :
  ../include/linux/textsearch.h:65: warning: Incorrect use of kernel-doc format:
* get_next_block - fetch next block of data
  ../include/linux/textsearch.h:82: warning: Incorrect use of kernel-doc format:
* finish - finalize/clean a series of get_next_block() calls

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 Documentation/core-api/kernel-api.rst |   13 +++
 include/linux/textsearch.h|4 +-
 lib/textsearch.c  |   40 +---
 3 files changed, 38 insertions(+), 19 deletions(-)

--- linux-next-20180416.orig/Documentation/core-api/kernel-api.rst
+++ linux-next-20180416/Documentation/core-api/kernel-api.rst
@@ -136,6 +136,19 @@ Sorting
 .. kernel-doc:: lib/list_sort.c
:export:
 
+Text Searching
+--
+
+.. kernel-doc:: lib/textsearch.c
+   :doc: ts_intro
+
+.. kernel-doc:: lib/textsearch.c
+   :export:
+
+.. kernel-doc:: include/linux/textsearch.h
+   :functions: textsearch_find textsearch_next \
+   textsearch_get_pattern textsearch_get_pattern_len
+
 UUID/GUID
 -
 
--- linux-next-20180416.orig/lib/textsearch.c
+++ linux-next-20180416/lib/textsearch.c
@@ -10,7 +10,10 @@
  * Pablo Neira Ayuso <pa...@netfilter.org>
  *
  * ==
- *
+ */
+
+/**
+ * DOC: ts_intro
  * INTRODUCTION
  *
  *   The textsearch infrastructure provides text searching facilities for
@@ -19,7 +22,9 @@
  *
  * ARCHITECTURE
  *
- *  User
+ * .. code-block:: none
+ *
+ * User
  * ++
  * |finish()|<--(6)-+
  * |get_next_block()|<--(5)---+ |
@@ -33,21 +38,21 @@
  * | (3)|->| find()/next() |---+  |
  * | (7)|->| destroy() |--+
  * ++  +---+
- *  
- *   (1) User configures a search by calling _prepare() specifying the
- *   search parameters such as the pattern and algorithm name.
+ *
+ *   (1) User configures a search by calling textsearch_prepare() specifying
+ *   the search parameters such as the pattern and algorithm name.
  *   (2) Core requests the algorithm to allocate and initialize a search
  *   configuration according to the specified parameters.
- *   (3) User starts the search(es) by calling _find() or _next() to
- *   fetch subsequent occurrences. A state variable is provided
- *   to the algorithm to store persistent variables.
+ *   (3) User starts the search(es) by calling textsearch_find() or
+ *   textsearch_next() to fetch subsequent occurrences. A state variable
+ *   is provided to the algorithm to store persistent variables.
  *   (4) Core eventually resets the search offset and forwards the find()
  *   request to the algorithm.
  *   (5) Algorithm calls get_next_block() provided by the user continuously
  *   to fetch the data to be searched in block by block.
  *   (6) Algorithm invokes finish() after the last call to get_next_block
  *   to clean up any leftovers from get_next_block. (Optional)
- *   (7) User destroys the configuration by calling _destroy().
+ *   (7) User destroys the configuration by calling textsearch_destroy().
  *   (8) Core notifies the algorithm to destroy algorithm specific
  *   allocations. (Optional)
  *
@@ -62,9 +67,10 @@
  *   amount of times and even in parallel as long as a separate struct
  *   ts_state variable is provided to every instance.
  *
- *   The actual search is performed by either calling textsearch_find_-
- *   continuous() for linear data or by providing an own get_next_block()
- *   implementation and calling textsearch_find(). Both functions return
+ *   The actual search is performed by either calling
+ *   textsearch_find_continuous() for linear data or by providing
+ *   an own get_next_block() implementation and
+ *   calling textsearch_find(). Both functions return
  *   the position of the first occurrence of the pattern or UINT_MAX if
  *   no match was found. Subsequent occurrences can be found by calling
  *   textsearch_next() regardless of the linearity of the data.
@@ -72,7 +78,7 @@
  *   Once you're done using a configuration it must be given back via
  *   textsearch_destroy.
  *
- * EXAMPLE
+ * EXAMPLE::
  *
  *   int pos;
  *   struct ts_config *conf;
@@ -87,13 +93,13 @@
  *   goto errout;
  *   }
  *
- *   pos = textsearch_find_continuous(conf, , example, strlen(example));
+ *   pos = textsearch_find_continuous(conf, \, example, strlen(example));
  *   if (pos != UINT_MAX)
- *   panic("Oh my god, dancing chickens at %d\n", pos);
+ *   panic("Oh my god, dancing chickens 

Re: [PATCH net-next V2] Documentation/networking: Add net DIM documentation

[Randy Dunlap]

rder to avoid getting stuck in a "deep sleep" scenario. Once a
> +decision is made, an interrupt moderation configuration is selected from
> +the predefined profiles.

I think a short description of the predefined profiles could help.

> +
> +The last step is to notify the registered driver that it should apply the
> +suggested configuration. This is done by scheduling a work function, defined 
> by
> +the Net DIM API and provided by the registered driver.
> +
> +As you can see, Net DIM itself does not actively interact with the system. It
> +would have trouble making the correct decisions if the wrong data is 
> supplied to
> +it and it would be useless if the work function would not apply the suggested
> +configuration. This does, however, allow the registered driver some room for
> +manoeuvre as it may provide partial data or ignore the algorithm suggestion
> +under some conditions.
> +
> +
> +Part III: Registering a Network Device to DIM
> +==
> +
> +Net DIM API exposes the main function net_dim(struct net_dim *dim,
> +struct net_dim_sample end_sample). This function is the entry point to the 
> Net
> +DIM algorithm and has to be called every time the driver would like to check 
> if
> +it should change interrupt moderation parameters. The driver should provide 
> two

Is it completely up to the driver to decide when to call net_dim()?
So it could be based on TX traffic, RX traffic, time, queue depths, etc.?

> +data structures: struct net_dim and struct net_dim_sample. Struct net_dim
> +describes the state of DIM for a specific object (RX queue, TX queue,
> +other queues, etc.). This includes the current selected profile, previous 
> data
> +samples, the callback function provided by the driver and more.
> +Struct net_dim_sample describes a data sample, which will be compared to the
> +data sample stored in struct net_dim in order to decide on the algorithm's 
> next
> +step. The sample should include bytes, packets and interrupts, measured by
> +the driver.
> +
> +In order to use Net DIM from a networking driver, the driver needs to call 
> the
> +main net_dim() function. The recommended method is to call net_dim() on each
> +interrupt. Since Net DIM has a built-in moderation and it might decide to 
> skip

(continuing my question from above:)
or on each interrupt.  But the hardware could also be doing interrupt 
mitigation,
so each interrupt doesn't always correlate to anything specific.

> +iterations under certain conditions, there is no need to moderate the 
> net_dim()
> +calls as well. As mentioned above, the driver needs to provide an object of 
> type
> +struct net_dim to the net_dim() function call. It is advised for each entity
> +using Net DIM to hold a struct net_dim as part of its data structure and use 
> it
> +as the main Net DIM API object. The struct net_dim_sample should hold the 
> latest
> +bytes, packets and interrupts count. No need to perform any calculations, 
> just
> +include the raw data.
> +
> +The net_dim() call itself does not return anything. Instead Net DIM relies on
> +the driver to provide a callback function, which is called when the algorithm
> +decides to make a change in the interrupt moderation parameters. This 
> callback
> +will be scheduled and run in a separate thread in order not to add overhead 
> to
> +the data flow. After the work is done, Net DIM algorithm needs to be set to
> +the proper state in order to move to the next iteration.
> +
> +
> +Part IV: Example
> +=
> +
> +The following code demonstrates how to register a driver to Net DIM. The 
> actual
> +usage is not complete but it should make the outline of the usage clear.
> +
> +my_driver.c:
> +
> +#include 
> +
> +/* Callback for net DIM to schedule on a decision to change moderation */
> +void my_driver_do_dim_work(struct work_struct *work)
> +{
> + /* Get struct net_dim from struct work_struct */
> + struct net_dim *dim = container_of(work, struct net_dim,
> +work);
> + /* Do interrupt moderation related stuff */
> + ...
> +
> + /* Signal net DIM work is done and it should move to next iteration */
> + dim->state = NET_DIM_START_MEASURE;
> +}
> +
> +/* My driver's interrupt handler */
> +int my_driver_handle_interrupt(struct my_driver_entity *my_entity, ...)
> +{
> + ...
> + /* A struct to hold current measured data */
> + struct net_dim_sample dim_sample;
> + ...
> + /* Initiate data sample struct with current data */
> + net_dim_sample(my_entity->events,
> +my_entity->packets,
> +my_entity->bytes,
> +_sample);
> + /* Call net DIM */
> + net_dim(_entity->dim, dim_sample);
> + ...
> +}
> +
> +/* My entity's initialization function (my_entity was already allocated) */
> +int my_driver_init_my_entity(struct my_driver_entity *my_entity, ...)
> +{
> + ...
> + /* Initiate struct work_struct with my driver's callback function */
> + INIT_WORK(_entity->dim.work, my_driver_do_dim_work);
> + ...
> +}
> 

Reviewed-by: Randy Dunlap <rdun...@infradead.org>

thanks,
-- 
~Randy

Re: [PATCH net-next] Documentation/networking: Add net DIM documentation

[Randy Dunlap]

On 03/21/2018 11:20 AM, Marcelo Ricardo Leitner wrote:
> On Wed, Mar 21, 2018 at 11:30:29AM +0200, Tal Gilboa wrote:
> ...
>> +Dynamic Interrupt Moderation (DIM) (in networking) refers to changing the 
>> interrupt
>> +moderation configuration of a channel in order to optimize packet 
>> processing.
>> +The mechanism includes an algorithm which decides if and how to change
>> +moderation parameters for a channel, usually by performing an analysis on
>> +runtime data sampled from the system. Net DIM is such a mechanism. In each
>> +iteration of the algorithm, it analyses a given sample of the data, 
>> compares it to
>> +the previous sample and if required, is can decide to change some of the 
>> interrupt moderation
> 
> Some lines are above 80 chars. Please format the text so they don't exceed it.

Agreed.

thanks,
-- 
~Randy

Re: [PATCH net-next] Documentation/networking: Add net DIM documentation

[Randy Dunlap]

On 03/21/2018 02:30 AM, Tal Gilboa wrote:
> Net DIM is a generic algorithm, purposed for dynamically
> optimizing network devices interrupt moderation. This
> document describes how it works and how to use it.
> 
> Signed-off-by: Tal Gilboa 
> ---
>  Documentation/networking/net_dim.txt | 174 
> +++
>  1 file changed, 174 insertions(+)
>  create mode 100644 Documentation/networking/net_dim.txt
> 
> diff --git a/Documentation/networking/net_dim.txt 
> b/Documentation/networking/net_dim.txt
> new file mode 100644
> index 000..ef622c8
> --- /dev/null
> +++ b/Documentation/networking/net_dim.txt
> @@ -0,0 +1,174 @@
> +Net DIM - Generic Network Dynamic Interrupt Moderation
> +==
> +
> +Author:
> + Tal Gilboa 
> +
> +
> +Contents
> +=
> +
> +- Assumptions
> +- Introduction
> +- The Net DIM Algorithm
> +- Registering a Network Device to DIM
> +- Example
> +
> +Part 0: Assumptions
> +==
> +
> +This document assumes the reader has basic knowledge in network drivers
> +and in general interrupt moderation.
> +
> +
> +Part I: Introduction
> +==
> +
> +Dynamic Interrupt Moderation (DIM) (in networking) refers to changing the 
> interrupt
> +moderation configuration of a channel in order to optimize packet processing.
> +The mechanism includes an algorithm which decides if and how to change
> +moderation parameters for a channel, usually by performing an analysis on
> +runtime data sampled from the system. Net DIM is such a mechanism. In each
> +iteration of the algorithm, it analyses a given sample of the data, compares 
> it to
> +the previous sample and if required, is can decide to change some of the 
> interrupt moderation

it can

> +configuration fields. The data sample is composed of data bandwidth, the 
> number of
> +packets and the number of events. The time between samples is also measured. 
> Net DIM
> +compares the current and the previous data and returns an adjusted interrupt
> +moderation configuration object. In some cases, the algorithm might decide 
> not
> +to change anything. The configuration fields are the minimum duration
> +(microseconds) allowed between events and the maximum number of wanted 
> packets
> +per event. The Net DIM algorithm ascribes importance to increase bandwidth 
> over
> +reducing interrupt rate.
> +
> +
> +Part II: The Net DIM Algorithm
> +===
> +
> +Each iteration of the Net DIM algorithm follows these steps:
> +1. Calculates new data sample.
> +2. Compares it to previous sample.
> +3. Makes a decision - suggests interrupt moderation configuration fields.
> +4. Applies a schedule work function, which applies suggested configuration.
> +
> +The first two steps are straight forward, both the new and the previous data 
> are

   straightforward;

> +supplied by the driver registered to Net DIM. The previous data is the new 
> data
> +supplied to the previous iteration. The comparison step checks the difference
> +between the new and previous data and decides on the result of the last 
> step. A step
> +would result as "better" if bandwidth increases and as "worse" if bandwidth
> +reduces. If there is no change in bandwidth, the packet rate is compared in 
> a similar
> +fashion - increase == "better" and decrease == "worse". In case there is no
> +change in the packet rate as well, the interrupt rate is compared. Here the
> +algorithm tries to optimize for lower interrupt rate so an increase in the
> +interrupt rate is considered "worse" and a decrease is considered "better".
> +Step #2 has an optimization for avoiding false results, it only considers a

  results:

> +difference between samples as valid if it is greater than a certain 
> percentage.
> +Also, since Net DIM does not measure anything by itself, it assumes the data
> +provided by the driver is valid.
> +
> +Step #3 decides on the suggested configuration based on the result from step 
> #2
> +and the internal state of the algorithm. The states reflect the "direction" 
> of
> +the algorithm, is it going left (reducing moderation), right (increasing

   algorithm:

> +moderation) or standing still. Another optimization is that if a decision
> +to stay still is made multiple times, the interval between iterations of the
> +algorithm would increase in order to reduce calculation overhead. Also, after
> +"parking" on one of the most left or most right decisions, the algorithm may
> +decide to verify this decision by taking a step on the other direction. This 
> is

  step in

> +done in order to avoid getting stuck in a "deep sleep" scenario. Once a
> +decision is made, an interrupt moderation configuration is selected from
> +the predefined profiles.
> +

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

[Randy Dunlap]

On 03/09/2018 04:07 PM, Andrew Morton wrote:
> On Fri, 9 Mar 2018 12:05:36 -0800 Kees Cook  wrote:
> 
>> When max() is used in stack array size calculations from literal values
>> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler
>> thinks this is a dynamic calculation due to the single-eval logic, which
>> is not needed in the literal case. This change removes several accidental
>> stack VLAs from an x86 allmodconfig build:
>>
>> $ diff -u before.txt after.txt | grep ^-
>> -drivers/input/touchscreen/cyttsp4_core.c:871:2: warning: ISO C90 forbids 
>> variable length array ‘ids’ [-Wvla]
>> -fs/btrfs/tree-checker.c:344:4: warning: ISO C90 forbids variable length 
>> array ‘namebuf’ [-Wvla]
>> -lib/vsprintf.c:747:2: warning: ISO C90 forbids variable length array ‘sym’ 
>> [-Wvla]
>> -net/ipv4/proc.c:403:2: warning: ISO C90 forbids variable length array 
>> ‘buff’ [-Wvla]
>> -net/ipv6/proc.c:198:2: warning: ISO C90 forbids variable length array 
>> ‘buff’ [-Wvla]
>> -net/ipv6/proc.c:218:2: warning: ISO C90 forbids variable length array 
>> ‘buff64’ [-Wvla]
>>
>> Based on an earlier patch from Josh Poimboeuf.
> 
> v1, v2 and v3 of this patch all fail with gcc-4.4.4:
> 
> ./include/linux/jiffies.h: In function 'jiffies_delta_to_clock_t':
> ./include/linux/jiffies.h:444: error: first argument to 
> '__builtin_choose_expr' not a constant


I'm seeing that problem with
> gcc --version
gcc (SUSE Linux) 4.8.5

in mmotm.

> That's with
> 
> #define __max(t1, t2, x, y)   \
>   __builtin_choose_expr(__builtin_constant_p(x) &&\
> __builtin_constant_p(y) &&\
> __builtin_types_compatible_p(t1, t2), \
> (t1)(x) > (t2)(y) ? (t1)(x) : (t2)(y),\
> __single_eval_max(t1, t2, \
>   __UNIQUE_ID(max1_), \
>   __UNIQUE_ID(max2_), \
>   x, y))
> /**
>  * max - return maximum of two values of the same or compatible types
>  * @x: first value
>  * @y: second value
>  */
> #define max(x, y) __max(typeof(x), typeof(y), x, y)
> 
> 
> A brief poke failed to reveal a workaround - gcc-4.4.4 doesn't appear
> to know that __builtin_constant_p(x) is a constant.  Or something.
> 
> Sigh.  Wasn't there some talk about modernizing our toolchain
> requirements?


-- 
~Randy

Re: [pull request][for-next 00/11] Mellanox, mlx5 IPSec updates 2018-02-28-2 (Part 2)

[Randy Dunlap]

On 03/08/2018 11:14 AM, Doug Ledford wrote:
> On 3/8/2018 1:04 PM, David Miller wrote:
>> From: Saeed Mahameed 
>> Date: Wed,  7 Mar 2018 17:26:03 -0800
>>
>>> Hi Dave and Doug,
>>>
>>> This series includes shared code updates (IPSec part2) for mlx5 core 
>>> driver for both netdev and rdma subsystems.  This series should be pulled
>>> to both trees so we can continue netdev and rdma specific submissions
>>> separately.
>>
>> Doug, please give this series a quick review.
>>
>> Thank you.
>>
> 
> I'm good with it.  Pull it as you see fit.
> 

I got this build error in today's linux-next (20180308):

../drivers/net/ethernet/mellanox/mlx5/core/fs_core.c: In function 
'mlx5_init_fs':
../drivers/net/ethernet/mellanox/mlx5/core/fs_core.c:2652:2: error: implicit 
declaration of function 'mlx5_accel_ipsec_device_caps' 
[-Werror=implicit-function-declaration]
  if (mlx5_accel_ipsec_device_caps(steering->dev) &
  ^
../drivers/net/ethernet/mellanox/mlx5/core/fs_core.c:2653:6: error: 
'MLX5_ACCEL_IPSEC_DEVICE' undeclared (first use in this function)
  MLX5_ACCEL_IPSEC_DEVICE) {
  ^
../drivers/net/ethernet


Is this perhaps fixed already?
Do you need the randconfig file?

thanks,
-- 
~Randy

Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

[Randy Dunlap]

Hi,

On 03/05/2018 05:34 PM, Alexei Starovoitov wrote:

> diff --git a/kernel/module.c b/kernel/module.c
> index ad2d420024f6..6cfa35795741 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c

> @@ -3669,6 +3683,17 @@ static int load_module(struct load_info *info, const 
> char __user *uargs,
>   if (err)
>   goto free_copy;
>  
> + if (info->hdr->e_type == ET_EXEC) {
> +#ifdef CONFIG_MODULE_SIG
> + if (!info->sig_ok) {
> + pr_notice_once("umh %s verification failed: signature 
> and/or required key missing - tainting kernel\n",

That's not a very friendly message to tell a user.  "umh" eh?

> +info->file->f_path.dentry->d_name.name);
> + add_taint(TAINT_UNSIGNED_MODULE, LOCKDEP_STILL_OK);
> + }

And since the signature failed, why is it being loaded at all?
Is this in the "--force" load path?

> +#endif
> + return 0;
> + }
> +
>   /* Figure out module layout, and allocate all the memory. */
>   mod = layout_and_allocate(info, flags);
>   if (IS_ERR(mod)) {

thanks,
-- 
~Randy

[PATCH] net/wireless: fix spaces and grammar copy/paste in vendor Kconfig help text

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Lots of the wireless driver vendor Kconfig symol help text says
"questions about  cards." (2 spaces between "about" and "cards")

Besides dropping one of those spaces, it also needs some other word
inserted there. Instead of putting each vendor's name there, I chose
to say "these" cards in all of the Kconfig help text.

Cc: Kalle Valo <kv...@codeaurora.org>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 drivers/net/wireless/admtek/Kconfig|4 ++--
 drivers/net/wireless/ath/Kconfig   |4 ++--
 drivers/net/wireless/atmel/Kconfig |4 ++--
 drivers/net/wireless/broadcom/Kconfig  |4 ++--
 drivers/net/wireless/cisco/Kconfig |4 ++--
 drivers/net/wireless/intel/Kconfig |4 ++--
 drivers/net/wireless/intersil/Kconfig  |4 ++--
 drivers/net/wireless/marvell/Kconfig   |4 ++--
 drivers/net/wireless/mediatek/Kconfig  |4 ++--
 drivers/net/wireless/quantenna/Kconfig |4 ++--
 drivers/net/wireless/ralink/Kconfig|4 ++--
 drivers/net/wireless/realtek/Kconfig   |4 ++--
 drivers/net/wireless/rsi/Kconfig   |4 ++--
 drivers/net/wireless/st/Kconfig|4 ++--
 drivers/net/wireless/ti/Kconfig|4 ++--
 drivers/net/wireless/zydas/Kconfig |4 ++--
 16 files changed, 32 insertions(+), 32 deletions(-)

--- linux-next-20180302.orig/drivers/net/wireless/admtek/Kconfig
+++ linux-next-20180302/drivers/net/wireless/admtek/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_ADMTEK
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_ADMTEK
--- linux-next-20180302.orig/drivers/net/wireless/ath/Kconfig
+++ linux-next-20180302/drivers/net/wireless/ath/Kconfig
@@ -8,8 +8,8 @@ config WLAN_VENDOR_ATH
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
  For more information and documentation on this module you can visit:
--- linux-next-20180302.orig/drivers/net/wireless/atmel/Kconfig
+++ linux-next-20180302/drivers/net/wireless/atmel/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_ATMEL
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_ATMEL
--- linux-next-20180302.orig/drivers/net/wireless/broadcom/Kconfig
+++ linux-next-20180302/drivers/net/wireless/broadcom/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_BROADCOM
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_BROADCOM
--- linux-next-20180302.orig/drivers/net/wireless/cisco/Kconfig
+++ linux-next-20180302/drivers/net/wireless/cisco/Kconfig
@@ -5,8 +5,8 @@ config WLAN_VENDOR_CISCO
  If you have a wireless card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
- kernel: saying N will just cause the configurator to skip all
- the questions about  cards. If you say Y, you will be asked for
+ kernel: saying N will just cause the configurator to skip all the
+ questions about these cards. If you say Y, you will be asked for
  your specific card in the following questions.
 
 if WLAN_VENDOR_CISCO
--- linux-next-20180302.orig/drivers/net/wireless/intel/Kconfig
+++ linux-nex

[PATCH] ethernet: natsemi: correct spelling

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Correct spelling of National Semi-conductor (no hyphen)
in drivers/net/ethernet/.

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 drivers/net/ethernet/8390/Kconfig |2 +-
 drivers/net/ethernet/natsemi/Kconfig  |6 +++---
 drivers/net/ethernet/natsemi/Makefile |2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

--- linux-next-20180302.orig/drivers/net/ethernet/8390/Kconfig
+++ linux-next-20180302/drivers/net/ethernet/8390/Kconfig
@@ -3,7 +3,7 @@
 #
 
 config NET_VENDOR_8390
-   bool "National Semi-conductor 8390 devices"
+   bool "National Semiconductor 8390 devices"
default y
depends on NET_VENDOR_NATSEMI
---help---
--- linux-next-20180302.orig/drivers/net/ethernet/natsemi/Kconfig
+++ linux-next-20180302/drivers/net/ethernet/natsemi/Kconfig
@@ -1,16 +1,16 @@
 #
-# National Semi-conductor device configuration
+# National Semiconductor device configuration
 #
 
 config NET_VENDOR_NATSEMI
-   bool "National Semi-conductor devices"
+   bool "National Semiconductor devices"
default y
---help---
  If you have a network (Ethernet) card belonging to this class, say Y.
 
  Note that the answer to this question doesn't directly affect the
  kernel: saying N will just cause the configurator to skip all
- the questions about National Semi-conductor devices. If you say Y,
+ the questions about National Semiconductor devices. If you say Y,
  you will be asked for your specific card in the following questions.
 
 if NET_VENDOR_NATSEMI
--- linux-next-20180302.orig/drivers/net/ethernet/natsemi/Makefile
+++ linux-next-20180302/drivers/net/ethernet/natsemi/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 #
-# Makefile for the National Semi-conductor Sonic devices.
+# Makefile for the National Semiconductor Sonic devices.
 #
 
 obj-$(CONFIG_MACSONIC) += macsonic.o

Re: Kernel panic with 4.16-rc1 (and 4.16-rc2) running selftest

[Randy Dunlap]

[add Matthew Wilcox; hopefully he can look/see]

On 02/23/2018 04:13 PM, Cong Wang wrote:
> On Fri, Feb 23, 2018 at 3:27 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote:
>> On Fri, Feb 23, 2018 at 11:00 AM, Randy Dunlap <rdun...@infradead.org> wrote:
>>> [adding netdev]
>>>
>>> On 02/23/2018 08:05 AM, Khalid Aziz wrote:
>>>> I am seeing a kernel panic with 4.16-rc1 and 4.16-rc2 kernels when running 
>>>> selftests
>>>> from tools/testing/selftests. Last messages from selftest before kernel 
>>>> panic are:
>>>>
>> ...
>>>> Same selftest does not cause panic on 4.15. git bisect pointed to commit 
>>>> 6ce711f2750031d12cec91384ac5cfa0a485b60a ("idr: Make 1-based IDRs more 
>>>> efficient").
>>>> Kernel config is attached.
>>
>> Looks like something horribly wrong with u32 key id idr...
> 
> Adding a few printk's, I got:
> 
> [   31.231560] requested handle = ffe0
> [   31.232426] allocated handle = 0
> ...
> [   31.246475] requested handle = ffd0
> [   31.247555] allocated handle = 1
> 
> 
> So the bug is here where we can't allocate a specific handle:
> 
> err = idr_alloc_u32(_c->handle_idr, ht, ,
> handle, GFP_KERNEL);
> if (err) {
> kfree(ht);
> return err;
> }
> 


-- 
~Randy

Re: Kernel panic with 4.16-rc1 (and 4.16-rc2) running selftest

[Randy Dunlap]

[adding netdev]

On 02/23/2018 08:05 AM, Khalid Aziz wrote:
> I am seeing a kernel panic with 4.16-rc1 and 4.16-rc2 kernels when running 
> selftests
> from tools/testing/selftests. Last messages from selftest before kernel panic 
> are:
> 
> 
> running psock_tpacket test
> 
> test: TPACKET_V1 with PACKET_RX_RING test: skip TPACKET_V1 PACKET_RX_RING 
> since user and kernel space have different bit width
> test: TPACKET_V1 with PACKET_TX_RING test: skip TPACKET_V1 PACKET_TX_RING 
> since user and kernel space have different bit width
> test: TPACKET_V2 with PACKET_RX_RING  100 pkts (14200 
> bytes)
> test: TPACKET_V2 with PACKET_TX_RING  100 pkts (14200 
> bytes)
> test: TPACKET_V3 with PACKET_RX_RING  100 pkts (14200 
> bytes)
> test: TPACKET_V3 with PACKET_TX_RING  100 pkts (14200 
> bytes)
> OK. All tests passed
> [PASS]
> ok 1..7 selftests: run_afpackettests [PASS]
> selftests: test_bpf.sh
> 
> test_bpf: [FAIL]
> not ok 1..8 selftests:  test_bpf.sh [FAIL]
> selftests: netdevice.sh
> 
> ok 1..9 selftests: netdevice.sh [PASS]
> selftests: rtnetlink.sh
> 
> PASS: policy routing
> PASS: route get
> 
> 
> Kernel panic message is below:
> 
> [  572.486722] BUG: unable to handle kernel paging request at 0600
> [  572.494498] IP: tcf_exts_dump_stats+0x10/0x30
> [  572.499360] PGD 80be413cb067 P4D 80be413cb067 PUD bead15c067 PMD 0 
> [  572.507126] Oops:  [#1] SMP PTI
> [  572.511010] Modules linked in: cls_u32 sch_htb dummy vfat fat ext4 mbcache 
> jb
> d2 intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul 
> crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper 
> cryptd sg iTCO_wdt iTCO_vendor_support ioatdma ipmi_ssif pcspkr wmi i2c_i801 
> lpc_ich shpchp mfd_core ipmi_si ipmi_devintf ipmi_msghandler nfsd auth_rpcgss 
> nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 
> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm igb ahci 
> crc32c_intel nvme libahci dca drm megaraid_sas nvme_core i2c_algo_bit libata 
> bnxt_en i2c_core dm_mirror dm_region_hash dm_log dm_mod
> [  572.574377] CPU: 81 PID: 17886 Comm: tc Not tainted 4.16.0-rc2 #112
> [  572.581371] Hardware name: Oracle Corporation ORACLE SERVER X7-2/ASM, MB, 
> X7-2, BIOS 41017600 10/06/2017
> [  572.591957] RIP: 0010:tcf_exts_dump_stats+0x10/0x30
> [  572.597402] RSP: 0018:c900313b7928 EFLAGS: 00010206
> [  572.603226] RAX: 0600 RBX: 88bea9117db0 RCX: 
> 1ca4
> [  572.611191] RDX: 1ca3 RSI: 88bea90cf018 RDI: 
> 88be4fb6c000
> [  572.619157] RBP: 88be4fb6c000 R08: 00024800 R09: 
> a05697fb
> [  572.627121] R10: 88bebe064800 R11: ea02faa445c0 R12: 
> 88bea90ce034
> [  572.635087] R13: 88bea90cf000 R14: 88be9fe33300 R15: 
> 88bea90ce000
> [  572.643053] FS:  7f98ae464740() GS:88bebe04() 
> knlGS:
> [  572.652084] CS:  0010 DS:  ES:  CR0: 80050033
> [  572.658497] CR2: 0600 CR3: 00be41a94005 CR4: 
> 007606e0
> [  572.666462] DR0:  DR1:  DR2: 
> 
> [  572.674428] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  572.682393] PKRU: 5554
> [  572.685413] Call Trace:
> [  572.688145]  u32_dump+0x2be/0x3c0 [cls_u32]
> [  572.692816]  tcf_fill_node.isra.29+0x15b/0x1f0
> [  572.69]  tfilter_notify+0xc1/0x150
> [  572.701952]  tc_ctl_tfilter+0x87d/0xbd0
> [  572.706238]  rtnetlink_rcv_msg+0x29c/0x310
> [  572.710813]  ? _cond_resched+0x15/0x30
> [  572.714999]  ? __kmalloc_node_track_caller+0x1b9/0x270
> [  572.720737]  ? rtnl_calcit.isra.28+0x100/0x100
> [  572.725697]  netlink_rcv_skb+0xd2/0x110
> [  572.729969]  netlink_unicast+0x17c/0x230
> [  572.734348]  netlink_sendmsg+0x2cd/0x3c0
> [  572.738719]  sock_sendmsg+0x30/0x40
> [  572.742612]  ___sys_sendmsg+0x27a/0x290
> [  572.746896]  ? do_wp_page+0x89/0x4c0
> [  572.750886]  ? page_add_new_anon_rmap+0x72/0xc0
> [  572.755944]  ? __handle_mm_fault+0x74b/0x1280
> [  572.760807]  __sys_sendmsg+0x51/0x90
> [  572.764800]  do_syscall_64+0x6e/0x1a0
> [  572.76]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [  572.774526] RIP: 0033:0x7f98ada843b0
> [  572.778515] RSP: 002b:7fff833a4f38 EFLAGS: 0246 ORIG_RAX: 
> 002e
> [  572.786963] RAX: ffda RBX: 5a8deb31 RCX: 
> 7f98ada843b0
> [  572.794929] RDX:  RSI: 7fff833a4f80 RDI: 
> 0003
> [  572.802892] RBP: 7fff833a4f80 R08:  R09: 
> 0001
> [  572.810856] R10: 7fff833a4320 R11: 0246 R12: 
> 
> [  572.818823] R13: 00650ba0 R14: 7fff833b11e8 R15: 

Re: [net-next v2 2/2] bpf: Add eBPF seccomp sample programs

[Randy Dunlap]

On 02/16/2018 11:36 PM, Sargun Dhillon wrote:
> + close(111);
> + assert(errno == EBADF);
> + close(999);
> + assert(errno = EPERM);

should that be   == ?

> +
> + return 0;
> +}


-- 
~Randy

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/11/2018 11:27 PM, Ingo Molnar wrote:
> 
> * Randy Dunlap <rdun...@infradead.org> wrote:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> Nice find:
> 
> Reviewed-by: Ingo Molnar <mi...@kernel.org>
> 
> I agree that it needs to go through 0-day to find any hidden dependencies we 
> might 
> have grown due to this.

Andrew,

This patch has mostly survived both 0day and ozlabs multi-arch testing with
2 build errors being reported by both of them.  I have posted patches for
those separately. (and are attached here)

other-patch-1:
lkml.kernel.org/r/5664ced1-a0cd-7e4e-71b6-9c3a97d68...@infradead.org
"lib/test_firmware: add header file to prevent build errors"

other-patch-2:
lkml.kernel.org/r/b3b7eebb-0e9f-f175-94a8-379c5ddca...@infradead.org
"integrity/security: fix digsig.c build error"

Will you see that these are merged or do you want me to repost them?

thanks,
-- 
~Randy
From: Randy Dunlap <rdun...@infradead.org>

security/integrity/digsig.c has build errors on some $ARCH due to a
missing header file, so add it.

  security/integrity/digsig.c:146:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Mimi Zohar <zo...@linux.vnet.ibm.com>
Cc: linux-integr...@vger.kernel.org
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 security/integrity/digsig.c |    1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/security/integrity/digsig.c
+++ lnx-416-rc1/security/integrity/digsig.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 



From: Randy Dunlap <rdun...@infradead.org>

lib/test_firmware.c has build errors on some $ARCH due to a
missing header file, so add it.

  lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
  lib/test_firmware.c:620:25: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]

Reported-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Wei Yongjun <weiyongj...@huawei.com>
Cc: Luis R. Rodriguez <mcg...@kernel.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Link: http://kisskb.ellerman.id.au/kisskb/head/13396/
---
 lib/test_firmware.c |1 +
 1 file changed, 1 insertion(+)

--- lnx-416-rc1.orig/lib/test_firmware.c
+++ lnx-416-rc1/lib/test_firmware.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TEST_FIRMWARE_NAME	"test-firmware.bin"
 #define TEST_FIRMWARE_NUM_REQS	4

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/13/2018 02:09 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> On 02/12/2018 04:28 AM, Michael Ellerman wrote:
>>> Randy Dunlap <rdun...@infradead.org> writes:
>>>
>>>> From: Randy Dunlap <rdun...@infradead.org>
>>>>
>>>> Currently  #includes  for no obvious
>>>> reason. It looks like it's only a convenience, so remove kmemleak.h
>>>> from slab.h and add  to any users of kmemleak_*
>>>> that don't already #include it.
>>>> Also remove  from source files that do not use it.
>>>>
>>>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>>>> would be good to run it through the 0day bot for other $ARCHes.
>>>> I have neither the horsepower nor the storage space for the other
>>>> $ARCHes.
>>>>
>>>> [slab.h is the second most used header file after module.h; kernel.h
>>>> is right there with slab.h. There could be some minor error in the
>>>> counting due to some #includes having comments after them and I
>>>> didn't combine all of those.]
>>>>
>>>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>>>> header files).
>>>>
>>>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
>>>
>>> I threw it at a random selection of configs and so far the only failures
>>> I'm seeing are:
>>>
>>>   lib/test_firmware.c:134:2: error: implicit declaration of function 
>>> 'vfree' [-Werror=implicit-function-declaration] 
>>> 
>>>  
>>>   lib/test_firmware.c:620:25: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   lib/test_firmware.c:620:2: error: implicit declaration of function 
>>> 'vzalloc' [-Werror=implicit-function-declaration]
>>>   security/integrity/digsig.c:146:2: error: implicit declaration of 
>>> function 'vfree' [-Werror=implicit-function-declaration]
>>
>> Both of those source files need to #include .
> 
> Yep, I added those and rebuilt. I don't see any more failures that look
> related to your patch.

Great, thanks.

I also sent patches for both of those.

>   http://kisskb.ellerman.id.au/kisskb/head/13399/
> 
> 
> I haven't gone through the defconfigs I have enabled for a while, so
> it's possible I have some missing but it's still a reasonable cross
> section.


-- 
~Randy

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 
> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/

That's very useful, thanks.

I'll send a few patches for those.

-- 
~Randy

Re: [PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

On 02/12/2018 04:28 AM, Michael Ellerman wrote:
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> From: Randy Dunlap <rdun...@infradead.org>
>>
>> Currently  #includes  for no obvious
>> reason. It looks like it's only a convenience, so remove kmemleak.h
>> from slab.h and add  to any users of kmemleak_*
>> that don't already #include it.
>> Also remove  from source files that do not use it.
>>
>> This is tested on i386 allmodconfig and x86_64 allmodconfig. It
>> would be good to run it through the 0day bot for other $ARCHes.
>> I have neither the horsepower nor the storage space for the other
>> $ARCHes.
>>
>> [slab.h is the second most used header file after module.h; kernel.h
>> is right there with slab.h. There could be some minor error in the
>> counting due to some #includes having comments after them and I
>> didn't combine all of those.]
>>
>> This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
>> header files).
>>
>> Signed-off-by: Randy Dunlap <rdun...@infradead.org>
> 
> I threw it at a random selection of configs and so far the only failures
> I'm seeing are:
> 
>   lib/test_firmware.c:134:2: error: implicit declaration of function 'vfree' 
> [-Werror=implicit-function-declaration]   
>
>   lib/test_firmware.c:620:25: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   lib/test_firmware.c:620:2: error: implicit declaration of function 
> 'vzalloc' [-Werror=implicit-function-declaration]
>   security/integrity/digsig.c:146:2: error: implicit declaration of function 
> 'vfree' [-Werror=implicit-function-declaration]
> 

Both of those source files need to #include .

> Full results trickling in here, not all the failures there are caused by
> this patch, ie. some configs are broken in mainline:
> 
>   http://kisskb.ellerman.id.au/kisskb/head/13396/
> 
> cheers

:)

-- 
~Randy

[PATCH] headers: untangle kmemleak.h from mm.h

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Currently  #includes  for no obvious
reason. It looks like it's only a convenience, so remove kmemleak.h
from slab.h and add  to any users of kmemleak_*
that don't already #include it.
Also remove  from source files that do not use it.

This is tested on i386 allmodconfig and x86_64 allmodconfig. It
would be good to run it through the 0day bot for other $ARCHes.
I have neither the horsepower nor the storage space for the other
$ARCHes.

[slab.h is the second most used header file after module.h; kernel.h
is right there with slab.h. There could be some minor error in the
counting due to some #includes having comments after them and I
didn't combine all of those.]

This is Lingchi patch #1 (death by a thousand cuts, applied to kernel
header files).

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---

Fengguang, can you have this patch run thru 0day builds, please?

 arch/powerpc/sysdev/dart_iommu.c  |1 +
 arch/powerpc/sysdev/msi_bitmap.c  |1 +
 arch/s390/kernel/nmi.c|2 +-
 arch/s390/kernel/smp.c|1 -
 arch/sparc/kernel/irq_64.c|1 -
 arch/x86/kernel/pci-dma.c |1 -
 drivers/iommu/exynos-iommu.c  |1 +
 drivers/iommu/mtk_iommu_v1.c  |1 -
 drivers/net/ethernet/ti/cpsw.c|1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c|1 -
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/fw_common.c |1 -
 drivers/staging/rtl8188eu/hal/fw.c|2 +-
 drivers/staging/rtlwifi/pci.c |1 -
 drivers/virtio/virtio_ring.c  |1 -
 include/linux/slab.h  |1 -
 kernel/ucount.c   |1 +
 mm/cma.c  |1 +
 mm/memblock.c |1 +
 net/core/sysctl_net_core.c|1 -
 net/ipv4/route.c  |1 -
 security/apparmor/lsm.c   |1 -
 21 files changed, 9 insertions(+), 14 deletions(-)

--- lnx-416-rc1.orig/include/linux/slab.h
+++ lnx-416-rc1/include/linux/slab.h
@@ -125,7 +125,6 @@
 #define ZERO_OR_NULL_PTR(x) ((unsigned long)(x) <= \
(unsigned long)ZERO_SIZE_PTR)
 
-#include 
 #include 
 
 struct mem_cgroup;
--- lnx-416-rc1.orig/kernel/ucount.c
+++ lnx-416-rc1/kernel/ucount.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define UCOUNTS_HASHTABLE_BITS 10
--- lnx-416-rc1.orig/mm/memblock.c
+++ lnx-416-rc1/mm/memblock.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/mm/cma.c
+++ lnx-416-rc1/mm/cma.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "cma.h"
--- lnx-416-rc1.orig/drivers/staging/rtl8188eu/hal/fw.c
+++ lnx-416-rc1/drivers/staging/rtl8188eu/hal/fw.c
@@ -30,7 +30,7 @@
 #include "rtl8188e_hal.h"
 
 #include 
-#include 
+#include 
 
 static void _rtl88e_enable_fw_download(struct adapter *adapt, bool enable)
 {
--- lnx-416-rc1.orig/drivers/iommu/exynos-iommu.c
+++ lnx-416-rc1/drivers/iommu/exynos-iommu.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/s390/kernel/nmi.c
+++ lnx-416-rc1/arch/s390/kernel/nmi.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/dart_iommu.c
+++ lnx-416-rc1/arch/powerpc/sysdev/dart_iommu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/arch/powerpc/sysdev/msi_bitmap.c
+++ lnx-416-rc1/arch/powerpc/sysdev/msi_bitmap.c
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/net/ethernet/ti/cpsw.c
+++ lnx-416-rc1/drivers/net/ethernet/ti/cpsw.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
--- lnx-416-rc1.orig/drivers/virtio/virtio_ring.c
+++ lnx-416-rc1/drivers/virtio/virtio_ring.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
--- lnx-416-rc1.orig/security/apparmor/lsm.c
+++ lnx-416-rc1/security/apparmor/lsm.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "include/apparmor.h"
--- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c
+++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- lnx-416-rc1.orig/drivers/

Re: [PATCH RFC 2/4] netlink: add generic object description infrastructure

[Randy Dunlap]

On 02/06/2018 05:37 PM, Pablo Neira Ayuso wrote:
> This patch allows netlink busses to provide object descriptions to
> userspace, in terms of supported attributes and its corresponding
> datatypes.
> 
> Userspace sends a requests that looks like:
> 
>   netlink header
>   NLA_DESC_REQ_BUS
>   NLA_DESC_REQ_DATA
> 
> Where NLA_DESC_REQ_BUS is the netlink bus/protocol number, eg.
> NETLINK_NETFILTER, and NLA_DESC_REQ_DATA is an attribute layout is
> specific to the bus that you are inspecting, this is useful for both
> nfnetlink and genetlink since they need to what subsystem in the bus
> specifically you're targeting to.
> 
> Then, the netlink description subsystem response via netlink dump looks
> like this:
> 
>   netlink header
>   NLA_DESC_NUM_OBJS
>   NLA_DESC_OBJS (nest)
>   NLA_DESC_LIST_ITEM (nest)
>   NLA_DESC_OBJ_ID
>   NLA_DESC_OBJ_ATTRS_MAX
>   NLA_DESC_OBJ_ATTRS (nest)
>   NLA_DESC_LIST_ITEM (nest)
>   NLA_DESC_ATTR_NUM
>   NLA_DESC_ATTR_TYPE
>   NLA_DESC_ATTR_LEN
>   NLA_DESC_ATTR_MAXVAL
>   NLA_DESC_ATTR_NEST_ID
>   NLA_DESC_LIST_ITEM (nest)
>   ...
> 
> Each object definition is composed of an unique ID, the number of
> attributes and the list of attribute definitions.
> 
> The NETLINK_DESC bus provides a generic interface to retrieve the list
> of existing objects and its attributes via netlink dump. This new
> description family autoloads module dependencies based on what userspace
> requests.
> 
> Each bus needs to register a struct nl_desc_subsys definition, that
> provides the lookup and parse callbacks. These route the description
> requests to the corresponding backend subsystem for genetlink and
> nfnetlink. The lookup callback returns struct nl_desc_objs that provides
> the array of object descriptions.
> 
> Signed-off-by: Pablo Neira Ayuso 
> ---
>  include/net/net_namespace.h  |   1 +
>  include/net/nldesc.h | 160 ++
>  include/uapi/linux/netlink.h |  67 ++
>  net/netlink/Makefile |   2 +-
>  net/netlink/desc.c   | 499 
> +++
>  5 files changed, 728 insertions(+), 1 deletion(-)
>  create mode 100644 include/net/nldesc.h
>  create mode 100644 net/netlink/desc.c
> 

> diff --git a/include/net/nldesc.h b/include/net/nldesc.h
> new file mode 100644
> index ..19306a648f10
> --- /dev/null
> +++ b/include/net/nldesc.h
> @@ -0,0 +1,160 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __NET_NLDESC_H
> +#define __NET_NLDESC_H
> +
> +#include 
> +
> +struct nl_desc_cmd;
> +struct nl_desc_obj;
> +
> +struct nl_desc_cmds {
> + int max;
> + const struct nl_desc_cmd*table;
> +};
> +
> +struct nl_desc_objs {
> + int max;
> + const struct nl_desc_obj**table;
> +};
> +
> +struct nl_desc_req {
> + u32 bus;
> +};
> +
> +struct net;
> +struct sk_buff;
> +struct nlmsghdr;
> +struct nlattr;
> +

> +
> +/**
> + * struct nl_desc_obj - netlink object description
> + * @id: unique ID to identify this netlink object
> + * @max: number of attributes to describe this object

  @attr_max:

> + * @attrs: array of attribute descriptions
> + */
> +struct nl_desc_obj {
> + u16 id;
> + u16 attr_max;
> + const struct nl_desc_attr   *attrs;
> +};


Is there a test program for this?
Maybe add it to tools/testing/ ?

thanks,
-- 
~Randy

Re: [PATCH v4 04/36] nds32: Kernel booting and initialization

[Randy Dunlap]

On 12/17/2017 10:46 PM, Greentime Hu wrote:
> From: Greentime Hu 
> 
> This patch includes the kernel startup code. It can get dtb pointer
> passed from bootloader. It will create a temp mapping by tlb
> instructions at beginning and goto start_kernel.
> 
> Signed-off-by: Vincent Chen 
> Signed-off-by: Greentime Hu 
> ---
>  arch/nds32/kernel/head.S  |  189 ++
>  arch/nds32/kernel/setup.c |  383 
> +
>  2 files changed, 572 insertions(+)
>  create mode 100644 arch/nds32/kernel/head.S
>  create mode 100644 arch/nds32/kernel/setup.c
> 

> diff --git a/arch/nds32/kernel/setup.c b/arch/nds32/kernel/setup.c
> new file mode 100644
> index 000..7718c58
> --- /dev/null
> +++ b/arch/nds32/kernel/setup.c
> @@ -0,0 +1,383 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2005-2017 Andes Technology Corporation
> +

[snip]

> +struct cache_info L1_cache_info[2];
> +static void __init dump_cpu_info(int cpu)
> +{
> + int i, p = 0;
> + char str[sizeof(hwcap_str) + 16];
> +
> + for (i = 0; hwcap_str[i]; i++) {
> + if (elf_hwcap & (1 << i)) {
> + sprintf(str + p, "%s ", hwcap_str[i]);
> + p += strlen(hwcap_str[i]) + 1;
> + }
> + }
> +
> + pr_info("CPU%d Featuretures: %s\n", cpu, str);

   Features:


-- 
~Randy

Re: [PATCH v1] net: pasemi: Replace mac address parsing

[Randy Dunlap]

On 12/19/2017 11:27 AM, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 11:19 -0800, Randy Dunlap wrote:
>> On 12/19/2017 10:31 AM, Andy Shevchenko wrote:
>>> Replace sscanf() with mac_pton().
>>>
>>> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
>>
>> You don't need to select GENERIC_NET_UTILS for that?
> 
> It's done by CONFIG_NET.
> 

Ah, thanks.

-- 
~Randy

Re: [PATCH v1] bridge: Use helpers to handle MAC address

[Randy Dunlap]

On 12/19/2017 10:10 AM, Andy Shevchenko wrote:
> Use
>   %pM to print MAC
>   mac_pton() to convert it from ASCII to binary format, and
>   ether_addr_copy() to copy.
> 
> Signed-off-by: Andy Shevchenko 

(same)
select GENERIC_NET_UTILS
?

> ---
>  net/bridge/br_sysfs_br.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
> index 723f25eed8ea..b1be0dcfba6b 100644
> --- a/net/bridge/br_sysfs_br.c
> +++ b/net/bridge/br_sysfs_br.c
> @@ -272,10 +272,7 @@ static ssize_t group_addr_show(struct device *d,
>  struct device_attribute *attr, char *buf)
>  {
>   struct net_bridge *br = to_bridge(d);
> - return sprintf(buf, "%x:%x:%x:%x:%x:%x\n",
> -br->group_addr[0], br->group_addr[1],
> -br->group_addr[2], br->group_addr[3],
> -br->group_addr[4], br->group_addr[5]);
> + return sprintf(buf, "%pM\n", br->group_addr);
>  }
>  
>  static ssize_t group_addr_store(struct device *d,
> @@ -284,14 +281,11 @@ static ssize_t group_addr_store(struct device *d,
>  {
>   struct net_bridge *br = to_bridge(d);
>   u8 new_addr[6];
> - int i;
>  
>   if (!ns_capable(dev_net(br->dev)->user_ns, CAP_NET_ADMIN))
>   return -EPERM;
>  
> - if (sscanf(buf, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
> -_addr[0], _addr[1], _addr[2],
> -_addr[3], _addr[4], _addr[5]) != 6)
> + if (!mac_pton(buf, new_addr))
>   return -EINVAL;
>  
>   if (!is_link_local_ether_addr(new_addr))
> @@ -306,8 +300,7 @@ static ssize_t group_addr_store(struct device *d,
>   return restart_syscall();
>  
>   spin_lock_bh(>lock);
> - for (i = 0; i < 6; i++)
> - br->group_addr[i] = new_addr[i];
> + ether_addr_copy(br->group_addr, new_addr);
>   spin_unlock_bh(>lock);
>  
>   br->group_addr_set = true;
> 


-- 
~Randy

Re: [PATCH v1] net: pasemi: Replace mac address parsing

[Randy Dunlap]

On 12/19/2017 10:31 AM, Andy Shevchenko wrote:
> Replace sscanf() with mac_pton().
> 
> Signed-off-by: Andy Shevchenko 

You don't need to select GENERIC_NET_UTILS for that?

> ---
>  drivers/net/ethernet/pasemi/pasemi_mac.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c 
> b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index c9a55b774935..07a2eb3781b1 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -212,9 +212,7 @@ static int pasemi_get_mac_addr(struct pasemi_mac *mac)
>   return -ENOENT;
>   }
>  
> - if (sscanf(maddr, "%hhx:%hhx:%hhx:%hhx:%hhx:%hhx",
> -[0], [1], [2], [3], [4], [5])
> - != ETH_ALEN) {
> + if (!mac_pton(maddr, addr)) {
>   dev_warn(>dev,
>"can't parse mac address, not configuring\n");
>   return -EINVAL;
> 


-- 
~Randy

net/wireless/certs/*.x509 binary files

[Randy Dunlap]

This is just an FYI/acknowledgment that net/wireless/certs/*.x509
binary file(s) practically kills use of Linux kernel tarballs.

Of course, someone can always enable EXPERT and CFG80211_CERTIFICATION_ONUS
and disable the REGDB kconfig symbols to get around this.
Oh, and then chmod +x tools/objtool/sync-check.sh (unrelated problem).

Then you are good to go. :)

Background:
I was getting build errors on net/wireless/shipped-certs.o and the
build log didn't help me at all. It just said something like,
Error: build failed on net/wireless/shipped-certs.o.
Even building with V=1 didn't help.
So I finally discovered the reason and worked around it.

-- 
~Randy

PS:  Yes, I know about git.

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

[Randy Dunlap]

On 12/11/2017 10:49 AM, Richard Weinberger wrote:
> Am Montag, 11. Dezember 2017, 11:19:54 CET schrieb Daniel Borkmann:
>> Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ]
>>
>> On 12/11/2017 09:32 AM, Richard Weinberger wrote:
>>> Randy,
>>>
>>> Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap:
>>>> On 12/10/2017 06:08 PM, Linus Torvalds wrote:
>>>>> Another week, another rc.
>>>>
>>>> um (uml) won't build on i386 or x86_64:
>>>>   CC  init/main.o
>>>>
>>>> In file included from ../include/linux/perf_event.h:18:0,
>>>>
>>>>  from ../include/linux/trace_events.h:10,
>>>>  from ../include/trace/syscall.h:7,
>>>>  from ../include/linux/syscalls.h:82,
>>>>
>>>>  from ../init/main.c:20:
>>>> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
>>>> asm/bpf_perf_event.h: No such file or directory #include
>>>> 
>>>>
>>>> ^
>>>>
>>>> compilation terminated.
>>>> ../scripts/Makefile.build:310: recipe for target 'init/main.o' failed
>>>
>>> How do you trigger that build failure?
>>> Can you share your .config?
>>
>> Hmm, too bad kbuild bot doesn't catch issues on uml. I'm not too familiar
>> with uml, but looks like it's the only special case where there's no
>> arch/um/include/uapi/asm/. What is the usual convention to pull in such
>> headers in this case? Something like the below, would that fix it for you?
>>
>> Thanks for your help,
>> Daniel
>>
>>  arch/um/include/asm/bpf_perf_event.h | 1 +
>>  include/asm-generic/bpf_perf_event.h | 1 +
>>  2 files changed, 2 insertions(+)
>>  create mode 100644 arch/um/include/asm/bpf_perf_event.h
>>  create mode 100644 include/asm-generic/bpf_perf_event.h
>>
>> diff --git a/arch/um/include/asm/bpf_perf_event.h
>> b/arch/um/include/asm/bpf_perf_event.h new file mode 100644
>> index 000..3097758
>> --- /dev/null
>> +++ b/arch/um/include/asm/bpf_perf_event.h
>> @@ -0,0 +1 @@
>> +#include 
>> diff --git a/include/asm-generic/bpf_perf_event.h
>> b/include/asm-generic/bpf_perf_event.h new file mode 100644
>> index 000..67112e5
>> --- /dev/null
>> +++ b/include/asm-generic/bpf_perf_event.h
>> @@ -0,0 +1 @@
>> +#include 
> 
> Hmm, what about this?
> 
> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
> index 50a32c33d729..fb35ec000433 100644
> --- a/arch/um/include/asm/Kbuild
> +++ b/arch/um/include/asm/Kbuild
> @@ -27,3 +27,4 @@ generic-y += trace_clock.h
>  generic-y += word-at-a-time.h
>  generic-y += xor.h
>  generic-y += kprobes.h
> +generic-y += bpf_perf_event.h
> 

That also works for arch/um.

thanks,
-- 
~Randy

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

[Randy Dunlap]

On 12/11/2017 02:19 AM, Daniel Borkmann wrote:
> Hi Randy, hi Richard, [ +Hendrik for c895f6f703ad7dd2f ]
> 
> On 12/11/2017 09:32 AM, Richard Weinberger wrote:
>> Randy,
>>
>> Am Montag, 11. Dezember 2017, 03:42:12 CET schrieb Randy Dunlap:
>>> On 12/10/2017 06:08 PM, Linus Torvalds wrote:
>>>> Another week, another rc.
>>>
>>> um (uml) won't build on i386 or x86_64:
>>>
>>>   CC  init/main.o
>>> In file included from ../include/linux/perf_event.h:18:0,
>>>  from ../include/linux/trace_events.h:10,
>>>  from ../include/trace/syscall.h:7,
>>>  from ../include/linux/syscalls.h:82,
>>>  from ../init/main.c:20:
>>> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
>>> asm/bpf_perf_event.h: No such file or directory #include
>>> 
>>> ^
>>> compilation terminated.
>>> ../scripts/Makefile.build:310: recipe for target 'init/main.o' failed
>>
>> How do you trigger that build failure?
>> Can you share your .config?

Richard, it's just defconfig on both i386 and x86_64.

> Hmm, too bad kbuild bot doesn't catch issues on uml. I'm not too familiar
> with uml, but looks like it's the only special case where there's no
> arch/um/include/uapi/asm/. What is the usual convention to pull in such
> headers in this case? Something like the below, would that fix it for you?
> 
> Thanks for your help,
> Daniel

Yes, that patch works.  Thanks.

>  arch/um/include/asm/bpf_perf_event.h | 1 +
>  include/asm-generic/bpf_perf_event.h | 1 +
>  2 files changed, 2 insertions(+)
>  create mode 100644 arch/um/include/asm/bpf_perf_event.h
>  create mode 100644 include/asm-generic/bpf_perf_event.h
> 
> diff --git a/arch/um/include/asm/bpf_perf_event.h 
> b/arch/um/include/asm/bpf_perf_event.h
> new file mode 100644
> index 000..3097758
> --- /dev/null
> +++ b/arch/um/include/asm/bpf_perf_event.h
> @@ -0,0 +1 @@
> +#include 
> diff --git a/include/asm-generic/bpf_perf_event.h 
> b/include/asm-generic/bpf_perf_event.h
> new file mode 100644
> index 000..67112e5
> --- /dev/null
> +++ b/include/asm-generic/bpf_perf_event.h
> @@ -0,0 +1 @@
> +#include 
> 


-- 
~Randy

Re: Linux 4.15-rc3 (uml + bpf_perf_event.h)

[Randy Dunlap]

On 12/10/2017 06:08 PM, Linus Torvalds wrote:
> Another week, another rc.
> 

um (uml) won't build on i386 or x86_64:

  CC  init/main.o
In file included from ../include/linux/perf_event.h:18:0,
 from ../include/linux/trace_events.h:10,
 from ../include/trace/syscall.h:7,
 from ../include/linux/syscalls.h:82,
 from ../init/main.c:20:
../include/uapi/linux/bpf_perf_event.h:11:32: fatal error: 
asm/bpf_perf_event.h: No such file or directory
 #include 
^
compilation terminated.
../scripts/Makefile.build:310: recipe for target 'init/main.o' failed


Should that be  ?

-- 
~Randy

Re: [PATCH V11 4/5] vsprintf: add printk specifier %px

[Randy Dunlap]

On 11/30/2017 02:38 AM, David Laight wrote:
> From: Kees Cook
>> Sent: 29 November 2017 22:28
>> On Wed, Nov 29, 2017 at 2:07 AM, David Laight  
>> wrote:
>>> From: Linus Torvalds
 Sent: 29 November 2017 02:29

 On Tue, Nov 28, 2017 at 6:05 PM, Tobin C. Harding  wrote:
>
>Let's add specifier %px as a
> clear, opt-in, way to print a pointer and maintain some level of
> isolation from all the other hex integer output within the Kernel.

 Yes, I like this model. It's easy and it's obvious ("'x' for hex"),
 and it gives people a good way to say "yes, I really want the actual
 address as hex" for if/when the hashed pointer doesn't work for some
 reason.
>>>
>>> Remind me to change every %p to %px on kernels that support it.
>>>
>>> Although the absolute values of pointers may not be useful, knowing
>>> that two pointer differ by a small amount is useful.
>>> It is also useful to know whether pointers are to stack, code, static
>>> data or heap.
>>>
>>> This change to %p is going to make debugging a nightmare.
>>
>> In the future, maybe we could have a knob: unhashed, hashed (default),
>> or zeroed.
> 
> Add a 4th, hashed_page+offset.
> 
> Isn't there already a knob for %pK, bits in the same value could be used.
> That would make it easy to ensure that %pK is more restructive than %p.

(yeah, I'm kind of behind on this thread.)

This kind of option (with default hashed) is what I was just thinking of
after having seen a few unhelpful traces.  But then the knob might not be
changed in time for the traces either. :(


-- 
~Randy

[PATCH] cfg80211: fix kernel-doc warnings

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Drop kernel-doc comment for this value since this value was dropped
in a previous commit.

Fixes >100 of these warnings:
../include/net/cfg80211.h:3278: warning: Excess enum value 
'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'

Fixes: ca986ad9bcd3 ("nl80211: allow multiple active scheduled scan requests")
Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Arend Van Spriel <arend.vanspr...@broadcom.com>
---
 include/net/cfg80211.h |1 -
 1 file changed, 1 deletion(-)

--- lnx-415-rc2.orig/include/net/cfg80211.h
+++ lnx-415-rc2/include/net/cfg80211.h
@@ -3226,7 +3226,6 @@ struct cfg80211_ops {
  * @WIPHY_FLAG_IBSS_RSN: The device supports IBSS RSN.
  * @WIPHY_FLAG_MESH_AUTH: The device supports mesh authentication by routing
  * auth frames to userspace. See @NL80211_MESH_SETUP_USERSPACE_AUTH.
- * @WIPHY_FLAG_SUPPORTS_SCHED_SCAN: The device supports scheduled scans.
  * @WIPHY_FLAG_SUPPORTS_FW_ROAM: The device supports roaming feature in the
  * firmware.
  * @WIPHY_FLAG_AP_UAPSD: The device supports uapsd on AP.

Re: [PATCH] leds: trigger: Introduce a NETDEV trigger

[Randy Dunlap]

On 11/28/2017 01:54 PM, Ben Whitten wrote:

> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index 3f9ddb9..4ec1853 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -126,4 +126,11 @@ config LEDS_TRIGGER_PANIC
> a different trigger.
> If unsure, say Y.
>  
> +config LEDS_TRIGGER_NETDEV
> + tristate "LED Netdev Trigger"
> + depends on NET && LEDS_TRIGGERS
> + help
> +   This allows LEDs to be controlled by network device activity.
> +   If unsure, say Y.
> +
>  endif # LEDS_TRIGGERS

What LEDs do LED triggers manipulate?  I.e., where are they?

-- 
~confuzed

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

[Randy Dunlap]

Hi,

Mostly typos/spellos...


On 11/27/2017 09:18 AM, Djalal Harouni wrote:
> Cc: Serge Hallyn 
> Cc: Andy Lutomirski 
> Suggested-by: Rusty Russell 
> Suggested-by: Kees Cook 
> Signed-off-by: Djalal Harouni 
> ---
>  include/linux/kmod.h  | 65 
> ++-
>  include/linux/lsm_hooks.h |  6 -
>  include/linux/security.h  |  7 +++--
>  kernel/kmod.c | 29 -
>  security/security.c   |  6 +++--
>  security/selinux/hooks.c  |  3 ++-
>  6 files changed, 97 insertions(+), 19 deletions(-)
> 
> diff --git a/include/linux/kmod.h b/include/linux/kmod.h
> index 40c89ad..ccd6a1c 100644
> --- a/include/linux/kmod.h
> +++ b/include/linux/kmod.h
> @@ -33,16 +33,67 @@

> +/**
> + * request_module  Try to load a kernel module
> + *
> + * Automatically loads the request module.
> + *
> + * @mod...: The module name
> + */

what are the "..." for?  what do they do here?

> +#define request_module(mod...) __request_module(true, -1, NULL, mod)
> +
> +#define request_module_nowait(mod...) __request_module(false, -1, NULL, mod)
> +
> +/**
> + * request_module_cap  Load kernel module only if the required capability is 
> set
> + *
> + * Automatically load a module if the required capability is set and it
> + * corresponds to the appropriate subsystem that is indicated by prefix.
> + *
> + * This allows to load aliased modules like 'netdev-%s' with CAP_NET_ADMIN.
> + *
> + * ex:
> + *   request_module_cap(CAP_NET_ADMIN, "netdev", "%s", mod);
> + *
> + * @required_cap: Required capability to load the module
> + * @prefix: The module prefix if any, otherwise NULL
> + * @fmt: printf style format string for the name of the module with its
> + *   arguments if any
> + *
> + * If '@required_cap' is positive, the security subsystem will check if
> + * '@prefix' is set and if caller has the required capability then the
> + * operation is allowed.
> + * The security subsystem can not make assumption about the boundaries
> + * of other subsystems, it is their responsability to make a call with

   responsibility

> + * the right capability and module alias.
> + *
> + * If '@required_cap' is positive and '@prefix' is NULL then we assume
> + * that the '@required_cap' is CAP_SYS_MODULE.
> + *
> + * If '@required_cap' is negative then there are no permission checks, this
> + * is the equivalent to request_module() function.
> + *
> + * This function trust callers to pass the right capability with the

trusts

> + * appropriate prefix.
> + *
> + * Note: the permission checks may still fail, even if the required
> + * capability is negative, this is due to module loading restrictions

negative; this

> + * that are controlled by the enduser.
> + */
> +#define request_module_cap(required_cap, prefix, fmt...) \
> + __request_module(true, required_cap, prefix, fmt)
> +
>  #endif /* __LINUX_KMOD_H__ */
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 7161d8e..d898bd0 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -571,6 +571,9 @@
>   *   Ability to trigger the kernel to automatically upcall to userspace for
>   *   userspace to load a kernel module with the given name.
>   *   @kmod_name name of the module requested by the kernel
> + *   @required_cap If positive, the required capability to automatically load
> + *   the correspondig kernel module.

corresponding

> + *   @prefix The prefix of the module if any. Can be NULL.
>   *   Return 0 if successful.
>   * @kernel_read_file:
>   *   Read a file specified by userspace.

> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index bc6addd..679d401 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -109,6 +109,8 @@ static int call_modprobe(char *module_name, int wait)
>  /**
>   * __request_module - try to load a kernel module
>   * @wait: wait (or not) for the operation to complete
> + * @required_cap: required capability to load the module
> + * @prefix: module prefix if any otherwise NULL
>   * @fmt: printf style format string for the name of the module
>   * @...: arguments as specified in the format string
>   *
> @@ -119,14 +121,20 @@ static int call_modprobe(char *module_name, int wait)
>   * must check that the service they requested is now available not blindly
>   * invoke it.
>   *
> - * If module auto-loading support is disabled then this function
> - * becomes a no-operation.
> + * If "required_cap" is positive, The security subsystem will trust the 
> caller

 the

> + * that if it has "required_cap" then it may allow to load some modules that
> + * have a specific alias.
> + *
> + * If module auto-loading support is disabled by clearing the modprobe path
> + * then this function becomes a no-operation.
>   */
> -int 

Re: [PATCH v1] Bluetooth: introduce DEFINE_SHOW_ATTRIBUTE() macro

[Randy Dunlap]

On 11/22/2017 02:04 PM, Randy Dunlap wrote:
> On 11/22/2017 01:15 PM, Andy Shevchenko wrote:
>> This macro deduplicates a lot of similar code across the hci_debugfs.c
>> module. Targeting to be moved to seq_file.h eventually.
>>
>> Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
>> ---
>>  net/bluetooth/hci_debugfs.c | 184 
>> +---
>>  1 file changed, 18 insertions(+), 166 deletions(-)
> 
> Looks like a good idea, but below, there is a use of
> DEFINE_SHOW_ATTRIBUTE() before it is #defined.
> 
>> diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c
>> index 63df63ebfb24..d4174d508cbf 100644
>> --- a/net/bluetooth/hci_debugfs.c
>> +++ b/net/bluetooth/hci_debugfs.c
>> @@ -88,6 +88,9 @@ static int __name ## _show(struct seq_file *f, void *ptr)  
>>   \
>>  return 0; \
>>  } \
>>\
>> +DEFINE_SHOW_ATTRIBUTE(__name)
> 
> eh?

OK, it's a continuation of the macro above it.
Sorry about that.


>> +> +#define DEFINE_SHOW_ATTRIBUTE(__name)
>>   \
>>  static int __name ## _open(struct inode *inode, struct file *file)\
>>  { \
>>  return single_open(file, __name ## _show, inode->i_private);  \
> 
> 


-- 
~Randy

Re: [PATCH v1] Bluetooth: introduce DEFINE_SHOW_ATTRIBUTE() macro

[Randy Dunlap]

On 11/22/2017 01:15 PM, Andy Shevchenko wrote:
> This macro deduplicates a lot of similar code across the hci_debugfs.c
> module. Targeting to be moved to seq_file.h eventually.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  net/bluetooth/hci_debugfs.c | 184 
> +---
>  1 file changed, 18 insertions(+), 166 deletions(-)

Looks like a good idea, but below, there is a use of
DEFINE_SHOW_ATTRIBUTE() before it is #defined.

> diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c
> index 63df63ebfb24..d4174d508cbf 100644
> --- a/net/bluetooth/hci_debugfs.c
> +++ b/net/bluetooth/hci_debugfs.c
> @@ -88,6 +88,9 @@ static int __name ## _show(struct seq_file *f, void *ptr)   
>   \
>   return 0; \
>  }  \
> \
> +DEFINE_SHOW_ATTRIBUTE(__name)

eh?

> +> +#define DEFINE_SHOW_ATTRIBUTE(__name) 
>   \
>  static int __name ## _open(struct inode *inode, struct file *file) \
>  {  \
>   return single_open(file, __name ## _show, inode->i_private);  \


-- 
~Randy

Re: [PATCH net-next v2 0/2] netem: fix compilation on 32 bit

[Randy Dunlap]

On 11/14/2017 11:27 AM, Stephen Hemminger wrote:
> A couple of places where 64 bit CPU was being assumed incorrectly.
> 
> Stephen Hemminger (2):
>   netem: fix 64 bit divide
>   netem: remove unnecessary 64 bit modulus
> 
>  net/sched/sch_netem.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 

Acked-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

-- 
~Randy

Re: [PATCH] netem: fix 64 bit divide

[Randy Dunlap]

On 11/14/2017 09:28 AM, Stephen Hemminger wrote:
> Since times are now expressed in 64 bit nanosecond, need to now do
> true 64 bit divide. Change the name of the function to bette express
> the new units.
> 
> Fixes: 99803171ef04 ("netem: add uapi to express delay and jitter in 
> nanoseconds")
> Reported-by: Randy Dunlap <rdun...@infradead.org>
> Signed-off-by: Stephen Hemminger <step...@networkplumber.org>

Hi Stephen,

I still get it. Maybe it's this % operator:

skb->data[prandom_u32() % skb_headlen(skb)] ^=
1<<(prandom_u32() % 8);

in net_enqueue().

> ---
>  net/sched/sch_netem.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
> index b686e755fda9..644323d6081c 100644
> --- a/net/sched/sch_netem.c
> +++ b/net/sched/sch_netem.c
> @@ -339,10 +339,8 @@ static s64 tabledist(s64 mu, s64 sigma,
>   return  x / NETEM_DIST_SCALE + (sigma / NETEM_DIST_SCALE) * t + mu;
>  }
>  
> -static u64 packet_len_2_sched_time(unsigned int len,
> -struct netem_sched_data *q)
> +static u64 packet_time_ns(u64 len, const struct netem_sched_data *q)
>  {
> - u64 offset;
>   len += q->packet_overhead;
>  
>   if (q->cell_size) {
> @@ -352,9 +350,8 @@ static u64 packet_len_2_sched_time(unsigned int len,
>   cells++;
>   len = cells * (q->cell_size + q->cell_overhead);
>   }
> - offset = (u64)len * NSEC_PER_SEC;
> - do_div(offset, q->rate);
> - return offset;
> +
> + return div64_u64(len * NSEC_PER_SEC, q->rate);
>  }
>  
>  static void tfifo_reset(struct Qdisc *sch)
> @@ -556,7 +553,7 @@ static int netem_enqueue(struct sk_buff *skb, struct 
> Qdisc *sch,
>   now = last->time_to_send;
>   }
>  
> - delay += packet_len_2_sched_time(qdisc_pkt_len(skb), q);
> + delay += packet_time_ns(qdisc_pkt_len(skb), q);
>   }
>  
>   cb->time_to_send = now + delay;
> 


-- 
~Randy

Re: linux-next: Tree for Nov 14 (net/sched/sch_netem)

[Randy Dunlap]

On 11/13/2017 10:20 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Please do not add any v4.16 material to your linux-next included trees
> until v4.15-rc1 has been released.
> 
> Changes since 20171113:


on i386:

ERROR: "__moddi3" [net/sched/sch_netem.ko] undefined!


-- 
~Randy

[PATCH] textsearch: fix typos in library helpers

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix spellos (typos) in textsearch library helpers.

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 lib/ts_fsm.c |2 +-
 lib/ts_kmp.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- lnx-414-rc5.orig/lib/ts_fsm.c
+++ lnx-414-rc5/lib/ts_fsm.c
@@ -11,7 +11,7 @@
  * ==
  *
  *   A finite state machine consists of n states (struct ts_fsm_token)
- *   representing the pattern as a finite automation. The data is read
+ *   representing the pattern as a finite automaton. The data is read
  *   sequentially on an octet basis. Every state token specifies the number
  *   of recurrences and the type of value accepted which can be either a
  *   specific character or ctype based set of characters. The available
--- lnx-414-rc5.orig/lib/ts_kmp.c
+++ lnx-414-rc5/lib/ts_kmp.c
@@ -27,7 +27,7 @@
  *
  *   [1] Cormen, Leiserson, Rivest, Stein
  *   Introdcution to Algorithms, 2nd Edition, MIT Press
- *   [2] See finite automation theory
+ *   [2] See finite automaton theory
  */
 
 #include 

Re: [PATCH] tests: Remove bashisms (s/source/.)

[Randy Dunlap]

On 10/11/17 11:01, Stephen Hemminger wrote:
> On Sun,  8 Oct 2017 16:39:16 +0200
> Petr Vorel  wrote:
> 
>> Signed-off-by: Petr Vorel 
> 
> Ok, applied. But iproute2 is really limited to Linux and bash is lingua 
> franca on Linux
> 

no French, please. Some distros use dash, but being POSIX is usually good.

-- 
~Randy

Re: [PATCH v4 4/4] samples/bpf: Add documentation on cross compilation

[Randy Dunlap]

On 09/20/17 09:11, Joel Fernandes wrote:
> Acked-by: Alexei Starovoitov 
> Signed-off-by: Joel Fernandes 
> ---
>  samples/bpf/README.rst | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst
> index 79f9a58f1872..2b906127ef54 100644
> --- a/samples/bpf/README.rst
> +++ b/samples/bpf/README.rst
> @@ -64,3 +64,13 @@ It is also possible to point make to the newly compiled 
> 'llc' or
>  'clang' command via redefining LLC or CLANG on the make command line::
>  
>   make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
> CLANG=~/git/llvm/build/bin/clang
> +
> +Cross compiling samples
> +---
> +Inorder to cross-compile, say for arm64 targets, export CROSS_COMPILE and 
> ARCH

   In order to

> +environment variables before calling make. This will direct make to build
> +samples for the cross target.
> +
> +export ARCH=arm64
> +export CROSS_COMPILE="aarch64-linux-gnu-"
> +make samples/bpf/ LLC=~/git/llvm/build/bin/llc 
> CLANG=~/git/llvm/build/bin/clang
> 


-- 
~Randy

[PATCH] Documentation: networking: fix ASCII art in switchdev.txt

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix ASCII art in Documentation/networking/switchdev.txt:

Change non-ASCII "spaces" to ASCII spaces.

Change 2 erroneous '+' characters in ASCII art to '-' (at the '*'
characters below):

line 32:
 +--++++-*--++---+  +-+-+
line 41:
 +--+---*+

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 Documentation/networking/switchdev.txt |   64 +++
 1 file changed, 32 insertions(+), 32 deletions(-)

--- lnx-413.orig/Documentation/networking/switchdev.txt
+++ lnx-413/Documentation/networking/switchdev.txt
@@ -13,42 +13,42 @@ an example setup using a data-center-cla
 with SR-IOV or soft switches, such as OVS, are possible.
 
 
- User-space tools
+ User-space tools
 
-   user space   |
-  +---+
-   kernel   | Netlink
-|
- +--+---+
- | Network stack|
- |   (Linux)|
- |  |
- +--+
+   user space   |
+  +---+
+   kernel   | Netlink
+|
+ +--+---+
+ | Network stack|
+ |   (Linux)|
+ |  |
+ +--+
 
sw1p2 sw1p4 sw1p6
-  sw1p1  +  sw1p3  +  sw1p5  +  eth1
-+|+|+|+
-|||||||
- +--++++-+--++---+  +-+-+
- | Switch driver |  |mgmt   |
- |(this document)|  |   driver  |
- |   |  |   |
- +--++  +---+
-|
-   kernel   | HW bus (eg PCI)
-  +---+
-   hardware |
- +--+---++
- | Switch device (sw1)   |
- |  ++   ++
- |  |v offloaded data path   | mgmt port
- |  ||   |
- +--||++++---+
-||||||
-++++++
-   p1   p2   p3   p4   p5   p6
+  sw1p1  +  sw1p3  +  sw1p5  +  eth1
++|+|+|+
+|||||||
+ +--++++++---+  +-+-+
+ | Switch driver |  |mgmt   |
+ |(this document)|  |   driver  |
+ |   |  |   |
+ +--++  +---+
+|
+   kernel   | HW bus (eg PCI)
+  +---+
+   hardware |
+ +--++
+ | Switch device (sw1)   |
+ |  ++   ++
+ |  |v offloaded data path   | mgmt port
+ |  ||   |
+ +--||++++---+
+||||||
+++++++
+   p1   p2   p3   p4   p5   p6
 
- front-panel ports
+ front-panel ports
 
 
 Fig 1.

Re: [PATCH] Documentation: fix ascii art in networking docs

[Randy Dunlap]

On 09/16/17 11:18, Andreas Schwab wrote:
> On Sep 16 2017, Pavel Machek  wrote:
> 
>> diff --git a/Documentation/networking/switchdev.txt 
>> b/Documentation/networking/switchdev.txt
>> index 5e40e1f..6309e90 100644
>> --- a/Documentation/networking/switchdev.txt
>> +++ b/Documentation/networking/switchdev.txt
>> @@ -29,7 +29,7 @@ with SR-IOV or soft switches, such as OVS, are possible.
>>    sw1p1  +  sw1p3  +  sw1p5  +  eth1
>>  +|+|+|+
>>  |||||||
>> - +--++++-+--++---+  +-+-+
>> + +--++++++---+  +-+-+
>>   | Switch driver |  |mgmt   |
>>   |(this document)|  |   driver  |
>>   |   |  |   |
>>
> 
> This is all mis-aligned.  How about replacing all the thin space
> characters by normal spaces?

Yes, there are lots of non-ASCII "spaces" in the ASCII art.  :(

-- 
~Randy

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

[Randy Dunlap]

On 08/15/2017 10:36 AM, David Miller wrote:
> From: Randy Dunlap <rdun...@infradead.org>
> Date: Tue, 15 Aug 2017 09:41:53 -0700
> 
>> On 08/15/2017 06:51 AM, Neal Cardwell wrote:
>>> On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah
>>> <mohamed.a.alrs...@ieee.org> wrote:
>>>
>>>> +static void agilesdtcp_cong_avoid(struct sock *sk, u32 ack, u32 in_flight)
>>>> +{
>>>> +   struct tcp_sock *tp = tcp_sk(sk);
>>>> +   struct agilesdtcp *ca = inet_csk_ca(sk);
>>>> +   u32 inc_factor;
>>>> +   u32 ca_inc;
>>>> +   u32 current_gap, total_gap;
>>>
>>> For coding style, please order local variable declarations from
>>> longest to shortest line, also know as Reverse Christmas Tree Format.
>>
>> Per what coding style, please?  This is not in current coding style nor in 
>> the
>> netdev-FAQ exceptions.
> 
> It is the established practice, documented or not, and I enforce this for all
> networking code submissions.

I see.  Thanks for clarifying that.

-- 
~Randy

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

[Randy Dunlap]

On 08/15/2017 06:08 AM, mohamedalrshah wrote:
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index 91a2557..474f72c 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -677,6 +677,17 @@ config TCP_CONG_BBR
>   bufferbloat, policers, or AQM schemes that do not provide a delay
>   signal. It requires the fq ("Fair Queue") pacing packet scheduler.
>  
> +config TCP_CONG_AGILESD
> +tristate "Agile-SD Congestion control"
> +default n
> +---help---
> +
> +This is version 1.0 of Agile-SD TCP. It is a sender-side only. 

It is a sender-side only .

> +It contributes the Agility Factor (AF) to shorten the epoch time 
> +and to make TCP independent from RTT. AF reduces the sensitivity 
> +to packet losses, which in turn Agile-SD to achieve better 
> throughput 

   in turn allows Agile-SD

> +over high-speed networks.
> +

Please drop the tab(s) and space(s) at the ends of lines.

>  choice
>   prompt "Default TCP congestion control"
>   default DEFAULT_CUBIC
> @@ -713,6 +724,9 @@ choice
>  
>   config DEFAULT_BBR
>   bool "BBR" if TCP_CONG_BBR=y
> +
> +config DEFAULT_AGILESD

Indent above with tab, not spaces.

> + bool "AGILESD" if TCP_CONG_AGILESD=y
>  
>   config DEFAULT_RENO
>   bool "Reno"
> @@ -738,6 +752,7 @@ config DEFAULT_TCP_CONG
>   default "dctcp" if DEFAULT_DCTCP
>   default "cdg" if DEFAULT_CDG
>   default "bbr" if DEFAULT_BBR
> +default "agilesd" if DEFAULT_AGILESD

Indent above with tab, not spaces.

>   default "cubic"
>  
>  config TCP_MD5SIG


-- 
~Randy

Re: [PATCH] Adding-Agile-SD-TCP-module-and-modifying-Kconfig-and-makefile

[Randy Dunlap]

On 08/15/2017 06:51 AM, Neal Cardwell wrote:
> On Tue, Aug 15, 2017 at 9:08 AM, mohamedalrshah
>  wrote:
> 
>> +static void agilesdtcp_cong_avoid(struct sock *sk, u32 ack, u32 in_flight)
>> +{
>> +   struct tcp_sock *tp = tcp_sk(sk);
>> +   struct agilesdtcp *ca = inet_csk_ca(sk);
>> +   u32 inc_factor;
>> +   u32 ca_inc;
>> +   u32 current_gap, total_gap;
> 
> For coding style, please order local variable declarations from
> longest to shortest line, also know as Reverse Christmas Tree Format.

Per what coding style, please?  This is not in current coding style nor in the
netdev-FAQ exceptions.


-- 
~Randy

Re: [PATCH net] net: phy: Fix MDIO_THUNDER dependencies

[Randy Dunlap]

On 06/12/17 17:18, Florian Fainelli wrote:
> After commit 90eff9096c01 ("net: phy: Allow splitting MDIO
> bus/device support from PHYs") we could create a configuration where
> MDIO_DEVICE=y and PHYLIB=m which leads to the following undefined
> references:
> 
>  drivers/built-in.o: In function `thunder_mdiobus_pci_remove':
>>> mdio-thunder.c:(.text+0x2a212f): undefined reference to
>>> `mdiobus_unregister'
>>> mdio-thunder.c:(.text+0x2a2138): undefined reference to
>>> `mdiobus_free'
>drivers/built-in.o: In function `thunder_mdiobus_pci_probe':
>mdio-thunder.c:(.text+0x2a22e7): undefined reference to
> `devm_mdiobus_alloc_size'
>mdio-thunder.c:(.text+0x2a236f): undefined reference to
> `of_mdiobus_register'
> 
> Reported-by: kbuild test robot <fengguang...@intel.com>
> Fixes: 90eff9096c01 ("net: phy: Allow splitting MDIO bus/device support from 
> PHYs")
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>

Tested-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  drivers/net/phy/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index c360dd6ead22..3ab6c58d4be6 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -127,6 +127,7 @@ config MDIO_THUNDER
>   tristate "ThunderX SOCs MDIO buses"
>   depends on 64BIT
>   depends on PCI
> + depends on !(MDIO_DEVICE=y && PHYLIB=m)
>   select MDIO_CAVIUM
>   help
> This driver supports the MDIO interfaces found on Cavium
> 


-- 
~Randy

Re: mdio-thunder.c:undefined reference to `mdiobus_unregister'

[Randy Dunlap]

On 06/11/17 19:14, kbuild test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   32c1431eea4881a6b17bd7c639315010aeefa452
> commit: 90eff9096c01ba90cdae504a6b95ee87fe2556a3 net: phy: Allow splitting 
> MDIO bus/device support from PHYs
> date:   3 months ago
> config: x86_64-randconfig-s2-06120830 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> git checkout 90eff9096c01ba90cdae504a6b95ee87fe2556a3
> # save the attached .config to linux build tree
> make ARCH=x86_64 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `thunder_mdiobus_pci_remove':
>>> mdio-thunder.c:(.text+0x2a212f): undefined reference to `mdiobus_unregister'
>>> mdio-thunder.c:(.text+0x2a2138): undefined reference to `mdiobus_free'
>drivers/built-in.o: In function `thunder_mdiobus_pci_probe':
>mdio-thunder.c:(.text+0x2a22e7): undefined reference to 
> `devm_mdiobus_alloc_size'
>mdio-thunder.c:(.text+0x2a236f): undefined reference to 
> `of_mdiobus_register'
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Ugh. I don't know the solution to this one.

CONFIG_MDIO_DEVICE=y
CONFIG_MDIO_THUNDER=y
CONFIG_PHYLIB=m

First 2 lines are OK, but the third line causes the problem...
in drivers/net/phy/Makefile:

# PHYLIB implies MDIO_DEVICE, in that case, we have a bunch of circular
# dependencies that does not make it possible to split mdio-bus objects into a
# dedicated loadable module, so we bundle them all together into libphy.ko
ifdef CONFIG_PHYLIB
libphy-y+= $(mdio-bus-y)
else
obj-$(CONFIG_MDIO_DEVICE)   += mdio-bus.o
endif
libphy-$(CONFIG_SWPHY)  += swphy.o
libphy-$(CONFIG_LED_TRIGGER_PHY)+= phy_led_triggers.o

obj-$(CONFIG_PHYLIB)+= libphy.o


So PHYLIB is built as libphy.ko and the mdiobus functions are there
instead of being in mdio-bus.o (so they are not built-in), while the
mdio-thunder driver is built-in.



-- 
~Randy

Re: [Regression, 4.12-rc1] Address family not supported by protocol

[Randy Dunlap]

[adding netdev]

Hi Paul,
Did you get anywhere with this?

The only difference that I see in the kernel config files is

4.12-rc1 says:
# CONFIG_NET_SCH_DEFAULT is not set

and 4.11 does not have that kconfig option.


On 05/15/17 05:53, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> When building Linux 4.12-rc1 with the configuration from Linux 4.11, then 
> many user space programs show the error `Address family not supported by 
> protocol`.
> 
> Please find the configuration, and the Linux kernel messages attached.
> 
> [5.383630] systemd[1]: Failed to insert module 'autofs4': No such file or 
> directory
> [5.383808] systemd[1]: Failed to insert module 'unix': No such file or 
> directory
> [5.600711] systemd[1]: systemd 231 running in system mode. (+PAM -AUDIT 
> -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP +GCRYPT +GNUTLS 
> -ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
> [5.601028] systemd[1]: Detected architecture x86-64.
> [5.623700] systemd[1]: Set hostname to .
> [5.631835] systemd[1]: Failed to read AF_UNIX datagram queue length, 
> ignoring: No such file or directory
> [6.404973] systemd[1]: Failed to allocate notification socket: Address 
> family not supported by protocol
> [6.405441] systemd[1]: Failed to allocate cgroups agent socket: Address 
> family not supported by protocol
> [6.405817] systemd[1]: Failed to allocate private socket: Address family 
> not supported by protocol
> [6.406218] systemd[1]: socket() failed: Address family not supported by 
> protocol
> [6.406379] systemd[1]: Failed to fully start up daemon: Address family 
> not supported by protocol
> [6.515759] systemd[1]: Failed to listen on udev Control Socket.
> [8.597362] systemd-udevd[283]: error getting socket: Address family not 
> supported by protocol
> Any help, where to report this issue to, is welcome.
> 
> 
> Kind regards,
> 
> Paul


-- 
~Randy

[PATCH] net: phy: fix kernel-doc warnings

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix kernel-doc warnings (typo) in drivers/net/phy/phy.c:

..//drivers/net/phy/phy.c:259: warning: No description found for parameter 
'features'
..//drivers/net/phy/phy.c:259: warning: Excess function parameter 'feature' 
description in 'phy_lookup_setting'

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 drivers/net/phy/phy.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-412-rc4.orig/drivers/net/phy/phy.c
+++ lnx-412-rc4/drivers/net/phy/phy.c
@@ -241,7 +241,7 @@ static const struct phy_setting settings
  * phy_lookup_setting - lookup a PHY setting
  * @speed: speed to match
  * @duplex: duplex to match
- * @feature: allowed link modes
+ * @features: allowed link modes
  * @exact: an exact match is required
  *
  * Search the settings array for a setting that matches the speed and

[PATCH] net/phy: fix mdio-octeon dependency and build

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix build errors by making this driver depend on OF_MDIO, like
several other similar drivers do.

drivers/built-in.o: In function `octeon_mdiobus_remove':
mdio-octeon.c:(.text+0x196ee0): undefined reference to `mdiobus_unregister'
mdio-octeon.c:(.text+0x196ee8): undefined reference to `mdiobus_free'
drivers/built-in.o: In function `octeon_mdiobus_probe':
mdio-octeon.c:(.text+0x196f1d): undefined reference to `devm_mdiobus_alloc_size'
mdio-octeon.c:(.text+0x196ffe): undefined reference to `of_mdiobus_register'
mdio-octeon.c:(.text+0x197010): undefined reference to `mdiobus_free'

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Andrew Lunn <and...@lunn.ch>
Cc: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Found in linux-next but applies to mainline also.

--- linux-next-20170523.orig/drivers/net/phy/Kconfig
+++ linux-next-20170523/drivers/net/phy/Kconfig
@@ -108,7 +108,7 @@ config MDIO_MOXART
 config MDIO_OCTEON
tristate "Octeon and some ThunderX SOCs MDIO buses"
depends on 64BIT
-   depends on HAS_IOMEM
+   depends on HAS_IOMEM && OF_MDIO
select MDIO_CAVIUM
help
  This module provides a driver for the Octeon and ThunderX MDIO

Re: linux-next: Tree for May 16 (net/core)

[Randy Dunlap]

On 05/15/17 18:21, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170515:
> 

on i386 or x86_64:

when CONFIG_INET is not enabled:

../net/core/sock.c: In function 'skb_orphan_partial':
../net/core/sock.c:1810:2: error: implicit declaration of function 
'skb_is_tcp_pure_ack' [-Werror=implicit-function-declaration]
  if (skb_is_tcp_pure_ack(skb))
  ^



-- 
~Randy

Re: linux-next: Tree for Apr 26 (net/can/bcm.c)

[Randy Dunlap]

On 04/26/17 01:03, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170424:
> 

on x86_64:

when CONFIG_PROC_FS is not enabled:

../net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 
'bcmproc_dir'
../net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 
'bcmproc_dir'
../net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 
'bcmproc_dir'
../net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 
'bcmproc_dir'

2 of those are "protected" by
if (IS_ENABLED(CONFIG_PROC_FS)) {
but that doesn't seem to help/work here.

gcc v4.8.5



-- 
~Randy

[PATCH -next] net/phy: fix phy_bcm_nsp_usb3.c build and kconfig

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

This driver uses mdio* (PHYLIB) interfaces, so it should select
PHYLIB. PHYLIB depends on NETDEVICES to this driver should also
depend on NETDEVICES.

Fixes these build errors:

drivers/built-in.o: In function `nsp_usb3_phy_init':
phy-bcm-nsp-usb3.c:(.text+0x42d8): undefined reference to `mdiobus_write'
phy-bcm-nsp-usb3.c:(.text+0x42f4): undefined reference to `mdiobus_write'
phy-bcm-nsp-usb3.c:(.text+0x4310): undefined reference to `mdiobus_write'
phy-bcm-nsp-usb3.c:(.text+0x432c): undefined reference to `mdiobus_write'
phy-bcm-nsp-usb3.c:(.text+0x4348): undefined reference to `mdiobus_write'
drivers/built-in.o:phy-bcm-nsp-usb3.c:(.text+0x437a): more undefined references 
to `mdiobus_write' follow
drivers/built-in.o: In function `mdio_module_init':
phy-bcm-nsp-usb3.c:(.init.text+0x1e1): undefined reference to 
`mdio_driver_register'
drivers/built-in.o: In function `mdio_module_exit':
phy-bcm-nsp-usb3.c:(.exit.text+0xae): undefined reference to 
`mdio_driver_unregister'

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: Yendapally Reddy Dhananjaya Reddy <yendapally.re...@broadcom.com>
---
 drivers/phy/Kconfig |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20170130.orig/drivers/phy/Kconfig
+++ linux-next-20170130/drivers/phy/Kconfig
@@ -504,8 +504,9 @@ config PHY_MESON8B_USB2
 
 config PHY_NSP_USB3
tristate "Broadcom NorthStar plus USB3 PHY driver"
-   depends on OF && (ARCH_BCM_NSP || COMPILE_TEST)
+   depends on OF && (ARCH_BCM_NSP || COMPILE_TEST) && NETDEVICES
select GENERIC_PHY
+   select PHYLIB
default ARCH_BCM_NSP
help
  Enable this to support the Broadcom Northstar plus USB3 PHY.

Re: [PATCH net-next] net: dsa: select NET_SWITCHDEV

[Randy Dunlap]

On 01/09/17 08:32, Vivien Didelot wrote:
> Hi Randy,
> 
> Randy Dunlap <rdun...@infradead.org> writes:
> 
>> On 01/08/17 17:18, Florian Fainelli wrote:
>>> On 01/08/2017 03:17 PM, Vivien Didelot wrote:
>>>> DSA wraps SWITCHDEV, thus select it instead of depending on it.
>>>>
>>>> Signed-off-by: Vivien Didelot <vivien.dide...@savoirfairelinux.com>
>>>
>>> Reviewed-by: Florian Fainelli <f.faine...@gmail.com>
>>>
>>
>> but when CONFIG_INET is not enabled, the patch causes this warning:
>>
>> warning: (NET_DSA) selects NET_SWITCHDEV which has unmet direct dependencies 
>> (NET && INET)
> 
> Thanks for spotting that! Would that be enough to change this first?
> 
> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index 675acbf1502d..c7263b70e72b 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -1,6 +1,6 @@
> config HAVE_NET_DSA
> def_bool y
> -   depends on NETDEVICES && !S390
> +   depends on INET && NETDEVICES && !S390
> 
> # Drivers must select NET_DSA and the appropriate tagging format

Yes, thanks.

Tested-by: Randy Dunlap <rdun...@infradead.org>


-- 
~Randy

Re: [PATCH net-next] net: dsa: select NET_SWITCHDEV

[Randy Dunlap]

On 01/08/17 17:18, Florian Fainelli wrote:
> On 01/08/2017 03:17 PM, Vivien Didelot wrote:
>> DSA wraps SWITCHDEV, thus select it instead of depending on it.
>>
>> Signed-off-by: Vivien Didelot 
> 
> Reviewed-by: Florian Fainelli 
> 

but when CONFIG_INET is not enabled, the patch causes this warning:

warning: (NET_DSA) selects NET_SWITCHDEV which has unmet direct dependencies 
(NET && INET)


-- 
~Randy

Re: linux-next: Tree for Dec 1 (ethernet/mellanox)

[Randy Dunlap]

On 11/30/16 22:42, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20161130:
> 

on i386:

when CONFIG_INET is not enabled:

drivers/built-in.o: In function `mlx5e_test_loopback':
en_selftest.c:(.text+0x690bde): undefined reference to `ip_send_check'
en_selftest.c:(.text+0x690c42): undefined reference to `udp4_hwcsum'


-- 
~Randy

[PATCH] netdevice.h: fix kernel-doc warning

[Randy Dunlap]

From: Randy Dunlap <rdun...@infradead.org>

Fix kernel-doc warning in  (missing ':'):

..//include/linux/netdevice.h:1904: warning: No description found for parameter 
'prio_tc_map[TC_BITMASK + 1]'

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
---
 include/linux/netdevice.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-49-rc6.orig/include/linux/netdevice.h
+++ lnx-49-rc6/include/linux/netdevice.h
@@ -1619,7 +1619,7 @@ enum netdev_priv_flags {
  * @dcbnl_ops: Data Center Bridging netlink ops
  * @num_tc:Number of traffic classes in the net device
  * @tc_to_txq: XXX: need comments on this one
- * @prio_tc_mapXXX: need comments on this one
+ * @prio_tc_map:   XXX: need comments on this one
  *
  * @fcoe_ddp_xid:  Max exchange id for FCoE LRO by ddp
  *

Re: linux-next: Tree for Nov 9 (netdev, netfilter v6)

[Randy Dunlap]

On 11/08/16 20:40, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20161108:
> 
> The drm-misc tree gained a build failure, so I used the version from
> next-20161108.
> 
> The sound-asoc tree still had its build failure, so I used the version
> from next-20161028.

(similar to yesterday, ipv6 instead of ipv4) on x86_64:

ERROR: "udp6_lib_lookup" [net/ipv6/netfilter/nf_socket_ipv6.ko] undefined!


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.9.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
CONFIG_IRQ_TIME_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
CONFIG_RCU_NOCB_CPU=y
# CONFIG_RCU_NOCB_CPU_NONE is not set
# CONFIG_RCU_NOCB_CPU_ZERO is not set
CONFIG_RCU_NOCB_CPU_ALL=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
# CONFIG_BLK_CGROUP is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
CONFIG_RD_LZ4=y
CONFIG_INITRAMFS_COMPRESSION=".lz4"
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set

Re: linux-next: Tree for Nov 8 (netdev, netfilter)

[Randy Dunlap]

On 11/07/16 23:38, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20161028:


on i386 or x86_64:

net/built-in.o: In function `nf_sk_lookup_slow_v4':
(.text+0x97414): undefined reference to `udp4_lib_lookup'

when these are not enabled:
#if IS_ENABLED(CONFIG_NETFILTER_XT_MATCH_SOCKET) || \
IS_ENABLED(CONFIG_NETFILTER_XT_TARGET_TPROXY)

and
CONFIG_NF_SOCKET_IPV4=y

See net/ipv4/netfilter/nf_socket_ipv4.c.


Reported-by: Randy Dunlap <rdun...@infradead.org>
-- 
~Randy

Re: Coding Style: Reverse XMAS tree declarations ? (was Re: [PATCH net-next v6 02/10] dpaa_eth: add support for DPAA Ethernet)

[Randy Dunlap]

On 11/03/16 23:53, Joe Perches wrote:
> On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
>> From: Madalin Bucur 
>> Date: Wed, 2 Nov 2016 22:17:26 +0200
>>
>>> This introduces the Freescale Data Path Acceleration Architecture
>>> +static inline size_t bpool_buffer_raw_size(u8 index, u8 cnt)
>>> +{
>>> + u8 i;
>>> + size_t res = DPAA_BP_RAW_SIZE / 2;
>>
>> Always order local variable declarations from longest to shortest line,
>> also know as Reverse Christmas Tree Format.
> 
> I think this declaration sorting order is misguided but
> here's a possible change to checkpatch adding a test for it
> that does this test just for net/ and drivers/net/

I agree with the misguided part.
That's not actually in CodingStyle AFAICT. Where did this come from?


thanks.
-- 
~Randy

Re: [net-next RFC v2 9/9] doc: Add LSM / BPF Checmate docs

[Randy Dunlap]

On 08/29/16 04:47, Sargun Dhillon wrote:
> This adds documentation on how to operate, and develop against the
> Checmate LSM and Cgroup controller.
> 
> Signed-off-by: Sargun Dhillon 
> ---
>  Documentation/security/Checmate.txt | 54 
> +
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/security/Checmate.txt
> 
> diff --git a/Documentation/security/Checmate.txt 
> b/Documentation/security/Checmate.txt
> new file mode 100644
> index 000..d409785
> --- /dev/null
> +++ b/Documentation/security/Checmate.txt
> @@ -0,0 +1,54 @@
> +--- What is Checmate? ---
> +
> +Checmate is a flexible programmable, extensible minor LSM that's coupled with
> +cgroups and BPF. It is designed to enforce container-specific policies. By
> +default, it does not enforce any policies. It is selectable at build time
> +with CONFIG_SECURITY_CHECMATE, and it is controlled through the unified 
> cgroups
> +controller hierarchy.
> +
> +# How to use Checmate
> +In order to use Checmate, you have to enable the controller on the cgroup2
> +hierarchy. In order to prevent a centralized configuration daemon from 
> mounting
> +Checmate on the V1 hierarchy you may want to add 'cgroup_no_v1=checmate' to 
> your
> +boot command line.
> +
> +Enabling the controller:
> + mount -t cgroup2 none $MOUNT_POINT
> + cd $MOUNT_POINT
> + echo +checmate > cgroup.subtree_control
> +
> +Once you do this, immediate children of this node on the hierarchy will have 
> a
> +number of control files that begin with 'checmate.'. Each of these is mapped
> +to an LSM hook by the same name. If you read the file, it will return the
> +number of filters attached to that given hook. Details of the hooks can be
> +found in lsm_hooks.h.
> +
> +All tasks which are members of a cgroup will have no only the checmate 
> filters

s/no/not/

> +at that level enforced, but all levels above as well. If there is a need
> +to exempt a specific sub-cgroup, a program can use current_task_under_cgroup
> +along with a bpf map.
> +
> +## Adding filters:
> +If you would like to add a filter, you must compile a BPF_PROG_TYPE_CHECMATE 
> BPF
> +program. You can then write the '%d\n' formatted version of the BPF program
> +file descriptor to the relevant control file.
> +
> +## Removing filters:
> +If you would like to remove a specific filter, you can write the negative 
> file
> +descriptor of the BPF program to the control file (a la '-%d\n'). If you 
> would
> +like to do this, then it is recommended that you pin your programs.
> +
> +If you would like to remove all filters from a specific hook, simply write 
> '0'
> +to the control file. During normal operation, you shouldn't have the bpf 
> syscall
> +return '0' for a given program, please take proper precautions to work around
> +this.
> +
> +# Caveats
> +## Hook Limit:
> +Each hook is limited to having MAX_CHECMATE_INSTANCES (32) hooks per level
> +in the hierarchy. The write call will return ENOSPC if you hit this 
> condition.
> +
> +## CGroup v2 interaction with CGroup v1:
> +Because the cgroups subsystem is in transition, using the net_prio or the
> +net_classid v1 cgroups will render Checmate inoperable on all network
> +hooks that inspect sockets.
> \ No newline at end of file



-- 
~Randy

Re: linux-next: Tree for Aug 16 (mellanox/mlx5 & sound/oss/)

[Randy Dunlap]

On 08/15/16 21:01, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160815:
> 

on i386:

sound/built-in.o:(.data+0x5c): multiple definition of `dev_list'
drivers/built-in.o:(.data+0x6aee8): first defined here
ld: Warning: size of symbol `dev_list' changed from 8 in drivers/built-in.o to 
16 in sound/built-in.o


sound/ is an old oss driver (soundcard.c):

struct oss_minor_dev {
unsigned short minor;
unsigned int enabled;
} dev_list[] = {
{ SND_DEV_DSP16 },
{ SND_DEV_AUDIO },
};

=

drivers/ is net/ethernet/mellanox/mlx5/core/mlx5_core.h:

extern struct list_head dev_list;




-- 
~Randy

Re: [PATCH] net: bfin_mac: Fix a few spelling fixes

[Randy Dunlap]

On 08/12/16 05:58, LABBE Corentin wrote:
> This patch respell some word badly spelled.
> - Invidate instead of Invalidate
> - proble instead of probe
> 
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/net/ethernet/adi/bfin_mac.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/adi/bfin_mac.c 
> b/drivers/net/ethernet/adi/bfin_mac.c
> index 38eaea1..00f9ee3 100644
> --- a/drivers/net/ethernet/adi/bfin_mac.c
> +++ b/drivers/net/ethernet/adi/bfin_mac.c
> @@ -192,8 +192,8 @@ static int desc_list_init(struct net_device *dev)
>   goto init_error;
>  
>   skb_reserve(new_skb, NET_IP_ALIGN);
> - /* Invidate the data cache of skb->data range when it is write 
> back
> -  * cache. It will prevent overwritting the new data from DMA
> + /* Invalidate the data cache of skb->data range when it is 
> write back
> +  * cache. It will prevent overwriting the new data from DMA
>*/
>   blackfin_dcache_invalidate_range((unsigned long)new_skb->head,
>(unsigned long)new_skb->end);
> @@ -1205,7 +1205,7 @@ static void bfin_mac_rx(struct bfin_mac_local *lp)
>   }
>   /* reserve 2 bytes for RXDWA padding */
>   skb_reserve(new_skb, NET_IP_ALIGN);
> - /* Invidate the data cache of skb->data range when it is write back
> + /* Invalidate the data cache of skb->data range when it is write back
>* cache. It will prevent overwritting the new data from DMA

  overwriting

>*/
>   blackfin_dcache_invalidate_range((unsigned long)new_skb->head,
> @@ -1599,7 +1599,7 @@ static int bfin_mac_probe(struct platform_device *pdev)
>   *(__le16 *) (&(ndev->dev_addr[4])) = cpu_to_le16((u16) 
> bfin_read_EMAC_ADDRHI());
>  
>   /* probe mac */
> - /*todo: how to proble? which is revision_register */
> + /*todo: how to probe? which is revision_register */
>   bfin_write_EMAC_ADDRLO(0x12345678);
>   if (bfin_read_EMAC_ADDRLO() != 0x12345678) {
>   dev_err(>dev, "Cannot detect Blackfin on-chip ethernet 
> MAC controller!\n");
> 


-- 
~Randy

Re: [RFC V2 PATCH 01/25] net: introduce NET policy

[Randy Dunlap]

On 08/04/16 12:36, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> This patch introduce NET policy subsystem. If proc is supported in the
> system, it creates netpolicy node in proc system.
> 
> Signed-off-by: Kan Liang 
> ---
>  include/linux/netdevice.h   |   7 +++
>  include/net/net_namespace.h |   3 ++
>  net/Kconfig |   7 +++
>  net/core/Makefile   |   1 +
>  net/core/netpolicy.c| 128 
> 
>  5 files changed, 146 insertions(+)
>  create mode 100644 net/core/netpolicy.c

> diff --git a/net/Kconfig b/net/Kconfig
> index c2cdbce..00552ba 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -205,6 +205,13 @@ source "net/bridge/netfilter/Kconfig"
>  
>  endif
>  
> +config NETPOLICY
> + depends on NET
> + bool "Net policy support"
> + default y
> + ---help---
> + Net policy support
> +

New kconfig options shouldn't default to y.


-- 
~Randy

Re: [RFC PATCH 30/30] Documentation/networking: Document net policy

[Randy Dunlap]

On 07/17/16 23:56, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> Signed-off-by: Kan Liang 
> ---
>  Documentation/networking/netpolicy.txt | 158 
> +
>  1 file changed, 158 insertions(+)
>  create mode 100644 Documentation/networking/netpolicy.txt
> 
> diff --git a/Documentation/networking/netpolicy.txt 
> b/Documentation/networking/netpolicy.txt
> new file mode 100644
> index 000..2ce938e
> --- /dev/null
> +++ b/Documentation/networking/netpolicy.txt
> @@ -0,0 +1,158 @@
> +What is Linux Net Policy?
> +
> +It is a big challenge to get good network performance. First, the network
> +performance is not good with default system settings. Second, it is too
> +difficult to do automatic tuning for all possible workloads, since workloads
> +have different requirements. Some workloads may want high throughput. Some 
> may
> +need low latency. Last but not least, there are lots of manual 
> configurations.
> +Fine grained configuration is too difficult for users.
> +
> +"NET policy" intends to simplify the network configuration and get a
> +good network performance according to the hints(policy) which is applied by
> +user. It provides some typical "policies" for user which can be set
> +per-socket, per-task or per-device. The kernel will automatically figures out

  drop:   will

> +how to merge different requests to get good network performance.
> +
> +"Net policy" is designed for multiqueue network devices. This document
> +describes the concepts and APIs of "net policy" support.
> +
> +NET POLICY CONCEPTS
> +
> +Scope of Net Policies
> +
> +Device net policy: this policy applies to the whole device. Once the
> +device net policy is set, it automatically configures the system
> +according to the applied policy. The configuration usually includes irq
> +affinity, irq balance disable, interrupt moderation, and so on. But the
> +device net policy does not change the packet direction.
> +
> +Task net policy: this is a per-task policy. When it is applied to 
> specific
> +task, all packets transmissions of the task will be redirect to the

 packetredirected

> +assigned queues accordingly. If a task does not define a task policy,
> +it "falls back" to the system default way to direct the packets. The
> +per-task policy must be compatible with device net policy.
> +
> +Socket net policy: this is a per-socket policy. When it is applied to
> +specific socket, all packets transmissions of the socket will be redirect

packet  
redirected

> +to the assigned queues accordingly. If a socket does not define a socket
> +policy, it "falls back" to the system default way to direct the packets.
> +The per-socket policy must be compatible with both device net policy and
> +per-task policy.
> +
> +Components of Net Policies
> +
> +Net policy object: it is a combination of cpu and queue. The queue irq 
> has
> +to set affinity with the cpu. It can be shared between sockets and tasks.
> +A reference counter is used to track the sharing number.

I would prefer to see CPU instead of cpu and IRQ instead of irq throughout the 
file.

> +
> +Net policy object list: each device policy has an object list. Once the
> +device policy is determined, the net policy object will be inserted into
> +the net policy object list. The net policy object list does not change
> +unless the cpu/queue number is changed, the netpolicy is disabled or
> +the device policy is changed.
> +The network performance for objects could be different because of the
> +queue/cpu topology and dev location. The objects which can bring high
> +performance are in the front of the list.
> +
> +RCU hash table: a RCU hash table to maintain the relationship between

   an RCU

> +the task/socket and the assigned object. The task/socket can get the
> +assigned object by searching the table.
> +If it is the first time, there is no assigned object in the table. It 
> will
> +go through the object list to find the available object based on position
> +and reference number.
> +If the net policy object list changes, all the assigned object will 
> become

   objects

> +invalid.
> +
> +NET POLICY APIs
> +
> +Interfaces between net policy and device driver
> +
> +int (*ndo_netpolicy_init)(struct net_device *dev,
> +  struct netpolicy_info *info);
> +
> +The device driver who has NET policy support must implement this 
> interface.
> +In this interface, the device driver do necessory initialization, and 
> fill

does necessary

> +the info for net 

Re: [patch net-next 2/2] devlink: fix trace format string

[Randy Dunlap]

On 07/14/16 02:37, Jiri Pirko wrote:
> From: Arnd Bergmann <a...@arndb.de>
> 
> Including devlink.h on ARM and probably other 32-bit architectures results in
> a harmless warning:
> 
> In file included from ../include/trace/define_trace.h:95:0,
>  from ../include/trace/events/devlink.h:51,
>  from ../net/core/devlink.c:30:
> include/trace/events/devlink.h: In function 'trace_raw_output_devlink_hwmsg':
> include/trace/events/devlink.h:42:12: error: format '%lu' expects argument of 
> type 'long unsigned int', but argument 10 has type 'size_t {aka unsigned 
> int}' [-Werror=format=]
> 
> The correct format string for 'size_t' is %zu, not %lu, this works on all
> architectures.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: e5224f0fe2ac ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko <j...@mellanox.com>

Acked-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  include/trace/events/devlink.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/trace/events/devlink.h b/include/trace/events/devlink.h
> index 77dce71..09f1df2 100644
> --- a/include/trace/events/devlink.h
> +++ b/include/trace/events/devlink.h
> @@ -39,7 +39,7 @@ TRACE_EVENT(devlink_hwmsg,
>   __entry->len = len;
>   ),
>  
> - TP_printk("bus_name=%s dev_name=%s driver_name=%s incoming=%d type=%lu 
> buf=0x[%*phD] len=%lu",
> + TP_printk("bus_name=%s dev_name=%s driver_name=%s incoming=%d type=%lu 
> buf=0x[%*phD] len=%zu",
> __get_str(bus_name), __get_str(dev_name),
> __get_str(driver_name), __entry->incoming, __entry->type,
> (int) __entry->len, __get_dynamic_array(buf), __entry->len)
> 


-- 
~Randy

Re: [patch net-next 1/2] tracing: change owner name to driver name for devlink hwmsg tracepoint

[Randy Dunlap]

On 07/14/16 02:37, Jiri Pirko wrote:
> From: Jiri Pirko <j...@mellanox.com>
> 
> Turned on that driver->owner which is struct module is not available when
> modules are disabled. Better to depend on a driver name which is
> always available.
> 
> Reported-by: Randy Dunlap <rdun...@infradead.org>
> Fixes: e5224f0fe2 ("devlink: add hardware messages tracing facility")
> Signed-off-by: Jiri Pirko <j...@mellanox.com>

Acked-by: Randy Dunlap <rdun...@infradead.org>

Thanks.

> ---
>  include/trace/events/devlink.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/include/trace/events/devlink.h b/include/trace/events/devlink.h
> index 333c32a..77dce71 100644
> --- a/include/trace/events/devlink.h
> +++ b/include/trace/events/devlink.h
> @@ -22,7 +22,7 @@ TRACE_EVENT(devlink_hwmsg,
>   TP_STRUCT__entry(
>   __string(bus_name, devlink->dev->bus->name)
>   __string(dev_name, dev_name(devlink->dev))
> - __string(owner_name, devlink->dev->driver->owner->name)
> + __string(driver_name, devlink->dev->driver->name)
>   __field(bool, incoming)
>   __field(unsigned long, type)
>   __dynamic_array(u8, buf, len)
> @@ -32,16 +32,16 @@ TRACE_EVENT(devlink_hwmsg,
>   TP_fast_assign(
>   __assign_str(bus_name, devlink->dev->bus->name);
>   __assign_str(dev_name, dev_name(devlink->dev));
> - __assign_str(owner_name, devlink->dev->driver->owner->name);
> + __assign_str(driver_name, devlink->dev->driver->name);
>   __entry->incoming = incoming;
>   __entry->type = type;
>   memcpy(__get_dynamic_array(buf), buf, len);
>   __entry->len = len;
>   ),
>  
> - TP_printk("bus_name=%s dev_name=%s owner_name=%s incoming=%d type=%lu 
> buf=0x[%*phD] len=%lu",
> + TP_printk("bus_name=%s dev_name=%s driver_name=%s incoming=%d type=%lu 
> buf=0x[%*phD] len=%lu",
> __get_str(bus_name), __get_str(dev_name),
> -   __get_str(owner_name), __entry->incoming, __entry->type,
> +   __get_str(driver_name), __entry->incoming, __entry->type,
> (int) __entry->len, __get_dynamic_array(buf), __entry->len)
>  );
>  
> 


-- 
~Randy

Re: linux-next: Tree for Jul 13 (net/core/devlink with Tracing)

[Randy Dunlap]

On 07/12/16 23:47, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160712:
> 

on x86_64:
(full randconfig file is attached)


  CC  net/core/devlink.o
In file included from ../include/trace/define_trace.h:95:0,
 from ../include/trace/events/devlink.h:51,
 from ../net/core/devlink.c:30:
../include/trace/events/devlink.h: In function 
'trace_event_get_offsets_devlink_hwmsg':
../include/trace/events/devlink.h:25:51: error: dereferencing pointer to 
incomplete type
   __string(owner_name, devlink->dev->driver->owner->name)
   ^
../include/trace/trace_events.h:501:2: note: in definition of macro 
'DECLARE_EVENT_CLASS'
  tstruct;   \
  ^
../include/trace/trace_events.h:63:9: note: in expansion of macro 'PARAMS'
 PARAMS(tstruct), \
 ^
../include/trace/events/devlink.h:16:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(devlink_hwmsg,
 ^
../include/trace/events/devlink.h:22:2: note: in expansion of macro 
'TP_STRUCT__entry'
  TP_STRUCT__entry(
  ^
../include/trace/trace_events.h:466:29: note: in expansion of macro 
'__dynamic_array'
 #define __string(item, src) __dynamic_array(char, item,   \
 ^
../include/trace/events/devlink.h:25:3: note: in expansion of macro '__string'
   __string(owner_name, devlink->dev->driver->owner->name)
   ^
../include/trace/events/devlink.h:25:51: error: dereferencing pointer to 
incomplete type
   __string(owner_name, devlink->dev->driver->owner->name)
   ^
../include/trace/trace_events.h:501:2: note: in definition of macro 
'DECLARE_EVENT_CLASS'
  tstruct;   \
  ^
../include/trace/trace_events.h:63:9: note: in expansion of macro 'PARAMS'
 PARAMS(tstruct), \
 ^
../include/trace/events/devlink.h:16:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(devlink_hwmsg,
 ^
../include/trace/events/devlink.h:22:2: note: in expansion of macro 
'TP_STRUCT__entry'
  TP_STRUCT__entry(
  ^
../include/trace/trace_events.h:466:29: note: in expansion of macro 
'__dynamic_array'
 #define __string(item, src) __dynamic_array(char, item,   \
 ^
../include/trace/events/devlink.h:25:3: note: in expansion of macro '__string'
   __string(owner_name, devlink->dev->driver->owner->name)
   ^
In file included from ../include/trace/define_trace.h:95:0,
 from ../include/trace/events/devlink.h:51,
 from ../net/core/devlink.c:30:
../include/trace/events/devlink.h: In function 
'trace_event_raw_event_devlink_hwmsg':
../include/trace/events/devlink.h:35:55: error: dereferencing pointer to 
incomplete type
   __assign_str(owner_name, devlink->dev->driver->owner->name);
   ^
../include/trace/trace_events.h:686:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
  { assign; }   \
^
../include/trace/trace_events.h:64:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
../include/trace/events/devlink.h:16:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(devlink_hwmsg,
 ^
../include/trace/events/devlink.h:32:2: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
../include/trace/events/devlink.h:35:3: note: in expansion of macro 
'__assign_str'
   __assign_str(owner_name, devlink->dev->driver->owner->name);
   ^
../include/trace/events/devlink.h:35:55: error: dereferencing pointer to 
incomplete type
   __assign_str(owner_name, devlink->dev->driver->owner->name);
   ^
../include/trace/trace_events.h:686:4: note: in definition of macro 
'DECLARE_EVENT_CLASS'
  { assign; }   \
^
../include/trace/trace_events.h:64:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^
../include/trace/events/devlink.h:16:1: note: in expansion of macro 
'TRACE_EVENT'
 TRACE_EVENT(devlink_hwmsg,
 ^
../include/trace/events/devlink.h:32:2: note: in expansion of macro 
'TP_fast_assign'
  TP_fast_assign(
  ^
../include/trace/events/devlink.h:35:3: note: in expansion of macro 
'__assign_str'
   __assign_str(owner_name, devlink->dev->driver->owner->name);
   ^
In file included from ../include/trace/define_trace.h:96:0,
 from ../include/trace/events/devlink.h:51,
 from ../net/core/devlink.c:30:
../include/trace/events/devlink.h: In function 'perf_trace_devlink_hwmsg':
../include/trace/events/devlink.h:35:55: error: dereferencing pointer to 
incomplete type
   __assign_str(owner_name, devlink->dev->driver->owner->name);
   ^
../include/trace/perf.h:65:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
  { assign; }   \
^
../include/trace/trace_events.h:64:9: note: in expansion of macro 'PARAMS'
 PARAMS(assign), \
 ^

Re: [PATCH] of_mdio: select fixed phy support unconditionally

[Randy Dunlap]

On 06/24/16 02:24, Arnd Bergmann wrote:
> Calling the fixed-phy functions when CONFIG_FIXED_PHY=m as a previous
> change tried cannot work if the caller is in built-in code:
> 
> drivers/of/built-in.o: In function `of_phy_register_fixed_link':
> of_reserved_mem.c:(.text+0x85e0): undefined reference to `fixed_phy_register'
> 
> Making of_mdio depend on 'FIXED_PHY || !FIXED_PHY' would solve this
> dependency by enforcing that OF_MDIO itself becomes a loadable module
> when FIXED_PHY=y, but that creates a different dependency as it
> breaks any built-in ethernet driver that uses of_mdio.
> 
> Making FIXED_PHY a bool option also cannot work, since it depends on
> PHYLIB, which again is tristate.
> 
> This version now uses 'select FIXED_PHY' to ensure that the fixed-phy
> portion of of_mdio is not optional. The main downside of this is
> a small increase in code size for cases that do not need fixed phy
> support, but it should avoid all of the link-time problems.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: d1bd330a229f ("of_mdio: Enable fixed PHY support if driver is a 
> module")

Fixes the build errors that I was seeing.  Thanks.

Acked-by: Randy Dunlap <rdun...@infradead.org>


> ---
>  drivers/of/Kconfig  | 1 +
>  drivers/of/of_mdio.c| 2 --
>  include/linux/of_mdio.h | 8 ++--
>  3 files changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index b3bec3aaa45d..bc07ad30c9bf 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -74,6 +74,7 @@ config OF_NET
>  config OF_MDIO
>   def_tristate PHYLIB
>   depends on PHYLIB
> + select FIXED_PHY
>   help
> OpenFirmware MDIO bus (Ethernet PHY) accessors
>  
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index de68707a99c7..e2b50bc12f23 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -361,7 +361,6 @@ struct phy_device *of_phy_attach(struct net_device *dev,
>  }
>  EXPORT_SYMBOL(of_phy_attach);
>  
> -#if IS_ENABLED(CONFIG_FIXED_PHY)
>  /*
>   * of_phy_is_fixed_link() and of_phy_register_fixed_link() must
>   * support two DT bindings:
> @@ -451,4 +450,3 @@ int of_phy_register_fixed_link(struct device_node *np)
>   return -ENODEV;
>  }
>  EXPORT_SYMBOL(of_phy_register_fixed_link);
> -#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 6c8cb9aa4c00..4b04587d0441 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -25,6 +25,8 @@ struct phy_device *of_phy_attach(struct net_device *dev,
>  
>  extern struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np);
>  extern int of_mdio_parse_addr(struct device *dev, const struct device_node 
> *np);
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +extern bool of_phy_is_fixed_link(struct device_node *np);
>  
>  #else /* CONFIG_OF */
>  static inline int of_mdiobus_register(struct mii_bus *mdio, struct 
> device_node *np)
> @@ -67,12 +69,6 @@ static inline int of_mdio_parse_addr(struct device *dev,
>  {
>   return -ENOSYS;
>  }
> -#endif /* CONFIG_OF */
> -
> -#if defined(CONFIG_OF) && IS_ENABLED(CONFIG_FIXED_PHY)
> -extern int of_phy_register_fixed_link(struct device_node *np);
> -extern bool of_phy_is_fixed_link(struct device_node *np);
> -#else
>  static inline int of_phy_register_fixed_link(struct device_node *np)
>  {
>   return -ENOSYS;
> 


-- 
~Randy

Re: Regarding VRF support in Linux Kernel

[Randy Dunlap]

On 06/22/16 14:05, Ajith Adapa wrote:
> Hi,
> 
> I am following the steps present in
> (https://www.kernel.org/doc/Documentation/networking/vrf.txt) and
> trying to create IPv4 VRF in latest Fedora 24 distribution with 4.5
> Linux kernel.
> 
> [root@localhost ip]# uname -a
> Linux localhost.localdomain 4.5.5-300.fc24.x86_64 #1 SMP Thu May 19
> 13:05:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> I am getting operation not supported error as shown below
> 
> # ip link add vrf-blue type vrf table 10
> RTNETLINK answers: Operation not supported
> 
> Is there any CONFIG option to enable VRF in Linux kernel ?

Yes, in drivers/net/Kconfig:

config NET_VRF
tristate "Virtual Routing and Forwarding (Lite)"
depends on IP_MULTIPLE_TABLES
depends on NET_L3_MASTER_DEV
depends on IPV6 || IPV6=n
depends on IPV6_MULTIPLE_TABLES || IPV6=n
---help---
  This option enables the support for mapping interfaces into VRF's. The
  support enables VRF devices.




-- 
~Randy

Re: linux-next: Tree for Mar 21 (openvswitch)

[Randy Dunlap]

On 03/20/16 21:13, Stephen Rothwell wrote:
> Hi all,
> 
> Please do not add any v4.7 related material to your linux-next included
> trees until after v4.6-rc1 is released.
> 
> Changes since 20160318:
> 

on i386:

ERROR: "nf_nat_icmp_reply_translation" [net/openvswitch/openvswitch.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.5.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
# CONFIG_MEMCG is not set
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
# CONFIG_PROC_PID_CPUSET is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_PERF=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
CONFIG_RD_LZO=y
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_ABSOLUTE_PERCPU is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
# CONFIG_FUTEX is not set
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not 

Re: linux-next: Tree for Mar 9 (net: bpf)

[Randy Dunlap]

On 03/09/16 09:07, Randy Dunlap wrote:
> On 03/09/16 08:48, Daniel Borkmann wrote:
>> On 03/09/2016 05:44 PM, Randy Dunlap wrote:
>>> On 03/08/16 21:38, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20160308:
>>>
>>> on x86_64:
>>>
>>> ../net/core/filter.c: In function 'bpf_skb_get_tunnel_opt':
>>> ../net/core/filter.c:1824:2: error: implicit declaration of function 
>>> 'ip_tunnel_info_opts_get' [-Werror=implicit-function-declaration]
>>>ip_tunnel_info_opts_get(to, info);
>>>^
>>> ../net/core/filter.c: In function 'bpf_skb_set_tunnel_opt':
>>> ../net/core/filter.c:1918:2: error: implicit declaration of function 
>>> 'ip_tunnel_info_opts_set' [-Werror=implicit-function-declaration]
>>>ip_tunnel_info_opts_set(info, from, size);
>>>^
>>> Full randconfig file is attached.
>>
>> Already fixed with net-next commit e28e87ed474c ("ip_tunnel, bpf:
>> ip_tunnel_info_opts_{get, set} depends on CONFIG_INET").
>>
>> Thanks,
>> Daniel
>>
> 
> Hi Daniel,
> 
> Is that patch on the netdev mailing list or patchwork?
> I can't find it.
> 
> Does it handle where net/Kconfig symbol NET selects BPF unconditionally?

I got the patch from git and tested it.  Works.  Thanks.



-- 
~Randy

Re: linux-next: Tree for Mar 9 (net: bpf)

[Randy Dunlap]

On 03/09/16 08:48, Daniel Borkmann wrote:
> On 03/09/2016 05:44 PM, Randy Dunlap wrote:
>> On 03/08/16 21:38, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20160308:
>>
>> on x86_64:
>>
>> ../net/core/filter.c: In function 'bpf_skb_get_tunnel_opt':
>> ../net/core/filter.c:1824:2: error: implicit declaration of function 
>> 'ip_tunnel_info_opts_get' [-Werror=implicit-function-declaration]
>>ip_tunnel_info_opts_get(to, info);
>>^
>> ../net/core/filter.c: In function 'bpf_skb_set_tunnel_opt':
>> ../net/core/filter.c:1918:2: error: implicit declaration of function 
>> 'ip_tunnel_info_opts_set' [-Werror=implicit-function-declaration]
>>ip_tunnel_info_opts_set(info, from, size);
>>^
>> Full randconfig file is attached.
> 
> Already fixed with net-next commit e28e87ed474c ("ip_tunnel, bpf:
> ip_tunnel_info_opts_{get, set} depends on CONFIG_INET").
> 
> Thanks,
> Daniel
> 

Hi Daniel,

Is that patch on the netdev mailing list or patchwork?
I can't find it.

Does it handle where net/Kconfig symbol NET selects BPF unconditionally?

thanks,
-- 
~Randy

Re: linux-next: Tree for Mar 9 (net: bpf)

[Randy Dunlap]

On 03/08/16 21:38, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160308:
> 

on x86_64:

../net/core/filter.c: In function 'bpf_skb_get_tunnel_opt':
../net/core/filter.c:1824:2: error: implicit declaration of function 
'ip_tunnel_info_opts_get' [-Werror=implicit-function-declaration]
  ip_tunnel_info_opts_get(to, info);
  ^
../net/core/filter.c: In function 'bpf_skb_set_tunnel_opt':
../net/core/filter.c:1918:2: error: implicit declaration of function 
'ip_tunnel_info_opts_set' [-Werror=implicit-function-declaration]
  ip_tunnel_info_opts_set(info, from, size);
  ^


Full randconfig file is attached.


-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc7 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_CGROUP_PIDS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

Re: linux-next: Tree for Dec 31 (net/xfrm/xfrm_input.c)

[Randy Dunlap]

On 12/31/15 04:30, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20151223:
> 


seen on i386 or x86_64:

In file included from ../net/xfrm/xfrm_input.c:17:0:
../include/net/ip6_tunnel.h: In function 'ip6tunnel_xmit':
../include/net/ip6_tunnel.h:93:2: error: implicit declaration of function 
'iptunnel_xmit_stats' [-Werror=implicit-function-declaration]
  iptunnel_xmit_stats(dev, pkt_len);
  ^



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html