[PATCH] mm/hugetlb: remove redundant reservation check condition in alloc_huge_page()
If there is no reservation corresponding to a vma, map_chg is always != 0,
i.e. we can not meet the condition where a vma does not have reservation
while map_chg = 0.
Signed-off-by: Miaohe Lin
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4f2c92ddbca4..36c3646fa55f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2311,7 +2311,7 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
/* If this allocation is not consuming a reservation, charge it now.
*/
- deferred_reserve = map_chg || avoid_reserve || !vma_resv_map(vma);
+ deferred_reserve = map_chg || avoid_reserve;
if (deferred_reserve) {
ret = hugetlb_cgroup_charge_cgroup_rsvd(
idx, pages_per_huge_page(h), _cg);
--
2.19.1
[PATCH v3] mm: cma: support sysfs
Since CMA is getting used more widely, it's more important to
keep monitoring CMA statistics for system health since it's
directly related to user experience.
This patch introduces sysfs statistics for CMA, in order to provide
some basic monitoring of the CMA allocator.
* the number of CMA page allocation attempts
* the number of CMA page allocation failures
These two values allow the user to calcuate the allocation
failure rate for each CMA area.
e.g.)
/sys/kernel/mm/cma/WIFI/cma_alloc_pages_[attempts|fails]
/sys/kernel/mm/cma/SENSOR/cma_alloc_pages_[attempts|fails]
/sys/kernel/mm/cma/BLUETOOTH/cma_alloc_pages_[attempts|fails]
Signed-off-by: Minchan Kim
---
>From v2 -
>https://lore.kernel.org/linux-mm/20210208180142.2765456-1-minc...@kernel.org/
* sysfs doc and description modification - jhubbard
>From v1 -
>https://lore.kernel.org/linux-mm/20210203155001.4121868-1-minc...@kernel.org/
* fix sysfs build and refactoring - willy
* rename and drop some attributes - jhubbard
Documentation/ABI/testing/sysfs-kernel-mm-cma | 25
mm/Kconfig| 7 ++
mm/Makefile | 1 +
mm/cma.c | 6 +-
mm/cma.h | 18 +++
mm/cma_sysfs.c| 114 ++
6 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-cma
create mode 100644 mm/cma_sysfs.c
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cma
b/Documentation/ABI/testing/sysfs-kernel-mm-cma
new file mode 100644
index ..f518af819cee
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cma
@@ -0,0 +1,25 @@
+What: /sys/kernel/mm/cma/
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ /sys/kernel/mm/cma/ contains a subdirectory for each CMA
+ heap name (also sometimes called CMA areas).
+
+ Each CMA heap subdirectory (that is, each
+ /sys/kernel/mm/cma/ directory) contains the
+ following items:
+
+ cma_alloc_pages_attempts
+ cma_alloc_pages_fails
+
+What: /sys/kernel/mm/cma//cma_alloc_pages_attempts
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ the number of pages CMA API tried to allocate
+
+What: /sys/kernel/mm/cma//cma_alloc_pages_fails
+Date: Feb 2021
+Contact: Minchan Kim
+Description:
+ the number of pages CMA API failed to allocate
diff --git a/mm/Kconfig b/mm/Kconfig
index ec35bf406439..ad7e9c065657 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -513,6 +513,13 @@ config CMA_DEBUGFS
help
Turns on the DebugFS interface for CMA.
+config CMA_SYSFS
+ bool "CMA information through sysfs interface"
+ depends on CMA && SYSFS
+ help
+ This option exposes some sysfs attributes to get information
+ from CMA.
+
config CMA_AREAS
int "Maximum count of the CMA areas"
depends on CMA
diff --git a/mm/Makefile b/mm/Makefile
index b2a564eec27f..e10c14300191 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_CMA) += cma.o
obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o
obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o
obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o
+obj-$(CONFIG_CMA_SYSFS) += cma_sysfs.o
obj-$(CONFIG_USERFAULTFD) += userfaultfd.o
obj-$(CONFIG_IDLE_PAGE_TRACKING) += page_idle.o
obj-$(CONFIG_DEBUG_PAGE_REF) += debug_page_ref.o
diff --git a/mm/cma.c b/mm/cma.c
index 23d4a97c834a..b42ccafc71e5 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -447,9 +447,10 @@ struct page *cma_alloc(struct cma *cma, size_t count,
unsigned int align,
offset = cma_bitmap_aligned_offset(cma, align);
bitmap_maxno = cma_bitmap_maxno(cma);
bitmap_count = cma_bitmap_pages_to_bits(cma, count);
+ cma_sysfs_alloc_count(cma, count);
if (bitmap_count > bitmap_maxno)
- return NULL;
+ goto out;
for (;;) {
mutex_lock(>lock);
@@ -504,6 +505,9 @@ struct page *cma_alloc(struct cma *cma, size_t count,
unsigned int align,
__func__, count, ret);
cma_debug_show_areas(cma);
}
+out:
+ if (!page)
+ cma_sysfs_fail_count(cma, count);
pr_debug("%s(): returned %p\n", __func__, page);
return page;
diff --git a/mm/cma.h b/mm/cma.h
index 42ae082cb067..24a1d61eabc7 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -3,6 +3,14 @@
#define __MM_CMA_H__
#include
+#include
+
+struct cma_stat {
+ spinlock_t lock;
+ unsigned long pages_attempts; /* the number of CMA page allocation
attempts */
+ unsigned long pages_fails; /* the number of CMA page allocation
failures */
+ struct kobject kobj;
+};
struct cma {
unsigned
[PATCH -next] soc: ti: knav_qmss_queue: Make symbol 'knav_acc_firmwares' static
The sparse tool complains as follows:
drivers/soc/ti/knav_qmss_queue.c:70:12: warning:
symbol 'knav_acc_firmwares' was not declared. Should it be static?
This symbol is not used outside of knav_qmss_queue.c, so this
commit marks it 'static const char * const'.
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/soc/ti/knav_qmss_queue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 2ac3856b8d42..7985c4197cf7 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -67,7 +67,7 @@ static DEFINE_MUTEX(knav_dev_lock);
* Newest followed by older ones. Search is done from start of the array
* until a firmware file is found.
*/
-const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+static const char * const knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
static bool device_ready;
bool knav_qmss_device_ready(void)
Re: [PATCH] ubsan: remove overflow checks
On Tue, Feb 09, 2021 at 04:19:03PM -0800, Kees Cook wrote:
> On Wed, Feb 10, 2021 at 02:23:48AM +0300, Andrey Ryabinin wrote:
> > Since GCC 8.0 -fsanitize=signed-integer-overflow doesn't work with -fwrapv.
> > -fwrapv makes signed overflows defines and GCC essentially disables
> > ubsan checks. On GCC < 8.0 -fwrapv doesn't have influence on
> > -fsanitize=signed-integer-overflow setting, so it kinda works
> > but generates false-positves and violates uaccess rules:
> >
> > lib/iov_iter.o: warning: objtool: iovec_from_user()+0x22d: call to
> > __ubsan_handle_add_overflow() with UACCESS enabled
> >
> > Disable signed overflow checks to avoid these problems.
> > Remove unsigned overflow checks as well.
> > Unsigned overflow appeared as side effect of the commit
> > cdf8a76fda4a ("ubsan: move cc-option tests into Kconfig"),
> > but it never worked (kernel doesn't boot). And unsigned overflows
> > are allowed by C standard, so it just pointless.
> >
> > Signed-off-by: Andrey Ryabinin
>
> NAK, please don't remove the entire thing. I want this to work again
> with -fwrapv, and it's not entirely broken under Clang. But the feature
> shouldn't be removed from the kernel.
>
> I'd prefer Peter's fix instead.
But what do you want it to do? This is UBsan, there's no UB.
If you want signed overflow warnings, call it something else. But I'll
still hate it :-)
FWIW:
Acked-by: Peter Zijlstra (Intel)
RE: [PATCH v2 0/9] Introduce vfio-pci-core subsystem
Hi, Max, > From: Max Gurtovoy > Sent: Tuesday, February 2, 2021 12:28 AM > > Hi Alex and Cornelia, > > This series split the vfio_pci driver into 2 parts: pci driver and a > subsystem driver that will also be library of code. The pci driver, > vfio_pci.ko will be used as before and it will bind to the subsystem > driver vfio_pci_core.ko to register to the VFIO subsystem. This patchset > if fully backward compatible. This is a typical Linux subsystem > framework behaviour. This framework can be also adopted by vfio_mdev > devices as we'll see in the below sketch. > > This series is coming to solve the issues that were raised in the > previous attempt for extending vfio-pci for vendor specific > functionality: https://lkml.org/lkml/2020/5/17/376 by Yan Zhao. > > This solution is also deterministic in a sense that when a user will > bind to a vendor specific vfio-pci driver, it will get all the special > goodies of the HW. > > This subsystem framework will also ease on adding vendor specific > functionality to VFIO devices in the future by allowing another module > to provide the pci_driver that can setup number of details before > registering to VFIO subsystem (such as inject its own operations). I'm a bit confused about the change from v1 to v2, especially about how to inject module specific operations. From live migration p.o.v it may requires two hook points at least for some devices (e.g. i40e in original Yan's example): register a migration region and intercept guest writes to specific registers. [PATCH 4/9] demonstrates the former but not the latter (which is allowed in v1). I saw some concerns about reporting struct vfio_pci_device outside of vfio-pci-core in v1 which should be the main reason driving this change. But I'm still curious to know how we plan to address this requirement (allowing vendor driver to tweak specific vfio_device_ops) moving forward. Then another question. Once we have this framework in place, do we mandate this approach for any vendor specific tweak or still allow doing it as vfio_pci_core extensions (such as igd and zdev in this series)? If the latter, what is the criteria to judge which way is desired? Also what about the scenarios where we just want one-time vendor information, e.g. to tell whether a device can tolerate arbitrary I/O page faults [1] or the offset in VF PCI config space to put PASID/ATS/PRI capabilities [2]? Do we expect to create a module for each device to provide such info? Having those questions answered is helpful for better understanding of this proposal IMO. [1] https://lore.kernel.org/kvm/d4c51504-24ed-2592-37b4-f390b97fd...@huawei.com/T/ [2] https://lore.kernel.org/kvm/20200407095801.648b1...@w520.home/ > > Below we can see the proposed changes (this patchset only deals with > VFIO_PCI subsystem but it can easily be extended to VFIO_MDEV subsystem > as well): > > +--+ > | | > | VFIO | > | | > +--+ > > +--++--+ > | || | > |VFIO_PCI_CORE || VFIO_MDEV_CORE | > | || | > +--++--+ > > +--+ +-++-+ +--+ > | | | || | | | > | | | || | | | > | VFIO_PCI | |MLX5_VFIO_PCI|| VFIO_MDEV | |MLX5_VFIO_MDEV| > | | | || | | | > | | | || | | | > +--+ +-++-+ +--+ > The VFIO_PCI part is clear but I didn't get how this concept is applied to VFIO_MDEV. the mdev sub-system looks like below in my mind: +--+ | | | VFIO | | | +--+ +--++--+ | || | |VFIO_PCI_CORE || VFIO_MDEV| | || | +--++--+ +--+ +-+
Re: [PATCH v2] mm: cma: support sysfs
On 2/9/21 11:26 PM, Greg KH wrote: ... I just am not especially happy about the inability to do natural, efficient things here, such as use a statically allocated set of things with sysfs. And I remain convinced that the above is not "improper"; it's a reasonable step, given the limitations of the current sysfs design. I just wanted to say that out loud, as my proposal sinks to the bottom of the trench here. haha :) What is "odd" is that you are creating an object in the kernel that you _never_ free. That's not normal at all in the kernel, and so, your wish to have a kobject that you never free represent this object also is not normal :) OK, thanks for taking the time to explain that, much appreciated! thanks, -- John Hubbard NVIDIA
Re: [PATCH] sched/autogroup: Use true and false for bool variable
On Wed, Feb 10, 2021 at 11:46:25AM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warning:
Please fix your robot or find yourself in the 'special' mailbox.
2b076054e524 ("remove boolinit.cocci")
[PATCH v2 0/2] pinctrl: pinmux: Add pinmux-select debugfs file
This series first converts the debugfs files in the pinctrl subsystem to octal permissions and then adds a new debug file "pinmux-select". Function name and group name can be written to "pinmux-select" which will cause the function and group to be activated on the pin controller. Notes for PATCH v2: - create patch series that includes patch to switch all the debugfs files in pinctrl subsystem over to octal permission - write function name and group name, instead of error-prone selector numbers, to the 'pinmux-select' file - switch from static to dynamic allocation for the kernel buffer filled by strncpy_from_user() - look up function selector from function name using pinmux_func_name_to_selector() - validate group name with get_function_groups() and match_string() - look up selector for group name with pinctrl_get_group_selector() Notes for PATCH v1: - posted seperate patch to switch all the debugfs files in pinctrl subsystem over to octal permission [1] - there is no existing documentation for any of the debugfs enteries for pinctrl, so it seemed to have a bigger scope than just this patch. I also noticed that rst documentation is confusingly named "pinctl" (no 'r') and started thread about that [2]. Linus suggested chaning that to 'pin-control'. Thus I am planning a seperate documentation patch series where the file is renamed, references changed and a section on the pinctrl debugfs files is added. Notes for RFC v2 [3]: - rename debugfs file "pinmux-set" to "pinmux-select" - renmae pinmux_set_write() to pinmux_select() - switch from memdup_user_nul() to strncpy_from_user() - switch from pr_warn() to dev_err() [1] https://lore.kernel.org/linux-gpio/20210126044742.87602-1-d...@beagleboard.org/ [2] https://lore.kernel.org/linux-gpio/20210126050817.GA187797@x1/ [3] https://lore.kernel.org/linux-gpio/20210123064909.466225-1-d...@beagleboard.org/ Drew Fustini (2): pinctrl: use to octal permissions for debugfs files pinctrl: pinmux: Add pinmux-select debugfs file drivers/pinctrl/core.c| 6 +-- drivers/pinctrl/pinconf.c | 4 +- drivers/pinctrl/pinmux.c | 110 +- 3 files changed, 113 insertions(+), 7 deletions(-) -- 2.25.1
[PATCH v2 1/2] pinctrl: use to octal permissions for debugfs files
Switch over pinctrl debugfs files to use octal permissions as they are
preferred over symbolic permissions. Refer to commit f90774e1fd27
("checkpatch: look for symbolic permissions and suggest octal instead").
Signed-off-by: Drew Fustini
---
drivers/pinctrl/core.c| 6 +++---
drivers/pinctrl/pinconf.c | 4 ++--
drivers/pinctrl/pinmux.c | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 3663d87f51a0..c9c28f653799 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1914,11 +1914,11 @@ static void pinctrl_init_debugfs(void)
return;
}
- debugfs_create_file("pinctrl-devices", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinctrl-devices", 0400,
debugfs_root, NULL, _devices_fops);
- debugfs_create_file("pinctrl-maps", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinctrl-maps", 0400,
debugfs_root, NULL, _maps_fops);
- debugfs_create_file("pinctrl-handles", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinctrl-handles", 0400,
debugfs_root, NULL, _fops);
}
diff --git a/drivers/pinctrl/pinconf.c b/drivers/pinctrl/pinconf.c
index 02c075cc010b..f005921bb49e 100644
--- a/drivers/pinctrl/pinconf.c
+++ b/drivers/pinctrl/pinconf.c
@@ -370,9 +370,9 @@ DEFINE_SHOW_ATTRIBUTE(pinconf_groups);
void pinconf_init_device_debugfs(struct dentry *devroot,
struct pinctrl_dev *pctldev)
{
- debugfs_create_file("pinconf-pins", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinconf-pins", 0400,
devroot, pctldev, _pins_fops);
- debugfs_create_file("pinconf-groups", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinconf-groups", 0400,
devroot, pctldev, _groups_fops);
}
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index bab888fe3f8e..7f6190eaedbb 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -676,9 +676,9 @@ DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
void pinmux_init_device_debugfs(struct dentry *devroot,
struct pinctrl_dev *pctldev)
{
- debugfs_create_file("pinmux-functions", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinmux-functions", 0400,
devroot, pctldev, _functions_fops);
- debugfs_create_file("pinmux-pins", S_IFREG | S_IRUGO,
+ debugfs_create_file("pinmux-pins", 0400,
devroot, pctldev, _pins_fops);
}
--
2.25.1
[PATCH v2 2/2] pinctrl: pinmux: Add pinmux-select debugfs file
Add "pinmux-select" to debugfs which will activate a function and group
when 2 integers " " are written to
the file. The write operation pinmux_select() handles this by checking
if fsel and gsel are valid selectors and then calling ops->set_mux().
The existing "pinmux-functions" debugfs file lists the pin functions
registered for the pin controller. For example:
function: pinmux-uart0, groups = [ pinmux-uart0-pins ]
function: pinmux-mmc0, groups = [ pinmux-mmc0-pins ]
function: pinmux-mmc1, groups = [ pinmux-mmc1-pins ]
function: pinmux-i2c0, groups = [ pinmux-i2c0-pins ]
function: pinmux-i2c1, groups = [ pinmux-i2c1-pins ]
function: pinmux-spi1, groups = [ pinmux-spi1-pins ]
To activate function pinmux-i2c1 (fsel 4) and group pinmux-i2c1-pins
(gsel 4):
echo '4 4' > pinmux-select
Signed-off-by: Drew Fustini
---
drivers/pinctrl/pinmux.c | 106 +++
1 file changed, 106 insertions(+)
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 7f6190eaedbb..b8cd0c3bedf7 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -673,6 +673,110 @@ void pinmux_show_setting(struct seq_file *s,
DEFINE_SHOW_ATTRIBUTE(pinmux_functions);
DEFINE_SHOW_ATTRIBUTE(pinmux_pins);
+
+#define PINMUX_MAX_NAME 64
+static ssize_t pinmux_select(struct file *file, const char __user *user_buf,
+ size_t len, loff_t *ppos)
+{
+ struct seq_file *sfile = file->private_data;
+ struct pinctrl_dev *pctldev = sfile->private;
+ const struct pinmux_ops *pmxops = pctldev->desc->pmxops;
+ const char *const *groups;
+ char *buf, *fname, *gname;
+ unsigned int num_groups;
+ int fsel, gsel, ret;
+
+ if (len > (PINMUX_MAX_NAME * 2)) {
+ dev_err(pctldev->dev, "write too big for buffer");
+ return -EINVAL;
+ }
+
+ buf = devm_kzalloc(pctldev->dev, PINMUX_MAX_NAME * 2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ fname = devm_kzalloc(pctldev->dev, PINMUX_MAX_NAME, GFP_KERNEL);
+ if (!fname) {
+ ret = -ENOMEM;
+ goto free_buf;
+ }
+
+ gname = devm_kzalloc(pctldev->dev, PINMUX_MAX_NAME, GFP_KERNEL);
+ if (!buf) {
+ ret = -ENOMEM;
+ goto free_fname;
+ }
+
+ ret = strncpy_from_user(buf, user_buf, PINMUX_MAX_NAME * 2);
+ if (ret < 0) {
+ dev_err(pctldev->dev, "failed to copy buffer from userspace");
+ goto free_gname;
+ }
+ buf[len-1] = '\0';
+
+ ret = sscanf(buf, "%s %s", fname, gname);
+ if (ret != 2) {
+ dev_err(pctldev->dev, "expected format:
");
+ goto free_gname;
+ }
+
+ fsel = pinmux_func_name_to_selector(pctldev, fname);
+ if (fsel < 0) {
+ dev_err(pctldev->dev, "invalid function %s in map table\n",
fname);
+ ret = -EINVAL;
+ goto free_gname;
+ }
+
+ ret = pmxops->get_function_groups(pctldev, fsel, , _groups);
+ if (ret) {
+ dev_err(pctldev->dev, "no groups for function %d (%s)", fsel,
fname);
+ goto free_gname;
+
+ }
+
+ ret = match_string(groups, num_groups, gname);
+ if (ret < 0) {
+ dev_err(pctldev->dev, "invalid group %s", gname);
+ goto free_gname;
+ }
+
+ ret = pinctrl_get_group_selector(pctldev, gname);
+ if (ret < 0) {
+ dev_err(pctldev->dev, "failed to get group selectorL %s",
gname);
+ goto free_gname;
+ }
+ gsel = ret;
+
+ ret = pmxops->set_mux(pctldev, fsel, gsel);
+ if (ret) {
+ dev_err(pctldev->dev, "set_mux() failed: %d", ret);
+ goto free_gname;
+ }
+
+ return len;
+free_buf:
+ devm_kfree(pctldev->dev, buf);
+free_fname:
+ devm_kfree(pctldev->dev, fname);
+free_gname:
+ devm_kfree(pctldev->dev, gname);
+ return ret;
+}
+
+static int pinmux_select_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, NULL, inode->i_private);
+}
+
+static const struct file_operations pinmux_select_ops = {
+ .owner = THIS_MODULE,
+ .open = pinmux_select_open,
+ .read = seq_read,
+ .write = pinmux_select,
+ .llseek = no_llseek,
+ .release = single_release,
+};
+
void pinmux_init_device_debugfs(struct dentry *devroot,
struct pinctrl_dev *pctldev)
{
@@ -680,6 +784,8 @@ void pinmux_init_device_debugfs(struct dentry *devroot,
devroot, pctldev, _functions_fops);
debugfs_create_file("pinmux-pins", 0400,
devroot, pctldev, _pins_fops);
+ debugfs_create_file("pinmux-select", 0200,
+ devroot, pctldev, _select_ops);
}
#endif /* CONFIG_DEBUG_FS */
--
2.25.1
Re: [PATCH] dmaengine: ti: k3-udma: Fix NULL pointer dereference error
Hi Kishon,
On 2/9/21 2:45 PM, Kishon Vijay Abraham I wrote:
> Hi Peter,
>
> On 09/02/21 5:53 pm, Péter Ujfalusi wrote:
>> Hi Kishon,
>>
>> On 2/9/21 11:00 AM, Kishon Vijay Abraham I wrote:
>>> bcdma_get_*() and udma_get_*() checks if bchan/rchan/tchan/rflow is
>>> already allocated by checking if it has a NON NULL value. For the
>>> error cases, bchan/rchan/tchan/rflow will have error value
>>> and bcdma_get_*() and udma_get_*() considers this as already allocated
>>> (PASS) since the error values are NON NULL. This results in
>>> NULL pointer dereference error while de-referencing
>>> bchan/rchan/tchan/rflow.
>>
>> I think this can happen when a channel request fails and we get a second
>> request coming and faces with the not cleanup up tchan/rchan/bchan/rflow
>> from the previous failure.
>> Interesting that I have not faced with this, but it is a valid oversight
>> from me.
>
> Thank you for reviewing.
>
> Got into this issue when all the PCIe endpoint functions were requesting
> for a MEMCOPY channel (total 22 endpoint functions) specifically in
> bcdma_get_bchan() where the scenario you mentioned above happened.
I see, do we even have 22 bchan allocated for Linux out from the 40? ;)
> Vignesh asked me to fix it for all udma_get_*().
Yes, that is the right thing to do, thank you!
>>
>>> Reset the value of bchan/rchan/tchan/rflow to NULL if the allocation
>>> actually fails.
>>>
>>> Fixes: 017794739702 ("dmaengine: ti: k3-udma: Initial support for K3 BCDMA")
>>> Fixes: 25dcb5dd7b7c ("dmaengine: ti: New driver for K3 UDMA")
>>
>> Will this patch apply at any of these?
>> 25dcb5dd7b7c does not have BCDMA (bchan)
>> 017794739702 does not contain PKTDMA (tflow)
>
> I can probably split this patch
> 017794739702 for bchan and 25dcb5dd7b7c for bchan/rchan/tchan/rflow
the tflow support for PKTDMA makes the tchan fix a bit problematic for
backporting, but it might worth a try to split to bcdma and
rchan/tchan/rflow patch.
--
Péter
[PATCH -next] soc: mediatek: Make symbol 'mtk_mutex_driver' static
The sparse tool complains as follows:
drivers/soc/mediatek/mtk-mutex.c:464:24: warning:
symbol 'mtk_mutex_driver' was not declared. Should it be static?
This symbol is not used outside of mtk-mutex.c, so this
commit marks it static.
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/soc/mediatek/mtk-mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index f531b119da7a..3a315a62e783 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -461,7 +461,7 @@ static const struct of_device_id mutex_driver_dt_match[] = {
};
MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
-struct platform_driver mtk_mutex_driver = {
+static struct platform_driver mtk_mutex_driver = {
.probe = mtk_mutex_probe,
.remove = mtk_mutex_remove,
.driver = {
[PATCH -next] mfd: arizona: Make some symbols static
The sparse tool complains as follows:
drivers/mfd/arizona-spi.c:28:31: warning:
symbol 'reset_gpios' was not declared. Should it be static?
drivers/mfd/arizona-spi.c:29:31: warning:
symbol 'ldoena_gpios' was not declared. Should it be static?
Those symbols are not used outside of arizona-spi.c, so this
commit marks them static.
Fixes: e933836744a2 ("mfd: arizona: Add support for ACPI enumeration of WM5102
connected over SPI")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/mfd/arizona-spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 24a2c75d691a..aa1d6f94ae53 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -25,8 +25,8 @@
#include "arizona.h"
#ifdef CONFIG_ACPI
-const struct acpi_gpio_params reset_gpios = { 1, 0, false };
-const struct acpi_gpio_params ldoena_gpios = { 2, 0, false };
+static const struct acpi_gpio_params reset_gpios = { 1, 0, false };
+static const struct acpi_gpio_params ldoena_gpios = { 2, 0, false };
static const struct acpi_gpio_mapping arizona_acpi_gpios[] = {
{ "reset-gpios", _gpios, 1, },
[PATCH -next] drm/rockchip: cdn-dp: Mark cdn_dp_resume as __maybe_unused
The function cdn_dp_resume() may have no callers depending
on configuration, so it must be marked __maybe_unused to
avoid harmless warning:
drivers/gpu/drm/rockchip/cdn-dp-core.c:1124:12: warning:
'cdn_dp_resume' defined but not used [-Wunused-function]
1124 | static int cdn_dp_resume(struct device *dev)
|^
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index a4a45daf93f2..1162e321aaed 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -1121,7 +1121,7 @@ static int cdn_dp_suspend(struct device *dev)
return ret;
}
-static int cdn_dp_resume(struct device *dev)
+static int __maybe_unused cdn_dp_resume(struct device *dev)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
Re: [PATCH v2] Drivers: staging: most: sound: Fixed styling issue.
On Wed, Feb 10, 2021 at 06:30:45AM +0530, Mukul Mehar wrote:
> This patch fixes a warning, of the line ending with a '(',
> generated by checkpatch.pl.
>
> Signed-off-by: Mukul Mehar
> ---
> Changes since v1:
> - Fixed indentation.
> ---
> drivers/staging/most/sound/sound.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/most/sound/sound.c
> b/drivers/staging/most/sound/sound.c
> index 4dd1bf95d1ce..4d497ce6d7b8 100644
> --- a/drivers/staging/most/sound/sound.c
> +++ b/drivers/staging/most/sound/sound.c
> @@ -231,9 +231,9 @@ static int playback_thread(void *data)
> wait_event_interruptible(channel->playback_waitq,
>kthread_should_stop() ||
>(channel->is_stream_running &&
> - (mbo = most_get_mbo(channel->iface,
> - channel->id,
> - ;
> + (mbo = most_get_mbo(channel->iface,
> + channel->id,
> + ;
> if (!mbo)
> continue;
>
This patch does not apply to my tree at all :(
greg k-h
[PATCH] sign-file: add openssl engine support
Use a customized signature service supported by openssl engine
to sign the kernel module.
Add command line parameters that support engine for sign-file
to use the customized openssl engine service to sign kernel modules.
Signed-off-by: Yang Song
---
scripts/sign-file.c | 65 ++---
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index fbd34b8e8f57..276068e9b595 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -70,7 +70,7 @@ static __attribute__((noreturn))
void format(void)
{
fprintf(stderr,
- "Usage: scripts/sign-file [-dp]
[]\n");
+ "Usage: scripts/sign-file [-edp] []
[]\n");
fprintf(stderr,
" scripts/sign-file -s
[]\n");
exit(2);
@@ -206,12 +206,54 @@ static X509 *read_x509(const char *x509_name)
return x509;
}
+/* Try to load an engine in a shareable library */
+static ENGINE *try_load_engine(const char *engine)
+{
+ ENGINE *e = ENGINE_by_id("dynamic");
+ if (e) {
+ if (!ENGINE_ctrl_cmd_string(e, "SO_PATH", engine, 0)
+ || !ENGINE_ctrl_cmd_string(e, "LOAD", NULL, 0)) {
+ ENGINE_free(e);
+ e = NULL;
+ }
+ }
+ return e;
+}
+
+static ENGINE *setup_engine(const char *engine)
+{
+ ENGINE *e = NULL;
+
+ if (engine) {
+ e = ENGINE_by_id(engine);
+ if (e == NULL) {
+ e = try_load_engine(engine);
+ if (e == NULL) {
+ ERR(1, "invalid engine \"%s\"\n", engine);
+ return NULL;
+ }
+ }
+
+ if (!ENGINE_set_default(e, ENGINE_METHOD_ALL)) {
+ ERR(1, "can't use that engine\n");
+ ENGINE_free(e);
+ return NULL;
+ }
+
+ fprintf(stdout, "engine \"%s\" set.\n", ENGINE_get_id(e));
+ }
+
+ return e;
+}
+
int main(int argc, char **argv)
{
struct module_signature sig_info = { .id_type = PKEY_ID_PKCS7 };
+ char *ossl_engine = NULL;
char *hash_algo = NULL;
char *private_key_name = NULL, *raw_sig_name = NULL;
char *x509_name, *module_name, *dest_name;
+ bool use_engine = false;
bool save_sig = false, replace_orig;
bool sign_only = false;
bool raw_sig = false;
@@ -242,8 +284,9 @@ int main(int argc, char **argv)
#endif
do {
- opt = getopt(argc, argv, "sdpk");
+ opt = getopt(argc, argv, "sedpk");
switch (opt) {
+ case 'e': use_engine = true; break;
case 's': raw_sig = true; break;
case 'p': save_sig = true; break;
case 'd': sign_only = true; save_sig = true; break;
@@ -257,13 +300,18 @@ int main(int argc, char **argv)
argc -= optind;
argv += optind;
- if (argc < 4 || argc > 5)
+ if (argc < 4 || argc > 6)
format();
if (raw_sig) {
raw_sig_name = argv[0];
hash_algo = argv[1];
} else {
+ if (use_engine) {
+ ossl_engine = argv[0];
+ argc--;
+ argv++;
+ }
hash_algo = argv[0];
private_key_name = argv[1];
}
@@ -291,6 +339,17 @@ int main(int argc, char **argv)
ERR(!bm, "%s", module_name);
if (!raw_sig) {
+ if (use_engine) {
+ if (ossl_engine == NULL) {
+ fprintf(stderr, "Input openssl engine is
null\n");
+ exit(1);
+ }
+
+ // Engine setup
+ ENGINE_load_builtin_engines();
+ setup_engine(ossl_engine);
+ }
+
/* Read the private key and the X.509 cert the PKCS#7 message
* will point to.
*/
--
2.19.1.3.ge56e4f7
Re: [PATCH 0/3] drm/ttm: constify static vm_operations_structs
Reviewed-by: Christian König for the series. Am 10.02.21 um 00:48 schrieb Rikard Falkeborn: Constify a few static vm_operations_struct that are never modified. Their only usage is to assign their address to the vm_ops field in the vm_area_struct, which is a pointer to const vm_operations_struct. Make them const to allow the compiler to put them in read-only memory. With this series applied, all static struct vm_operations_struct in the kernel tree are const. Rikard Falkeborn (3): drm/amdgpu/ttm: constify static vm_operations_struct drm/radeon/ttm: constify static vm_operations_struct drm/nouveau/ttm: constify static vm_operations_struct drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +- drivers/gpu/drm/radeon/radeon_ttm.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
[PATCH -next] NTB: Drop kfree for memory allocated with devm_kzalloc
It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.
Fixes: 363baf7d6051 ("NTB: Add support for EPF PCI-Express Non-Transparent
Bridge")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/ntb/hw/epf/ntb_hw_epf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/ntb/hw/epf/ntb_hw_epf.c b/drivers/ntb/hw/epf/ntb_hw_epf.c
index 2cccb7dff5dd..b019755e4e21 100644
--- a/drivers/ntb/hw/epf/ntb_hw_epf.c
+++ b/drivers/ntb/hw/epf/ntb_hw_epf.c
@@ -723,7 +723,6 @@ static void ntb_epf_pci_remove(struct pci_dev *pdev)
ntb_unregister_device(>ntb);
ntb_epf_cleanup_isr(ndev);
ntb_epf_deinit_pci(ndev);
- kfree(ndev);
}
static const struct ntb_epf_data j721e_data = {
Re: [PATCH] Documentation: Replace lkml.org links with lore
On Tue, 2021-02-09 at 23:28 -0800, Kees Cook wrote: > On Sun, Jan 10, 2021 at 12:41:44PM -0800, Joe Perches wrote: > > Replace the lkml.org links with lore to better use a single source > > that's more likely to stay available long-term. > > What's the best way to teach checkpatch about this? I couldn't find the > right place to do it. (And more generally, can it also suggest https > over http?) Bjorn's patch: https://lore.kernel.org/lkml/20201217235615.43328-1-helg...@kernel.org/ And my comments: https://lore.kernel.org/lkml/3e21b6e87e219d6538a193a9021b965fd8180025.ca...@perches.com/
Re: [PATCH] rtlwifi: rtl8821ae: phy: Simplify bool comparison
Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:3853:7-17: > WARNING: Comparison of 0/1 to bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Patch applied to wireless-drivers-next.git, thanks. 8e79106a7dbb rtlwifi: rtl8821ae: phy: Simplify bool comparison -- https://patchwork.kernel.org/project/linux-wireless/patch/1612840381-109714-1-git-send-email-jiapeng.ch...@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: rtl8192se: Simplify bool comparison
Jiapeng Chong wrote: > Fix the follow coccicheck warnings: > > ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27: > WARNING: Comparison of 0/1 to bool variable. > > ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26: > WARNING: Comparison of 0/1 to bool variable. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Patch applied to wireless-drivers-next.git, thanks. 15085446c171 rtlwifi: rtl8192se: Simplify bool comparison -- https://patchwork.kernel.org/project/linux-wireless/patch/1612839264-85773-1-git-send-email-jiapeng.ch...@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] nvme: Add 48-bit DMA address quirk for Amazon NVMe controllers
On Wed, Feb 10, 2021 at 01:39:42AM +0100, Filippo Sironi wrote: > Amazon NVMe controllers do not support 64-bit DMA addresses; they are > limited to 48-bit DMA addresses. Let's add a quirk to ensure that we > make use of 48-bit DMA addresses to avoid misbehavior. This should probably say some, and mention that they do not follow the spec. But I can fix this up when applying the patch.
Re: [PATCH 1/4] perf/core: Add support to exclude kernel mode instruction tracing
Hi Peter, On 2021-02-02 11:41, Sai Prakash Ranjan wrote: Hi Peter, On 2021-02-01 19:11, Peter Zijlstra wrote: On Mon, Feb 01, 2021 at 01:11:04PM +0530, Sai Prakash Ranjan wrote: Ok I suppose you mean CONFIG_SECURITY_LOCKDOWN_LSM? But I don't see how this new config has to depend on that? This can work independently whether complete lockdown is enforced or not since it applies to only hardware instruction tracing. Ideally this depends on several hardware tracing configs such as ETMs and others but we don't need them because we are already exposing PERF_PMU_CAP_ITRACE check in the events core. If you don't have lockdown, root pretty much owns the kernel, or am I missing something? You are right in saying that without lockdown root would own kernel but this config(EXCLUDE_KERNEL) will independently make sure that kernel level pmu tracing is not allowed(we return -EACCES) even if LOCKDOWN config is disabled. So I'm saying that we don't need to depend on LOCKDOWN config, its good to have LOCKDOWN config enabled but perf subsystem doesn't have to care about that. be used for some speculative execution based attacks. Which other kernel level PMUs can be used to get a full branch trace that is not locked down? If there is one, then this should probably be applied to it as well. Just the regular counters. The information isn't as accurate, but given enough goes you can infer plenty. Just like all the SMT size-channel attacks. Sure, PT and friends make it even easier, but I don't see a fundamental distinction. Right, we should then exclude all kernel level pmu tracing, is it fine? if (IS_ENABLED(CONFIG_EXCLUDE_KERNEL_HW_ITRACE) && !attr.exclude_kernel)) return -EACCES; Sorry for being pushy, but does the above make sense? Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] staging: rtl8723bs: fix block comments alignment
On Wed, Feb 10, 2021 at 10:27:17AM +0300, Dan Carpenter wrote:
> On Wed, Feb 10, 2021 at 12:23:17AM +0530, karthik alapati wrote:
> > fix checkpatch.pl warning for "block comments should align the * on each
> > line"
> >
> > Signed-off-by: karthik alapati
> > ---
> > .../staging/rtl8723bs/hal/rtl8723b_phycfg.c | 204 +-
> > 1 file changed, 102 insertions(+), 102 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > index cf23414d7..003f954c2 100644
> > --- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > +++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
> > @@ -20,16 +20,16 @@
> > #define MAX_DOZE_WAITING_TIMES_9x 64
> >
> > /**
> > -* Function:phy_CalculateBitShift
> > -*
> > -* OverView:Get shifted position of the BitMask
> > -*
> > -* Input:
> > -* u32 BitMask,
> > -*
> > -* Output: none
> > -* Return: u32 Return the shift bit bit position of the mask
> > -*/
> > + * Function: phy_CalculateBitShift
> > + *
> > + * OverView: Get shifted position of the BitMask
> > + *
> > + * Input:
> > + * u32 BitMask,
>
> Why is this on a different line??
>
> > + *
> > + * Output: none
> > + * Return: u32 Return the shift bit bit position of the mask
>
> The "u32" is indented more than the "none". "bit bit" is probably a
> typo?
>
> > + */
> > static u32 phy_CalculateBitShift(u32 BitMask)
> > {
> > u32 i;
>
> There is a proper kernel-doc style that function comments are supposed
> to use. https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html
>
> ./scripts/kernel-doc -v -none drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
>
> regards,
> dan carpenter
>
thats my old patch
the new one is already sent to greg,lkml
Re: [PATCH] Documentation: Replace lkml.org links with lore
On Sun, Jan 10, 2021 at 12:41:44PM -0800, Joe Perches wrote: > Replace the lkml.org links with lore to better use a single source > that's more likely to stay available long-term. What's the best way to teach checkpatch about this? I couldn't find the right place to do it. (And more generally, can it also suggest https over http?) -- Kees Cook
Re: [PATCH v2 01/14] x86/fault: Fix AMD erratum #91 errata fixup for user code
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v2] mm: cma: support sysfs
On Tue, Feb 09, 2021 at 11:16:07PM -0800, John Hubbard wrote:
> On 2/9/21 11:12 PM, Minchan Kim wrote:
> ...
> > > > Agreed. How about this for the warning part?
> > > >
> > > > +
> > > > +/*
> > > > + * note: kobj_type should provide a release function to free
> > > > dynamically
> > > > + * allocated object since kobject is responsible for controlling
> > > > lifespan
> > > > + * of the object. However, cma_area is static object so technially, it
> > > > + * doesn't need release function. It's very exceptional case so pleaes
> > > > + * do not follow this model.
> > > > + */
> > > > static struct kobj_type cma_ktype = {
> > > > .sysfs_ops = _sysfs_ops,
> > > > .default_groups = cma_groups
> > > > + .release = NULL, /* do not follow. See above */
> > > > };
> > > >
> > >
> > > No, please no. Just do it the correct way, what is the objection to
> > > creating a few dynamic kobjects from the heap? How many of these are
> > > you going to have that it will somehow be "wasteful"?
> > >
> > > Please do it properly.
> >
> > Oh, I misunderstood your word "don't provide a release function for the
> > kobject" so thought you agreed on John. If you didn't, we are stuck again:
> > IIUC, the objection from John was the cma_stat lifetime should be on parent
> > object, which is reasonable and make code simple.
> > Frankly speaking, I don't have strong opinion about either approach.
> > John?
> >
>
> We should do it as Greg requests, now that it's quite clear that he's
> insisting
> on this. Not a big deal.
>
> I just am not especially happy about the inability to do natural, efficient
> things here, such as use a statically allocated set of things with sysfs. And
> I remain convinced that the above is not "improper"; it's a reasonable
> step, given the limitations of the current sysfs design. I just wanted to say
> that out loud, as my proposal sinks to the bottom of the trench here. haha :)
What is "odd" is that you are creating an object in the kernel that you
_never_ free. That's not normal at all in the kernel, and so, your wish
to have a kobject that you never free represent this object also is not
normal :)
thanks,
greg k-h
Re: [PATCH 0/4] crypto: hisilicon - some updates to adapt Kunpeng930
On Thu, Feb 04, 2021 at 04:59:32PM +0800, Hui Tang wrote: > 1.Update clusters number for both Kunpeng920 and Kunpeng930. > 2.Some bugfixs only on Kunpeng920, so added hardware version wrap. > 3.Fix use of 'dma_map_single'. > 4.Fix PASID on Kunpeng930. > > Hui Tang (2): > crypto: hisilicon/hpre - adapt the number of clusters > crypto: hisilicon/hpre - tiny fix > > Weili Qian (2): > crypto:hisilicon/qm - fix use of "dma_map_single" > crypto:hisilicon - PASID fixed on Kupeng 930 > > drivers/crypto/hisilicon/hpre/hpre.h | 8 ++- > drivers/crypto/hisilicon/hpre/hpre_main.c | 100 > +++--- > drivers/crypto/hisilicon/qm.c | 61 +++--- > drivers/crypto/hisilicon/qm.h | 1 + > drivers/crypto/hisilicon/sec2/sec_main.c | 2 +- > drivers/crypto/hisilicon/zip/zip_main.c | 2 +- > 6 files changed, 110 insertions(+), 64 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [ANNOUNCE] exfatprogs-1.1.0 version released
On Wed, Feb 10, 2021 at 5:51 AM Namjae Jeon wrote: > > Hope Sven will do a new release for Debian. > > ( Note that Debian/bullseye release plans "Milestone 2" this Friday, > > February 12th (see [1] > "Key > > release dates" > "[2021-Feb-12] Soft Freeze"). Dunno which impact this > > might have on this. ) > I hope he will do it, too! > > Thanks Sedat:) I filed Debian Bug #982431 "exfatprogs: Update to version 1.1.0" - Sedat - [1] https://bugs.debian.org/982431
Re: [PATCH] crypto: hisilicon/hpre - enable Elliptic curve cryptography
On Thu, Feb 04, 2021 at 05:00:24PM +0800, Hui Tang wrote: > Enable x25519/x448/ecdh/ecdsa/sm2 algorithm on Kunpeng 930. > > Signed-off-by: Hui Tang > --- > drivers/crypto/hisilicon/hpre/hpre_main.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/6] crypto: hisilicon/qm - misc fixes
On Fri, Feb 05, 2021 at 06:12:52PM +0800, Weili Qian wrote: > This patchset fixes some bugs: > 1. Removing the waiting reset's completion logic of driver. > 2. In order to prevent request missing, >call user's callback before device resetting. > 3. Fix the value of 'QM_SQC_VFT_BASE_MASK_V2'. > 4. Update irqflag. > 5. Do not reset when CE error occurs. > 6. Fix printing format issue. > > Sihang Chen (1): > crypto: hisilicon/qm - update irqflag > > Weili Qian (5): > crypto: hisilicon/qm - removing driver after reset > crypto: hisilicon/qm - fix request missing error > crypto: hisilicon/qm - fix the value of 'QM_SQC_VFT_BASE_MASK_V2' > crypto: hisilicon/qm - do not reset hardware when CE happens > crypto: hisilicon/qm - fix printing format issue > > drivers/crypto/hisilicon/hpre/hpre_main.c | 3 +- > drivers/crypto/hisilicon/qm.c | 124 > +- > drivers/crypto/hisilicon/qm.h | 5 +- > drivers/crypto/hisilicon/sec2/sec_main.c | 3 +- > drivers/crypto/hisilicon/zip/zip_main.c | 7 +- > 5 files changed, 101 insertions(+), 41 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] crypto: octeontx2 - fix -Wpointer-bool-conversion warning
On Thu, Feb 04, 2021 at 04:42:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When CONFIG_CPUMASK_OFFSTACK is disabled, clang reports a warning
> about a bogus condition:
>
> drivers/crypto/marvell/octeontx2/otx2_cptlf.c:334:21: error: address of array
> 'lfs->lf[slot].affinity_mask' will always evaluate to 'true'
> [-Werror,-Wpointer-bool-conversion]
> if (lfs->lf[slot].affinity_mask)
> ~~ ~~^
>
> In this configuration, the free_cpumask_var() function does nothing,
> so the condition could be skipped.
>
> When the option is enabled, there is no warning, but the check
> is also redundant because free_cpumask_var() falls back to kfree(),
> which is documented as ignoring NULL pointers.
>
> Remove the check to avoid the warning.
>
> Fixes: 64506017030d ("crypto: octeontx2 - add LF framework")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/crypto/marvell/octeontx2/otx2_cptlf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] mm/huge_memory.c: Remove unnecessary local variable ret2
There is no need to use a new local variable ret2 to get the return value
of handle_userfault(). Use ret directly to make code more succinct.
Signed-off-by: Miaohe Lin
---
mm/huge_memory.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 395c75111d33..caf552834dbb 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -624,14 +624,12 @@ static vm_fault_t __do_huge_pmd_anonymous_page(struct
vm_fault *vmf,
/* Deliver the page fault to userland */
if (userfaultfd_missing(vma)) {
- vm_fault_t ret2;
-
spin_unlock(vmf->ptl);
put_page(page);
pte_free(vma->vm_mm, pgtable);
- ret2 = handle_userfault(vmf, VM_UFFD_MISSING);
- VM_BUG_ON(ret2 & VM_FAULT_FALLBACK);
- return ret2;
+ ret = handle_userfault(vmf, VM_UFFD_MISSING);
+ VM_BUG_ON(ret & VM_FAULT_FALLBACK);
+ return ret;
}
entry = mk_huge_pmd(page, vma->vm_page_prot);
--
2.19.1
Re: [PATCH] crypto: cavium: remove casting dma_alloc_coherent
On Thu, Feb 04, 2021 at 07:11:33AM +, Xu Wang wrote: > Remove casting the values returned by dma_alloc_coherent. > > Signed-off-by: Xu Wang > --- > drivers/crypto/cavium/cpt/cptvf_main.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: keembay-ocs-aes - Fix 'q' assignment during CCM B0 generation
On Wed, Feb 03, 2021 at 03:42:10PM +, Daniele Alessandrelli wrote: > From: Daniele Alessandrelli > > In ocs_aes_ccm_write_b0(), 'q' (the octet length of the binary > representation of the octet length of the payload) is set to 'iv[0]', > while it should be set to 'iv[0] & 0x7' (i.e., only the last 3 > bits of iv[0] should be used), as documented in NIST Special Publication > 800-38C: > https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf > > In practice, this is not an issue, since 'iv[0]' is checked to be in the > range [1-7] by ocs_aes_validate_inputs(), but let's fix the assignment > anyway, in order to make the code more robust. > > Signed-off-by: Daniele Alessandrelli > --- > drivers/crypto/keembay/ocs-aes.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[nouveau] WARNING: possible circular locking dependency detected in linux-next
I've been seeing these warnings for a couple of weeks now. Any
pointers on how to address this would be much appreciated.
[ 57.207457] ==
[ 57.207470] WARNING: possible circular locking dependency detected
[ 57.207483] 5.11.0-rc7-next-20210209 #142 Tainted: GW
[ 57.207497] --
[ 57.207508] Xorg/459 is trying to acquire lock:
[ 57.207521] 888016edc518 (>mutex){+.+.}-{3:3}, at:
nouveau_bo_move+0x4bf/0x2ec0 [nouveau]
[faddr2line]
nouveau_bo_move+0x4bf/0x2ec0:
nouveau_bo_move_m2mf at
/home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_bo.c:804
(inlined by) nouveau_bo_move at
/home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_bo.c:1024
/home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_bo.c:800,804
if (drm_drv_uses_atomic_modeset(drm->dev))
mutex_lock(>mutex);
else
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, ctx->interruptible);
[ 57.207923]
but task is already holding lock:
[ 57.207934] 88801f49e9a0
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
nouveau_bo_pin+0xc1/0xb60 [nouveau]
[faddr2line]
nouveau_bo_pin+0xc1/0xb60:
ttm_bo_reserve at /home/sasha/linux-next/./include/drm/ttm/ttm_bo_driver.h:152
(inlined by) nouveau_bo_pin at
/home/sasha/linux-next/drivers/gpu/drm/nouveau/nouveau_bo.c:424
/home/sasha/linux-next/include/drm/ttm/ttm_bo_driver.h:148,154
if (interruptible)
ret = dma_resv_lock_interruptible(bo->base.resv, ticket);
else
ret = dma_resv_lock(bo->base.resv, ticket);
if (ret == -EINTR)
return -ERESTARTSYS;
return ret;
[ 57.208317]
which lock already depends on the new lock.
[ 57.208329]
the existing dependency chain (in reverse order) is:
[ 57.208340]
-> #1 (reservation_ww_class_mutex){+.+.}-{3:3}:
[ 57.208373]__ww_mutex_lock.constprop.0+0x18a/0x2d40
[ 57.208395]nouveau_bo_pin+0xc1/0xb60 [nouveau]
[ 57.208753]nouveau_channel_prep+0x2c6/0xba0 [nouveau]
[ 57.209105]nouveau_channel_new+0x127/0x2020 [nouveau]
[ 57.209457]nouveau_abi16_ioctl_channel_alloc+0x33b/0xdf0 [nouveau]
[ 57.209809]drm_ioctl_kernel+0x1cb/0x260
[ 57.209826]drm_ioctl+0x420/0x850
[ 57.209841]nouveau_drm_ioctl+0xdf/0x210 [nouveau]
[ 57.210198]__x64_sys_ioctl+0x122/0x190
[ 57.210214]do_syscall_64+0x33/0x40
[ 57.210230]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 57.210247]
-> #0 (>mutex){+.+.}-{3:3}:
[ 57.210280]__lock_acquire+0x2a01/0x5ab0
[ 57.210298]lock_acquire+0x1a9/0x690
[ 57.210314]__mutex_lock+0x125/0x1140
[ 57.210329]nouveau_bo_move+0x4bf/0x2ec0 [nouveau]
[ 57.210686]ttm_bo_handle_move_mem+0x1b6/0x570 [ttm]
[ 57.210719]ttm_bo_validate+0x316/0x420 [ttm]
[ 57.210750]nouveau_bo_pin+0x3c4/0xb60 [nouveau]
[ 57.211107]nv50_wndw_prepare_fb+0x117/0xcb0 [nouveau]
[ 57.211460]drm_atomic_helper_prepare_planes+0x1ec/0x600
[ 57.211477]nv50_disp_atomic_commit+0x189/0x530 [nouveau]
[ 57.211833]drm_atomic_helper_update_plane+0x2ac/0x380
[ 57.211849]drm_mode_cursor_universal+0x3f3/0xb40
[ 57.211865]drm_mode_cursor_common+0x27b/0x930
[ 57.211880]drm_mode_cursor_ioctl+0x95/0xd0
[ 57.211895]drm_ioctl_kernel+0x1cb/0x260
[ 57.211910]drm_ioctl+0x420/0x850
[ 57.211925]nouveau_drm_ioctl+0xdf/0x210 [nouveau]
[ 57.212281]__x64_sys_ioctl+0x122/0x190
[ 57.212297]do_syscall_64+0x33/0x40
[ 57.212312]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 57.212328]
other info that might help us debug this:
[ 57.212339] Possible unsafe locking scenario:
[ 57.212350]CPU0CPU1
[ 57.212360]
[ 57.212370] lock(reservation_ww_class_mutex);
[ 57.212390]lock(>mutex);
[ 57.212410]lock(reservation_ww_class_mutex);
[ 57.212430] lock(>mutex);
[ 57.212449]
*** DEADLOCK ***
[ 57.212460] 3 locks held by Xorg/459:
[ 57.212473] #0: c944fb38
(crtc_ww_class_acquire){+.+.}-{0:0}, at:
drm_mode_cursor_common+0x1fd/0x930
[ 57.212520] #1: 88800d9f2098
(crtc_ww_class_mutex){+.+.}-{3:3}, at: modeset_lock+0xdb/0x4c0
[ 57.212564] #2: 88801f49e9a0
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
nouveau_bo_pin+0xc1/0xb60 [nouveau]
[ 57.212949]
stack backtrace:
[ 57.212961] CPU: 0 PID: 459 C
Re: [PATCH] crypto: Fixed optimzation to optimization in the file crypto/xor.c
On Wed, Feb 03, 2021 at 09:09:33PM +0530, Bhaskar Chowdhury wrote: > > s/optimzation/optimization/ > > Signed-off-by: Bhaskar Chowdhury > --- > crypto/xor.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: powerpc: remove unneeded semicolon
On Tue, Feb 02, 2021 at 11:17:30AM +0800, Yang Li wrote: > Eliminate the following coccicheck warning: > ./arch/powerpc/crypto/sha256-spe-glue.c:132:2-3: Unneeded > semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > arch/powerpc/crypto/sha256-spe-glue.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()
On Wed, Feb 03, 2021 at 11:28:37AM +, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli
>
> The length ('len' parameter) passed to crypto_ecdh_decode_key() is never
> checked against the length encoded in the passed buffer ('buf'
> parameter). This could lead to an out-of-bounds access when the passed
> length is less than the encoded length.
>
> Add a check to prevent that.
>
> Signed-off-by: Daniele Alessandrelli
> ---
> crypto/ecdh_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: marvell - CRYPTO_DEV_OCTEONTX2_CPT should depend on ARCH_THUNDER2
On Mon, Feb 01, 2021 at 02:44:31PM +0100, Geert Uytterhoeven wrote:
> The Marvell OcteonTX2 CPT physical function PCI device is present only
> on OcteonTx2 SoC, and not available as an independent PCIe endpoint.
> Hence add a dependency on ARCH_THUNDER2, to prevent asking the user
> about this driver when configuring a kernel without OcteonTx2 platform
> support.
>
> Fixes: 5e8ce8334734c5f2 ("crypto: marvell - add Marvell OcteonTX2 CPT PF
> driver")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/crypto/marvell/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: caam - Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE
On Tue, Feb 02, 2021 at 10:06:15AM +0800, Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./drivers/crypto/caam/debugfs.c:23:0-23: WARNING: caam_fops_u64_ro > should be defined with DEFINE_DEBUGFS_ATTRIBUTE. > > ./drivers/crypto/caam/debugfs.c:22:0-23: WARNING: caam_fops_u32_ro > should be defined with DEFINE_DEBUGFS_ATTRIBUTE. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > Changes in v2: > -Modified subject. > > drivers/crypto/caam/debugfs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] hw_random/timeriomem-rng: Fix cooldown period calculation
On Mon, Feb 01, 2021 at 04:14:59PM +0100, Jan Henrik Weinstock wrote: > Ensure cooldown period tolerance of 1% is actually accounted for. > > Signed-off-by: Jan Henrik Weinstock > --- > > Before patch, if period_us was less than 100us, no extra sleep time was > added. If it was more than 100us, only 1us extra time (and not 1%) is slept. > > drivers/char/hw_random/timeriomem-rng.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. BTW your patch was space corrupted so I had to apply it by hand. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v6 04/11] crypto: qce: skcipher: Return unsupported if any three keys are same for DES3 algorithms
On Sun, Feb 07, 2021 at 09:39:39AM -0500, Thara Gopinath wrote: > > + /* > + * The crypto engine does not support any two keys > + * being the same for triple des algorithms. The > + * verify_skcipher_des3_key does not check for all the > + * below conditions. Return -ENOKEY in case any two keys > + * are the same. Revisit to see if a fallback cipher > + * is needed to handle this condition. > + */ > + memcpy(_key, key, DES3_EDE_KEY_SIZE); > + if (!((_key[0] ^ _key[2]) | (_key[1] ^ _key[3])) | > + !((_key[2] ^ _key[4]) | (_key[3] ^ _key[5])) | > + !((_key[0] ^ _key[4]) | (_key[1] ^ _key[5]))) > + return -ENOKEY; This introduces a sparse warning: CHECK ../drivers/crypto/qce/skcipher.c ../drivers/crypto/qce/skcipher.c:241:58: warning: dubious: !x | !y ../drivers/crypto/qce/skcipher.c:242:58: warning: dubious: x | !y Please make sure that you test your patches with C=1 so that you don't introduce new sparse warnings. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] mm: cma: support sysfs
On 2/9/21 11:12 PM, Minchan Kim wrote:
...
Agreed. How about this for the warning part?
+
+/*
+ * note: kobj_type should provide a release function to free dynamically
+ * allocated object since kobject is responsible for controlling lifespan
+ * of the object. However, cma_area is static object so technially, it
+ * doesn't need release function. It's very exceptional case so pleaes
+ * do not follow this model.
+ */
static struct kobj_type cma_ktype = {
.sysfs_ops = _sysfs_ops,
.default_groups = cma_groups
+ .release = NULL, /* do not follow. See above */
};
No, please no. Just do it the correct way, what is the objection to
creating a few dynamic kobjects from the heap? How many of these are
you going to have that it will somehow be "wasteful"?
Please do it properly.
Oh, I misunderstood your word "don't provide a release function for the
kobject" so thought you agreed on John. If you didn't, we are stuck again:
IIUC, the objection from John was the cma_stat lifetime should be on parent
object, which is reasonable and make code simple.
Frankly speaking, I don't have strong opinion about either approach.
John?
We should do it as Greg requests, now that it's quite clear that he's insisting
on this. Not a big deal.
I just am not especially happy about the inability to do natural, efficient
things here, such as use a statically allocated set of things with sysfs. And
I remain convinced that the above is not "improper"; it's a reasonable
step, given the limitations of the current sysfs design. I just wanted to say
that out loud, as my proposal sinks to the bottom of the trench here. haha :)
thanks,
--
John Hubbard
NVIDIA
[PATCH] mm/hugetlb: optimize the surplus state transfer code in move_hugetlb_state()
We should not transfer the per-node surplus state when we do not cross the
node in order to save some cpu cycles
Signed-off-by: Miaohe Lin
---
mm/hugetlb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index da347047ea10..4f2c92ddbca4 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5632,6 +5632,12 @@ void move_hugetlb_state(struct page *oldpage, struct
page *newpage, int reason)
SetHPageTemporary(oldpage);
ClearHPageTemporary(newpage);
+ /*
+* There is no need to transfer the per-node surplus state
+* when we do not cross the node.
+*/
+ if (new_nid == old_nid)
+ return;
spin_lock(_lock);
if (h->surplus_huge_pages_node[old_nid]) {
h->surplus_huge_pages_node[old_nid]--;
--
2.19.1
Re: [page-reclaim] Augmented Page Reclaim
On Tue, Feb 09, 2021 at 01:32:58PM -0800, Jesse Barnes wrote: > > == > > Augmented Page Reclaim > > == > > We would like to share a work with you and see if there is enough > > interest to warrant a run for the mainline. This work is a part of > > result from a decade of research and experimentation in memory > > overcommit at Google: an augmented page reclaim that, in our > > experience, is performant, versatile and, more importantly, simple. > > Per discussion on IRC, maybe some additional background would help. And I'll add more details to the doc included in the tree once I've finished collecting feedback. > In looking at browser workloads on Chrome OS, we found that reclaim was: > 1) too expensive in terms of CPU usage We have two general metrics for this item: CPU time spent on page reclaim and (direct) page reclaim latency. CPU usage is important to everybody but latency is also quite important for phones, laptops, etc. > 2) often making poor decisions about what to reclaim We have another two metrics here: the number of refaults and the number of false inactive pages. For example, it's bad if pages refault within a hundred of milliseconds after they have been reclaimed. Also it's bad if reclaim thinks many pages are inactive but later finds they are actually active. > This work was mainly targeted toward improving those things, with an > eye toward interactive performance for browser workloads. > > We have a few key tests we use for that, that measure tab switch times > and number of tab discards when under memory pressure, and this > approach significantly improves these (see Yu's data). We monitor workload-specific metrics as well. For example, we found page reclaim also affects battery life, tab switch latency and the number of janks (pauses when scrolling web pages) on Chrome OS. I don't want to dump everything here because they seem irrelevant to most people. > We do expect this approach will also be beneficial to cloud workloads, > and so are looking for people to try it out in their environments with > their favorite key tests or workloads. And if you are interested in our workload-specific metrics, Android, Cloud, etc., please feel free to contact us. Any other questions, concerns and suggestions are also welcome.
Re: [PATCH v2] mm: cma: support sysfs
On Wed, Feb 10, 2021 at 07:43:37AM +0100, Greg KH wrote:
> On Tue, Feb 09, 2021 at 01:13:17PM -0800, Minchan Kim wrote:
> > On Tue, Feb 09, 2021 at 12:11:20PM -0800, John Hubbard wrote:
> > > On 2/9/21 9:49 AM, Greg KH wrote:
> > > > > > That's fine if you want to add it to the parent. If so, then the
> > > > > > kobject controls the lifetime of the structure, nothing else can.
> > > > >
> > > > > The problem was parent object(i.e., struct cma cma_areas) is
> > > > > static arrary so kobj->release function will be NULL or just
> > > > > dummy. Is it okay? I thought it was one of the what you wanted
> > > > > to avoid it.
> > > >
> > > > No, that is not ok.
> > > >
> > > > > > Either is fine with me, what is "forbidden" is having a kobject and
> > > > > > somehow thinking that it does not control the lifetime of the
> > > > > > structure.
> > > > >
> > > > > Since parent object is static arrary, there is no need to control the
> > > > > lifetime so I am curious if parent object approach is okay from
> > > > > kobject
> > > > > handling point of view.
> > > >
> > > > So the array is _NEVER_ freed? If not, fine, don't provide a release
> > > > function for the kobject, but ick, just make a dynamic kobject I don't
> > > > see the problem for something so tiny and not very many...
> > > >
> > >
> > > Yeah, I wasn't trying to generate so much discussion, I initially thought
> > > it
> > > would be a minor comment: "just use an embedded struct and avoid some
> > > extra
> > > code", at first.
> > >
> > > > I worry that any static kobject might be copied/pasted as someone might
> > > > think this is an ok thing to do. And it's not an ok thing to do.
> > > >
> > >
> > > Overall, then, we're seeing that there is a small design hole: in order
> > > to use sysfs most naturally, you either much provide a dynamically
> > > allocated
> > > item for it, or you must use the static kobject, and the second one sets a
> > > bad example.
> > >
> > > I think we should just use a static kobject, with a cautionary comment to
> > > would-be copy-pasters, that explains the design constraints above. That
> > > way,
> > > we still get a nice, less-code implementation, a safe design, and it only
> > > really costs us a single carefully written comment.
> > >
> > > thanks,
> >
> > Agreed. How about this for the warning part?
> >
> > +
> > +/*
> > + * note: kobj_type should provide a release function to free dynamically
> > + * allocated object since kobject is responsible for controlling lifespan
> > + * of the object. However, cma_area is static object so technially, it
> > + * doesn't need release function. It's very exceptional case so pleaes
> > + * do not follow this model.
> > + */
> > static struct kobj_type cma_ktype = {
> > .sysfs_ops = _sysfs_ops,
> > .default_groups = cma_groups
> > + .release = NULL, /* do not follow. See above */
> > };
> >
>
> No, please no. Just do it the correct way, what is the objection to
> creating a few dynamic kobjects from the heap? How many of these are
> you going to have that it will somehow be "wasteful"?
>
> Please do it properly.
Oh, I misunderstood your word "don't provide a release function for the
kobject" so thought you agreed on John. If you didn't, we are stuck again:
IIUC, the objection from John was the cma_stat lifetime should be on parent
object, which is reasonable and make code simple.
Frankly speaking, I don't have strong opinion about either approach.
John?
[PATCH] mfd: dbx500-prcmu: Use true and false for bool variable
Fix the following coccicheck warning:
./include/linux/mfd/db8500-prcmu.h:723:8-9: WARNING: return of 0/1 in
function 'db8500_prcmu_is_ac_wake_requested' with return type bool.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
include/linux/mfd/db8500-prcmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
index 4b63d3e..a62de3d 100644
--- a/include/linux/mfd/db8500-prcmu.h
+++ b/include/linux/mfd/db8500-prcmu.h
@@ -720,7 +720,7 @@ static inline int db8500_prcmu_load_a9wdog(u8 id, u32 val)
static inline bool db8500_prcmu_is_ac_wake_requested(void)
{
- return 0;
+ return false;
}
static inline int db8500_prcmu_set_arm_opp(u8 opp)
--
1.8.3.1
Re: [patch V2 12/13] softirq: Move do_softirq_own_stack() to generic asm header
On Wed, Feb 10, 2021 at 12:40:53AM +0100, Thomas Gleixner wrote: > To avoid include recursion hell move the do_softirq_own_stack() related > content into a generic asm header and include it from all places in arch/ > which need the prototype. > > This allows architectures to provide an inline implementation of > do_softirq_own_stack() without introducing a lot of #ifdeffery all over the > place. > > Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook -- Kees Cook
Re: [patch V2 11/13] softirq: Move __ARCH_HAS_DO_SOFTIRQ to Kconfig
On Wed, Feb 10, 2021 at 12:40:52AM +0100, Thomas Gleixner wrote: > To prepare for inlining do_softirq_own_stack() replace > __ARCH_HAS_DO_SOFTIRQ with a Kconfig switch and select it in the affected > architectures. > > This allows in the next step to move the function prototype and the inline > stub into a seperate asm-generic header file which is required to avoid > include recursion. > > Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook -- Kees Cook
Re: [PATCH net-next 7/9] net: phy: icplus: select page before writing control register
On 09.02.2021 17:40, Michael Walle wrote:
> Registers >= 16 are paged. Be sure to set the page. It seems this was
> working for now, because the default is correct for the registers used
> in the driver at the moment. But this will also assume, nobody will
> change the page select register before linux is started. The page select
> register is _not_ reset with a soft reset of the PHY.
>
> Add read_page()/write_page() support for the IP101G and use it
> accordingly.
>
> Signed-off-by: Michael Walle
> ---
> drivers/net/phy/icplus.c | 50 +++-
> 1 file changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/phy/icplus.c b/drivers/net/phy/icplus.c
> index a6e1c7611f15..858b9326a72d 100644
> --- a/drivers/net/phy/icplus.c
> +++ b/drivers/net/phy/icplus.c
> @@ -49,6 +49,8 @@ MODULE_LICENSE("GPL");
> #define IP101G_DIGITAL_IO_SPEC_CTRL 0x1d
> #define IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32 BIT(2)
>
> +#define IP101G_DEFAULT_PAGE 16
> +
> #define IP175C_PHY_ID 0x02430d80
> #define IP1001_PHY_ID 0x02430d90
> #define IP101A_PHY_ID 0x02430c54
> @@ -250,23 +252,25 @@ static int ip101a_g_probe(struct phy_device *phydev)
> static int ip101a_g_config_init(struct phy_device *phydev)
> {
> struct ip101a_g_phy_priv *priv = phydev->priv;
> - int err;
> + int oldpage, err;
> +
> + oldpage = phy_select_page(phydev, IP101G_DEFAULT_PAGE);
>
> /* configure the RXER/INTR_32 pin of the 32-pin IP101GR if needed: */
> switch (priv->sel_intr32) {
> case IP101GR_SEL_INTR32_RXER:
> - err = phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
> - IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32, 0);
> + err = __phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
> +IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32, 0);
> if (err < 0)
> - return err;
> + goto out;
> break;
>
> case IP101GR_SEL_INTR32_INTR:
> - err = phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
> - IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32,
> - IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32);
> + err = __phy_modify(phydev, IP101G_DIGITAL_IO_SPEC_CTRL,
> +IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32,
> +IP101G_DIGITAL_IO_SPEC_CTRL_SEL_INTR32);
> if (err < 0)
> - return err;
> + goto out;
> break;
>
> default:
> @@ -284,12 +288,14 @@ static int ip101a_g_config_init(struct phy_device
> *phydev)
>* reserved as 'write-one'.
>*/
> if (priv->model == IP101A) {
> - err = phy_set_bits(phydev, IP10XX_SPEC_CTRL_STATUS,
> IP101A_G_APS_ON);
> + err = __phy_set_bits(phydev, IP10XX_SPEC_CTRL_STATUS,
> + IP101A_G_APS_ON);
> if (err)
> - return err;
> + goto out;
> }
>
> - return 0;
> +out:
> + return phy_restore_page(phydev, oldpage, err);
If a random page was set before entering config_init, do we actually want
to restore it? Or wouldn't it be better to set the default page as part
of initialization?
> }
>
> static int ip101a_g_ack_interrupt(struct phy_device *phydev)
> @@ -347,6 +353,26 @@ static irqreturn_t ip101a_g_handle_interrupt(struct
> phy_device *phydev)
> return IRQ_HANDLED;
> }
>
> +static int ip101a_g_read_page(struct phy_device *phydev)
> +{
> + struct ip101a_g_phy_priv *priv = phydev->priv;
> +
> + if (priv->model == IP101A)
> + return 0;
> +
> + return __phy_read(phydev, IP101G_PAGE_CONTROL);
> +}
> +
> +static int ip101a_g_write_page(struct phy_device *phydev, int page)
> +{
> + struct ip101a_g_phy_priv *priv = phydev->priv;
> +
> + if (priv->model == IP101A)
> + return 0;
> +
> + return __phy_write(phydev, IP101G_PAGE_CONTROL, page);
> +}
> +
> static struct phy_driver icplus_driver[] = {
> {
> PHY_ID_MATCH_MODEL(IP175C_PHY_ID),
> @@ -373,6 +399,8 @@ static struct phy_driver icplus_driver[] = {
> .config_intr= ip101a_g_config_intr,
> .handle_interrupt = ip101a_g_handle_interrupt,
> .config_init= ip101a_g_config_init,
> + .read_page = ip101a_g_read_page,
> + .write_page = ip101a_g_write_page,
> .soft_reset = genphy_soft_reset,
> .suspend= genphy_suspend,
> .resume = genphy_resume,
>
Re: [PATCH v7 3/6] mfd: bd9576: Add IRQ support
Hello Lee,
I appreciate your thorough reviews :) Thanks.
On Tue, 2021-02-09 at 15:25 +, Lee Jones wrote:
> On Fri, 22 Jan 2021, Matti Vaittinen wrote:
>
> > BD9573 and BD9576 support set of "protection" interrupts for
> > "fatal"
> > issues. Those lead to SOC reset as PMIC shuts the power outputs.
> > Thus
> > there is no relevant IRQ handling for them.
> >
> > Few "detection" interrupts were added to the BD9576 with the idea
> > that
> > SOC could take some recovery-action before error gets
> > unrecoverable.
> >
> > Unfortunately the BD9576 interrupt logic was not re-evaluated. IRQs
> > are not designed to be properly acknowleged - and IRQ line is kept
> > active for whole duration of error condition (in comparison to
> > informing only about state change).
> >
> > For above reason, do not consider missing IRQ as error.
> >
> > Signed-off-by: Matti Vaittinen
> > case ROHM_CHIP_TYPE_BD9573:
> > mfd = bd9573_mfd_cells;
> > cells = ARRAY_SIZE(bd9573_mfd_cells);
> > + /* BD9573 only supports fatal IRQs which we do not
> > handle */
>
> Why not?
Because 'fatal' in the context of this comment means that when this
condition occurs the PMIC will do emergency shut down for power outputs
- which means the processor will not be able to handle the IRQ as it
loses the power. Maybe I'd better clarify the meaning of 'fatal' here.
+ /*
> > +* BD9576 behaves badly. It kepts IRQ asserted for the whole
>
> This is solution is less than pretty.
Um, sorry, What are you referring to?
> > +* duration of detected HW condition (like over temp). This
> > does
>
> "over-temperature"
Right. Thanks :)
> > +* not play nicely under any condition but we can work around
> > it
> > +* except when we have shared IRQs. So we don't require IRQ to
> > be
> > +* populated to help those poor sods who did connect IRQ to
> > shared pin.
>
> No swearing in comments please.
Ok. This is actually a good reminder for me that I can't know how
something sounds like for a reader. (That phrase sounds quite innocent
to me but I've no idea how 'severe' swearing that is for the rest of
the world). I'll clean this up.
> How do you know if an IRQ is shared?
I don't. This is something that board designer does know. And my
thinking here was to allow board designer to omit the IRQ information
from DT if he prefers to not use these IRQs. I just tried to explain
that the driver does not _require_ IRQ information to be populated.
>
> > +* If IRQ information is not given, then we mask all IRQs and
> > do not
> > +* provide IRQ resources to regulator driver - which then just
> > omits
> > +* the notifiers.
> > +*/
>
> This situation doesn't sound totally crazy. Is there no way to
> handle
> 'persistent IRQ' conditions in the kernel?
Actually there is. Even for shared IRQs in this case. I made a mistake
at the beginning when I noticed that not all of these IRQs have mask
bits in the sub-IRQ registers. So I thought that for these IRQs the
device can't be told to revert IRQ back to normal. That would have
meaned that only way to prevent IRQ storm was to disable IRQs from the
processor end. But I was mistaken. All of the IRQs can be masked from
the 'main IRQ' level register. So we can mask the whole set of IRQs
form BD9576 when IRQ triggers - and then we can get the BD9576 to
restore the IRQ line.
So yes - we can make this to somehow work. And more importantly, we
don't completely spoil the shared IRQs. Still, the IRQ handling for
BD9576 is ... how to put it ... hacky. And I think few of the setups
might not actually have use for the notifications - so making IRQs
optional just sounded like the best course of action (to me).
+ } else {
> > + ret = regmap_update_bits(regmap,
> > BD957X_REG_INT_MAIN_MASK,
> > +BD957X_MASK_INT_ALL,
> > +BD957X_MASK_INT_ALL);
>
> What's the default state of the interrupts? Unmasked?
I've learned that I'd rather not assume the default state with ROHM
ICs. I've seen all kinds of defaults changing between IC revisions. And
occasionally I've seen same IC versions having different set of
defaults depending on the OTP version. I guess this comes from
traditional operation model where ICs have been tailored to meet needs
of the different customers.
> > diff --git a/include/linux/mfd/rohm-bd957x.h
> > b/include/linux/mfd/rohm-bd957x.h
> > index 3e7ca6fe5d4f..4fa632d8467a 100644
> > --- a/include/linux/mfd/rohm-bd957x.h
> > +++ b/include/linux/mfd/rohm-bd957x.h
> > @@ -13,47 +13,109 @@ enum {
> > BD957X_VOUTS1,
> > };
> >
> > +/* The BD9576 has own IRQ 'blocks' for:
>
> Comments start on line 2.
Do you mean I should move this comment block top of the file? The idea
of this comment is to clarify the IRQs in the hardware. Hence I placed
it in the section where IRQ definitions dwell.
> > + * I2C/THERMAL,
>
> Does this precede each line?
You
RE: How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)?
> From: James Morse > Sent: Tuesday, February 9, 2021 10:15 AM > To: Dexuan Cui > Cc: Rafael J. Wysocki ; linux-a...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-hyp...@vger.kernel.org; Michael Kelley > ; Leandro Pereira > Subject: Re: How can a userspace program tell if the system supports the ACPI > S4 state (Suspend-to-Disk)? > > Hi Dexuan, > > On 05/02/2021 19:36, Dexuan Cui wrote: > >> From: Rafael J. Wysocki > >> Sent: Friday, February 5, 2021 5:06 AM > >> To: Dexuan Cui > >> Cc: linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org; > >> linux-hyp...@vger.kernel.org; Michael Kelley > >> Subject: Re: How can a userspace program tell if the system supports the > ACPI > >> S4 state (Suspend-to-Disk)? > >> > >> On Sat, Dec 12, 2020 at 2:22 AM Dexuan Cui wrote: > >>> > >>> Hi all, > >>> It looks like Linux can hibernate even if the system does not support the > ACPI > >>> S4 state, as long as the system can shut down, so "cat /sys/power/state" > >>> always contains "disk", unless we specify the kernel parameter > "nohibernate" > >>> or we use LOCKDOWN_HIBERNATION. > > >>> In some scenarios IMO it can still be useful if the userspace is able to > >>> detect if the ACPI S4 state is supported or not, e.g. when a Linux guest > >>> runs on Hyper-V, Hyper-V uses the virtual ACPI S4 state as an indicator > >>> of the proper support of the tool stack on the host, i.e. the guest is > >>> discouraged from trying hibernation if the state is not supported. > > What goes wrong? This sounds like a funny way of signalling hypervisor policy. Hi James, Sorry if I have caused any confusion. My above description only applies to x86 Linux VM on Hyper-V. For ARM64 Hyper-V, I suspect the mainline Linux kernel still can't work in a Linux VM running on ARM64 Hyper-V, so AFAIK the VM hibernation hasn't been tested: it may work or may not work. This is in our To-Do list. Linux VM on Hyper-V needs to know if hibernation is supported/enabled for the VM, mainly due to 2 reasons: 1. In the VM, the hv_balloon driver should disable the balloon up/down operations if hibernation is enabled for the VM, otherwise bad things can happen, e.g. the hv_balloon driver allocates some pages and gives the pages to the hyperpvisor; now if the VM is allowed to hibernate, later when the VM resumes back, the VM loses the pages for ever, because Hyper-V doesn't save the info of the pages that were from the VM, so Hyper-V thinks no pages need to be returned to the VM. 2. If hibernation is enabled for a VM, the VM has a Linux agent program that automatically creates and sets up the swap file for hibernation. If hibernation is not enabled for the VM, the agent should not try to create and set up the swap file for hibernation. > >>> I know we can check the S4 state by 'dmesg': > >>> > >>> # dmesg |grep ACPI: | grep support > >>> [3.034134] ACPI: (supports S0 S4 S5) > >>> > >>> But this method is unreliable because the kernel msg buffer can be filled > >>> and overwritten. Is there any better method? If not, do you think if the > >>> below patch is appropriate? Thanks! > >> > >> Sorry for the delay. > >> > >> If ACPI S4 is supported, /sys/power/disk will list "platform" as one > >> of the options (and it will be the default one then). Otherwise, > >> "platform" is not present in /sys/power/disk, because ACPI is the only > >> user of hibernation_ops. > > > This works on x86. Thanks a lot! > > > > BTW, does this also work on ARM64? > > Not today. The S4/S5 stuff is part of 'ACPI_SYSTEM_POWER_STATES_SUPPORT', > which arm64 > doesn't enable as it has a firmware mechanism that covers this on both DT and > ACPI > systems. That code is what calls hibernation_set_ops() to enable ACPI's > platform mode. Thanks for the explanation! > Regardless: hibernate works fine. What does your hypervisor do that causes > problems? > (I think all we expect from firmware is it doesn't randomise the placement of > the ACPI > tables as they aren't necessarily part of the hibernate image) > > Thanks, > James I have explained the problems above for Linux VM on ARM64 Hyper-V. I suppose you mean hibernation works fine for ARM64 bare metal. For Linux VM on ARM64 Hyper-V, I suspect some Hyper-V specific states may have to be saved and restored for hibernation. This is in our To-Do lsit. Thanks, Dexuan
[PATCH/v2] bpf: add bpf_skb_adjust_room flag BPF_F_ADJ_ROOM_ENCAP_L2_ETH
From: huangxuesen
bpf_skb_adjust_room sets the inner_protocol as skb->protocol for packets
encapsulation. But that is not appropriate when pushing Ethernet header.
Add an option to further specify encap L2 type and set the inner_protocol
as ETH_P_TEB.
Suggested-by: Willem de Bruijn
Signed-off-by: huangxuesen
Signed-off-by: chengzhiyong
Signed-off-by: wangli
---
include/uapi/linux/bpf.h | 5 +
net/core/filter.c | 11 ++-
tools/include/uapi/linux/bpf.h | 5 +
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 77d7c1b..d791596 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
* Use with ENCAP_L3/L4 flags to further specify the tunnel
* type; *len* is the length of the inner MAC header.
*
+ * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
+ * Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
+ * L2 type as Ethernet.
+ *
* A call to this helper is susceptible to change the underlying
* packet buffer. Therefore, at load time, all checks on pointers
* previously done by the verifier are invalidated and must be
@@ -4088,6 +4092,7 @@ enum {
BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
+ BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
};
enum {
diff --git a/net/core/filter.c b/net/core/filter.c
index 255aeee..8d1fb61 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -3412,6 +3412,7 @@ static u32 bpf_skb_net_base_len(const struct sk_buff *skb)
BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
+BPF_F_ADJ_ROOM_ENCAP_L2_ETH | \
BPF_F_ADJ_ROOM_ENCAP_L2( \
BPF_ADJ_ROOM_ENCAP_L2_MASK))
@@ -3448,6 +3449,10 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
off, u32 len_diff,
flags & BPF_F_ADJ_ROOM_ENCAP_L4_UDP)
return -EINVAL;
+ if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH &&
+ inner_mac_len < ETH_HLEN)
+ return -EINVAL;
+
if (skb->encapsulation)
return -EALREADY;
@@ -3466,7 +3471,11 @@ static int bpf_skb_net_grow(struct sk_buff *skb, u32
off, u32 len_diff,
skb->inner_mac_header = inner_net - inner_mac_len;
skb->inner_network_header = inner_net;
skb->inner_transport_header = inner_trans;
- skb_set_inner_protocol(skb, skb->protocol);
+
+ if (flags & BPF_F_ADJ_ROOM_ENCAP_L2_ETH)
+ skb_set_inner_protocol(skb, htons(ETH_P_TEB));
+ else
+ skb_set_inner_protocol(skb, skb->protocol);
skb->encapsulation = 1;
skb_set_network_header(skb, mac_len);
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 77d7c1b..d791596 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1751,6 +1751,10 @@ struct bpf_stack_build_id {
* Use with ENCAP_L3/L4 flags to further specify the tunnel
* type; *len* is the length of the inner MAC header.
*
+ * * **BPF_F_ADJ_ROOM_ENCAP_L2_ETH**:
+ * Use with BPF_F_ADJ_ROOM_ENCAP_L2 flag to further specify the
+ * L2 type as Ethernet.
+ *
* A call to this helper is susceptible to change the underlying
* packet buffer. Therefore, at load time, all checks on pointers
* previously done by the verifier are invalidated and must be
@@ -4088,6 +4092,7 @@ enum {
BPF_F_ADJ_ROOM_ENCAP_L4_GRE = (1ULL << 3),
BPF_F_ADJ_ROOM_ENCAP_L4_UDP = (1ULL << 4),
BPF_F_ADJ_ROOM_NO_CSUM_RESET= (1ULL << 5),
+ BPF_F_ADJ_ROOM_ENCAP_L2_ETH = (1ULL << 6),
};
enum {
--
1.8.3.1
Re: [PATCH V2 4/8] mm/highmem: Add VM_BUG_ON() to mem*_page() calls
On 2/9/21 22:25, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
> memory operations do not result in corrupted data in neighbor pages and
> to make them consistent with zero_user().[1][2]
>
I did not understand this, in my tree :-
zero_user()
-> zero_user_segments()
which uses BUG_ON(), the commit log says add VM_BUG_ON(), isn't that
inconsistent withwhat is there in zero_user_segments() which uses BUG_ON() ?
Also, this patch uses BUG_ON() which doesn't match the commit log that says
ADD VM_BUG_ON(),
Did I interpret the commit log wrong ?
[1]
void zero_user_segments(struct page *page, unsigned start1, unsigned end1,
365 unsigned start2, unsigned end2)
366 {
367 unsigned int
i;
368
369 BUG_ON(end1 > page_size(page) || end2 > page_size(page));
370
371 for (i = 0; i < compound_nr(page); i++) {
372 void *kaddr = NULL;
373
374 if (start1 < PAGE_SIZE || start2 < PAGE_SIZE)
375 kaddr = kmap_atomic(page + i);
376
377 if (start1 >= PAGE_SIZE) {
378 start1 -= PAGE_SIZE;
379 end1 -= PAGE_SIZE;
380 } else {
381 unsigned this_end = min_t(unsigned, end1,
PAGE_SIZE);
382
383 if (end1 > start1)
384 memset(kaddr + start1, 0, this_end -
start1);
385 end1 -= this_end;
386 start1 = 0;
387 }
388
389 if (start2 >= PAGE_SIZE) {
390 start2 -= PAGE_SIZE;
391 end2 -= PAGE_SIZE;
392 } else {
393 unsigned this_end = min_t(unsigned, end2,
PAGE_SIZE);
394
395 if (end2 > start2)
396 memset(kaddr + start2, 0, this_end -
start2);
397 end2 -= this_end;
398 start2 = 0;
399 }
400
401 if (kaddr) {
402 kunmap_atomic(kaddr);
403 flush_dcache_page(page + i);
404 }
405
406 if (!end1 && !end2)
407 break;
408 }
409
410 BUG_ON((start1 | start2 | end1 | end2) != 0);
411 }
412 EXPORT_SYMBOL(zero_user_segments);
[PATCH] mm/hugetlb: use some helper functions to cleanup code
We could use pages_per_huge_page to get the number of pages per hugepage,
use get_hstate_idx to calculate hstate index, and use hstate_is_gigantic
to check if a hstate is gigantic to make code more succinct.
Signed-off-by: Miaohe Lin
---
fs/hugetlbfs/inode.c | 2 +-
mm/hugetlb.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 701c82c36138..c262566f7c5d 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1435,7 +1435,7 @@ static int get_hstate_idx(int page_size_log)
if (!h)
return -1;
- return h - hstates;
+ return hstate_index(h);
}
/*
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8f6c98096476..da347047ea10 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1271,7 +1271,7 @@ static void free_gigantic_page(struct page *page,
unsigned int order)
static struct page *alloc_gigantic_page(struct hstate *h, gfp_t gfp_mask,
int nid, nodemask_t *nodemask)
{
- unsigned long nr_pages = 1UL << huge_page_order(h);
+ unsigned long nr_pages = pages_per_huge_page(h);
if (nid == NUMA_NO_NODE)
nid = numa_mem_id();
@@ -3262,10 +3262,10 @@ static int __init hugepages_setup(char *s)
/*
* Global state is always initialized later in hugetlb_init.
-* But we need to allocate >= MAX_ORDER hstates here early to still
+* But we need to allocate gigantic hstates here early to still
* use the bootmem allocator.
*/
- if (hugetlb_max_hstate && parsed_hstate->order >= MAX_ORDER)
+ if (hugetlb_max_hstate && hstate_is_gigantic(parsed_hstate))
hugetlb_hstate_alloc_pages(parsed_hstate);
last_mhp = mhp;
--
2.19.1
Re: [PATCH 00/20] Rid W=1 warnings in Crypto
On Thu, Feb 04, 2021 at 11:09:40AM +, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > This is set 1 of 2 sets required to fully clean Crypto. > > Lee Jones (20): > crypto: hisilicon: sec_drv: Supply missing description for > 'sec_queue_empty()'s 'queue' param > crypto: bcm: util: Repair a couple of documentation formatting issues > crypto: chelsio: chcr_core: File headers are not good candidates for > kernel-doc > crypto: ux500: hash: hash_core: Fix worthy kernel-doc headers and > remove others > crypto: bcm: spu: Fix formatting and misspelling issues > crypto: keembay: ocs-hcu: Fix incorrectly named functions/structs > crypto: bcm: spu2: Fix a whole host of kernel-doc misdemeanours > crypto: ux500: cryp: Demote some conformant non-kernel headers fix > another > crypto: ux500: cryp_irq: File headers are not good kernel-doc > candidates > crypto: chelsio: chcr_algo: Fix a couple of kernel-doc issues caused > by doc-rot > crypto: ux500: cryp_core: Fix formatting issue and add description for > 'session_id' > crypto: atmel-ecc: Struct headers need to start with keyword 'struct' > crypto: bcm: cipher: Provide description for 'req' and fix formatting > issues > crypto: caam: caampkc: Provide the name of the function > crypto: caam: caamalg_qi2: Supply a couple of 'fallback' related > descriptions > crypto: vmx: Source headers are not good kernel-doc candidates > crypto: nx: nx-aes-cbc: Headers comments should not be kernel-doc > crypto: nx: nx_debugfs: Header comments should not be kernel-doc > crypto: nx: Demote header comment and add description for 'nbytes' > crypto: cavium: nitrox_isr: Demote non-compliant kernel-doc headers Thanks for doing this. But please don't split the patches at the file level. Instead split them at the driver level. For example, all of your bcm changes should be one patch. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC 0/6] Add roundrobin raid1 read policy
On 10/02/2021 04:30, Michal Rostecki wrote: From: Michal Rostecki This patch series adds a new raid1 read policy - roundrobin. For each request, it selects the mirror which has lower load than queue depth. Load is defined as the number of inflight requests + a penalty value (if the scheduled request is not local to the last processed request for a rotational disk). The series consists of preparational changes which add necessary information to the btrfs_device struct and the change with the policy. This policy was tested with fio and compared with the default `pid` policy. The singlethreaded test has the following parameters: [global] name=btrfs-raid1-seqread filename=btrfs-raid1-seqread rw=read bs=64k direct=0 numjobs=1 time_based=0 [file1] size=10G ioengine=libaio and shows the following results: - raid1c3 with 3 HDDs: 3 x Segate Barracuda ST2000DM008 (2TB) * pid policy READ: bw=217MiB/s (228MB/s), 217MiB/s-217MiB/s (228MB/s-228MB/s), io=10.0GiB (10.7GB), run=47082-47082msec * roundrobin policy READ: bw=409MiB/s (429MB/s), 409MiB/s-409MiB/s (429MB/s-429MB/s), io=10.0GiB (10.7GB), run=25028-25028mse - raid1c3 with 2 HDDs and 1 SSD: 2 x Segate Barracuda ST2000DM008 (2TB) 1 x Crucial CT256M550SSD1 (256GB) * pid policy (the worst case when only HDDs were chosen) READ: bw=220MiB/s (231MB/s), 220MiB/s-220MiB/s (231MB/s-231MB/s), io=10.0GiB (10.7GB), run=46577-46577mse * pid policy (the best case when SSD was used as well) READ: bw=513MiB/s (538MB/s), 513MiB/s-513MiB/s (538MB/s-538MB/s), io=10.0GiB (10.7GB), run=19954-19954msec * roundrobin (there are no noticeable differences when testing multiple times) READ: bw=541MiB/s (567MB/s), 541MiB/s-541MiB/s (567MB/s-567MB/s), io=10.0GiB (10.7GB), run=18933-18933msec The multithreaded test has the following parameters: [global] name=btrfs-raid1-seqread filename=btrfs-raid1-seqread rw=read bs=64k direct=0 numjobs=8 time_based=0 [file1] size=10G ioengine=libaio and shows the following results: - raid1c3 with 3 HDDs: 3 x Segate Barracuda ST2000DM008 (2TB) 3 x Segate Barracuda ST2000DM008 (2TB) * pid policy READ: bw=1569MiB/s (1645MB/s), 196MiB/s-196MiB/s (206MB/s-206MB/s), io=80.0GiB (85.9GB), run=52210-52211msec * roundrobin READ: bw=1733MiB/s (1817MB/s), 217MiB/s-217MiB/s (227MB/s-227MB/s), io=80.0GiB (85.9GB), run=47269-47271msec - raid1c3 with 2 HDDs and 1 SSD: 2 x Segate Barracuda ST2000DM008 (2TB) 1 x Crucial CT256M550SSD1 (256GB) * pid policy READ: bw=1843MiB/s (1932MB/s), 230MiB/s-230MiB/s (242MB/s-242MB/s), io=80.0GiB (85.9GB), run=9-44450msec * roundrobin READ: bw=2485MiB/s (2605MB/s), 311MiB/s-311MiB/s (326MB/s-326MB/s), io=80.0GiB (85.9GB), run=32969-32970msec Both of the above test cases are sequential. How about some random IO workload? Also, the seek time for non-rotational devices does not exist. So it is a good idea to test with ssd + nvme and all nvme or all ssd. To measure the performance of each policy and find optimal penalty values, I created scripts which are available here: https://gitlab.com/vadorovsky/btrfs-perf https://github.com/mrostecki/btrfs-perf Michal Rostecki (6): btrfs: Add inflight BIO request counter btrfs: Store the last device I/O offset These patches look good. But as only round-robin policy requires to monitor the inflight and last-offset. Could you bring them under if policy=roundrobin? Otherwise, it is just a waste of CPU cycles if the policy != roundrobin. >btrfs: Add stripe_physical function >btrfs: Check if the filesystem is has mixed type of devices Thanks, Anand btrfs: sysfs: Add directory for read policies btrfs: Add roundrobin raid1 read policy fs/btrfs/ctree.h | 3 + fs/btrfs/disk-io.c | 3 + fs/btrfs/sysfs.c | 144 ++ fs/btrfs/volumes.c | 218 +++-- fs/btrfs/volumes.h | 22 + 5 files changed, 366 insertions(+), 24 deletions(-)
Re: [PATCH v2 16/24] net: stmmac: Use optional reset control API to work with stmmaceth
Hi,
On Mon, 8 Feb 2021 16:56:00 +0300 Serge Semin wrote:
>
> Since commit bb3222f71b57 ("net: stmmac: platform: use optional clk/reset
> get APIs") a manual implementation of the optional device reset control
> functionality has been replaced with using the
> devm_reset_control_get_optional() method. But for some reason the optional
> reset control handler usage hasn't been fixed and preserved the
> NULL-checking statements. There is no need in that in order to perform the
> reset control assertion/deassertion because the passed NULL will be
> considered by the reset framework as absent optional reset control handler
> anyway.
>
> Fixes: bb3222f71b57 ("net: stmmac: platform: use optional clk/reset get APIs")
The patch itself looks good, but the Fix tag isn't necessary since the
patch is a clean up rather than a bug fix. Can you please drop it in next
version?
Thanks
> Signed-off-by: Serge Semin
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 4f1bf8f6538b..a8dec219c295 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -4935,15 +4935,13 @@ int stmmac_dvr_probe(struct device *device,
> if ((phyaddr >= 0) && (phyaddr <= 31))
> priv->plat->phy_addr = phyaddr;
>
> - if (priv->plat->stmmac_rst) {
> - ret = reset_control_assert(priv->plat->stmmac_rst);
> - reset_control_deassert(priv->plat->stmmac_rst);
> - /* Some reset controllers have only reset callback instead of
> -* assert + deassert callbacks pair.
> -*/
> - if (ret == -ENOTSUPP)
> - reset_control_reset(priv->plat->stmmac_rst);
> - }
> + ret = reset_control_assert(priv->plat->stmmac_rst);
> + reset_control_deassert(priv->plat->stmmac_rst);
> + /* Some reset controllers have only reset callback instead of
> +* assert + deassert callbacks pair.
> +*/
> + if (ret == -ENOTSUPP)
> + reset_control_reset(priv->plat->stmmac_rst);
>
> /* Init MAC and get the capabilities */
> ret = stmmac_hw_init(priv);
> @@ -5155,8 +5153,7 @@ int stmmac_dvr_remove(struct device *dev)
> stmmac_exit_fs(ndev);
> #endif
> phylink_destroy(priv->phylink);
> - if (priv->plat->stmmac_rst)
> - reset_control_assert(priv->plat->stmmac_rst);
> + reset_control_assert(priv->plat->stmmac_rst);
> if (priv->hw->pcs != STMMAC_PCS_TBI &&
> priv->hw->pcs != STMMAC_PCS_RTBI)
> stmmac_mdio_unregister(ndev);
> --
> 2.29.2
>
Re: [PATCH V2 3/8] mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page()
On 2/9/21 22:25, ira.we...@intel.com wrote: > From: Ira Weiny > > 3 more common kmap patterns are kmap/memcpy/kunmap, kmap/memmove/kunmap. > and kmap/memset/kunmap. > > Add helper functions for those patterns which use kmap_local_page(). > > Cc: Andrew Morton > Cc: Christoph Hellwig > Signed-off-by: Ira Weiny Looks good. Reviewed-by: Chaitanya Kulkarni
Re: [PATCH] driver core: auxiliary bus: Fix calling stage for auxiliary bus init
On Tue, Feb 09, 2021 at 12:01:06PM -0800, Dan Williams wrote: > On Tue, Feb 9, 2021 at 11:16 AM Greg KH wrote: > [..] > > > diff --git a/drivers/base/auxiliary.c b/drivers/base/auxiliary.c > > > index 8336535f1e11..53f93a506626 100644 > > > --- a/drivers/base/auxiliary.c > > > +++ b/drivers/base/auxiliary.c > > > @@ -270,7 +270,7 @@ static void __exit auxiliary_bus_exit(void) > > > bus_unregister(_bus_type); > > > } > > > > > > -module_init(auxiliary_bus_init); > > > +subsys_initcall(auxiliary_bus_init); > > > > Ah, the linker priority dance. Are you _SURE_ this will solve this? > > All users are module_init() today so it will work today. The > moment someone wants to use it in a built-in driver that uses > subsystem_init() it will ultimately be chased into driver_init(). > > > Why not just call this explicitly in driver_init() so that you know it > > will be ok? Just like we do for the platform bus? > > Cross that bridge when / if it happens? Let's fix it properly now please. thanks, greg k-h
[PATCH] tee: optee: add invoke_fn tracepoints
Add tracepoints to retrieve information about the invoke_fn. This would
help to measure how many invoke_fn are triggered and how long it takes
to complete one invoke_fn call.
Signed-off-by: Jisheng Zhang
---
Since v1:
- add BUILD_BUG_ON() macro usage to make sure that the size of what is being
copied, is not smaller than the amount being copied. Thank Steve.
- move optee_trace.h to keep include headers sorted
drivers/tee/optee/call.c| 4 ++
drivers/tee/optee/optee_trace.h | 67 +
2 files changed, 71 insertions(+)
create mode 100644 drivers/tee/optee/optee_trace.h
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
index 780d7c4fd756..0da6fe50f1af 100644
--- a/drivers/tee/optee/call.c
+++ b/drivers/tee/optee/call.c
@@ -14,6 +14,8 @@
#include
#include "optee_private.h"
#include "optee_smc.h"
+#define CREATE_TRACE_POINTS
+#include "optee_trace.h"
struct optee_call_waiter {
struct list_head list_node;
@@ -138,9 +140,11 @@ u32 optee_do_call_with_arg(struct tee_context *ctx,
phys_addr_t parg)
while (true) {
struct arm_smccc_res res;
+ trace_optee_invoke_fn_begin();
optee->invoke_fn(param.a0, param.a1, param.a2, param.a3,
param.a4, param.a5, param.a6, param.a7,
);
+ trace_optee_invoke_fn_end(, );
if (res.a0 == OPTEE_SMC_RETURN_ETHREAD_LIMIT) {
/*
diff --git a/drivers/tee/optee/optee_trace.h b/drivers/tee/optee/optee_trace.h
new file mode 100644
index ..7c954eefa4bf
--- /dev/null
+++ b/drivers/tee/optee/optee_trace.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * optee trace points
+ *
+ * Copyright (C) 2021 Synaptics Incorporated
+ * Author: Jisheng Zhang
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM optee
+
+#if !defined(_TRACE_OPTEE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_OPTEE_H
+
+#include
+#include
+#include "optee_private.h"
+
+TRACE_EVENT(optee_invoke_fn_begin,
+ TP_PROTO(struct optee_rpc_param *param),
+ TP_ARGS(param),
+
+ TP_STRUCT__entry(
+ __field(void *, param)
+ __array(u32, args, 8)
+ ),
+
+ TP_fast_assign(
+ __entry->param = param;
+ BUILD_BUG_ON(sizeof(*param) < sizeof(__entry->args));
+ memcpy(__entry->args, param, sizeof(__entry->args));
+ ),
+
+ TP_printk("param=%p (%x, %x, %x, %x, %x, %x, %x, %x)", __entry->param,
+ __entry->args[0], __entry->args[1], __entry->args[2],
+ __entry->args[3], __entry->args[4], __entry->args[5],
+ __entry->args[6], __entry->args[7])
+);
+
+TRACE_EVENT(optee_invoke_fn_end,
+ TP_PROTO(struct optee_rpc_param *param, struct arm_smccc_res *res),
+ TP_ARGS(param, res),
+
+ TP_STRUCT__entry(
+ __field(void *, param)
+ __array(unsigned long, rets, 4)
+ ),
+
+ TP_fast_assign(
+ __entry->param = param;
+ BUILD_BUG_ON(sizeof(*res) < sizeof(__entry->rets));
+ memcpy(__entry->rets, res, sizeof(__entry->rets));
+ ),
+
+ TP_printk("param=%p ret (%lx, %lx, %lx, %lx)", __entry->param,
+ __entry->rets[0], __entry->rets[1], __entry->rets[2],
+ __entry->rets[3])
+);
+#endif /* _TRACE_OPTEE_H */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE optee_trace
+
+/* This part must be outside protection */
+#include
--
2.30.0
Re: [PATCH v2] driver core: auxiliary bus: Fix calling stage for auxiliary bus init
On Tue, Feb 09, 2021 at 03:17:00PM -0700, Dave Jiang wrote:
> When the auxiliary device code is built into the kernel, it can be executed
> before the auxiliary bus is registered. This causes bus->p to be not
> allocated and triggers a NULL pointer dereference when the auxiliary bus
> device gets added with bus_add_device(). Call the auxiliary_bus_init()
> under driver_init() so the bus is initialized before devices.
>
> Below is the kernel splat for the bug:
> [ 1.948215] BUG: kernel NULL pointer dereference, address: 0060
> [ 1.950670] #PF: supervisor read access in kernel mode
> [ 1.950670] #PF: error_code(0x) - not-present page
> [ 1.950670] PGD 0
> [ 1.950670] Oops: 1 SMP NOPTI
> [ 1.950670] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 5.10.0-intel-nextsvmtest+ #2205
> [ 1.950670] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> [ 1.950670] RIP: 0010:bus_add_device+0x64/0x140
> [ 1.950670] Code: 00 49 8b 75 20 48 89 df e8 59 a1 ff ff 41 89 c4 85 c0 75 7b
> 48 8b 53 50 48 85 d2 75 03 48 8b 13 49 8b 85 a0 00 00 00 48 89 de <48> 8
> 78 60 48 83 c7 18 e8 ef d9 a9 ff 41 89 c4 85 c0 75 45 48 8b
> [ 1.950670] RSP: :ff46032ac001baf8 EFLAGS: 00010246
> [ 1.950670] RAX: RBX: ff4597f7414aa680 RCX:
> [ 1.950670] RDX: ff4597f74142bbc0 RSI: ff4597f7414aa680 RDI: ff4597f7414aa680
> [ 1.950670] RBP: ff46032ac001bb10 R08: 0044 R09: 0228
> [ 1.950670] R10: ff4597f741141b30 R11: ff4597f740182a90 R12:
> [ 1.950670] R13: a5e936c0 R14: R15:
> [ 1.950670] FS: () GS:ff4597f7bba0()
> knlGS:
> [ 1.950670] CS: 0010 DS: ES: CR0: 80050033
> [ 1.950670] CR2: 0060 CR3: 2140c001 CR4: 00f71ef0
> [ 1.950670] DR0: DR1: DR2:
> [ 1.950670] DR3: DR6: fffe07f0 DR7: 0400
> [ 1.950670] PKRU: 5554
> [ 1.950670] Call Trace:
> [ 1.950670] device_add+0x3ee/0x850
> [ 1.950670] __auxiliary_device_add+0x47/0x60
> [ 1.950670] idxd_pci_probe+0xf77/0x1180
> [ 1.950670] local_pci_probe+0x4a/0x90
> [ 1.950670] pci_device_probe+0xff/0x1b0
> [ 1.950670] really_probe+0x1cf/0x440
> [ 1.950670] ? rdinit_setup+0x31/0x31
> [ 1.950670] driver_probe_device+0xe8/0x150
> [ 1.950670] device_driver_attach+0x58/0x60
> [ 1.950670] __driver_attach+0x8f/0x150
> [ 1.950670] ? device_driver_attach+0x60/0x60
> [ 1.950670] ? device_driver_attach+0x60/0x60
> [ 1.950670] bus_for_each_dev+0x79/0xc0
> [ 1.950670] ? kmem_cache_alloc_trace+0x323/0x430
> [ 1.950670] driver_attach+0x1e/0x20
> [ 1.950670] bus_add_driver+0x154/0x1f0
> [ 1.950670] driver_register+0x70/0xc0
> [ 1.950670] __pci_register_driver+0x54/0x60
> [ 1.950670] idxd_init_module+0xe2/0xfc
> [ 1.950670] ? idma64_platform_driver_init+0x19/0x19
> [ 1.950670] do_one_initcall+0x4a/0x1e0
> [ 1.950670] kernel_init_freeable+0x1fc/0x25c
> [ 1.950670] ? rest_init+0xba/0xba
> [ 1.950670] kernel_init+0xe/0x116
> [ 1.950670] ret_from_fork+0x1f/0x30
> [ 1.950670] Modules linked in:
> [ 1.950670] CR2: 0060
> [ 1.950670] --[ end trace cd7d1b226d3ca901 ]--
>
> Fixes: 7de3697e9cbd ("Add auxiliary bus support")
> Reported-by: Jacob Pan
> Acked-by: Dave Ertman
> Reviewed-by: Dan Williams
> Signed-off-by: Dave Jiang
> ---
>
> v2:
> - Call in driver_init() to ensure aux bus gets init before devices. (GregKH)
>
> drivers/base/auxiliary.c | 10 +-
> drivers/base/base.h |5 +
> drivers/base/init.c |1 +
> 3 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/base/auxiliary.c b/drivers/base/auxiliary.c
> index 8336535f1e11..8ff389653126 100644
> --- a/drivers/base/auxiliary.c
> +++ b/drivers/base/auxiliary.c
> @@ -260,19 +260,11 @@ void auxiliary_driver_unregister(struct
> auxiliary_driver *auxdrv)
> }
> EXPORT_SYMBOL_GPL(auxiliary_driver_unregister);
>
> -static int __init auxiliary_bus_init(void)
> +int __init auxiliary_bus_init(void)
> {
> return bus_register(_bus_type);
Ok, you return an int, and then...
> }
>
> -static void __exit auxiliary_bus_exit(void)
> -{
> - bus_unregister(_bus_type);
> -}
> -
> -module_init(auxiliary_bus_init);
> -module_exit(auxiliary_bus_exit);
> -
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("Auxiliary Bus");
> MODULE_AUTHOR("David Ertman ");
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index f5600a83124f..978ad265c42e 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -119,6 +119,11 @@ static inline int hypervisor_init(void) { return 0; }
> extern int platform_bus_init(void);
> extern void cpu_dev_init(void);
> extern void container_dev_init(void);
> +#ifdef CONFIG_AUXILIARY_BUS
> +extern int auxiliary_bus_init(void);
> +#else
> +static inline int auxiliary_bus_init(void) { return 0; }
[PATCH 2/3] Revert "ASoC: audio-graph-card: Add clocks property to endpoint node"
An endpoint is not a device and it is recommended to use clocks property
in the device node. Hence reverting the original change.
Fixes: 531e5b7abbde ("ASoC: audio-graph-card: Add clocks property to endpoint
node")
Suggested-by: Rob Herring
Cc: Kuninori Morimoto
Signed-off-by: Sameer Pujar
---
Documentation/devicetree/bindings/sound/audio-graph-port.yaml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
index 08ed8f5..766e910 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
+++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml
@@ -33,9 +33,6 @@ properties:
properties:
remote-endpoint:
maxItems: 1
- clocks:
-maxItems: 1
-description: Describes the clock used by audio component.
mclk-fs:
description: |
Multiplication factor between stream rate and codec mclk.
--
2.7.4
[PATCH 3/3] arm64: tegra: Move clocks from RT5658 endpoint to device node
An endpoint is not a device and it is recommended to use clocks property
in device node. RT5658 Codec binding already specifies the usage of
clocks property. Thus move the clocks from endpoint to device node.
Fixes: 5b4f6323096a ("arm64: tegra: Audio graph sound card for Jetson AGX
Xavier")
Suggested-by: Rob Herring
Signed-off-by: Sameer Pujar
---
arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
index b079420..ef41349e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
@@ -651,6 +651,7 @@
reg = <0x1a>;
interrupt-parent = <>;
interrupts = ;
+ clocks = < TEGRA194_CLK_AUD_MCLK>;
realtek,jd-src = <2>;
sound-name-prefix = "CVB-RT";
@@ -658,7 +659,6 @@
rt5658_ep: endpoint {
remote-endpoint =
<_dap_ep>;
mclk-fs = <256>;
- clocks = <
TEGRA194_CLK_AUD_MCLK>;
};
};
};
--
2.7.4
[PATCH 0/3] Use clocks property in a device node
It is recommended to not specifiy clocks property in an endpoint subnode. This series moves clocks to device node. However after moving the clocks to device node, the audio playback or capture fails. The specified clock is not actually getting enabled and hence the failure is seen. There seems to be a bug in simple-card-utils.c where clock handle is not assigned when parsing clocks from device node. Fix the same and revert original change which actually added clocks property in endpoint subnode. Also update Jetson AGX Xavier DT where the usage is found. Sameer Pujar (3): ASoC: simple-card-utils: Fix device module clock Revert "ASoC: audio-graph-card: Add clocks property to endpoint node" arm64: tegra: Move clocks from RT5658 endpoint to device node .../devicetree/bindings/sound/audio-graph-port.yaml | 3 --- arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 2 +- sound/soc/generic/simple-card-utils.c | 13 ++--- 3 files changed, 7 insertions(+), 11 deletions(-) -- 2.7.4
[PATCH 1/3] ASoC: simple-card-utils: Fix device module clock
If "clocks = <>" is specified from the CPU or Codec component
device node, the clock is not getting enabled. Thus audio playback
or capture fails.
Fix this by populating "simple_dai->clk" field when clocks property
is specified from device node as well. Also tidy up by re-organising
conditional statements of parsing logic.
Fixes: bb6fc620c2ed ("ASoC: simple-card-utils: add
asoc_simple_card_parse_clk()")
Cc: Kuninori Morimoto
Signed-off-by: Sameer Pujar
---
sound/soc/generic/simple-card-utils.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/sound/soc/generic/simple-card-utils.c
b/sound/soc/generic/simple-card-utils.c
index bc0b62e..0754d70 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -173,16 +173,15 @@ int asoc_simple_parse_clk(struct device *dev,
* or device's module clock.
*/
clk = devm_get_clk_from_child(dev, node, NULL);
- if (!IS_ERR(clk)) {
- simple_dai->sysclk = clk_get_rate(clk);
+ if (IS_ERR(clk))
+ clk = devm_get_clk_from_child(dev, dlc->of_node, NULL);
+ if (!IS_ERR(clk)) {
simple_dai->clk = clk;
- } else if (!of_property_read_u32(node, "system-clock-frequency", ))
{
+ simple_dai->sysclk = clk_get_rate(clk);
+ } else if (!of_property_read_u32(node, "system-clock-frequency",
+)) {
simple_dai->sysclk = val;
- } else {
- clk = devm_get_clk_from_child(dev, dlc->of_node, NULL);
- if (!IS_ERR(clk))
- simple_dai->sysclk = clk_get_rate(clk);
}
if (of_property_read_bool(node, "system-clock-direction-out"))
--
2.7.4
Re: [PATCH v2 3/3] crypto: hisilicon/sec - fixes shash test error
On Sun, Feb 07, 2021 at 06:04:40PM +0800, Longfang Liu wrote: > If the header file "crypto/internal/hash.h" not > added, the allocation of crypto_tfm will fail when > the shash algorithm calculates the hash > through the software. > > Signed-off-by: Longfang Liu > --- > drivers/crypto/hisilicon/sec2/sec_crypto.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c > b/drivers/crypto/hisilicon/sec2/sec_crypto.c > index d2c4a2c..988faf7 100644 > --- a/drivers/crypto/hisilicon/sec2/sec_crypto.c > +++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c > @@ -7,6 +7,7 @@ > #include > #include > #include > +#include Please explain what exactly in this file needs this header file. As it stands you could just be hiding real bugs. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] mm: cma: support sysfs
On Tue, Feb 09, 2021 at 01:13:17PM -0800, Minchan Kim wrote:
> On Tue, Feb 09, 2021 at 12:11:20PM -0800, John Hubbard wrote:
> > On 2/9/21 9:49 AM, Greg KH wrote:
> > > > > That's fine if you want to add it to the parent. If so, then the
> > > > > kobject controls the lifetime of the structure, nothing else can.
> > > >
> > > > The problem was parent object(i.e., struct cma cma_areas) is
> > > > static arrary so kobj->release function will be NULL or just
> > > > dummy. Is it okay? I thought it was one of the what you wanted
> > > > to avoid it.
> > >
> > > No, that is not ok.
> > >
> > > > > Either is fine with me, what is "forbidden" is having a kobject and
> > > > > somehow thinking that it does not control the lifetime of the
> > > > > structure.
> > > >
> > > > Since parent object is static arrary, there is no need to control the
> > > > lifetime so I am curious if parent object approach is okay from kobject
> > > > handling point of view.
> > >
> > > So the array is _NEVER_ freed? If not, fine, don't provide a release
> > > function for the kobject, but ick, just make a dynamic kobject I don't
> > > see the problem for something so tiny and not very many...
> > >
> >
> > Yeah, I wasn't trying to generate so much discussion, I initially thought it
> > would be a minor comment: "just use an embedded struct and avoid some extra
> > code", at first.
> >
> > > I worry that any static kobject might be copied/pasted as someone might
> > > think this is an ok thing to do. And it's not an ok thing to do.
> > >
> >
> > Overall, then, we're seeing that there is a small design hole: in order
> > to use sysfs most naturally, you either much provide a dynamically allocated
> > item for it, or you must use the static kobject, and the second one sets a
> > bad example.
> >
> > I think we should just use a static kobject, with a cautionary comment to
> > would-be copy-pasters, that explains the design constraints above. That way,
> > we still get a nice, less-code implementation, a safe design, and it only
> > really costs us a single carefully written comment.
> >
> > thanks,
>
> Agreed. How about this for the warning part?
>
> +
> +/*
> + * note: kobj_type should provide a release function to free dynamically
> + * allocated object since kobject is responsible for controlling lifespan
> + * of the object. However, cma_area is static object so technially, it
> + * doesn't need release function. It's very exceptional case so pleaes
> + * do not follow this model.
> + */
> static struct kobj_type cma_ktype = {
> .sysfs_ops = _sysfs_ops,
> .default_groups = cma_groups
> + .release = NULL, /* do not follow. See above */
> };
>
No, please no. Just do it the correct way, what is the objection to
creating a few dynamic kobjects from the heap? How many of these are
you going to have that it will somehow be "wasteful"?
Please do it properly.
thanks,
greg k-h
Re: [PATCH v2 6/7] ASoC: codec: lpass-tx-macro: add support for lpass tx macro
Hi Srinivas,
I love your patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v5.11-rc7 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/ASoC-codecs-add-support-for-LPASS-Codec-TX-and-RX-macros/20210209-084643
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
config: ia64-randconfig-r013-20210209 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/4d44cfba08462d518a10d9d335287b19c2cbff02
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Srinivas-Kandagatla/ASoC-codecs-add-support-for-LPASS-Codec-TX-and-RX-macros/20210209-084643
git checkout 4d44cfba08462d518a10d9d335287b19c2cbff02
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
sound/soc/codecs/lpass-tx-macro.c: In function
'tx_macro_tx_hpf_corner_freq_callback':
>> sound/soc/codecs/lpass-tx-macro.c:656:15: warning: variable 'adc_n' set but
>> not used [-Wunused-but-set-variable]
656 | u16 adc_reg, adc_n;
| ^
vim +/adc_n +656 sound/soc/codecs/lpass-tx-macro.c
647
648 static void tx_macro_tx_hpf_corner_freq_callback(struct work_struct
*work)
649 {
650 struct delayed_work *hpf_delayed_work;
651 struct hpf_work *hpf_work;
652 struct tx_macro *tx;
653 struct snd_soc_component *component;
654 u16 dec_cfg_reg, hpf_gate_reg;
655 u8 hpf_cut_off_freq;
> 656 u16 adc_reg, adc_n;
657
658 hpf_delayed_work = to_delayed_work(work);
659 hpf_work = container_of(hpf_delayed_work, struct hpf_work,
dwork);
660 tx = hpf_work->tx;
661 component = tx->component;
662 hpf_cut_off_freq = hpf_work->hpf_cut_off_freq;
663
664 dec_cfg_reg = CDC_TXn_TX_PATH_CFG0(hpf_work->decimator);
665 hpf_gate_reg = CDC_TXn_TX_PATH_SEC2(hpf_work->decimator);
666
667 if (is_amic_enabled(component, hpf_work->decimator)) {
668 adc_reg =
CDC_TX_INP_MUX_ADC_MUXn_CFG0(hpf_work->decimator);
669 adc_n = snd_soc_component_read(component, adc_reg) &
670 CDC_TX_MACRO_SWR_MIC_MUX_SEL_MASK;
671 /* analog mic clear TX hold */
672 snd_soc_component_write_field(component,
673 dec_cfg_reg,
674 CDC_TXn_HPF_CUT_FREQ_MASK,
675 hpf_cut_off_freq);
676 snd_soc_component_update_bits(component, hpf_gate_reg,
677CDC_TXn_HPF_F_CHANGE_MASK
|
678
CDC_TXn_HPF_ZERO_GATE_MASK,
6790x02);
680 snd_soc_component_update_bits(component, hpf_gate_reg,
681CDC_TXn_HPF_F_CHANGE_MASK
|
682
CDC_TXn_HPF_ZERO_GATE_MASK,
6830x01);
684 } else {
685 snd_soc_component_write_field(component, dec_cfg_reg,
686CDC_TXn_HPF_CUT_FREQ_MASK,
687hpf_cut_off_freq);
688 snd_soc_component_write_field(component, hpf_gate_reg,
689
CDC_TXn_HPF_F_CHANGE_MASK, 0x1);
690 /* Minimum 1 clk cycle delay is required as per HW spec
*/
691 usleep_range(1000, 1010);
692 snd_soc_component_write_field(component, hpf_gate_reg,
693
CDC_TXn_HPF_F_CHANGE_MASK, 0x0);
694 }
695 }
696
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH V2 2/8] mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page()
On 2/9/21 22:25, ira.we...@intel.com wrote: > From: Ira Weiny > > kmap_local_page() is more efficient and is well suited for these calls. > Convert the kmap() to kmap_local_page() > > Cc: Andrew Morton > Cc: Christoph Hellwig > Signed-off-by: Ira Weiny Looks good. Reviewed-by: Chaitanya Kulkarni
Re: [PATCH v2 2/7] ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg
On Wed, Feb 10, 2021 at 6:30 AM Mark Brown wrote: > > On Tue, Feb 09, 2021 at 05:16:16PM +0800, Shengjiu Wang wrote: > > On Mon, Feb 8, 2021 at 7:53 PM Mark Brown wrote: > > > > hw_params() can be called multiple times and there's no need for it to > > > be balanced with hw_free(), I'd move this to a different callback (DAPM > > > should work well). > > > Which callback should I use? Is there an example? > > Like I say I'd actually recommend moving this control to DAPM. I may understand your point, you suggest to use the .set_bias_level interface. But in my case I need to enable the clock in earlier stage and keep the clock on when system go to suspend. I am not sure .set_bias_level can met my requirement. we start the Chinese new year holiday now, so currently I can't do test for this recommendation. Maybe we can keep current implementation, can we? Later after I do the test, I can submit another patch for it. Best regards Wang Shengjiu
Re: [kbuild-all] Re: [PATCH v12 7/7] kasan: don't run tests in async mode
On 2/9/21 7:33 PM, Vincenzo Frascino wrote: On 2/9/21 6:32 AM, kernel test robot wrote: Hi Vincenzo, I love your patch! Yet something to improve: [auto build test ERROR on next-20210125] [cannot apply to arm64/for-next/core xlnx/master arm/for-next soc/for-next kvmarm/next linus/master hnaz-linux-mm/master v5.11-rc6 v5.11-rc5 v5.11-rc4 v5.11-rc6] The patches are based on linux-next/akpm and since they depend on some patches present on that tree, can be applied only on linux-next/akpm and linux-next/master. The dependency is reported in the cover letter. Hi Vincenzo, Thanks for the feedback, we'll take a look. Best Regards, Rong Chen Thanks, Vincenzo [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 base:59fa6a163ffabc1bf25c5e0e33899e268a96d3cc config: powerpc64-randconfig-r033-20210209 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/53907a0b15724b414ddd9201356f92e09571ef90 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Vincenzo-Frascino/arm64-ARMv8-5-A-MTE-Add-async-mode-support/20210209-080907 git checkout 53907a0b15724b414ddd9201356f92e09571ef90 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): powerpc-linux-ld: lib/test_kasan.o: in function `kasan_test_init': test_kasan.c:(.text+0x849a): undefined reference to `kasan_flag_async' powerpc-linux-ld: test_kasan.c:(.text+0x84a2): undefined reference to `kasan_flag_async' powerpc-linux-ld: test_kasan.c:(.text+0x84e2): undefined reference to `kasan_flag_async' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH V2 1/8] mm/highmem: Lift memcpy_[to|from]_page to core
On 2/9/21 22:25, ira.we...@intel.com wrote: > From: Ira Weiny > > Working through a conversion to a call kmap_local_page() instead of > kmap() revealed many places where the pattern kmap/memcpy/kunmap > occurred. > > Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al > Viro all suggested putting this code into helper functions. Al Viro > further pointed out that these functions already existed in the iov_iter > code.[1] > > Various locations for the lifted functions were considered. > > Headers like mm.h or string.h seem ok but don't really portray the > functionality well. pagemap.h made some sense but is for page cache > functionality.[2] > > Another alternative would be to create a new header for the promoted > memcpy functions, but it masks the fact that these are designed to copy > to/from pages using the kernel direct mappings and complicates matters > with a new header. > > Placing these functions in 'highmem.h' is suboptimal especially with the > changes being proposed in the functionality of kmap. From a caller > perspective including/using 'highmem.h' implies that the functions > defined in that header are only required when highmem is in use which is > increasingly not the case with modern processors. However, highmem.h is > where all the current functions like this reside (zero_user(), > clear_highpage(), clear_user_highpage(), copy_user_highpage(), and > copy_highpage()). So it makes the most sense even though it is > distasteful for some.[3] > > Lift memcpy_to_page() and memcpy_from_page() to pagemap.h. > > [1] https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/ > https://lore.kernel.org/lkml/20201013112544.ga5...@infradead.org/ > > [2] https://lore.kernel.org/lkml/20201208122316.gh7...@casper.infradead.org/ > > [3] > https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/#t > > https://lore.kernel.org/lkml/20201208163814.gn1563...@iweiny-desk2.sc.intel.com/ > > Cc: Boris Pismenny > Cc: Or Gerlitz > Cc: Dave Hansen > Suggested-by: Matthew Wilcox > Suggested-by: Christoph Hellwig > Suggested-by: Dan Williams > Suggested-by: Al Viro > Suggested-by: Eric Biggers > Signed-off-by: Ira Weiny Thanks for adding a new line in the new calls after variable declaration. Looks good. Reviewed-by: Chaitanya Kulkarni
Re: [PATCH v3] printk: fix deadlock when kernel panic
On (21/02/10 11:48), Muchun Song wrote:
> printk_safe_flush_on_panic() caused the following deadlock on our
> server:
>
> CPU0: CPU1:
> panic rcu_dump_cpu_stacks
> kdump_nmi_shootdown_cpus nmi_trigger_cpumask_backtrace
> register_nmi_handler(crash_nmi_callback) printk_safe_flush
> __printk_safe_flush
>
> raw_spin_lock_irqsave(_lock)
> // send NMI to other processors
> apic_send_IPI_allbutself(NMI_VECTOR)
> // NMI interrupt,
> dead loop
> crash_nmi_callback
> printk_safe_flush_on_panic
> printk_safe_flush
> __printk_safe_flush
> // deadlock
> raw_spin_lock_irqsave(_lock)
>
> DEADLOCK: read_lock is taken on CPU1 and will never get released.
>
> It happens when panic() stops a CPU by NMI while it has been in
> the middle of printk_safe_flush().
>
> Handle the lock the same way as logbuf_lock. The printk_safe buffers
> are flushed only when both locks can be safely taken. It can avoid
> the deadlock _in this particular case_ at expense of losing contents
> of printk_safe buffers.
>
> Note: It would actually be safe to re-init the locks when all CPUs were
> stopped by NMI. But it would require passing this information
> from arch-specific code. It is not worth the complexity.
> Especially because logbuf_lock and printk_safe buffers have been
> obsoleted by the lockless ring buffer.
>
> Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic")
> Signed-off-by: Muchun Song
> Reviewed-by: Petr Mladek
> Cc:
Acked-by: Sergey Senozhatsky
-ss
Re: [GIT PULL] memblock: remove return value of memblock_free_all()
On Tue, Feb 09, 2021 at 05:17:30PM -0800, Linus Torvalds wrote: > On Tue, Feb 9, 2021 at 1:43 AM Mike Rapoport wrote: > > > > This a small cleanup in memblock for 5.12 merge window. > > If it's going to make Andrew's patches easier to apply during the 5.12 > timeframe, I'm happy to pull this early. > > Yes/No? No -- Sincerely yours, Mike.
Re: [PATCH Resend] mailbox: arm_mhuv2: Fix sparse warnings
On 10-02-21, 00:25, Jassi Brar wrote: > Yup any bug fix should be sent in rc. But this, imo, lies on the > boundary of code and cosmetic issues, so I practiced discretion to > keep it for the next pull request lest I won't have much to send ;) Fair enough, would have been better though if you could have replied with this earlier. I had no clue on what's going on until this email came from you :) Thanks anyway. -- viresh
[PATCH v2] perf probe: fix kretprobe issue caused by GCC bug
Perf failed to add kretprobe event with debuginfo of vmlinux which is
compiled by gcc with -fpatchable-function-entry option enabled.
The same issue with kernel module.
Issue:
# perf probe -v 'kernel_clone%return $retval'
..
Writing event: r:probe/kernel_clone__return _text+599624 $retval
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Invalid argument (Code: -22)
# cat /sys/kernel/debug/tracing/error_log
[156.75] trace_kprobe: error: Retprobe address must be an function entry
Command: r:probe/kernel_clone__return _text+599624 $retval
^
# llvm-dwarfdump vmlinux |grep -A 10 -w 0x00df2c2b
0x00df2c2b: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("kernel_clone")
DW_AT_decl_file ("/home/code/linux-next/kernel/fork.c")
DW_AT_decl_line (2423)
DW_AT_decl_column (0x07)
DW_AT_prototyped(true)
DW_AT_type (0x00dcd492 "pid_t")
DW_AT_low_pc(0x800010092648)
DW_AT_high_pc (0x800010092b9c)
DW_AT_frame_base(DW_OP_call_frame_cfa)
# cat /proc/kallsyms |grep kernel_clone
800010092640 T kernel_clone
# readelf -s vmlinux |grep -i kernel_clone
183173: 800010092640 1372 FUNCGLOBAL DEFAULT2 kernel_clone
# objdump -d vmlinux |grep -A 10 -w \:
800010092640 :
800010092640: d503201fnop
800010092644: d503201fnop
800010092648: d503233fpaciasp
80001009264c: a9b87bfdstp x29, x30, [sp, #-128]!
800010092650: 910003fdmov x29, sp
800010092654: a90153f3stp x19, x20, [sp, #16]
The entry address of kernel_clone converted by debuginfo is _text+599624
(0x92648), which is consistent with the value of DW_AT_low_pc attribute.
But the symbolic address of kernel_clone from /proc/kallsyms is
800010092640.
This issue is found on arm64, -fpatchable-function-entry=2 is enabled when
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y;
Just as objdump displayed the assembler contents of kernel_clone,
GCC generate 2 NOPs at the beginning of each function.
kprobe_on_func_entry detects that (_text+599624) is not the entry address
of the function, which leads to the failure of adding kretprobe event.
---
kprobe_on_func_entry
->_kprobe_addr
->kallsyms_lookup_size_offset
->arch_kprobe_on_func_entry // FALSE
---
The cause of the issue is that the first instruction in the compile unit
indicated by DW_AT_low_pc does not include NOPs.
This issue exists in all gcc versions that support
-fpatchable-function-entry option.
I have reported it to the GCC community:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776
Currently arm64 and PA-RISC may enable fpatchable-function-entry option.
The kernel compiled with clang does not have this issue.
FIX:
This GCC issue only cause the registration failure of the kretprobe event
which doesn't need debuginfo. So, stop using debuginfo for retprobe.
map will be used to query the probe function address.
Signed-off-by: Jianlin Lv
---
v2: stop using debuginfo for retprobe, and update changelog.
---
tools/perf/util/probe-event.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 8eae2afff71a..a59d3268adb0 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -894,6 +894,16 @@ static int try_to_find_probe_trace_events(struct
perf_probe_event *pev,
struct debuginfo *dinfo;
int ntevs, ret = 0;
+ /* Workaround for gcc #98776 issue.
+* Perf failed to add kretprobe event with debuginfo of vmlinux which is
+* compiled by gcc with -fpatchable-function-entry option enabled. The
+* same issue with kernel module. The retprobe doesn`t need debuginfo.
+* This workaround solution use map to query the probe function address
+* for retprobe event.
+*/
+ if (pev->point.retprobe)
+ return 0;
+
dinfo = open_debuginfo(pev->target, pev->nsi, !need_dwarf);
if (!dinfo) {
if (need_dwarf)
--
2.25.1
Re: [PATCH] crypto: picoxcell - convert sysfs sprintf/snprintf family to sysfs_emit
On Thu, Feb 04, 2021 at 03:24:13PM +0800, Jiapeng Chong wrote: > Fix the following coccicheck warning: > > ./drivers/crypto/picoxcell_crypto.c:1201:8-16: WARNING: use scnprintf > or sprintf. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/crypto/picoxcell_crypto.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This driver no longer exists. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RESEND PATCH v18 0/3] userspace MHI client interface driver
On Tue, Feb 09, 2021 at 08:17:44AM -0800, Jakub Kicinski wrote: > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > This may be a stupid suggestion, but would the integration look less a > > backdoor if it would have been named "mhi_wwan" and it exposed already > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > QMI? > > What's DIAG? Who's going to remember that this is a backdoor driver > a year from now when Qualcomm sends a one liner patches which just > adds a single ID to open another channel? I really appreciate your feedback on this driver eventhough I'm not inclined with you calling this driver a "backdoor interface". But can you please propose a solution on how to make this driver a good one as per your thoughts? I really don't know what bothers you even if the userspace tools making use of these chardevs are available openly (you can do the audit and see if anything wrong we are doing). And exposing the raw access to the hardware is not a new thing in kernel. There are several existing subsystems/drivers does this as pointed out by Bjorn. Moreover we don't have in-kernel APIs for the functionalities exposed by this driver and creating one is not feasible as explained by many. So please let us know the path forward on this series. We are open to any suggestions but you haven't provided one till now. Thanks, Mani
Re: [PATCH Resend] mailbox: arm_mhuv2: Fix sparse warnings
On Tue, Feb 9, 2021 at 5:18 AM Viresh Kumar wrote: > > This patch fixes a bunch of sparse warnings in the newly added arm_mhuv2 > driver. > > drivers/mailbox/arm_mhuv2.c:506:24: warning: incorrect type in argument 1 > (different address spaces) > drivers/mailbox/arm_mhuv2.c:506:24:expected void const volatile [noderef] > __iomem *addr > drivers/mailbox/arm_mhuv2.c:506:24:got unsigned int [usertype] * > drivers/mailbox/arm_mhuv2.c:547:42: warning: incorrect type in argument 2 > (different address spaces) > drivers/mailbox/arm_mhuv2.c:547:42:expected unsigned int [usertype] *reg > drivers/mailbox/arm_mhuv2.c:547:42:got unsigned int [noderef] __iomem * > drivers/mailbox/arm_mhuv2.c:625:42: warning: incorrect type in argument 2 > (different address spaces) > drivers/mailbox/arm_mhuv2.c:625:42:expected unsigned int [usertype] *reg > drivers/mailbox/arm_mhuv2.c:625:42:got unsigned int [noderef] __iomem * > drivers/mailbox/arm_mhuv2.c:972:24: warning: dereference of noderef expression > drivers/mailbox/arm_mhuv2.c:973:22: warning: dereference of noderef expression > drivers/mailbox/arm_mhuv2.c:993:25: warning: dereference of noderef expression > drivers/mailbox/arm_mhuv2.c:1026:24: warning: dereference of noderef > expression > drivers/mailbox/arm_mhuv2.c:1027:22: warning: dereference of noderef > expression > drivers/mailbox/arm_mhuv2.c:1048:17: warning: dereference of noderef > expression > > Reported-by: kernel test robot > Signed-off-by: Viresh Kumar > --- > Hi, > > This should have been merged to 5.11-rc since the driver got introduced > in 5.11-rc1 itself. I don't see it queued for linux-next as well. It was > posted over 6 weeks back and no response is received yet: > Yup any bug fix should be sent in rc. But this, imo, lies on the boundary of code and cosmetic issues, so I practiced discretion to keep it for the next pull request lest I won't have much to send ;) > https://lore.kernel.org/lkml/db5dd593cfd8b428ce44c1cce7484d887fa5e67c.1609303304.git.viresh.ku...@linaro.org/ > > Would be good if this can still go in 5.11. > Of course it will. thanks.
[PATCH V2 6/8] btrfs: use memcpy_[to|from]_page() and kmap_local_page()
From: Ira Weiny There are many places where the pattern kmap/memcpy/kunmap occurs. This pattern was lifted to the core common functions memcpy_[to|from]_page(). Use these new functions to reduce the code, eliminate direct uses of kmap, and leverage the new core functions use of kmap_local_page(). Also, there is 1 place where a kmap/memcpy is followed by an optional memset. Here we leave the kmap open coded to avoid remapping the page but use kmap_local_page() directly. Development of this patch was aided by the coccinelle script: // // SPDX-License-Identifier: GPL-2.0-only // Find kmap/memcpy/kunmap pattern and replace with memcpy*page calls // // NOTE: Offsets and other expressions may be more complex than what the script // will automatically generate. Therefore a catchall rule is provided to find // the pattern which then must be evaluated by hand. // // Confidence: Low // Copyright: (C) 2021 Intel Corporation // URL: http://coccinelle.lip6.fr/ // Comments: // Options: // // simple memcpy version // @ memcpy_rule1 @ expression page, T, F, B, Off; identifier ptr; type VP; @@ ( -VP ptr = kmap(page); | -ptr = kmap(page); | -VP ptr = kmap_atomic(page); | -ptr = kmap_atomic(page); ) <+... ( -memcpy(ptr + Off, F, B); +memcpy_to_page(page, Off, F, B); | -memcpy(ptr, F, B); +memcpy_to_page(page, 0, F, B); | -memcpy(T, ptr + Off, B); +memcpy_from_page(T, page, Off, B); | -memcpy(T, ptr, B); +memcpy_from_page(T, page, 0, B); ) ...+> ( -kunmap(page); | -kunmap_atomic(ptr); ) // Remove any pointers left unused @ depends on memcpy_rule1 @ identifier memcpy_rule1.ptr; type VP, VP1; @@ -VP ptr; ... when != ptr; ? VP1 ptr; // // Some callers kmap without a temp pointer // @ memcpy_rule2 @ expression page, T, Off, F, B; @@ <+... ( -memcpy(kmap(page) + Off, F, B); +memcpy_to_page(page, Off, F, B); | -memcpy(kmap(page), F, B); +memcpy_to_page(page, 0, F, B); | -memcpy(T, kmap(page) + Off, B); +memcpy_from_page(T, page, Off, B); | -memcpy(T, kmap(page), B); +memcpy_from_page(T, page, 0, B); ) ...+> -kunmap(page); // No need for the ptr variable removal // // Catch all // @ memcpy_rule3 @ expression page; expression GenTo, GenFrom, GenSize; identifier ptr; type VP; @@ ( -VP ptr = kmap(page); | -ptr = kmap(page); | -VP ptr = kmap_atomic(page); | -ptr = kmap_atomic(page); ) <+... ( // // Some call sites have complex expressions within the memcpy // match a catch all to be evaluated by hand. // -memcpy(GenTo, GenFrom, GenSize); +memcpy_to_pageExtra(page, GenTo, GenFrom, GenSize); +memcpy_from_pageExtra(GenTo, page, GenFrom, GenSize); ) ...+> ( -kunmap(page); | -kunmap_atomic(ptr); ) // Remove any pointers left unused @ depends on memcpy_rule3 @ identifier memcpy_rule3.ptr; type VP, VP1; @@ -VP ptr; ... when != ptr; ? VP1 ptr; // Signed-off-by: Ira Weiny --- Changes from v1: Update commit message per David https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/ --- fs/btrfs/compression.c | 6 ++ fs/btrfs/lzo.c | 4 ++-- fs/btrfs/reflink.c | 6 +- fs/btrfs/send.c| 7 ++- fs/btrfs/zlib.c| 5 ++--- fs/btrfs/zstd.c| 6 ++ 6 files changed, 11 insertions(+), 23 deletions(-) diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c index 5ae3fa0386b7..047b632b4139 100644 --- a/fs/btrfs/compression.c +++ b/fs/btrfs/compression.c @@ -1231,7 +1231,6 @@ int btrfs_decompress_buf2page(const char *buf, unsigned long buf_start, unsigned long prev_start_byte; unsigned long working_bytes = total_out - buf_start; unsigned long bytes; - char *kaddr; struct bio_vec bvec = bio_iter_iovec(bio, bio->bi_iter); /* @@ -1262,9 +1261,8 @@ int btrfs_decompress_buf2page(const char *buf, unsigned long buf_start, PAGE_SIZE - (buf_offset % PAGE_SIZE)); bytes = min(bytes, working_bytes); - kaddr = kmap_atomic(bvec.bv_page); - memcpy(kaddr + bvec.bv_offset, buf + buf_offset, bytes); - kunmap_atomic(kaddr); + memcpy_to_page(bvec.bv_page, bvec.bv_offset, buf + buf_offset, + bytes); flush_dcache_page(bvec.bv_page); buf_offset += bytes; diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c index aa9cd11f4b78..9084a950dc09 100644 --- a/fs/btrfs/lzo.c +++ b/fs/btrfs/lzo.c @@ -467,7 +467,7 @@ int lzo_decompress(struct list_head *ws, unsigned char *data_in, destlen = min_t(unsigned long, destlen, PAGE_SIZE); bytes = min_t(unsigned long, destlen, out_len - start_byte); - kaddr = kmap_atomic(dest_page); + kaddr = kmap_local_page(dest_page); memcpy(kaddr, workspace->buf + start_byte, bytes); /* @@ -477,7 +477,7 @@ int lzo_decompress(struct list_head *ws, unsigned char *data_in, */ if (bytes < destlen) memset(kaddr+bytes, 0, destlen-bytes); -
[PATCH V2 7/8] btrfs: use copy_highpage() instead of 2 kmaps()
From: Ira Weiny
There are many places where kmap/memove/kunmap patterns occur.
This pattern exists in the core common function copy_highpage().
Use copy_highpage to avoid open coding the use of kmap and leverages the
core functions use of kmap_local_page().
Development of this patch was aided by the following coccinelle script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/copypage/kunmap pattern and replace with copy_highpage calls
//
// NOTE: The expressions in the copy page version of this kmap pattern are
// overly complex and so these all need individual attention.
//
// Confidence: Low
// Copyright: (C) 2021 Intel Corporation
// URL: http://coccinelle.lip6.fr/
// Comments:
// Options:
//
// Then a copy_page where we have 2 pages involved.
//
@ copy_page_rule @
expression page, page2, To, From, Size;
identifier ptr, ptr2;
type VP, VP2;
@@
/* kmap */
(
-VP ptr = kmap(page);
...
-VP2 ptr2 = kmap(page2);
|
-VP ptr = kmap_atomic(page);
...
-VP2 ptr2 = kmap_atomic(page2);
|
-ptr = kmap(page);
...
-ptr2 = kmap(page2);
|
-ptr = kmap_atomic(page);
...
-ptr2 = kmap_atomic(page2);
)
// 1 or more copy versions of the entire page
<+...
(
-copy_page(To, From);
+copy_highpage(To, From);
|
-memmove(To, From, Size);
+memmoveExtra(To, From, Size);
)
...+>
/* kunmap */
(
-kunmap(page2);
...
-kunmap(page);
|
-kunmap(page);
...
-kunmap(page2);
|
-kmap_atomic(ptr2);
...
-kmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on copy_page_rule
@
identifier copy_page_rule.ptr;
identifier copy_page_rule.ptr2;
type VP, VP1;
type VP2, VP21;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
-VP2 ptr2;
... when != ptr2;
? VP21 ptr2;
//
Signed-off-by: Ira Weiny
---
Changes from v1:
Update commit message per David
https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/
---
fs/btrfs/raid56.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
index dbf52f1a379d..7c3f6dc918c1 100644
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -250,8 +250,6 @@ int btrfs_alloc_stripe_hash_table(struct btrfs_fs_info
*info)
static void cache_rbio_pages(struct btrfs_raid_bio *rbio)
{
int i;
- char *s;
- char *d;
int ret;
ret = alloc_rbio_pages(rbio);
@@ -262,13 +260,7 @@ static void cache_rbio_pages(struct btrfs_raid_bio *rbio)
if (!rbio->bio_pages[i])
continue;
- s = kmap(rbio->bio_pages[i]);
- d = kmap(rbio->stripe_pages[i]);
-
- copy_page(d, s);
-
- kunmap(rbio->bio_pages[i]);
- kunmap(rbio->stripe_pages[i]);
+ copy_highpage(rbio->stripe_pages[i], rbio->bio_pages[i]);
SetPageUptodate(rbio->stripe_pages[i]);
}
set_bit(RBIO_CACHE_READY_BIT, >flags);
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 8/8] btrfs: convert to zero_user()
From: Ira Weiny
There are many places where kmap/memset/kunmap patterns occur.
This pattern exists in the core as zero_user()
Use zero_user() to eliminate direct uses of kmap and leverage the new
core functions use of kmap_local_page().
The development of this patch was aided by the following coccinelle
script:
//
// SPDX-License-Identifier: GPL-2.0-only
// Find kmap/memset/kunmap pattern and replace with memset*page calls
//
// NOTE: Offsets and other expressions may be more complex than what the script
// will automatically generate. Therefore a catchall rule is provided to find
// the pattern which then must be evaluated by hand.
//
// Confidence: Low
// Copyright: (C) 2021 Intel Corporation
// URL: http://coccinelle.lip6.fr/
// Comments:
// Options:
//
// Then the memset pattern
//
@ memset_rule1 @
expression page, V, L, Off;
identifier ptr;
type VP;
@@
(
-VP ptr = kmap(page);
|
-ptr = kmap(page);
|
-VP ptr = kmap_atomic(page);
|
-ptr = kmap_atomic(page);
)
<+...
(
-memset(ptr, 0, L);
+zero_user(page, 0, L);
|
-memset(ptr + Off, 0, L);
+zero_user(page, Off, L);
|
-memset(ptr, V, L);
+memset_page(page, V, 0, L);
|
-memset(ptr + Off, V, L);
+memset_page(page, V, Off, L);
)
...+>
(
-kunmap(page);
|
-kunmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on memset_rule1
@
identifier memset_rule1.ptr;
type VP, VP1;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
//
// Catch all
//
@ memset_rule2 @
expression page;
identifier ptr;
expression GenTo, GenSize, GenValue;
type VP;
@@
(
-VP ptr = kmap(page);
|
-ptr = kmap(page);
|
-VP ptr = kmap_atomic(page);
|
-ptr = kmap_atomic(page);
)
<+...
(
//
// Some call sites have complex expressions within the memset/memcpy
// The follow are catch alls which need to be evaluated by hand.
//
-memset(GenTo, 0, GenSize);
+zero_userExtra(page, GenTo, GenSize);
|
-memset(GenTo, GenValue, GenSize);
+memset_pageExtra(page, GenValue, GenTo, GenSize);
)
...+>
(
-kunmap(page);
|
-kunmap_atomic(ptr);
)
// Remove any pointers left unused
@
depends on memset_rule2
@
identifier memset_rule2.ptr;
type VP, VP1;
@@
-VP ptr;
... when != ptr;
? VP1 ptr;
//
Signed-off-by: Ira Weiny
---
Changes from v1:
Update commit message per David
https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/
---
fs/btrfs/compression.c | 5 +
fs/btrfs/extent_io.c | 22 --
fs/btrfs/inode.c | 33 ++---
fs/btrfs/reflink.c | 6 +-
fs/btrfs/zlib.c| 5 +
fs/btrfs/zstd.c| 5 +
6 files changed, 18 insertions(+), 58 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 047b632b4139..a219dcdb749e 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -567,16 +567,13 @@ static noinline int add_ra_bio_pages(struct inode *inode,
free_extent_map(em);
if (page->index == end_index) {
- char *userpage;
size_t zero_offset = offset_in_page(isize);
if (zero_offset) {
int zeros;
zeros = PAGE_SIZE - zero_offset;
- userpage = kmap_atomic(page);
- memset(userpage + zero_offset, 0, zeros);
+ zero_user(page, zero_offset, zeros);
flush_dcache_page(page);
- kunmap_atomic(userpage);
}
}
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index c9cee458e001..bdc9389bff59 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3229,15 +3229,12 @@ int btrfs_do_readpage(struct page *page, struct
extent_map **em_cached,
}
if (page->index == last_byte >> PAGE_SHIFT) {
- char *userpage;
size_t zero_offset = offset_in_page(last_byte);
if (zero_offset) {
iosize = PAGE_SIZE - zero_offset;
- userpage = kmap_atomic(page);
- memset(userpage + zero_offset, 0, iosize);
+ zero_user(page, zero_offset, iosize);
flush_dcache_page(page);
- kunmap_atomic(userpage);
}
}
while (cur <= end) {
@@ -3245,14 +3242,11 @@ int btrfs_do_readpage(struct page *page, struct
extent_map **em_cached,
u64 offset;
if (cur >= last_byte) {
- char *userpage;
struct extent_state *cached = NULL;
iosize = PAGE_SIZE - pg_offset;
- userpage = kmap_atomic(page);
- memset(userpage + pg_offset, 0, iosize);
+ zero_user(page, pg_offset, iosize);
flush_dcache_page(page);
-
[PATCH V2 3/8] mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page()
From: Ira Weiny
3 more common kmap patterns are kmap/memcpy/kunmap, kmap/memmove/kunmap.
and kmap/memset/kunmap.
Add helper functions for those patterns which use kmap_local_page().
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index c17a175fe5fe..0b5d89621cb9 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -276,6 +276,39 @@ static inline void copy_highpage(struct page *to, struct
page *from)
#endif
+static inline void memcpy_page(struct page *dst_page, size_t dst_off,
+ struct page *src_page, size_t src_off,
+ size_t len)
+{
+ char *dst = kmap_local_page(dst_page);
+ char *src = kmap_local_page(src_page);
+
+ memcpy(dst + dst_off, src + src_off, len);
+ kunmap_local(src);
+ kunmap_local(dst);
+}
+
+static inline void memmove_page(struct page *dst_page, size_t dst_off,
+ struct page *src_page, size_t src_off,
+ size_t len)
+{
+ char *dst = kmap_local_page(dst_page);
+ char *src = kmap_local_page(src_page);
+
+ memmove(dst + dst_off, src + src_off, len);
+ kunmap_local(src);
+ kunmap_local(dst);
+}
+
+static inline void memset_page(struct page *page, size_t offset, int val,
+ size_t len)
+{
+ char *addr = kmap_local_page(page);
+
+ memset(addr + offset, val, len);
+ kunmap_local(addr);
+}
+
static inline void memcpy_from_page(char *to, struct page *page,
size_t offset, size_t len)
{
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 5/8] iov_iter: Remove memzero_page() in favor of zero_user()
From: Ira Weiny
zero_user() is already defined with the same interface and contains the
same code pattern as memzero_page(). Remove memzero_page() and use the
already defined common function zero_user()
To: Alexander Viro
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
lib/iov_iter.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 9889e9903cdf..aa0d03b33a1e 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -466,13 +467,6 @@ void iov_iter_init(struct iov_iter *i, unsigned int
direction,
}
EXPORT_SYMBOL(iov_iter_init);
-static void memzero_page(struct page *page, size_t offset, size_t len)
-{
- char *addr = kmap_atomic(page);
- memset(addr + offset, 0, len);
- kunmap_atomic(addr);
-}
-
static inline bool allocated(struct pipe_buffer *buf)
{
return buf->ops == _pipe_buf_ops;
@@ -950,7 +944,7 @@ static size_t pipe_zero(size_t bytes, struct iov_iter *i)
do {
size_t chunk = min_t(size_t, n, PAGE_SIZE - off);
- memzero_page(pipe->bufs[i_head & p_mask].page, off, chunk);
+ zero_user(pipe->bufs[i_head & p_mask].page, off, chunk);
i->head = i_head;
i->iov_offset = off + chunk;
n -= chunk;
@@ -967,7 +961,7 @@ size_t iov_iter_zero(size_t bytes, struct iov_iter *i)
return pipe_zero(bytes, i);
iterate_and_advance(i, bytes, v,
clear_user(v.iov_base, v.iov_len),
- memzero_page(v.bv_page, v.bv_offset, v.bv_len),
+ zero_user(v.bv_page, v.bv_offset, v.bv_len),
memset(v.iov_base, 0, v.iov_len)
)
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 4/8] mm/highmem: Add VM_BUG_ON() to mem*_page() calls
From: Ira Weiny
Add VM_BUG_ON bounds checks to ensure the newly lifted and created page
memory operations do not result in corrupted data in neighbor pages and
to make them consistent with zero_user().[1][2]
[1]
https://lore.kernel.org/lkml/20201210053502.gs1563...@iweiny-desk2.sc.intel.com/
[2]
https://lore.kernel.org/lkml/20210209110931.00f00e47d9a0529fcee2f...@linux-foundation.org/
Cc: Christoph Hellwig
Suggested-by: Matthew Wilcox
Suggested-by: Andrew Morton
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 0b5d89621cb9..520bbc67e67f 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -283,6 +283,7 @@ static inline void memcpy_page(struct page *dst_page,
size_t dst_off,
char *dst = kmap_local_page(dst_page);
char *src = kmap_local_page(src_page);
+ BUG_ON(dst_off + len > PAGE_SIZE || src_off + len > PAGE_SIZE);
memcpy(dst + dst_off, src + src_off, len);
kunmap_local(src);
kunmap_local(dst);
@@ -295,6 +296,7 @@ static inline void memmove_page(struct page *dst_page,
size_t dst_off,
char *dst = kmap_local_page(dst_page);
char *src = kmap_local_page(src_page);
+ BUG_ON(dst_off + len > PAGE_SIZE || src_off + len > PAGE_SIZE);
memmove(dst + dst_off, src + src_off, len);
kunmap_local(src);
kunmap_local(dst);
@@ -305,6 +307,7 @@ static inline void memset_page(struct page *page, size_t
offset, int val,
{
char *addr = kmap_local_page(page);
+ BUG_ON(offset + len > PAGE_SIZE);
memset(addr + offset, val, len);
kunmap_local(addr);
}
@@ -314,6 +317,7 @@ static inline void memcpy_from_page(char *to, struct page
*page,
{
char *from = kmap_local_page(page);
+ BUG_ON(offset + len > PAGE_SIZE);
memcpy(to, from + offset, len);
kunmap_local(from);
}
@@ -323,6 +327,7 @@ static inline void memcpy_to_page(struct page *page, size_t
offset,
{
char *to = kmap_local_page(page);
+ BUG_ON(offset + len > PAGE_SIZE);
memcpy(to + offset, from, len);
kunmap_local(to);
}
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 0/8] btrfs: convert kmaps to core page calls
From: Ira Weiny Changes from V1: Rework commit messages because they were very weak Change 'fs/btrfs: X' to 'btrfs: x' https://lore.kernel.org/lkml/20210209151442.gu1...@suse.cz/ Per Andrew Split out changes to highmem.h The addition memcpy, memmove, and memset page functions The change from kmap_atomic to kmap_local_page The addition of BUG_ON The conversion of memzero_page to zero_user in iov_iter Change BUG_ON to VM_BUG_ON While we are refactoring adjust the line length down per Chaitany There are many places where kmap//kunmap patterns occur. We lift a couple of these patterns to the core common functions and use them as well as existing core functions in the btrfs file system. At the same time we convert those core functions to use kmap_local_page() which is more efficient in those calls. Per the conversation on V1 it looks like Andrew would like this to go through the btrfs tree. I think that is fine. The other users of memcpy_[to|from]_page are probably not ready and I believe could be taken in an early rc after David submits. Is that ok with you David? Thanks, Ira Ira Weiny (8): mm/highmem: Lift memcpy_[to|from]_page to core mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page() mm/highmem: Introduce memcpy_page(), memmove_page(), and memset_page() mm/highmem: Add VM_BUG_ON() to mem*_page() calls iov_iter: Remove memzero_page() in favor of zero_user() btrfs: use memcpy_[to|from]_page() and kmap_local_page() btrfs: use copy_highpage() instead of 2 kmaps() btrfs: convert to zero_user() fs/btrfs/compression.c | 11 +++- fs/btrfs/extent_io.c| 22 +++- fs/btrfs/inode.c| 33 fs/btrfs/lzo.c | 4 +-- fs/btrfs/raid56.c | 10 +--- fs/btrfs/reflink.c | 12 ++--- fs/btrfs/send.c | 7 ++ fs/btrfs/zlib.c | 10 +++- fs/btrfs/zstd.c | 11 +++- include/linux/highmem.h | 56 + lib/iov_iter.c | 26 +++ 11 files changed, 89 insertions(+), 113 deletions(-) -- 2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 1/8] mm/highmem: Lift memcpy_[to|from]_page to core
From: Ira Weiny
Working through a conversion to a call kmap_local_page() instead of
kmap() revealed many places where the pattern kmap/memcpy/kunmap
occurred.
Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
Viro all suggested putting this code into helper functions. Al Viro
further pointed out that these functions already existed in the iov_iter
code.[1]
Various locations for the lifted functions were considered.
Headers like mm.h or string.h seem ok but don't really portray the
functionality well. pagemap.h made some sense but is for page cache
functionality.[2]
Another alternative would be to create a new header for the promoted
memcpy functions, but it masks the fact that these are designed to copy
to/from pages using the kernel direct mappings and complicates matters
with a new header.
Placing these functions in 'highmem.h' is suboptimal especially with the
changes being proposed in the functionality of kmap. From a caller
perspective including/using 'highmem.h' implies that the functions
defined in that header are only required when highmem is in use which is
increasingly not the case with modern processors. However, highmem.h is
where all the current functions like this reside (zero_user(),
clear_highpage(), clear_user_highpage(), copy_user_highpage(), and
copy_highpage()). So it makes the most sense even though it is
distasteful for some.[3]
Lift memcpy_to_page() and memcpy_from_page() to pagemap.h.
[1] https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/
https://lore.kernel.org/lkml/20201013112544.ga5...@infradead.org/
[2] https://lore.kernel.org/lkml/20201208122316.gh7...@casper.infradead.org/
[3] https://lore.kernel.org/lkml/20201013200149.gi3576...@zeniv.linux.org.uk/#t
https://lore.kernel.org/lkml/20201208163814.gn1563...@iweiny-desk2.sc.intel.com/
Cc: Boris Pismenny
Cc: Or Gerlitz
Cc: Dave Hansen
Suggested-by: Matthew Wilcox
Suggested-by: Christoph Hellwig
Suggested-by: Dan Williams
Suggested-by: Al Viro
Suggested-by: Eric Biggers
Signed-off-by: Ira Weiny
---
Changes from v1 btrfs series:
https://lore.kernel.org/lkml/20210205232304.1670522-2-ira.we...@intel.com/
Split out the BUG_ON()'s per Andrew
Split out the change to kmap_local_page() per Andrew
Split out the addition of memcpy_page, memmove_page, and memset_page
While we are refactoring adjust the line length down per Chaitanya
https://lore.kernel.org/lkml/byapr04mb49655e5bdb24a108feffe9c486...@byapr04mb4965.namprd04.prod.outlook.com/
Chagnes for V4:
Update commit message to say kmap_local_page() since
kmap_thread() is no longer valid
Changes for V3:
From Matthew Wilcox
Move calls to highmem.h
Add BUG_ON()
Changes for V2:
From Thomas Gleixner
Change kmap_atomic() to kmap_local_page() after basing
on tip/core/mm
From Joonas Lahtinen
Reverse offset/val in memset_page()
---
include/linux/highmem.h | 18 ++
lib/iov_iter.c | 14 --
2 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index d2c70d3772a3..736b6a9f144d 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -276,4 +276,22 @@ static inline void copy_highpage(struct page *to, struct
page *from)
#endif
+static inline void memcpy_from_page(char *to, struct page *page,
+ size_t offset, size_t len)
+{
+ char *from = kmap_atomic(page);
+
+ memcpy(to, from + offset, len);
+ kunmap_atomic(from);
+}
+
+static inline void memcpy_to_page(struct page *page, size_t offset,
+ const char *from, size_t len)
+{
+ char *to = kmap_atomic(page);
+
+ memcpy(to + offset, from, len);
+ kunmap_atomic(to);
+}
+
#endif /* _LINUX_HIGHMEM_H */
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index a21e6a5792c5..9889e9903cdf 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -466,20 +466,6 @@ void iov_iter_init(struct iov_iter *i, unsigned int
direction,
}
EXPORT_SYMBOL(iov_iter_init);
-static void memcpy_from_page(char *to, struct page *page, size_t offset,
size_t len)
-{
- char *from = kmap_atomic(page);
- memcpy(to, from + offset, len);
- kunmap_atomic(from);
-}
-
-static void memcpy_to_page(struct page *page, size_t offset, const char *from,
size_t len)
-{
- char *to = kmap_atomic(page);
- memcpy(to + offset, from, len);
- kunmap_atomic(to);
-}
-
static void memzero_page(struct page *page, size_t offset, size_t len)
{
char *addr = kmap_atomic(page);
--
2.28.0.rc0.12.gb6a658bd00c9
[PATCH V2 2/8] mm/highmem: Convert memcpy_[to|from]_page() to kmap_local_page()
From: Ira Weiny
kmap_local_page() is more efficient and is well suited for these calls.
Convert the kmap() to kmap_local_page()
Cc: Andrew Morton
Cc: Christoph Hellwig
Signed-off-by: Ira Weiny
---
New for V2
---
include/linux/highmem.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index 736b6a9f144d..c17a175fe5fe 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -279,19 +279,19 @@ static inline void copy_highpage(struct page *to, struct
page *from)
static inline void memcpy_from_page(char *to, struct page *page,
size_t offset, size_t len)
{
- char *from = kmap_atomic(page);
+ char *from = kmap_local_page(page);
memcpy(to, from + offset, len);
- kunmap_atomic(from);
+ kunmap_local(from);
}
static inline void memcpy_to_page(struct page *page, size_t offset,
const char *from, size_t len)
{
- char *to = kmap_atomic(page);
+ char *to = kmap_local_page(page);
memcpy(to + offset, from, len);
- kunmap_atomic(to);
+ kunmap_local(to);
}
#endif /* _LINUX_HIGHMEM_H */
--
2.28.0.rc0.12.gb6a658bd00c9
Re: [PATCH v7 2/6] mfd: Support ROHM BD9576MUF and BD9573MUF
Hello Lee,
On Tue, 2021-02-09 at 14:55 +, Lee Jones wrote:
> On Fri, 22 Jan 2021, Matti Vaittinen wrote:
>
> > Add core support for ROHM BD9576MUF and BD9573MUF PMICs which are
> > mainly used to power the R-Car series processors.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > +
> > +static struct mfd_cell bd9573_mfd_cells[] = {
> > + { .name = "bd9573-pmic", },
> > + { .name = "bd9576-wdt", },
> > +};
> > +
> > +static struct mfd_cell bd9576_mfd_cells[] = {
> > + { .name = "bd9576-pmic", },
> > + { .name = "bd9576-wdt", },
> > +};
>
> What is a PMIC in this context?
>
> To me a PMIC is a bunch of devices. What is this probing?
I agree. PMIC is the IC as a whole. This name was not the best one.
>
> Maybe this is *-regulator?
That would be more descriptive and I can change this. However, it means
I need to change the already applied regulator part too. Furthermore,
all other ROHM PMIC drivers I've written use the -pmic for
regulators and so does a few other drivers at least for ICs from Maxim,
Samsung and TI. That's why I don't think the -pmic is that
confusing. If it was my decision, I would stick with the pmic for the
sake of the consistency.
+
> > + ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_AUTO, mfd,
> > cells,
>
> This nomenclature is confusing.
>
> cells and num_cells would clear it up.
I can change it.
+
> > +#define BD957X_MAX_REGISTER 0x61
>
> Nit: Can you tab these out for improved readability please?
Sure, no problem.
Thanks for the review!
Best Regards
--Matti
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation Simon)
Re: [PATCH v2 08/14] x86/fault: Skip erratum #93 workaround on new CPUs
On Tue, Feb 9, 2021 at 6:33 PM Andy Lutomirski wrote:
>
> Erratum #93 applies to the first generation of AMD K8 CPUs. Skip the
> workaround on newer CPUs.
Whoops, this breaks the !CPU_SUP_AMD build. It needs a fixup like this:
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fault=06772a3b6918bf6d6d0778946149b7d56ae30d80
Boris, do you want a v3?
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/mm/fault.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index cbb1a9754473..3fe2f4800b69 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -442,9 +442,8 @@ static void dump_pagetable(unsigned long address)
> */
> static int is_errata93(struct pt_regs *regs, unsigned long address)
> {
> -#if defined(CONFIG_X86_64) && defined(CONFIG_CPU_SUP_AMD)
> - if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD
> - || boot_cpu_data.x86 != 0xf)
> +#if defined(CONFIG_X86_64)
> + if (!is_amd_k8_pre_npt())
> return 0;
>
> if (user_mode(regs))
> --
> 2.29.2
>
Re: [PATCH v2 06/28] locking/rwlocks: Add contention detection for rwlocks
On 2/9/21 4:27 PM, Waiman Long wrote: [ ... ] > > It is because in arch/mips/include/asm/spinlock.h, asm/qrwlock.h is included > before asm/qspinlock.h. The compilation error should be gone if the > asm/qrwlock.h is removed or moved after asm/qspinlock.h. > > I did a x86 build and there was no compilation issue. > I can not really comment on what exactly is wrong - I don't know the code well enough to do that - but I don't think this is a valid argument. Anyway, it seems like mips is the only architecture affected by the problem. I am not entirely sure, though - linux-next is too broken for that. Thanks, Guenter
Re: [PATCH] bpf_lru_list: Read double-checked variable once without lock
On Tue, Feb 09, 2021 at 12:27:01PM +0100, Marco Elver wrote:
> For double-checked locking in bpf_common_lru_push_free(), node->type is
> read outside the critical section and then re-checked under the lock.
> However, concurrent writes to node->type result in data races.
>
> For example, the following concurrent access was observed by KCSAN:
>
> write to 0x88801521bc22 of 1 bytes by task 10038 on cpu 1:
>__bpf_lru_node_move_inkernel/bpf/bpf_lru_list.c:91
>__local_list_flushkernel/bpf/bpf_lru_list.c:298
>...
> read to 0x88801521bc22 of 1 bytes by task 10043 on cpu 0:
>bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:507
>bpf_lru_push_free kernel/bpf/bpf_lru_list.c:555
>...
>
> Fix the data races where node->type is read outside the critical section
> (for double-checked locking) by marking the access with READ_ONCE() as
> well as ensuring the variable is only accessed once.
>
> Reported-by: syzbot+3536db46dfa58c573...@syzkaller.appspotmail.com
> Reported-by: syzbot+516acdb03d3e27d91...@syzkaller.appspotmail.com
> Signed-off-by: Marco Elver
> ---
> Detailed reports:
>
> https://groups.google.com/g/syzkaller-upstream-moderation/c/PwsoQ7bfi8k/m/NH9Ni2WxAQAJ
>
>
> https://groups.google.com/g/syzkaller-upstream-moderation/c/-fXQO9ehxSM/m/RmQEcI2oAQAJ
>
> ---
> kernel/bpf/bpf_lru_list.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/bpf/bpf_lru_list.c b/kernel/bpf/bpf_lru_list.c
> index 1b6b9349cb85..d99e89f113c4 100644
> --- a/kernel/bpf/bpf_lru_list.c
> +++ b/kernel/bpf/bpf_lru_list.c
> @@ -502,13 +502,14 @@ struct bpf_lru_node *bpf_lru_pop_free(struct bpf_lru
> *lru, u32 hash)
> static void bpf_common_lru_push_free(struct bpf_lru *lru,
>struct bpf_lru_node *node)
> {
> + u8 node_type = READ_ONCE(node->type);
> unsigned long flags;
>
> - if (WARN_ON_ONCE(node->type == BPF_LRU_LIST_T_FREE) ||
> - WARN_ON_ONCE(node->type == BPF_LRU_LOCAL_LIST_T_FREE))
> + if (WARN_ON_ONCE(node_type == BPF_LRU_LIST_T_FREE) ||
> + WARN_ON_ONCE(node_type == BPF_LRU_LOCAL_LIST_T_FREE))
> return;
>
> - if (node->type == BPF_LRU_LOCAL_LIST_T_PENDING) {
> + if (node_type == BPF_LRU_LOCAL_LIST_T_PENDING) {
I think this can be bpf-next.
Acked-by: Martin KaFai Lau
Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
On Thu, Dec 17, 2020 at 07:17:03PM -0800, Saravana Kannan wrote: > Cyclic dependencies in some firmware was one of the last remaining > reasons fw_devlink=on couldn't be set by default. Now that cyclic > dependencies don't block probing, set fw_devlink=on by default. > > Setting fw_devlink=on by default brings a bunch of benefits (currently, > only for systems with device tree firmware): > * Significantly cuts down deferred probes. > * Device probe is effectively attempted in graph order. > * Makes it much easier to load drivers as modules without having to > worry about functional dependencies between modules (depmod is still > needed for symbol dependencies). > > If this patch prevents some devices from probing, it's very likely due > to the system having one or more device drivers that "probe"/set up a > device (DT node with compatible property) without creating a struct > device for it. If we hit such cases, the device drivers need to be > fixed so that they populate struct devices and probe them like normal > device drivers so that the driver core is aware of the devices and their > status. See [1] for an example of such a case. > > [1] - > https://lore.kernel.org/lkml/CAGETcx9PiX==mlxb9po8myyk6u2vhpvwtmsa5nkd-ywh5xh...@mail.gmail.com/ > Signed-off-by: Saravana Kannan This patch breaks nios2 boot tests in qemu. The system gets stuck when trying to reboot. Reverting this patch fixes the problem. Bisect log is attached. It may also break a variety of other boot tests, but with 115 of 430 boot tests failing in -next it is difficult to identify all culprits. Guenter --- Bisect log: # bad: [a4bfd8d46ac357c12529e4eebb6c89502b03ecc9] Add linux-next specific files for 20210209 # good: [92bf22614b21a2706f4993b278017e437f7785b3] Linux 5.11-rc7 git bisect start 'HEAD' 'v5.11-rc7' # good: [a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53] Merge remote-tracking branch 'crypto/master' git bisect good a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53 # good: [21d507c41bdf83f6afc0e02976e43c10badfc6cd] Merge remote-tracking branch 'spi/for-next' git bisect good 21d507c41bdf83f6afc0e02976e43c10badfc6cd # bad: [30cd4c688a3bcf324f011d7716044b1a4681efc1] Merge remote-tracking branch 'soundwire/next' git bisect bad 30cd4c688a3bcf324f011d7716044b1a4681efc1 # good: [c43d2173d3eb4047bb62a7a393a298a1032cce18] Merge remote-tracking branch 'drivers-x86/for-next' git bisect good c43d2173d3eb4047bb62a7a393a298a1032cce18 # bad: [4dd66c506de68a592f2dd4ef64cc9b0d7c0f3117] Merge remote-tracking branch 'usb-chipidea-next/for-usb-next' git bisect bad 4dd66c506de68a592f2dd4ef64cc9b0d7c0f3117 # good: [29b01295a829fba7399ee84afff4e64660e49f04] usb: typec: Add typec_partner_set_pd_revision git bisect good 29b01295a829fba7399ee84afff4e64660e49f04 # bad: [dac8ab120e531bf7c358b85750338e1b3d3ca0b9] Merge remote-tracking branch 'usb/usb-next' git bisect bad dac8ab120e531bf7c358b85750338e1b3d3ca0b9 # good: [678481467d2e1460a49e626d8e9ba0c7e9742f53] usb: dwc3: core: Check maximum_speed SSP genXxY git bisect good 678481467d2e1460a49e626d8e9ba0c7e9742f53 # good: [5d3d0a61479847a8729ffdda33867f6b3443c15f] Merge remote-tracking branch 'ipmi/for-next' git bisect good 5d3d0a61479847a8729ffdda33867f6b3443c15f # bad: [e13f5b7a130f7b6d4d34be27a87393890b5ee2ba] of: property: Add fw_devlink support for "gpio" and "gpios" binding git bisect bad e13f5b7a130f7b6d4d34be27a87393890b5ee2ba # good: [b0e2fa4f611bb9ab22928605d5b1c7fd44e73955] driver core: Handle cycles in device links created by fw_devlink git bisect good b0e2fa4f611bb9ab22928605d5b1c7fd44e73955 # bad: [0fab972eef49ef8d30eb91d6bd98861122d083d1] drivers: core: Detach device from power domain on shutdown git bisect bad 0fab972eef49ef8d30eb91d6bd98861122d083d1 # bad: [e590474768f1cc04852190b61dec692411b22e2a] driver core: Set fw_devlink=on by default git bisect bad e590474768f1cc04852190b61dec692411b22e2a # good: [c13b827927112ba6170bea31c638a8573c127461] driver core: fw_devlink_relax_cycle() can be static git bisect good c13b827927112ba6170bea31c638a8573c127461 # first bad commit: [e590474768f1cc04852190b61dec692411b22e2a] driver core: Set fw_devlink=on by default
[PATCH] docs: reporting-issues.rst: explain how to decode stack traces
Replace placeholder text about decoding stack traces with a section that properly describes what a typical user should do these days. To make it works for them, add a paragraph in an earlier section to ensure people build their kernels with everything that's needed to decode stack traces later. Signed-off-by: Thorsten Leemhuis --- Reminder: This is not my area of expertise. Hopefully I didn't write anything stupid or omitted something people find important. If I did, please let me know, ideally suggesting what to write; bonus points for people sending text I can simply include in the next revision. I CCed Sasha, because he wrote decode_stacktrace.sh; I also CCed a bunch of people that showed interest in this topic when I asked for help on Twitter. I'm still unsure if linking to admin-guide/bug-hunting.rst is a good idea, as it seems quite outdated; reporting-bugs did that, but for now I settled on 'don't do that'. Ciao, Thorsten --- .../admin-guide/reporting-issues.rst | 77 +-- 1 file changed, 55 insertions(+), 22 deletions(-) diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index 07879d01fe68..b9c07d8e3141 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -154,8 +154,8 @@ After these preparations you'll now enter the main part: that hear about it for the first time. And if you learned something in this process, consider searching again for existing reports about the issue. - * If the failure includes a stack dump, like an Oops does, consider decoding - it to find the offending line of code. + * If your failure involves a 'panic', 'oops', or 'warning', consider decoding + the kernel log to find the line of code that trigger the error. * If your problem is a regression, try to narrow down when the issue was introduced as much as possible. @@ -869,6 +869,15 @@ pick up the configuration of your current kernel and then tries to adjust it somewhat for your system. That does not make the resulting kernel any better, but quicker to compile. +Note: If you are dealing with a kernel panic, oops, or warning, please make +sure to enable CONFIG_KALLSYMS when configuring your kernel. Additionally, +enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO, too; the latter is the +relevant one of those two, but can only be reached if you enable the former. Be +aware CONFIG_DEBUG_INFO increases the storage space required to build a kernel +by quite a bit. But that's worth it, as these options will allow you later to +pinpoint the exact line of code that triggers your issue. The section 'Decode +failure messages' below explains this in more detail. + Check 'taint' flag -- @@ -923,31 +932,55 @@ instead you can join. Decode failure messages --- -.. note:: +*If your failure involves a 'panic', 'oops', or 'warning', consider +decoding the kernel log to find the line of code that trigger the error.* - FIXME: The text in this section is a placeholder for now and quite similar to - the old text found in 'Documentation/admin-guide/reporting-bugs.rst' - currently. It and the document it references are known to be outdated and - thus need to be revisited. Thus consider this note a request for help: if you - are familiar with this topic, please write a few lines that would fit here. - Alternatively, simply outline the current situation roughly to the main - authors of this document (see intro), as they might be able to write - something then. +When the kernel detects an internal problem, it will log some information about +the executed code. This makes it possible to pinpoint the exact line in the +source code that triggered the issue and shows how it was called. But that only +works if you enabled CONFIG_DEBUG_INFO and CONFIG_KALLSYMS when configuring +your kernel. If you did so, consider to decode the information from the +kernel's log. That will make it a lot easier to understand what lead to the +'panic', 'oops', or 'warning', which increases the chances enormously that +someone can provide a fix. - This section in the end should answer questions like "when is this actually - needed", "what .config options to ideally set earlier to make this step easy - or unnecessary?" (likely CONFIG_UNWINDER_ORC when it's available, otherwise - CONFIG_UNWINDER_FRAME_POINTER; but is there anything else needed?). +Decoding can be done with a script you find in the Linux source tree. If you +are running a kernel you compiled yourself earlier, call it like this:: -.. + [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux + +If you are running a packaged vanilla kernel, you will likely have to install +the corresponding packages with debug symbols. Then call the script (which you +might need to get from the Linux sources if your distro
Re: [PATCH] ext4: add .kunitconfig fragment to enable ext4-specific tests
On Tue, Feb 9, 2021 at 6:33 PM Theodore Ts'o wrote: > > On Tue, Feb 09, 2021 at 05:32:06PM -0800, Daniel Latypov wrote: > > > > After [2]: > > $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4/.kunitconfig > > Any chance that in the future this might become: > > $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4 I've been in favor of something like that for a while, but haven't gotten folks to agree on the details. Using bazel-like syntax for a bit, I'd really like it if we had some easy way to do $ kunit test //fs/... # run all fs tests across all subdirs But since there's the possibility of having tests w/ incompatible requirements, I don't know that kunit.py can support it. (Tbh, I think just concatenating fragments would probably just work 99% of the time so kunit.py could get away with doing that). So --kunitconfig= is currently a compromise to give us a less controversial way of providing one-liners for testing a whole subdirectory. I don't think there'd be too much opposition for --kunitconfig to automatically append ".kunitconfig" when passed a directory. But there might be some, since a reader might think --kunitconfig=dir/ means it's recursing over all subdirs. > > Or better yet, syntactic sugar like: > > $ ./tools/testing/kunit.py test fs/ext4 The positional argument for run/exec is probably going to be taken by: https://lore.kernel.org/linux-kselftest/20210206000854.2037923-1-dlaty...@google.com/ https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/commit/?h=kunit=5d31f71efcb6bce56ca3ab92eed0c8f2dbcc6f9a So we'd see something like: $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4 '*inode*' Or if we set and followed naming conventions: $ ./tools/testing/kunit.py run --alltests "ext4-*" (this would take a lot longer to build however...) Filtering could also let us curate only a few, less granular .kunitconfig fragments (at the cost of higher build time). E.g. $ ./tools/testing/kunit.py run --kunitconfig=fs/ "ext4-*" > > would be really nice. > > - Ted
Re: [PATCH] net/mlx5: docs: correct section reference in table of contents
On Fri, 2021-02-05 at 10:55 +0100, Lukas Bulwahn wrote:
> Commit 142d93d12dc1 ("net/mlx5: Add devlink subfunction port
> documentation") refers to a section 'mlx5 port function' in the table
> of
> contents, but includes a section 'mlx5 function attributes' instead.
>
> Hence, make htmldocs warns:
>
> mlx5.rst:16: WARNING: Unknown target name: "mlx5 port function".
>
> Correct the section reference in table of contents to the actual name
> of
> section in the documentation.
>
> Also, tune another section underline while visiting this document.
>
> Signed-off-by: Lukas Bulwahn
> ---
> Saeed, please pick this patch for your -next tree on top of the
> commit above.
Applied to net-next-mlx5,
Thanks,
Saeed.
RE: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree
Hi all,
> -Original Message-
> From: Arnd Bergmann [mailto:a...@kernel.org]
> Sent: Tuesday, February 9, 2021 8:36 PM
> To: Geert Uytterhoeven
> Cc: Stephen Rothwell ; Bartosz Golaszewski
> ; Olof Johansson ;
> Arnd Bergmann ; ARM ;
> Bartosz Golaszewski
> ; Linux Kernel Mailing List
> ; Linux Next Mailing List
> ; iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
>
> Subject: Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc
> tree
>
> On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven
> wrote:
> > On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell
> > wrote:
>
> > > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > index 37da418393e0,950010a290f0..
> > > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > @@@ -42,7 -42,6 +42,11 @@@
> > > clock-names = "apb_pclk";
> > > };
> > >
> > > + {
> > > + status = "okay";
> > > + clocks = <_clk>;
> > > +};
> > > ++
> > > + {
> > > + status = "okay";
> > > + };
> >
> > Probably some sort order should be taken into account (gpio before uart0),
> > also avoidng the conflict?
> >
>
> We normally do this by asking everyone to send the dts changes for
> inclusion through the soc tree rather than the subsystem that contains
> the driver. Why is this one in the gpio-brgl tree?
Perhaps this is Bartosz's mistake.
Linus has commented that gpio ml is captured via the soc tree.
https://lore.kernel.org/linux-gpio/cacrpkdb--gsy-0vnafs9pik4tjrnrtryezr2rbzd6sfm8zo...@mail.gmail.com/
Bartosz, could you remove commit " arm: dts: visconti: Add DT support for
Toshiba Visconti5 GPIO driver" from
your tree?
Best regards,
Nobuhiro
Re: [next] [s390 ] net: mlx5: tc_tun.h:24:29: error: field 'match_level' has incomplete type
On Wed, 2021-02-10 at 10:50 +0530, Naresh Kamboju wrote: > While building Linux next tag 20210209 s390 (defconfig) with gcc-9 > make modules failed. > ... > Reported-by: Naresh Kamboju > Thanks for the report a patch was already posted earlier today https://patchwork.kernel.org/project/netdevbpf/patch/20210209203722.12387-1-sa...@kernel.org/ >
