* [PATCH] [ATM] firestream: fix spelling mistake: "reseverd" -> "reserved"
From: Colin King @ 2018-05-08 22:01 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in res_strings string array
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/atm/firestream.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/atm/firestream.c b/drivers/atm/firestream.c
index d97c05690faa..4e46dc9e41ad 100644
--- a/drivers/atm/firestream.c
+++ b/drivers/atm/firestream.c
@@ -191,7 +191,7 @@ static char *res_strings[] = {
"reserved 37",
"reserved 38",
"reserved 39",
- "reseverd 40",
+ "reserved 40",
"reserved 41",
"reserved 42",
"reserved 43",
--
2.17.0
^ permalink raw reply related
* [PATCH] sctp: fix spelling mistake: "max_retans" -> "max_retrans"
From: Colin King @ 2018-05-08 22:24 UTC (permalink / raw)
To: Vlad Yasevich, Neil Horman, Marcelo Ricardo Leitner,
David S . Miller, linux-sctp, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in error string
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/sctp/sm_make_chunk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 4d7b3ccea078..4a4fd1971255 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1131,7 +1131,7 @@ struct sctp_chunk *sctp_make_violation_max_retrans(
const struct sctp_association *asoc,
const struct sctp_chunk *chunk)
{
- static const char error[] = "Association exceeded its max_retans count";
+ static const char error[] = "Association exceeded its max_retrans count";
size_t payload_len = sizeof(error) + sizeof(struct sctp_errhdr);
struct sctp_chunk *retval;
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v6 05/13] firmware_loader: enhance Kconfig documentation over FW_LOADER
From: Kees Cook @ 2018-05-08 22:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Andrew Morton, Josh Triplett, maco, Andy Gross,
David Brown, bjorn.andersson, teg, wagi, Hans de Goede,
Andres Rodriguez, Mimi Zohar, Jakub Kicinski, Shuah Khan,
Martin Fuzzey, David Howells, pali.rohar, Takashi Iwai,
Kalle Valo, Arend van Spriel, Rafał Miłecki,
Nicolas Broeking
In-Reply-To: <20180508181247.19431-6-mcgrof@kernel.org>
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> If you try to read FW_LOADER today it speaks of old riddles and
> unless you have been following development closely you will loose
Typo: lose
> track of what is what. Even the documentation for PREVENT_FIRMWARE_BUILD
> is a bit fuzzy and how it fits into this big picture.
>
> Give the FW_LOADER kconfig documentation some love with more up to
> date developments and recommendations. While at it, wrap the FW_LOADER
> code into its own menu to compartamentalize and make it clearer which
Typo: compartmentalize
> components really are part of the FW_LOADER. This should also make
> it easier to later move these kconfig entries into the firmware_loader/
> directory later.
>
> This also now recommends using firmwared [0] for folks left needing a uevent
> handler in userspace for the sysfs firmware fallback mechanis given udev's
> uevent firmware mechanism was ripped out a while ago.
>
> [0] https://github.com/teg/firmwared
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> drivers/base/Kconfig | 165 ++++++++++++++++++++++++++++++++++---------
> 1 file changed, 131 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 29b0eb452b3a..a4fe86caecca 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -70,39 +70,64 @@ config STANDALONE
> If unsure, say Y.
>
> config PREVENT_FIRMWARE_BUILD
> - bool "Prevent firmware from being built"
> + bool "Disable drivers features which enable custom firmware building"
> default y
> help
> - Say yes to avoid building firmware. Firmware is usually shipped
> - with the driver and only when updating the firmware should a
> - rebuild be made.
> - If unsure, say Y here.
> + Say yes to disable driver features which enable building a custom
> + driver firmwar at kernel build time. These drivers do not use the
Typo: firmware
> + kernel firmware API to load firmware (CONFIG_FW_LOADER), instead they
> + use their own custom loading mechanism. The required firmware is
> + usually shipped with the driver, building the driver firmware
> + should only be needed if you have an updated firmware source.
> +
> + Firmware should not be being built as part of kernel, these days
> + you should always prevent this and say Y here. There are only two
> + old drivers which enable building of its firmware at kernel build
> + time:
> +
> + o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
> + o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
> +
> +menu "Firmware loader"
>
> config FW_LOADER
> - tristate "Userspace firmware loading support" if EXPERT
> + tristate "Firmware loading facility" if EXPERT
> default y
> ---help---
> - This option is provided for the case where none of the in-tree modules
> - require userspace firmware loading support, but a module built
> - out-of-tree does.
> + This enables the firmware loading facility in the kernel. The kernel
> + will first look for built-in firmware, if it has any. Next, it will
> + look for the requested firmware in a series of filesystem paths:
> +
> + o firmware_class path module parameter or kernel boot param
> + o /lib/firmware/updates/UTS_RELEASE
> + o /lib/firmware/updates
> + o /lib/firmware/UTS_RELEASE
> + o /lib/firmware
> +
> + Enabling this feature only increases your kernel image by about
> + 828 bytes, enable this option unless you are certain you don't
> + need firmware.
> +
> + You typically want this built-in (=y) but you can also enable this
> + as a module, in which case the firmware_class module will be built.
> + You also want to be sure to enable this built-in if you are going to
> + enable built-in firmware (CONFIG_EXTRA_FIRMWARE).
> +
> +if FW_LOADER
>
> config EXTRA_FIRMWARE
> - string "External firmware blobs to build into the kernel binary"
> - depends on FW_LOADER
> + string "Build these firmware blobs into the kernel binary"
Maybe "Build named firmware blobs ..." "these" took me a while to figure out.
> help
> - Various drivers in the kernel source tree may require firmware,
> - which is generally available in your distribution's linux-firmware
> - package.
> + Device drivers which require firmware can typically deal with
> + having the kernel load firmware from the various supported
> + /lib/firmware/ paths. This option enables you to build into the
> + kernel firmware files. Built-in firmware searches are preceeded
Typo: preceded
> + over firmware lookups using your filesystem over the supported
> + /lib/firmware paths documented on CONFIG_FW_LOADER.
>
> - The linux-firmware package should install firmware into
> - /lib/firmware/ on your system, so they can be loaded by userspace
> - helpers on request.
> -
> - This option allows firmware to be built into the kernel for the case
> - where the user either cannot or doesn't want to provide it from
> - userspace at runtime (for example, when the firmware in question is
> - required for accessing the boot device, and the user doesn't want to
> - use an initrd).
> + This may be useful for testing or if the firmware is required early on
> + in boot and cannot rely on the firmware being placed in an initrd or
> + initramfs.
>
> This option is a string and takes the (space-separated) names of the
> firmware files -- the same names that appear in MODULE_FIRMWARE()
> @@ -113,7 +138,7 @@ config EXTRA_FIRMWARE
> For example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin", copy
> the usb8388.bin file into /lib/firmware, and build the kernel. Then
> any request_firmware("usb8388.bin") will be satisfied internally
> - without needing to call out to userspace.
> + inside the kernel without ever looking at your filesystem at runtime.
>
> WARNING: If you include additional firmware files into your binary
> kernel image that are not available under the terms of the GPL,
> @@ -130,22 +155,94 @@ config EXTRA_FIRMWARE_DIR
> looks for the firmware files listed in the EXTRA_FIRMWARE option.
>
> config FW_LOADER_USER_HELPER
> - bool
> + bool "Enable the firmware sysfs fallback mechanism"
> + help
> + This option enables a sysfs loading facility to enable firmware
> + loading to the kernel through userspace as a fallback mechanism
> + if and only if the kernel's direct filesystem lookup for the
> + firmware failed using the different /lib/firmware/ paths, or the
> + path specified in the firmware_class path module parameter, or the
> + firmware_class path kernel boot parameter if the firmware_class is
> + built-in. For details on how to work with the sysfs fallback mechanism
> + refer to Documentation/driver-api/firmware/fallback-mechanisms.rst.
> +
> + The direct filesystem lookup for firwmare is always used first now.
Typo: firmware
> +
> + If the kernel's direct filesystem lookup for firware fails to find
> + the requested firmware a sysfs fallback loading facility is made
> + available and userspace is informed about this through uevents.
> + The uevent can be supressed if the driver explicitly requested it,
> + this is known as the driver using the custom fallback mechanism.
> + If the custom fallback mechanism is used userspace must always
> + acknowledge failure to find firmware as the timeout for the fallback
> + mechanism is disabled, and failed requests will linger forever.
> +
> + This used to be the default firmware loading facility, and udev used
> + to listen for uvents to load firmware for the kernel. The firmware
> + loading facility functionality in udev has been removed, as such it
> + can no longer be relied upon as a fallback mechanism. Linux no longer
> + relies on or uses a fallback mechanism in userspace. If you need to
> + rely on one refer to the permissively licensed firmwared:
Typo: firmware
> +
> + https://github.com/teg/firmwared
> +
> + Since this was the default firmware loading facility at one point,
> + old userspace may exist which relies upon it, and as such this
> + mechanism can never be removed from the kernel.
> +
> + You should only enable this functionality if you are certain you
> + require a fallback mechanism and have a userspace mechanism ready to
> + load firmware in case it is not found. One main reason for this may
> + be if you have drivers which require firmware built-in and for
> + whatever reason cannot place the required firmware in initramfs.
> + Another reason kernels may have this feature enabled is to support a
> + driver which explicitly relies on this fallback mechanism. Only two
> + drivers need this today:
> +
> + o CONFIG_LEDS_LP55XX_COMMON
> + o CONFIG_DELL_RBU
> +
> + Outside of supporting the above drivers, another reason for needing
> + this may be that your firmware resides outside of the paths the kernel
> + looks for and cannot possibily be specified using the firmware_class
> + path module parameter or kernel firmware_class path boot parameter
> + if firmware_class is built-in.
> +
> + A modern use case may be to temporarily mount a custom partition
> + during provisioning which is only accessible to userspace, and then
> + to use it to look for and fetch the required firmware. Such type of
> + driver functionality may not even ever be desirable upstream by
> + vendors, and as such is only required to be supported as an interface
> + for provisioning. Since udev's firmware loading facility has been
> + removed you can use firmwared or a fork of it to customize how you
> + want to load firmware based on uevents issued.
> +
> + Enabling this option will increase your kernel image size by about
> + 13436 bytes.
> +
> + If you are unsure about this, say N here, unless you are Linux
> + distribution and need to support the above two drivers, or you are
> + certain you need to support some really custom firmware loading
> + facility in userspace.
>
> config FW_LOADER_USER_HELPER_FALLBACK
> - bool "Fallback user-helper invocation for firmware loading"
> - depends on FW_LOADER
> - select FW_LOADER_USER_HELPER
> + bool "Force the firmware sysfs fallback mechanism when possible"
> + depends on FW_LOADER_USER_HELPER
> help
> - This option enables / disables the invocation of user-helper
> - (e.g. udev) for loading firmware files as a fallback after the
> - direct file loading in kernel fails. The user-mode helper is
> - no longer required unless you have a special firmware file that
> - resides in a non-standard path. Moreover, the udev support has
> - been deprecated upstream.
> + Enabling this option forces a sysfs userspace fallback mechanism
> + to be used for all firmware requests which explicitly do not disable a
> + a fallback mechanism. Firmware calls which do prohibit a fallback
> + mechanism is request_firmware_direct(). This option is kept for
> + backward compatibility purposes given this precise mechanism can also
> + be enabled by setting the proc sysctl value to true:
> +
> + /proc/sys/kernel/firmware_config/force_sysfs_fallback
>
> If you are unsure about this, say N here.
>
> +endif # FW_LOADER
> +endmenu
> +
> config WANT_DEV_COREDUMP
> bool
> help
> --
> 2.17.0
>
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH v6 00/13] firmware_loader changes for v4.18
From: Kees Cook @ 2018-05-08 22:45 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Greg KH, Andrew Morton, Josh Triplett, maco, Andy Gross,
David Brown, bjorn.andersson, teg, wagi, Hans de Goede,
Andres Rodriguez, Mimi Zohar, Jakub Kicinski, Shuah Khan,
Martin Fuzzey, David Howells, pali.rohar, Takashi Iwai,
Kalle Valo, Arend van Spriel, Rafał Miłecki,
Nicolas Broeking
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez <mcgrof@kernel.org> wrote:
> Greg,
>
> Here is what I have queued up for the firmware_loader for v4.18. It
> includes a slew of cleanup work, and the new firmware_request_nowarn()
> which is quiet but enables the sysfs fallback mechanism. I've gone ahead
> and also queued up a few minor fixes for the firmware loader documentation
> which have come up recently. These changes are available on my git tree
> both based on linux-next [0] and Linus' latest tree [1]. Folks working
> on new developments for the firmware loader can use my linux-next
> branch 20180508-firmware_loader_for-v4.18-try2 for now.
>
> 0-day sends its blessings.
>
> The patches from Mimi's series still require a bit more discussion and
> review. The discussion over the EFI firmware fallback mechanism is still
> ongoing.
>
> As for the rename that you wanted, perhaps we can do this late in the
> merge window considering we're at rc4 now. I can prep something up for
> that later.
>
> Question, and specially rants are warmly welcomed.
I sent some typo catches, but with those fixed, please consider the
whole series:
Reviewed-by: Kees Cook <keescook@chromium.org>
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: The SO_BINDTODEVICE was set to the desired interface, but packets are received from all interfaces.
From: David Ahern @ 2018-05-08 22:48 UTC (permalink / raw)
To: Paolo Abeni, Damir Mansurov, netdev
Cc: Konstantin Ushakov, Alexandra N. Kossovsky, Andrey Dmitrov
In-Reply-To: <1525696890.2587.24.camel@redhat.com>
On 5/7/18 6:41 AM, Paolo Abeni wrote:
> Hi,
> On Mon, 2018-05-07 at 13:19 +0300, Damir Mansurov wrote:
>> After successful call of the setsockopt(SO_BINDTODEVICE) function to set
>> data reception from only one interface, the data is still received from
>> all interfaces. Function setsockopt() returns 0 but then recv() receives
>> data from all available network interfaces.
>>
>> The problem is reproducible on linux kernels 4.14 - 4.16, but it does
>> not on linux kernels 4.4, 4.13.
>
> I think that the cause is commit:
>
> commit fb74c27735f0a34e76dbf1972084e984ad2ea145
> Author: David Ahern <dsahern@gmail.com>
> Date: Mon Aug 7 08:44:16 2017 -0700
>
> net: ipv4: add second dif to udp socket lookups
>
> Something like the following should fix, but I'm unsure it preserves
> the intended semathics for 'sdif'. David, can you please have a look?
> Thanks!
>
> Paolo
> ---
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index dd3102a37ef9..0d593d5c33cf 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -401,9 +401,9 @@ static int compute_score(struct sock *sk, struct net *net,
> bool dev_match = (sk->sk_bound_dev_if == dif ||
> sk->sk_bound_dev_if == sdif);
>
> - if (exact_dif && !dev_match)
> + if (!dev_match)
> return -1;
> - if (sk->sk_bound_dev_if && dev_match)
> + if (sk->sk_bound_dev_if)
> score += 4;
> }
>
>
The above fixes the reported problem. You should make the same change to
ipv6 as well. Fixes tags:
Fixes: fb74c27735f0a ("net: ipv4: add second dif to udp socket lookups")
Fixes: 1801b570dd2ae ("net: ipv6: add second dif to udp socket lookups")
The change does break a VRF use case, but that case works by accident
given this bug. The use case is a client or server bound to an enslaved
device and trying to communicate locally. In some cases the error is the
ICMP 'Connection refused' getting lost; in other cases the packets don't
make it from one scope to another (eg., VRF based server talking to
device based client). After poking around for a couple of days, I
believe the proper fix for this uses case is beyond the scope of
anything that should be backported to 4.14. So I am fine with the
breakage to what is IMHO a corner case - and there is a reasonable
workaround until I find a proper solution.
^ permalink raw reply
* Re: [PATCH] hv_netvsc: Fix net device attach on older Windows hosts
From: Stephen Hemminger @ 2018-05-08 22:49 UTC (permalink / raw)
To: Mohammed Gamal; +Cc: sthemmin, netdev, haiyangz, linux-kernel, devel, vkuznets
In-Reply-To: <1525803471.4366.15.camel@redhat.com>
On Tue, 08 May 2018 20:17:51 +0200
Mohammed Gamal <mgamal@redhat.com> wrote:
> On Tue, 2018-05-08 at 11:13 -0700, Stephen Hemminger wrote:
> > On Tue, 8 May 2018 19:40:47 +0200
> > Mohammed Gamal <mgamal@redhat.com> wrote:
> >
> > > On older windows hosts the net_device instance is returned to
> > > the caller of rndis_filter_device_add() without having the presence
> > > bit set first. This would cause any subsequent calls to network
> > > device
> > > operations (e.g. MTU change, channel change) to fail after the
> > > device
> > > is detached once, returning -ENODEV.
> > >
> > > Make sure we explicitly call netif_device_attach() before returning
> > > the net_device instance to make sure the presence bit is set
> > >
> > > Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic")
> > >
> > > Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
> > > ---
> > > drivers/net/hyperv/rndis_filter.c | 4 +++-
> > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/hyperv/rndis_filter.c
> > > b/drivers/net/hyperv/rndis_filter.c
> > > index 6b127be..09a3c1d 100644
> > > --- a/drivers/net/hyperv/rndis_filter.c
> > > +++ b/drivers/net/hyperv/rndis_filter.c
> > > @@ -1287,8 +1287,10 @@ struct netvsc_device
> > > *rndis_filter_device_add(struct hv_device *dev,
> > > rndis_device->hw_mac_adr,
> > > rndis_device->link_state ? "down" : "up");
> > >
> > > - if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
> > > + if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5) {
> > > + netif_device_attach(net);
> > > return net_device;
> > > + }
> >
> > Yes, this looks right, but it might be easier to use goto existing
> > exit
> > path.
> >
>
> I was just not sure if we should set max_chn and num_chn here. I will
> modify the patch and resend.
On older code it was just a goto. At that point: num_chn = max_chn = 1
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [bpf-next v2 0/9] bpf: Add helper to do FIB lookups
From: Daniel Borkmann @ 2018-05-08 23:53 UTC (permalink / raw)
To: David Ahern, netdev, borkmann, ast
Cc: davem, shm, roopa, brouer, toke, john.fastabend
In-Reply-To: <20180504025432.23451-1-dsahern@gmail.com>
On 05/04/2018 04:54 AM, David Ahern wrote:
> Provide a helper for doing a FIB and neighbor lookup in the kernel
> tables from an XDP program. The helper provides a fastpath for forwarding
> packets. If the packet is a local delivery or for any reason is not a
> simple lookup and forward, the packet is expected to continue up the stack
> for full processing.
>
> The response from a FIB and neighbor lookup is either the egress index
> with the bpf_fib_lookup struct filled in with dmac and gateway or
> 0 meaning the packet should continue up the stack. In time we can
> revisit this to return the FIB lookup result errno if it is one of the
> special RTN_'s such as RTN_BLACKHOLE (-EINVAL) so that the XDP
> programs can do an early drop if desired.
>
> Patches 1-6 do some more refactoring to IPv6 with the end goal of
> extracting a FIB lookup function that aligns with fib_lookup for IPv4,
> basically returning a fib6_info without creating a dst based entry.
>
> Patch 7 adds lookup functions to the ipv6 stub. These are needed since
> bpf is built into the kernel and ipv6 may not be built or loaded.
>
> Patch 8 adds the bpf helper and 9 adds a sample program.
>
> v2
> - removed pkt_access from bpf_func_proto as noticed by Daniel
> - added check in that IPv6 forwarding is enabled
> - added DaveM's ack on patches 1-7 and 9 based on v1 response and
> fact that no changes were made to them in v2
>
> v1
> - updated commit messages and cover letter
> - added comment to sample program noting lack of verification on
> egress device supporting XDP
>
> RFC v2
> - fixed use of foward helper from cls_act as noted by Daniel
> - in patch 1 rename fib6_lookup_1 as well for consistency
Applied to bpf-next, thanks David.
^ permalink raw reply
* Re: Failed to clone net-next.git
From: David Miller @ 2018-05-09 0:04 UTC (permalink / raw)
To: songliubraving; +Cc: netdev, ast, konstantin
In-Reply-To: <FB252D9C-2FB2-437C-8646-4F61406AC96D@fb.com>
From: Song Liu <songliubraving@fb.com>
Date: Tue, 8 May 2018 17:46:23 +0000
> We are seeing the following error on multiple different systems while
> cloning net-next tree.
>
> $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> Cloning into 'net-next'...
Regardless of the failure, it is so _insanely_ wasteful to clone my
trees like this.
Just simply always have Linus's tree always checked out somewhere:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Let's say you have it under src/GIT/linux as I do.
Then go to src/GIT and say:
git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
This way it only downloads the objects that are unique to the net-next
tree. Similarly for 'net':
git clone --reference linux/.git https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Or any other subsystem tree.
Periodically "git pull --ff-only" your Linus's tree, and you'll be
much happier in GIT land :-)
As subsystem changes make their way into Linus's GIT tree, git will
notice over time and garbage collect the dups that are in your
subsystem GIT trees.
^ permalink raw reply
* Re: pull-request: ieee802154 2018-05-08
From: David Miller @ 2018-05-09 0:06 UTC (permalink / raw)
To: stefan; +Cc: s.schmidt, linux-wpan, alex.aring, netdev
In-Reply-To: <a61fa7c3-fa57-535c-7f00-b495d0a46bb0@osg.samsung.com>
From: Stefan Schmidt <stefan@osg.samsung.com>
Date: Tue, 8 May 2018 21:55:37 +0200
> On 05/08/2018 04:18 PM, David Miller wrote:
>> Please submit the -stable fix directly, you can feel free to CC: me.
>
> Will do when the patch hits Linus git tree.
>
> I have a quick question on the process here. From the netdev-faq document
> I was under the impression all stable patches under net/ and drivers/net
> should be brought up to you and would be handled by you.
>
> Does this apply to the core part of net (I fully understand that ieee802154
> is rather a niche) or is there some other reason for this exception?
>
> Both processes (the normal stable one as well as the slightly different one
> for net/) would be fine to go with for me. Just need to know which one I
> should use for future stable patches. :-)
>
> regards
> Stefan Schmidt
Generally wireless and ipsec have been submitting them directly,
sometimes the Intel ethernet guys do too.
Sometimes this makes things easier for me, and I'll ask you to submit
things directly when that is the case like right now.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given
From: David Miller @ 2018-05-09 0:14 UTC (permalink / raw)
To: antoine.tenart
Cc: linux, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20180504152103.18152-1-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Fri, 4 May 2018 17:21:03 +0200
> When computing the bitrate using values read from an SFP module EEPROM,
> we use the nominal BR plus BR,min and BR,max to determine the
> boundaries. But in some cases BR,min and BR,max aren't provided, which
> led the SFP code to end up having the nominal value for both the minimum
> and maximum bitrate values. When using a passive cable, the nominal
> value should be used as the maximum one, and there is no minimum one
> so we should use 0.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: dsa: Plug in PHYLINK support
From: David Miller @ 2018-05-09 0:17 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, privat, andrew, vivien.didelot, rmk+kernel, sean.wang,
Woojung.Huh, john, cphealy
In-Reply-To: <20180505190425.14378-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Sat, 5 May 2018 12:04:16 -0700
> This patch series adds PHYLINK support to DSA which is necessary to
> support more complex PHY and pluggable modules setups.
The regression Andrew reported with patch #7 is holding up my
applying this series.
How would you like this to be handled? Are you going to respin
once Andrew sends you the fix?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: dsa: Plug in PHYLINK support
From: Florian Fainelli @ 2018-05-09 0:20 UTC (permalink / raw)
To: David Miller
Cc: netdev, privat, andrew, vivien.didelot, rmk+kernel, sean.wang,
Woojung.Huh, john, cphealy
In-Reply-To: <20180508.201709.1396958179924861550.davem@davemloft.net>
Le 05/08/18 à 17:17, David Miller a écrit :
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Sat, 5 May 2018 12:04:16 -0700
>
>> This patch series adds PHYLINK support to DSA which is necessary to
>> support more complex PHY and pluggable modules setups.
>
> The regression Andrew reported with patch #7 is holding up my
> applying this series.
>
> How would you like this to be handled? Are you going to respin
> once Andrew sends you the fix?
Andrew sent me the fix and I squashed it in patch 7, waiting for Russell
to give me his SoB for patch 3 since he originally sent that to me
privately and I changed it a bit.
Expect a v2 soon, should have made that clearer. Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Paul Moore @ 2018-05-09 0:25 UTC (permalink / raw)
To: Stephen Smalley
Cc: Alexey Kodanev, Richard Haines, selinux, Eric Paris,
linux-security-module, netdev
In-Reply-To: <1eb10913-8802-e2dd-68f0-9483435cd949@tycho.nsa.gov>
On Tue, May 8, 2018 at 2:40 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 05/08/2018 01:05 PM, Paul Moore wrote:
>> On Tue, May 8, 2018 at 10:05 AM, Alexey Kodanev
>> <alexey.kodanev@oracle.com> wrote:
>>> Commit d452930fd3b9 ("selinux: Add SCTP support") breaks compatibility
>>> with the old programs that can pass sockaddr_in with AF_UNSPEC and
>>> INADDR_ANY to bind(). As a result, bind() returns EAFNOSUPPORT error.
>>> It was found with LTP/asapi_01 test.
>>>
>>> Similar to commit 29c486df6a20 ("net: ipv4: relax AF_INET check in
>>> bind()"), which relaxed AF_INET check for compatibility, add AF_UNSPEC
>>> case to AF_INET and make sure that the address is INADDR_ANY.
>>>
>>> Also, in the end of selinux_socket_bind(), instead of adding AF_UNSPEC
>>> to 'address->sa_family == AF_INET', verify AF_INET6 first.
>>>
>>> Fixes: d452930fd3b9 ("selinux: Add SCTP support")
>>> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
>>> ---
>>> security/selinux/hooks.c | 12 +++++++++---
>>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> Thanks for finding and reporting this regression.
>>
>> I think I would prefer to avoid having to duplicate the
>> AF_UNSPEC/INADDR_ANY checking logic in the SELinux hook, even though
>> it is a small bit of code and unlikely to change. I'm wondering if it
>> would be better to check both the socket and sockaddr address family
>> in the main if conditional inside selinux_socket_bind(), what do you
>> think? Another option would be to go back to just checking the
>> soackaddr address family; we moved away from that for a reason which
>> escapes at the moment (code cleanliness?), but perhaps that was a
>> mistake.
>
> We've always used the sk->sk_family there; it was only the recent code from Richard that started
> using the socket address family.
Yes I know, I thought I was the one that suggested it at some point
(I'll take the blame) ... although now that I'm looking at the git
log, maybe I'm confusing it with something else.
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 4cafe6a19167..a3789b167667 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -4577,6 +4577,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
>> {
>> struct sock *sk = sock->sk;
>> u16 family;
>> + u16 family_sa;
>> int err;
>>
>> err = sock_has_perm(sk, SOCKET__BIND);
>> @@ -4585,7 +4586,9 @@ static int selinux_socket_bind(struct socket *sock, struc>
>>
>> /* If PF_INET or PF_INET6, check name_bind permission for the port. */
>> family = sk->sk_family;
>> - if (family == PF_INET || family == PF_INET6) {
>> + family_sa = address->sa_family;
>> + if ((family == PF_INET || family == PF_INET6) &&
>> + (family_sa == PF_INET || family_sa == PF_INET6)) {
>
> Wouldn't this allow bypassing the name_bind permission check by passing in AF_UNSPEC?
I believe these name_bind permission checkis skipped for AF_UNSPEC
already, isn't it? The only way the name_bind check would be
triggered is if the source port, snum, was non-zero and I didn't think
that was really legal for AF_UNSPEC/INADDR_ANY, is it?
>> char *addrp;
>> struct sk_security_struct *sksec = sk->sk_security;
>> struct common_audit_data ad;
>> @@ -4601,7 +4604,7 @@ static int selinux_socket_bind(struct socket *sock, struc>
>> * need to check address->sa_family as it is possible to have
>> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
>> */
>> - switch (address->sa_family) {
>> + switch (family_sa) {
>> case AF_INET:
>> if (addrlen < sizeof(struct sockaddr_in))
>> return -EINVAL;
>>
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 4cafe6a..649a3be 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -4602,10 +4602,16 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
>>> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
>>> */
>>> switch (address->sa_family) {
>>> + case AF_UNSPEC:
>>> case AF_INET:
>>> if (addrlen < sizeof(struct sockaddr_in))
>>> return -EINVAL;
>>> addr4 = (struct sockaddr_in *)address;
>>> +
>>> + if (address->sa_family == AF_UNSPEC &&
>>> + addr4->sin_addr.s_addr != htonl(INADDR_ANY))
>>> + return -EAFNOSUPPORT;
>>> +
>>> snum = ntohs(addr4->sin_port);
>>> addrp = (char *)&addr4->sin_addr.s_addr;
>>> break;
>>> @@ -4681,10 +4687,10 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
>>> ad.u.net->sport = htons(snum);
>>> ad.u.net->family = family;
>>>
>>> - if (address->sa_family == AF_INET)
>>> - ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>>> - else
>>> + if (address->sa_family == AF_INET6)
>>> ad.u.net->v6info.saddr = addr6->sin6_addr;
>>> + else
>>> + ad.u.net->v4info.saddr = addr4->sin_addr.s_addr;
>>>
>>> err = avc_has_perm(&selinux_state,
>>> sksec->sid, sid,
>>> --
>>> 1.8.3.1
>>>
>>
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC bpf-next 00/10] initial control flow support for eBPF verifier
From: David Miller @ 2018-05-09 0:28 UTC (permalink / raw)
To: jiong.wang
Cc: alexei.starovoitov, daniel, john.fastabend, netdev, oss-drivers
In-Reply-To: <1525688567-19618-1-git-send-email-jiong.wang@netronome.com>
From: Jiong Wang <jiong.wang@netronome.com>
Date: Mon, 7 May 2018 06:22:36 -0400
> This infrastructure comes with some memory usage and execution time cost.
> Memory pool based allocation is used to avoid frequently calling of
> kmalloc/free. Singly linked list and compact pointer are used to reduce
> various cfg node size.
The memory and execution time costs are unfortunate, but we will
certainly need a real control flow graph in the verifier whether we
like it or not.
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: dsa: Remove unnecessary #address/#size-cells
From: David Miller @ 2018-05-09 0:28 UTC (permalink / raw)
To: festevam; +Cc: f.fainelli, andrew, robh+dt, netdev, devicetree, fabio.estevam
In-Reply-To: <1525695471-19984-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Mon, 7 May 2018 09:17:51 -0300
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> If the example binding is used on a real dts file, the following DTC
> warning is seen with W=1:
>
> arch/arm/boot/dts/imx6q-b450v3.dtb: Warning (avoid_unnecessary_addr_size): /mdio-gpio/switch@0: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
>
> Remove unnecessary #address-cells/#size-cells to improve the binding
> document examples.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thank you.
^ permalink raw reply
* Re: [net-next 0/6][pull request] 100GbE Intel Wired LAN Driver Updates 2018-05-07
From: David Miller @ 2018-05-09 0:29 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180507144521.6979-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 7 May 2018 07:45:15 -0700
> This series contains updates to fm10k only.
Waiting for a respin after patch #2 is updated based upon feedback.
Thanks.
^ permalink raw reply
* [net-next 1/1] tipc: clean up removal of binding table items
From: Jon Maloy @ 2018-05-09 0:59 UTC (permalink / raw)
To: davem, netdev
Cc: mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen, hoang.h.le,
jon.maloy, canh.d.luu, ying.xue, tipc-discussion
In commit be47e41d77fb ("tipc: fix use-after-free in tipc_nametbl_stop")
we fixed a problem caused by premature release of service range items.
That fix is correct, and solved the problem. However, it doesn't address
the root of the problem, which is that we don't lookup the tipc_service
-> service_range -> publication items in the correct hierarchical
order.
In this commit we try to make this right, and as a side effect obtain
some code simplification.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
---
net/tipc/name_table.c | 103 ++++++++++++++++++++++++++------------------------
1 file changed, 53 insertions(+), 50 deletions(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index dd1c4fa..bebe88c 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -136,12 +136,12 @@ static struct tipc_service *tipc_service_create(u32 type, struct hlist_head *hd)
}
/**
- * tipc_service_find_range - find service range matching a service instance
+ * tipc_service_first_range - find first service range in tree matching instance
*
* Very time-critical, so binary search through range rb tree
*/
-static struct service_range *tipc_service_find_range(struct tipc_service *sc,
- u32 instance)
+static struct service_range *tipc_service_first_range(struct tipc_service *sc,
+ u32 instance)
{
struct rb_node *n = sc->ranges.rb_node;
struct service_range *sr;
@@ -158,6 +158,30 @@ static struct service_range *tipc_service_find_range(struct tipc_service *sc,
return NULL;
}
+/* tipc_service_find_range - find service range matching publication parameters
+ */
+static struct service_range *tipc_service_find_range(struct tipc_service *sc,
+ u32 lower, u32 upper)
+{
+ struct rb_node *n = sc->ranges.rb_node;
+ struct service_range *sr;
+
+ sr = tipc_service_first_range(sc, lower);
+ if (!sr)
+ return NULL;
+
+ /* Look for exact match */
+ for (n = &sr->tree_node; n; n = rb_next(n)) {
+ sr = container_of(n, struct service_range, tree_node);
+ if (sr->upper == upper)
+ break;
+ }
+ if (!n || sr->lower != lower || sr->upper != upper)
+ return NULL;
+
+ return sr;
+}
+
static struct service_range *tipc_service_create_range(struct tipc_service *sc,
u32 lower, u32 upper)
{
@@ -238,54 +262,19 @@ static struct publication *tipc_service_insert_publ(struct net *net,
/**
* tipc_service_remove_publ - remove a publication from a service
*/
-static struct publication *tipc_service_remove_publ(struct net *net,
- struct tipc_service *sc,
- u32 lower, u32 upper,
- u32 node, u32 key,
- struct service_range **rng)
+static struct publication *tipc_service_remove_publ(struct service_range *sr,
+ u32 node, u32 key)
{
- struct tipc_subscription *sub, *tmp;
- struct service_range *sr;
struct publication *p;
- bool found = false;
- bool last = false;
- struct rb_node *n;
-
- sr = tipc_service_find_range(sc, lower);
- if (!sr)
- return NULL;
- /* Find exact matching service range */
- for (n = &sr->tree_node; n; n = rb_next(n)) {
- sr = container_of(n, struct service_range, tree_node);
- if (sr->upper == upper)
- break;
- }
- if (!n || sr->lower != lower || sr->upper != upper)
- return NULL;
-
- /* Find publication, if it exists */
list_for_each_entry(p, &sr->all_publ, all_publ) {
if (p->key != key || (node && node != p->node))
continue;
- found = true;
- break;
+ list_del(&p->all_publ);
+ list_del(&p->local_publ);
+ return p;
}
- if (!found)
- return NULL;
-
- list_del(&p->all_publ);
- list_del(&p->local_publ);
- if (list_empty(&sr->all_publ))
- last = true;
-
- /* Notify any waiting subscriptions */
- list_for_each_entry_safe(sub, tmp, &sc->subscriptions, service_list) {
- tipc_sub_report_overlap(sub, p->lower, p->upper, TIPC_WITHDRAWN,
- p->port, p->node, p->scope, last);
- }
- *rng = sr;
- return p;
+ return NULL;
}
/**
@@ -376,17 +365,31 @@ struct publication *tipc_nametbl_remove_publ(struct net *net, u32 type,
u32 node, u32 key)
{
struct tipc_service *sc = tipc_service_find(net, type);
+ struct tipc_subscription *sub, *tmp;
struct service_range *sr = NULL;
struct publication *p = NULL;
+ bool last;
if (!sc)
return NULL;
spin_lock_bh(&sc->lock);
- p = tipc_service_remove_publ(net, sc, lower, upper, node, key, &sr);
+ sr = tipc_service_find_range(sc, lower, upper);
+ if (!sr)
+ goto exit;
+ p = tipc_service_remove_publ(sr, node, key);
+ if (!p)
+ goto exit;
+
+ /* Notify any waiting subscriptions */
+ last = list_empty(&sr->all_publ);
+ list_for_each_entry_safe(sub, tmp, &sc->subscriptions, service_list) {
+ tipc_sub_report_overlap(sub, lower, upper, TIPC_WITHDRAWN,
+ p->port, node, p->scope, last);
+ }
/* Remove service range item if this was its last publication */
- if (sr && list_empty(&sr->all_publ)) {
+ if (list_empty(&sr->all_publ)) {
rb_erase(&sr->tree_node, &sc->ranges);
kfree(sr);
}
@@ -396,6 +399,7 @@ struct publication *tipc_nametbl_remove_publ(struct net *net, u32 type,
hlist_del_init_rcu(&sc->service_list);
kfree_rcu(sc, rcu);
}
+exit:
spin_unlock_bh(&sc->lock);
return p;
}
@@ -437,7 +441,7 @@ u32 tipc_nametbl_translate(struct net *net, u32 type, u32 instance, u32 *dnode)
goto not_found;
spin_lock_bh(&sc->lock);
- sr = tipc_service_find_range(sc, instance);
+ sr = tipc_service_first_range(sc, instance);
if (unlikely(!sr))
goto no_match;
@@ -484,7 +488,7 @@ bool tipc_nametbl_lookup(struct net *net, u32 type, u32 instance, u32 scope,
spin_lock_bh(&sc->lock);
- sr = tipc_service_find_range(sc, instance);
+ sr = tipc_service_first_range(sc, instance);
if (!sr)
goto no_match;
@@ -756,8 +760,7 @@ static void tipc_service_delete(struct net *net, struct tipc_service *sc)
spin_lock_bh(&sc->lock);
rbtree_postorder_for_each_entry_safe(sr, tmpr, &sc->ranges, tree_node) {
list_for_each_entry_safe(p, tmp, &sr->all_publ, all_publ) {
- tipc_service_remove_publ(net, sc, p->lower, p->upper,
- p->node, p->key, &sr);
+ tipc_service_remove_publ(sr, p->node, p->key);
kfree_rcu(p, rcu);
}
rb_erase(&sr->tree_node, &sc->ranges);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH ghak81 RFC V1 2/5] audit: convert sessionid unset to a macro
From: Richard Guy Briggs @ 2018-05-09 1:34 UTC (permalink / raw)
To: Linux-Audit Mailing List, LKML,
Linux NetDev Upstream Mailing List, Netfilter Devel List,
Linux Security Module list, Integrity Measurement Architecture,
SElinux list
Cc: David Howells, Ingo Molnar
In-Reply-To: <91fd13c7a66718dc827d299fa101883e5d0a864f.1525466167.git.rgb@redhat.com>
On 2018-05-04 16:54, Richard Guy Briggs wrote:
> Use a macro, "AUDIT_SID_UNSET", to replace each instance of
> initialization and comparison to an audit session ID.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
There's a minor issue with this patch, adding a header include to
init/init_task.c in this patch and removing it from patch 5. That'll be
in the next revision.
I have dynamic allocation working, so that has a good chance of
appearing too.
> ---
> include/linux/audit.h | 2 +-
> include/net/xfrm.h | 2 +-
> include/uapi/linux/audit.h | 1 +
> init/init_task.c | 2 +-
> kernel/auditsc.c | 4 ++--
> 5 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 75d5b03..5f86f7c 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -513,7 +513,7 @@ static inline kuid_t audit_get_loginuid(struct task_struct *tsk)
> }
> static inline unsigned int audit_get_sessionid(struct task_struct *tsk)
> {
> - return -1;
> + return AUDIT_SID_UNSET;
> }
> static inline void audit_ipc_obj(struct kern_ipc_perm *ipcp)
> { }
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index a872379..fcce8ee 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -751,7 +751,7 @@ static inline void xfrm_audit_helper_usrinfo(bool task_valid,
> audit_get_loginuid(current) :
> INVALID_UID);
> const unsigned int ses = task_valid ? audit_get_sessionid(current) :
> - (unsigned int) -1;
> + AUDIT_SID_UNSET;
>
> audit_log_format(audit_buf, " auid=%u ses=%u", auid, ses);
> audit_log_task_context(audit_buf);
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 4e61a9e..04f9bd2 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -465,6 +465,7 @@ struct audit_tty_status {
> };
>
> #define AUDIT_UID_UNSET (unsigned int)-1
> +#define AUDIT_SID_UNSET ((unsigned int)-1)
>
> /* audit_rule_data supports filter rules with both integer and string
> * fields. It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and
> diff --git a/init/init_task.c b/init/init_task.c
> index 3ac6e75..c788f91 100644
> --- a/init/init_task.c
> +++ b/init/init_task.c
> @@ -119,7 +119,7 @@ struct task_struct init_task
> .thread_node = LIST_HEAD_INIT(init_signals.thread_head),
> #ifdef CONFIG_AUDITSYSCALL
> .loginuid = INVALID_UID,
> - .sessionid = (unsigned int)-1,
> + .sessionid = AUDIT_SID_UNSET,
> #endif
> #ifdef CONFIG_PERF_EVENTS
> .perf_event_mutex = __MUTEX_INITIALIZER(init_task.perf_event_mutex),
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f3817d0..6e3ceb9 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -2050,7 +2050,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, kuid_t kloginuid,
> int audit_set_loginuid(kuid_t loginuid)
> {
> struct task_struct *task = current;
> - unsigned int oldsessionid, sessionid = (unsigned int)-1;
> + unsigned int oldsessionid, sessionid = AUDIT_SID_UNSET;
> kuid_t oldloginuid;
> int rc;
>
> @@ -2064,7 +2064,7 @@ int audit_set_loginuid(kuid_t loginuid)
> /* are we setting or clearing? */
> if (uid_valid(loginuid)) {
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> - if (unlikely(sessionid == (unsigned int)-1))
> + if (unlikely(sessionid == AUDIT_SID_UNSET))
> sessionid = (unsigned int)atomic_inc_return(&session_id);
> }
>
> --
> 1.8.3.1
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH bpf-next v3 3/6] bpf: Add IPv6 Segment Routing helpers
From: Alexei Starovoitov @ 2018-05-09 1:57 UTC (permalink / raw)
To: Mathieu Xhonneux; +Cc: David Lebrun, netdev, David Miller
In-Reply-To: <CAKSCvkSNFDvRXXBV9GkxzbiQgZikRriKSD5tnhjsyx99m_x3Ww@mail.gmail.com>
On Mon, May 07, 2018 at 11:21:11PM +0100, Mathieu Xhonneux wrote:
> I'm not sure what would be the best approach here. These errors appear
> when CONFIG_IPV6=m and CONFIG_IPV6_SEG6_LWTUNNEL=y (which is bool and
> depends on IPv6, hence it is also modularized in this case), then
> IS_ENABLED(CONFIG_IPV6_SEG6_LWTUNNEL) returns true, even though the
> seg6_* symbols are not available when linking vmlinux. If I'm correct,
> since net/core/filter.c is always built-in, all functions it uses must
> also be built-in.
>
> I didn't find any other dependency from net/core/filter.c using a
> feature which can be modularized, hence the only solution I see here
> is to create a new bool CONFIG variable, e.g. CONFIG_IPV6_SEG6_BPF,
> which would require CONFIG_IPV6=y and CONFIG_IPV6_SEG6_LWTUNNEL=y. I
> could then replace my #if IS_ENABLED(CONFIG_IPV6_SEG6_LWTUNNEL)
> conditions by #if IS_ENABLED(CONFIG_IPV6_SEG6_BPF) in
> net/core/filter.c.
Requiring CONFIG_IPV6=y for this feature would unfortunate.
I think the least ugliest solution would be to add seg6 functions
to ipv6_bpf_stub and call them indirectly if they are not
in critical path.
If it is the fast path then CONFIG_IPV6=y is the only option,
but don't expose the new CONFIG_IPV6_SEG6_BPF to the user.
Make it automatic y/n depending on CONFIG_IPV6=y or (n|m)
> Any comment on this ?
>
> Thanks.
>
> 2018-05-07 0:29 GMT+01:00 kbuild test robot <lkp@intel.com>:
> > Hi Mathieu,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on bpf-next/master]
> >
> > url: https://github.com/0day-ci/linux/commits/Mathieu-Xhonneux/ipv6-sr-introduce-seg6local-End-BPF-action/20180506-233046
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
> > config: s390-allmodconfig (attached as .config)
> > compiler: s390x-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=s390
> >
> > All errors (new ones prefixed by >>):
> >
> > net/core/filter.o: In function `bpf_push_seg6_encap':
> > filter.c:(.text+0xaf4c): undefined reference to `seg6_validate_srh'
> > filter.c:(.text+0xaf8a): undefined reference to `seg6_do_srh_inline'
> > filter.c:(.text+0xafc4): undefined reference to `seg6_do_srh_encap'
> > filter.c:(.text+0xb016): undefined reference to `seg6_lookup_nexthop'
> > net/core/filter.o: In function `bpf_lwt_seg6_store_bytes':
> >>> (.text+0xb106): undefined reference to `seg6_bpf_srh_states'
> > net/core/filter.o: In function `bpf_lwt_seg6_action':
> > (.text+0xb2b0): undefined reference to `seg6_bpf_srh_states'
> >>> (.text+0xb334): undefined reference to `seg6_validate_srh'
> >>> (.text+0xb394): undefined reference to `seg6_lookup_nexthop'
> > (.text+0xb3c4): undefined reference to `seg6_lookup_nexthop'
> > net/core/filter.o: In function `bpf_lwt_seg6_adjust_srh':
> > (.text+0xb492): undefined reference to `seg6_bpf_srh_states'
> >
> > ---
> > 0-DAY kernel test infrastructure Open Source Technology Center
> > https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH ghak81 RFC V1 4/5] audit: use inline function to set audit context
From: Tobin C. Harding @ 2018-05-09 2:07 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Linux-Audit Mailing List, LKML,
Linux NetDev Upstream Mailing List, Netfilter Devel List,
Linux Security Module list, Integrity Measurement Architecture,
SElinux list, Eric Paris, Paul Moore, Steve Grubb, Ingo Molnar,
David Howells
In-Reply-To: <2f0566af8ccafdaf400a3d002cb4aef9b80e44cf.1525466167.git.rgb@redhat.com>
On Fri, May 04, 2018 at 04:54:37PM -0400, Richard Guy Briggs wrote:
> Recognizing that the audit context is an internal audit value, use an
> access function to set the audit context pointer for the task
> rather than reaching directly into the task struct to set it.
>
> Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> include/linux/audit.h | 8 ++++++++
> kernel/auditsc.c | 6 +++---
> kernel/fork.c | 2 +-
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 93e4c61..dba0d45 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -235,6 +235,10 @@ extern void __audit_inode_child(struct inode *parent,
> extern void __audit_seccomp(unsigned long syscall, long signr, int code);
> extern void __audit_ptrace(struct task_struct *t);
>
> +static inline void audit_set_context(struct task_struct *task, struct audit_context *ctx)
> +{
> + task->audit_context = ctx;
> +}
> static inline struct audit_context *audit_context(struct task_struct *task)
> {
> return task->audit_context;
> @@ -472,6 +476,10 @@ static inline bool audit_dummy_context(void)
> {
> return true;
> }
> +static inline void audit_set_context(struct task_struct *task, struct audit_context *ctx)
> +{
> + task->audit_context = ctx;
> +}
If audit_context is an internal audit value why do we set it when
CONFIG_AUDITSYSCALL is not set?
thanks,
Tobin.
^ permalink raw reply
* pull-request Cavium liquidio firmware v1.7.2
From: Felix Manlunas @ 2018-05-09 2:21 UTC (permalink / raw)
To: linux-firmware
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
felix.manlunas
The following changes since commit 8fc2d4e55685bf73b6f7752383da9067404a74bb:
Merge git://git.marvell.com/mwifiex-firmware (2018-05-07 09:09:40 -0400)
are available in the git repository at:
https://github.com/felix-cavium/linux-firmware.git for-upstreaming-v1.7.2
for you to fetch changes up to d3b6941e1a85cbff895a92aa9e36b50deaeac970:
linux-firmware: liquidio: update firmware to v1.7.2 (2018-05-08 19:02:41 -0700)
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
----------------------------------------------------------------
Felix Manlunas (1):
linux-firmware: liquidio: update firmware to v1.7.2
WHENCE | 8 ++++----
liquidio/lio_210nv_nic.bin | Bin 1265368 -> 1281464 bytes
liquidio/lio_210sv_nic.bin | Bin 1163128 -> 1179352 bytes
liquidio/lio_23xx_nic.bin | Bin 1271456 -> 1287264 bytes
liquidio/lio_410nv_nic.bin | Bin 1265368 -> 1281464 bytes
5 files changed, 4 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Cong Wang @ 2018-05-09 2:24 UTC (permalink / raw)
To: Michel Machado
Cc: Nishanth Devarajan, Jiri Pirko, Jamal Hadi Salim, David Miller,
Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <273f91db-7a2f-acda-b306-5a78dd948478@digirati.com.br>
On Tue, May 8, 2018 at 5:59 AM, Michel Machado <michel@digirati.com.br> wrote:
>>> Overall it looks good to me, just one thing below:
>>>
>>>> +struct Qdisc_ops gkprio_qdisc_ops __read_mostly = {
>>>> + .id = "gkprio",
>>>> + .priv_size = sizeof(struct gkprio_sched_data),
>>>> + .enqueue = gkprio_enqueue,
>>>> + .dequeue = gkprio_dequeue,
>>>> + .peek = qdisc_peek_dequeued,
>>>> + .init = gkprio_init,
>>>> + .reset = gkprio_reset,
>>>> + .change = gkprio_change,
>>>> + .dump = gkprio_dump,
>>>> + .destroy = gkprio_destroy,
>>>> + .owner = THIS_MODULE,
>>>> +};
>>>
>>>
>>> You probably want to add Qdisc_class_ops here so that you can
>>> dump the stats of each internal queue.
>
>
> Hi Cong,
>
> In the production scenario we are targeting, this priority queue must be
> classless; being classful would only bloat the code for us. I don't see
> making this queue classful as a problem per se, but I suggest leaving it as
> a future improvement for when someone can come up with a useful scenario for
> it.
Take a look at sch_prio, it is fairly simple since your internal
queues are just an array... Per-queue stats are quite useful
in production, we definitely want to observe which queues are
full which are not.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper
From: Alexei Starovoitov @ 2018-05-09 2:25 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Eric Paris, Matthew Auld, Josh Triplett, Kirill A. Shutemov,
Joonas Lahtinen, Chris Wilson, Stephen Smalley, Eric W. Biederman,
Mimi Zohar, Alexei Starovoitov, davem, daniel, torvalds, gregkh,
luto, netdev, linux-kernel, kernel-team, Al Viro, David Howells,
Kees Cook, Andrew Morton
In-Reply-To: <20180507183931.GV27853@wotan.suse.de>
On Mon, May 07, 2018 at 06:39:31PM +0000, Luis R. Rodriguez wrote:
>
> > Are you saying make 'static struct vfsmount *shm_mnt;'
> > global and use it here? so no init_tmpfs() necessary?
> > I think that can work, but feels that having two
> > tmpfs mounts (one for shmem and one for umh) is cleaner.
>
> No, but now that you mention it... if a shared vfsmount is not used the
> /sys/kernel/mm/transparent_hugepage/shmem_enabled knob for using huge pages
> would not be followed for umh modules. For the i915 driver this was *why*
> they ended up adding shmem_file_setup_with_mnt(), they wanted huge pages to
> support huge-gtt-pages. What is the rationale behind umh.c using it for
> umh modules?
>
> Users of shmem_kernel_file_setup() spawned later out of the desire to
> *avoid* LSMs since it didn't make sense in their case as their inodes
> are never exposed to userspace. Such is the case for ipc/shm.c and
> security/keys/big_key.c. Refer to commit c7277090927a5 ("security: shmem:
> implement kernel private shmem inodes") and then commit e1832f2923ec9
> ("ipc: use private shmem or hugetlbfs inodes for shm segments").
>
> In this new umh usermode modules case we are:
>
> a) actually mapping data already extracted by the kernel somehow from
> a file somehow, presumably from /lib/modules/ path somewhere, but
> again this is not visible to umc.c, as it just gets called with:
>
> fork_usermode_blob(void *data, size_t len, struct umh_info *info)
>
> b) Creating the respective tmpfs file with shmem_file_setup_with_mnt()
> with our on our own shared struct vfsmount *umh_fs.
>
> c) Populating the file created and stuffing it with our data passed
>
> d) Calling do_execve_file() on it.
>
> Its not clear to me why you used shmem_file_setup_with_mnt() in this case. What
> are the gains? It would make sense to use shmem_kernel_file_setup() to avoid an
> LSM check on step b) *but* only if we already had a proper LSM check on step
> a).
>
> I checked how you use fork_usermode_blob() in a) and in this case the kernel
> module bpfilter would be loaded first, and for that we already have an LSM
> check / hook for that module. From my review then, the magic done on your
> second patch to stuff the userspace application into the module should be
> irrelevant to us from an LSM perspective.
>
> So, I can see a reason to use shmem_kernel_file_setup() but not I cannot
> see a reason to be using shmem_file_setup_with_mnt() at the moment.
That's a good idea. I will switch to using shmem_kernel_file_setup().
I guess I can use kernel_write() as well instead of populate_file().
I wonder why i915 had to use pagecache_write_begin() and the loop
instead of kernel_write()...
The only reason to copy into tmpfs file is to make that memory swappable.
All standard shmem knobs should apply.
> > > > +{
> > > > + size_t offset = 0;
> > > > + int err;
> > > > +
> > > > + do {
> > > > + unsigned int len = min_t(typeof(size), size, PAGE_SIZE);
> > > > + struct page *page;
> > > > + void *pgdata, *vaddr;
> > > > +
> > > > + err = pagecache_write_begin(file, file->f_mapping, offset, len,
> > > > + 0, &page, &pgdata);
> > > > + if (err < 0)
> > > > + goto fail;
> > > > +
> > > > + vaddr = kmap(page);
> > > > + memcpy(vaddr, data, len);
> > > > + kunmap(page);
> > > > +
> > > > + err = pagecache_write_end(file, file->f_mapping, offset, len,
> > > > + len, page, pgdata);
> > > > + if (err < 0)
> > > > + goto fail;
> > > > +
> > > > + size -= len;
> > > > + data += len;
> > > > + offset += len;
> > > > + } while (size);
> > >
> > > Character for character, this looks like a wonderful copy and paste from
> > > i915_gem_object_create_from_data()'s own loop which does the same exact
> > > thing. Perhaps its time for a helper on mm/filemap.c with an export so
> > > if a bug is fixed in one place its fixed in both places.
> >
> > yes, of course, but not right now.
> > Once it all lands that will be the time to create common helper.
> > It's not a good idea to mess with i915 in one patch set.
>
> Either way works with me, so long as its done.
Will be gone due to switch to kernel_write().
>
> > > > +int fork_usermode_blob(void *data, size_t len, struct umh_info *info)
> > >
> > > Please use umh_fork_blob()
> >
> > sorry, no. fork_usermode_blob() is much more descriptive name.
>
> Prefixing new umh.c symbols with umh_*() makes it very clear this came from
> kernel/umh.c functionality. I've been dealing with other places in the kernel
> that have conflated their own use of kernel/umh.c functionality what they
> expose in both code and documentation, and correcting this has taken a long
> time. Best avoid future confusion and be consistent with new exported symbols
> for umc.c functionality.
There is no confusion today. The most known umh api is a family of
call_usermodehelper*()
In this case it's not a 'call', it's a 'fork', since part of kernel module
being forked as user mode process.
I considered naming this function fork_usermodehelper(),
but it's also not quite correct, since 'user mode helper' has predefined
meaning of something that has the path whereas here it's a blob of bytes.
Hence fork_usermode_blob() is more accurate and semantically correct name,
whereas umh_fork_blob() is not.
Notice I no longer call these new kernel modules as 'umh modules',
since that's the wrong name for the same reasons.
They are good ol' kernel modules.
The new functionality allowed by this patch is:
forking part of kernel module data as user mode process.
A lot of umh logic is reused, but 'user mode helpers' and
'user mode blobs' are distinct kernel features.
> I don't even want to test USB, I am just interesting in the *very* *very*
> basic aspects of it. A simple lib/test_umh_module.c would do with a respective
> check that its loaded, given this is a requirement from the API. It also helps
> folks understand the core basic knobs without having to look at bfilter code.
I agree that lib/test_usermode_blob.c must be available eventually.
Right now we cannot add it to the tree, since we need to figure how interface
between kernel and usermode_blob will work based on real world use case
of bpfilter. Once it gets further along that would be the time to say:
"look, here is the test for fork_usermode_blob() and here how others (usb drivers)
can and should use it".
Today is not the right time to fix the api. Such lib/test_usermode_blob.c
would have to be constantly adjusted as we tweak bpfilter side becoming
unnecessary burden of us bpfilter developers.
Everyone really need to think of these patches as work in progress
and internal details and api of fork_usermode_blob() will change.
^ permalink raw reply
* Re: [PATCH net-next] net:sched: add gkprio scheduler
From: Cong Wang @ 2018-05-09 2:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Michel Machado, Nishanth Devarajan, Jiri Pirko, David Miller,
Linux Kernel Network Developers, Cody Doucette
In-Reply-To: <2855ce67-f1bc-c04c-81ae-70ae3fdc6b17@mojatatu.com>
On Tue, May 8, 2018 at 6:29 AM, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> Have you considered using skb->prio instead of peeking into the packet
> header.
> Also have you looked at the dsmark qdisc?
>
dsmark modifies ds fields, while this one just maps ds fields into
different queues.
^ permalink raw reply
* Re: [PATCH net-next v10 3/4] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: David Miller @ 2018-05-09 2:28 UTC (permalink / raw)
To: steven.hill; +Cc: netdev, cmunoz, david.daney
In-Reply-To: <1525713731-27092-4-git-send-email-steven.hill@cavium.com>
From: "Steven J. Hill" <steven.hill@cavium.com>
Date: Mon, 7 May 2018 12:22:10 -0500
> +static atomic_t request_mgmt_once;
> +static atomic_t load_driver_once;
> +static atomic_t pki_id;
...
> + /* One time request driver module */
> + if (is_mix) {
> + if (atomic_cmpxchg(&request_mgmt_once, 0, 1) == 0)
> + request_module_nowait("octeon_mgmt");
> + }
> + if (is_pki) {
> + if (atomic_cmpxchg(&load_driver_once, 0, 1) == 0)
> + request_module_nowait("octeon3-ethernet");
> + }
You're going to have to explain this, it makes no sense to me.
> +static int bgx_pki_ports_init(void)
> +{
> + int i;
> + int j;
> + int k;
"int i, j, k;" please.
> +static int bgx_port_xgmii_set_link_up(struct bgx_port_priv *priv)
> +{
> + u64 data;
> + int timeout;
Please order from longest to shortest line for variable declarations.
> +static int bgx_port_sgmii_set_link_speed(struct bgx_port_priv *priv,
> + struct port_status status)
> +{
> + int timeout;
> + u64 miscx;
> + u64 data;
> + u64 prtx;
Please use "u64 miscx, data, prtx;" and put it on the first line.
> +static struct port_status bgx_port_get_xaui_link(struct bgx_port_priv *priv)
> +{
> + struct port_status status;
> + int lanes;
> + int speed;
> + u64 data;
"int lanes, speed;"
> +static int bgx_port_gser_27882(struct bgx_port_priv *priv)
> +{
> + int timeout;
> + u64 addr;
> + u64 data;
"u64 addr, data;" and move to first line.
> +static int bgx_port_qlm_rx_equalization(struct bgx_port_priv *priv,
> + int qlm, int lane)
> +{
> + int max_lanes = bgx_port_get_max_qlm_lanes(qlm);
> + int lane_mask;
> + int timeout;
> + int rc = 0;
> + u64 lmode;
> + u64 addr;
> + u64 data;
> + int i;
Please group these local variables. Have some pity for people who
have not so much vertical space on their screen when they are reading
your code. :)
> +static int bgx_port_init_xaui_link(struct bgx_port_priv *priv)
> +{
> + int use_training = 0;
> + int use_ber = 0;
> + int timeout;
> + int rc = 0;
> + u64 data;
Please group the int variables into a smaller number of lines.
> + /* Wait for mac rx to be ready */
> + timeout = 10000;
> + do {
> + data = oct_csr_read(BGX_SMU_RX_CTL(priv->node, priv->bgx, priv->index));
> + data &= GENMASK_ULL(1, 0);
> + if (!data)
> + break;
> + timeout--;
> + udelay(1);
> + } while (timeout);
This construct is repeated so many times, over and over. Make a helper
function that performs this operation.
> +static void bgx_port_adjust_link(struct net_device *netdev)
> +{
> + struct bgx_port_priv *priv = bgx_port_netdev2priv(netdev);
> + bool link_changed = false;
> + unsigned int duplex;
> + unsigned int speed;
> + unsigned int link;
Please group the unsigned ints.
> +static int bgx_port_probe(struct platform_device *pdev)
> +{
> + struct bgx_port_priv *priv;
> + const __be32 *reg;
> + const u8 *mac;
> + int numa_node;
> + u32 index;
> + u64 addr;
> + int rc;
Please group variables of the same time into one line.
> +static int __init bgx_port_driver_init(void)
> +{
> + int r;
> + int i;
> + int j;
> + int k;
"int r, i, j, k;"
> +static inline u64 scratch_read64(u64 offset)
Do not use "inline" for functions in foo.c files, let the compiler
decide.
> +static inline void scratch_write64(u64 offset, u64 value)
Likewise.
> +static inline struct wr_ret octeon3_core_get_work_sync(int grp)
> +{
> + u64 node = cvmx_get_node_num();
> + struct wr_ret r;
> + u64 response;
> + u64 addr;
"u64 response, addr;" Don't use inline.
> +static inline void octeon3_core_get_work_async(unsigned int grp)
> +{
Kill the inline.
> +static inline struct wr_ret octeon3_core_get_response_async(void)
Likewise.
> +static int octeon3_eth_tx_complete_hwtstamp(struct octeon3_ethernet *priv,
> + struct sk_buff *skb)
> +{
> + struct skb_shared_hwtstamps shts;
> + u64 hwts;
> + u64 ns;
"u64 hwts, ns;"
> +static int octeon3_eth_tx_complete_worker(void *data)
> +{
> + struct octeon3_ethernet_worker *worker = data;
> + struct octeon3_ethernet_node *oen;
> + int tx_complete_stop_thresh;
> + int backlog_stop_thresh;
> + int backlog;
> + u64 aq_cnt;
> + int order;
> + int i;
Group the variable declarations, please.
> +static int octeon3_eth_common_ndo_init(struct net_device *netdev,
> + int extra_skip)
> +{
> + struct octeon3_ethernet_node *oen;
> + int base_rx_grp[MAX_RX_QUEUES];
> + struct octeon3_ethernet *priv;
> + int pki_chan;
> + int aura;
> + int dq;
> + int i;
> + int r;
"int pki_chan, aura, dq, i, r;"
> +static void octeon3_eth_ndo_get_stats64(struct net_device *netdev,
> + struct rtnl_link_stats64 *s)
> +{
> + struct octeon3_ethernet *priv = netdev_priv(netdev);
> + u64 delta_packets;
> + u64 delta_dropped;
> + u64 delta_octets;
> + u64 dropped;
> + u64 packets;
> + u64 octets;
Group the u64s please.
> +static int octeon3_eth_common_ndo_open(struct net_device *netdev)
> +{
> + struct octeon3_ethernet *priv = netdev_priv(netdev);
> + struct octeon3_rx *rx;
> + int i;
> + int r;
"int i, r;"
> +static inline u64 build_pko_send_ext_desc(struct sk_buff *skb)
Kill the inline.
> +static inline u64 build_pko_send_tso(struct sk_buff *skb, uint mtu)
Likewise.
> +static inline u64 build_pko_send_mem_sub(u64 addr)
Likewise.
> +static inline u64 build_pko_send_mem_ts(u64 addr)
Likewise.
> +static inline u64 build_pko_send_free(u64 addr)
Likewise.
> +static inline u64 build_pko_send_work(int grp, u64 addr)
Likewise.
> +static int octeon3_eth_ndo_start_xmit(struct sk_buff *skb,
> + struct net_device *netdev)
> +{
> + struct octeon3_ethernet *priv = netdev_priv(netdev);
> + struct octeon3_ethernet_node *oen;
> + u64 scr_off = LMTDMA_SCR_OFFSET;
> + struct sk_buff *skb_tmp;
> + u64 pko_send_desc;
> + u64 *lmtdma_addr;
> + unsigned int mss;
> + u64 lmtdma_data;
> + u64 aq_cnt = 0;
> + int frag_count;
> + long backlog;
> + u64 head_len;
> + void **work;
> + int grp;
> + int i;
Please group these variables, this is crazy...
> +static int octeon3_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> +{
> + struct octeon3_ethernet *priv;
> + int neg_ppb = 0;
> + u64 comp;
> + u64 diff;
"u64 comp, diff;"
> +int octeon_fpa3_init(int node)
> +{
> + static bool init_done[2];
> + int aura_cnt;
> + u64 data;
> + int i;
"int aura_cnt, i; "
> +int octeon_fpa3_aura_init(int node, int pool, int aura_num,
> + int *aura, int num_bufs, unsigned int limit)
> +{
> + struct global_resource_tag tag;
> + unsigned int drop;
> + unsigned int pass;
> + char buf[16];
> + int rc = 0;
> + u64 shift;
> + u64 data;
"unsigned int drop, pass;"
"u64 shift, data;"
> +void *octeon_fpa3_alloc(int node, int aura)
> +{
> + void *buf = NULL;
> + u64 buf_phys;
> + u64 addr;
"u64 buf_phys, addr;"
> +void octeon_fpa3_free(int node, int aura, const void *buf)
> +{
> + u64 buf_phys;
> + u64 addr;
"u64 buf_phys, addr;"
> +int octeon_fpa3_mem_fill(int node, struct kmem_cache *cache,
> + int aura, int num_bufs)
> +{
> + void *mem;
> + int rc = 0;
> + int i;
"int i, rc = 0;"
> +static int octeon3_pki_pcam_alloc_entry(int node, int entry, int bank)
> +{
> + struct global_resource_tag tag;
> + char buf[16];
> + int num_clusters;
> + int rc;
> + int i;
"int num_clusters, rc, i;"
> +static int octeon3_pki_pcam_write_entry(int node,
> + struct pcam_term_info *term_info)
> +{
> + int num_clusters;
> + u64 action;
> + int entry;
> + u64 match;
> + int bank;
> + u64 term;
> + int i;
"u64 action, match, term;"
"int num_clusters, entry, bank, i;"
> +int octeon3_pki_set_ptp_skip(int node, int pknd, int skip)
> +{
> + int num_clusters;
> + u64 data;
> + u64 i;
"u64 data, i;"
That's all I have the stomache for at the moment.
This thing is really large, making it nearly impossible to review
as one huge patch #3. Perhaps you can find a way to split it up
logically somehow?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox