* Re: [PATCH] perf cs-etm: Improve completeness for kernel address space
From: Arnaldo Carvalho de Melo @ 2019-06-24 19:00 UTC (permalink / raw)
To: Leo Yan
Cc: Mathieu Poirier, Linux Kernel Mailing List, linux-arm-kernel,
netdev, bpf, Alexander Shishkin, Jiri Olsa, Namhyung Kim,
Peter Zijlstra, Suzuki Poulouse, Coresight ML
In-Reply-To: <20190620005829.GH24549@leoy-ThinkPad-X240s>
Em Thu, Jun 20, 2019 at 08:58:29AM +0800, Leo Yan escreveu:
> Hi Mathieu,
>
> On Wed, Jun 19, 2019 at 11:49:44AM -0600, Mathieu Poirier wrote:
>
> [...]
>
> > > diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> > > index 51dd00f65709..4776c2c1fb6d 100644
> > > --- a/tools/perf/Makefile.config
> > > +++ b/tools/perf/Makefile.config
> > > @@ -418,6 +418,30 @@ ifdef CORESIGHT
> > > endif
> > > LDFLAGS += $(LIBOPENCSD_LDFLAGS)
> > > EXTLIBS += $(OPENCSDLIBS)
> > > + ifneq ($(wildcard $(srctree)/arch/arm64/kernel/vmlinux.lds),)
> > > + # Extract info from lds:
> > > + # . = ((((((((0xffffffffffffffff)) - (((1)) << (48)) + 1) + (0)) + (0x08000000))) + (0x08000000))) + 0x00080000;
> > > + # ARM64_PRE_START_SIZE := (0x08000000 + 0x08000000 + 0x00080000)
> > > + ARM64_PRE_START_SIZE := $(shell egrep ' \. \= \({8}0x[0-9a-fA-F]+\){2}' \
> > > + $(srctree)/arch/arm64/kernel/vmlinux.lds | \
> > > + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
> > > + awk -F' ' '{print "("$$6 "+" $$7 "+" $$8")"}' 2>/dev/null)
> > > + else
> > > + ARM64_PRE_START_SIZE := 0
> > > + endif
> > > + CFLAGS += -DARM64_PRE_START_SIZE="$(ARM64_PRE_START_SIZE)"
> > > + ifneq ($(wildcard $(srctree)/arch/arm/kernel/vmlinux.lds),)
> > > + # Extract info from lds:
> > > + # . = ((0xC0000000)) + 0x00208000;
> > > + # ARM_PRE_START_SIZE := 0x00208000
> > > + ARM_PRE_START_SIZE := $(shell egrep ' \. \= \({2}0x[0-9a-fA-F]+\){2}' \
> > > + $(srctree)/arch/arm/kernel/vmlinux.lds | \
> > > + sed -e 's/[(|)|.|=|+|<|;|-]//g' -e 's/ \+/ /g' -e 's/^[ \t]*//' | \
> > > + awk -F' ' '{print "("$$2")"}' 2>/dev/null)
> > > + else
> > > + ARM_PRE_START_SIZE := 0
> > > + endif
> > > + CFLAGS += -DARM_PRE_START_SIZE="$(ARM_PRE_START_SIZE)"
> > > $(call detected,CONFIG_LIBOPENCSD)
> > > ifdef CSTRACE_RAW
> > > CFLAGS += -DCS_DEBUG_RAW
> > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > index 0c7776b51045..ae831f836c70 100644
> > > --- a/tools/perf/util/cs-etm.c
> > > +++ b/tools/perf/util/cs-etm.c
> > > @@ -613,10 +613,34 @@ static void cs_etm__free(struct perf_session *session)
> > > static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
> > > {
> > > struct machine *machine;
> > > + u64 fixup_kernel_start = 0;
> > > + const char *arch;
> > >
> > > machine = etmq->etm->machine;
> > > + arch = perf_env__arch(machine->env);
> > >
> > > - if (address >= etmq->etm->kernel_start) {
> > > + /*
> > > + * Since arm and arm64 specify some memory regions prior to
> > > + * 'kernel_start', kernel addresses can be less than 'kernel_start'.
> > > + *
> > > + * For arm architecture, the 16MB virtual memory space prior to
> > > + * 'kernel_start' is allocated to device modules, a PMD table if
> > > + * CONFIG_HIGHMEM is enabled and a PGD table.
> > > + *
> > > + * For arm64 architecture, the root PGD table, device module memory
> > > + * region and BPF jit region are prior to 'kernel_start'.
> > > + *
> > > + * To reflect the complete kernel address space, compensate these
> > > + * pre-defined regions for kernel start address.
> > > + */
> > > + if (!strcmp(arch, "arm64"))
> > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > + ARM64_PRE_START_SIZE;
> > > + else if (!strcmp(arch, "arm"))
> > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > + ARM_PRE_START_SIZE;
> >
> > I will test your work but from a quick look wouldn't it be better to
> > have a single define name here? From looking at the modifications you
> > did to Makefile.config there doesn't seem to be a reason to have two.
>
> Thanks for suggestion. I changed to use single define
> ARM_PRE_START_SIZE and sent patch v2 [1].
>
> If possible, please test patch v2.
>
> Thanks,
> Leo Yan
So just for the record, I'm waiting for Mathieu on this one, i.e. for
him to test/ack v3.
- Arnaldo
> [1] https://lore.kernel.org/linux-arm-kernel/20190620005428.20883-1-leo.yan@linaro.org/T/#u
>
> > > +
> > > + if (address >= fixup_kernel_start) {
> > > if (machine__is_host(machine))
> > > return PERF_RECORD_MISC_KERNEL;
> > > else
> > > --
> > > 2.17.1
> > >
--
- Arnaldo
^ permalink raw reply
* Re: [PATCH net-next v2] hinic: implement the statistical interface of ethtool
From: Jakub Kicinski @ 2019-06-24 19:05 UTC (permalink / raw)
To: Xue Chaojing, davem
Cc: linux-kernel, netdev, luoshaokai, cloud.wangxiaoyun, chiqijun,
wulike1, Stephen Hemminger
In-Reply-To: <20190624035012.7221-1-xuechaojing@huawei.com>
On Mon, 24 Jun 2019 03:50:12 +0000, Xue Chaojing wrote:
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> index be28a9a7f033..8d98f37c88a8 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
> @@ -438,6 +438,344 @@ static u32 hinic_get_rxfh_indir_size(struct net_device *netdev)
> return HINIC_RSS_INDIR_SIZE;
> }
>
> +#define ARRAY_LEN(arr) ((int)((int)sizeof(arr) / (int)sizeof(arr[0])))
> +
> +#define HINIC_NETDEV_STAT(_stat_item) { \
> + .name = #_stat_item, \
> + .size = FIELD_SIZEOF(struct rtnl_link_stats64, _stat_item), \
> + .offset = offsetof(struct rtnl_link_stats64, _stat_item) \
> +}
> +
> +static struct hinic_stats hinic_netdev_stats[] = {
> + HINIC_NETDEV_STAT(rx_packets),
> + HINIC_NETDEV_STAT(tx_packets),
> + HINIC_NETDEV_STAT(rx_bytes),
> + HINIC_NETDEV_STAT(tx_bytes),
> + HINIC_NETDEV_STAT(rx_errors),
> + HINIC_NETDEV_STAT(tx_errors),
> + HINIC_NETDEV_STAT(rx_dropped),
> + HINIC_NETDEV_STAT(tx_dropped),
> + HINIC_NETDEV_STAT(multicast),
> + HINIC_NETDEV_STAT(collisions),
> + HINIC_NETDEV_STAT(rx_length_errors),
> + HINIC_NETDEV_STAT(rx_over_errors),
> + HINIC_NETDEV_STAT(rx_crc_errors),
> + HINIC_NETDEV_STAT(rx_frame_errors),
> + HINIC_NETDEV_STAT(rx_fifo_errors),
> + HINIC_NETDEV_STAT(rx_missed_errors),
> + HINIC_NETDEV_STAT(tx_aborted_errors),
> + HINIC_NETDEV_STAT(tx_carrier_errors),
> + HINIC_NETDEV_STAT(tx_fifo_errors),
> + HINIC_NETDEV_STAT(tx_heartbeat_errors),
> +};
I think we wanted to stop duplicating standard netdev stats in ethtool
-S. Chaojing please post a patch to remove this part, the other stats
are good.
^ permalink raw reply
* Re: [PATCH V2 03/15] ARM: ep93xx: cleanup cppcheck shifting errors
From: Alexander Sverdlin @ 2019-06-24 19:16 UTC (permalink / raw)
To: Phong Tran
Cc: acme, alexander.shishkin, allison, andrew, ast, bgolaszewski, bpf,
daniel, daniel, dmg, festevam, gerg, gregkh, gregory.clement,
haojian.zhuang, hsweeten, illusionist.neo, info, jason, jolsa,
kafai, kernel, kgene, krzk, kstewart, linux-arm-kernel, linux-imx,
linux-kernel, linux-omap, linux-samsung-soc, linux, liviu.dudau,
lkundrak, lorenzo.pieralisi, mark.rutland, mingo, namhyung,
netdev, nsekhar, peterz, robert.jarzmik, s.hauer,
sebastian.hesselbarth, shawnguo, songliubraving, sudeep.holla,
swinslow, tglx, tony, will, yhs
In-Reply-To: <20190624135105.15579-4-tranmanphong@gmail.com>
Hi!
On 24/06/2019 15:50, Phong Tran wrote:
> [arch/arm/mach-ep93xx/clock.c:102]: (error) Shifting signed 32-bit value
> by 31 bits is undefined behaviour
> [arch/arm/mach-ep93xx/clock.c:132]: (error) Shifting signed 32-bit value
> by 31 bits is undefined behaviour
> [arch/arm/mach-ep93xx/clock.c:140]: (error) Shifting signed 32-bit value
> by 31 bits is undefined behaviour
> [arch/arm/mach-ep93xx/core.c:1001]: (error) Shifting signed 32-bit value
> by 31 bits is undefined behaviour
> [arch/arm/mach-ep93xx/core.c:1002]: (error) Shifting signed 32-bit value
> by 31 bits is undefined behaviour
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> arch/arm/mach-ep93xx/soc.h | 132 ++++++++++++++++++++++-----------------------
> 1 file changed, 66 insertions(+), 66 deletions(-)
>
> diff --git a/arch/arm/mach-ep93xx/soc.h b/arch/arm/mach-ep93xx/soc.h
> index f2dace1c9154..250c82f8b0a1 100644
> --- a/arch/arm/mach-ep93xx/soc.h
> +++ b/arch/arm/mach-ep93xx/soc.h
> @@ -109,89 +109,89 @@
> #define EP93XX_SYSCON_REG(x) (EP93XX_SYSCON_BASE + (x))
> #define EP93XX_SYSCON_POWER_STATE EP93XX_SYSCON_REG(0x00)
> #define EP93XX_SYSCON_PWRCNT EP93XX_SYSCON_REG(0x04)
> -#define EP93XX_SYSCON_PWRCNT_FIR_EN (1<<31)
> -#define EP93XX_SYSCON_PWRCNT_UARTBAUD (1<<29)
> -#define EP93XX_SYSCON_PWRCNT_USH_EN (1<<28)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2M1 (1<<27)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2M0 (1<<26)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P8 (1<<25)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P9 (1<<24)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P6 (1<<23)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P7 (1<<22)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P4 (1<<21)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P5 (1<<20)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P2 (1<<19)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P3 (1<<18)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P0 (1<<17)
> -#define EP93XX_SYSCON_PWRCNT_DMA_M2P1 (1<<16)
> +#define EP93XX_SYSCON_PWRCNT_FIR_EN BIT(31)
> +#define EP93XX_SYSCON_PWRCNT_UARTBAUD BIT(29)
> +#define EP93XX_SYSCON_PWRCNT_USH_EN BIT(28)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2M1 BIT(27)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2M0 BIT(26)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P8 BIT(25)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P9 BIT(24)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P6 BIT(23)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P7 BIT(22)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P4 BIT(21)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P5 BIT(20)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P2 BIT(19)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P3 BIT(18)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P0 BIT(17)
> +#define EP93XX_SYSCON_PWRCNT_DMA_M2P1 BIT(16)
> #define EP93XX_SYSCON_HALT EP93XX_SYSCON_REG(0x08)
> #define EP93XX_SYSCON_STANDBY EP93XX_SYSCON_REG(0x0c)
> #define EP93XX_SYSCON_CLKSET1 EP93XX_SYSCON_REG(0x20)
> -#define EP93XX_SYSCON_CLKSET1_NBYP1 (1<<23)
> +#define EP93XX_SYSCON_CLKSET1_NBYP1 BIT(23)
> #define EP93XX_SYSCON_CLKSET2 EP93XX_SYSCON_REG(0x24)
> -#define EP93XX_SYSCON_CLKSET2_NBYP2 (1<<19)
> -#define EP93XX_SYSCON_CLKSET2_PLL2_EN (1<<18)
> +#define EP93XX_SYSCON_CLKSET2_NBYP2 BIT(19)
> +#define EP93XX_SYSCON_CLKSET2_PLL2_EN BIT(18)
> #define EP93XX_SYSCON_DEVCFG EP93XX_SYSCON_REG(0x80)
> -#define EP93XX_SYSCON_DEVCFG_SWRST (1<<31)
> -#define EP93XX_SYSCON_DEVCFG_D1ONG (1<<30)
> -#define EP93XX_SYSCON_DEVCFG_D0ONG (1<<29)
> -#define EP93XX_SYSCON_DEVCFG_IONU2 (1<<28)
> -#define EP93XX_SYSCON_DEVCFG_GONK (1<<27)
> -#define EP93XX_SYSCON_DEVCFG_TONG (1<<26)
> -#define EP93XX_SYSCON_DEVCFG_MONG (1<<25)
> -#define EP93XX_SYSCON_DEVCFG_U3EN (1<<24)
> -#define EP93XX_SYSCON_DEVCFG_CPENA (1<<23)
> -#define EP93XX_SYSCON_DEVCFG_A2ONG (1<<22)
> -#define EP93XX_SYSCON_DEVCFG_A1ONG (1<<21)
> -#define EP93XX_SYSCON_DEVCFG_U2EN (1<<20)
> -#define EP93XX_SYSCON_DEVCFG_EXVC (1<<19)
> -#define EP93XX_SYSCON_DEVCFG_U1EN (1<<18)
> -#define EP93XX_SYSCON_DEVCFG_TIN (1<<17)
> -#define EP93XX_SYSCON_DEVCFG_HC3IN (1<<15)
> -#define EP93XX_SYSCON_DEVCFG_HC3EN (1<<14)
> -#define EP93XX_SYSCON_DEVCFG_HC1IN (1<<13)
> -#define EP93XX_SYSCON_DEVCFG_HC1EN (1<<12)
> -#define EP93XX_SYSCON_DEVCFG_HONIDE (1<<11)
> -#define EP93XX_SYSCON_DEVCFG_GONIDE (1<<10)
> -#define EP93XX_SYSCON_DEVCFG_PONG (1<<9)
> -#define EP93XX_SYSCON_DEVCFG_EONIDE (1<<8)
> -#define EP93XX_SYSCON_DEVCFG_I2SONSSP (1<<7)
> -#define EP93XX_SYSCON_DEVCFG_I2SONAC97 (1<<6)
> -#define EP93XX_SYSCON_DEVCFG_RASONP3 (1<<4)
> -#define EP93XX_SYSCON_DEVCFG_RAS (1<<3)
> -#define EP93XX_SYSCON_DEVCFG_ADCPD (1<<2)
> -#define EP93XX_SYSCON_DEVCFG_KEYS (1<<1)
> -#define EP93XX_SYSCON_DEVCFG_SHENA (1<<0)
> +#define EP93XX_SYSCON_DEVCFG_SWRST BIT(31)
> +#define EP93XX_SYSCON_DEVCFG_D1ONG BIT(30)
> +#define EP93XX_SYSCON_DEVCFG_D0ONG BIT(29)
> +#define EP93XX_SYSCON_DEVCFG_IONU2 BIT(28)
> +#define EP93XX_SYSCON_DEVCFG_GONK BIT(27)
> +#define EP93XX_SYSCON_DEVCFG_TONG BIT(26)
> +#define EP93XX_SYSCON_DEVCFG_MONG BIT(25)
> +#define EP93XX_SYSCON_DEVCFG_U3EN BIT(24)
> +#define EP93XX_SYSCON_DEVCFG_CPENA BIT(23)
> +#define EP93XX_SYSCON_DEVCFG_A2ONG BIT(22)
> +#define EP93XX_SYSCON_DEVCFG_A1ONG BIT(21)
> +#define EP93XX_SYSCON_DEVCFG_U2EN BIT(20)
> +#define EP93XX_SYSCON_DEVCFG_EXVC BIT(19)
> +#define EP93XX_SYSCON_DEVCFG_U1EN BIT(18)
> +#define EP93XX_SYSCON_DEVCFG_TIN BIT(17)
> +#define EP93XX_SYSCON_DEVCFG_HC3IN BIT(15)
> +#define EP93XX_SYSCON_DEVCFG_HC3EN BIT(14)
> +#define EP93XX_SYSCON_DEVCFG_HC1IN BIT(13)
> +#define EP93XX_SYSCON_DEVCFG_HC1EN BIT(12)
> +#define EP93XX_SYSCON_DEVCFG_HONIDE BIT(11)
> +#define EP93XX_SYSCON_DEVCFG_GONIDE BIT(10)
> +#define EP93XX_SYSCON_DEVCFG_PONG BIT(9)
> +#define EP93XX_SYSCON_DEVCFG_EONIDE BIT(8)
> +#define EP93XX_SYSCON_DEVCFG_I2SONSSP BIT(7)
> +#define EP93XX_SYSCON_DEVCFG_I2SONAC97 BIT(6)
> +#define EP93XX_SYSCON_DEVCFG_RASONP3 BIT(4)
> +#define EP93XX_SYSCON_DEVCFG_RAS BIT(3)
> +#define EP93XX_SYSCON_DEVCFG_ADCPD BIT(2)
> +#define EP93XX_SYSCON_DEVCFG_KEYS BIT(1)
> +#define EP93XX_SYSCON_DEVCFG_SHENA BIT(0)
> #define EP93XX_SYSCON_VIDCLKDIV EP93XX_SYSCON_REG(0x84)
> -#define EP93XX_SYSCON_CLKDIV_ENABLE (1<<15)
> -#define EP93XX_SYSCON_CLKDIV_ESEL (1<<14)
> -#define EP93XX_SYSCON_CLKDIV_PSEL (1<<13)
> +#define EP93XX_SYSCON_CLKDIV_ENABLE BIT(15)
> +#define EP93XX_SYSCON_CLKDIV_ESEL BIT(14)
> +#define EP93XX_SYSCON_CLKDIV_PSEL BIT(13)
> #define EP93XX_SYSCON_CLKDIV_PDIV_SHIFT 8
> #define EP93XX_SYSCON_I2SCLKDIV EP93XX_SYSCON_REG(0x8c)
> -#define EP93XX_SYSCON_I2SCLKDIV_SENA (1<<31)
> -#define EP93XX_SYSCON_I2SCLKDIV_ORIDE (1<<29)
> -#define EP93XX_SYSCON_I2SCLKDIV_SPOL (1<<19)
> +#define EP93XX_SYSCON_I2SCLKDIV_SENA BIT(31)
> +#define EP93XX_SYSCON_I2SCLKDIV_ORIDE BIT(29)
> +#define EP93XX_SYSCON_I2SCLKDIV_SPOL BIT(19)
> #define EP93XX_I2SCLKDIV_SDIV (1 << 16)
> #define EP93XX_I2SCLKDIV_LRDIV32 (0 << 17)
> #define EP93XX_I2SCLKDIV_LRDIV64 (1 << 17)
> #define EP93XX_I2SCLKDIV_LRDIV128 (2 << 17)
> #define EP93XX_I2SCLKDIV_LRDIV_MASK (3 << 17)
> #define EP93XX_SYSCON_KEYTCHCLKDIV EP93XX_SYSCON_REG(0x90)
> -#define EP93XX_SYSCON_KEYTCHCLKDIV_TSEN (1<<31)
> -#define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV (1<<16)
> -#define EP93XX_SYSCON_KEYTCHCLKDIV_KEN (1<<15)
> -#define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV (1<<0)
> +#define EP93XX_SYSCON_KEYTCHCLKDIV_TSEN BIT(31)
> +#define EP93XX_SYSCON_KEYTCHCLKDIV_ADIV BIT(16)
> +#define EP93XX_SYSCON_KEYTCHCLKDIV_KEN BIT(15)
> +#define EP93XX_SYSCON_KEYTCHCLKDIV_KDIV BIT(0)
> #define EP93XX_SYSCON_SYSCFG EP93XX_SYSCON_REG(0x9c)
> #define EP93XX_SYSCON_SYSCFG_REV_MASK (0xf0000000)
> #define EP93XX_SYSCON_SYSCFG_REV_SHIFT (28)
> -#define EP93XX_SYSCON_SYSCFG_SBOOT (1<<8)
> -#define EP93XX_SYSCON_SYSCFG_LCSN7 (1<<7)
> -#define EP93XX_SYSCON_SYSCFG_LCSN6 (1<<6)
> -#define EP93XX_SYSCON_SYSCFG_LASDO (1<<5)
> -#define EP93XX_SYSCON_SYSCFG_LEEDA (1<<4)
> -#define EP93XX_SYSCON_SYSCFG_LEECLK (1<<3)
> -#define EP93XX_SYSCON_SYSCFG_LCSN2 (1<<1)
> -#define EP93XX_SYSCON_SYSCFG_LCSN1 (1<<0)
> +#define EP93XX_SYSCON_SYSCFG_SBOOT BIT(8)
> +#define EP93XX_SYSCON_SYSCFG_LCSN7 BIT(7)
> +#define EP93XX_SYSCON_SYSCFG_LCSN6 BIT(6)
> +#define EP93XX_SYSCON_SYSCFG_LASDO BIT(5)
> +#define EP93XX_SYSCON_SYSCFG_LEEDA BIT(4)
> +#define EP93XX_SYSCON_SYSCFG_LEECLK BIT(3)
> +#define EP93XX_SYSCON_SYSCFG_LCSN2 BIT(1)
> +#define EP93XX_SYSCON_SYSCFG_LCSN1 BIT(0)
> #define EP93XX_SYSCON_SWLOCK EP93XX_SYSCON_REG(0xc0)
>
> /* EP93xx System Controller software locked register write */
^ permalink raw reply
* Re: [PATCH 03/11] xdp: add offset param to zero_copy_allocator
From: Jakub Kicinski @ 2019-06-24 19:23 UTC (permalink / raw)
To: Kevin Laatz
Cc: netdev, ast, daniel, bjorn.topel, magnus.karlsson, bpf,
intel-wired-lan, bruce.richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-4-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 09:09:50 +0000, Kevin Laatz wrote:
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 0f25b3675c5c..ea801fd2bf98 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -53,7 +53,8 @@ struct xdp_mem_info {
> struct page_pool;
>
> struct zero_copy_allocator {
> - void (*free)(struct zero_copy_allocator *zca, unsigned long handle);
> + void (*free)(struct zero_copy_allocator *zca, unsigned long handle,
> + off_t off);
> };
Please run checkpatch --strict on all your changes. The code
formatting is incorrect in many ways in this series.
Please include performance measurements proving the slow down
is negligible in the cover letter.
^ permalink raw reply
* Re: [PATCH bpf-next v5 0/3] xdp: Allow lookup into devmaps before redirect
From: Toke Høiland-Jørgensen @ 2019-06-24 19:38 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Networking, Jesper Dangaard Brouer, Daniel Borkmann,
Alexei Starovoitov, David Miller, Jonathan Lemon
In-Reply-To: <CAEf4BzYFCAp7yUU80ia=C5ywDBgepeaMmVPJW8VG4gLUT=ht=A@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Sat, Jun 22, 2019 at 7:19 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> When using the bpf_redirect_map() helper to redirect packets from XDP, the eBPF
>> program cannot currently know whether the redirect will succeed, which makes it
>> impossible to gracefully handle errors. To properly fix this will probably
>> require deeper changes to the way TX resources are allocated, but one thing that
>> is fairly straight forward to fix is to allow lookups into devmaps, so programs
>> can at least know when a redirect is *guaranteed* to fail because there is no
>> entry in the map. Currently, programs work around this by keeping a shadow map
>> of another type which indicates whether a map index is valid.
>>
>> This series contains two changes that are complementary ways to fix this issue:
>>
>> - Moving the map lookup into the bpf_redirect_map() helper (and caching the
>> result), so the helper can return an error if no value is found in the map.
>> This includes a refactoring of the devmap and cpumap code to not care about
>> the index on enqueue.
>>
>> - Allowing regular lookups into devmaps from eBPF programs, using the read-only
>> flag to make sure they don't change the values.
>>
>> The performance impact of the series is negligible, in the sense that I cannot
>> measure it because the variance between test runs is higher than the difference
>> pre/post series.
>>
>> Changelog:
>>
>> v5:
>> - Rebase on latest bpf-next.
>> - Update documentation for bpf_redirect_map() with the new meaning of flags.
>>
>> v4:
>> - Fix a few nits from Andrii
>> - Lose the #defines in bpf.h and just compare the flags argument directly to
>> XDP_TX in bpf_xdp_redirect_map().
>>
>> v3:
>> - Adopt Jonathan's idea of using the lower two bits of the flag value as the
>> return code.
>> - Always do the lookup, and cache the result for use in xdp_do_redirect(); to
>> achieve this, refactor the devmap and cpumap code to get rid the bitmap for
>> selecting which devices to flush.
>>
>> v2:
>> - For patch 1, make it clear that the change works for any map type.
>> - For patch 2, just use the new BPF_F_RDONLY_PROG flag to make the return
>> value read-only.
>>
>> ---
>>
>> Toke Høiland-Jørgensen (3):
>> devmap/cpumap: Use flush list instead of bitmap
>> bpf_xdp_redirect_map: Perform map lookup in eBPF helper
>> devmap: Allow map lookups from eBPF
>>
>>
>> include/linux/filter.h | 1
>> include/uapi/linux/bpf.h | 7 ++-
>> kernel/bpf/cpumap.c | 106 ++++++++++++++++++++-----------------------
>> kernel/bpf/devmap.c | 113 ++++++++++++++++++++++------------------------
>> kernel/bpf/verifier.c | 7 +--
>> net/core/filter.c | 29 +++++-------
>> 6 files changed, 123 insertions(+), 140 deletions(-)
>>
>
>
> Looks like you forgot to add my Acked-by's for your patches?
Ah yes, did not carry those forward for the individual patches, my
apologies. Could you perhaps be persuaded to send a new one (I believe a
response to the cover letter acking the whole series would suffice)?
I'll make sure to add the carrying forward of acks into my workflow in
the future :)
-Toke
^ permalink raw reply
* Re: [PATCH V3 07/10] net: dsa: microchip: Initial SPI regmap support
From: kbuild test robot @ 2019-06-24 19:39 UTC (permalink / raw)
To: Marek Vasut
Cc: kbuild-all, netdev, Marek Vasut, Andrew Lunn, Florian Fainelli,
Tristram Ha, Woojung Huh
In-Reply-To: <20190623223508.2713-8-marex@denx.de>
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net/master]
[also build test WARNING on v5.2-rc6 next-20190621]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Marek-Vasut/net-dsa-microchip-Convert-to-regmap/20190625-021215
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long read_flag_mask @@ got restricted __beunsigned long read_flag_mask @@
>> drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: expected unsigned long read_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: got restricted __be32 [usertype]
>> drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long write_flag_mask @@ got restricted __beunsigned long write_flag_mask @@
>> drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: expected unsigned long write_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:44:9: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long read_flag_mask @@ got restricted __beunsigned long read_flag_mask @@
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: expected unsigned long read_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long write_flag_mask @@ got restricted __beunsigned long write_flag_mask @@
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: expected unsigned long write_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:45:9: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long read_flag_mask @@ got restricted __beunsigned long read_flag_mask @@
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: expected unsigned long read_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: sparse: incorrect type in initializer (different base types) @@ expected unsigned long write_flag_mask @@ got restricted __beunsigned long write_flag_mask @@
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: expected unsigned long write_flag_mask
drivers/net/dsa/microchip/ksz9477_spi.c:46:9: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:52:31: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:52:31: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:52:31: sparse: got struct regmap **
drivers/net/dsa/microchip/ksz9477_spi.c:60:36: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:60:36: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:60:36: sparse: got struct regmap **
drivers/net/dsa/microchip/ksz9477_spi.c:63:24: sparse: sparse: cast to restricted __be16
drivers/net/dsa/microchip/ksz9477_spi.c:63:24: sparse: sparse: cast to restricted __be16
drivers/net/dsa/microchip/ksz9477_spi.c:63:24: sparse: sparse: cast to restricted __be16
drivers/net/dsa/microchip/ksz9477_spi.c:63:24: sparse: sparse: cast to restricted __be16
drivers/net/dsa/microchip/ksz9477_spi.c:70:36: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:70:36: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:70:36: sparse: got struct regmap **
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:73:24: sparse: sparse: cast to restricted __be32
drivers/net/dsa/microchip/ksz9477_spi.c:80:29: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:80:29: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:80:29: sparse: got struct regmap **
drivers/net/dsa/microchip/ksz9477_spi.c:85:15: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] value @@ got resunsigned short [usertype] value @@
drivers/net/dsa/microchip/ksz9477_spi.c:85:15: sparse: expected unsigned short [usertype] value
drivers/net/dsa/microchip/ksz9477_spi.c:85:15: sparse: got restricted __be16 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:86:34: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:86:34: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:86:34: sparse: got struct regmap **
drivers/net/dsa/microchip/ksz9477_spi.c:91:15: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned int [usertype] value @@ got restrunsigned int [usertype] value @@
drivers/net/dsa/microchip/ksz9477_spi.c:91:15: sparse: expected unsigned int [usertype] value
drivers/net/dsa/microchip/ksz9477_spi.c:91:15: sparse: got restricted __be32 [usertype]
drivers/net/dsa/microchip/ksz9477_spi.c:92:34: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected struct regmap *map @@ got sstruct regmap *map @@
drivers/net/dsa/microchip/ksz9477_spi.c:92:34: sparse: expected struct regmap *map
drivers/net/dsa/microchip/ksz9477_spi.c:92:34: sparse: got struct regmap **
vim +44 drivers/net/dsa/microchip/ksz9477_spi.c
25
26 #define KS_SPIOP_FLAG_MASK(opcode) \
27 cpu_to_be32((opcode) << (SPI_ADDR_SHIFT + SPI_TURNAROUND_SHIFT))
28
29 #define KSZ_REGMAP_COMMON(width) \
30 { \
31 .val_bits = (width), \
32 .reg_stride = (width) / 8, \
33 .reg_bits = SPI_ADDR_SHIFT + SPI_ADDR_ALIGN, \
34 .pad_bits = SPI_TURNAROUND_SHIFT, \
35 .max_register = BIT(SPI_ADDR_SHIFT) - 1, \
36 .cache_type = REGCACHE_NONE, \
37 .read_flag_mask = KS_SPIOP_FLAG_MASK(KS_SPIOP_RD), \
38 .write_flag_mask = KS_SPIOP_FLAG_MASK(KS_SPIOP_WR), \
39 .reg_format_endian = REGMAP_ENDIAN_BIG, \
40 .val_format_endian = REGMAP_ENDIAN_BIG \
41 }
42
43 static const struct regmap_config ksz9477_regmap_config[] = {
> 44 KSZ_REGMAP_COMMON(8),
45 KSZ_REGMAP_COMMON(16),
46 KSZ_REGMAP_COMMON(32),
47 };
48
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] ipv4: enable route flushing in network namespaces
From: David Ahern @ 2019-06-24 19:49 UTC (permalink / raw)
To: Christian Brauner, davem, kuznet, yoshfuji, netdev; +Cc: linux-kernel
In-Reply-To: <20190624132923.16792-1-christian@brauner.io>
On 6/24/19 7:29 AM, Christian Brauner wrote:
> Tools such as vpnc try to flush routes when run inside network
> namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This
> currently does not work because flush is not enabled in non-initial
> network namespaces.
> Since routes are per network namespace it is safe to enable
> /proc/sys/net/ipv4/route/flush in there.
>
> Link: https://github.com/lxc/lxd/issues/4257
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> ---
> net/ipv4/route.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
why not teach vpnc to use rtnetlink and then add a flush option to
RTM_DELROUTE?
^ permalink raw reply
* Re: selftests: bpf: test_libbpf.sh failed at file test_l4lb.o
From: Dan Rue @ 2019-06-24 19:53 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Naresh Kamboju, open list:KERNEL SELFTEST FRAMEWORK, bpf, Netdev,
open list, xdp-newbies, David S. Miller, Daniel Borkmann,
Alexei Starovoitov, Martin Lau, Yonghong Song, john fastabend,
hawk, Jakub Kicinski, Shuah Khan
In-Reply-To: <CAEf4BzaSoKA5H5rN=w+OAtUz4bD30-VOjjjY+Qv9tTAnhMweiA@mail.gmail.com>
On Mon, Jun 24, 2019 at 11:32:25AM -0700, Andrii Nakryiko wrote:
> On Fri, Jun 21, 2019 at 9:17 AM Dan Rue <dan.rue@linaro.org> wrote:
> >
> > On Thu, Jun 20, 2019 at 10:17:04PM -0700, Andrii Nakryiko wrote:
> > > On Thu, Jun 20, 2019 at 1:08 AM Naresh Kamboju
> > > <naresh.kamboju@linaro.org> wrote:
> > > >
> > > > selftests: bpf test_libbpf.sh failed running Linux -next kernel
> > > > 20190618 and 20190619.
> > > >
> > > > Here is the log from x86_64,
> > > > # selftests bpf test_libbpf.sh
> > > > bpf: test_libbpf.sh_ #
> > > > # [0] libbpf BTF is required, but is missing or corrupted.
> > >
> > > You need at least clang-9.0.0 (not yet released) to run some of these
> > > tests successfully, as they rely on Clang's support for
> > > BTF_KIND_VAR/BTF_KIND_DATASEC.
> >
> > Can there be a runtime check for BTF that emits a skip instead of a fail
> > in such a case?
>
> I'm not sure how to do this simply and minimally intrusively. The best
> I can come up with is setting some envvar from Makefile and checking
> for that in each inidividual test, which honestly sounds a bit gross.
>
> How hard is it for you guys to upgrade compiler used to run these test?
We should be able to run kselftest with any compiler that Linux
supports, so that we can test with the toolchain that users actually run
with.
I would say if it's not possible to check at runtime, and it requires
clang 9.0, that this test should not be enabled by default.
Maybe something could be done in Makefile for that? Only add it to
TEST_GEN_PROGS if the toolchain feature exists, otherwise add it to
TEST_GEN_PROGS_EXTENDED. I don't know if this is a good idea.. but from
kselftest.rst:
TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by
default.
...
TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
executable which is not tested by default.
Dan
>
> >
> > Thanks,
> > Dan
> >
> > >
> > > > libbpf: BTF_is #
> > > > # test_libbpf failed at file test_l4lb.o
> > > > failed: at_file #
> > > > # selftests test_libbpf [FAILED]
> > > > test_libbpf: [FAILED]_ #
> > > > [FAIL] 29 selftests bpf test_libbpf.sh
> > > > selftests: bpf_test_libbpf.sh [FAIL]
> > > >
> > > > Full test log,
> > > > https://qa-reports.linaro.org/lkft/linux-next-oe/build/next-20190619/testrun/781777/log
> > > >
> > > > Test results comparison,
> > > > https://qa-reports.linaro.org/lkft/linux-next-oe/tests/kselftest/bpf_test_libbpf.sh
> > > >
> > > > Good linux -next tag: next-20190617
> > > > Bad linux -next tag: next-20190618
> > > > git branch master
> > > > git commit 1c6b40509daf5190b1fd2c758649f7df1da4827b
> > > > git repo
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > > >
> > > > Best regards
> > > > Naresh Kamboju
> >
> > --
> > Linaro - Kernel Validation
--
Linaro - Kernel Validation
^ permalink raw reply
* Re: [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Matthew Garrett @ 2019-06-24 19:54 UTC (permalink / raw)
To: Daniel Borkmann
Cc: James Morris, LSM List, Linux Kernel Mailing List, Linux API,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Jann Horn, bpf
In-Reply-To: <739e21b5-9559-d588-3542-bf0bc81de1b2@iogearbox.net>
On Mon, Jun 24, 2019 at 8:37 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 06/22/2019 02:03 AM, Matthew Garrett wrote:
> > From: David Howells <dhowells@redhat.com>
> >
> > There are some bpf functions can be used to read kernel memory:
>
> Nit: that
Fixed.
> > bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
>
> Please explain how bpf_probe_write_user reads kernel memory ... ?!
Ha.
> > private keys in kernel memory (e.g. the hibernation image signing key) to
> > be read by an eBPF program and kernel memory to be altered without
>
> ... and while we're at it, also how they allow "kernel memory to be
> altered without restriction". I've been pointing this false statement
> out long ago.
Yup. How's the following description:
bpf: Restrict bpf when kernel lockdown is in confidentiality mode
There are some bpf functions that can be used to read kernel memory and
exfiltrate it to userland: bpf_probe_read, bpf_probe_write_user and
bpf_trace_printk. These could be abused to (eg) allow private
keys in kernel
memory to be leaked. Disable them if the kernel has been locked
down in confidentiality
mode.
> This whole thing is still buggy as has been pointed out before by
> Jann. For helpers like above and few others below, error conditions
> must clear the buffer ...
Sorry, yes. My fault.
^ permalink raw reply
* Re: WWAN Controller Framework (was IPA [PATCH v2 00/17])
From: Dan Williams @ 2019-06-24 19:54 UTC (permalink / raw)
To: Alex Elder, davem, arnd, bjorn.andersson, ilias.apalodimas
Cc: evgreen, benchan, ejcaruso, cpratapa, syadagir, subashab,
abhishek.esse, netdev, devicetree, linux-kernel, linux-soc,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <23ff4cce-1fee-98ab-3608-1fd09c2d97f1@linaro.org>
On Mon, 2019-06-24 at 11:30 -0500, Alex Elder wrote:
> OK I want to try to organize a little more concisely some of the
> discussion on this, because there is a very large amount of volume
> to date and I think we need to try to narrow the focus back down
> again.
>
> I'm going to use a few terms here. Some of these I really don't
> like, but I want to be unambiguous *and* (at least for now) I want
> to avoid the very overloaded term "device".
>
> I have lots more to say, but let's start with a top-level picture,
> to make sure we're all on the same page.
>
> WWAN Communication
> Channel (Physical)
> | ------------------------
> ------------ v | :+ Control | \
> > |-----------| :+ Data | |
> > AP | | WWAN unit :+ Voice | > Functions
> > |===========| :+ GPS | |
> ------------ ^ | :+ ... | /
> | -------------------------
> Multiplexed WWAN
> Communication
> Channel (Physical)
>
> - The *AP* is the main CPU complex that's running Linux on one or
> more CPU cores.
> - A *WWAN unit* is an entity that shares one or more physical
> *WWAN communication channels* with the AP.
You could just say "WWAN modem" here.
> - A *WWAN communication channel* is a bidirectional means of
> carrying data between the AP and WWAN unit.
> - A WWAN communication channel carries data using a *WWAN protocol*.
> - A WWAN unit implements one or more *WWAN functions*, such as
> 5G data, LTE voice, GPS, and so on.
Go more generic here. Not just 5G data but any WWAN IP-based data
(GPRS, EDGE, CDMA, UMTS, EVDO, LTE, 5G, etc). And not just LTE voice
but any voice data; plenty of devices don't support LTE but still have
"WWAN logical communication channels"
> - A WWAN unit shall implement a *WWAN control function*, used to
> manage the use of other WWAN functions, as well as the WWAN unit
> itself.
> - The AP communicates with a WWAN function using a WWAN protocol.
> - A WWAN physical channel can be *multiplexed*, in which case it
> carries the data for one or more *WWAN logical channels*.
It's unclear to me what "physical" means here. USB Interface or
Endpoint or PCI Function or SMD channel? Or kernel TTY device?
For example on Qualcomm-based USB dongles a given USB Interface's
Endpoint represents a QMAP "IP data" channel which itself could be
multiplexed into separate "IP data" channels. Or that USB Endpoint(s)
could be exposed as a TTY which itself can be MUX-ed dynamically using
GSM 07.10.
To me "physical" usually means the bus type (PCI, USB, SMD, whatever).
A Linux hardware driver (IPA, qmi_wwan, option, sierra, etc) binds to
that physical entity using hardware IDs (USB or PCI VID/PID, devicetree
properties) and exposes some "WWAN logical communication channels".
Those logical channels might be multiplexed and another driver (rmnet)
could handle exposing the de-muxed logical channels that the muxed
logical channel carries.
> - A multiplexed WWAN communication channel uses a *WWAN wultiplexing
> protocol*, which is used to separate independent data streams
> carrying other WWAN protocols.
> - A WWAN logical channel carries a bidirectional stream of WWAN
> protocol data between an entity on the AP and a WWAN function.
It *usually* is bidirectional. For example some GPS logical
communication channels just start spitting out NMEA when you give the
control function a command. The NMEA ports themselves don't accept any
input.
> Does that adequately represent a very high-level picture of what
> we're trying to manage?
Yes, pretty well. Thanks for trying to specify it all.
> And if I understand it right, the purpose of the generic framework
> being discussed is to define a common mechanism for managing (i.e.,
> discovering, creating, destroying, querying, configuring, enabling,
> disabling, etc.) WWAN units and the functions they implement, along
> with the communication and logical channels used to communicate with
> them.
Yes.
Dan
> Comments?
>
> -Alex
^ permalink raw reply
* Re: selftests: bpf: test_libbpf.sh failed at file test_l4lb.o
From: Alexei Starovoitov @ 2019-06-24 19:58 UTC (permalink / raw)
To: Dan Rue
Cc: Andrii Nakryiko, Naresh Kamboju,
open list:KERNEL SELFTEST FRAMEWORK, bpf, Netdev, open list, Xdp,
David S. Miller, Daniel Borkmann, Alexei Starovoitov, Martin Lau,
Yonghong Song, john fastabend, Jesper Dangaard Brouer,
Jakub Kicinski, Shuah Khan
In-Reply-To: <20190624195336.nubi7n2np5vfjutr@xps.therub.org>
On Mon, Jun 24, 2019 at 12:53 PM Dan Rue <dan.rue@linaro.org> wrote:
>
> I would say if it's not possible to check at runtime, and it requires
> clang 9.0, that this test should not be enabled by default.
The latest clang is the requirement.
If environment has old clang or no clang at all these tests will be failing.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: enable route flushing in network namespaces
From: Christian Brauner @ 2019-06-24 19:59 UTC (permalink / raw)
To: David Ahern, davem, kuznet, yoshfuji, netdev; +Cc: linux-kernel
In-Reply-To: <56ed92eb-14db-789a-c226-cdf8a5862e61@gmail.com>
On June 24, 2019 9:49:33 PM GMT+02:00, David Ahern <dsahern@gmail.com> wrote:
>On 6/24/19 7:29 AM, Christian Brauner wrote:
>> Tools such as vpnc try to flush routes when run inside network
>> namespaces by writing 1 into /proc/sys/net/ipv4/route/flush. This
>> currently does not work because flush is not enabled in non-initial
>> network namespaces.
>> Since routes are per network namespace it is safe to enable
>> /proc/sys/net/ipv4/route/flush in there.
>>
>> Link: https://github.com/lxc/lxd/issues/4257
>> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
>> ---
>> net/ipv4/route.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>
>why not teach vpnc to use rtnetlink and then add a flush option to
>RTM_DELROUTE?
I think that if you can do it unprivileged through netlink
you should also allow it through sysctls.
Even the original commit references it
to make it possible to enable the sysctls
1-by-1 as needed.
^ permalink raw reply
* [PATCH ipsec-next] xfrm: remove get_mtu indirection from xfrm_type
From: Florian Westphal @ 2019-06-24 20:04 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
esp4_get_mtu and esp6_get_mtu are exactly the same, the only difference
is a single sizeof() (ipv4 vs. ipv6 header).
Merge both into xfrm_state_mtu() and remove the indirection.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/net/xfrm.h | 4 +---
net/ipv4/esp4.c | 27 +--------------------------
net/ipv6/esp6.c | 20 +-------------------
net/xfrm/xfrm_device.c | 5 ++---
net/xfrm/xfrm_state.c | 34 +++++++++++++++++++++++++++++-----
5 files changed, 34 insertions(+), 56 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 56b31676e330..b22db30c3d88 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -404,8 +404,6 @@ struct xfrm_type {
int (*reject)(struct xfrm_state *, struct sk_buff *,
const struct flowi *);
int (*hdr_offset)(struct xfrm_state *, struct sk_buff *, u8 **);
- /* Estimate maximal size of result of transformation of a dgram */
- u32 (*get_mtu)(struct xfrm_state *, int size);
};
int xfrm_register_type(const struct xfrm_type *type, unsigned short family);
@@ -1546,7 +1544,7 @@ void xfrm_sad_getinfo(struct net *net, struct xfrmk_sadinfo *si);
void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si);
u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq);
int xfrm_init_replay(struct xfrm_state *x);
-int xfrm_state_mtu(struct xfrm_state *x, int mtu);
+u32 xfrm_state_mtu(struct xfrm_state *x, int mtu);
int __xfrm_init_state(struct xfrm_state *x, bool init_replay, bool offload);
int xfrm_init_state(struct xfrm_state *x);
int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index c06562aded11..5c967764041f 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -33,8 +33,6 @@ struct esp_output_extra {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)&((__skb)->cb[0]))
-static u32 esp4_get_mtu(struct xfrm_state *x, int mtu);
-
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -506,7 +504,7 @@ static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
u32 padto;
- padto = min(x->tfcpad, esp4_get_mtu(x, dst->child_mtu_cached));
+ padto = min(x->tfcpad, xfrm_state_mtu(x, dst->child_mtu_cached));
if (skb->len < padto)
esp.tfclen = padto - skb->len;
}
@@ -788,28 +786,6 @@ static int esp_input(struct xfrm_state *x, struct sk_buff *skb)
return err;
}
-static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
-{
- struct crypto_aead *aead = x->data;
- u32 blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- unsigned int net_adj;
-
- switch (x->props.mode) {
- case XFRM_MODE_TRANSPORT:
- case XFRM_MODE_BEET:
- net_adj = sizeof(struct iphdr);
- break;
- case XFRM_MODE_TUNNEL:
- net_adj = 0;
- break;
- default:
- BUG();
- }
-
- return ((mtu - x->props.header_len - crypto_aead_authsize(aead) -
- net_adj) & ~(blksize - 1)) + net_adj - 2;
-}
-
static int esp4_err(struct sk_buff *skb, u32 info)
{
struct net *net = dev_net(skb->dev);
@@ -1035,7 +1011,6 @@ static const struct xfrm_type esp_type =
.flags = XFRM_TYPE_REPLAY_PROT,
.init_state = esp_init_state,
.destructor = esp_destroy,
- .get_mtu = esp4_get_mtu,
.input = esp_input,
.output = esp_output,
};
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index b6c6b3e08836..a3b403ba8f8f 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -41,8 +41,6 @@ struct esp_skb_cb {
#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)&((__skb)->cb[0]))
-static u32 esp6_get_mtu(struct xfrm_state *x, int mtu);
-
/*
* Allocate an AEAD request structure with extra space for SG and IV.
*
@@ -447,7 +445,7 @@ static int esp6_output(struct xfrm_state *x, struct sk_buff *skb)
struct xfrm_dst *dst = (struct xfrm_dst *)skb_dst(skb);
u32 padto;
- padto = min(x->tfcpad, esp6_get_mtu(x, dst->child_mtu_cached));
+ padto = min(x->tfcpad, xfrm_state_mtu(x, dst->child_mtu_cached));
if (skb->len < padto)
esp.tfclen = padto - skb->len;
}
@@ -687,21 +685,6 @@ static int esp6_input(struct xfrm_state *x, struct sk_buff *skb)
return ret;
}
-static u32 esp6_get_mtu(struct xfrm_state *x, int mtu)
-{
- struct crypto_aead *aead = x->data;
- u32 blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- unsigned int net_adj;
-
- if (x->props.mode != XFRM_MODE_TUNNEL)
- net_adj = sizeof(struct ipv6hdr);
- else
- net_adj = 0;
-
- return ((mtu - x->props.header_len - crypto_aead_authsize(aead) -
- net_adj) & ~(blksize - 1)) + net_adj - 2;
-}
-
static int esp6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
u8 type, u8 code, int offset, __be32 info)
{
@@ -919,7 +902,6 @@ static const struct xfrm_type esp6_type = {
.flags = XFRM_TYPE_REPLAY_PROT,
.init_state = esp6_init_state,
.destructor = esp6_destroy,
- .get_mtu = esp6_get_mtu,
.input = esp6_input,
.output = esp6_output,
.hdr_offset = xfrm6_find_1stfragopt,
diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
index b24cd86a02c3..f10a70388f72 100644
--- a/net/xfrm/xfrm_device.c
+++ b/net/xfrm/xfrm_device.c
@@ -275,9 +275,8 @@ bool xfrm_dev_offload_ok(struct sk_buff *skb, struct xfrm_state *x)
return false;
if ((!dev || (dev == xfrm_dst_path(dst)->dev)) &&
- (!xdst->child->xfrm && x->type->get_mtu)) {
- mtu = x->type->get_mtu(x, xdst->child_mtu_cached);
-
+ (!xdst->child->xfrm)) {
+ mtu = xfrm_state_mtu(x, xdst->child_mtu_cached);
if (skb->len <= mtu)
goto ok;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index fd51737f9f17..c6f3c4a1bd99 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -27,6 +27,8 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
+#include <crypto/aead.h>
+
#include "xfrm_hash.h"
#define xfrm_state_deref_prot(table, net) \
@@ -2403,16 +2405,38 @@ void xfrm_state_delete_tunnel(struct xfrm_state *x)
}
EXPORT_SYMBOL(xfrm_state_delete_tunnel);
-int xfrm_state_mtu(struct xfrm_state *x, int mtu)
+u32 xfrm_state_mtu(struct xfrm_state *x, int mtu)
{
const struct xfrm_type *type = READ_ONCE(x->type);
+ struct crypto_aead *aead;
+ u32 blksize, net_adj = 0;
+
+ if (x->km.state != XFRM_STATE_VALID ||
+ !type || type->proto != IPPROTO_ESP)
+ return mtu - x->props.header_len;
+
+ aead = x->data;
+ blksize = ALIGN(crypto_aead_blocksize(aead), 4);
- if (x->km.state == XFRM_STATE_VALID &&
- type && type->get_mtu)
- return type->get_mtu(x, mtu);
+ switch (x->props.mode) {
+ case XFRM_MODE_TRANSPORT:
+ case XFRM_MODE_BEET:
+ if (x->props.family == AF_INET)
+ net_adj = sizeof(struct iphdr);
+ else if (x->props.family == AF_INET6)
+ net_adj = sizeof(struct ipv6hdr);
+ break;
+ case XFRM_MODE_TUNNEL:
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ break;
+ }
- return mtu - x->props.header_len;
+ return ((mtu - x->props.header_len - crypto_aead_authsize(aead) -
+ net_adj) & ~(blksize - 1)) + net_adj - 2;
}
+EXPORT_SYMBOL_GPL(xfrm_state_mtu);
int __xfrm_init_state(struct xfrm_state *x, bool init_replay, bool offload)
{
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net-next 01/18] ionic: Add basic framework for IONIC Network device driver
From: Jakub Kicinski @ 2019-06-24 20:03 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev
In-Reply-To: <20190620202424.23215-2-snelson@pensando.io>
On Thu, 20 Jun 2019 13:24:07 -0700, Shannon Nelson wrote:
> diff --git a/Documentation/networking/device_drivers/pensando/ionic.rst b/Documentation/networking/device_drivers/pensando/ionic.rst
> new file mode 100644
> index 000000000000..84bdf682052b
> --- /dev/null
> +++ b/Documentation/networking/device_drivers/pensando/ionic.rst
> @@ -0,0 +1,75 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +==========================================================
> +Linux* Driver for the Pensando(R) Ethernet adapter family
> +==========================================================
> +
> +Pensando Linux Ethernet driver.
> +Copyright(c) 2019 Pensando Systems, Inc
> +
> +Contents
> +========
> +
> +- Identifying the Adapter
> +- Special Features
> +- Support
> +
> +
nit: all instances of multiple empty lines in the docs look a bit
unnecessary
^ permalink raw reply
* Re: [PATCH net-next 01/18] ionic: Add basic framework for IONIC Network device driver
From: Jakub Kicinski @ 2019-06-24 20:07 UTC (permalink / raw)
To: Shannon Nelson; +Cc: Andrew Lunn, netdev
In-Reply-To: <7f1fcda2-dce4-feb6-ec3a-c54bfb691e5d@pensando.io>
On Fri, 21 Jun 2019 15:13:31 -0700, Shannon Nelson wrote:
> >> +#define DRV_VERSION "0.11.0-k"
> > DRV_VERSION is pretty useless. What you really want to know is the
> > kernel git tree and commit. The big distributions might backport this
> > version of the driver back to the old kernel with a million
> > patches. At which point 0.11.0-k tells you nothing much.
> Yes, any version numbering thing from the big distros is put into
> question, but I find this number useful to me for tracking what has been
> put into the upstream kernel. This plus the full kernel version gives
> me a pretty good idea of what I'm looking at.
Still, we strongly encourage ditching the driver version.
It encourages upstream first development model among other benefits.
^ permalink raw reply
* Re: [PATCH bpf-next] MAINTAINERS: add reviewer to maintainers entry
From: Song Liu @ 2019-06-24 20:07 UTC (permalink / raw)
To: Björn Töpel
Cc: Alexei Starovoitov, Daniel Borkmann, Networking,
Björn Töpel, Magnus Karlsson, bpf, open list,
jonathan.lemon
In-Reply-To: <20190624052455.10659-1-bjorn.topel@gmail.com>
On Sun, Jun 23, 2019 at 10:45 PM Björn Töpel <bjorn.topel@gmail.com> wrote:
>
> From: Björn Töpel <bjorn.topel@intel.com>
>
> Jonathan Lemon has volunteered as an official AF_XDP reviewer. Thank
> you, Jonathan!
Thanks Jonathan! Please reply with your Acked-by.
Thanks,
Song
>
> Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0cfe98a6761a..dd875578d53c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17284,6 +17284,7 @@ N: xdp
> XDP SOCKETS (AF_XDP)
> M: Björn Töpel <bjorn.topel@intel.com>
> M: Magnus Karlsson <magnus.karlsson@intel.com>
> +R: Jonathan Lemon <jonathan.lemon@gmail.com>
> L: netdev@vger.kernel.org
> L: bpf@vger.kernel.org
> S: Maintained
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Andy Lutomirski @ 2019-06-24 20:08 UTC (permalink / raw)
To: Matthew Garrett
Cc: Daniel Borkmann, James Morris, LSM List,
Linux Kernel Mailing List, Linux API, David Howells,
Alexei Starovoitov, Network Development, Chun-Yi Lee, Jann Horn,
bpf
In-Reply-To: <CACdnJuvR2bn3y3fYzg06GWXXgAGjgED2Dfa5g0oAwJ28qCCqBg@mail.gmail.com>
On Mon, Jun 24, 2019 at 12:54 PM Matthew Garrett <mjg59@google.com> wrote:
>
> On Mon, Jun 24, 2019 at 8:37 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 06/22/2019 02:03 AM, Matthew Garrett wrote:
> > > From: David Howells <dhowells@redhat.com>
> > >
> > > There are some bpf functions can be used to read kernel memory:
> >
> > Nit: that
>
> Fixed.
>
> > > bpf_probe_read, bpf_probe_write_user and bpf_trace_printk. These allow
> >
> > Please explain how bpf_probe_write_user reads kernel memory ... ?!
>
> Ha.
>
> > > private keys in kernel memory (e.g. the hibernation image signing key) to
> > > be read by an eBPF program and kernel memory to be altered without
> >
> > ... and while we're at it, also how they allow "kernel memory to be
> > altered without restriction". I've been pointing this false statement
> > out long ago.
>
> Yup. How's the following description:
>
> bpf: Restrict bpf when kernel lockdown is in confidentiality mode
>
> There are some bpf functions that can be used to read kernel memory and
> exfiltrate it to userland: bpf_probe_read, bpf_probe_write_user and
> bpf_trace_printk. These could be abused to (eg) allow private
> keys in kernel
> memory to be leaked. Disable them if the kernel has been locked
> down in confidentiality
> mode.
I'm confused. I understand why we're restricting bpf_probe_read().
Why are we restricting bpf_probe_write_user() and bpf_trace_printk(),
though?
--Andy
^ permalink raw reply
* Re: [PATCH net-next 02/18] ionic: Add hardware init and device commands
From: Jakub Kicinski @ 2019-06-24 20:13 UTC (permalink / raw)
To: Shannon Nelson; +Cc: Andrew Lunn, netdev
In-Reply-To: <65461426-92d8-cd87-942d-1fd82bd64fe4@pensando.io>
On Fri, 21 Jun 2019 15:22:22 -0700, Shannon Nelson wrote:
> >> +static int identity_show(struct seq_file *seq, void *v)
> >> +{
> >> + struct ionic *ionic = seq->private;
> >> + struct identity *ident = &ionic->ident;
> >> + struct ionic_dev *idev = &ionic->idev;
> >> +
> >> + seq_printf(seq, "asic_type: 0x%x\n", idev->dev_info.asic_type);
> >> + seq_printf(seq, "asic_rev: 0x%x\n", idev->dev_info.asic_rev);
> >> + seq_printf(seq, "serial_num: %s\n", idev->dev_info.serial_num);
> >> + seq_printf(seq, "fw_version: %s\n", idev->dev_info.fw_version);
> >> + seq_printf(seq, "fw_status: 0x%x\n",
> >> + ioread8(&idev->dev_info_regs->fw_status));
> >> + seq_printf(seq, "fw_heartbeat: 0x%x\n",
> >> + ioread32(&idev->dev_info_regs->fw_heartbeat));
> > devlink just gained a much more flexible version of ethtool -i. Please
> > remove all this and use that.
> Yes, we intend to add a devlink interface, it just isn't in this first
> patchset, which is already plenty big.
Please take this out of your patch set, we can't be expected to merge
debugfs implementation of what has proper APIs :/
^ permalink raw reply
* Re: [PATCH V34 23/29] bpf: Restrict bpf when kernel lockdown is in confidentiality mode
From: Matthew Garrett @ 2019-06-24 20:15 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Daniel Borkmann, James Morris, LSM List,
Linux Kernel Mailing List, Linux API, David Howells,
Alexei Starovoitov, Network Development, Chun-Yi Lee, Jann Horn,
bpf
In-Reply-To: <CALCETrWmZX3R1L88Gz9vLY68gcK8zSXL4cA4GqAzQoyqSR7rRQ@mail.gmail.com>
On Mon, Jun 24, 2019 at 1:09 PM Andy Lutomirski <luto@kernel.org> wrote:
> I'm confused. I understand why we're restricting bpf_probe_read().
> Why are we restricting bpf_probe_write_user() and bpf_trace_printk(),
> though?
Hmm. I think the thinking here was around exfiltration mechanisms, but
if the read is blocked then that seems less likely. This seems to
trace back to http://kernsec.org/pipermail/linux-security-module-archive/2017-October/003545.html
- Joey, do you know the reasoning here?
^ permalink raw reply
* Re: [PATCH net-next 00/18] Add ionic driver
From: Jakub Kicinski @ 2019-06-24 20:19 UTC (permalink / raw)
To: David Miller; +Cc: Shannon Nelson, netdev, Andrew Lunn
In-Reply-To: <20190620202424.23215-1-snelson@pensando.io>
On Thu, 20 Jun 2019 13:24:06 -0700, Shannon Nelson wrote:
> 28 files changed, 9970 insertions(+)
Dave, could we consider setting a LoC limit for series and patches?
I know this is a new driver, but there's gotta be a way to split
this up more, even if it's painful for the submitter :S
All the debugfs stuff shouldn't be necessary in the first version,
just looking at first 2 patches...
^ permalink raw reply
* Re: [PATCH v7 0/6] Add support for Orange Pi 3
From: David Miller @ 2019-06-24 20:24 UTC (permalink / raw)
To: megous
Cc: linux-sunxi, maxime.ripard, wens, robh+dt, jernej.skrabec,
airlied, daniel, mark.rutland, peppe.cavallaro, alexandre.torgue,
joabreu, mcoquelin.stm32, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, netdev, linux-stm32
In-Reply-To: <20190624174637.6sznc5ifiuh4c3sm@core.my.home>
From: Ondřej Jirman <megous@megous.com>
Date: Mon, 24 Jun 2019 19:46:37 +0200
> This series was even longer before, with patches all around for various
> maintainers. I'd expect that relevant maintainers pick the range of patches
> meant for them. I don't know who's exactly responsible for what, but I think,
> this should work:
>
> - 2 stmmac patches should go together via some networking tree (is there
> something specific for stmmac?)
> - all DTS patches should go via sunxi
> - hdmi patches via some drm tree
Thank you. So I'll merge the first two patches that touch the stmmac
driver via my net-next tree.
^ permalink raw reply
* Re: [PATCH net v2 1/2] ipv6: constify rt6_nexthop()
From: David Miller @ 2019-06-24 20:27 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: ndesaulniers, netdev, lkp
In-Reply-To: <3d7c16c4-9c3e-d18c-aad4-6583216ea457@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 24 Jun 2019 20:18:37 +0200
> Le 24/06/2019 à 19:37, Nick Desaulniers a écrit :
> [snip]
>>
>> The author stated that this patch was no functional change. Nicolas,
>> it can be helpful to include compiler warnings in the commit message
>> when sending warning fixes, but it's not a big deal. Thanks for
>> sending the patches.
>>
> Yep, but I was not aware of this compilation warning. As explained in the commit
> log, the goal of this patch was to prepare the next one.
Yeah, don't worry about it.
^ permalink raw reply
* Re: [PATCH v7 0/6] Add support for Orange Pi 3
From: Ondřej Jirman @ 2019-06-24 20:28 UTC (permalink / raw)
To: David Miller
Cc: linux-sunxi, maxime.ripard, wens, robh+dt, jernej.skrabec,
airlied, daniel, mark.rutland, peppe.cavallaro, alexandre.torgue,
joabreu, mcoquelin.stm32, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, netdev, linux-stm32
In-Reply-To: <20190624.132456.2013417744691373807.davem@davemloft.net>
On Mon, Jun 24, 2019 at 01:24:56PM -0700, David Miller wrote:
> From: Ondřej Jirman <megous@megous.com>
> Date: Mon, 24 Jun 2019 19:46:37 +0200
>
> > This series was even longer before, with patches all around for various
> > maintainers. I'd expect that relevant maintainers pick the range of patches
> > meant for them. I don't know who's exactly responsible for what, but I think,
> > this should work:
> >
> > - 2 stmmac patches should go together via some networking tree (is there
> > something specific for stmmac?)
> > - all DTS patches should go via sunxi
> > - hdmi patches via some drm tree
>
> Thank you. So I'll merge the first two patches that touch the stmmac
> driver via my net-next tree.
Thank you.
regards,
Ondrej
^ permalink raw reply
* Re: [PATCH] bpf: hide do_bpf_send_signal when unused
From: Yonghong Song @ 2019-06-24 20:37 UTC (permalink / raw)
To: Steven Rostedt, Alexei Starovoitov, arnd@arndb.de
Cc: Matt Mullins, Song Liu, linux-kernel@vger.kernel.org,
daniel@iogearbox.net, bpf@vger.kernel.org, ast@kernel.org,
mingo@redhat.com, netdev@vger.kernel.org, Martin Lau,
Andrii Nakryiko
In-Reply-To: <20190617201850.010a4cf6@gandalf.local.home>
On 6/17/19 5:18 PM, Steven Rostedt wrote:
> On Mon, 17 Jun 2019 16:27:33 -0700
> Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
>> On Mon, Jun 17, 2019 at 4:13 PM Matt Mullins <mmullins@fb.com> wrote:
>>>>
>>>> The bug (really just a warning) reported is exactly here.
>>>
>>> I don't think bpf_send_signal is tied to modules at all;
>>> send_signal_irq_work_init and the corresponding initcall should be
>>> moved outside that #ifdef.
>>
>> right. I guess send_signal_irq_work_init was accidentally placed
>> after bpf_event_init and happened to be within that ifdef.
>> Should definitely be outside.
>
> So Arnd did find a bug. Just the wrong solution ;-)
>
> -- Steve
Hi, Arnd,
The following change can fix the issue.
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index c102c240bb0b..ca1255d14576 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -1431,6 +1431,20 @@ int bpf_get_perf_event_info(const struct
perf_event *event, u32 *prog_id,
return err;
}
+static int __init send_signal_irq_work_init(void)
+{
+ int cpu;
+ struct send_signal_irq_work *work;
+
+ for_each_possible_cpu(cpu) {
+ work = per_cpu_ptr(&send_signal_work, cpu);
+ init_irq_work(&work->irq_work, do_bpf_send_signal);
+ }
+ return 0;
+}
+
+subsys_initcall(send_signal_irq_work_init);
+
#ifdef CONFIG_MODULES
static int bpf_event_notify(struct notifier_block *nb, unsigned long op,
void *module)
@@ -1478,18 +1492,5 @@ static int __init bpf_event_init(void)
return 0;
}
-static int __init send_signal_irq_work_init(void)
-{
- int cpu;
- struct send_signal_irq_work *work;
-
- for_each_possible_cpu(cpu) {
- work = per_cpu_ptr(&send_signal_work, cpu);
- init_irq_work(&work->irq_work, do_bpf_send_signal);
- }
- return 0;
-}
-
fs_initcall(bpf_event_init);
-subsys_initcall(send_signal_irq_work_init);
#endif /* CONFIG_MODULES */
Could you submit a new revision? Thanks!
Yonghong
^ permalink raw reply related
* [PATCH v2 net-next] ipv6: Convert gateway validation to use fib6_info
From: David Ahern @ 2019-06-24 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, kafai, weiwan, David Ahern
From: David Ahern <dsahern@gmail.com>
Gateway validation does not need a dst_entry, it only needs the fib
entry to validate the gateway resolution and egress device. So,
convert ip6_nh_lookup_table from ip6_pol_route to fib6_table_lookup
and ip6_route_check_nh to use fib6_lookup over rt6_lookup.
ip6_pol_route is a call to fib6_table_lookup and if successful a call
to fib6_select_path. From there the exception cache is searched for an
entry or a dst_entry is created to return to the caller. The exception
entry is not relevant for gateway validation, so what matters are the
calls to fib6_table_lookup and then fib6_select_path.
Similarly, rt6_lookup can be replaced with a call to fib6_lookup with
RT6_LOOKUP_F_IFACE set in flags. Again, the exception cache search is
not relevant, only the lookup with path selection. The primary difference
in the lookup paths is the use of rt6_select with fib6_lookup versus
rt6_device_match with rt6_lookup. When you remove complexities in the
rt6_select path, e.g.,
1. saddr is not set for gateway validation, so RT6_LOOKUP_F_HAS_SADDR
is not relevant
2. rt6_check_neigh is not called so that removes the RT6_NUD_FAIL_DO_RR
return and round-robin logic.
the code paths are believed to be equivalent for the given use case -
validate the gateway and optionally given the device. Furthermore, it
aligns the validation with onlink code path and the lookup path actually
used for rx and tx.
Adjust the users, ip6_route_check_nh_onlink and ip6_route_check_nh to
handle a fib6_info vs a rt6_info when performing validation checks.
Existing selftests fib-onlink-tests.sh and fib_tests.sh are used to
verify the changes.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v2
- use in6_dev_get versus __in6_dev_get + in6_dev_hold (comment from Wei)
- updated commit message
net/ipv6/route.c | 118 ++++++++++++++++++++++++++-----------------------------
1 file changed, 56 insertions(+), 62 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index be5e65c97652..5fe0fd6f2909 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3144,10 +3144,9 @@ static int ip6_dst_gc(struct dst_ops *ops)
return entries > rt_max_size;
}
-static struct rt6_info *ip6_nh_lookup_table(struct net *net,
- struct fib6_config *cfg,
- const struct in6_addr *gw_addr,
- u32 tbid, int flags)
+static int ip6_nh_lookup_table(struct net *net, struct fib6_config *cfg,
+ const struct in6_addr *gw_addr, u32 tbid,
+ int flags, struct fib6_result *res)
{
struct flowi6 fl6 = {
.flowi6_oif = cfg->fc_ifindex,
@@ -3155,25 +3154,23 @@ static struct rt6_info *ip6_nh_lookup_table(struct net *net,
.saddr = cfg->fc_prefsrc,
};
struct fib6_table *table;
- struct rt6_info *rt;
+ int err;
table = fib6_get_table(net, tbid);
if (!table)
- return NULL;
+ return -EINVAL;
if (!ipv6_addr_any(&cfg->fc_prefsrc))
flags |= RT6_LOOKUP_F_HAS_SADDR;
flags |= RT6_LOOKUP_F_IGNORE_LINKSTATE;
- rt = ip6_pol_route(net, table, cfg->fc_ifindex, &fl6, NULL, flags);
- /* if table lookup failed, fall back to full lookup */
- if (rt == net->ipv6.ip6_null_entry) {
- ip6_rt_put(rt);
- rt = NULL;
- }
+ err = fib6_table_lookup(net, table, cfg->fc_ifindex, &fl6, res, flags);
+ if (!err && res->f6i != net->ipv6.fib6_null_entry)
+ fib6_select_path(net, res, &fl6, cfg->fc_ifindex,
+ cfg->fc_ifindex != 0, NULL, flags);
- return rt;
+ return err;
}
static int ip6_route_check_nh_onlink(struct net *net,
@@ -3181,29 +3178,19 @@ static int ip6_route_check_nh_onlink(struct net *net,
const struct net_device *dev,
struct netlink_ext_ack *extack)
{
- u32 tbid = l3mdev_fib_table(dev) ? : RT_TABLE_MAIN;
+ u32 tbid = l3mdev_fib_table_rcu(dev) ? : RT_TABLE_MAIN;
const struct in6_addr *gw_addr = &cfg->fc_gateway;
- u32 flags = RTF_LOCAL | RTF_ANYCAST | RTF_REJECT;
- struct fib6_info *from;
- struct rt6_info *grt;
+ struct fib6_result res = {};
int err;
- err = 0;
- grt = ip6_nh_lookup_table(net, cfg, gw_addr, tbid, 0);
- if (grt) {
- rcu_read_lock();
- from = rcu_dereference(grt->from);
- if (!grt->dst.error &&
- /* ignore match if it is the default route */
- from && !ipv6_addr_any(&from->fib6_dst.addr) &&
- (grt->rt6i_flags & flags || dev != grt->dst.dev)) {
- NL_SET_ERR_MSG(extack,
- "Nexthop has invalid gateway or device mismatch");
- err = -EINVAL;
- }
- rcu_read_unlock();
-
- ip6_rt_put(grt);
+ err = ip6_nh_lookup_table(net, cfg, gw_addr, tbid, 0, &res);
+ if (!err && !(res.fib6_flags & RTF_REJECT) &&
+ /* ignore match if it is the default route */
+ !ipv6_addr_any(&res.f6i->fib6_dst.addr) &&
+ (res.fib6_type != RTN_UNICAST || dev != res.nh->fib_nh_dev)) {
+ NL_SET_ERR_MSG(extack,
+ "Nexthop has invalid gateway or device mismatch");
+ err = -EINVAL;
}
return err;
@@ -3216,47 +3203,50 @@ static int ip6_route_check_nh(struct net *net,
{
const struct in6_addr *gw_addr = &cfg->fc_gateway;
struct net_device *dev = _dev ? *_dev : NULL;
- struct rt6_info *grt = NULL;
+ int flags = RT6_LOOKUP_F_IFACE;
+ struct fib6_result res = {};
int err = -EHOSTUNREACH;
if (cfg->fc_table) {
- int flags = RT6_LOOKUP_F_IFACE;
-
- grt = ip6_nh_lookup_table(net, cfg, gw_addr,
- cfg->fc_table, flags);
- if (grt) {
- if (grt->rt6i_flags & RTF_GATEWAY ||
- (dev && dev != grt->dst.dev)) {
- ip6_rt_put(grt);
- grt = NULL;
- }
- }
+ err = ip6_nh_lookup_table(net, cfg, gw_addr,
+ cfg->fc_table, flags, &res);
+ /* gw_addr can not require a gateway or resolve to a reject
+ * route. If a device is given, it must match the result.
+ */
+ if (err || res.fib6_flags & RTF_REJECT ||
+ res.nh->fib_nh_gw_family ||
+ (dev && dev != res.nh->fib_nh_dev))
+ err = -EHOSTUNREACH;
}
- if (!grt)
- grt = rt6_lookup(net, gw_addr, NULL, cfg->fc_ifindex, NULL, 1);
+ if (err < 0) {
+ struct flowi6 fl6 = {
+ .flowi6_oif = cfg->fc_ifindex,
+ .daddr = *gw_addr,
+ };
- if (!grt)
- goto out;
+ err = fib6_lookup(net, cfg->fc_ifindex, &fl6, &res, flags);
+ if (err || res.fib6_flags & RTF_REJECT ||
+ res.nh->fib_nh_gw_family)
+ err = -EHOSTUNREACH;
+
+ if (err)
+ return err;
+
+ fib6_select_path(net, &res, &fl6, cfg->fc_ifindex,
+ cfg->fc_ifindex != 0, NULL, flags);
+ }
+ err = 0;
if (dev) {
- if (dev != grt->dst.dev) {
- ip6_rt_put(grt);
- goto out;
- }
+ if (dev != res.nh->fib_nh_dev)
+ err = -EHOSTUNREACH;
} else {
- *_dev = dev = grt->dst.dev;
- *idev = grt->rt6i_idev;
+ *_dev = dev = res.nh->fib_nh_dev;
dev_hold(dev);
- in6_dev_hold(grt->rt6i_idev);
+ *idev = in6_dev_get(dev);
}
- if (!(grt->rt6i_flags & RTF_GATEWAY))
- err = 0;
-
- ip6_rt_put(grt);
-
-out:
return err;
}
@@ -3297,11 +3287,15 @@ static int ip6_validate_gw(struct net *net, struct fib6_config *cfg,
goto out;
}
+ rcu_read_lock();
+
if (cfg->fc_flags & RTNH_F_ONLINK)
err = ip6_route_check_nh_onlink(net, cfg, dev, extack);
else
err = ip6_route_check_nh(net, cfg, _dev, idev);
+ rcu_read_unlock();
+
if (err)
goto out;
}
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox