* [PATCH 2/3] mfd: madera: Fix minor formatting issues
From: Charles Keepax @ 2020-05-29 15:57 UTC (permalink / raw)
To: lee.jones; +Cc: s.nawrocki, linux-kernel, patches
In-Reply-To: <20200529155742.18399-1-ckeepax@opensource.cirrus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
drivers/mfd/madera-core.c | 12 ++++++------
drivers/mfd/madera-i2c.c | 1 -
include/linux/mfd/madera/pdata.h | 1 -
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 7e0835cb062b1..4724c1a01a39f 100644
--- a/drivers/mfd/madera-core.c
+++ b/drivers/mfd/madera-core.c
@@ -44,7 +44,7 @@ static const char * const madera_core_supplies[] = {
};
static const struct mfd_cell madera_ldo1_devs[] = {
- { .name = "madera-ldo1" },
+ { .name = "madera-ldo1", },
};
static const char * const cs47l15_supplies[] = {
@@ -55,8 +55,8 @@ static const char * const cs47l15_supplies[] = {
static const struct mfd_cell cs47l15_devs[] = {
{ .name = "madera-pinctrl", },
- { .name = "madera-irq" },
- { .name = "madera-gpio" },
+ { .name = "madera-irq", },
+ { .name = "madera-gpio", },
{
.name = "madera-extcon",
.parent_supplies = cs47l15_supplies,
@@ -108,7 +108,7 @@ static const char * const cs47l85_supplies[] = {
static const struct mfd_cell cs47l85_devs[] = {
{ .name = "madera-pinctrl", },
{ .name = "madera-irq", },
- { .name = "madera-micsupp" },
+ { .name = "madera-micsupp", },
{ .name = "madera-gpio", },
{
.name = "madera-extcon",
@@ -155,10 +155,10 @@ static const char * const cs47l92_supplies[] = {
};
static const struct mfd_cell cs47l92_devs[] = {
- { .name = "madera-pinctrl" },
+ { .name = "madera-pinctrl", },
{ .name = "madera-irq", },
{ .name = "madera-micsupp", },
- { .name = "madera-gpio" },
+ { .name = "madera-gpio", },
{
.name = "madera-extcon",
.parent_supplies = cs47l92_supplies,
diff --git a/drivers/mfd/madera-i2c.c b/drivers/mfd/madera-i2c.c
index 6b965eb034b6c..7df5b9ba58554 100644
--- a/drivers/mfd/madera-i2c.c
+++ b/drivers/mfd/madera-i2c.c
@@ -88,7 +88,6 @@ static int madera_i2c_probe(struct i2c_client *i2c,
if (!madera)
return -ENOMEM;
-
madera->regmap = devm_regmap_init_i2c(i2c, regmap_16bit_config);
if (IS_ERR(madera->regmap)) {
ret = PTR_ERR(madera->regmap);
diff --git a/include/linux/mfd/madera/pdata.h b/include/linux/mfd/madera/pdata.h
index fa9595dd42ba5..601cbbc10370c 100644
--- a/include/linux/mfd/madera/pdata.h
+++ b/include/linux/mfd/madera/pdata.h
@@ -21,7 +21,6 @@
struct gpio_desc;
struct pinctrl_map;
-struct madera_codec_pdata;
/**
* struct madera_pdata - Configuration data for Madera devices
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] mfd: arizona: Remove BUG_ON usage
From: Charles Keepax @ 2020-05-29 15:57 UTC (permalink / raw)
To: lee.jones; +Cc: s.nawrocki, linux-kernel, patches
BUG_ON macros are generally frowned upon when the issue isn't super
critical, the kernel can certainly carry on with the 32k clock on the
CODEC in a bad state so change the BUG_ON to a WARN_ON.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
drivers/mfd/arizona-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index f73cf76d1373d..19e0bc3c0683e 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -80,7 +80,7 @@ int arizona_clk32k_disable(struct arizona *arizona)
{
mutex_lock(&arizona->clk_lock);
- BUG_ON(arizona->clk32k_ref <= 0);
+ WARN_ON(arizona->clk32k_ref <= 0);
arizona->clk32k_ref--;
--
2.11.0
^ permalink raw reply related
* Re: PANIC: double fault in fixup_bad_iret
From: Thomas Gleixner @ 2020-05-29 15:57 UTC (permalink / raw)
To: Dmitry Vyukov, syzbot
Cc: LKML, syzkaller-bugs, Ingo Molnar, Borislav Petkov,
the arch/x86 maintainers, Oleg Nesterov
In-Reply-To: <CACT4Y+ajjB8RmG3_H_9r-kaRAZ05ejW02-Py47o7wkkBjwup3Q@mail.gmail.com>
Dmitry,
Dmitry Vyukov <dvyukov@google.com> writes:
> On Fri, May 29, 2020 at 3:14 PM syzbot
> <syzbot+dc1fa714cb070b184db5@syzkaller.appspotmail.com> wrote:
>>
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit: 7b4cb0a4 Add linux-next specific files for 20200525
>> git tree: linux-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=15dc34ba100000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=47b0740d89299c10
>> dashboard link: https://syzkaller.appspot.com/bug?extid=dc1fa714cb070b184db5
>> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14678626100000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1017ef06100000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+dc1fa714cb070b184db5@syzkaller.appspotmail.com
>
> From the reproducer it seems to be either x86 related or ptrace
> related.
>
>> RIP: 0010:fixup_bad_iret+0x24/0x170 arch/x86/kernel/traps.c:665
as a quick assumption that's related to KASAN in fixup_bad_iret() which
is a frightenly bad idea. I'm about to verify.
Thanks,
tglx
^ permalink raw reply
* [linux-next:master 3891/13554] drivers/net/ethernet/huawei/hinic/hinic_sriov.c:477:6: warning: variable 'func_id' set but not used
From: kbuild test robot @ 2020-05-29 15:57 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 6100 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: ff387fc20c697cdc887b2abf7ef494e853795a2f
commit: 7dd29ee128654702bd493ecec0bb22c2c5f0f395 [3891/13554] hinic: add sriov feature support
config: arm64-randconfig-r005-20200529 (attached as .config)
compiler: aarch64-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
git checkout 7dd29ee128654702bd493ecec0bb22c2c5f0f395
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:26:5: warning: no previous prototype for 'hinic_set_mac' [-Wmissing-prototypes]
26 | int hinic_set_mac(struct hinic_hwdev *hwdev, const u8 *mac_addr, u16 vlan_id,
| ^~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:87:5: warning: no previous prototype for 'hinic_vf_info_vlanprio' [-Wmissing-prototypes]
87 | u16 hinic_vf_info_vlanprio(struct hinic_hwdev *hwdev, int vf_id)
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:100:5: warning: no previous prototype for 'hinic_set_vf_vlan' [-Wmissing-prototypes]
100 | int hinic_set_vf_vlan(struct hinic_hwdev *hwdev, bool add, u16 vid,
| ^~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:166:5: warning: no previous prototype for 'hinic_register_vf_msg_handler' [-Wmissing-prototypes]
166 | int hinic_register_vf_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:195:5: warning: no previous prototype for 'hinic_unregister_vf_msg_handler' [-Wmissing-prototypes]
195 | int hinic_unregister_vf_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:212:5: warning: no previous prototype for 'hinic_change_vf_mtu_msg_handler' [-Wmissing-prototypes]
212 | int hinic_change_vf_mtu_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:230:5: warning: no previous prototype for 'hinic_get_vf_mac_msg_handler' [-Wmissing-prototypes]
230 | int hinic_get_vf_mac_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:249:5: warning: no previous prototype for 'hinic_set_vf_mac_msg_handler' [-Wmissing-prototypes]
249 | int hinic_set_vf_mac_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:283:5: warning: no previous prototype for 'hinic_del_vf_mac_msg_handler' [-Wmissing-prototypes]
283 | int hinic_del_vf_mac_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:315:5: warning: no previous prototype for 'hinic_get_vf_link_status_msg_handler' [-Wmissing-prototypes]
315 | int hinic_get_vf_link_status_msg_handler(void *hwdev, u16 vf_id,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:354:26: warning: no previous prototype for 'hinic_get_sriov_info_by_pcidev' [-Wmissing-prototypes]
354 | struct hinic_sriov_info *hinic_get_sriov_info_by_pcidev(struct pci_dev *pdev)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:362:5: warning: no previous prototype for 'hinic_kill_vf_vlan' [-Wmissing-prototypes]
362 | int hinic_kill_vf_vlan(struct hinic_hwdev *hwdev, int vf_id)
| ^~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:385:5: warning: no previous prototype for 'nic_pf_mbox_handler' [-Wmissing-prototypes]
385 | int nic_pf_mbox_handler(void *hwdev, u16 vf_id, u8 cmd, void *buf_in,
| ^~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:474:6: warning: no previous prototype for 'hinic_clear_vf_infos' [-Wmissing-prototypes]
474 | void hinic_clear_vf_infos(struct hinic_dev *nic_dev, u16 vf_id)
| ^~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c: In function 'hinic_clear_vf_infos':
>> drivers/net/ethernet/huawei/hinic/hinic_sriov.c:477:6: warning: variable 'func_id' set but not used [-Wunused-but-set-variable]
477 | u16 func_id;
| ^~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c: At top level:
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:492:5: warning: no previous prototype for 'hinic_deinit_vf_hw' [-Wmissing-prototypes]
492 | int hinic_deinit_vf_hw(struct hinic_sriov_info *sriov_info, u16 start_vf_id,
| ^~~~~~~~~~~~~~~~~~
drivers/net/ethernet/huawei/hinic/hinic_sriov.c:593:5: warning: no previous prototype for 'hinic_init_vf_hw' [-Wmissing-prototypes]
593 | int hinic_init_vf_hw(struct hinic_hwdev *hwdev, u16 start_vf_id, u16 end_vf_id)
| ^~~~~~~~~~~~~~~~
vim +/func_id +477 drivers/net/ethernet/huawei/hinic/hinic_sriov.c
473
474 void hinic_clear_vf_infos(struct hinic_dev *nic_dev, u16 vf_id)
475 {
476 struct vf_data_storage *vf_infos;
> 477 u16 func_id;
478
479 func_id = hinic_glb_pf_vf_offset(nic_dev->hwdev->hwif) + vf_id;
480 vf_infos = nic_dev->hwdev->func_to_io.vf_infos + HW_VF_ID_TO_OS(vf_id);
481 if (vf_infos->pf_set_mac)
482 hinic_port_del_mac(nic_dev, vf_infos->vf_mac_addr, 0);
483
484 if (hinic_vf_info_vlanprio(nic_dev->hwdev, vf_id))
485 hinic_kill_vf_vlan(nic_dev->hwdev, vf_id);
486
487 memset(vf_infos, 0, sizeof(*vf_infos));
488 /* set vf_infos to default */
489 hinic_init_vf_infos(&nic_dev->hwdev->func_to_io, HW_VF_ID_TO_OS(vf_id));
490 }
491
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 41058 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
From: Andreas Färber @ 2020-05-29 15:56 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Greg Kroah-Hartman, Manivannan Sadhasivam, linux-actions,
linux-kernel, linux-serial, Jiri Slaby, linux-arm-kernel
In-Reply-To: <6ee88060c129715980592a1ae33c93923916a14b.1590766726.git.cristian.ciocaltea@gmail.com>
Hi,
Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> that enables OWL UART to be used for KGDB debugging over serial line.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> ---
> drivers/tty/serial/owl-uart.c | 45 ++++++++++++++++++++++++++++++-----
> 1 file changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> index c2fa2f15d50a..26dcc374dec5 100644
> --- a/drivers/tty/serial/owl-uart.c
> +++ b/drivers/tty/serial/owl-uart.c
> @@ -12,6 +12,7 @@
> #include <linux/console.h>
> #include <linux/delay.h>
> #include <linux/io.h>
> +#include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> @@ -20,13 +21,13 @@
> #include <linux/tty.h>
> #include <linux/tty_flip.h>
>
> -#define OWL_UART_PORT_NUM 7
> -#define OWL_UART_DEV_NAME "ttyOWL"
> +#define OWL_UART_PORT_NUM 7
> +#define OWL_UART_DEV_NAME "ttyOWL"
>
> -#define OWL_UART_CTL 0x000
> -#define OWL_UART_RXDAT 0x004
> -#define OWL_UART_TXDAT 0x008
> -#define OWL_UART_STAT 0x00c
> +#define OWL_UART_CTL 0x000
> +#define OWL_UART_RXDAT 0x004
> +#define OWL_UART_TXDAT 0x008
> +#define OWL_UART_STAT 0x00c
Please do not unnecessarily re-indent kernel code. You can do so when
you're actually adding something new.
>
> #define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
> #define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
> @@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port, int flags)
> }
> }
>
> +#ifdef CONFIG_CONSOLE_POLL
> +
> +static int owl_uart_poll_get_char(struct uart_port *port)
> +{
> + u32 c = NO_POLL_CHAR;
> +
> + if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
> + c = owl_uart_read(port, OWL_UART_RXDAT);
> +
> + return c;
> +}
> +
> +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
> +{
> + /* Wait while TX FIFO is full */
> + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
> + cpu_relax();
> +
> + /* Send the character out */
> + owl_uart_write(port, c, OWL_UART_TXDAT);
> +
> + /* Wait for transmitter to become empty */
> + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
> + cpu_relax();
> +}
How is this different from earlycon? I dislike that this is being
open-coded. Please try to reuse existing functions for this.
Regards,
Andreas
> +
> +#endif /* CONFIG_CONSOLE_POLL */
> +
> static const struct uart_ops owl_uart_ops = {
> .set_mctrl = owl_uart_set_mctrl,
> .get_mctrl = owl_uart_get_mctrl,
> @@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
> .request_port = owl_uart_request_port,
> .release_port = owl_uart_release_port,
> .verify_port = owl_uart_verify_port,
> +#ifdef CONFIG_CONSOLE_POLL
> + .poll_get_char = owl_uart_poll_get_char,
> + .poll_put_char = owl_uart_poll_put_char,
> +#endif
> };
>
> #ifdef CONFIG_SERIAL_OWL_CONSOLE
>
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] tty: serial: owl: Add support for kernel debugger
From: Andreas Färber @ 2020-05-29 15:56 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Manivannan Sadhasivam, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, linux-arm-kernel, linux-kernel, linux-actions
In-Reply-To: <6ee88060c129715980592a1ae33c93923916a14b.1590766726.git.cristian.ciocaltea@gmail.com>
Hi,
Am 29.05.20 um 17:50 schrieb Cristian Ciocaltea:
> Implement poll_put_char and poll_get_char callbacks in struct uart_ops
> that enables OWL UART to be used for KGDB debugging over serial line.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
> ---
> drivers/tty/serial/owl-uart.c | 45 ++++++++++++++++++++++++++++++-----
> 1 file changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/owl-uart.c b/drivers/tty/serial/owl-uart.c
> index c2fa2f15d50a..26dcc374dec5 100644
> --- a/drivers/tty/serial/owl-uart.c
> +++ b/drivers/tty/serial/owl-uart.c
> @@ -12,6 +12,7 @@
> #include <linux/console.h>
> #include <linux/delay.h>
> #include <linux/io.h>
> +#include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> @@ -20,13 +21,13 @@
> #include <linux/tty.h>
> #include <linux/tty_flip.h>
>
> -#define OWL_UART_PORT_NUM 7
> -#define OWL_UART_DEV_NAME "ttyOWL"
> +#define OWL_UART_PORT_NUM 7
> +#define OWL_UART_DEV_NAME "ttyOWL"
>
> -#define OWL_UART_CTL 0x000
> -#define OWL_UART_RXDAT 0x004
> -#define OWL_UART_TXDAT 0x008
> -#define OWL_UART_STAT 0x00c
> +#define OWL_UART_CTL 0x000
> +#define OWL_UART_RXDAT 0x004
> +#define OWL_UART_TXDAT 0x008
> +#define OWL_UART_STAT 0x00c
Please do not unnecessarily re-indent kernel code. You can do so when
you're actually adding something new.
>
> #define OWL_UART_CTL_DWLS_MASK GENMASK(1, 0)
> #define OWL_UART_CTL_DWLS_5BITS (0x0 << 0)
> @@ -461,6 +462,34 @@ static void owl_uart_config_port(struct uart_port *port, int flags)
> }
> }
>
> +#ifdef CONFIG_CONSOLE_POLL
> +
> +static int owl_uart_poll_get_char(struct uart_port *port)
> +{
> + u32 c = NO_POLL_CHAR;
> +
> + if (!(owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_RFEM))
> + c = owl_uart_read(port, OWL_UART_RXDAT);
> +
> + return c;
> +}
> +
> +static void owl_uart_poll_put_char(struct uart_port *port, unsigned char c)
> +{
> + /* Wait while TX FIFO is full */
> + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TFFU)
> + cpu_relax();
> +
> + /* Send the character out */
> + owl_uart_write(port, c, OWL_UART_TXDAT);
> +
> + /* Wait for transmitter to become empty */
> + while (owl_uart_read(port, OWL_UART_STAT) & OWL_UART_STAT_TRFL_MASK)
> + cpu_relax();
> +}
How is this different from earlycon? I dislike that this is being
open-coded. Please try to reuse existing functions for this.
Regards,
Andreas
> +
> +#endif /* CONFIG_CONSOLE_POLL */
> +
> static const struct uart_ops owl_uart_ops = {
> .set_mctrl = owl_uart_set_mctrl,
> .get_mctrl = owl_uart_get_mctrl,
> @@ -476,6 +505,10 @@ static const struct uart_ops owl_uart_ops = {
> .request_port = owl_uart_request_port,
> .release_port = owl_uart_release_port,
> .verify_port = owl_uart_verify_port,
> +#ifdef CONFIG_CONSOLE_POLL
> + .poll_get_char = owl_uart_poll_get_char,
> + .poll_put_char = owl_uart_poll_put_char,
> +#endif
> };
>
> #ifdef CONFIG_SERIAL_OWL_CONSOLE
>
--
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)
^ permalink raw reply
* [PATCH 2/2] perf build: Allow explicitely disabling the NO_SYSCALL_TABLE variable
From: Arnaldo Carvalho de Melo @ 2020-05-29 15:55 UTC (permalink / raw)
To: Jiri Olsa, Namhyung Kim
Cc: Ingo Molnar, Thomas Gleixner, Clark Williams, linux-kernel,
linux-perf-users, Arnaldo Carvalho de Melo, Adrian Hunter
In-Reply-To: <20200529155552.463-1-acme@kernel.org>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
This is useful to see if, on x86, the legacy libaudit still works, as it
is used in architectures that don't have the SYSCALL_TABLE logic and we
want to have it tested in 'make -C tools/perf/ build-test'.
E.g.:
Without having audit-libs-devel installed:
$ make NO_SYSCALL_TABLE=1 O=/tmp/build/perf -C tools/perf install-bin
make: Entering directory '/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j12' parallel build
<SNIP>
Auto-detecting system features:
<SNIP>
... libaudit: [ OFF ]
... libbfd: [ on ]
... libcap: [ on ]
<SNIP>
Makefile.config:664: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev
<SNIP>
After installing it:
$ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf
$ time make NO_SYSCALL_TABLE=1 O=/tmp/build/perf -C tools/perf install-bin ; perf test python
make: Entering directory '/home/acme/git/perf/tools/perf'
BUILD: Doing 'make -j12' parallel build
HOSTCC /tmp/build/perf/fixdep.o
HOSTLD /tmp/build/perf/fixdep-in.o
LINK /tmp/build/perf/fixdep
Warning: Kernel ABI header at 'tools/arch/x86/include/asm/msr-index.h' differs from latest version at 'arch/x86/include/asm/msr-index.h'
diff -u tools/arch/x86/include/asm/msr-index.h arch/x86/include/asm/msr-index.h
Warning: Kernel ABI header at 'tools/perf/util/hashmap.h' differs from latest version at 'tools/lib/bpf/hashmap.h'
diff -u tools/perf/util/hashmap.h tools/lib/bpf/hashmap.h
Warning: Kernel ABI header at 'tools/perf/util/hashmap.c' differs from latest version at 'tools/lib/bpf/hashmap.c'
diff -u tools/perf/util/hashmap.c tools/lib/bpf/hashmap.c
Auto-detecting system features:
<SNIP>
... libaudit: [ on ]
... libbfd: [ on ]
... libcap: [ on ]
<SNIP>
$ ldd ~/bin/perf | grep audit
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007fc18978e000)
$
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile.config | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 93fb7510a9a9..6bc9251f1634 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -24,20 +24,22 @@ $(call detected_var,SRCARCH)
NO_PERF_REGS := 1
-NO_SYSCALL_TABLE := 1
+ifneq ($(NO_SYSCALL_TABLE),1)
+ NO_SYSCALL_TABLE := 1
-ifeq ($(SRCARCH),x86)
- ifeq (${IS_64_BIT}, 1)
- NO_SYSCALL_TABLE := 0
- endif
-else
- ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
- NO_SYSCALL_TABLE := 0
+ ifeq ($(SRCARCH),x86)
+ ifeq (${IS_64_BIT}, 1)
+ NO_SYSCALL_TABLE := 0
+ endif
+ else
+ ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
+ NO_SYSCALL_TABLE := 0
+ endif
endif
-endif
-ifneq ($(NO_SYSCALL_TABLE),1)
- CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
+ ifneq ($(NO_SYSCALL_TABLE),1)
+ CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
+ endif
endif
# Additional ARCH settings for ppc
--
2.25.3
^ permalink raw reply related
* [PATCH 1/2] perf build: Group the NO_SYSCALL_TABLE logic
From: Arnaldo Carvalho de Melo @ 2020-05-29 15:55 UTC (permalink / raw)
To: Jiri Olsa, Namhyung Kim
Cc: Ingo Molnar, Thomas Gleixner, Clark Williams, linux-kernel,
linux-perf-users, Arnaldo Carvalho de Melo, Adrian Hunter
In-Reply-To: <20200529155552.463-1-acme@kernel.org>
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To help in allowing to disable it from the make command line.
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/Makefile.config | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index ae325f79e598..93fb7510a9a9 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -23,12 +23,26 @@ include $(srctree)/tools/scripts/Makefile.arch
$(call detected_var,SRCARCH)
NO_PERF_REGS := 1
+
NO_SYSCALL_TABLE := 1
+ifeq ($(SRCARCH),x86)
+ ifeq (${IS_64_BIT}, 1)
+ NO_SYSCALL_TABLE := 0
+ endif
+else
+ ifneq ($(SRCARCH),$(filter $(SRCARCH),powerpc arm64 s390))
+ NO_SYSCALL_TABLE := 0
+ endif
+endif
+
+ifneq ($(NO_SYSCALL_TABLE),1)
+ CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
+endif
+
# Additional ARCH settings for ppc
ifeq ($(SRCARCH),powerpc)
NO_PERF_REGS := 0
- NO_SYSCALL_TABLE := 0
CFLAGS += -I$(OUTPUT)arch/powerpc/include/generated
LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
endif
@@ -37,7 +51,6 @@ endif
ifeq ($(SRCARCH),x86)
$(call detected,CONFIG_X86)
ifeq (${IS_64_BIT}, 1)
- NO_SYSCALL_TABLE := 0
CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -I$(OUTPUT)arch/x86/include/generated
ARCH_INCLUDE = ../../arch/x86/lib/memcpy_64.S ../../arch/x86/lib/memset_64.S
LIBUNWIND_LIBS = -lunwind-x86_64 -lunwind -llzma
@@ -55,7 +68,6 @@ endif
ifeq ($(SRCARCH),arm64)
NO_PERF_REGS := 0
- NO_SYSCALL_TABLE := 0
CFLAGS += -I$(OUTPUT)arch/arm64/include/generated
LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
endif
@@ -70,7 +82,6 @@ endif
ifeq ($(ARCH),s390)
NO_PERF_REGS := 0
- NO_SYSCALL_TABLE := 0
CFLAGS += -fPIC -I$(OUTPUT)arch/s390/include/generated
endif
@@ -78,10 +89,6 @@ ifeq ($(NO_PERF_REGS),0)
$(call detected,CONFIG_PERF_REGS)
endif
-ifneq ($(NO_SYSCALL_TABLE),1)
- CFLAGS += -DHAVE_SYSCALL_TABLE_SUPPORT
-endif
-
# So far there's only x86 and arm libdw unwind support merged in perf.
# Disable it on all other architectures in case libdw unwind
# support is detected in system. Add supported architectures
--
2.25.3
^ permalink raw reply related
* [RFC 0/2] tools/build/ patches to allow setting NO_SYSCALL_TABLE=1 from make command line
From: Arnaldo Carvalho de Melo @ 2020-05-29 15:55 UTC (permalink / raw)
To: Jiri Olsa, Namhyung Kim
Cc: Ingo Molnar, Thomas Gleixner, Clark Williams, linux-kernel,
linux-perf-users, Arnaldo Carvalho de Melo
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Hi Jiri,
Can you please take a look if these are ok? I've tested it
extensively, but being Makefiles, I may be missing something... There
are more patches on top of these in the tmp.perf/core branch in my tree,
if you could take a quick look on those, that would be great as well.
The one that makes libaudit not be tested by default, for instace.
Best regards,
- Arnaldo
Arnaldo Carvalho de Melo (2):
perf build: Group the NO_SYSCALL_TABLE logic
perf build: Allow explicitely disabling the NO_SYSCALL_TABLE variable
tools/perf/Makefile.config | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
--
2.25.3
^ permalink raw reply
* Re: Warn to terminal that subvolume is default on deletion intent
From: David Sterba @ 2020-05-29 15:55 UTC (permalink / raw)
To: Damian Stevenson; +Cc: linux-btrfs
In-Reply-To: <CADAn_AF=p2mQ2p3KsRes-CCFHS+VPHZsVg1L7S=wtFMF4ZOzqw@mail.gmail.com>
On Fri, May 29, 2020 at 05:14:20PM +0200, Damian Stevenson wrote:
> # Error description
> Trying to delete subvolume which is set as default, not allowed.
> States reason to dmesg but not to terminal.
>
> # Request:
> Output to terminal as well, the reason why can't delete subvolume. In
> example: because subvolume is set as default on deletion intent. As
> user I didn't knew I had to follow dmesg, read it just out of luck.
Thanks for the detailed report. You're right, this should be printed as
an error message.
> # On deletion intent
> sudo btrfs subvolume delete /drive/newvol/
> Delete subvolume (no-commit): '/drive/newvol'
> ERROR: Could not destroy subvolume/snapshot: Operation not permitted
This is easy to fix, if anybody wants to take it, if the subvolume
deletion returns -1 and EPERM, then check if the subvolume is default
(btrfs_util_get_default_subvolume_fd) and then print the message.
Additionally, if there's EPERM and the subvolume is not default, it's
either race (the subvolume lost the default status meanwhie), or there's
send in progress. As this could be also confusing, fixing both would be
welcome.
> https://bugzilla.kernel.org/show_bug.cgi?id=207975
I've cross-referenced in github/btrfs-progs issue.
^ permalink raw reply
* Re: [PATCH v3 1/2] PCI: vmd: Filter resource type bits from shadow register
From: Derrick, Jonathan @ 2020-05-29 15:53 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com
Cc: alex.williamson@redhat.com, linux-pci@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
andrzej.jakowski@linux.intel.com, helgaas@kernel.org, hch@lst.de
In-Reply-To: <20200529103315.GC12270@e121166-lin.cambridge.arm.com>
On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> On Wed, May 27, 2020 at 11:02:39PM -0400, Jon Derrick wrote:
> > Versions of VMD with the Host Physical Address shadow register use this
> > register to calculate the bus address offset needed to do guest
> > passthrough of the domain. This register shadows the Host Physical
> > Address registers including the resource type bits. After calculating
> > the offset, the extra resource type bits lead to the VMD resources being
> > over-provisioned at the front and under-provisioned at the back.
> >
> > Example:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> >
> > Expected:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> >
> > If other devices are mapped in the over-provisioned front, it could lead
> > to resource conflict issues with VMD or those devices.
> >
> > Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> > drivers/pci/controller/vmd.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Hi Jon,
>
> it looks like I can take this patch for v5.8 whereas patch 2 depends
> on the QEMU changes acceptance and should probably wait.
>
> Please let me know your thoughts asap and I will try to at least
> squeeze this patch in.
>
> Lorenzo
Hi Lorenzo,
This is fine. Please take Patch 1.
Patch 2 is harmless without the QEMU changes, but may always need a
different approach.
Best,
jon
>
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index dac91d6..e386d4e 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -445,9 +445,11 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> > if (!membar2)
> > return -ENOMEM;
> > offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
> > - readq(membar2 + MB2_SHADOW_OFFSET);
> > + (readq(membar2 + MB2_SHADOW_OFFSET) &
> > + PCI_BASE_ADDRESS_MEM_MASK);
> > offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
> > - readq(membar2 + MB2_SHADOW_OFFSET + 8);
> > + (readq(membar2 + MB2_SHADOW_OFFSET + 8) &
> > + PCI_BASE_ADDRESS_MEM_MASK);
> > pci_iounmap(vmd->dev, membar2);
> > }
> > }
> > --
> > 1.8.3.1
> >
^ permalink raw reply
* Re: [PATCH dt-schema] Fix interrupt controllers with interrupt-map
From: Rob Herring @ 2020-05-29 15:54 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: devicetree
In-Reply-To: <20200528132323.30288-1-geert+renesas@glider.be>
On Thu, May 28, 2020 at 7:23 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
>
> When an interrupt controller has an "interrupt-map" property, an "is
> valid under each of" error is triggered.
>
> Fix this by allowing "interrupt-controller" and "interrupt-map" to
> coexist, in both the interrrupts meta-schema and the
> interrupt-controller schema.
But both should not be present. If 'interrupt-controller' is present,
the Linux irq parsing code will ignore 'interrupt-map'. Seems like
that's backwards, but this parsing code is older than dirt and we'd
probably break some 1990s machine changing it.
Rob
^ permalink raw reply
* Re: [RFC PATCH v4 4/4] scsi: ufs-qcom: add Inline Crypto Engine support
From: Thara Gopinath @ 2020-05-29 15:54 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-scsi, linux-arm-msm, linux-block, linux-fscrypt,
Alim Akhtar, Andy Gross, Avri Altman, Barani Muthukumaran,
Bjorn Andersson, Can Guo, Elliot Berman, John Stultz,
Satya Tangirala
In-Reply-To: <20200507180838.GC236103@gmail.com>
On 5/7/20 2:08 PM, Eric Biggers wrote:
> On Thu, May 07, 2020 at 11:04:35AM -0700, Eric Biggers wrote:
>> Hi Thara,
>>
>> On Thu, May 07, 2020 at 08:36:58AM -0400, Thara Gopinath wrote:
>>>
>>>
>>> On 5/1/20 12:51 AM, Eric Biggers wrote:
>>>> From: Eric Biggers <ebiggers@google.com>
>>>>
>>>> Add support for Qualcomm Inline Crypto Engine (ICE) to ufs-qcom.
>>>>
>>>> The standards-compliant parts, such as querying the crypto capabilities
>>>> and enabling crypto for individual UFS requests, are already handled by
>>>> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
>>>> However, ICE requires vendor-specific init, enable, and resume logic,
>>>> and it requires that keys be programmed and evicted by vendor-specific
>>>> SMC calls. Make the ufs-qcom driver handle these details.
>>>>
>>>> I tested this on Dragonboard 845c, which is a publicly available
>>>> development board that uses the Snapdragon 845 SoC and runs the upstream
>>>> Linux kernel. This is the same SoC used in the Pixel 3 and Pixel 3 XL
>>>> phones. This testing included (among other things) verifying that the
>>>> expected ciphertext was produced, both manually using ext4 encryption
>>>> and automatically using a block layer self-test I've written.
>>> Hello Eric,
>>>
>>> I am interested in testing out this series on 845, 855 and if possile on 865
>>> platforms. Can you give me some more details about your testing please.
>>>
>>
>> Great! You can test this with fscrypt, a.k.a. ext4 or f2fs encryption.
>>
>> A basic manual test would be:
>>
>> 1. Build a kernel with:
>>
>> CONFIG_BLK_INLINE_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION=y
>> CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
>
> Sorry, I forgot: 'CONFIG_SCSI_UFS_CRYPTO=y' is needed too.
Hi Eric,
I tested this manually on db845c, sm8150-mtp and sm8250-mtp.(I added the
dts file entries for 8150 and 8250).
I also ran OsBench test case createfiles[1] on the above platforms.
Following are the results on a non encrypted and encrypted directory on
the same file system(lower the number better)
8250-MTP 8150-MTP DB845
nonencrypt_dir(us) 55.3108954 26.8323124 69.5709552
encrypt_dir(us) 70.0214426 37.5411254 92.3818296
1. https://github.com/mbitsnbites/osbench/blob/master/README.md
--
Warm Regards
Thara
^ permalink raw reply
* Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility
From: Ian Jackson @ 2020-05-29 15:53 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel, Wei Liu
In-Reply-To: <2076e9a4-c07e-9aab-1cc2-f38f7eacd8c0@citrix.com>
Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility"):
> On 05/03/2020 16:24, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH v2 07/17] libxc/restore: STATIC_DATA_END inference for v2 compatibility"):
> >> More importantly however, by design, common code can't call
> >> arch-specific code without a restore_ops hook. Deduping these would
> >> require breaking the restriction which is currently doing a decent job
> >> of keeping x86-isms out of common code.
> > I'm afraid you're going to have to explain that to me at a bit greater
> > length. The biggest thing that is confusing me about your statement
> > here is that your patch is indeed adding x86-specific code to a common
> > file. But also I don't understand the comment about restore_ops
> > hooks - do you mean something in restore_callbacks ?
>
> No. restore_callbacks are plumbing between libxl-save-helper and libxc.
>
> restore_ops are internal to the restore code, and come in x86_pv and
> x86_hvm flavours, with ARM existing in some theoretical future. The
> design of the common save/restore code had deliberate measures put in
> place to make it hard to get arch-specific details slip into common
> code, so porting to different architectures didn't have to start by
> doing a bunch of cleanup.
>
> tl;dr I could put an #ifdef x86'd static inline in the root common
> header (xc_sr_common.h), but the overall complexity is greater than what
> is presented here.
Well, I still don't quite follow but as you point out on irc I haven't
replied for too long. I don't think I should withhold my ack at this
stage.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Thanks,
Ian.
^ permalink raw reply
* Re: kci_build proposal
From: Dan Rue @ 2020-05-29 15:53 UTC (permalink / raw)
To: Guillaume Tucker; +Cc: kernelci, Kevin Hilman
In-Reply-To: <22a9d522-4777-741d-74c9-f3f86ed3422b@collabora.com>
Let's add the questions and items raised in this thread to the agenda
for the discussion scheduled for June 23rd.
Thanks,
Dan
On Thu, May 28, 2020 at 10:03:20PM +0100, Guillaume Tucker wrote:
> On 28/05/2020 18:28, Dan Rue wrote:
> > On Thu, May 28, 2020 at 07:43:40AM +0100, Guillaume Tucker wrote:
> >> On 27/05/2020 20:58, Dan Rue wrote:
> >>> On Fri, May 22, 2020 at 11:22:17AM -0700, Kevin Hilman wrote:
> >>>> "Dan Rue" <dan.rue@linaro.org> writes:
> >>>>
> >>>>> On Tue, Apr 21, 2020 at 04:46:34PM +0100, Guillaume Tucker wrote:
> >>>>>> On Mon, Apr 20, 2020 at 5:36 PM Dan Rue <dan.rue@linaro.org> wrote:
> >>>>
> >>>> [...]
> >>>>
> >>>>>> Basically, rather than adapting kci_build for other purposes, I'm
> >>>>>> suggesting to create a generic tool that can be used by kci_build
> >>>>>> as well as any other kernel CI system.
> >>>>>>
> >>>>>> I don't know how to call this toolbox and where to host it, but
> >>>>>> it would seem wise imho to keep it separate from KernelCI, LKFT
> >>>>>> or any other CI system that would be using it. It would probably
> >>>>>> also make sense to at least keep it kernel-centric to focus on a
> >>>>>> group of use-cases. How does that sound?
> >>>>>
> >>>>> If there's agreement to do this together with kernelci, which I'm really
> >>>>> happy about, then I propose it be something like
> >>>>> github.com/kernelci/<somename>, where somename is available in the pypi
> >>>>> namespace (spanner isn't).
> >>>>>
> >>>>> I think our requirements are largely the same. We do need to decide
> >>>>> about the docker bits, and about how opinionated the tool should be.
> >>>>
> >>>> Having spent the last few weeks getting the existing kci_build working
> >>>> in k8s environment[1], I think how docker/containers fits in here is the
> >>>> key thing we should agree upon.
> >>>>
> >>>> For the initial k8s migration, I started with the requirement to use
> >>>> kci_build as-is, but some of the issues Dan raised are already issues
> >>>> with the k8s build e.g. non-trivial to discover which part of the build
> >>>> failed (and if it's critical or not.)
> >>>>
> >>>> I'm fully supportive rethinking/reworking this tool to be cloud-native.
> >>>> I would also add we also need to be intentional about how
> >>>> artifacts/results are passed between the various phases so we build
> >>>> flexible piplines that fit into a variety of CI/CD pipeline tools (I'd
> >>>> really like to find someone with the time explore reworking our jenkins
> >>>> pipline into tekton[2])
> >>
> >> I think that passing artifacts between build stages is really
> >> part of the pipeline integration work and shouldn't be imposed by
> >> the tools. The tools however should produce intermediary data
> >> and files in a way that can be integrated into various pipelines
> >> with different requirements.
> >>
> >> It seems we can improve this in kci_build by first generating a
> >> JSON file with the static meta-data before starting a kernel
> >> build, then the build would add to that data, then the install
> >> step would add more data again.
> >>
> >> See also my comment below about having the ability to build
> >> individual steps, which should help with error handling.
> >>
> >>> Hi Kevin!
> >>>
> >>> OK, we've started to put some thoughts together on an implementation at
> >>> https://gitlab.com/Linaro/tuxmake.
> >>>
> >>> Some of the details are still a bit preliminary, but we plan to start on
> >>> it soon and get the basic interface and use-cases in place.
> >>>
> >>> Would the design meet your needs? If you have any feedback, we would
> >>> really appreciate it. I'm really not sure how it would fit in with k8s,
> >>> but I anticipate if it were used as a python library there would be a
> >>> lot of fine grained control of the steps.
> >>
> >> I still strongly believe that making the tool call Docker itself
> >> is going to be a big issue - it should really be the other way
> >> round, or at least there should be a way to run the kernel build
> >> directly with an option to wrap it inside a Docker container at
> >> the user's discretion.
> >
> > I'll address this further down.
> >
> >>
> >> It's also important to have the possibility to run each
> >> individual make command separately, to create the .config, build
> >> the image, build the modules, the dtbs, or other arbitrary things
> >> such as kselftest. The current kci_build implementation does too
> >> much already in the build_kernel() function, I've had to hack it
> >> so many times to force it to not build modules...
> >
> > We agree on this point - it should be possible as a cli and as a library
> > to run each build command separately.
> >
> > In the tuxmake readme, we have the following proposed to handle this
> > (from a cli point of view):
> >
> > tuxmake --targets kernel,selftests,htmldocs
> >
> > If --targets were specified, only those targets (and any dependent
> > targets) would be called. If --targets is not specified,
> > kernel+modules+dtbs (as applicable) would be built by default.
> >
> > Config itself is a special case which I have some ideas for, but are not
> > yet described in the readme.
> >
> >>
> >> About k8s, yes I agree a Python library should provide the
> >> required flexibility. It shouldn't need to have any "cloud"
> >> special features as it's just one use-case among many. The key
> >> thing is to provide just enough added value without turning it
> >> into a complete integration. I guess one could see the stack as
> >> follows:
> >>
> >>
> >> user
> >> ------------
> >> environment
> >> ------------
> >> tuxmake
> >> ------------
> >> make
> >> compiler
> >> kernel source code
> >>
> >>
> >> The "environment" can be a plain shell in a terminal, or in a
> >> Docker container, which may be managed by Kubernetes, which may
> >> have been started by Jenkins or Tekton or anything else. By
> >> keeping the environment as a higher-level entity in the stack we
> >> also keep the tool (tuxmake) generic.
> >
> > Either the environment needs to be aware of the tool, or the tool needs
> > to be aware of the environment. Right now, our container environments
> > are not generic because they have to have support for kci_build, for
> > example, built in (python, required python modules, even jenkins
> > requirements are leaking in). Someone else reusing the tools would have
> > to bake their own dependencies in, making the environments non-portable.
>
> What do you mean exactly by "our container environments"? Are
> they Docker containers used by LKFT?
>
> > Worse, I'm really trying to focus on the kernel developer use-cases, and
> > reproducing a kci_build today is non-trivial - largely because it's up
> > to the user to perform multiple steps to get a container running, get
> > their source code into the container, get kci_build into the container,
> > and rerun the kernelci build.
>
> That's right, kci_build is currently mostly designed to get
> integrated into an automated build pipeline using say, Jenkins or
> Gitlab CI. We all know that having a way to wrap that in a
> Docker call would make things easier for developers - and there's
> nothing really hard about it. We could for example have a "kci"
> higher-level command which would act as a shell-oriented
> integration to first pull a Docker image, then run some commands
> inside it. It could have one command for each step in a typical
> automated pipeline: build, test, report...
>
> > From a correctness point of view, a container that is designed to
> > provide an environment for a kernel build should *only* contain things
> > that are required by the kernel build itself.
>
> I'm sorry but I really don't get what you mean here. If you mean
> that the container should only have the dependencies to be able
> to run plain build commands such as "make defconfig && make",
> then how can you have any tool on top of that? Would it need to
> be merged in the upstream kernel build system to satisfy your
> criteria?
>
> The README says "Requirements: python 3.6+, docker", so you
> actually want to use Docker images but _still_ require users to
> install a particular version of Python outside the container, and
> tuxmake not depend on any other Python module?
>
> > I believe there's an opportunity here to provide a layer of abstraction
> > that makes build environments portable, and then builds themselves more
> > portable - making it easier for more developers to do more build
> > combinations more easily. Right now it's a hassle that every developer
> > has to solve for themselves (or just not solve it). And if a developer
> > finds a build problem, it may be difficult for another developer to
> > reproduce the problem if it's environmental.
>
> Sounds great, although I'm still struggling to understand how
> you're proposing to achieve that in practice.
>
> >>> We hope that this would be useful for kernelci and tuxbuild projects as
> >>> a library, but also for kernel engineers to be able to more easily
> >>> perform and reproduce a variety of builds locally using the cli.
> >>
> >> Err, do you want to call it tuxbuild or tuxmake? ;)
> >
> > tuxbuild is a commercial build service and tuxmake is an open source
> > build implementation. For what it's worth, I think kernelci should
> > consider using tuxbuild; it's designed to be highly scalable (thousands
> > of concurrent builds) and reliable, and would solve kernelci's build
> > capacity problems. LKFT has been using it in production since January
> > and it has reduced our build times dramatically.
>
> OK, makes more sense now that I've read this:
>
> https://pypi.org/project/tuxbuild/
>
> About using it in KernelCI, for sure there are lots of things we
> could do to improve our build efficiency. Being tied to a
> particular service is probably not going to play out well though,
> unless it's only an option when deploying instances (i.e. same as
> we use Jenkins and now Kubernetes but don't require them etc...).
>
> So assuming KernelCI could depend on tuxmake, and one possible
> way to run it was via tuxbuild, then that might work.
>
> Otherwise, importing tuxmake into kci_build would in theory be
> fine as long as tuxmake does cover our use-case in practice.
>
> >> I wonder if tuxmake would sound more like a lower-lavel "make"
> >> tool, such as Ninja or Meson. So tuxbuild is probably a bit
> >> clearer in that it's about facilitating builds (i.e. above
> >> the "make" layer in the stack...).
> >>
> >> You suggested to have a project under github.com/kernelci, which
> >> I believe probably makes more sense if we want KernelCI to
> >> provide a common set of tools for others to reuse (not being
> >> biased at all here). Or, we can do what I was trying to suggest
> >> in my previous email and have a new "namespace" for these tools
> >> that don't need to be associated with KernelCI, or LKFT or
> >> anything else.
> >
> > I don't think a new namespace is necessary. At this point, it's a Linaro
> > project so I've put it there. We can re-assess as necessary but I don't
> > think the location of the git repo is a critical factor at this point,
> > nor is it necessarily permanent.
>
> Right, sorry I was missing some background about tuxbuild.
>
> The git URL obviously has very little significance, but the
> organisation which has the destiny of the tool in its hands does.
> If it's under /linaro, it's a Linaro tool, and obviously it will
> at least appear to be designed for the very specific use-case
> that is tuxbuild and LKFT:
>
> https://gitlab.com/Linaro/lkft/ci-scripts/-/blob/master/branch-gitlab-ci.yml#L52
>
> >>>>> If there's wide agreement then we could establish such a repository and
> >>>>> start iterating on a design document. I have someone available to start
> >>>>> working on the actual implementation in a few weeks.
> >>>>>
> >>>>> There are other details to discuss, like how to deal with config (we had
> >>>>> to do a bit of a workaround for it outside of kci_build), licensing,
> >>>>> etc.
>
> To clarify one thing, have you completely stopped using kci_build
> with LKFT?
>
> >>>> I propose that we we dedicate one of our tuesday weekly calls to this
> >>>> topic. Would Tues, June 2nd work?
> >>>
> >>> I can make that work,
> >>
> >> Well, the main topic for that meeting is going to be to review
> >> the KernelCI plans for the next 3 months. You're welcome to join
> >> in any case, and if we don't spend too much time on the plan we
> >> may have time to discuss that. However, maybe we could aim for
> >> the 9th instead?
> >
> > I'm unavailable on the 9th and the 16th of June. Just ping me on irc
> > if it ends up on the agenda.
>
> OK let's catch up again by Monday at the latest.
>
> Thanks,
> Guillaume
>
> >>>> [1] https://github.com/kernelci/kernelci-core/pull/366/commits/4ec097537de61fa8a4f6de4fe9c1cf6b26f6ac04
> >>>> [2] https://tekton.dev/
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply
* [PATCH] image: android: fix abootimg support
From: Christian Gmeiner @ 2020-05-29 15:53 UTC (permalink / raw)
To: u-boot
abootimg creates images where all load addresses are 0.
Android Boot Image Info:
* file name = artifacts/fastboot.img
* image size = 31381504 bytes (29.93 MB)
page size = 2048 bytes
* Boot Name = ""
* kernel size = 9397406 bytes (8.96 MB)
ramdisk size = 21981144 bytes (20.96 MB)
* load addresses:
kernel: 0x00000000
ramdisk: 0x00000000
tags: 0x00000000
Without this fix we end in a data abort:
Booting kernel at 0x15000000...
* kernel: cmdline image address = 0x15000000
Kernel load addr 0x00000000 size 9178 KiB
Kernel command line: ip=dhcp console=ttymxc0,115200n8
kernel data at 0x15000800, len = 0x008f649e (9397406)
* ramdisk: cmdline image address = 0x15000000
RAM disk load addr 0x00000000 size 21473 KiB
ramdisk start = 0x158f7000, ramdisk end = 0x16def35c
kernel loaded at 0x00000000, end = 0x00000000
Loading Kernel Image
data abort
pc : [<8ff8c004>] lr : [<5d7ac70f>]
sp : 8f57ed64 ip : 48f17668 fp : 00000000
r10: 00000002 r9 : 8f58aed0 r8 : 03fa4c58
r7 : 5e842497 r6 : fbe73965 r5 : 7c459955 r4 : df020fde
r3 : 1b7aa45b r2 : 007f23fe r1 : 15104820 r0 : 00104000
Flags: nzCv IRQs off FIQs off Mode SVC_32 (T)
Code: f07c e8b1 51f8 3a20 (e8a0) 51f8
Resetting CPU ...
resetting ...
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
---
common/image-android.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/common/image-android.c b/common/image-android.c
index 6af9baa121..18f7c8db03 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -33,6 +33,13 @@ static ulong android_image_get_kernel_addr(const struct andr_img_hdr *hdr)
if (hdr->kernel_addr == ANDROID_IMAGE_DEFAULT_KERNEL_ADDR)
return (ulong)hdr + hdr->page_size;
+ /*
+ * abootimg creates images where all load addresses are 0
+ * and we need to fix them.
+ */
+ if (hdr->kernel_addr == 0 && hdr->ramdisk_addr == 0)
+ return env_get_ulong("kernel_addr_r", 16, 0);
+
return hdr->kernel_addr;
}
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v3 1/2] PCI: vmd: Filter resource type bits from shadow register
From: Derrick, Jonathan @ 2020-05-29 15:53 UTC (permalink / raw)
To: lorenzo.pieralisi@arm.com
Cc: hch@lst.de, linux-pci@vger.kernel.org,
virtualization@lists.linux-foundation.org, helgaas@kernel.org,
andrzej.jakowski@linux.intel.com, qemu-devel@nongnu.org,
alex.williamson@redhat.com
In-Reply-To: <20200529103315.GC12270@e121166-lin.cambridge.arm.com>
On Fri, 2020-05-29 at 11:33 +0100, Lorenzo Pieralisi wrote:
> On Wed, May 27, 2020 at 11:02:39PM -0400, Jon Derrick wrote:
> > Versions of VMD with the Host Physical Address shadow register use this
> > register to calculate the bus address offset needed to do guest
> > passthrough of the domain. This register shadows the Host Physical
> > Address registers including the resource type bits. After calculating
> > the offset, the extra resource type bits lead to the VMD resources being
> > over-provisioned at the front and under-provisioned at the back.
> >
> > Example:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit]
> >
> > Expected:
> > pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit]
> >
> > If other devices are mapped in the over-provisioned front, it could lead
> > to resource conflict issues with VMD or those devices.
> >
> > Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes")
> > Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> > ---
> > drivers/pci/controller/vmd.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Hi Jon,
>
> it looks like I can take this patch for v5.8 whereas patch 2 depends
> on the QEMU changes acceptance and should probably wait.
>
> Please let me know your thoughts asap and I will try to at least
> squeeze this patch in.
>
> Lorenzo
Hi Lorenzo,
This is fine. Please take Patch 1.
Patch 2 is harmless without the QEMU changes, but may always need a
different approach.
Best,
jon
>
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index dac91d6..e386d4e 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -445,9 +445,11 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> > if (!membar2)
> > return -ENOMEM;
> > offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
> > - readq(membar2 + MB2_SHADOW_OFFSET);
> > + (readq(membar2 + MB2_SHADOW_OFFSET) &
> > + PCI_BASE_ADDRESS_MEM_MASK);
> > offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
> > - readq(membar2 + MB2_SHADOW_OFFSET + 8);
> > + (readq(membar2 + MB2_SHADOW_OFFSET + 8) &
> > + PCI_BASE_ADDRESS_MEM_MASK);
> > pci_iounmap(vmd->dev, membar2);
> > }
> > }
> > --
> > 1.8.3.1
> >
^ permalink raw reply
* [GIT PULL] Ceph fixes for 5.7-rc8
From: Ilya Dryomov @ 2020-05-29 15:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ceph-devel, linux-kernel
Hi Linus,
The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145:
Linux 5.7-rc7 (2020-05-24 15:32:54 -0700)
are available in the Git repository at:
https://github.com/ceph/ceph-client.git tags/ceph-for-5.7-rc8
for you to fetch changes up to fb33c114d3ed5bdac230716f5b0a93b56b92a90d:
ceph: flush release queue when handling caps for unknown inode (2020-05-27 13:03:57 +0200)
----------------------------------------------------------------
Cache tiering and cap handling fixups, both marked for stable.
----------------------------------------------------------------
Jeff Layton (1):
ceph: flush release queue when handling caps for unknown inode
Jerry Lee (1):
libceph: ignore pool overlay and cache logic on redirects
fs/ceph/caps.c | 2 +-
net/ceph/osd_client.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports
From: Thomas Bogendoerfer @ 2020-05-29 15:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: Russell King - ARM Linux admin, David S. Miller, Jakub Kicinski,
netdev, linux-kernel
In-Reply-To: <20200529145928.GF869823@lunn.ch>
On Fri, 29 May 2020 16:59:28 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> On Fri, May 29, 2020 at 01:05:39PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 28 May 2020 23:04:20 +0100
> > Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:
> >
> > > Can you explain this please? Just as we think we understand what's
> > > going on here, you throw in a new comment that makes us confused.
> >
> > sorry about that.
> >
> > > You said previously that the mvpp2 was connected to a switch, which
> > > makes us think that you've got some DSA-like setup going on here.
> > > Does your switch drop its serdes link when all the external links
> > > (presumably the 10G SFP+ cages) fail?
> > >
> > > Both Andrew and myself wish to have a complete picture before we
> > > move forward with this.
> >
> > full understandable, I'll try by a small picture, which just
> > covers one switch:
> >
> > external ports
> > | | | |
> > *-----------------------------*
> > | 1 1 2 2 |
> > | |
> > | switch |
> > | |
> > | 1 2 1 2 |
> > *-----------------------------*
> > | | | |
> > | | | |
> > *----------* *----------*
> > | 1 2 | | 1 2 |
> > | | | |
> > | node 1 | ... | node 8 |
> > | | | |
> > *----------* *----------*
> >
> > External ports a grouped in ports to network 1 and network 2. If one of the
> > external ports has an established link, this link state will be propagated
> > to the internal ports. Same when both external ports of a network are down.
>
> By propagated, you mean if the external link is down, the link between
> the switch and node 1 will also be forced down, at the SERDES level?
yes
> And if external ports are down, the nodes cannot talk to each other?
correct
> External link down causes the whole in box network to fall apart? That
> seems a rather odd design.
as I'm not an expert in ceph, I can't judge. But I'll bring it up.
> > I have no control over the software running on the switch, therefore I can't
> > enable autoneg on the internal links.
>
> O.K. So that means using in-band signalling in DT is clearly
> wrong. There is no signalling....
>
> What you are actually interested in is the sync state of the SERDES?
> The link is up if the SERDES has sync.
yes, that's what I need. How can I do that ?
Thomas.
--
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
^ permalink raw reply
* Re: [Intel-gfx] [RFC PATCH 1/1] drm/mm: add ig_frag selftest
From: Chris Wilson @ 2020-05-29 15:52 UTC (permalink / raw)
To: Nirmoy, Nirmoy Das, dri-devel; +Cc: intel-gfx, Nirmoy Das, christian.koenig
In-Reply-To: <cdb604b7-0817-c786-45f6-3c2f9a395c70@amd.com>
Quoting Nirmoy (2020-05-29 16:40:53)
> This works correctly most of the times but sometimes
>
> 20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
> Regards,
>
> Nirmoy
>
> On 5/29/20 6:33 PM, Nirmoy Das wrote:
> > This patch introduces fragmentation in the address range
> > and measures time taken by 10k and 20k insertions. ig_frag()
> > will fail if time taken by 20k insertions takes more than 4 times
> > of 10k insertions as we know that insertions scale quadratically.
> > Also tolerate 10% error because of kernel scheduler's jitters.
> >
> > Output:
> > <snip>
> > [ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
> > [ 8092.653520] drm_mm: igt_sanitycheck - ok!
> > [ 8092.653525] igt_debug 0x0000000000000000-0x0000000000000200: 512: free
> > [ 8092.653526] igt_debug 0x0000000000000200-0x0000000000000600: 1024: used
> > [ 8092.653527] igt_debug 0x0000000000000600-0x0000000000000a00: 1024: free
> > [ 8092.653528] igt_debug 0x0000000000000a00-0x0000000000000e00: 1024: used
> > [ 8092.653529] igt_debug 0x0000000000000e00-0x0000000000001000: 512: free
> > [ 8092.653529] igt_debug total: 4096, used 2048 free 2048
> > [ 8112.569813] drm_mm: best fragmented insert of 10000 and 20000 insertions took 504 and 1996 msecs
> > [ 8112.723254] drm_mm: bottom-up fragmented insert of 10000 and 20000 insertions took 44 and 108 msecs
> > [ 8112.813212] drm_mm: top-down fragmented insert of 10000 and 20000 insertions took 40 and 44 msecs
> > [ 8112.847733] drm_mm: evict fragmented insert of 10000 and 20000 insertions took 8 and 20 msecs
> > <snip>
> >
> > Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> > ---
> > drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
> > drivers/gpu/drm/selftests/test-drm_mm.c | 73 ++++++++++++++++++++
> > 2 files changed, 74 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > index 6b943ea1c57d..8c87c964176b 100644
> > --- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > +++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > @@ -14,6 +14,7 @@ selftest(insert, igt_insert)
> > selftest(replace, igt_replace)
> > selftest(insert_range, igt_insert_range)
> > selftest(align, igt_align)
> > +selftest(frag, igt_frag)
> > selftest(align32, igt_align32)
> > selftest(align64, igt_align64)
> > selftest(evict, igt_evict)
> > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
> > index 9aabe82dcd3a..05d8f3659b4d 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_mm.c
> > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
> > @@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
> > return 0;
> > }
> >
> > +static int get_insert_time(unsigned int num_insert,
> > + const struct insert_mode *mode)
> > +{
> > + struct drm_mm mm;
> > + struct drm_mm_node *nodes, *node, *next;
> > + unsigned int size = 4096, align = 8192;
> > + unsigned long start;
> > + unsigned int i;
> > + int ret = -EINVAL;
> > +
> > + drm_mm_init(&mm, 1, U64_MAX - 2);
> > + nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
> > + if (!nodes)
> > + goto err;
> > +
> > + start = jiffies;
Use ktime_t start = ktime_now();
> > + for (i = 0; i < num_insert; i++) {
> > + if (!expect_insert(&mm, &nodes[i], size, align, i, mode)) {
> > + pr_err("%s insert failed\n", mode->name);
> > + goto out;
> > + }
> > + }
> > +
> > + ret = jiffies_to_msecs(jiffies - start);
ret = ktime_sub(ktime_now(), start);
The downside to using ktime is remembering it is s64 and so requires care
and attention in doing math.
> > +out:
> > + drm_mm_for_each_node_safe(node, next, &mm)
> > + drm_mm_remove_node(node);
> > + drm_mm_takedown(&mm);
> > + vfree(nodes);
> > +err:
> > + return ret;
> > +
> > +}
> > +
> > +static int igt_frag(void *ignored)
> > +{
> > + const struct insert_mode *mode;
> > + unsigned int insert_time1, insert_time2;
> > + unsigned int insert_size = 10000;
> > + unsigned int scale_factor = 4;
> > + /* tolerate 10% excess insertion duration */
> > + unsigned int error_factor = 110;
> > + int ret = -EINVAL;
> > +
> > + for (mode = insert_modes; mode->name; mode++) {
> > + unsigned int expected_time;
> > +
> > + insert_time1 = get_insert_time(insert_size, mode);
> > + if (insert_time1 < 0)
> > + goto err;
Ah, can you propagate the actual error. I see you are returning EINVAL
for ENOMEM errors. Just wait until it hits and you have to debug why :)
> > + insert_time2 = get_insert_time((insert_size * 2), mode);
> > + if (insert_time2 < 0)
> > + goto err;
> > +
> > + expected_time = (scale_factor * insert_time1 *
> > + error_factor)/100;
> > + if (insert_time2 > expected_time) {
> > + pr_err("%s fragmented insert took more %u msecs\n",
> > + mode->name, insert_time2 - expected_time);
> > + goto err;
> > + }
> > +
> > + pr_info("%s fragmented insert of %u and %u insertions took %u and %u msecs\n",
> > + mode->name, insert_size, insert_size * 2, insert_time1,
> > + insert_time2);
Put the info first before the error. We always want the full details,
with the error message explaining why it's unhappy.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [RFC PATCH 1/1] drm/mm: add ig_frag selftest
From: Chris Wilson @ 2020-05-29 15:52 UTC (permalink / raw)
To: Nirmoy, Nirmoy Das, dri-devel; +Cc: intel-gfx, Nirmoy Das, christian.koenig
In-Reply-To: <cdb604b7-0817-c786-45f6-3c2f9a395c70@amd.com>
Quoting Nirmoy (2020-05-29 16:40:53)
> This works correctly most of the times but sometimes
>
> 20k insertions can take more than 8 times of 10k insertion time.
The pressure is on to improve then :)
> Regards,
>
> Nirmoy
>
> On 5/29/20 6:33 PM, Nirmoy Das wrote:
> > This patch introduces fragmentation in the address range
> > and measures time taken by 10k and 20k insertions. ig_frag()
> > will fail if time taken by 20k insertions takes more than 4 times
> > of 10k insertions as we know that insertions scale quadratically.
> > Also tolerate 10% error because of kernel scheduler's jitters.
> >
> > Output:
> > <snip>
> > [ 8092.653518] drm_mm: Testing DRM range manger (struct drm_mm), with random_seed=0x9bfb4117 max_iterations=8192 max_prime=128
> > [ 8092.653520] drm_mm: igt_sanitycheck - ok!
> > [ 8092.653525] igt_debug 0x0000000000000000-0x0000000000000200: 512: free
> > [ 8092.653526] igt_debug 0x0000000000000200-0x0000000000000600: 1024: used
> > [ 8092.653527] igt_debug 0x0000000000000600-0x0000000000000a00: 1024: free
> > [ 8092.653528] igt_debug 0x0000000000000a00-0x0000000000000e00: 1024: used
> > [ 8092.653529] igt_debug 0x0000000000000e00-0x0000000000001000: 512: free
> > [ 8092.653529] igt_debug total: 4096, used 2048 free 2048
> > [ 8112.569813] drm_mm: best fragmented insert of 10000 and 20000 insertions took 504 and 1996 msecs
> > [ 8112.723254] drm_mm: bottom-up fragmented insert of 10000 and 20000 insertions took 44 and 108 msecs
> > [ 8112.813212] drm_mm: top-down fragmented insert of 10000 and 20000 insertions took 40 and 44 msecs
> > [ 8112.847733] drm_mm: evict fragmented insert of 10000 and 20000 insertions took 8 and 20 msecs
> > <snip>
> >
> > Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
> > ---
> > drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
> > drivers/gpu/drm/selftests/test-drm_mm.c | 73 ++++++++++++++++++++
> > 2 files changed, 74 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > index 6b943ea1c57d..8c87c964176b 100644
> > --- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > +++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
> > @@ -14,6 +14,7 @@ selftest(insert, igt_insert)
> > selftest(replace, igt_replace)
> > selftest(insert_range, igt_insert_range)
> > selftest(align, igt_align)
> > +selftest(frag, igt_frag)
> > selftest(align32, igt_align32)
> > selftest(align64, igt_align64)
> > selftest(evict, igt_evict)
> > diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c
> > index 9aabe82dcd3a..05d8f3659b4d 100644
> > --- a/drivers/gpu/drm/selftests/test-drm_mm.c
> > +++ b/drivers/gpu/drm/selftests/test-drm_mm.c
> > @@ -1033,6 +1033,79 @@ static int igt_insert_range(void *ignored)
> > return 0;
> > }
> >
> > +static int get_insert_time(unsigned int num_insert,
> > + const struct insert_mode *mode)
> > +{
> > + struct drm_mm mm;
> > + struct drm_mm_node *nodes, *node, *next;
> > + unsigned int size = 4096, align = 8192;
> > + unsigned long start;
> > + unsigned int i;
> > + int ret = -EINVAL;
> > +
> > + drm_mm_init(&mm, 1, U64_MAX - 2);
> > + nodes = vzalloc(array_size(num_insert, sizeof(*nodes)));
> > + if (!nodes)
> > + goto err;
> > +
> > + start = jiffies;
Use ktime_t start = ktime_now();
> > + for (i = 0; i < num_insert; i++) {
> > + if (!expect_insert(&mm, &nodes[i], size, align, i, mode)) {
> > + pr_err("%s insert failed\n", mode->name);
> > + goto out;
> > + }
> > + }
> > +
> > + ret = jiffies_to_msecs(jiffies - start);
ret = ktime_sub(ktime_now(), start);
The downside to using ktime is remembering it is s64 and so requires care
and attention in doing math.
> > +out:
> > + drm_mm_for_each_node_safe(node, next, &mm)
> > + drm_mm_remove_node(node);
> > + drm_mm_takedown(&mm);
> > + vfree(nodes);
> > +err:
> > + return ret;
> > +
> > +}
> > +
> > +static int igt_frag(void *ignored)
> > +{
> > + const struct insert_mode *mode;
> > + unsigned int insert_time1, insert_time2;
> > + unsigned int insert_size = 10000;
> > + unsigned int scale_factor = 4;
> > + /* tolerate 10% excess insertion duration */
> > + unsigned int error_factor = 110;
> > + int ret = -EINVAL;
> > +
> > + for (mode = insert_modes; mode->name; mode++) {
> > + unsigned int expected_time;
> > +
> > + insert_time1 = get_insert_time(insert_size, mode);
> > + if (insert_time1 < 0)
> > + goto err;
Ah, can you propagate the actual error. I see you are returning EINVAL
for ENOMEM errors. Just wait until it hits and you have to debug why :)
> > + insert_time2 = get_insert_time((insert_size * 2), mode);
> > + if (insert_time2 < 0)
> > + goto err;
> > +
> > + expected_time = (scale_factor * insert_time1 *
> > + error_factor)/100;
> > + if (insert_time2 > expected_time) {
> > + pr_err("%s fragmented insert took more %u msecs\n",
> > + mode->name, insert_time2 - expected_time);
> > + goto err;
> > + }
> > +
> > + pr_info("%s fragmented insert of %u and %u insertions took %u and %u msecs\n",
> > + mode->name, insert_size, insert_size * 2, insert_time1,
> > + insert_time2);
Put the info first before the error. We always want the full details,
with the error message explaining why it's unhappy.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v4 06/11] thermal: Add mode helpers
From: Guenter Roeck @ 2020-05-29 15:52 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip,
Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team, Darren Hart, Zhang Rui,
Gayatri Kammela, Len Brown, Johannes Berg, Intel Linux Wireless,
Sascha Hauer, Ido Schimmel, Baolin Wang, Jiri Pirko, Orson Zhai,
Thomas Gleixner, Kalle Valo, Support Opensource, Enrico Weigelt,
Peter Kaestle, Sebastian Reichel, Bartlomiej Zolnierkiewicz,
Pengutronix Kernel Team, Niklas Söderlund, Shawn Guo,
David S . Miller, Andy Shevchenko
On Thu, May 28, 2020 at 09:20:46PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for making the drivers not access tzd's private members.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
> drivers/thermal/thermal_core.c | 53 ++++++++++++++++++++++++++++++++++
> include/linux/thermal.h | 13 +++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 14d3b1b94c4f..f2a5c5ee3455 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -459,6 +459,59 @@ static void thermal_zone_device_reset(struct thermal_zone_device *tz)
> thermal_zone_device_init(tz);
> }
>
> +int thermal_zone_device_set_mode(struct thermal_zone_device *tz,
> + enum thermal_device_mode mode)
> +{
> + int ret = 0;
> +
> + mutex_lock(&tz->lock);
> +
> + /* do nothing if mode isn't changing */
> + if (mode == tz->mode) {
> + mutex_unlock(&tz->lock);
> +
Nit: unnecessary empty line.
> + return ret;
> + }
> +
> + if (tz->ops->set_mode)
> + ret = tz->ops->set_mode(tz, mode);
> +
> + if (!ret)
> + tz->mode = mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
> +
> + return ret;
> +}
> +
> +int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_ENABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_enable);
Other exports in thermal/ use EXPORT_SYMBOL_GPL.
> +
> +int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_DISABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_disable);
> +
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{
> + enum thermal_device_mode mode;
> +
> + mutex_lock(&tz->lock);
> +
> + mode = tz->mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + return mode == THERMAL_DEVICE_ENABLED;
> +}
> +EXPORT_SYMBOL(thermal_zone_device_is_enabled);
> +
> void thermal_zone_device_update(struct thermal_zone_device *tz,
> enum thermal_notify_event event)
> {
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a808f6fa2777..df013c39ba9b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -416,6 +416,9 @@ int thermal_zone_get_offset(struct thermal_zone_device *tz);
>
> void thermal_cdev_update(struct thermal_cooling_device *);
> void thermal_notify_framework(struct thermal_zone_device *, int);
> +int thermal_zone_device_enable(struct thermal_zone_device *tz);
> +int thermal_zone_device_disable(struct thermal_zone_device *tz);
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz);
> #else
> static inline struct thermal_zone_device *thermal_zone_device_register(
> const char *type, int trips, int mask, void *devdata,
> @@ -463,6 +466,16 @@ static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
> static inline void thermal_notify_framework(struct thermal_zone_device *tz,
> int trip)
> { }
> +
> +static inline int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int
> +thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> #endif /* CONFIG_THERMAL */
>
> #endif /* __THERMAL_H__ */
^ permalink raw reply
* Re: [PATCH v4 06/11] thermal: Add mode helpers
From: Guenter Roeck @ 2020-05-29 15:52 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: linux-pm, linux-acpi, netdev, linux-wireless, platform-driver-x86,
linux-arm-kernel, linux-renesas-soc, linux-rockchip,
Emmanuel Grumbach, Heiko Stuebner, Rafael J . Wysocki,
Vishal Kulkarni, Luca Coelho, Miquel Raynal, kernel,
Fabio Estevam, Amit Kucheria, Chunyan Zhang, Daniel Lezcano,
Allison Randal, NXP Linux Team
On Thu, May 28, 2020 at 09:20:46PM +0200, Andrzej Pietrasiewicz wrote:
> Prepare for making the drivers not access tzd's private members.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> ---
> drivers/thermal/thermal_core.c | 53 ++++++++++++++++++++++++++++++++++
> include/linux/thermal.h | 13 +++++++++
> 2 files changed, 66 insertions(+)
>
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 14d3b1b94c4f..f2a5c5ee3455 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -459,6 +459,59 @@ static void thermal_zone_device_reset(struct thermal_zone_device *tz)
> thermal_zone_device_init(tz);
> }
>
> +int thermal_zone_device_set_mode(struct thermal_zone_device *tz,
> + enum thermal_device_mode mode)
> +{
> + int ret = 0;
> +
> + mutex_lock(&tz->lock);
> +
> + /* do nothing if mode isn't changing */
> + if (mode == tz->mode) {
> + mutex_unlock(&tz->lock);
> +
Nit: unnecessary empty line.
> + return ret;
> + }
> +
> + if (tz->ops->set_mode)
> + ret = tz->ops->set_mode(tz, mode);
> +
> + if (!ret)
> + tz->mode = mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED);
> +
> + return ret;
> +}
> +
> +int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_ENABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_enable);
Other exports in thermal/ use EXPORT_SYMBOL_GPL.
> +
> +int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{
> + return thermal_zone_device_set_mode(tz, THERMAL_DEVICE_DISABLED);
> +}
> +EXPORT_SYMBOL(thermal_zone_device_disable);
> +
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{
> + enum thermal_device_mode mode;
> +
> + mutex_lock(&tz->lock);
> +
> + mode = tz->mode;
> +
> + mutex_unlock(&tz->lock);
> +
> + return mode == THERMAL_DEVICE_ENABLED;
> +}
> +EXPORT_SYMBOL(thermal_zone_device_is_enabled);
> +
> void thermal_zone_device_update(struct thermal_zone_device *tz,
> enum thermal_notify_event event)
> {
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index a808f6fa2777..df013c39ba9b 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -416,6 +416,9 @@ int thermal_zone_get_offset(struct thermal_zone_device *tz);
>
> void thermal_cdev_update(struct thermal_cooling_device *);
> void thermal_notify_framework(struct thermal_zone_device *, int);
> +int thermal_zone_device_enable(struct thermal_zone_device *tz);
> +int thermal_zone_device_disable(struct thermal_zone_device *tz);
> +int thermal_zone_device_is_enabled(struct thermal_zone_device *tz);
> #else
> static inline struct thermal_zone_device *thermal_zone_device_register(
> const char *type, int trips, int mask, void *devdata,
> @@ -463,6 +466,16 @@ static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
> static inline void thermal_notify_framework(struct thermal_zone_device *tz,
> int trip)
> { }
> +
> +static inline int thermal_zone_device_enable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int thermal_zone_device_disable(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> +
> +static inline int
> +thermal_zone_device_is_enabled(struct thermal_zone_device *tz)
> +{ return -ENODEV; }
> #endif /* CONFIG_THERMAL */
>
> #endif /* __THERMAL_H__ */
^ permalink raw reply
* [linux-next:master 6204/13554] arch/powerpc/platforms/cell/spufs/coredump.c:124:11: warning: comparison of unsigned expression < 0 is always false
From: kbuild test robot @ 2020-05-29 15:51 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: ff387fc20c697cdc887b2abf7ef494e853795a2f
commit: 5456ffdee666c66e27ccc1006f9afe83ad55559f [6204/13554] powerpc/spufs: simplify spufs core dumping
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-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
git checkout 5456ffdee666c66e27ccc1006f9afe83ad55559f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
arch/powerpc/platforms/cell/spufs/coredump.c: In function 'spufs_arch_write_note':
>> arch/powerpc/platforms/cell/spufs/coredump.c:124:11: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
124 | if (ret < 0)
| ^
vim +124 arch/powerpc/platforms/cell/spufs/coredump.c
101
102 static int spufs_arch_write_note(struct spu_context *ctx, int i,
103 struct coredump_params *cprm, int dfd)
104 {
105 size_t sz = spufs_coredump_read[i].size;
106 char fullname[80];
107 struct elf_note en;
108 size_t ret;
109
110 sprintf(fullname, "SPU/%d/%s", dfd, spufs_coredump_read[i].name);
111 en.n_namesz = strlen(fullname) + 1;
112 en.n_descsz = sz;
113 en.n_type = NT_SPU;
114
115 if (!dump_emit(cprm, &en, sizeof(en)))
116 return -EIO;
117 if (!dump_emit(cprm, fullname, en.n_namesz))
118 return -EIO;
119 if (!dump_align(cprm, 4))
120 return -EIO;
121
122 if (spufs_coredump_read[i].dump) {
123 ret = spufs_coredump_read[i].dump(ctx, cprm);
> 124 if (ret < 0)
125 return ret;
126 } else {
127 char buf[32];
128
129 ret = snprintf(buf, sizeof(buf), "0x%.16llx",
130 spufs_coredump_read[i].get(ctx));
131 if (ret >= sizeof(buf))
132 return sizeof(buf);
133
134 /* count trailing the NULL: */
135 if (!dump_emit(cprm, buf, ret + 1))
136 return -EIO;
137 }
138
139 if (!dump_skip(cprm, roundup(cprm->pos - ret + sz, 4) - cprm->pos))
140 return -EIO;
141 return 0;
142 }
143
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 66050 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support
From: Anthony PERARD @ 2020-05-29 15:51 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andrew Cooper, Roger Pau Monné, Wei Liu, Xen-devel
In-Reply-To: <c3c3aea0-806f-4058-c1aa-cdc0f75007e2@suse.com>
On Fri, May 29, 2020 at 01:59:55PM +0200, Jan Beulich wrote:
> On 28.05.2020 20:10, Andrew Cooper wrote:
> > On 28/05/2020 11:25, Jan Beulich wrote:
> >> On 27.05.2020 21:18, Andrew Cooper wrote:
> >>> --- a/xen/scripts/Kconfig.include
> >>> +++ b/xen/scripts/Kconfig.include
> >>> @@ -31,6 +31,10 @@ cc-option = $(success,$(CC) -Werror $(CLANG_FLAGS) $(1) -E -x c /dev/null -o /de
> >>> # Return y if the linker supports <flag>, n otherwise
> >>> ld-option = $(success,$(LD) -v $(1))
> >>>
> >>> +# $(as-instr,<instr>)
> >>> +# Return y if the assembler supports <instr>, n otherwise
> >>> +as-instr = $(success,printf "%b\n" "$(1)" | $(CC) $(CLANG_FLAGS) -c -x assembler -o /dev/null -)
> >> Is this actually checking the right thing in the clang case?
> >
> > Appears to work correctly for me. (Again, its either fine, or need
> > bugfixing anyway for 4.14, and raising with Linux as this is unmodified
> > upstream code like the rest of Kconfig.include).
>
> This answer made me try it out: On a system with clang 5 and
> binutils 2.32 "incsspd %eax" translates fine with
> -no-integrated-as but doesn't without. The previously mentioned
> odd use of CLANG_FLAGS, perhaps together with the disconnect
> from where we establish whether to use -no-integrated-as in the
> first place (arch.mk; I have no idea whether the CFLAGS
> determined would be usable by the kconfig invocation, nor how
> to solve the chicken-and-egg problem there if this is meant to
> work that way), may be the reason for this. Cc-ing Anthony once
> again ...
I've just prepare/sent a patch which should fix this CLANG_FLAGS issue
and allows to tests the assembler in Kconfig.
See: [XEN PATCH] xen/build: introduce CLANG_FLAGS for testing other CFLAGS
--
Anthony PERARD
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.