* [PATCH v6 03/13] firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: small coding style changes]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 8 ++++----
drivers/base/firmware_loader/fallback.h | 16 ++++++++--------
drivers/base/firmware_loader/firmware.h | 2 +-
drivers/base/firmware_loader/main.c | 2 +-
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 529f7013616f..3db9e0f225ac 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -662,10 +662,10 @@ static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
return fw_force_sysfs_fallback(opt_flags);
}
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret)
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret)
{
if (!fw_run_sysfs_fallback(opt_flags))
return ret;
diff --git a/drivers/base/firmware_loader/fallback.h b/drivers/base/firmware_loader/fallback.h
index a3b73a09db6c..21063503e4ea 100644
--- a/drivers/base/firmware_loader/fallback.h
+++ b/drivers/base/firmware_loader/fallback.h
@@ -31,10 +31,10 @@ struct firmware_fallback_config {
};
#ifdef CONFIG_FW_LOADER_USER_HELPER
-int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret);
+int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret);
void kill_pending_fw_fallback_reqs(bool only_kill_custom);
void fw_fallback_set_cache_timeout(void);
@@ -43,10 +43,10 @@ void fw_fallback_set_default_timeout(void);
int register_sysfs_loader(void);
void unregister_sysfs_loader(void);
#else /* CONFIG_FW_LOADER_USER_HELPER */
-static inline int fw_sysfs_fallback(struct firmware *fw, const char *name,
- struct device *device,
- enum fw_opt opt_flags,
- int ret)
+static inline int firmware_fallback_sysfs(struct firmware *fw, const char *name,
+ struct device *device,
+ enum fw_opt opt_flags,
+ int ret)
{
/* Keep carrying over the same error */
return ret;
diff --git a/drivers/base/firmware_loader/firmware.h b/drivers/base/firmware_loader/firmware.h
index 4f433b447367..4c1395f8e7ed 100644
--- a/drivers/base/firmware_loader/firmware.h
+++ b/drivers/base/firmware_loader/firmware.h
@@ -20,7 +20,7 @@
* @FW_OPT_NOWAIT: Used to describe the firmware request is asynchronous.
* @FW_OPT_USERHELPER: Enable the fallback mechanism, in case the direct
* filesystem lookup fails at finding the firmware. For details refer to
- * fw_sysfs_fallback().
+ * firmware_fallback_sysfs().
* @FW_OPT_NO_WARN: Quiet, avoid printing warning messages.
* @FW_OPT_NOCACHE: Disables firmware caching. Firmware caching is used to
* cache the firmware upon suspend, so that upon resume races against the
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index 4d11efadb3a4..abdc4e4d55f1 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -581,7 +581,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
dev_warn(device,
"Direct firmware load for %s failed with error %d\n",
name, ret);
- ret = fw_sysfs_fallback(fw, name, device, opt_flags, ret);
+ ret = firmware_fallback_sysfs(fw, name, device, opt_flags, ret);
} else
ret = assign_fw(fw, device, opt_flags);
--
2.17.0
^ permalink raw reply related
* [PATCH v6 04/13] firmware_loader: document firmware_sysfs_fallback()
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
This also sets the expecations for future fallback interfaces, even
if they are not exported.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 3db9e0f225ac..9169e7b9800c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -662,6 +662,26 @@ static bool fw_run_sysfs_fallback(enum fw_opt opt_flags)
return fw_force_sysfs_fallback(opt_flags);
}
+/**
+ * firmware_fallback_sysfs() - use the fallback mechanism to find firmware
+ * @fw: pointer to firmware image
+ * @name: name of firmware file to look for
+ * @device: device for which firmware is being loaded
+ * @opt_flags: options to control firmware loading behaviour
+ * @ret: return value from direct lookup which triggered the fallback mechanism
+ *
+ * This function is called if direct lookup for the firmware failed, it enables
+ * a fallback mechanism through userspace by exposing a sysfs loading
+ * interface. Userspace is in charge of loading the firmware through the syfs
+ * loading interface. This syfs fallback mechanism may be disabled completely
+ * on a system by setting the proc sysctl value ignore_sysfs_fallback to true.
+ * If this false we check if the internal API caller set the @FW_OPT_NOFALLBACK
+ * flag, if so it would also disable the fallback mechanism. A system may want
+ * to enfoce the sysfs fallback mechanism at all times, it can do this by
+ * setting ignore_sysfs_fallback to false and force_sysfs_fallback to true.
+ * Enabling force_sysfs_fallback is functionally equivalent to build a kernel
+ * with CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
+ **/
int firmware_fallback_sysfs(struct firmware *fw, const char *name,
struct device *device,
enum fw_opt opt_flags,
--
2.17.0
^ permalink raw reply related
* [PATCH v6 05/13] firmware_loader: enhance Kconfig documentation over FW_LOADER
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
If you try to read FW_LOADER today it speaks of old riddles and
unless you have been following development closely you will loose
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
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
+ 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"
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
+ 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.
+
+ 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:
+
+ 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
^ permalink raw reply related
* [PATCH v6 06/13] firmware_loader: move kconfig FW_LOADER entries to its own file
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/Kconfig | 155 +--------------------------
drivers/base/firmware_loader/Kconfig | 154 ++++++++++++++++++++++++++
2 files changed, 155 insertions(+), 154 deletions(-)
create mode 100644 drivers/base/firmware_loader/Kconfig
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index a4fe86caecca..06d6e27784fa 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -88,160 +88,7 @@ config PREVENT_FIRMWARE_BUILD
o CONFIG_WANXL through CONFIG_WANXL_BUILD_FIRMWARE
o CONFIG_SCSI_AIC79XX through CONFIG_AIC79XX_BUILD_FIRMWARE
-menu "Firmware loader"
-
-config FW_LOADER
- tristate "Firmware loading facility" if EXPERT
- default y
- ---help---
- 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 "Build these firmware blobs into the kernel binary"
- help
- 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
- over firmware lookups using your filesystem over the supported
- /lib/firmware paths documented on CONFIG_FW_LOADER.
-
- 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()
- and request_firmware() in the source. These files should exist under
- the directory specified by the EXTRA_FIRMWARE_DIR option, which is
- /lib/firmware by default.
-
- 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
- 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,
- then it may be a violation of the GPL to distribute the resulting
- image since it combines both GPL and non-GPL work. You should
- consult a lawyer of your own before distributing such an image.
-
-config EXTRA_FIRMWARE_DIR
- string "Firmware blobs root directory"
- depends on EXTRA_FIRMWARE != ""
- default "/lib/firmware"
- help
- This option controls the directory in which the kernel build system
- looks for the firmware files listed in the EXTRA_FIRMWARE option.
-
-config FW_LOADER_USER_HELPER
- 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.
-
- 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:
-
- 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 "Force the firmware sysfs fallback mechanism when possible"
- depends on FW_LOADER_USER_HELPER
- help
- 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
+source "drivers/base/firmware_loader/Kconfig"
config WANT_DEV_COREDUMP
bool
diff --git a/drivers/base/firmware_loader/Kconfig b/drivers/base/firmware_loader/Kconfig
new file mode 100644
index 000000000000..bff3606bc7fa
--- /dev/null
+++ b/drivers/base/firmware_loader/Kconfig
@@ -0,0 +1,154 @@
+menu "Firmware loader"
+
+config FW_LOADER
+ tristate "Firmware loading facility" if EXPERT
+ default y
+ ---help---
+ 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 "Build these firmware blobs into the kernel binary"
+ help
+ 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
+ over firmware lookups using your filesystem over the supported
+ /lib/firmware paths documented on CONFIG_FW_LOADER.
+
+ 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()
+ and request_firmware() in the source. These files should exist under
+ the directory specified by the EXTRA_FIRMWARE_DIR option, which is
+ /lib/firmware by default.
+
+ 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
+ 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,
+ then it may be a violation of the GPL to distribute the resulting
+ image since it combines both GPL and non-GPL work. You should
+ consult a lawyer of your own before distributing such an image.
+
+config EXTRA_FIRMWARE_DIR
+ string "Firmware blobs root directory"
+ depends on EXTRA_FIRMWARE != ""
+ default "/lib/firmware"
+ help
+ This option controls the directory in which the kernel build system
+ looks for the firmware files listed in the EXTRA_FIRMWARE option.
+
+config FW_LOADER_USER_HELPER
+ 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.
+
+ 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:
+
+ 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 "Force the firmware sysfs fallback mechanism when possible"
+ depends on FW_LOADER_USER_HELPER
+ help
+ 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
--
2.17.0
^ permalink raw reply related
* [PATCH v6 07/13] firmware_loader: make firmware_fallback_sysfs() print more useful
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
If we resort to using the sysfs fallback mechanism we don't print
the filename. This can be deceiving given we could have a series of
callers intertwined and it'd be unclear exactly for what firmware
this was meant for.
Additionally, although we don't currently use FW_OPT_NO_WARN when
dealing with the fallback mechanism, we will soon, so just respect
its use consistently.
And even if you *don't* want to print always on failure, you may
want to print when debugging so enable dynamic debug print when
FW_OPT_NO_WARN is used.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/base/firmware_loader/fallback.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/base/firmware_loader/fallback.c b/drivers/base/firmware_loader/fallback.c
index 9169e7b9800c..b676a99c469c 100644
--- a/drivers/base/firmware_loader/fallback.c
+++ b/drivers/base/firmware_loader/fallback.c
@@ -690,6 +690,11 @@ int firmware_fallback_sysfs(struct firmware *fw, const char *name,
if (!fw_run_sysfs_fallback(opt_flags))
return ret;
- dev_warn(device, "Falling back to user helper\n");
+ if (!(opt_flags & FW_OPT_NO_WARN))
+ dev_warn(device, "Falling back to syfs fallback for: %s\n",
+ name);
+ else
+ dev_dbg(device, "Falling back to sysfs fallback for: %s\n",
+ name);
return fw_load_from_user_helper(fw, name, device, opt_flags);
}
--
2.17.0
^ permalink raw reply related
* [PATCH v6 08/13] firmware: add firmware_request_nowarn() - load firmware without warnings
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
Currently the firmware loader only exposes one silent path for querying
optional firmware, and that is firmware_request_direct(). This function
also disables the sysfs fallback mechanism, which might not always be the
desired behaviour [0].
This patch introduces a variations of request_firmware() that enable the
caller to disable the undesired warning messages but enables the sysfs
fallback mechanism. This is equivalent to adding FW_OPT_NO_WARN to the
old behaviour.
[0]: https://git.kernel.org/linus/c0cc00f250e1
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
[mcgrof: used the old API calls as the full rename is not done yet, and
add the caller for when FW_LOADER is disabled, enhance documentation ]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/request_firmware.rst | 5 ++++
drivers/base/firmware_loader/main.c | 27 +++++++++++++++++++
include/linux/firmware.h | 10 +++++++
3 files changed, 42 insertions(+)
diff --git a/Documentation/driver-api/firmware/request_firmware.rst b/Documentation/driver-api/firmware/request_firmware.rst
index d5ec95a7195b..f62bdcbfed5b 100644
--- a/Documentation/driver-api/firmware/request_firmware.rst
+++ b/Documentation/driver-api/firmware/request_firmware.rst
@@ -20,6 +20,11 @@ request_firmware
.. kernel-doc:: drivers/base/firmware_loader/main.c
:functions: request_firmware
+firmware_request_nowarn
+-----------------------
+.. kernel-doc:: drivers/base/firmware_loader/main.c
+ :functions: firmware_request_nowarn
+
request_firmware_direct
-----------------------
.. kernel-doc:: drivers/base/firmware_loader/main.c
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c
index abdc4e4d55f1..2be79ee773c0 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -631,6 +631,33 @@ request_firmware(const struct firmware **firmware_p, const char *name,
}
EXPORT_SYMBOL(request_firmware);
+/**
+ * firmware_request_nowarn() - request for an optional fw module
+ * @firmware: pointer to firmware image
+ * @name: name of firmware file
+ * @device: device for which firmware is being loaded
+ *
+ * This function is similar in behaviour to request_firmware(), except
+ * it doesn't produce warning messages when the file is not found.
+ * The sysfs fallback mechanism is enabled if direct filesystem lookup fails,
+ * however, however failures to find the firmware file with it are still
+ * supressed. It is therefore up to the driver to check for the return value
+ * of this call and to decide when to inform the users of errors.
+ **/
+int firmware_request_nowarn(const struct firmware **firmware, const char *name,
+ struct device *device)
+{
+ int ret;
+
+ /* Need to pin this module until return */
+ __module_get(THIS_MODULE);
+ ret = _request_firmware(firmware, name, device, NULL, 0,
+ FW_OPT_UEVENT | FW_OPT_NO_WARN);
+ module_put(THIS_MODULE);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(firmware_request_nowarn);
+
/**
* request_firmware_direct() - load firmware directly without usermode helper
* @firmware_p: pointer to firmware image
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 41050417cafb..2dd566c91d44 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -42,6 +42,8 @@ struct builtin_fw {
#if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && defined(MODULE))
int request_firmware(const struct firmware **fw, const char *name,
struct device *device);
+int firmware_request_nowarn(const struct firmware **fw, const char *name,
+ struct device *device);
int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
@@ -59,6 +61,14 @@ static inline int request_firmware(const struct firmware **fw,
{
return -EINVAL;
}
+
+static inline int firmware_request_nowarn(const struct firmware **fw,
+ const char *name,
+ struct device *device)
+{
+ return -EINVAL;
+}
+
static inline int request_firmware_nowait(
struct module *module, bool uevent,
const char *name, struct device *device, gfp_t gfp, void *context,
--
2.17.0
^ permalink raw reply related
* [PATCH v6 09/13] ath10k: use firmware_request_nowarn() to load firmware
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 4cf54a7ef09a..ad4f6e3c0737 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -694,7 +694,7 @@ static const struct firmware *ath10k_fetch_fw_file(struct ath10k *ar,
dir = ".";
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
- ret = request_firmware(&fw, filename, ar->dev);
+ ret = firmware_request_nowarn(&fw, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
filename, ret);
--
2.17.0
^ permalink raw reply related
* [PATCH v6 10/13] ath10k: re-enable the firmware fallback mechanism for testmode
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
From: Andres Rodriguez <andresx7@gmail.com>
The ath10k testmode uses request_firmware_direct() in order to avoid
producing firmware load warnings. Disabling the fallback mechanism was a
side effect of disabling warnings.
We now have a new API that allows us to avoid warnings while keeping the
fallback mechanism enabled. So use that instead.
Signed-off-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 568810b41657..c24ee616833c 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -157,7 +157,7 @@ static int ath10k_tm_fetch_utf_firmware_api_1(struct ath10k *ar,
ar->hw_params.fw.dir, ATH10K_FW_UTF_FILE);
/* load utf firmware image */
- ret = request_firmware_direct(&fw_file->firmware, filename, ar->dev);
+ ret = firmware_request_nowarn(&fw_file->firmware, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode fw request '%s': %d\n",
filename, ret);
--
2.17.0
^ permalink raw reply related
* [PATCH v6 11/13] Documentation: fix few typos and clarifications for the firmware loader
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
Fix a few typos, and clarify a few sentences.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++--
Documentation/driver-api/firmware/firmware_cache.rst | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index f353783ae0be..a39323ef7d29 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -83,7 +83,7 @@ and a file upload firmware into:
* /sys/$DEVPATH/data
To upload firmware you will echo 1 onto the loading file to indicate
-you are loading firmware. You then cat the firmware into the data file,
+you are loading firmware. You then write the firmware into the data file,
and you notify the kernel the firmware is ready by echo'ing 0 onto
the loading file.
@@ -136,7 +136,8 @@ by kobject uevents. This is specially exacerbated due to the fact that most
distributions today disable CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
Refer to do_firmware_uevent() for details of the kobject event variables
-setup. Variables passwdd with a kobject add event:
+setup. The variables currently passed to userspace with a "kobject add"
+event are:
* FIRMWARE=firmware name
* TIMEOUT=timeout value
diff --git a/Documentation/driver-api/firmware/firmware_cache.rst b/Documentation/driver-api/firmware/firmware_cache.rst
index 2210e5bfb332..c2e69d9c6bf1 100644
--- a/Documentation/driver-api/firmware/firmware_cache.rst
+++ b/Documentation/driver-api/firmware/firmware_cache.rst
@@ -29,8 +29,8 @@ Some implementation details about the firmware cache setup:
* If an asynchronous call is used the firmware cache is only set up for a
device if if the second argument (uevent) to request_firmware_nowait() is
true. When uevent is true it requests that a kobject uevent be sent to
- userspace for the firmware request. For details refer to the Fackback
- mechanism documented below.
+ userspace for the firmware request through the sysfs fallback mechanism
+ if the firmware file is not found.
* If the firmware cache is determined to be needed as per the above two
criteria the firmware cache is setup by adding a devres entry for the
--
2.17.0
^ permalink raw reply related
* [PATCH v6 12/13] Documentation: remove stale firmware API reference
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
It refers to a pending patch, but this was merged eons ago.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
Documentation/dell_rbu.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 0fdb6aa2704c..077fdc29a0d0 100644
--- a/Documentation/dell_rbu.txt
+++ b/Documentation/dell_rbu.txt
@@ -121,9 +121,6 @@ read back the image downloaded.
.. note::
- This driver requires a patch for firmware_class.c which has the modified
- request_firmware_nowait function.
-
Also after updating the BIOS image a user mode application needs to execute
code which sends the BIOS update request to the BIOS. So on the next reboot
the BIOS knows about the new image downloaded and it updates itself.
--
2.17.0
^ permalink raw reply related
* [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module
From: Luis R. Rodriguez @ 2018-05-08 18:12 UTC (permalink / raw)
To: gregkh
Cc: akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, andresx7, zohar, kubakici,
shuah, mfuzzey, dhowells, pali.rohar, tiwai, kvalo,
arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, jewalt, oneukum,
cantabile.desu, ast, hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-1-mcgrof@kernel.org>
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
index a39323ef7d29..a8047be4a96e 100644
--- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by
associating the device used to make the request as the device's parent.
The sysfs directory's file attributes are defined and controlled through
the new device's class (firmware_class) and group (fw_dev_attr_groups).
-This is actually where the original firmware_class.c file name comes from,
-as originally the only firmware loading mechanism available was the
-mechanism we now use as a fallback mechanism.
+This is actually where the original firmware_class module name came from,
+given that originally the only firmware loading mechanism available was the
+mechanism we now use as a fallback mechanism, which which registers a
+struct class firmware_class. Because the attributes exposed are part of the
+module name, the module name firmware_class cannot be renamed in the future, to
+ensure backward compatibilty with old userspace.
To load firmware using the sysfs interface we expose a loading indicator,
and a file upload firmware into:
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] hv_netvsc: Fix net device attach on older Windows hosts
From: Stephen Hemminger @ 2018-05-08 18:13 UTC (permalink / raw)
To: Mohammed Gamal; +Cc: netdev, sthemmin, haiyangz, linux-kernel, devel, vkuznets
In-Reply-To: <1525801247-27765-1-git-send-email-mgamal@redhat.com>
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.
diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c
index 3b6dbacaf77d..ed941c5a0be9 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1316,7 +1316,7 @@ struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
rndis_device->link_state ? "down" : "up");
if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
- return net_device;
+ goto out;
rndis_filter_query_link_speed(rndis_device, net_device);
^ permalink raw reply related
* Re: [PATCH] hv_netvsc: Fix net device attach on older Windows hosts
From: Mohammed Gamal @ 2018-05-08 18:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, sthemmin, haiyangz, linux-kernel, devel, vkuznets
In-Reply-To: <20180508111323.1767fc0c@xeon-e3>
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.
> diff --git a/drivers/net/hyperv/rndis_filter.c
> b/drivers/net/hyperv/rndis_filter.c
> index 3b6dbacaf77d..ed941c5a0be9 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -1316,7 +1316,7 @@ struct netvsc_device
> *rndis_filter_device_add(struct hv_device *dev,
> rndis_device->link_state ? "down" : "up");
>
> if (net_device->nvsp_version < NVSP_PROTOCOL_VERSION_5)
> - return net_device;
> + goto out;
>
> rndis_filter_query_link_speed(rndis_device, net_device);
>
^ permalink raw reply
* [PATCH net 0/2] qed*: Rdma fixes
From: Michal Kalderon @ 2018-05-08 18:29 UTC (permalink / raw)
To: michal.kalderon, davem
Cc: netdev, linux-rdma, chad.dupuis, Michal Kalderon,
Sudarsana Kalluru
This patch series include two fixes for bugs related to rdma.
The first has to do with loading the driver over an iWARP
device.
The second fixes a previous commit that added proper link
indication for iWARP / RoCE.
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
Michal Kalderon (2):
qed: Fix l2 initializations over iWARP personality
qede: Fix gfp flags sent to rdma event node allocation
drivers/net/ethernet/qlogic/qed/qed_l2.c | 6 ++----
drivers/net/ethernet/qlogic/qede/qede_rdma.c | 2 +-
2 files changed, 3 insertions(+), 5 deletions(-)
--
2.9.5
^ permalink raw reply
* [PATCH net 1/2] qed: Fix l2 initializations over iWARP personality
From: Michal Kalderon @ 2018-05-08 18:29 UTC (permalink / raw)
To: michal.kalderon, davem
Cc: netdev, linux-rdma, chad.dupuis, Michal Kalderon,
Sudarsana Kalluru
In-Reply-To: <20180508182919.23590-1-Michal.Kalderon@cavium.com>
If qede driver was loaded on a device configured for iWARP
the l2 mutex wouldn't be allocated, and some l2 related
resources wouldn't be freed.
fixes: c851a9dc4359 ("qed: Introduce iWARP personality")
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index e874504..8667799 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -115,8 +115,7 @@ int qed_l2_alloc(struct qed_hwfn *p_hwfn)
void qed_l2_setup(struct qed_hwfn *p_hwfn)
{
- if (p_hwfn->hw_info.personality != QED_PCI_ETH &&
- p_hwfn->hw_info.personality != QED_PCI_ETH_ROCE)
+ if (!QED_IS_L2_PERSONALITY(p_hwfn))
return;
mutex_init(&p_hwfn->p_l2_info->lock);
@@ -126,8 +125,7 @@ void qed_l2_free(struct qed_hwfn *p_hwfn)
{
u32 i;
- if (p_hwfn->hw_info.personality != QED_PCI_ETH &&
- p_hwfn->hw_info.personality != QED_PCI_ETH_ROCE)
+ if (!QED_IS_L2_PERSONALITY(p_hwfn))
return;
if (!p_hwfn->p_l2_info)
--
2.9.5
^ permalink raw reply related
* [PATCH net 2/2] qede: Fix gfp flags sent to rdma event node allocation
From: Michal Kalderon @ 2018-05-08 18:29 UTC (permalink / raw)
To: michal.kalderon, davem
Cc: netdev, linux-rdma, chad.dupuis, Michal Kalderon,
Sudarsana Kalluru
In-Reply-To: <20180508182919.23590-1-Michal.Kalderon@cavium.com>
A previous commit 4609adc27175 ("qede: Fix qedr link update")
added a flow that could allocate rdma event objects from an
interrupt path (link notification). Therefore the kzalloc call
should be done with GFP_ATOMIC.
fixes: 4609adc27175 ("qede: Fix qedr link update")
Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
Signed-off-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_rdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_rdma.c b/drivers/net/ethernet/qlogic/qede/qede_rdma.c
index 50b142f..1900bf7 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_rdma.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_rdma.c
@@ -238,7 +238,7 @@ qede_rdma_get_free_event_node(struct qede_dev *edev)
}
if (!found) {
- event_node = kzalloc(sizeof(*event_node), GFP_KERNEL);
+ event_node = kzalloc(sizeof(*event_node), GFP_ATOMIC);
if (!event_node) {
DP_NOTICE(edev,
"qedr: Could not allocate memory for rdma work\n");
--
2.9.5
^ permalink raw reply related
* Re: Failed to clone net-next.git
From: Song Liu @ 2018-05-08 18:37 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Networking, Alexei Starovoitov
In-Reply-To: <f5d5d5c3-3b15-ddbe-45c6-9f360f1042bf@linuxfoundation.org>
> On May 8, 2018, at 11:06 AM, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
>
> On 05/08/18 13:46, Song Liu wrote:
>> 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'...
>> remote: Counting objects: 6017287, done.
>> remote: Compressing objects: 100% (2458/2458), done.
>> fatal: The remote end hung up unexpectedly 1.00 GiB | 8.13 MiB/s
>> fatal: early EOF
>> fatal: index-pack failed
>>
>> It looks like the size of the data being fetched reached server side
>> limit of 1.00 GiB. So we probably need change server side configuration.
>> Could someone please look into it?
>
> It was probably due to a timeout value. Can you try it now, I've bumped
> it to a much larger number.
>
> Regards,
> --
> Konstantin Ryabitsev
> Director, IT Infrastructure Security
> The Linux Foundation
Thanks Konstantin. It works for me now.
By the way, I do need to increase http.postBuffer on the client side:
git config --global http.postBuffer "something > 1GiB"
Song
^ permalink raw reply
* Re: [PATCH] selinux: add AF_UNSPEC and INADDR_ANY checks to selinux_socket_bind()
From: Stephen Smalley @ 2018-05-08 18:40 UTC (permalink / raw)
To: Paul Moore, Alexey Kodanev, Richard Haines
Cc: selinux, Eric Paris, linux-security-module, netdev
In-Reply-To: <CAHC9VhTACGPt2dSkUN9Efxs-HQVSAsxoiwPxHcujd++O-mMafg@mail.gmail.com>
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.
>
> 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?
> 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
>>
>
^ permalink raw reply
* Re: [PATCH v6 13/13] Documentation: clarify firmware_class provenance and why we can't rename the module
From: Andres Rodriguez @ 2018-05-08 18:53 UTC (permalink / raw)
To: Luis R. Rodriguez, gregkh
Cc: andresx7, akpm, keescook, josh, maco, andy.gross, david.brown,
bjorn.andersson, teg, wagi, hdegoede, zohar, kubakici, shuah,
mfuzzey, dhowells, pali.rohar, tiwai, kvalo, arend.vanspriel,
zajec5, nbroeking, markivx, broonie, dmitry.torokhov, dwmw2,
torvalds, Abhay_Salunke, jewalt, oneukum, cantabile.desu, ast,
hare, jejb, martin.petersen, khc, davem
In-Reply-To: <20180508181247.19431-14-mcgrof@kernel.org>
On 2018-05-08 02:12 PM, Luis R. Rodriguez wrote:
> Clarify the provenance of the firmware loader firmware_class module name
> and why we cannot rename the module in the future.
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> .../driver-api/firmware/fallback-mechanisms.rst | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index a39323ef7d29..a8047be4a96e 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -72,9 +72,12 @@ the firmware requested, and establishes it in the device hierarchy by
> associating the device used to make the request as the device's parent.
> The sysfs directory's file attributes are defined and controlled through
> the new device's class (firmware_class) and group (fw_dev_attr_groups).
> -This is actually where the original firmware_class.c file name comes from,
> -as originally the only firmware loading mechanism available was the
> -mechanism we now use as a fallback mechanism.
> +This is actually where the original firmware_class module name came from,
> +given that originally the only firmware loading mechanism available was the
> +mechanism we now use as a fallback mechanism, which which registers a
Just a tiny repeated word here, "which which".
-Andres
> +struct class firmware_class. Because the attributes exposed are part of the
> +module name, the module name firmware_class cannot be renamed in the future, to
> +ensure backward compatibilty with old userspace.
>
> To load firmware using the sysfs interface we expose a loading indicator,
> and a file upload firmware into:
>
^ permalink raw reply
* Re: KASAN: use-after-free Read in sctp_do_sm
From: Marcelo Ricardo Leitner @ 2018-05-08 18:57 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
In-Reply-To: <CADvbK_d8O7b9OCfCKGhaaQuBafi6rgkKEQh9Bk7pvZKX3KDKCg@mail.gmail.com>
On Wed, May 09, 2018 at 01:41:03AM +0800, Xin Long wrote:
...
> > sctp_chunk_destroy net/sctp/sm_make_chunk.c:1481 [inline]
> > sctp_chunk_put+0x321/0x440 net/sctp/sm_make_chunk.c:1504
> > sctp_ulpevent_make_rcvmsg+0x955/0xd40 net/sctp/ulpevent.c:718
> There's no reason to put the chunk in sctp_ulpevent_make_rcvmsg's
> fail_mark err path before holding this chunk later there.
>
> We should just remove it.
Oups. Agreed.
Marcelo
^ permalink raw reply
* Re: pull-request: ieee802154 2018-05-08
From: Stefan Schmidt @ 2018-05-08 19:55 UTC (permalink / raw)
To: David Miller, s.schmidt; +Cc: linux-wpan, alex.aring, netdev
In-Reply-To: <20180508.101808.776198033126419650.davem@davemloft.net>
Hello.
On 05/08/2018 04:18 PM, David Miller wrote:
> From: Stefan Schmidt <s.schmidt@samsung.com>
> Date: Tue, 8 May 2018 10:29:27 +0200
>
>> An update from ieee802154 for your *net* tree.
>>
>> Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
>> by Gustavo and myself.
>> The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
>> Jia-Ju.
>>
>> The last and most important fix is from Alex to get IPv6 reassembly working
>> again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
>> queue this one also up for the 4.16 stable tree.
> Pulled, thanks.
Thanks.
>
> 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
^ permalink raw reply
* Re: [PATCH net-next] dt-bindings: dsa: Remove unnecessary #address/#size-cells
From: Florian Fainelli @ 2018-05-08 20:58 UTC (permalink / raw)
To: Fabio Estevam, davem; +Cc: andrew, robh+dt, netdev, devicetree, Fabio Estevam
In-Reply-To: <1525695471-19984-1-git-send-email-festevam@gmail.com>
On 05/07/2018 05:17 AM, Fabio Estevam wrote:
> 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.
In most cases this is unnecessary because the parent node is an MDIO,
I2C or SPI controller, and those typically have #address-cells = <1> and
#size-cells = <0> because of their specific binding, but this is not
necessarily true if using e.g: a MMIO mapped Ethernet switch.
With the particular example though, this appears fine:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next 2/6] bpf: btf: Introduce BTF ID
From: Song Liu @ 2018-05-08 21:09 UTC (permalink / raw)
To: Martin Lau
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <20180504214955.1058805-3-kafai@fb.com>
> On May 4, 2018, at 2:49 PM, Martin KaFai Lau <kafai@fb.com> wrote:
>
> This patch gives an ID to each loaded BTF. The ID is allocated by
> the idr like the existing prog-id and map-id.
>
> The bpf_put(map->btf) is moved to __bpf_map_put() so that the
> userspace can stop seeing the BTF ID ASAP when the last BTF
> refcnt is gone.
>
> It also makes BTF accessible from userspace through the
> 1. new BPF_BTF_GET_FD_BY_ID command. It is limited to CAP_SYS_ADMIN
> which is inline with the BPF_BTF_LOAD cmd and the existing
> BPF_[MAP|PROG]_GET_FD_BY_ID cmd.
> 2. new btf_id (and btf_key_id + btf_value_id) in "struct bpf_map_info"
>
> Once the BTF ID handler is accessible from userspace, freeing a BTF
> object has to go through a rcu period. The BPF_BTF_GET_FD_BY_ID cmd
> can then be done under a rcu_read_lock() instead of taking
> spin_lock.
> [Note: A similar rcu usage can be done to the existing
> bpf_prog_get_fd_by_id() in a follow up patch]
>
> When processing the BPF_BTF_GET_FD_BY_ID cmd,
> refcount_inc_not_zero() is needed because the BTF object
> could be already in the rcu dead row . btf_get() is
> removed since its usage is currently limited to btf.c
> alone. refcount_inc() is used directly instead.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Acked-by: Alexei Starovoitov <ast@fb.com>
> ---
> include/linux/btf.h | 2 +
> include/uapi/linux/bpf.h | 5 +++
> kernel/bpf/btf.c | 108 ++++++++++++++++++++++++++++++++++++++++++-----
> kernel/bpf/syscall.c | 24 ++++++++++-
> 4 files changed, 128 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index a966dc6d61ee..e076c4697049 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -44,5 +44,7 @@ const struct btf_type *btf_type_id_size(const struct btf *btf,
> u32 *ret_size);
> void btf_type_seq_show(const struct btf *btf, u32 type_id, void *obj,
> struct seq_file *m);
> +int btf_get_fd_by_id(u32 id);
> +u32 btf_id(const struct btf *btf);
>
> #endif
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 93d5a4eeec2a..6106f23a9a8a 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -96,6 +96,7 @@ enum bpf_cmd {
> BPF_PROG_QUERY,
> BPF_RAW_TRACEPOINT_OPEN,
> BPF_BTF_LOAD,
> + BPF_BTF_GET_FD_BY_ID,
> };
>
> enum bpf_map_type {
> @@ -344,6 +345,7 @@ union bpf_attr {
> __u32 start_id;
> __u32 prog_id;
> __u32 map_id;
> + __u32 btf_id;
> };
> __u32 next_id;
> __u32 open_flags;
> @@ -2130,6 +2132,9 @@ struct bpf_map_info {
> __u32 ifindex;
> __u64 netns_dev;
> __u64 netns_ino;
> + __u32 btf_id;
> + __u32 btf_key_id;
> + __u32 btf_value_id;
> } __attribute__((aligned(8)));
>
> /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index fa0dce0452e7..40950b6bf395 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -11,6 +11,7 @@
> #include <linux/file.h>
> #include <linux/uaccess.h>
> #include <linux/kernel.h>
> +#include <linux/idr.h>
> #include <linux/bpf_verifier.h>
> #include <linux/btf.h>
>
> @@ -179,6 +180,9 @@
> i < btf_type_vlen(struct_type); \
> i++, member++)
>
> +static DEFINE_IDR(btf_idr);
> +static DEFINE_SPINLOCK(btf_idr_lock);
> +
> struct btf {
> union {
> struct btf_header *hdr;
> @@ -193,6 +197,8 @@ struct btf {
> u32 types_size;
> u32 data_size;
> refcount_t refcnt;
> + u32 id;
> + struct rcu_head rcu;
> };
>
> enum verifier_phase {
> @@ -598,6 +604,42 @@ static int btf_add_type(struct btf_verifier_env *env, struct btf_type *t)
> return 0;
> }
>
> +static int btf_alloc_id(struct btf *btf)
> +{
> + int id;
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock_bh(&btf_idr_lock);
> + id = idr_alloc_cyclic(&btf_idr, btf, 1, INT_MAX, GFP_ATOMIC);
> + if (id > 0)
> + btf->id = id;
> + spin_unlock_bh(&btf_idr_lock);
> + idr_preload_end();
> +
> + if (WARN_ON_ONCE(!id))
> + return -ENOSPC;
> +
> + return id > 0 ? 0 : id;
> +}
> +
> +static void btf_free_id(struct btf *btf)
> +{
> + unsigned long flags;
> +
> + /*
> + * In map-in-map, calling map_delete_elem() on outer
> + * map will call bpf_map_put on the inner map.
> + * It will then eventually call btf_free_id()
> + * on the inner map. Some of the map_delete_elem()
> + * implementation may have irq disabled, so
> + * we need to use the _irqsave() version instead
> + * of the _bh() version.
> + */
> + spin_lock_irqsave(&btf_idr_lock, flags);
> + idr_remove(&btf_idr, btf->id);
> + spin_unlock_irqrestore(&btf_idr_lock, flags);
> +}
> +
> static void btf_free(struct btf *btf)
> {
> kvfree(btf->types);
> @@ -607,15 +649,19 @@ static void btf_free(struct btf *btf)
> kfree(btf);
> }
>
> -static void btf_get(struct btf *btf)
> +static void btf_free_rcu(struct rcu_head *rcu)
> {
> - refcount_inc(&btf->refcnt);
> + struct btf *btf = container_of(rcu, struct btf, rcu);
> +
> + btf_free(btf);
> }
>
> void btf_put(struct btf *btf)
> {
> - if (btf && refcount_dec_and_test(&btf->refcnt))
> - btf_free(btf);
> + if (btf && refcount_dec_and_test(&btf->refcnt)) {
> + btf_free_id(btf);
> + call_rcu(&btf->rcu, btf_free_rcu);
> + }
> }
>
> static int env_resolve_init(struct btf_verifier_env *env)
> @@ -2006,10 +2052,15 @@ const struct file_operations btf_fops = {
> .release = btf_release,
> };
>
> +static int __btf_new_fd(struct btf *btf)
> +{
> + return anon_inode_getfd("btf", &btf_fops, btf, O_RDONLY | O_CLOEXEC);
> +}
> +
> int btf_new_fd(const union bpf_attr *attr)
> {
> struct btf *btf;
> - int fd;
> + int ret;
>
> btf = btf_parse(u64_to_user_ptr(attr->btf),
> attr->btf_size, attr->btf_log_level,
> @@ -2018,12 +2069,23 @@ int btf_new_fd(const union bpf_attr *attr)
> if (IS_ERR(btf))
> return PTR_ERR(btf);
>
> - fd = anon_inode_getfd("btf", &btf_fops, btf,
> - O_RDONLY | O_CLOEXEC);
> - if (fd < 0)
> + ret = btf_alloc_id(btf);
> + if (ret) {
> + btf_free(btf);
> + return ret;
> + }
> +
> + /*
> + * The BTF ID is published to the userspace.
> + * All BTF free must go through call_rcu() from
> + * now on (i.e. free by calling btf_put()).
> + */
> +
> + ret = __btf_new_fd(btf);
> + if (ret < 0)
> btf_put(btf);
>
> - return fd;
> + return ret;
> }
>
> struct btf *btf_get_by_fd(int fd)
> @@ -2042,7 +2104,7 @@ struct btf *btf_get_by_fd(int fd)
> }
>
> btf = f.file->private_data;
> - btf_get(btf);
> + refcount_inc(&btf->refcnt);
> fdput(f);
>
> return btf;
> @@ -2062,3 +2124,29 @@ int btf_get_info_by_fd(const struct btf *btf,
>
> return 0;
> }
> +
> +int btf_get_fd_by_id(u32 id)
> +{
> + struct btf *btf;
> + int fd;
> +
> + rcu_read_lock();
> + btf = idr_find(&btf_idr, id);
> + if (!btf || !refcount_inc_not_zero(&btf->refcnt))
> + btf = ERR_PTR(-ENOENT);
> + rcu_read_unlock();
> +
> + if (IS_ERR(btf))
> + return PTR_ERR(btf);
> +
> + fd = __btf_new_fd(btf);
> + if (fd < 0)
> + btf_put(btf);
> +
> + return fd;
> +}
> +
> +u32 btf_id(const struct btf *btf)
> +{
> + return btf->id;
> +}
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 263e13ede029..8b0a45d65454 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -252,7 +252,6 @@ static void bpf_map_free_deferred(struct work_struct *work)
>
> bpf_map_uncharge_memlock(map);
> security_bpf_map_free(map);
> - btf_put(map->btf);
> /* implementation dependent freeing */
> map->ops->map_free(map);
> }
> @@ -273,6 +272,7 @@ static void __bpf_map_put(struct bpf_map *map, bool do_idr_lock)
> if (atomic_dec_and_test(&map->refcnt)) {
> /* bpf_map_free_id() must be called first */
> bpf_map_free_id(map, do_idr_lock);
> + btf_put(map->btf);
> INIT_WORK(&map->work, bpf_map_free_deferred);
> schedule_work(&map->work);
> }
> @@ -2000,6 +2000,12 @@ static int bpf_map_get_info_by_fd(struct bpf_map *map,
> info.map_flags = map->map_flags;
> memcpy(info.name, map->name, sizeof(map->name));
>
> + if (map->btf) {
> + info.btf_id = btf_id(map->btf);
> + info.btf_key_id = map->btf_key_id;
> + info.btf_value_id = map->btf_value_id;
> + }
> +
> if (bpf_map_is_dev_bound(map)) {
> err = bpf_map_offload_info_fill(&info, map);
> if (err)
> @@ -2057,6 +2063,19 @@ static int bpf_btf_load(const union bpf_attr *attr)
> return btf_new_fd(attr);
> }
>
> +#define BPF_BTF_GET_FD_BY_ID_LAST_FIELD btf_id
> +
> +static int bpf_btf_get_fd_by_id(const union bpf_attr *attr)
> +{
> + if (CHECK_ATTR(BPF_BTF_GET_FD_BY_ID))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + return btf_get_fd_by_id(attr->btf_id);
> +}
> +
> SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
> {
> union bpf_attr attr = {};
> @@ -2140,6 +2159,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
> case BPF_BTF_LOAD:
> err = bpf_btf_load(&attr);
> break;
> + case BPF_BTF_GET_FD_BY_ID:
> + err = bpf_btf_get_fd_by_id(&attr);
> + break;
> default:
> err = -EINVAL;
> break;
> --
> 2.9.5
>
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next 3/6] bpf: btf: Add struct bpf_btf_info
From: Song Liu @ 2018-05-08 21:09 UTC (permalink / raw)
To: Martin Lau
Cc: netdev@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Kernel Team
In-Reply-To: <20180504214955.1058805-4-kafai@fb.com>
> On May 4, 2018, at 2:49 PM, Martin KaFai Lau <kafai@fb.com> wrote:
>
> During BPF_OBJ_GET_INFO_BY_FD on a btf_fd, the current bpf_attr's
> info.info is directly filled with the BTF binary data. It is
> not extensible. In this case, we want to add BTF ID.
>
> This patch adds "struct bpf_btf_info" which has the BTF ID as
> one of its member. The BTF binary data itself is exposed through
> the "btf" and "btf_size" members.
>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> Acked-by: Alexei Starovoitov <ast@fb.com>
> ---
> include/uapi/linux/bpf.h | 6 ++++++
> kernel/bpf/btf.c | 26 +++++++++++++++++++++-----
> kernel/bpf/syscall.c | 17 ++++++++++++++++-
> 3 files changed, 43 insertions(+), 6 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 6106f23a9a8a..d615c777b573 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -2137,6 +2137,12 @@ struct bpf_map_info {
> __u32 btf_value_id;
> } __attribute__((aligned(8)));
>
> +struct bpf_btf_info {
> + __aligned_u64 btf;
> + __u32 btf_size;
> + __u32 id;
> +} __attribute__((aligned(8)));
> +
> /* User bpf_sock_addr struct to access socket fields and sockaddr struct passed
> * by user and intended to be used by socket (e.g. to bind to, depends on
> * attach attach type).
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 40950b6bf395..ded10ab47b8a 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -2114,12 +2114,28 @@ int btf_get_info_by_fd(const struct btf *btf,
> const union bpf_attr *attr,
> union bpf_attr __user *uattr)
> {
> - void __user *udata = u64_to_user_ptr(attr->info.info);
> - u32 copy_len = min_t(u32, btf->data_size,
> - attr->info.info_len);
> + struct bpf_btf_info __user *uinfo;
> + struct bpf_btf_info info = {};
> + u32 info_copy, btf_copy;
> + void __user *ubtf;
> + u32 uinfo_len;
>
> - if (copy_to_user(udata, btf->data, copy_len) ||
> - put_user(btf->data_size, &uattr->info.info_len))
> + uinfo = u64_to_user_ptr(attr->info.info);
> + uinfo_len = attr->info.info_len;
> +
> + info_copy = min_t(u32, uinfo_len, sizeof(info));
> + if (copy_from_user(&info, uinfo, info_copy))
> + return -EFAULT;
> +
> + info.id = btf->id;
> + ubtf = u64_to_user_ptr(info.btf);
> + btf_copy = min_t(u32, btf->data_size, info.btf_size);
> + if (copy_to_user(ubtf, btf->data, btf_copy))
> + return -EFAULT;
> + info.btf_size = btf->data_size;
> +
> + if (copy_to_user(uinfo, &info, info_copy) ||
> + put_user(info_copy, &uattr->info.info_len))
> return -EFAULT;
>
> return 0;
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 8b0a45d65454..d2895e3e5cbf 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -2019,6 +2019,21 @@ static int bpf_map_get_info_by_fd(struct bpf_map *map,
> return 0;
> }
>
> +static int bpf_btf_get_info_by_fd(struct btf *btf,
> + const union bpf_attr *attr,
> + union bpf_attr __user *uattr)
> +{
> + struct bpf_btf_info __user *uinfo = u64_to_user_ptr(attr->info.info);
> + u32 info_len = attr->info.info_len;
> + int err;
> +
> + err = check_uarg_tail_zero(uinfo, sizeof(*uinfo), info_len);
> + if (err)
> + return err;
> +
> + return btf_get_info_by_fd(btf, attr, uattr);
> +}
> +
> #define BPF_OBJ_GET_INFO_BY_FD_LAST_FIELD info.info
>
> static int bpf_obj_get_info_by_fd(const union bpf_attr *attr,
> @@ -2042,7 +2057,7 @@ static int bpf_obj_get_info_by_fd(const union bpf_attr *attr,
> err = bpf_map_get_info_by_fd(f.file->private_data, attr,
> uattr);
> else if (f.file->f_op == &btf_fops)
> - err = btf_get_info_by_fd(f.file->private_data, attr, uattr);
> + err = bpf_btf_get_info_by_fd(f.file->private_data, attr, uattr);
> else
> err = -EINVAL;
>
> --
> 2.9.5
>
Acked-by: Song Liu <songliubraving@fb.com>
^ permalink raw reply
* Re: [PATCH bpf-next 1/6] bpf: btf: Avoid WARN_ON when CONFIG_REFCOUNT_FULL=y
From: Song Liu @ 2018-05-08 21:09 UTC (permalink / raw)
To: Martin Lau; +Cc: Networking, Alexei Starovoitov, Daniel Borkmann, Kernel Team
In-Reply-To: <20180504214955.1058805-2-kafai@fb.com>
> On May 4, 2018, at 2:49 PM, Martin KaFai Lau <kafai@fb.com> wrote:
>
> If CONFIG_REFCOUNT_FULL=y, refcount_inc() WARN when refcount is 0.
> When creating a new btf, the initial btf->refcnt is 0 and
> triggered the following:
>
> [ 34.855452] refcount_t: increment on 0; use-after-free.
> [ 34.856252] WARNING: CPU: 6 PID: 1857 at lib/refcount.c:153 refcount_inc+0x26/0x30
> ....
> [ 34.868809] Call Trace:
> [ 34.869168] btf_new_fd+0x1af6/0x24d0
> [ 34.869645] ? btf_type_seq_show+0x200/0x200
> [ 34.870212] ? lock_acquire+0x3b0/0x3b0
> [ 34.870726] ? security_capable+0x54/0x90
> [ 34.871247] __x64_sys_bpf+0x1b2/0x310
> [ 34.871761] ? __ia32_sys_bpf+0x310/0x310
> [ 34.872285] ? bad_area_access_error+0x310/0x310
> [ 34.872894] do_syscall_64+0x95/0x3f0
>
> This patch uses refcount_set() instead.
>
> Reported-by: Yonghong Song <yhs@fb.com>
> Tested-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
> ---
> kernel/bpf/btf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index 22e1046a1a86..fa0dce0452e7 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -1977,7 +1977,7 @@ static struct btf *btf_parse(void __user *btf_data, u32 btf_data_size,
>
> if (!err) {
> btf_verifier_env_free(env);
> - btf_get(btf);
> + refcount_set(&btf->refcnt, 1);
> return btf;
> }
>
> --
> 2.9.5
>
Acked-by: Song Liu <songliubraving@fb.com>
^ 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