Re: [PATCH v17 5/9] mm: hugetlb: set the PageHWPoison to the raw error page
On Thu, Feb 25, 2021 at 09:21:26PM +0800, Muchun Song wrote: > Because we reuse the first tail vmemmap page frame and remap it > with read-only, we cannot set the PageHWPosion on some tail pages. > So we can use the head[4].private (There are at least 128 struct > page structures associated with the optimized HugeTLB page, so > using head[4].private is safe) to record the real error page index > and set the raw error page PageHWPoison later. > Does the hardcoding of 4 come from HUGETLB_CGROUP_MIN_ORDER, if so do we need to hardcode 4? Also, I am not sure about the comment on safety and 128 struct pages Balbir
Re: [PATCH v3 0/4] ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 companion codec
On Sat, 06 Mar 2021 12:19:30 +0100, Vitaly Rodionov wrote: > > Dell's laptops Inspiron 3500, Inspiron 3501, Inspiron 3505 are using > Cirrus Logic CS8409 HDA bridge with CS42L42 companion codec. > > The CS8409 is a multichannel HD audio routing controller. > CS8409 includes support for four channels of digital > microphone data and two bidirectional ASPs for up to 32 > channels of TDM data or 4 channels of I2S data. The CS8409 is > intended to be used with a remote companion codec that implements > high performance analog functions in close physical > proximity to the end-equipment audio port or speaker driver. > > The CS42L42 is a low-power audio codec with integrated MIPI > SoundWire interface or I2C/I2S/TDM interfaces designed > for portable applications. It provides a high-dynamic range, > stereo DAC for audio playback and a mono high-dynamic-range > ADC for audio capture > > Changes since version 1: > > ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 > * No change > > ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 > companion codec. > * Removed redundant fields in fixup table > * Handle gpio via spec->gpio_dir, spec->gpio_data and spec->gpio_mask > * Moved cs8409_cs42l42_init() from patch 2, to handle resume correctly > > ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 > companion codec. > * Run scripts/checkpatch.pl, fixed new warnings > > ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control > * Moved control values to cache to avoid i2c read at each time. > > Stefan Binding (1): > ALSA: hda/cirrus: Add Headphone and Headset MIC Volume Control > > Vitaly Rodionov (3): > ALSA: hda/cirrus: Increase AUTO_CFG_MAX_INS from 8 to 18 > ALSA: hda/cirrus: Add support for CS8409 HDA bridge and CS42L42 > companion codec. > ALSA: hda/cirrus: Add jack detect interrupt support from CS42L42 > companion codec. Applied all four patches now. Thanks. Takashi
Re: qemu meltdown test failure was Re: [PATCH 4.4 00/30] 4.4.260-rc1 review
Hi! > > > Ok, so we ran some tests. > > > > > > And they failed: > > > > > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/jobs/1075959449 > > > > > > [ 26.785861] > > RESULT=fail> > > > Received signal: TEST_CASE_ID=CVE-2018-3639 RESULT=fail > > > > > > Testcase name is spectre-meltdown-checker... Failing on qemu? Somehow > > > strange, but it looks like real test failure. This is pointer to the pipeline: https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/265992696 > First let me try 7d472e4a11d6a2fb1c492b02c7d7dacd3297bbf4 -- > v4.4.257-cip54. That is > https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266532179 > ... Qemu is OKAY. > > add3ff3730919447a7519fede0b8554132e0f8d5 Merge remote-tracking branch > 'stable/queue/4.4' in to v4.4.260-bisect. Results will be at > https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266534478 > ... ... still pending. Qemu is okay here, too. > test 266539168 8c461bb103f89696576945ad9cb376df34fa9d28 xen-netback: > respect gnttab_map_refs()'s return value Qemu is ok. > test 266538760 1efe86b456816c95485c65cf9ba46a5bff8a241e staging: > fwserial: Fix error handling in fwserial_create Qemu is ok. > test 266539768 8b4bc0f97fdd13b08c2436aad01bd4515d07f93a iwlwifi: pcie: > fix to correct null check Pavel Qemu is ok. https://gitlab.com/cip-project/cip-kernel/linux-cip/-/pipelines/266539768 So... failure apparently went away when trying to bisect. That's strange? Aha, except that it looks like the same "suceeded" tests still have failures in them: https://lava.ciplatform.org/scheduler/job/173186 [ 26.224557] Received signal: TEST_CASE_ID=CVE-2017-5715 RESULT=fail ...I guess those fails are expected, then? And qemu tests on -stable-rc are really failing on timeouts. ... Hmm, let's just re-run the tests. I'm still not sure, but it looks like a test failure now. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: Digital signature
Re: [PATCH] net: mellanox: mlxsw: fix error return code of mlxsw_sp_router_nve_promote_decap()
On Sat, Mar 06, 2021 at 03:32:39PM +0100, Heiner Kallweit wrote:
> On 06.03.2021 15:07, Jia-Ju Bai wrote:
> > When fib_entry is NULL, no error return code of
> > mlxsw_sp_router_nve_promote_decap() is assigned.
> > To fix this bug, err is assigned with -EINVAL in this case.
> >
> Again, are you sure this is a bug? To me it looks like it is
> intentional to not return an error code if fib_entry is NULL.
> Please don't blindly trust the robot results, there may
> always be false positives.
Yes, it is OK not to return an error. There is even a comment above the
call to mlxsw_sp_router_ip2me_fib_entry_find():
/* It is valid to create a tunnel with a local IP and only later
* assign this IP address to a local interface
*/
>
> > Reported-by: TOTE Robot
> > Signed-off-by: Jia-Ju Bai
> > ---
> > drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > index 9ce90841f92d..7b260e25df1b 100644
> > --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
> > @@ -1981,8 +1981,10 @@ int mlxsw_sp_router_nve_promote_decap(struct
> > mlxsw_sp *mlxsw_sp, u32 ul_tb_id,
> > fib_entry = mlxsw_sp_router_ip2me_fib_entry_find(mlxsw_sp, ul_tb_id,
> > ul_proto, ul_sip,
> > type);
> > - if (!fib_entry)
> > + if (!fib_entry) {
> > + err = -EINVAL;
> > goto out;
> > + }
> >
> > fib_entry->decap.tunnel_index = tunnel_index;
> > fib_entry->type = MLXSW_SP_FIB_ENTRY_TYPE_NVE_DECAP;
> >
>
[PATCH] ti: wlcore: fix error return code of wl1271_cmd_build_ps_poll()
When ieee80211_pspoll_get() returns NULL to skb, no error return code of
wl1271_cmd_build_ps_poll() is assigned.
To fix this bug, ret is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/wireless/ti/wlcore/cmd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
index 32a2e27cc561..7bf8b8201fdd 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -1120,8 +1120,10 @@ int wl1271_cmd_build_ps_poll(struct wl1271 *wl, struct
wl12xx_vif *wlvif,
int ret = 0;
skb = ieee80211_pspoll_get(wl->hw, vif);
- if (!skb)
+ if (!skb) {
+ ret = -ENOMEM;
goto out;
+ }
ret = wl1271_cmd_template_set(wl, wlvif->role_id,
CMD_TEMPL_PS_POLL, skb->data,
--
2.17.1
[PATCH] rsi: fix error return code of rsi_load_9116_firmware()
When kmemdup() returns NULL to ta_firmware, no error return code of
rsi_load_9116_firmware() is assigned.
To fix this bug, status is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/wireless/rsi/rsi_91x_hal.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c
b/drivers/net/wireless/rsi/rsi_91x_hal.c
index ce9892152f4d..32ecb8b3d6c5 100644
--- a/drivers/net/wireless/rsi/rsi_91x_hal.c
+++ b/drivers/net/wireless/rsi/rsi_91x_hal.c
@@ -1038,8 +1038,10 @@ static int rsi_load_9116_firmware(struct rsi_hw *adapter)
}
ta_firmware = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
- if (!ta_firmware)
+ if (!ta_firmware) {
+ status = -ENOMEM;
goto fail_release_fw;
+ }
fw_p = ta_firmware;
instructions_sz = fw_entry->size;
rsi_dbg(INFO_ZONE, "FW Length = %d bytes\n", instructions_sz);
--
2.17.1
Re: [PATCH] platform/x86: intel_pmc: Ignore GBE LTR on Tiger Lake platforms
On 3/5/2021 21:06, David E. Box wrote:
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle. Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.
Signed-off-by: David E. Box
Reviewed-by: Sasha Neftin
Cc: intel-wired-...@lists.osuosl.org
---
drivers/platform/x86/intel_pmc_core.c | 55 ---
1 file changed, 42 insertions(+), 13 deletions(-)
diff --git a/drivers/platform/x86/intel_pmc_core.c
b/drivers/platform/x86/intel_pmc_core.c
index ee2f757515b0..ab31eb646a1a 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -863,34 +863,45 @@ static int pmc_core_pll_show(struct seq_file *s, void
*unused)
}
DEFINE_SHOW_ATTRIBUTE(pmc_core_pll);
-static ssize_t pmc_core_ltr_ignore_write(struct file *file,
-const char __user *userbuf,
-size_t count, loff_t *ppos)
+static int pmc_core_write_ltr_ignore(u32 value)
{
struct pmc_dev *pmcdev = &pmc;
const struct pmc_reg_map *map = pmcdev->map;
- u32 val, buf_size, fd;
- int err;
-
- buf_size = count < 64 ? count : 64;
-
- err = kstrtou32_from_user(userbuf, buf_size, 10, &val);
- if (err)
- return err;
+ u32 fd;
+ int err = 0;
mutex_lock(&pmcdev->lock);
- if (val > map->ltr_ignore_max) {
+ if (fls(value) > map->ltr_ignore_max) {
err = -EINVAL;
goto out_unlock;
}
fd = pmc_core_reg_read(pmcdev, map->ltr_ignore_offset);
- fd |= (1U << val);
+ fd |= value;
pmc_core_reg_write(pmcdev, map->ltr_ignore_offset, fd);
out_unlock:
mutex_unlock(&pmcdev->lock);
+
+ return err;
+}
+
+static ssize_t pmc_core_ltr_ignore_write(struct file *file,
+const char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+ u32 buf_size, val;
+ int err;
+
+ buf_size = count < 64 ? count : 64;
+
+ err = kstrtou32_from_user(userbuf, buf_size, 10, &val);
+ if (err)
+ return err;
+
+ err = pmc_core_write_ltr_ignore(1U << val);
+
return err == 0 ? count : err;
}
@@ -1189,6 +1200,15 @@ static int quirk_xtal_ignore(const struct dmi_system_id *id)
return 0;
}
+static int quirk_ltr_ignore(u32 val)
+{
+ int err;
+
+ err = pmc_core_write_ltr_ignore(val);
+
+ return err;
+}
+
static const struct dmi_system_id pmc_core_dmi_table[] = {
{
.callback = quirk_xtal_ignore,
@@ -1244,6 +1264,15 @@ static int pmc_core_probe(struct platform_device *pdev)
pmcdev->pmc_xram_read_bit = pmc_core_check_read_lock_bit();
dmi_check_system(pmc_core_dmi_table);
+ /*
+* On TGL, due to a hardware limitation, the GBE LTR blocks PC10 when
+* a cable is attached. Tell the PMC to ignore it.
+*/
+ if (pmcdev->map == &tgl_reg_map) {
I would suggest: if (pmcdev->map >= &tgl_reg_map)
+ dev_dbg(&pdev->dev, "ignoring GBE LTR\n");
+ quirk_ltr_ignore(1U << 3);
+ }
+
pmc_core_dbgfs_register(pmcdev);
device_initialized = true;
Re: [External] Re: [PATCH v17 5/9] mm: hugetlb: set the PageHWPoison to the raw error page
On Sun, Mar 7, 2021 at 4:19 PM Balbir Singh wrote: > > On Thu, Feb 25, 2021 at 09:21:26PM +0800, Muchun Song wrote: > > Because we reuse the first tail vmemmap page frame and remap it > > with read-only, we cannot set the PageHWPosion on some tail pages. > > So we can use the head[4].private (There are at least 128 struct > > page structures associated with the optimized HugeTLB page, so > > using head[4].private is safe) to record the real error page index > > and set the raw error page PageHWPoison later. > > > > Does the hardcoding of 4 come from HUGETLB_CGROUP_MIN_ORDER, if so Yes. > do we need to hardcode 4? Also, I am not sure about the comment > on safety and 128 struct pages We can set head[4].private only if free_vmemmap_pages_per_hpage(h) returns true. In this case, there are 128 struct page structures (we reserve 2 pages as vmemmap pages, so 2 * 4KB / sizeof(struct page) == 128) that can be used. Instead of hardcode, I introduce another patch to make the code more readable. Please refer to patch #8 in this series. Thanks. > > Balbir >
[PATCH] net: hisilicon: hns: fix error return code of hns_nic_clear_all_rx_fetch()
When hns_assemble_skb() returns NULL to skb, no error return code of
hns_nic_clear_all_rx_fetch() is assigned.
To fix this bug, ret is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 5d7824d2b4d4..c66a7a51198e 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1663,8 +1663,10 @@ static int hns_nic_clear_all_rx_fetch(struct net_device
*ndev)
for (j = 0; j < fetch_num; j++) {
/* alloc one skb and init */
skb = hns_assemble_skb(ndev);
- if (!skb)
+ if (!skb) {
+ ret = -ENOMEM;
goto out;
+ }
rd = &tx_ring_data(priv, skb->queue_mapping);
hns_nic_net_xmit_hw(ndev, skb, rd);
--
2.17.1
[PATCH] usb: gadget: legacy: fix error return code of multi_bind()
When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
return code of multi_bind() is assigned.
To fix this bug, status is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/usb/gadget/legacy/multi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/multi.c
b/drivers/usb/gadget/legacy/multi.c
index ec9749845660..7734bf77b309 100644
--- a/drivers/usb/gadget/legacy/multi.c
+++ b/drivers/usb/gadget/legacy/multi.c
@@ -399,8 +399,10 @@ static int __ref multi_bind(struct usb_composite_dev *cdev)
struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(gadget);
- if (!usb_desc)
+ if (!usb_desc) {
+ status = -ENOMEM;
goto fail_string_ids;
+ }
usb_otg_descriptor_init(gadget, usb_desc);
otg_desc[0] = usb_desc;
otg_desc[1] = NULL;
--
2.17.1
Re: [PATCH v4 4/4] mtd: spi-nor: implement OTP erase for Winbond and similar flashes
Hi Michael,
I love your patch! Yet something to improve:
[auto build test ERROR on mtd/spi-nor/next]
[also build test ERROR on linux/master linus/master v5.12-rc2 next-20210305]
[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/Michael-Walle/mtd-spi-nor-OTP-support/20210307-110709
base: https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
spi-nor/next
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-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/61574179875574d957f00e40fa3e9fe9671c0f6e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Michael-Walle/mtd-spi-nor-OTP-support/20210307-110709
git checkout 61574179875574d957f00e40fa3e9fe9671c0f6e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/mtd/spi-nor/otp.c: In function 'spi_nor_otp_init':
>> drivers/mtd/spi-nor/otp.c:451:7: error: 'struct mtd_info' has no member
>> named '_erase_user_prot_reg'; did you mean '_read_user_prot_reg'?
451 | mtd->_erase_user_prot_reg = spi_nor_mtd_otp_erase;
| ^~~~
| _read_user_prot_reg
vim +451 drivers/mtd/spi-nor/otp.c
427
428 void spi_nor_otp_init(struct spi_nor *nor)
429 {
430 struct mtd_info *mtd = &nor->mtd;
431
432 if (!nor->params->otp.ops)
433 return;
434
435 if (WARN_ON(!is_power_of_2(spi_nor_otp_region_len(nor
436 return;
437
438 /*
439 * We only support user_prot callbacks (yet).
440 *
441 * Some SPI NOR flashes like Macronix ones can be ordered in two
442 * different variants. One with a factory locked OTP area and
one where
443 * it is left to the user to write to it. The factory locked
OTP is
444 * usually preprogrammed with an "electrical serial number". We
don't
445 * support these for now.
446 */
447 mtd->_get_user_prot_info = spi_nor_mtd_otp_info;
448 mtd->_read_user_prot_reg = spi_nor_mtd_otp_read;
449 mtd->_write_user_prot_reg = spi_nor_mtd_otp_write;
450 mtd->_lock_user_prot_reg = spi_nor_mtd_otp_lock;
> 451 mtd->_erase_user_prot_reg = spi_nor_mtd_otp_erase;
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] usb: gadget: legacy: fix error return code of msg_bind()
When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
return code of msg_bind() is assigned.
To fix this bug, status is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot >
Signed-off-by: Jia-Ju Bai
---
drivers/usb/gadget/legacy/mass_storage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/mass_storage.c
b/drivers/usb/gadget/legacy/mass_storage.c
index 9ed22c5fb7fe..ac1741126619 100644
--- a/drivers/usb/gadget/legacy/mass_storage.c
+++ b/drivers/usb/gadget/legacy/mass_storage.c
@@ -175,8 +175,10 @@ static int msg_bind(struct usb_composite_dev *cdev)
struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
- if (!usb_desc)
+ if (!usb_desc) {
+ status = -ENOMEM;
goto fail_string_ids;
+ }
usb_otg_descriptor_init(cdev->gadget, usb_desc);
otg_desc[0] = usb_desc;
otg_desc[1] = NULL;
--
2.17.1
Re: [PATCH] net: mellanox: mlx5: fix error return code in mlx5_fpga_device_start()
On Thu, Mar 04, 2021 at 06:18:14AM -0800, Jia-Ju Bai wrote: > When mlx5_is_fpga_lookaside() returns a non-zero value, no error > return code is assigned. > To fix this bug, err is assigned with -EINVAL as error return code. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai > --- > drivers/net/ethernet/mellanox/mlx5/core/fpga/core.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Like Heiner said, the current code has correct behavior. The mlx5_fpga_device_load_check() has same mlx5_is_fpga_lookaside() check and it is not an error if it returns true. NAK: Leon Romanovsky Thanks
[PATCH resend] usb: gadget: legacy: fix error return code of msg_bind()
When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error
return code of msg_bind() is assigned.
To fix this bug, status is assigned with -ENOMEM in this case.
Reported-by: TOTE Robot >
Signed-off-by: Jia-Ju Bai
---
drivers/usb/gadget/legacy/mass_storage.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/mass_storage.c
b/drivers/usb/gadget/legacy/mass_storage.c
index 9ed22c5fb7fe..ac1741126619 100644
--- a/drivers/usb/gadget/legacy/mass_storage.c
+++ b/drivers/usb/gadget/legacy/mass_storage.c
@@ -175,8 +175,10 @@ static int msg_bind(struct usb_composite_dev *cdev)
struct usb_descriptor_header *usb_desc;
usb_desc = usb_otg_descriptor_alloc(cdev->gadget);
- if (!usb_desc)
+ if (!usb_desc) {
+ status = -ENOMEM;
goto fail_string_ids;
+ }
usb_otg_descriptor_init(cdev->gadget, usb_desc);
otg_desc[0] = usb_desc;
otg_desc[1] = NULL;
--
2.17.1
Re: [PATCH v6 2/5] USB: misc: Add onboard_usb_hub driver
Hi Matthias,
I love your patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on robh/for-next char-misc/char-misc-testing
driver-core/driver-core-testing linus/master v5.12-rc2 next-20210305]
[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/Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210307-113654
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: m68k-allmodconfig (attached as .config)
compiler: m68k-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/63d87372b7498dc0963eb5cd672e929b9514
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Matthias-Kaehlcke/USB-misc-Add-onboard_usb_hub-driver/20210307-113654
git checkout 63d87372b7498dc0963eb5cd672e929b9514
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/dev_printk.h:14,
from include/linux/device.h:15,
from drivers/usb/misc/onboard_usb_hub.c:8:
include/linux/scatterlist.h: In function 'sg_set_buf':
arch/m68k/include/asm/page_mm.h:174:49: warning: ordered comparison of
pointer with null pointer [-Wextra]
174 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
| ^~
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
78 | # define unlikely(x) __builtin_expect(!!(x), 0)
| ^
include/linux/scatterlist.h:137:2: note: in expansion of macro 'BUG_ON'
137 | BUG_ON(!virt_addr_valid(buf));
| ^~
include/linux/scatterlist.h:137:10: note: in expansion of macro
'virt_addr_valid'
137 | BUG_ON(!virt_addr_valid(buf));
| ^~~
drivers/usb/misc/onboard_usb_hub.c: At top level:
>> drivers/usb/misc/onboard_usb_hub.c:273:6: error: redefinition of
>> 'of_is_onboard_usb_hub'
273 | bool of_is_onboard_usb_hub(const struct device_node *np)
| ^
In file included from drivers/usb/misc/onboard_usb_hub.c:21:
include/linux/usb/onboard_hub.h:9:20: note: previous definition of
'of_is_onboard_usb_hub' was here
9 | static inline bool of_is_onboard_usb_hub(const struct device_node
*np)
|^
vim +/of_is_onboard_usb_hub +273 drivers/usb/misc/onboard_usb_hub.c
272
> 273 bool of_is_onboard_usb_hub(const struct device_node *np)
274 {
275 return !!of_match_node(onboard_hub_match, np);
276 }
277 EXPORT_SYMBOL_GPL(of_is_onboard_usb_hub);
278
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] usb: renesas_usbhs: fix error return code of usbhsf_pkt_handler()
When __usbhsf_pkt_get() returns NULL to pkt, no error return code of
usbhsf_pkt_handler() is assigned.
To fix this bug, ret is assigned with -EINVAL in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/usb/renesas_usbhs/fifo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index e6fa13701808..b5e7991dc7d9 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -160,8 +160,10 @@ static int usbhsf_pkt_handler(struct usbhs_pipe *pipe, int
type)
usbhs_lock(priv, flags);
pkt = __usbhsf_pkt_get(pipe);
- if (!pkt)
+ if (!pkt) {
+ ret = -EINVAL;
goto __usbhs_pkt_handler_end;
+ }
switch (type) {
case USBHSF_PKT_PREPARE:
--
2.17.1
Re: [PATCH 3/3] vDPA/ifcvf: bump version string to 1.0
On Fri, Mar 05, 2021 at 10:20:00PM +0800, Zhu Lingshan wrote: > This commit bumps ifcvf driver version string to 1.0 > > Signed-off-by: Zhu Lingshan > --- > drivers/vdpa/ifcvf/ifcvf_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c > index fd5befc5cbcc..56a0974cf93c 100644 > --- a/drivers/vdpa/ifcvf/ifcvf_main.c > +++ b/drivers/vdpa/ifcvf/ifcvf_main.c > @@ -14,7 +14,7 @@ > #include > #include "ifcvf_base.h" > > -#define VERSION_STRING "0.1" > +#define VERSION_STRING "1.0" Please delete it instead of bumping it. We are not supposed to use in-kernel version for years already. https://lore.kernel.org/ksummit-discuss/20170625072423.GR1248@mtr-leonro.local/ Thanks
[PATCH] ath: ath6kl: fix error return code of ath6kl_htc_rx_bundle()
When hif_scatter_req_get() returns NULL to scat_req, no error return
code of ath6kl_htc_rx_bundle() is assigned.
To fix this bug, status is assigned with -EINVAL in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 998947ef63b6..3f8857d19a0c 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -1944,8 +1944,10 @@ static int ath6kl_htc_rx_bundle(struct htc_target
*target,
scat_req = hif_scatter_req_get(target->dev->ar);
- if (scat_req == NULL)
+ if (scat_req == NULL) {
+ status = -EINVAL;
goto fail_rx_pkt;
+ }
for (i = 0; i < n_scat_pkt; i++) {
int pad_len;
--
2.17.1
Re: [PATCH] infiniband: hw: cxgb4: fix error return code of pass_open_rpl()
On Sat, Mar 06, 2021 at 05:53:17AM -0800, Jia-Ju Bai wrote:
> When ep is NULL, no error code of pass_open_rpl() is returned.
> To fix this bug, pass_open_rpl() returns -EINVAL in this case.
Why do you think that this is an error?
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/infiniband/hw/cxgb4/cm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/cxgb4/cm.c
> b/drivers/infiniband/hw/cxgb4/cm.c
> index 8769e7aa097f..773d3805bb25 100644
> --- a/drivers/infiniband/hw/cxgb4/cm.c
> +++ b/drivers/infiniband/hw/cxgb4/cm.c
> @@ -2382,7 +2382,7 @@ static int pass_open_rpl(struct c4iw_dev *dev, struct
> sk_buff *skb)
>
> if (!ep) {
> pr_warn("%s stid %d lookup failure!\n", __func__, stid);
> - goto out;
> + return -EINVAL;
> }
> pr_debug("ep %p status %d error %d\n", ep,
>rpl->status, status2errno(rpl->status));
> --
> 2.17.1
>
Re: [PATCH] infiniband: hw: cxgb4: fix error return code of close_listsrv_rpl()
On Sat, Mar 06, 2021 at 05:55:48AM -0800, Jia-Ju Bai wrote:
> When ep is NULL, no error code of close_listsrv_rpl() is returned.
> To fix this bug, close_listsrv_rpl() returns -EINVAL in this case.
I don't think that this is an error.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/infiniband/hw/cxgb4/cm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/cxgb4/cm.c
> b/drivers/infiniband/hw/cxgb4/cm.c
> index 8769e7aa097f..94492d2dfdc7 100644
> --- a/drivers/infiniband/hw/cxgb4/cm.c
> +++ b/drivers/infiniband/hw/cxgb4/cm.c
> @@ -2400,7 +2400,7 @@ static int close_listsrv_rpl(struct c4iw_dev *dev,
> struct sk_buff *skb)
>
> if (!ep) {
> pr_warn("%s stid %d lookup failure!\n", __func__, stid);
> - goto out;
> + return -EINVAL;
> }
> pr_debug("ep %p\n", ep);
> c4iw_wake_up_noref(ep->com.wr_waitp, status2errno(rpl->status));
> --
> 2.17.1
>
[PATCH] net: wan: fix error return code of uhdlc_init()
When priv->rx_skbuff or priv->tx_skbuff is NULL, no error return code of
uhdlc_init() is assigned.
To fix this bug, ret is assigned with -ENOMEM in these cases.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/wan/fsl_ucc_hdlc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index dca97cd7c4e7..7eac6a3e1cde 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -204,14 +204,18 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
priv->rx_skbuff = kcalloc(priv->rx_ring_size,
sizeof(*priv->rx_skbuff),
GFP_KERNEL);
- if (!priv->rx_skbuff)
+ if (!priv->rx_skbuff) {
+ ret = -ENOMEM;
goto free_ucc_pram;
+ }
priv->tx_skbuff = kcalloc(priv->tx_ring_size,
sizeof(*priv->tx_skbuff),
GFP_KERNEL);
- if (!priv->tx_skbuff)
+ if (!priv->tx_skbuff) {
+ ret = -ENOMEM;
goto free_rx_skbuff;
+ }
priv->skb_curtx = 0;
priv->skb_dirtytx = 0;
--
2.17.1
Re: [PATCH] ath: ath6kl: fix error return code of ath6kl_htc_rx_bundle()
On Sun, Mar 07, 2021 at 01:07:57AM -0800, Jia-Ju Bai wrote:
> When hif_scatter_req_get() returns NULL to scat_req, no error return
> code of ath6kl_htc_rx_bundle() is assigned.
> To fix this bug, status is assigned with -EINVAL in this case.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
> ---
> drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
> b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
> index 998947ef63b6..3f8857d19a0c 100644
> --- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
> +++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
> @@ -1944,8 +1944,10 @@ static int ath6kl_htc_rx_bundle(struct htc_target
> *target,
>
> scat_req = hif_scatter_req_get(target->dev->ar);
>
> - if (scat_req == NULL)
> + if (scat_req == NULL) {
> + status = -EINVAL;
I'm not sure about it.
David. Jakub,
Please be warned that patches from this guy are not so great.
I looked on 4 patches and 3 of them were wrong (2 in RDMA and 1 for mlx5)
plus this patch most likely is incorrect too.
Thanks
> goto fail_rx_pkt;
> + }
>
> for (i = 0; i < n_scat_pkt; i++) {
> int pad_len;
> --
> 2.17.1
>
[PATCH] gpu: drm: amd: amdgpu: fix error return code of amdgpu_acpi_init()
Add error return code in error hanlding code of amdgpu_acpi_init().
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 8155c54392c8..156f30d5a2c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -788,12 +788,15 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
/* Probe for ATIF, and initialize it if found */
atif_handle = amdgpu_atif_probe_handle(handle);
- if (!atif_handle)
+ if (!atif_handle) {
+ ret = -EINVAL;
goto out;
+ }
atif = kzalloc(sizeof(*atif), GFP_KERNEL);
if (!atif) {
DRM_WARN("Not enough memory to initialize ATIF\n");
+ ret = -ENOMEM;
goto out;
}
atif->handle = atif_handle;
@@ -803,6 +806,7 @@ int amdgpu_acpi_init(struct amdgpu_device *adev)
if (ret) {
DRM_DEBUG_DRIVER("Call to ATIF verify_interface failed: %d\n",
ret);
kfree(atif);
+ ret = -EINVAL;
goto out;
}
adev->atif = atif;
--
2.17.1
Re: [PATCH] ath: ath6kl: fix error return code of ath6kl_htc_rx_bundle()
Hi Leon,
I am quite sorry for my incorrect patches...
My static analysis tool reports some possible bugs about error handling
code, and thus I write some patches for the bugs that seem to be true in
my opinion.
Because I am not familiar with many device drivers, some of my reported
bugs can be false positives...
Best wishes,
Jia-Ju Bai
On 2021/3/7 17:18, Leon Romanovsky wrote:
On Sun, Mar 07, 2021 at 01:07:57AM -0800, Jia-Ju Bai wrote:
When hif_scatter_req_get() returns NULL to scat_req, no error return
code of ath6kl_htc_rx_bundle() is assigned.
To fix this bug, status is assigned with -EINVAL in this case.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 998947ef63b6..3f8857d19a0c 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -1944,8 +1944,10 @@ static int ath6kl_htc_rx_bundle(struct htc_target
*target,
scat_req = hif_scatter_req_get(target->dev->ar);
- if (scat_req == NULL)
+ if (scat_req == NULL) {
+ status = -EINVAL;
I'm not sure about it.
David. Jakub,
Please be warned that patches from this guy are not so great.
I looked on 4 patches and 3 of them were wrong (2 in RDMA and 1 for mlx5)
plus this patch most likely is incorrect too.
Re: [PATCH v4] RISC-V: enable XIP
Hi Vitaly,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc2 next-20210305]
[cannot apply to linux/master]
[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/Vitaly-Wool/RISC-V-enable-XIP/20210307-103904
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
280d542f6ffac0e6d65dc267f92191d509b13b64
config: riscv-defconfig (attached as .config)
compiler: riscv64-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/c9cb15092dcf53140fba57780677a9dcaef70612
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Vitaly-Wool/RISC-V-enable-XIP/20210307-103904
git checkout c9cb15092dcf53140fba57780677a9dcaef70612
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/riscv/kernel/cpu_ops_sbi.c: In function 'get_secondary_start_phys':
>> arch/riscv/kernel/cpu_ops_sbi.c:59:3: error: implicit declaration of
>> function 'XIP_PHYS_ADDR' [-Werror=implicit-function-declaration]
59 | XIP_PHYS_ADDR(secondary_start_sbi) :
| ^
cc1: some warnings being treated as errors
vim +/XIP_PHYS_ADDR +59 arch/riscv/kernel/cpu_ops_sbi.c
55
56 static inline unsigned long get_secondary_start_phys(void)
57 {
58 return IS_ENABLED(CONFIG_XIP_KERNEL) ?
> 59 XIP_PHYS_ADDR(secondary_start_sbi) :
60 __pa_symbol(secondary_start_sbi);
61 }
62
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH v3 2/4] devfreq/drivers/msm: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on dragonboard 845c
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/msm/msm_gpu.c | 12 +---
drivers/gpu/drm/msm/msm_gpu.h | 2 --
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index ab7c167b0623..eade94271a60 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
@@ -82,6 +81,7 @@ static struct devfreq_dev_profile msm_devfreq_profile = {
.target = msm_devfreq_target,
.get_dev_status = msm_devfreq_get_dev_status,
.get_cur_freq = msm_devfreq_get_cur_freq,
+ .is_cooling_device = true,
};
static void msm_devfreq_init(struct msm_gpu *gpu)
@@ -112,14 +112,6 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
}
devfreq_suspend_device(gpu->devfreq.devfreq);
-
- gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
- gpu->devfreq.devfreq);
- if (IS_ERR(gpu->cooling)) {
- DRM_DEV_ERROR(&gpu->pdev->dev,
- "Couldn't register GPU cooling device\n");
- gpu->cooling = NULL;
- }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -1056,6 +1048,4 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
if (gpu->worker) {
kthread_destroy_worker(gpu->worker);
}
-
- devfreq_cooling_unregister(gpu->cooling);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index d7cd02cd2109..93419368bac8 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -155,8 +155,6 @@ struct msm_gpu {
struct msm_gpu_state *crashstate;
/* True if the hardware supports expanded apriv (a650 and newer) */
bool hw_apriv;
-
- struct thermal_cooling_device *cooling;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.17.1
[PATCH v3 1/4] devfreq: Register devfreq as a cooling device on demand
Currently the default behavior is to manually having the devfreq
backend to register themselves as a devfreq cooling device.
Instead of adding the code in the drivers for the thermal cooling
device registering, let's provide a flag in the devfreq's profile to
tell the common devfreq code to register the newly created devfreq as
a cooling device.
Suggested-by: Chanwoo Choi
Signed-off-by: Daniel Lezcano
---
V3:
- Rebased on linux-pm branch without units.h
- Set the cdev to NULL in case of error
- Added description for the cdev field in the devfreq structure
V2:
- Added is_cooling_device boolean in profile structure
- Register cooling device when the is_cooling_device boolean is set
- Remove devfreq cooling device registration in the backend drivers
V1:
- Register devfreq as a cooling device unconditionnally
---
drivers/devfreq/devfreq.c | 13 +
include/linux/devfreq.h | 8
2 files changed, 21 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index bf3047896e41..cf64aeec468f 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -26,6 +27,7 @@
#include
#include
#include
+#include
#include "governor.h"
#define CREATE_TRACE_POINTS
@@ -935,6 +937,15 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq_list_lock);
+ if (devfreq->profile->is_cooling_device) {
+ devfreq->cdev = devfreq_cooling_em_register(devfreq, NULL);
+ if (IS_ERR(devfreq->cdev)) {
+ dev_info(dev, "Failed to register devfreq "
+"cooling device\n");
+ devfreq->cdev = NULL;
+ }
+ }
+
return devfreq;
err_init:
@@ -960,6 +971,8 @@ int devfreq_remove_device(struct devfreq *devfreq)
if (!devfreq)
return -EINVAL;
+ thermal_cooling_device_unregister(devfreq->cdev);
+
if (devfreq->governor) {
devfreq->governor->event_handler(devfreq,
DEVFREQ_GOV_STOP, NULL);
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 26ea0850be9b..aba7ace11b72 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -98,11 +98,15 @@ struct devfreq_dev_status {
* @freq_table:Optional list of frequencies to support
statistics
* and freq_table must be generated in ascending order.
* @max_state: The size of freq_table.
+ *
+ * @is_cooling_device: A self-explanatory boolean giving the device a
+ * cooling effect property.
*/
struct devfreq_dev_profile {
unsigned long initial_freq;
unsigned int polling_ms;
enum devfreq_timer timer;
+ bool is_cooling_device;
int (*target)(struct device *dev, unsigned long *freq, u32 flags);
int (*get_dev_status)(struct device *dev,
@@ -156,6 +160,7 @@ struct devfreq_stats {
* @suspend_count: suspend requests counter for a device.
* @stats: Statistics of devfreq device behavior
* @transition_notifier_list: list head of DEVFREQ_TRANSITION_NOTIFIER notifier
+ * @cdev: Cooling device pointer if the devfreq has cooling property
* @nb_min:Notifier block for DEV_PM_QOS_MIN_FREQUENCY
* @nb_max:Notifier block for DEV_PM_QOS_MAX_FREQUENCY
*
@@ -198,6 +203,9 @@ struct devfreq {
struct srcu_notifier_head transition_notifier_list;
+ /* Pointer to the cooling device if used for thermal mitigation */
+ struct thermal_cooling_device *cdev;
+
struct notifier_block nb_min;
struct notifier_block nb_max;
};
--
2.17.1
[PATCH v3 4/4] devfreq/drivers/lima: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/lima/lima_devfreq.c | 14 +-
drivers/gpu/drm/lima/lima_devfreq.h | 2 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index 5686ad4aaf7c..86aea1bdc4f4 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -7,7 +7,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -84,17 +83,13 @@ static struct devfreq_dev_profile lima_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = lima_devfreq_target,
.get_dev_status = lima_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
void lima_devfreq_fini(struct lima_device *ldev)
{
struct lima_devfreq *devfreq = &ldev->devfreq;
- if (devfreq->cooling) {
- devfreq_cooling_unregister(devfreq->cooling);
- devfreq->cooling = NULL;
- }
-
if (devfreq->devfreq) {
devm_devfreq_remove_device(ldev->dev, devfreq->devfreq);
devfreq->devfreq = NULL;
@@ -110,7 +105,6 @@ void lima_devfreq_fini(struct lima_device *ldev)
int lima_devfreq_init(struct lima_device *ldev)
{
- struct thermal_cooling_device *cooling;
struct device *dev = ldev->dev;
struct opp_table *opp_table;
struct devfreq *devfreq;
@@ -173,12 +167,6 @@ int lima_devfreq_init(struct lima_device *ldev)
ldevfreq->devfreq = devfreq;
- cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
- if (IS_ERR(cooling))
- dev_info(dev, "Failed to register cooling device\n");
- else
- ldevfreq->cooling = cooling;
-
return 0;
err_fini:
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
b/drivers/gpu/drm/lima/lima_devfreq.h
index 2d9b3008ce77..c43a2069e5d3 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -9,7 +9,6 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
struct lima_device;
@@ -17,7 +16,6 @@ struct lima_devfreq {
struct devfreq *devfreq;
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
ktime_t busy_time;
ktime_t idle_time;
--
2.17.1
[PATCH v3 3/4] devfreq/drivers/panfrost: Use devfreq cooling device registration
The devfreq core code is able to register the devfreq device as a
cooling device if the 'is_cooling_device' flag is set in the profile.
Use this flag and remove the cooling device registering code.
Tested on rock960.
Signed-off-by: Daniel Lezcano
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ---
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..4d96edf1bc54 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -3,7 +3,6 @@
#include
#include
-#include
#include
#include
@@ -80,6 +79,7 @@ static struct devfreq_dev_profile panfrost_devfreq_profile = {
.polling_ms = 50, /* ~3 frames */
.target = panfrost_devfreq_target,
.get_dev_status = panfrost_devfreq_get_dev_status,
+ .is_cooling_device = true,
};
int panfrost_devfreq_init(struct panfrost_device *pfdev)
@@ -90,7 +90,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = &pfdev->pdev->dev;
struct devfreq *devfreq;
struct opp_table *opp_table;
- struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
@@ -139,12 +138,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
}
pfdevfreq->devfreq = devfreq;
- cooling = devfreq_cooling_em_register(devfreq, NULL);
- if (IS_ERR(cooling))
- DRM_DEV_INFO(dev, "Failed to register cooling device\n");
- else
- pfdevfreq->cooling = cooling;
-
return 0;
err_fini:
@@ -156,11 +149,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
- if (pfdevfreq->cooling) {
- devfreq_cooling_unregister(pfdevfreq->cooling);
- pfdevfreq->cooling = NULL;
- }
-
if (pfdevfreq->opp_of_table_added) {
dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
pfdevfreq->opp_of_table_added = false;
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..470f5c974703 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -9,14 +9,11 @@
struct devfreq;
struct opp_table;
-struct thermal_cooling_device;
-
struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
- struct thermal_cooling_device *cooling;
bool opp_of_table_added;
ktime_t busy_time;
--
2.17.1
[syzbot] possible deadlock in io_sq_thread_finish
Hello,
syzbot found the following issue on:
HEAD commit:a38fd874 Linux 5.12-rc2
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=143ee02ad0
kernel config: https://syzkaller.appspot.com/x/.config?x=db9c6adb4986f2f2
dashboard link: https://syzkaller.appspot.com/bug?extid=ac39856cb1b332dbbdda
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ac39856cb1b332dbb...@syzkaller.appspotmail.com
WARNING: possible recursive locking detected
5.12.0-rc2-syzkaller #0 Not tainted
kworker/u4:7/7615 is trying to acquire lock:
888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_stop
fs/io_uring.c:7099 [inline]
888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_put_sq_data
fs/io_uring.c:7115 [inline]
888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_finish+0x408/0x650
fs/io_uring.c:7139
but task is already holding lock:
888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
fs/io_uring.c:7088 [inline]
888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park+0x63/0xc0
fs/io_uring.c:7082
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&sqd->lock);
lock(&sqd->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/u4:7/7615:
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
set_work_data kernel/workqueue.c:616 [inline]
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
#0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
process_one_work+0x871/0x1600 kernel/workqueue.c:2246
#1: c900023a7da8 ((work_completion)(&ctx->exit_work)){+.+.}-{0:0}, at:
process_one_work+0x8a5/0x1600 kernel/workqueue.c:2250
#2: 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
fs/io_uring.c:7088 [inline]
#2: 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park+0x63/0xc0
fs/io_uring.c:7082
stack backtrace:
CPU: 1 PID: 7615 Comm: kworker/u4:7 Not tainted 5.12.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Workqueue: events_unbound io_ring_exit_work
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
print_deadlock_bug kernel/locking/lockdep.c:2829 [inline]
check_deadlock kernel/locking/lockdep.c:2872 [inline]
validate_chain kernel/locking/lockdep.c:3661 [inline]
__lock_acquire.cold+0x14c/0x3b4 kernel/locking/lockdep.c:4900
lock_acquire kernel/locking/lockdep.c:5510 [inline]
lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5475
__mutex_lock_common kernel/locking/mutex.c:946 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1093
io_sq_thread_stop fs/io_uring.c:7099 [inline]
io_put_sq_data fs/io_uring.c:7115 [inline]
io_sq_thread_finish+0x408/0x650 fs/io_uring.c:7139
io_ring_ctx_free fs/io_uring.c:8408 [inline]
io_ring_exit_work+0x82/0x9a0 fs/io_uring.c:8539
process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x3b1/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[GIT PULL] m68k updates for 5.12 (take two)
Hi Linus,
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
tags/m68k-for-v5.12-tag2
for you to fetch changes up to a65a802aadba072ca7514fc0c301fd7fdc6fc6cb:
m68k: Fix virt_addr_valid() W=1 compiler warnings (2021-03-06 14:15:07 +0100)
m68k updates for v5.12 (take two)
- Fix virt_addr_valid() W=1 compiler warnings.
This is a single non-critical fix. As the build bots are now testing
all new code with W=1, these warnings are popping up everywhere,
confusing people. Hence I think it makes sense to silence it as soon as
possible.
Note that I have just rebased this single commit to v5.12-rc2, to avoid
the swapfile bug. Should be safe, as this file has not been touched
since v5.11-rc1.
Thanks for pulling!
Geert Uytterhoeven (1):
m68k: Fix virt_addr_valid() W=1 compiler warnings
arch/m68k/include/asm/page_mm.h | 2 +-
arch/m68k/include/asm/page_no.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/4] mips: bmips: add BCM63268 timer reset definitions
Hi Rob, El 06/03/2021 a las 22:17, Rob Herring escribió: On Thu, Feb 25, 2021 at 08:41:59PM +0100, Álvaro Fernández Rojas wrote: Add missing timer reset definitions for BCM63268. Signed-off-by: Álvaro Fernández Rojas --- include/dt-bindings/reset/bcm63268-reset.h | 4 1 file changed, 4 insertions(+) diff --git a/include/dt-bindings/reset/bcm63268-reset.h b/include/dt-bindings/reset/bcm63268-reset.h index 6a6403a4c2d5..d87a7882782a 100644 --- a/include/dt-bindings/reset/bcm63268-reset.h +++ b/include/dt-bindings/reset/bcm63268-reset.h @@ -23,4 +23,8 @@ #define BCM63268_RST_PCIE_HARD17 #define BCM63268_RST_GPHY 18 +#define BCM63268_TRST_SW 29 +#define BCM63268_TRST_HW 30 +#define BCM63268_TRST_POR 31 Numbering should be local to the provider, so shouldn't this be 0-2? Unless these numbers correspond to something in the h/w (bit positions for example). Numbering corresponds to bit positions in the HW: uint32ClkRstCtl; #define POR_RESET_STATUS(1 << 31) #define HW_RESET_STATUS (1 << 30) #define SW_RESET_STATUS (1 << 29) #define USB_REF_CLKEN (1 << 18) #define UTO_EXTIN_CLKEN (1 << 17) #define UTO_CLK50_SEL (1 << 16) #define FAP2_PLL_CLKEN (1 << 15) #define FAP2_PLL_FREQ_SHIFT 12 #define FAP1_PLL_CLKEN (1 << 11) #define FAP1_PLL_FREQ_SHIFT 8 #define WAKEON_DSL (1 << 7) #define WAKEON_EPHY (1 << 6) #define DSL_ENERGY_DETECT_ENABLE(1 << 4) #define GPHY_1_ENERGY_DETECT_ENABLE (1 << 3) #define EPHY_3_ENERGY_DETECT_ENABLE (1 << 2) #define EPHY_2_ENERGY_DETECT_ENABLE (1 << 1) #define EPHY_1_ENERGY_DETECT_ENABLE (1 << 0) http://datashed.science/misc/bcm/gpl/broadcom-sdk-416L05/shared/opensource/include/bcm963xx/63268_map_part.h + #endif /* __DT_BINDINGS_RESET_BCM63268_H */ -- 2.20.1 Best regards, Álvaro.
Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: document BCM6345 external interrupt controller
Hi Rob,
El 06/03/2021 a las 21:14, Rob Herring escribió:
On Wed, Feb 24, 2021 at 08:56:39AM +0100, Álvaro Fernández Rojas wrote:
Document the binding for the BCM6345 external interrupt controller.
Signed-off-by: Álvaro Fernández Rojas
Signed-off-by: Jonas Gorski
Reviewed-by: Florian Fainelli
---
v3: pass dt_binding_check.
v2: fix title typo.
.../brcm,bcm6345-ext-intc.yaml| 78 +++
1 file changed, 78 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-ext-intc.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-ext-intc.yaml
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-ext-intc.yaml
new file mode 100644
index ..a691510e78b7
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-ext-intc.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/interrupt-controller/brcm,bcm6345-ext-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM6345 external interrupt controller
+
+maintainers:
+ - Álvaro Fernández Rojas
+ - Jonas Gorski
+
+properties:
+ compatible:
+enum:
+ - brcm,bcm6318-ext-intc
+ - brcm,bcm6345-ext-intc
+
+ "#interrupt-cells":
+const: 2
+
+ reg:
+maxItems: 1
+
+ "#address-cells":
+const: 0
+
+ interrupt-controller: true
+
+ interrupts:
+description: Specifies the interrupt line(s) in the interrupt-parent
+ controller node. Valid values depend on the type of parent interrupt
+ controller.
+maxItems: 4
+
+ brcm,field-width:
+description: Interrupt controller field width (the default is 4).
default: 4
+maxItems: 1
All uint32's are 1 item.
Ok, so I should remove this :)
What's the set or range of values?
Only BCM6348 needs to set this value to 5, other BCM63xx use the default
value of 4 (BCM3368, BCM6318, BCM6328, BCM6338, BCM6345, BCM6358,
BCM6362, BCM6368, BCM63268).
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - "#address-cells"
+ - compatible
+ - reg
+ - "#interrupt-cells"
+ - interrupt-controller
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+interrupt-controller@1018 {
+ #address-cells = <0>;
+ compatible = "brcm,bcm6345-ext-intc";
+ reg = <0x1018 0x4>;
+
+ interrupt-parent = <&periph_intc>;
+ #interrupt-cells = <2>;
+
+ interrupt-controller;
+ interrupts = <24>, <25>, <26>, <27>;
+};
+
+ - |
+interrupt-controller@fffe0014 {
+ #address-cells = <0>;
+ compatible = "brcm,bcm6345-ext-intc";
+ reg = <0xfffe0014 0x4>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <3>, <4>, <5>, <6>;
+
+ brcm,field-width = <5>;
+};
--
2.20.1
Best regards,
Álvaro.
Re: [bugreport 5.9-rc8] general protection fault in __bfq_deactivate_entity
On Sun, Mar 7, 2021 at 11:09 AM Hillf Danton wrote: > > On Sun, 7 Mar 2021 08:46:19 +0100 Dmitry Vyukov wrote: > > On Sun, Mar 7, 2021 at 3:15 AM Hillf Danton wrote: > > > > > > Dmitry can you shed some light on the tricks to config kasan to print > > > Call Trace as the reports with the leading [syzbot] on the subject line > > > do? > > > > +kasan-dev > > > > Hi Hillf, > > > > KASAN prints stack traces always unconditionally. There is nothing you > > need to do at all. > > Got it, thanks. > > > Do you have any reports w/o stack traces? > > No, but I saw different formats in Call Trace prints. > > Below from [1] is the instance without file name and line number printed, > while both info help spot the cause of the reported issue. KASAN always prints stack traces w/o file:line info, like any other kernel bug detection facility. Kernel itself never symbolizes reports. In case of syzkaller, syzkaller will symbolize reports and add file:line info. The main config it requires is CONFIG_DEBUG_INFO. You may see syzkaller kernel configuration guide here: https://github.com/google/syzkaller/blob/master/docs/linux/kernel_configs.md Or fragments that are actually used to generate syzbot configs in this dir (the guide above may be out-of-date): https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/base.yml https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/debug.yml https://github.com/google/syzkaller/blob/master/dashboard/config/linux/bits/kasan.yml Or a complete syzbot config here: https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-apparmor-kasan.config > > > > I was running syzkaller and I found the following issue : > > Head Commit : b1313fe517ca3703119dcc99ef3bbf75ab42bcfb ( v5.10.4 ) > Git Tree : stable > Console Output : > [ 242.769080] INFO: task repro:2639 blocked for more than 120 seconds. > [ 242.769096] Not tainted 5.10.4 #8 > [ 242.769103] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 242.769112] task:repro state:D stack:0 pid: 2639 > ppid: 2638 flags:0x0004 > [ 242.769126] Call Trace: > [ 242.769148] __schedule+0x28d/0x7e0 > [ 242.769162] ? __percpu_counter_sum+0x75/0x90 > [ 242.769175] schedule+0x4f/0xc0 > [ 242.769187] __io_uring_task_cancel+0xad/0xf0 > [ 242.769198] ? wait_woken+0x80/0x80 > [ 242.769210] bprm_execve+0x67/0x8a0 > [ 242.769223] do_execveat_common+0x1d2/0x220 > [ 242.769235] __x64_sys_execveat+0x5d/0x70 > [ 242.769249] do_syscall_64+0x38/0x90 > [ 242.769260] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [1] > https://lore.kernel.org/lkml/CAGyP=7cfm6bje7x2pn9yuptqgt5uqywm4avmoivayqpjg1p...@mail.gmail.com/
Build regressions/improvements in v5.12-rc2
Below is the list of build error/warning regressions/improvements in v5.12-rc2[1] compared to v5.11[2]. Summarized: - build errors: +2/-0 - build warnings: +116/-8 JFYI, when comparing v5.12-rc2[1] to v5.12-rc1[3], the summaries are: - build errors: +0/-0 - build warnings: +0/-1 Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/a38fd8748464831584a19438cbb3082b5a2dab15/ (all 192 configs) [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f40ddce88593482919761f74910f42f4b84c004b/ (all 192 configs) [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8/ (all 192 configs) *** ERRORS *** 2 error regressions: + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'disable_kernel_vsx' [-Werror=implicit-function-declaration]: => 674:2 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: error: implicit declaration of function 'enable_kernel_vsx' [-Werror=implicit-function-declaration]: => 638:2 *** WARNINGS *** 116 warning regressions: + /kisskb/src/arch/m68k/include/asm/page_mm.h: warning: ordered comparison of pointer with null pointer [-Wextra]: => 174:49 + /kisskb/src/arch/s390/boot/mem_detect.c: warning: 'detect_memory' uses dynamic stack allocation: => 176:1 + /kisskb/src/drivers/clk/xilinx/xlnx_vcu.c: warning: (near initialization for 'parent_data[0]') [-Wmissing-braces]: => 524:9 + /kisskb/src/drivers/clk/xilinx/xlnx_vcu.c: warning: missing braces around initializer [-Wmissing-braces]: => 524:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c: warning: (near initialization for 'clock_table.DcfClocks') [-Wmissing-braces]: => 880:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c: warning: missing braces around initializer [-Wmissing-braces]: => 880:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/dcn301_smu.c: warning: (near initialization for 'idle_info.idle_info') [-Wmissing-braces]: => 198:8 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/dcn301_smu.c: warning: missing braces around initializer [-Wmissing-braces]: => 198:8 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/vg_clk_mgr.c: warning: (near initialization for 'dummy_wms.WatermarkRow') [-Wmissing-braces]: => 704:15 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/vg_clk_mgr.c: warning: (near initialization for 'idle_info.idle_info') [-Wmissing-braces]: => 129:10, 116:11 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn301/vg_clk_mgr.c: warning: missing braces around initializer [-Wmissing-braces]: => 129:10, 116:11, 704:15 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 1802:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c: warning: missing braces around initializer [-Wmissing-braces]: => 1802:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.c: warning: (near initialization for 'rq_regs.rq_regs_l') [-Wmissing-braces]: => 1273:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubp.c: warning: missing braces around initializer [-Wmissing-braces]: => 1273:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: warning: (near initialization for 'hw_locks.bits') [-Wmissing-braces]: => 1223:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: warning: missing braces around initializer [-Wmissing-braces]: => 1223:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c: warning: (near initialization for 'dcn2_0_nv12_soc.clock_limits') [-Wmissing-braces]: => 451:15 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_resource.c: warning: missing braces around initializer [-Wmissing-braces]: => 451:15 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hubp.c: warning: (near initialization for 'rq_regs.rq_regs_l') [-Wmissing-braces]: => 258:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hubp.c: warning: missing braces around initializer [-Wmissing-braces]: => 258:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c: warning: (near initialization for 'warmup_params.start_address') [-Wmissing-braces]: => 264:9 + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_hwseq.c: warning: missing braces around initializer [-Wmissing-braces]: => 264:9 + /kisskb/src/drivers/media/i2c/imx334.c: warning: (near initialization for 'msgs[0]') [-Wmissing-braces]: => 288:9 + /kisskb/src/drivers/media
[PATCH 1/2] Perf: Clean generated directory, other archs.
After a make clean there are generated directories left in the arch directories of perf. Clean them up. Suggested-by: Arnaldo Carvalho de Melo Signed-off-by: Andreas Wendleder --- tools/perf/arch/arm64/Makefile | 5 +++-- tools/perf/arch/powerpc/Makefile | 5 +++-- tools/perf/arch/s390/Makefile| 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile index fab3095fb5d0..426aecdd0b71 100644 --- a/tools/perf/arch/arm64/Makefile +++ b/tools/perf/arch/arm64/Makefile @@ -10,7 +10,8 @@ HAVE_KVM_STAT_SUPPORT := 1 # Syscall table generation for perf # -out:= $(OUTPUT)arch/arm64/include/generated/asm +generated := $(OUTPUT)arch/arm64/include/generated +out:= $(generated)/asm header := $(out)/syscalls.c incpath := $(srctree)/tools sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h @@ -24,6 +25,6 @@ $(header): $(sysdef) $(systbl) $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(incpath) $(sysdef) > $@ clean:: - $(call QUIET_CLEAN, arm64) $(RM) $(header) + $(call QUIET_CLEAN, arm64) $(RM) -r $(header) $(generated) archheaders: $(header) diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile index 840ea0e59287..979c2bebc167 100644 --- a/tools/perf/arch/powerpc/Makefile +++ b/tools/perf/arch/powerpc/Makefile @@ -11,7 +11,8 @@ PERF_HAVE_JITDUMP := 1 # Syscall table generation for perf # -out:= $(OUTPUT)arch/powerpc/include/generated/asm +generated := $(OUTPUT)arch/powerpc/include/generated +out:= $(generated)/asm header32 := $(out)/syscalls_32.c header64 := $(out)/syscalls_64.c sysprf := $(srctree)/tools/perf/arch/powerpc/entry/syscalls @@ -28,6 +29,6 @@ $(header32): $(sysdef) $(systbl) $(Q)$(SHELL) '$(systbl)' '32' $(sysdef) > $@ clean:: - $(call QUIET_CLEAN, powerpc) $(RM) $(header32) $(header64) + $(call QUIET_CLEAN, powerpc) $(RM) -r $(header32) $(header64) $(generated) archheaders: $(header32) $(header64) diff --git a/tools/perf/arch/s390/Makefile b/tools/perf/arch/s390/Makefile index 74bffbea03e2..27cf67f1cc78 100644 --- a/tools/perf/arch/s390/Makefile +++ b/tools/perf/arch/s390/Makefile @@ -10,7 +10,8 @@ PERF_HAVE_JITDUMP := 1 # Syscall table generation for perf # -out:= $(OUTPUT)arch/s390/include/generated/asm +generated := $(OUTPUT)arch/s390/include/generated +out:= $(generated)/asm header := $(out)/syscalls_64.c sysprf := $(srctree)/tools/perf/arch/s390/entry/syscalls sysdef := $(sysprf)/syscall.tbl @@ -23,6 +24,6 @@ $(header): $(sysdef) $(systbl) $(Q)$(SHELL) '$(systbl)' $(sysdef) > $@ clean:: - $(call QUIET_CLEAN, s390) $(RM) $(header) + $(call QUIET_CLEAN, s390) $(RM) -r $(header) $(generted) archheaders: $(header) -- 2.27.0
[PATCH 2/2] Perf: Clean beauty directory.
Clean up generated beauty directory. Suggested-by: Arnaldo Carvalho de Melo Signed-off-by: Andreas Wendleder --- tools/perf/Makefile.perf | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 5345ac70cd83..293e297f719d 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -1087,6 +1087,7 @@ clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clea $(OUTPUT)$(sync_file_range_arrays) $(call QUIET_CLEAN, Documentation) \ $(MAKE) -C $(DOC_DIR) O=$(OUTPUT) clean >/dev/null + $(call QUIET_CLEAN, beauty) $(RM) -r $(beauty_outdir) # # To provide FEATURE-DUMP into $(FEATURE_DUMP_COPY) -- 2.27.0
Re: [PATCH v1 12/15] powerpc/uaccess: Refactor get/put_user() and __get/put_user()
Hi Christophe,
I love your patch! Perhaps something to improve:
[auto build test WARNING on powerpc/next]
[also build test WARNING on v5.12-rc2 next-20210305]
[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/Christophe-Leroy/powerpc-Cleanup-of-uaccess-h/20210226-015715
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-s031-20210307 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-245-gacc5c298-dirty
#
https://github.com/0day-ci/linux/commit/449bdbf978936e67e4919be8be0eec3e490a65e2
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christophe-Leroy/powerpc-Cleanup-of-uaccess-h/20210226-015715
git checkout 449bdbf978936e67e4919be8be0eec3e490a65e2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: sparse: incorrect type in
>> initializer (different address spaces) @@ expected char [noderef] __user
>> *_pu_addr @@ got char *buf @@
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: expected char [noderef]
__user *_pu_addr
drivers/w1/slaves/w1_ds28e04.c:342:13: sparse: got char *buf
>> drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: sparse: incorrect type in
>> initializer (different address spaces) @@ expected char const [noderef]
>> __user *_gu_addr @@ got char const *buf @@
drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: expected char const
[noderef] __user *_gu_addr
drivers/w1/slaves/w1_ds28e04.c:356:13: sparse: got char const *buf
--
drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: sparse: cast removes
address space '__user' of expression
drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: sparse: cast removes
address space '__user' of expression
>> drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: sparse: incorrect type
>> in initializer (different address spaces) @@ expected unsigned int
>> [noderef] __user *_pu_addr @@ got unsigned int [usertype] * @@
drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: expected unsigned
int [noderef] __user *_pu_addr
drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: got unsigned int
[usertype] *
drivers/gpu/drm/radeon/radeon_ttm.c:933:21: sparse: sparse: cast removes
address space '__user' of expression
vim +342 drivers/w1/slaves/w1_ds28e04.c
fa33a65a9cf7e2 Greg Kroah-Hartman 2013-08-21 338
fa33a65a9cf7e2 Greg Kroah-Hartman 2013-08-21 339 static ssize_t
crccheck_show(struct device *dev, struct device_attribute *attr,
fa33a65a9cf7e2 Greg Kroah-Hartman 2013-08-21 340
char *buf)
fbf7f7b4e2ae40 Markus Franke 2012-05-26 341 {
fbf7f7b4e2ae40 Markus Franke 2012-05-26 @342 if
(put_user(w1_enable_crccheck + 0x30, buf))
fbf7f7b4e2ae40 Markus Franke 2012-05-26 343 return -EFAULT;
fbf7f7b4e2ae40 Markus Franke 2012-05-26 344
fbf7f7b4e2ae40 Markus Franke 2012-05-26 345 return
sizeof(w1_enable_crccheck);
fbf7f7b4e2ae40 Markus Franke 2012-05-26 346 }
fbf7f7b4e2ae40 Markus Franke 2012-05-26 347
fa33a65a9cf7e2 Greg Kroah-Hartman 2013-08-21 348 static ssize_t
crccheck_store(struct device *dev, struct device_attribute *attr,
fbf7f7b4e2ae40 Markus Franke 2012-05-26 349
const char *buf, size_t count)
fbf7f7b4e2ae40 Markus Franke 2012-05-26 350 {
fbf7f7b4e2ae40 Markus Franke 2012-05-26 351 char val;
fbf7f7b4e2ae40 Markus Franke 2012-05-26 352
fbf7f7b4e2ae40 Markus Franke 2012-05-26 353 if (count != 1 || !buf)
fbf7f7b4e2ae40 Markus Franke 2012-05-26 354 return -EINVAL;
fbf7f7b4e2ae40 Markus Franke 2012-05-26 355
fbf7f7b4e2ae40 Markus Franke 2012-05-26 @356 if (get_user(val, buf))
fbf7f7b4e2ae40 Markus Franke 2012-05-26 357 return -EFAULT;
fbf7f7b4e2ae40 Markus Franke 2012-05-26 358
fbf7f7b4e2ae40 Markus Franke 2012-05-26 359 /* convert to decimal */
fbf7f7b4e2ae40 Markus Franke 2012-05-26 360 val = val - 0x30;
fbf7f7b4e2ae40 Markus Franke
[GIT PULL] Please pull powerpc/linux.git powerpc-5.12-2 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull powerpc fixes for 5.12: The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8: Linux 5.12-rc1 (2021-02-28 16:05:19 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.12-2 for you to fetch changes up to 5c88a17e15795226b56d83f579cbb9b7a4864f79: powerpc/sstep: Fix VSX instruction emulation (2021-03-02 22:41:51 +1100) - -- powerpc fixes for 5.12 #2 One non-fix, the conversion of vio_driver->remove() to return void, which touches various powerpc specific drivers. Fix the privilege checks we do in our perf handling, which could cause soft/hard lockups in some configurations. Fix a bug with IRQ affinity seen on kdump kernels when CPU 0 is offline in the second kernel. Fix missed page faults after mprotect(..., PROT_NONE) on 603 (32-bit). Fix a bug in our VSX (vector) instruction emulation, which should only be seen when doing VSX ops to cache inhibited mappings. Three commits fixing various build issues with obscure configurations. Thanks to: Athira Rajeev, Cédric Le Goater, Christophe Leroy, Christoph Plattner, Greg Kurz, Jordan Niethe, Laurent Vivier, Ravi Bangoria, Tyrel Datwyler, Uwe Kleine-König. - -- Athira Rajeev (1): powerpc/perf: Fix handling of privilege level checks in perf interrupt context Christophe Leroy (3): powerpc/603: Fix protection of user pages mapped with PROT_NONE powerpc/syscall: Force inlining of __prep_irq_for_enabled_exit() powerpc: Force inlining of mmu_has_feature to fix build failure Greg Kurz (1): powerpc/pseries: Don't enforce MSI affinity with kdump Jordan Niethe (1): powerpc/sstep: Fix VSX instruction emulation Michael Ellerman (1): powerpc/4xx: Fix build errors from mfdcr() Uwe Kleine-König (1): vio: make remove callback return void arch/powerpc/include/asm/dcr-native.h| 8 +++ arch/powerpc/include/asm/mmu.h | 4 ++-- arch/powerpc/include/asm/vio.h | 2 +- arch/powerpc/kernel/head_book3s_32.S | 9 --- arch/powerpc/kernel/interrupt.c | 2 +- arch/powerpc/lib/sstep.c | 4 ++-- arch/powerpc/perf/core-book3s.c | 4 ++-- arch/powerpc/platforms/pseries/msi.c | 25 ++-- arch/powerpc/platforms/pseries/vio.c | 7 +++--- drivers/char/hw_random/pseries-rng.c | 3 +-- drivers/char/tpm/tpm_ibmvtpm.c | 4 +--- drivers/crypto/nx/nx-842-pseries.c | 4 +--- drivers/crypto/nx/nx.c | 4 +--- drivers/misc/ibmvmc.c| 4 +--- drivers/net/ethernet/ibm/ibmveth.c | 4 +--- drivers/net/ethernet/ibm/ibmvnic.c | 5 +--- drivers/scsi/ibmvscsi/ibmvfc.c | 3 +-- drivers/scsi/ibmvscsi/ibmvscsi.c | 4 +--- drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 4 +--- drivers/tty/hvc/hvcs.c | 4 +--- 20 files changed, 55 insertions(+), 53 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBEqeAACgkQUevqPMjh pYALkRAAhMzfrU//Dw1pykwjlJhF6TccHSjmLh5y5V3qq95yXdhogx/XamGsuxZx s0hAET3La+2HC75ZVtLbfDct1ZuFNUAqR7n/pyPINTqhAYPeB9VoVRSl7nLL8U19 dhxPKmtb1dBvEQFxtBO7Q5dka3S33sc1dX/ATqhXNeHpEgsN6FT99qOXzOHo3VdR X/i+yXIoTh72f565sxxW/Ca2apy0cfdwwAwsK+S63s9Sxmsx+sF3mtY/rZs04rzg JzsI14empb8nvz8EUJfk+In4uk9+BZxRF92OTGHvCkp6ptv+JtYT2A4h/JWnr0Vq kS40Xwqwa62tvevUgKYcjSvaCsoC5sTaETqV/5WPIIKvXjVe5DMoZWv/JqOGRGHF i4IbnIBEXYodcKaRto7/yNFgCvaInKjVHC1qX46ft809mfRIJlz0akUNwvIl8nRa o479MJpBVtSf+3e491InY26RCpwaBmEB2KM3pR30TZV4jFSWZN55cnJuVW1wj0Gg b1ObTrjJ/WjnIDUxLN2Hq4f60RWWhfxJtq9IplnWNM9kPx9AJRaUvlzS0Z2A7yFa eSNCJlV2aXhJUGOYhVM7FMgHd0HcmF00LC22X+mfxlKbAEm1ys9VmoFPhtnkUMLX menb5yEDGlVq+bDa0ChBUYmFx8jHbyF88YRo16TmtutW4trAr4I= =lgtl -END PGP SIGNATURE-
Re: [RFC PATCH v2 13/13] objtool: arm64: Enable stack validation for arm64
On Wed, 3 Mar 2021 at 18:10, Julien Thierry wrote: > > From: Raphael Gault > > Add build option to run stack validation at compile time. > > When requiring stack validation, jump tables are disabled as it > simplifies objtool analysis (without having to introduce unreliable > artifacs). In local testing, this does not appear to significaly > affect final binary size nor system performance. > > Signed-off-by: Raphael Gault > Signed-off-by: Julien Thierry > --- > arch/arm64/Kconfig | 1 + > arch/arm64/Makefile | 4 > 2 files changed, 5 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1f212b47a48a..928323c03318 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -187,6 +187,7 @@ config ARM64 > select MMU_GATHER_RCU_TABLE_FREE > select HAVE_RSEQ > select HAVE_STACKPROTECTOR > + select HAVE_STACK_VALIDATION > select HAVE_SYSCALL_TRACEPOINTS > select HAVE_KPROBES > select HAVE_KRETPROBES > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 5b84aec31ed3..b819fb2e8eda 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -136,6 +136,10 @@ ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y) >CC_FLAGS_FTRACE := -fpatchable-function-entry=2 > endif > > +ifeq ($(CONFIG_STACK_VALIDATION),y) > +KBUILD_CFLAGS += -fno-jump-tables > +endif > + This is a bit misleading: the Kconfig option in question is selected automatically in all cases, so jump tables are always disabled. However, I think disabling jump tables make sense anyway, at least when building the relocatable kernel for KASLR: we currently don't use -fpic/fpie in that case when building the vmlinux objects (because we don't want/need GOT tables), and so jump tables are emitted using absolute addresses, which induce some space overhead in the image. (24 bytes of RELA data per absolute address) ... unless I am missing something, and jump tables can/will be emitted as relative, even when not compiling in PIC mode? > # Default value > head-y := arch/arm64/kernel/head.o > > -- > 2.25.4 >
Re: [PATCH] ath: ath6kl: fix error return code of ath6kl_htc_rx_bundle()
On 07.03.2021 10:31, Jia-Ju Bai wrote:
> Hi Leon,
>
> I am quite sorry for my incorrect patches...
> My static analysis tool reports some possible bugs about error handling code,
> and thus I write some patches for the bugs that seem to be true in my opinion.
> Because I am not familiar with many device drivers, some of my reported bugs
> can be false positives...
Then, before posting a patch for a driver, get familiar with it to
an extent that you can identify false positives. Relying on others
to detect the false positives is not the best approach.
>
>
> Best wishes,
> Jia-Ju Bai
>
> On 2021/3/7 17:18, Leon Romanovsky wrote:
>> On Sun, Mar 07, 2021 at 01:07:57AM -0800, Jia-Ju Bai wrote:
>>> When hif_scatter_req_get() returns NULL to scat_req, no error return
>>> code of ath6kl_htc_rx_bundle() is assigned.
>>> To fix this bug, status is assigned with -EINVAL in this case.
>>>
>>> Reported-by: TOTE Robot
>>> Signed-off-by: Jia-Ju Bai
>>> ---
>>> drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
>>> b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
>>> index 998947ef63b6..3f8857d19a0c 100644
>>> --- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
>>> +++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
>>> @@ -1944,8 +1944,10 @@ static int ath6kl_htc_rx_bundle(struct htc_target
>>> *target,
>>>
>>> scat_req = hif_scatter_req_get(target->dev->ar);
>>>
>>> - if (scat_req == NULL)
>>> + if (scat_req == NULL) {
>>> + status = -EINVAL;
>> I'm not sure about it.
>>
>> David. Jakub,
>> Please be warned that patches from this guy are not so great.
>> I looked on 4 patches and 3 of them were wrong (2 in RDMA and 1 for mlx5)
>> plus this patch most likely is incorrect too.
>>
[PATCH V2] arm64: dts: imx8mp: add wdog2/3 nodes
From: Peng Fan
There is wdog[2,3] in i.MX8MP, so add them.
Signed-off-by: Peng Fan
---
V2:
Update commit log
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index c7523fd4eae9..05dd04116f2e 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -312,6 +312,22 @@ wdog1: watchdog@3028 {
status = "disabled";
};
+ wdog2: watchdog@3029 {
+ compatible = "fsl,imx8mp-wdt", "fsl,imx21-wdt";
+ reg = <0x3029 0x1>;
+ interrupts = ;
+ clocks = <&clk IMX8MP_CLK_WDOG2_ROOT>;
+ status = "disabled";
+ };
+
+ wdog3: watchdog@302a {
+ compatible = "fsl,imx8mp-wdt", "fsl,imx21-wdt";
+ reg = <0x302a 0x1>;
+ interrupts = ;
+ clocks = <&clk IMX8MP_CLK_WDOG3_ROOT>;
+ status = "disabled";
+ };
+
iomuxc: pinctrl@3033 {
compatible = "fsl,imx8mp-iomuxc";
reg = <0x3033 0x1>;
--
2.30.0
Re: [PATCH] CIFS: Prevent error log on spurious oplock break
Hi Vincent,
The reason for rejecting the request maybe a number of things like:
corrupted request, stale request (for some old session), or for a
wrong handle.
I don't think we should treat any of these cases as a success.
Also, from the MS-SMB2 documentation:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/4f35576a-6f3b-40f0-a832-1c30b0afccb3
"The client MUST locate the file in the GlobalFileTable using the
LeaseKey in the Lease Break Notification. If a file is not found, no
further processing is required."
So I don't think we should be changing the logic here.
If SMB v1 had a different behaviour, we should check if that is as per
the protocol documentation. If not, change it.
Regards,
Shyam
On Fri, Mar 5, 2021 at 3:12 PM Vincent Whitchurch
wrote:
>
> The SMB1 version of ->is_oplock_break() returns true even if the FileId
> is not found, as long as the oplock break notification message structure
> itself appears to be valid. A true return value makes
> cifs_demultiplex_thread() to not print an error message for such
> packets.
>
> However, the SMB2 version returns false in such cases, leading to an
> error "No task to wake, unknown frame received!" followed by a hexdump
> of the packet header being printed by cifs_demultiplex_thread().
>
> Note that before commit fa9c2362497fbd64788063288d ("CIFS: Fix SMB2
> oplock break processing"), SMB2 also returned true for the case where a
> connection was found but the FileId was not, but it's not clear to me if
> that commit really intended to change the behaviour of the error prints.
>
> Change the behaviour of SMB2 to be the same as SMB1 and avoid the error
> messages for these packets which we ignore as per the spec.
>
> Signed-off-by: Vincent Whitchurch
> ---
> fs/cifs/smb2misc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
> index 60d4bd1eae2b..3ea3bda64083 100644
> --- a/fs/cifs/smb2misc.c
> +++ b/fs/cifs/smb2misc.c
> @@ -679,7 +679,7 @@ smb2_is_valid_lease_break(char *buffer)
> }
> spin_unlock(&cifs_tcp_ses_lock);
> cifs_dbg(FYI, "Can not process lease break - no lease matched\n");
> - return false;
> + return true;
> }
>
> bool
> @@ -755,7 +755,7 @@ smb2_is_valid_oplock_break(char *buffer, struct
> TCP_Server_Info *server)
> }
> spin_unlock(&cifs_tcp_ses_lock);
> cifs_dbg(FYI, "Can not process oplock break for non-existent
> connection\n");
> - return false;
> + return true;
> }
>
> void
> --
> 2.28.0
>
--
Regards,
Shyam
[PATCH] drivers: tty: vt: vt.c: fix NULL dereference crash
Fix a NULL deference crash on hiding the cursor. Reported by: syzbot https://syzkaller.appspot.com/bug?id=defb47bf56e1c14d5687280c7bb91ce7b608b94b Signed-off-by: Hassan Shahbazi --- drivers/tty/vt/vt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 284b07224c55..8c3e83c81341 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -904,7 +904,9 @@ static void hide_cursor(struct vc_data *vc) if (vc_is_sel(vc)) clear_selection(); - vc->vc_sw->con_cursor(vc, CM_ERASE); + if (vc->vc_sw) + vc->vc_sw->con_cursor(vc, CM_ERASE); + hide_softcursor(vc); } -- 2.26.2
Linux 4.9.260
I'm announcing the release of the 4.9.260 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/filesystems/sysfs.txt |8 - Makefile|2 arch/arm/probes/kprobes/core.c |6 + arch/arm/xen/p2m.c | 35 + arch/arm64/include/asm/atomic_ll_sc.h | 109 +- arch/arm64/include/asm/atomic_lse.h | 46 +++ arch/arm64/include/asm/cmpxchg.h| 116 +-- arch/x86/kernel/module.c|1 arch/x86/kernel/reboot.c|9 + arch/x86/tools/relocs.c | 12 +- arch/x86/xen/p2m.c | 44 ++- drivers/block/zram/zram_drv.c |2 drivers/media/usb/uvc/uvc_driver.c |7 - drivers/media/v4l2-core/v4l2-ioctl.c| 19 +-- drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 -- drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 -- drivers/net/wireless/ti/wlcore/wlcore.h |3 drivers/net/xen-netback/netback.c | 12 +- drivers/scsi/libiscsi.c | 148 - drivers/scsi/scsi_transport_iscsi.c | 38 +- drivers/staging/fwserial/fwserial.c |2 drivers/staging/most/aim-sound/sound.c |2 drivers/tty/vt/consolemap.c |2 fs/jfs/jfs_filsys.h |1 fs/jfs/jfs_mount.c | 10 + fs/sysfs/file.c | 55 + fs/xfs/xfs_iops.c |2 include/linux/sysfs.h | 16 ++ include/linux/zsmalloc.h|2 kernel/futex.c | 188 kernel/printk/nmi.c | 16 ++ mm/hugetlb.c| 28 ++-- mm/page_io.c| 11 - mm/swapfile.c |2 mm/zsmalloc.c | 17 +- net/bluetooth/amp.c |3 net/core/pktgen.c |2 net/core/skbuff.c | 14 ++ scripts/Makefile|9 + security/smack/smackfs.c| 21 +++ 42 files changed, 668 insertions(+), 386 deletions(-) Andrew Murray (1): arm64: Use correct ll/sc atomic constraints Ben Hutchings (7): futex: Cleanup variable names for futex_top_waiter() futex: Cleanup refcounting futex: Pull rt_mutex_futex_unlock() out from under hb->lock futex: Futex_unlock_pi() determinism futex: Fix pi_state->owner serialization futex: Fix more put_pi_state() vs. exit_pi_state_list() races futex: Don't enable IRQs unconditionally in put_pi_state() Chris Leech (2): scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE scsi: iscsi: Verify lengths on passthrough PDUs Christian Gromm (1): staging: most: sound: add sanity check for function argument Di Zhu (1): pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() Dinghao Liu (1): staging: fwserial: Fix error handling in fwserial_create Fangrui Song (1): x86/build: Treat R_386_PLT32 relocation as R_386_PC32 Gopal Tiwari (1): Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data Greg Kroah-Hartman (1): Linux 4.9.260 Heiner Kallweit (1): x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk Jan Beulich (2): Xen/gnttab: handle p2m update errors on a per-slot basis xen-netback: respect gnttab_map_refs()'s return value Jens Axboe (1): swap: fix swapfile read/write offset Jiri Slaby (1): vt/consolemap: do font sum unsigned Joe Perches (1): sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output Lech Perczak (1): net: usb: qmi_wwan: support ZTE P685M modem Lee Duncan (1): scsi: iscsi: Restrict sessions and handles to admin capabilities Li Xinhai (1): mm/hugetlb.c: fix unnecessary address expansion of pmd sharing Marco Elver (1): net: fix up truesize of cloned skb in skb_prepare_for_shift() Masami Hiramatsu (1): arm: kprobes: Allow to handle reentered kprobe on single-stepping Miaoqing Pan (1): ath10k: fix wmi mgmt tx queue full due to race condition Mike Kravetz (1): hugetlb: fix update_and_free_page contig page struct assumption Muchun Song (1): printk: fix deadlock when kernel panic Randy Dunlap (1): JFS: more checks for invalid superblock Ricardo Ribalda (1): media: uvcvideo: Allow entities with no pads Rob
Re: Linux 4.4.260
diff --git a/Documentation/filesystems/sysfs.txt
b/Documentation/filesystems/sysfs.txt
index 24da7b32c489..1218a5e2975c 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -211,12 +211,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/Makefile b/Makefile
index a8c906a79f34..7efb6921d9de 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 259
+SUBLEVEL = 260
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 02579e6569f0..b4ec8d1b0bef 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -91,12 +91,39 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
int i;
for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >>
XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+* Signal an error for this slot. This in turn requires
+* immediate unmapping.
+*/
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+* Pre-populate the status field, to be recognizable in
+* the log message below.
+*/
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}
return 0;
diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
index 94779f66bf49..6f0d340594ca 100644
--- a/arch/x86/kernel/module.c
+++ b/arch/x86/kernel/module.c
@@ -124,6 +124,7 @@ int apply_relocate(Elf32_Shdr *sechdrs,
*location += sym->st_value;
break;
case R_386_PC32:
+ case R_386_PLT32:
/* Add the value, subtract its position */
*location += sym->st_value - (uint32_t)location;
break;
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index cbe14f7c2826..1c2451107e49 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -418,6 +418,15 @@ static struct dmi_system_id __initdata reboot_dmi_table[]
= {
},
},
+ { /* PCIe Wifi card isn't detected after reboot otherwise */
+ .callback = set_pci_reboot,
+ .ident = "Zotac ZBOX CI327 nano",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "NA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ZBOX-CI327NANO-GS-01"),
+ },
+ },
+
/* Sony */
{ /* Handle problems with rebooting on Sony VGN-Z540N */
.callback = set_bios_reboot,
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5b6c8486a0be..d1c3f82c7882 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -839,9 +839,11 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel,
Elf_Sym *sym,
case R_386_PC32:
case R_386_PC16:
case R_386_PC8:
+ case R_386_PLT32:
/*
-* NONE can be ignored and PC relative relocations don't
-* need to be adjusted.
+* NONE can be ignored and PC relative relocations don't need
+* to be adjusted. Because sym must
Linux 4.14.224
I'm announcing the release of the 4.14.224 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/btusb.txt |2 Documentation/filesystems/sysfs.txt |8 - Makefile|2 arch/arm/xen/p2m.c | 35 + arch/arm64/include/asm/atomic_ll_sc.h | 108 + arch/arm64/include/asm/atomic_lse.h | 46 +++ arch/arm64/include/asm/cmpxchg.h| 116 +- arch/arm64/kernel/module.lds|6 arch/parisc/kernel/irq.c|4 arch/x86/kernel/module.c|1 arch/x86/kernel/reboot.c|9 + arch/x86/tools/relocs.c | 12 + arch/x86/xen/p2m.c | 44 ++- drivers/block/zram/zram_drv.c |2 drivers/gpu/drm/virtio/virtgpu_vq.c |6 drivers/media/rc/mceusb.c |9 + drivers/media/usb/uvc/uvc_driver.c |7 - drivers/media/v4l2-core/v4l2-ioctl.c| 19 +-- drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 -- drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 -- drivers/net/wireless/ti/wlcore/wlcore.h |3 drivers/net/xen-netback/netback.c | 12 + drivers/s390/virtio/virtio_ccw.c|4 drivers/scsi/libiscsi.c | 148 drivers/scsi/scsi_transport_iscsi.c | 38 -- drivers/staging/fwserial/fwserial.c |2 drivers/staging/most/aim-sound/sound.c |2 drivers/tty/vt/consolemap.c |2 fs/f2fs/segment.h |4 fs/jfs/jfs_filsys.h |1 fs/jfs/jfs_mount.c | 10 + fs/sysfs/file.c | 55 fs/xfs/xfs_iops.c |2 include/linux/sysfs.h | 16 ++ include/linux/zsmalloc.h|2 mm/hugetlb.c| 28 ++-- mm/page_io.c| 11 - mm/swapfile.c |2 mm/zsmalloc.c | 17 +- net/bluetooth/amp.c |3 net/bridge/br_sysfs_if.c|9 - net/core/pktgen.c |2 net/core/skbuff.c | 14 ++ scripts/Makefile|9 + security/smack/smackfs.c| 21 +++ 47 files changed, 558 insertions(+), 329 deletions(-) Andrew Murray (1): arm64: Use correct ll/sc atomic constraints Chris Leech (2): scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE scsi: iscsi: Verify lengths on passthrough PDUs Christian Gromm (1): staging: most: sound: add sanity check for function argument Cornelia Huck (1): virtio/s390: implement virtio-ccw revision 2 correctly Di Zhu (1): pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() Dinghao Liu (1): staging: fwserial: Fix error handling in fwserial_create Fangrui Song (1): x86/build: Treat R_386_PLT32 relocation as R_386_PC32 Geert Uytterhoeven (1): dt-bindings: net: btusb: DT fix s/interrupt-name/interrupt-names/ Gopal Tiwari (1): Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data Greg Kroah-Hartman (1): Linux 4.14.224 Heiner Kallweit (1): x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk Jaegeuk Kim (1): f2fs: handle unallocated section and zone on pinned/atgc Jan Beulich (2): Xen/gnttab: handle p2m update errors on a per-slot basis xen-netback: respect gnttab_map_refs()'s return value Jens Axboe (1): swap: fix swapfile read/write offset Jiri Slaby (1): vt/consolemap: do font sum unsigned Joe Perches (1): sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output John David Anglin (1): parisc: Bump 64-bit IRQ stack size to 64 KB Lech Perczak (1): net: usb: qmi_wwan: support ZTE P685M modem Lee Duncan (1): scsi: iscsi: Restrict sessions and handles to admin capabilities Li Xinhai (1): mm/hugetlb.c: fix unnecessary address expansion of pmd sharing Marco Elver (1): net: fix up tr
Re: Linux 4.14.224
diff --git a/Documentation/devicetree/bindings/net/btusb.txt
b/Documentation/devicetree/bindings/net/btusb.txt
index 9c5e663fa1af..828a04695e1b 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -36,7 +36,7 @@ Following example uses irq pin number 3 of gpio0 for out of
band wake-on-bt:
compatible = "usb1286,204e";
reg = <1>;
interrupt-parent = <&gpio0>;
- interrupt-name = "wakeup";
+ interrupt-names = "wakeup";
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
};
};
diff --git a/Documentation/filesystems/sysfs.txt
b/Documentation/filesystems/sysfs.txt
index 9a3658cc399e..6ff1b9899fd0 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -211,12 +211,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/Makefile b/Makefile
index b8ab01786d09..eda72c1ca13a 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 223
+SUBLEVEL = 224
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index ce538c51fa3f..8a8a388549e7 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -91,12 +91,39 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
int i;
for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >>
XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+* Signal an error for this slot. This in turn requires
+* immediate unmapping.
+*/
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+* Pre-populate the status field, to be recognizable in
+* the log message below.
+*/
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}
return 0;
diff --git a/arch/arm64/include/asm/atomic_ll_sc.h
b/arch/arm64/include/asm/atomic_ll_sc.h
index f5a2d09afb38..1cc42441bc67 100644
--- a/arch/arm64/include/asm/atomic_ll_sc.h
+++ b/arch/arm64/include/asm/atomic_ll_sc.h
@@ -37,7 +37,7 @@
* (the optimize attribute silently ignores these options).
*/
-#define ATOMIC_OP(op, asm_op) \
+#define ATOMIC_OP(op, asm_op, constraint) \
__LL_SC_INLINE void\
__LL_SC_PREFIX(atomic_##op(int i, atomic_t *v))
\
{ \
@@ -51,11 +51,11 @@ __LL_SC_PREFIX(atomic_##op(int i, atomic_t *v))
\
" stxr%w1, %w0, %2\n" \
" cbnz%w1, 1b"\
: "=&r" (result), "=&r" (tmp), "+Q" (v->counter)\
- : "Ir" (i));\
+ : #constraint "r" (i)); \
} \
__LL_SC_EXPORT(atomic_##op);
-#define ATOMIC_OP_RETURN(name, mb, acq, rel, cl, op, asm_op) \
+#d
Re: Linux 4.9.260
diff --git a/Documentation/filesystems/sysfs.txt
b/Documentation/filesystems/sysfs.txt
index 24da7b32c489..1218a5e2975c 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -211,12 +211,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/Makefile b/Makefile
index cdc71bda92c4..7a29676e2b2f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 259
+SUBLEVEL = 260
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/probes/kprobes/core.c b/arch/arm/probes/kprobes/core.c
index 3eb018fa1a1f..c3362ddd6c4c 100644
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -270,6 +270,7 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
switch (kcb->kprobe_status) {
case KPROBE_HIT_ACTIVE:
case KPROBE_HIT_SSDONE:
+ case KPROBE_HIT_SS:
/* A pre- or post-handler probe got us here. */
kprobes_inc_nmissed_count(p);
save_previous_kprobe(kcb);
@@ -278,6 +279,11 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
singlestep(p, regs, kcb);
restore_previous_kprobe(kcb);
break;
+ case KPROBE_REENTER:
+ /* A nested probe was hit in FIQ, it is a BUG */
+ pr_warn("Unrecoverable kprobe detected at
%p.\n",
+ p->addr);
+ /* fall through */
default:
/* impossible cases */
BUG();
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index 02579e6569f0..b4ec8d1b0bef 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -91,12 +91,39 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
int i;
for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >>
XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+* Signal an error for this slot. This in turn requires
+* immediate unmapping.
+*/
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+* Pre-populate the status field, to be recognizable in
+* the log message below.
+*/
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}
return 0;
diff --git a/arch/arm64/include/asm/atomic_ll_sc.h
b/arch/arm64/include/asm/atomic_ll_sc.h
index f819fdcff1ac..1cc42441bc67 100644
--- a/arch/arm64/include/asm/atomic_ll_sc.h
+++ b/arch/arm64/include/asm/atomic_ll_sc.h
@@ -37,7 +37,7 @@
* (the optimize attribute silently ignores these options).
*/
-#define ATOMIC_OP(op, asm_op) \
+#define ATOMIC_OP(op, asm_op, constraint) \
__LL_SC_INLINE void\
__LL_SC_PREFIX(atomic_##op(int i, atomic_t *v))
\
{
Linux 4.4.260
I'm announcing the release of the 4.4.260 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/filesystems/sysfs.txt |8 - Makefile|2 arch/arm/xen/p2m.c | 35 ++- arch/x86/kernel/module.c|1 arch/x86/kernel/reboot.c|9 + arch/x86/tools/relocs.c | 12 +- arch/x86/xen/p2m.c | 44 - drivers/block/zram/zram_drv.c |2 drivers/media/usb/uvc/uvc_driver.c |7 + drivers/media/v4l2-core/v4l2-ioctl.c| 19 +--- drivers/mmc/host/sdhci-esdhc-imx.c |3 drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 --- drivers/net/wireless/iwlwifi/pcie/tx.c |4 drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 --- drivers/net/wireless/ti/wlcore/wlcore.h |3 drivers/net/xen-netback/netback.c | 12 ++ drivers/scsi/libiscsi.c | 148 drivers/scsi/scsi_transport_iscsi.c | 38 ++-- drivers/staging/fwserial/fwserial.c |2 drivers/staging/most/aim-sound/sound.c |2 drivers/tty/vt/consolemap.c |2 fs/jfs/jfs_filsys.h |1 fs/jfs/jfs_mount.c | 10 ++ fs/sysfs/file.c | 55 +++ fs/xfs/xfs_iops.c |2 include/linux/sysfs.h | 16 +++ include/linux/zsmalloc.h|2 kernel/futex.c | 24 ++--- mm/hugetlb.c| 28 +++--- mm/page_io.c| 11 -- mm/swapfile.c |2 mm/zsmalloc.c | 17 ++- net/bluetooth/amp.c |3 net/core/pktgen.c |2 net/core/skbuff.c | 14 ++- scripts/Makefile|9 + 38 files changed, 389 insertions(+), 194 deletions(-) Chris Leech (2): scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE scsi: iscsi: Verify lengths on passthrough PDUs Christian Gromm (1): staging: most: sound: add sanity check for function argument Di Zhu (1): pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() Dinghao Liu (1): staging: fwserial: Fix error handling in fwserial_create Fangrui Song (1): x86/build: Treat R_386_PLT32 relocation as R_386_PC32 Frank Li (1): mmc: sdhci-esdhc-imx: fix kernel panic when remove module Gopal Tiwari (1): Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data Greg Kroah-Hartman (1): Linux 4.4.260 Heiner Kallweit (1): x86/reboot: Add Zotac ZBOX CI327 nano PCI reboot quirk Jan Beulich (2): Xen/gnttab: handle p2m update errors on a per-slot basis xen-netback: respect gnttab_map_refs()'s return value Jens Axboe (1): swap: fix swapfile read/write offset Jiri Slaby (1): vt/consolemap: do font sum unsigned Joe Perches (1): sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output Lech Perczak (1): net: usb: qmi_wwan: support ZTE P685M modem Lee Duncan (1): scsi: iscsi: Restrict sessions and handles to admin capabilities Li Xinhai (1): mm/hugetlb.c: fix unnecessary address expansion of pmd sharing Marco Elver (1): net: fix up truesize of cloned skb in skb_prepare_for_shift() Miaoqing Pan (1): ath10k: fix wmi mgmt tx queue full due to race condition Mike Kravetz (1): hugetlb: fix update_and_free_page contig page struct assumption Nobuhiro Iwamatsu (1): iwlwifi: pcie: fix to correct null check Randy Dunlap (1): JFS: more checks for invalid superblock Ricardo Ribalda (1): media: uvcvideo: Allow entities with no pads Rokudo Yan (1): zsmalloc: account the number of compacted pages correctly Rolf Eike Beer (2): scripts: use pkg-config to locate libcrypto scripts: set proper OpenSSL include dir also for sign-file Sakari Ailus (1): media: v4l: ioctl: Fix memory leak in video_usercopy Thomas Gleixner (1): futex: Ensure the correct return value from futex_lock_pi() Tony Lindgren (1): wlcore: Fix command execute failure 19 for wl12xx Yumei Huang (1): xfs: Fix assert failure in xfs_setattr_size()
TREAT AND REPLY URGENTLY.
Dear Friend, Greetings! How are you with your family today? I hope both of you are in good health decently, I know that this message might meet you in utmost surprise as we never know each other before. I am Mr. Dabire Basole a banker by profession, I need your urgent assist in transferring the sum of $10.5 Million U.S Dollars into your account. It is 100% risk free and under this achievement you are entitled to receive 40% of the total cash. More details will be sent to you on confirmation of your interest. Please if you are real interest on my proposer, just providing me your following information details such as: (1)NAME.. (2)AGE: (3)SEX:. (4)PHONE NUMBER:. (5)OCCUPATION: . (6)YOUR COUNTRY:. Yours sincerely, Mr. Dabire Basole.
[PATCH v6 0/8] Fork brute force attack mitigation
Attacks against vulnerable userspace applications with the purpose to break ASLR or bypass canaries traditionally use some level of brute force with the help of the fork system call. This is possible since when creating a new process using fork its memory contents are the same as those of the parent process (the process that called the fork system call). So, the attacker can test the memory infinite times to find the correct memory values or the correct memory addresses without worrying about crashing the application. Based on the above scenario it would be nice to have this detected and mitigated, and this is the goal of this patch serie. Specifically the following attacks are expected to be detected: 1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a desirable memory layout is got (e.g. Stack Clash). 2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly until a desirable memory layout is got (e.g. what CTFs do for simple network service). 3.- Launching processes without exec() (e.g. Android Zygote) and exposing state to attack a sibling. 4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly until the previously shared memory layout of all the other children is exposed (e.g. kind of related to HeartBleed). In each case, a privilege boundary has been crossed: Case 1: setuid/setgid process Case 2: network to local Case 3: privilege changes Case 4: network to local So, what will really be detected are fork/exec brute force attacks that cross any of the commented bounds. The implementation details and comparison against other existing implementations can be found in the "Documentation" patch. Knowing all this information I will explain now the different patches: The 1/8 patch defines a new LSM hook to get the fatal signal of a task. This will be useful during the attack detection phase. The 2/8 patch defines a new LSM and manages the statistical data shared by all the fork hierarchy processes. The 3/8 patch detects a fork/exec brute force attack. The 4/8 patch narrows the detection taken into account the privilege boundary crossing. The 5/8 patch mitigates a brute force attack. The 6/8 patch adds self-tests to validate the Brute LSM expectations. The 7/8 patch adds the documentation to explain this implementation. The 8/8 patch updates the maintainers file. This patch serie is a task of the KSPP [1] and can also be accessed from my github tree [2] in the "brute_v6" branch. [1] https://github.com/KSPP/linux/issues/39 [2] https://github.com/johwood/linux/ The previous versions can be found in: RFC https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keesc...@chromium.org/ Version 2 https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.w...@gmx.com/ Version 3 https://lore.kernel.org/lkml/20210221154919.68050-1-john.w...@gmx.com/ Version 4 https://lore.kernel.org/lkml/20210227150956.6022-1-john.w...@gmx.com/ Version 5 https://lore.kernel.org/kernel-hardening/20210227153013.6747-1-john.w...@gmx.com/ Changelog RFC -> v2 --- - Rename this feature with a more suitable name (Jann Horn, Kees Cook). - Convert the code to an LSM (Kees Cook). - Add locking to avoid data races (Jann Horn). - Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees Cook). - Add the last crashes timestamps list to avoid false positives in the attack detection (Jann Horn). - Use "period" instead of "rate" (Jann Horn). - Other minor changes suggested (Jann Horn, Kees Cook). Changelog v2 -> v3 -- - Compute the application crash period on an on-going basis (Kees Cook). - Detect a brute force attack through the execve system call (Kees Cook). - Detect an slow brute force attack (Randy Dunlap). - Fine tuning the detection taken into account privilege boundary crossing (Kees Cook). - Taken into account only fatal signals delivered by the kernel (Kees Cook). - Remove the sysctl attributes to fine tuning the detection (Kees Cook). - Remove the prctls to allow per process enabling/disabling (Kees Cook). - Improve the documentation (Kees Cook). - Fix some typos in the documentation (Randy Dunlap). - Add self-test to validate the expectations (Kees Cook). Changelog v3 -> v4 -- - Fix all the warnings shown by the tool "scripts/kernel-doc" (Randy Dunlap). Changelog v4 -> v5 -- - Fix some typos (Randy Dunlap). Changelog v5 -> v6 -- - Fix a reported deadlock (kernel test robot). - Add high level details to the documentation (Andi Kleen). Any constructive comments are welcome. Thanks. John Wood (8): security: Add LSM hook at the point where a task gets a fatal signal security/brute: Define a LSM and manage statistical data securtiy/brute: Detect a brute force attack security/brute: Fine tuning the attack detection security/brute: Mitigate a brute force attack selftests/brute: Add tests for the Brute LSM Docum
[PATCH net] net: lapbether: Remove netif_start_queue / netif_stop_queue
For the devices in this driver, the default qdisc is "noqueue",
because their "tx_queue_len" is 0.
In function "__dev_queue_xmit" in "net/core/dev.c", devices with the
"noqueue" qdisc are specially handled. Packets are transmitted without
being queued after a "dev->flags & IFF_UP" check. However, it's possible
that even if this check succeeds, "ops->ndo_stop" may still have already
been called. This is because in "__dev_close_many", "ops->ndo_stop" is
called before clearing the "IFF_UP" flag.
If we call "netif_stop_queue" in "ops->ndo_stop", then it's possible in
"__dev_queue_xmit", it sees the "IFF_UP" flag is present, and then it
checks "netif_xmit_stopped" and finds that the queue is already stopped.
In this case, it will complain that:
"Virtual device ... asks to queue packet!"
To prevent "__dev_queue_xmit" from generating this complaint, we should
not call "netif_stop_queue" in "ops->ndo_stop".
We also don't need to call "netif_start_queue" in "ops->ndo_open",
because after a netdev is allocated and registered, the
"__QUEUE_STATE_DRV_XOFF" flag is initially not set, so there is no need
to call "netif_start_queue" to clear it.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xie He
---
drivers/net/wan/lapbether.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c
index 605fe555e157..c3372498f4f1 100644
--- a/drivers/net/wan/lapbether.c
+++ b/drivers/net/wan/lapbether.c
@@ -292,7 +292,6 @@ static int lapbeth_open(struct net_device *dev)
return -ENODEV;
}
- netif_start_queue(dev);
return 0;
}
@@ -300,8 +299,6 @@ static int lapbeth_close(struct net_device *dev)
{
int err;
- netif_stop_queue(dev);
-
if ((err = lapb_unregister(dev)) != LAPB_OK)
pr_err("lapb_unregister error: %d\n", err);
--
2.27.0
[PATCH v2 0/2] docs: reporting-issues: a easier process for reporting stable regressions
This series creates a streamlined process for users wanting to report regressions within a stable and longterm kernel series. The existing process is too demanding, complicated and takes too much time for this case. I didn't CC the stable maintainers here, they need to review the whole document anyway once the last few details have been sorted out. v2: * inital version, starting straight with v2 to avoid confusion, as one of the patches was submitted earlier already Thorsten Leemhuis (2): docs: reporting-issues.rst: move tainted check upwards docs: reporting-issues.rst: shortcut for reporting stable regressions .../admin-guide/reporting-issues.rst | 222 +++--- 1 file changed, 135 insertions(+), 87 deletions(-) base-commit: ba5cb300e0b540a330d579402d72cdd1808e5a8f -- 2.29.2
[PATCH v2 2/2] docs: reporting-issues.rst: shortcut for reporting stable regressions
Provide a much shorter and easier process for users that deal with regressions in stable and longterm kernels, as those should be reported quickly. Signed-off-by: Thorsten Leemhuis CC: Randy Dunlap --- v2 * revist, lots of small improvements in various places v1 * https://lore.kernel.org/linux-doc/20210214145454.357392-1-li...@leemhuis.info/ * initial version --- .../admin-guide/reporting-issues.rst | 140 -- 1 file changed, 94 insertions(+), 46 deletions(-) diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index 24ee78455d3e..937797e52837 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -106,6 +106,10 @@ process won't feel wasted in the end: issue, or a really severe problem: those are 'issues of high priority' that need special handling in some steps that are about to follow. + * If you are facing a regression within a stable or longterm version line + (say something broke when updating from 5.10.4 to 5.10.5), head over to + 'Dealing with regressions within a stable and longterm kernel line'. + * Locate the driver or kernel subsystem that seems to be causing the issue. Find out how and where its developers expect reports. Note: most of the time this won't be bugzilla.kernel.org, as issues typically need to be sent @@ -215,23 +219,42 @@ rebased on new stable or longterm releases. If that case follow these steps: deemed unsuitable for backporting. If backporting was not considered at all, join the newest discussion, asking if it's in the cards. - * Check if you're dealing with a regression that was never present in - mainline by installing the first release of the version line you care - about. If the issue doesn't show up with it, you basically need to report - the issue with this version like you would report a problem with mainline - (see above). This ideally includes a bisection followed by a search for - existing reports on the net; with the help of the subject and the two - relevant commit-ids. If that doesn't turn up anything, write the report; CC - or forward the report to the stable maintainers, the stable mailing list, - and those who authored the change. Include the shortened commit-id if you - found the change that causes it. - * One of the former steps should lead to a solution. If that doesn't work out, ask the maintainers for the subsystem that seems to be causing the issue for advice; CC the mailing list for the particular subsystem as well as the stable mailing list. +Dealing with regressions within a stable and longterm kernel line +- + +This section is for you, if you face a regression within a stable or longterm +kernel version line, e.g. if something breaks when updating from 5.10.4 to +5.10.5 (a switch from 5.9.15 to 5.10.5 would not qualify). The developers want +to fix such regressions as quickly as possible, hence there is a streamlined +process to report them: + + * Check the archives of the Linux stable mailing list for existing reports. + + * Check if the kernel developers still maintain the Linux kernel version + line you care about: go to the front page of kernel.org and make sure it + mentions the latest release of the particular version line without an + '[EOL]' tag. + + * Install the latest release from the particular version line as a vanilla + kernel. Ensure this kernel is not tainted and still shows the problem, as + the issue might have already been fixed there. + + * Make sure it's not the kernel's surroundings that are causing the issue + you face. + + * Send a short problem report by mail to the people and mailing lists the + :ref:`MAINTAINERS ` file specifies in the section 'STABLE + BRANCH'. Roughly describe the issue and ideally explain how to reproduce + it. Mention the first version that shows the problem and the last version + that's working fine. Then wait for further instructions. + + Reference section: Reporting issues to the kernel maintainers = @@ -433,6 +456,22 @@ fatal error where the kernel stop itself) with a 'Oops' (a recoverable error), as the kernel remains running after the latter. +Regression in stable or longterm kernel? + + +*If you are facing a regression within a stable or longterm version line +(say something broke when updating from 5.10.4 to 5.10.5), head over to +'Dealing with regressions within a stable and longterm kernel line'.* + +Regression within a stable and longterm kernel version line are something the +Linux developers want to fix badly, as such issues are even more unwanted than +regression in the main development branch, as they can quickly affect a lot of +people. The developers thus want to learn ab
[PATCH v2 1/2] docs: reporting-issues.rst: move tainted check upwards
Move the instuctions to check tainted status upwards one step. This is
done in preparation for a follow up patch that introduces a new step
that should come after the 'check tainted status' step, but is best done
right after the 'check if this qualifies as regression, ...' step.
Just moves text around, no other changes.
Signed-off-by: Thorsten Leemhuis
---
.../admin-guide/reporting-issues.rst | 84 +--
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/Documentation/admin-guide/reporting-issues.rst
b/Documentation/admin-guide/reporting-issues.rst
index 18b1280f7abf..24ee78455d3e 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -99,13 +99,13 @@ process won't feel wasted in the end:
install it. This kernel must not be modified or enhanced in any way, and
thus be considered 'vanilla'.
+ * Check if your kernel was 'tainted' when the issue occurred, as the event
+ that made the kernel set this flag might be causing the issue you face.
+
* See if the issue you are dealing with qualifies as regression, security
issue, or a really severe problem: those are 'issues of high priority' that
need special handling in some steps that are about to follow.
- * Check if your kernel was 'tainted' when the issue occurred, as the event
- that made the kernel set this flag might be causing the issue you face.
-
* Locate the driver or kernel subsystem that seems to be causing the issue.
Find out how and where its developers expect reports. Note: most of the
time this won't be bugzilla.kernel.org, as issues typically need to be sent
@@ -326,45 +326,6 @@ just make sure to use really fresh kernel (see below).
Are there any other major Linux distributions that should be mentioned here?
-Issue of high priority?
-
-*See if the issue you are dealing with qualifies as regression, security
-issue, or a really severe problem: those are 'issues of high priority' that
-need special handling in some steps that are about to follow.*
-
-Linus Torvalds and the leading Linux kernel developers want to see some issues
-fixed as soon as possible, hence there are 'issues of high priority' that get
-handled slightly differently in the reporting process. Three type of cases
-qualify: regressions, security issues, and really severe problems.
-
-You deal with a 'regression' if something that worked with an older version of
-the Linux kernel does not work with a newer one or somehow works worse with it.
-It thus is a regression when a WiFi driver that did a fine job with Linux 5.7
-somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if
-an application shows erratic behavior with a newer kernel, which might happen
-due to incompatible changes in the interface between the kernel and the
-userland (like procfs and sysfs). Significantly reduced performance or
-increased power consumption also qualify as regression. But keep in mind: the
-new kernel needs to be built with a configuration that is similar to the one
-from the old kernel (see below how to achieve that). That's because the kernel
-developers sometimes can not avoid incompatibilities when implementing new
-features; but to avoid regressions such features have to be enabled explicitly
-during build time configuration.
-
-What qualifies as security issue is left to your judgment. Consider reading
-'Documentation/admin-guide/security-bugs.rst' before proceeding, as it
-provides additional details how to best handle security issues.
-
-An issue is a 'really severe problem' when something totally unacceptably bad
-happens. That's for example the case when a Linux kernel corrupts the data it's
-handling or damages hardware it's running on. You're also dealing with a severe
-issue when the kernel suddenly stops working with an error message ('kernel
-panic') or without any farewell note at all. Note: do not confuse a 'panic' (a
-fatal error where the kernel stop itself) with a 'Oops' (a recoverable error),
-as the kernel remains running after the latter.
-
-
Check 'taint' flag
--
@@ -433,6 +394,45 @@ three things:
the name of the module in question).
+Issue of high priority?
+---
+
+*See if the issue you are dealing with qualifies as regression, security
+issue, or a really severe problem: those are 'issues of high priority' that
+need special handling in some steps that are about to follow.*
+
+Linus Torvalds and the leading Linux kernel developers want to see some issues
+fixed as soon as possible, hence there are 'issues of high priority' that get
+handled slightly differently in the reporting process. Three type of cases
+qualify: regressions, security issues, and really severe problems.
+
+You deal with a 'regression' if something that worked with an older version of
+the Linux kernel does not work with a newer one or somehow wor
Re: [RFC PATCH v2 00/13] Add futex2 syscall
Hi André, > ** The wait on multiple problem > > The use case lies in the Wine implementation of the Windows NT interface > WaitMultipleObjects. This Windows API function allows a thread to sleep > waiting on the first of a set of event sources (mutexes, timers, signal, > console input, etc) to signal. With that in mind would it be good to have some interaction with epoll (and similar calls)? Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic eventfd() or a new futex2fd()) would be a better interface? Or instead introduce an IORING_OP_FUTEX2_WAITV? Then the futex_waitv logic wait in an io-wq kernel thread... I guess the io_uring way would mean we could have that in mind as future addition, which can be implemented later... metze
Re: [RFT PATCH v3 21/27] tty: serial: samsung_tty: IRQ rework
On 05/03/2021 17:29, Hector Martin wrote: > On 06/03/2021 01.20, Andy Shevchenko wrote: >>> I am just splitting an >>> existing function into two, where one takes the lock and the other does >>> the work. Do you mean using a different locking function? I'm not >>> entirely sure what you're suggesting. >> >> Yes, as a prerequisite >> >> spin_lock_irqsave -> spin_lock(). > > Krzysztof, is this something you want in this series? I was trying to > avoid logic changes to the non-Apple paths. I don't quite get the need for such change (the code will be still called in interrupt handler, right?), but assuming the "why?" is properly documented, it can be a separate patch here. Best regards, Krzysztof
Re: [PATCH 5.11 000/104] 5.11.4-rc1 review
On Sun, Mar 07, 2021 at 07:46:06AM +0530, Naresh Kamboju wrote: > On Fri, 5 Mar 2021 at 17:55, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.11.4 release. > > There are 104 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.11.4-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.11.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Tested-by: Linux Kernel Functional Testing thanks for testing them all and helping with the tty regression. greg k-h
[PATCH] brcmfmac: Add support for BCM43596 PCIe Wi-Fi
Add support for BCM43596 dual-band AC chip, found in
SONY Xperia X Performance, XZ and XZs smartphones (and
*possibly* other devices from other manufacturers).
The chip doesn't require any special handling and seems to work
just fine OOTB.
PCIe IDs taken from:
https://github.com/sonyxperiadev/kernel/commit/9e43fefbac8e43c3d7792e73ca52a052dd86d7e3.patch
Signed-off-by: Konrad Dybcio
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 2 ++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 4
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 45037decba40..38ca0517f3cf 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -723,6 +723,7 @@ static u32 brcmf_chip_tcm_rambase(struct brcmf_chip_priv
*ci)
case BRCM_CC_43666_CHIP_ID:
return 0x20;
case BRCM_CC_4359_CHIP_ID:
+ case BRCM_CC_43596_CHIP_ID:
return (ci->pub.chiprev < 9) ? 0x18 : 0x16;
case BRCM_CC_4364_CHIP_ID:
case CY_CC_4373_CHIP_ID:
@@ -1411,6 +1412,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
reg = chip->ops->read32(chip->ctx, addr);
return (reg & CC_SR_CTL0_ENABLE_MASK) != 0;
case BRCM_CC_4359_CHIP_ID:
+ case BRCM_CC_43596_CHIP_ID:
case CY_CC_43012_CHIP_ID:
addr = CORE_CC_REG(pmu->base, retention_ctl);
reg = chip->ops->read32(chip->ctx, addr);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index ad79e3b7e74a..da604fa17f94 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -71,6 +71,7 @@ static const struct brcmf_firmware_mapping
brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43570_CHIP_ID, 0x, 43570),
BRCMF_FW_ENTRY(BRCM_CC_4358_CHIP_ID, 0x, 4358),
BRCMF_FW_ENTRY(BRCM_CC_4359_CHIP_ID, 0x, 4359),
+ BRCMF_FW_ENTRY(BRCM_CC_43596_CHIP_ID, 0x, 4359),
BRCMF_FW_ENTRY(BRCM_CC_4364_CHIP_ID, 0x, 4364),
BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0x000F, 4365B),
BRCMF_FW_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFF0, 4365C),
@@ -2107,6 +2108,9 @@ static const struct pci_device_id
brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_43570_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4358_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4359_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43596_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43596_2G_DEVICE_ID),
+ BRCMF_PCIE_DEVICE(BRCM_PCIE_43596_5G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_43602_5G_DEVICE_ID),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index 00309b272a0e..03542c096e40 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -43,6 +43,7 @@
#define BRCM_CC_43570_CHIP_ID 43570
#define BRCM_CC_4358_CHIP_ID 0x4358
#define BRCM_CC_4359_CHIP_ID 0x4359
+#define BRCM_CC_43596_CHIP_ID 43596
#define BRCM_CC_43602_CHIP_ID 43602
#define BRCM_CC_4364_CHIP_ID 0x4364
#define BRCM_CC_4365_CHIP_ID 0x4365
@@ -72,6 +73,9 @@
#define BRCM_PCIE_43570_DEVICE_ID 0x43d9
#define BRCM_PCIE_4358_DEVICE_ID 0x43e9
#define BRCM_PCIE_4359_DEVICE_ID 0x43ef
+#define BRCM_PCIE_43596_DEVICE_ID 0x4415
+#define BRCM_PCIE_43596_2G_DEVICE_ID 0x4416
+#define BRCM_PCIE_43596_5G_DEVICE_ID 0x4417
#define BRCM_PCIE_43602_DEVICE_ID 0x43ba
#define BRCM_PCIE_43602_2G_DEVICE_ID 0x43bb
#define BRCM_PCIE_43602_5G_DEVICE_ID 0x43bc
--
2.30.1
Re: [PATCH 5.11 000/104] 5.11.4-rc1 review
On Sat, Mar 06, 2021 at 08:39:56AM -0800, Guenter Roeck wrote: > On Fri, Mar 05, 2021 at 01:20:05PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.11.4 release. > > There are 104 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > > Anything received after that time might be too late. > > > > Build results: > total: 155 pass: 155 fail: 0 > Qemu test results: > total: 435 pass: 435 fail: 0 > > Tested-by: Guenter Roeck Thanks for testing all of these. greg k-h
Re: [PATCH 5.10 000/102] 5.10.21-rc1 review
On Sat, Mar 06, 2021 at 02:25:44PM +0800, Samuel Zou wrote: > > > On 2021/3/5 20:20, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.21 release. > > There are 102 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.21-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.10.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Our test CI monitored the 5.10.21-rc1, and compile failure on arm64: > > Kernel repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Branch: linux-5.10.y > Arch: arm64/x86 > Version: 5.10.21-rc1+ > Commit: 80aaabbaf433294d1f075981fa3785d7f4b55159 > Compiler: gcc version 7.3.0 (GCC) > > > arm64 (compile failure) > > Kernel build failed, error log: > kernel/rcu/tree.c:683:2: error: implicit declaration of function > ‘IRQ_WORK_INIT’; did you mean ‘QSTR_INIT’? > [-Werror=implicit-function-declaration] > IRQ_WORK_INIT(late_wakeup_func); > ^ > QSTR_INIT > kernel/rcu/tree.c:683:2: error: invalid initializer > > > x86 (No kernel failures) > > Testcase Result Summary: > total_num: 4716 > succeed_num: 4714 > failed_num: 2 > timeout_num: 0 > > Tested-by: Hulk Robot Thanks for testing and letting me know. greg k-h
Re: [PATCH 5.10 000/102] 5.10.21-rc1 review
On Fri, Mar 05, 2021 at 09:31:52PM -0800, Florian Fainelli wrote: > > > On 3/5/2021 4:20 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.21 release. > > There are 102 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sun, 07 Mar 2021 12:08:39 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.21-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.10.y > > and the diffstat can be found below. > > > > thanks, > > On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: > > Tested-by: Florian Fainelli Thanks for testing and letting me know. greg k-h
Re: [RFT PATCH v3 24/27] tty: serial: samsung_tty: Add support for Apple UARTs
On 05/03/2021 18:04, Hector Martin wrote:
> On 06/03/2021 00.28, Andy Shevchenko wrote:
>>> + case TYPE_APPLE_S5L:
>>> + WARN_ON(1); // No DMA
>>
>> Oh, no, please use the ONCE variant.
>
> Thanks, changing this for v4.
>
>>
>> ...
>>
>>> + /* Apple types use these bits for IRQ masks */
>>> + if (ourport->info->type != TYPE_APPLE_S5L) {
>>> + ucon &= ~(S3C64XX_UCON_TIMEOUT_MASK |
>>> + S3C64XX_UCON_EMPTYINT_EN |
>>> + S3C64XX_UCON_DMASUS_EN |
>>> + S3C64XX_UCON_TIMEOUT_EN);
>>> + ucon |= 0xf << S3C64XX_UCON_TIMEOUT_SHIFT |
>>
>> Can you spell 0xf with named constant(s), please?
>>
>> In case they are repetitive via the code, introduce either a temporary
>> variable (in case it scoped to one function only), or define it as a
>> constant.
>
> I'm just moving this code; as far as I can tell this is a timeout value
> (so just an integer), but I don't know if there is any special meaning
> to 0xf here. Note that this codepath is for *non-Apple* chips, as the
> Apple ones don't even have this field (at least not here).
I agree here with Hector. Andi, you propose here unrelated change (which
without documentation might not be doable by Hector).
>
>>> + irqreturn_t ret = IRQ_NONE;
>>
>> Redundant. You may return directly.
>
> What if both interrupts are pending?
>
>> No IO serialization?
>
> There is no DMA on the Apple variants (as far as I know; it's not
> implemented anyway), so there is no need for serializing IO with DMA. In
> any case, dealing with that is the DMA code's job, the interrupt handler
> shouldn't need to care.
>
> If you mean serializing IO with the IRQ: CPU-wise, I would hope that's
> the irqchip's job (AIC does this with a readl on the event). If you mean
> ensuring all writes are complete (i.e. posted write issue), on the Apple
> chips everything is non-posted as explained in the previous patches.
>
>> Extra blank line (check your entire series for a such)
>
> Thanks, noted. I'll check the declaration blocks in other patches.
>
>>> + ourport->rx_enabled = 1;
>>> + ourport->tx_enabled = 0;
>>
>> How are these protected against race?
>
> The serial core should be holding the port mutex for pretty much every
> call into the driver, as far as I can tell.
>
>>
>> ...
>>
>>> + case TYPE_APPLE_S5L: {
>>> + unsigned int ucon;
>>> + int ret;
>>> +
>>> + ret = clk_prepare_enable(ourport->clk);
>>> + if (ret) {
>>> + dev_err(dev, "clk_enable clk failed: %d\n",
>>> ret);
>>> + return ret;
>>> + }
>>> + if (!IS_ERR(ourport->baudclk)) {
>>> + ret = clk_prepare_enable(ourport->baudclk);
>>> + if (ret) {
>>> + dev_err(dev, "clk_enable baudclk
>>> failed: %d\n", ret);
>>> + clk_disable_unprepare(ourport->clk);
>>> + return ret;
>>> + }
>>> + }
>>
>> Wouldn't it be better to use CLK bulk API?
>
> Ah, I guess that could save a line or two of code here, even though it
> requires setting up the array. I'll give it a shot.
>
>>> +#ifdef CONFIG_ARCH_APPLE
>>
>> Why? Wouldn't you like the one kernel to work on many SoCs?
>
> This *adds* Apple support, it is not mutually exclusive with all the
> other SoCs. You can enable all of those options and get a driver that
> works on all of them. This is the same pattern used throughout the
> driver for all the other Samsung variants. There is no reason to have
> Apple SoC support in the samsung driver if the rest of the kernel
> doesn't have Apple SoC support either, of course.
How ifdef on ARCH_APLLE makes it non-working on many SoCs? All new
platforms are multi... The true question is - do the ifdefs in the code
make it more difficult to read/review?
Best regards,
Krzysztof
Re: [PATCH 2/2] dt-bindings: serial: samsung: include generic dtschema to match bluetooth child
On 05/03/2021 21:49, Rob Herring wrote:
> On Fri, Feb 12, 2021 at 05:39:05PM +0100, Krzysztof Kozlowski wrote:
>> Include the generic serial.yaml dtschema so the child node like
>> "bluetooh" will be properly matched:
>>
>> arch/arm/boot/dts/exynos4210-universal_c210.dt.yaml:
>> serial@1380: 'bluetooth' does not match any of the regexes:
>> 'pinctrl-[0-9]+'
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> .../bindings/serial/samsung_uart.yaml | 26 ++-
>> 1 file changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> index 3e29b561223d..f4faf32ab00f 100644
>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
>> @@ -78,9 +78,11 @@ required:
>>- interrupts
>>- reg
>>
>> -additionalProperties: false
>> +unevaluatedProperties: false
>>
>> allOf:
>> + - $ref: /schemas/serial.yaml#
>> +
>>- if:
>>properties:
>> compatible:
>> @@ -134,3 +136,25 @@ examples:
>> <&clocks SCLK_UART>;
>> samsung,uart-fifosize = <16>;
>> };
>> +
>> + - |
>> +#include
>> +#include
>> +
>> +serial@1380 {
>> +compatible = "samsung,exynos4210-uart";
>> +reg = <0x1380 0x100>;
>> +interrupts = ;
>> +clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
>> +clock-names = "uart", "clk_uart_baud0";
>> +dmas = <&pdma0 15>, <&pdma0 16>;
>> +dma-names = "rx", "tx";
>> +pinctrl-0 = <&uart0_data &uart0_fctl>;
>> +pinctrl-names = "default";
>> +
>> +bluetooth {
>> +compatible = "brcm,bcm4330-bt";
>
> Do we need a whole new example for this?
No, we don't need it. I find examples useful but if you prefer to have
them smaller, then I can skip it.
Best regards,
Krzysztof
Re: [PATCH] dt-bindings: iio: samsung,exynos-adc: add common clock properties
On 05/03/2021 21:41, Rob Herring wrote: > On Mon, Feb 15, 2021 at 10:29:15AM +0100, Krzysztof Kozlowski wrote: >> On Mon, Feb 15, 2021 at 10:01:48AM +0100, Marek Szyprowski wrote: >>> Hi Krzysztof, >>> >>> On 12.02.2021 17:38, Krzysztof Kozlowski wrote: Add common properties appearing in DTSes (assigned-clocks and similar) to fix dtbs_check warnings like: arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: adc@126c: assigned-clock-rates: [[600]] is not of type 'object' arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml: adc@126c: assigned-clocks: [[7, 238]] is not of type 'object' >>> >>> Does it mean that assigned-clocks related properties have to be added to >>> almost all bindings? >> >> To my understanding: yes, and we already added it to multiple schemas. >> >>> IMHO this is an over-engineering and this has to be >>> handled somewhere else... >> >> Would have to be made a part of the core schema (just like pinctrl nodes >> etc). > > That's the case now. It's contingent on having a 'clocks' property in > the node. Do I understand correctly: with new dtschema my patch is not needed anymore? Best regards, Krzysztof
[PATCH v6 1/8] security: Add LSM hook at the point where a task gets a fatal signal
Add a security hook that allows a LSM to be notified when a task gets a
fatal signal. This patch is a previous step on the way to compute the
task crash period by the "brute" LSM (linux security module to detect
and mitigate fork brute force attack against vulnerable userspace
processes).
Signed-off-by: John Wood
---
include/linux/lsm_hook_defs.h | 1 +
include/linux/lsm_hooks.h | 4
include/linux/security.h | 4
kernel/signal.c | 1 +
security/security.c | 5 +
5 files changed, 15 insertions(+)
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 477a597db013..0208df0955fa 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -220,6 +220,7 @@ LSM_HOOK(int, -ENOSYS, task_prctl, int option, unsigned
long arg2,
unsigned long arg3, unsigned long arg4, unsigned long arg5)
LSM_HOOK(void, LSM_RET_VOID, task_to_inode, struct task_struct *p,
struct inode *inode)
+LSM_HOOK(void, LSM_RET_VOID, task_fatal_signal, const kernel_siginfo_t
*siginfo)
LSM_HOOK(int, 0, ipc_permission, struct kern_ipc_perm *ipcp, short flag)
LSM_HOOK(void, LSM_RET_VOID, ipc_getsecid, struct kern_ipc_perm *ipcp,
u32 *secid)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index fb7f3193753d..beedaa6ee745 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -784,6 +784,10 @@
* security attributes, e.g. for /proc/pid inodes.
* @p contains the task_struct for the task.
* @inode contains the inode structure for the inode.
+ * @task_fatal_signal:
+ * This hook allows security modules to be notified when a task gets a
+ * fatal signal.
+ * @siginfo contains the signal information.
*
* Security hooks for Netlink messaging.
*
diff --git a/include/linux/security.h b/include/linux/security.h
index 8aeebd6646dc..e4025a13630f 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -430,6 +430,7 @@ int security_task_kill(struct task_struct *p, struct
kernel_siginfo *info,
int security_task_prctl(int option, unsigned long arg2, unsigned long arg3,
unsigned long arg4, unsigned long arg5);
void security_task_to_inode(struct task_struct *p, struct inode *inode);
+void security_task_fatal_signal(const kernel_siginfo_t *siginfo);
int security_ipc_permission(struct kern_ipc_perm *ipcp, short flag);
void security_ipc_getsecid(struct kern_ipc_perm *ipcp, u32 *secid);
int security_msg_msg_alloc(struct msg_msg *msg);
@@ -1165,6 +1166,9 @@ static inline int security_task_prctl(int option,
unsigned long arg2,
static inline void security_task_to_inode(struct task_struct *p, struct inode
*inode)
{ }
+static inline void security_task_fatal_signal(const kernel_siginfo_t *siginfo)
+{ }
+
static inline int security_ipc_permission(struct kern_ipc_perm *ipcp,
short flag)
{
diff --git a/kernel/signal.c b/kernel/signal.c
index ba4d1ef39a9e..d279df338f45 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2750,6 +2750,7 @@ bool get_signal(struct ksignal *ksig)
/*
* Anything else is fatal, maybe with a core dump.
*/
+ security_task_fatal_signal(&ksig->info);
current->flags |= PF_SIGNALED;
if (sig_kernel_coredump(signr)) {
diff --git a/security/security.c b/security/security.c
index 5ac96b16f8fa..d9cf653a4e70 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1840,6 +1840,11 @@ void security_task_to_inode(struct task_struct *p,
struct inode *inode)
call_void_hook(task_to_inode, p, inode);
}
+void security_task_fatal_signal(const kernel_siginfo_t *siginfo)
+{
+ call_void_hook(task_fatal_signal, siginfo);
+}
+
int security_ipc_permission(struct kern_ipc_perm *ipcp, short flag)
{
return call_int_hook(ipc_permission, 0, ipcp, flag);
--
2.25.1
Re: [PATCH] arm64/mm: Fix __enable_mmu() for new TGRAN range values
On 3/5/21 8:21 PM, Mark Rutland wrote: > On Fri, Mar 05, 2021 at 08:06:09PM +0530, Anshuman Khandual wrote: >> From: James Morse >> >> As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1 >> might contain a range of values to describe supported translation granules >> (4K and 16K pages sizes in particular) instead of just enabled or disabled >> values. This changes __enable_mmu() function to handle complete acceptable >> range of values (depending on whether the field is signed or unsigned) now >> represented with ID_AA64MMFR0_TGRAN_SUPPORTED_[MIN..MAX] pair. While here, >> also fix similar situations in EFI stub and KVM as well. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Marc Zyngier >> Cc: James Morse >> Cc: Suzuki K Poulose >> Cc: Ard Biesheuvel >> Cc: Mark Rutland >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: kvm...@lists.cs.columbia.edu >> Cc: linux-...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: James Morse >> Signed-off-by: Anshuman Khandual >> --- >> arch/arm64/include/asm/sysreg.h | 20 ++-- >> arch/arm64/kernel/head.S | 6 -- >> arch/arm64/kvm/reset.c| 23 --- >> drivers/firmware/efi/libstub/arm64-stub.c | 2 +- >> 4 files changed, 31 insertions(+), 20 deletions(-) >> >> diff --git a/arch/arm64/include/asm/sysreg.h >> b/arch/arm64/include/asm/sysreg.h >> index dfd4edb..d4a5fca9 100644 >> --- a/arch/arm64/include/asm/sysreg.h >> +++ b/arch/arm64/include/asm/sysreg.h >> @@ -796,6 +796,11 @@ >> #define ID_AA64MMFR0_PARANGE_48 0x5 >> #define ID_AA64MMFR0_PARANGE_52 0x6 >> >> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_DEFAULT 0x0 >> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE 0x1 >> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MIN 0x2 >> +#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MAX 0x7 > > The TGRAN2 fields doesn't quite follow the usual ID scheme rules, so how > do we deteremine the max value? Does the ARM ARM say anything in > particular about them, like we do for some of the PMU ID fields? Did not find anything in ARM ARM, regarding what scheme TGRAN2 fields actually follow. I had arrived at more restrictive 0x7 value, like the usual signed fields as the TGRAN4 fields definitely do not follow the unsigned ID scheme. Would restricting max value to 0x3 (i.e LPA2) be a better option instead ? > > Otherwise, this patch looks correct to me. > > Thanks, > Mark. >
Re: [PATCH] fb_defio: Use __set_page_dirty_no_writeback
Hi "Matthew, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc2] [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/Matthew-Wilcox-Oracle/fb_defio-Use-__set_page_dirty_no_writeback/20210307-110930 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a38fd8748464831584a19438cbb3082b5a2dab15 config: mips-randconfig-r002-20210307 (attached as .config) compiler: mipsel-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/5e5071e6e61cd1796322f6e365460451457d4d51 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Matthew-Wilcox-Oracle/fb_defio-Use-__set_page_dirty_no_writeback/20210307-110930 git checkout 5e5071e6e61cd1796322f6e365460451457d4d51 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__set_page_dirty_no_writeback" >> [drivers/video/fbdev/core/fb.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Linux 5.4.103
I'm announcing the release of the 5.4.103 kernel. All users of the 5.4 kernel series must upgrade. The updated 5.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/btusb.txt|2 Documentation/devicetree/bindings/net/ethernet-controller.yaml |5 Documentation/filesystems/sysfs.txt|8 Makefile |2 arch/arm/xen/p2m.c | 35 ++ arch/arm64/kernel/module.lds |6 arch/mips/include/asm/string.h | 121 arch/mips/vdso/Makefile|5 arch/parisc/kernel/irq.c |4 arch/x86/events/intel/core.c |3 arch/x86/kernel/module.c |1 arch/x86/kernel/reboot.c |9 arch/x86/tools/relocs.c| 12 arch/x86/xen/p2m.c | 44 ++ crypto/tcrypt.c| 20 - drivers/block/nbd.c| 32 +- drivers/block/zram/zram_drv.c |2 drivers/bluetooth/hci_h5.c |5 drivers/gpu/drm/amd/amdgpu/cz_ih.c | 37 +- drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 36 +- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 37 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c |5 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|1 drivers/gpu/drm/virtio/virtgpu_vq.c|5 drivers/input/mouse/elantech.c | 99 ++ drivers/input/mouse/elantech.h |4 drivers/media/rc/mceusb.c |9 drivers/media/usb/uvc/uvc_driver.c |7 drivers/media/v4l2-core/v4l2-ctrls.c |3 drivers/media/v4l2-core/v4l2-ioctl.c | 19 - drivers/net/ethernet/atheros/ag71xx.c |4 drivers/net/tap.c |7 drivers/net/tun.c |4 drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 - drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 32 ++ drivers/net/wireless/rsi/rsi_91x_hal.c |3 drivers/net/wireless/rsi/rsi_91x_sdio.c|6 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c| 52 --- drivers/net/wireless/rsi/rsi_sdio.h|8 drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 - drivers/net/wireless/ti/wlcore/wlcore.h|3 drivers/net/xen-netback/netback.c | 12 drivers/nvme/host/core.c | 20 + drivers/nvme/host/nvme.h |2 drivers/nvme/host/pci.c| 105 --- drivers/nvme/host/rdma.c | 18 + drivers/nvme/host/tcp.c| 18 + drivers/pci/pci.c |9 drivers/scsi/libiscsi.c| 148 +- drivers/scsi/scsi_transport_iscsi.c| 38 ++ drivers/staging/fwserial/fwserial.c|2 drivers/staging/most/sound/sound.c |2 drivers/staging/vc04_services/bcm2835-audio/bcm2835-ctl.c |6 drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c |2 drivers/staging/vc04_services/bcm2835-audio/bcm2835.c |6 drivers/tty/vt/consolemap.c|2 drivers/video/fbdev/udlfb.c|1 fs/btrfs/transaction.c | 11 fs/erofs/super.c |4 fs/f2fs/namei.c|8 fs/f2fs/segment.h
Linux 4.19.179
I'm announcing the release of the 4.19.179 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/btusb.txt |2 Documentation/filesystems/sysfs.txt |8 - Makefile|2 arch/arm/xen/p2m.c | 35 + arch/arm64/include/asm/atomic_ll_sc.h | 108 + arch/arm64/include/asm/atomic_lse.h | 46 +++ arch/arm64/include/asm/cmpxchg.h| 116 +- arch/arm64/kernel/module.lds|6 arch/mips/vdso/Makefile |5 arch/parisc/kernel/irq.c|4 arch/x86/kernel/module.c|1 arch/x86/kernel/reboot.c|9 + arch/x86/tools/relocs.c | 12 + arch/x86/xen/p2m.c | 44 ++- crypto/tcrypt.c | 20 +-- drivers/block/zram/zram_drv.c |2 drivers/bluetooth/hci_h5.c |5 drivers/gpu/drm/amd/display/dc/core/dc_link.c |5 drivers/gpu/drm/virtio/virtgpu_vq.c |6 drivers/media/rc/mceusb.c |9 + drivers/media/usb/uvc/uvc_driver.c |7 - drivers/media/v4l2-core/v4l2-ioctl.c| 19 +-- drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 -- drivers/net/wireless/rsi/rsi_91x_hal.c |3 drivers/net/wireless/rsi/rsi_91x_sdio.c |6 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 52 ++-- drivers/net/wireless/rsi/rsi_sdio.h |8 - drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 -- drivers/net/wireless/ti/wlcore/wlcore.h |3 drivers/net/xen-netback/netback.c | 12 + drivers/pci/pci.c |9 + drivers/s390/virtio/virtio_ccw.c|4 drivers/scsi/libiscsi.c | 148 drivers/scsi/scsi_transport_iscsi.c | 38 -- drivers/staging/fwserial/fwserial.c |2 drivers/staging/most/sound/sound.c |2 drivers/tty/vt/consolemap.c |2 drivers/video/fbdev/udlfb.c |1 fs/btrfs/transaction.c | 11 - fs/f2fs/namei.c |8 + fs/f2fs/segment.h |4 fs/jfs/jfs_filsys.h |1 fs/jfs/jfs_mount.c | 10 + fs/sysfs/file.c | 55 fs/xfs/xfs_iops.c |2 include/linux/sysfs.h | 16 ++ include/linux/zsmalloc.h|2 mm/hugetlb.c| 28 ++-- mm/page_io.c| 11 - mm/swapfile.c |2 mm/zsmalloc.c | 17 +- net/bluetooth/amp.c |3 net/bridge/br_sysfs_if.c|9 - net/core/pktgen.c |2 net/core/skbuff.c | 14 ++ security/smack/smackfs.c| 21 +++ sound/pci/hda/patch_realtek.c |2 sound/soc/intel/boards/bytcr_rt5640.c | 37 ++ 60 files changed, 651 insertions(+), 399 deletions(-) Andrew Murray (1): arm64: Use correct ll/sc atomic constraints Ard Biesheuvel (1): crypto: tcrypt - avoid signed overflow in byte count Chao Yu (1): f2fs: fix to set/clear I_LINKABLE under i_lock Chris Leech (2): scsi: iscsi: Ensure sysfs attributes are limited to PAGE_SIZE scsi: iscsi: Verify lengths on passthrough PDUs Christian Gromm (1): staging: most: sound: add sanity check for function argument Claire Chang (1): Bluetooth: hci_h5: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for btrtl Cornelia Huck (1): virtio/s390: implement virtio-ccw revision 2 correctly Di Zhu (1): pktgen: fix misuse of BUG_ON() in pktgen_thread_worker() Dinghao Liu (1): staging: fwserial: Fix error handling in fwserial_create Eckhart Mohr (1): ALSA: hda/realtek: Add quirk for Clevo NH55RZQ Fangrui Song (1): x86/build: Treat R_386_PLT32 relocation as R_386_PC32 Geert Uytterhoeven (1): dt-b
Re: Linux 4.19.179
diff --git a/Documentation/devicetree/bindings/net/btusb.txt
b/Documentation/devicetree/bindings/net/btusb.txt
index 37d67926dd6d..d883a35641d1 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -35,7 +35,7 @@ Following example uses irq pin number 3 of gpio0 for out of
band wake-on-bt:
compatible = "usb1286,204e";
reg = <1>;
interrupt-parent = <&gpio0>;
- interrupt-name = "wakeup";
+ interrupt-names = "wakeup";
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
};
};
diff --git a/Documentation/filesystems/sysfs.txt
b/Documentation/filesystems/sysfs.txt
index a1426cabcef1..2e38fafc1b63 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -211,12 +211,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/Makefile b/Makefile
index 6787efa2edc9..040b3cd699b0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 178
+SUBLEVEL = 179
EXTRAVERSION =
NAME = "People's Front"
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index ce538c51fa3f..8a8a388549e7 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -91,12 +91,39 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
int i;
for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >>
XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+* Signal an error for this slot. This in turn requires
+* immediate unmapping.
+*/
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+* Pre-populate the status field, to be recognizable in
+* the log message below.
+*/
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}
return 0;
diff --git a/arch/arm64/include/asm/atomic_ll_sc.h
b/arch/arm64/include/asm/atomic_ll_sc.h
index f5a2d09afb38..1cc42441bc67 100644
--- a/arch/arm64/include/asm/atomic_ll_sc.h
+++ b/arch/arm64/include/asm/atomic_ll_sc.h
@@ -37,7 +37,7 @@
* (the optimize attribute silently ignores these options).
*/
-#define ATOMIC_OP(op, asm_op) \
+#define ATOMIC_OP(op, asm_op, constraint) \
__LL_SC_INLINE void\
__LL_SC_PREFIX(atomic_##op(int i, atomic_t *v))
\
{ \
@@ -51,11 +51,11 @@ __LL_SC_PREFIX(atomic_##op(int i, atomic_t *v))
\
" stxr%w1, %w0, %2\n" \
" cbnz%w1, 1b"\
: "=&r" (result), "=&r" (tmp), "+Q" (v->counter)\
- : "Ir" (i));\
+ : #constraint "r" (i)); \
} \
__LL_SC_EXPORT(atomic_##op);
-#define ATOMIC_OP_RETURN(name, mb, acq, rel, cl, op, asm_op) \
Linux 5.10.21
I'm announcing the release of the 5.10.21 kernel. All users of the 5.10 kernel series must upgrade. The updated 5.10.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/btusb.txt|2 Documentation/devicetree/bindings/net/ethernet-controller.yaml |5 Documentation/networking/ip-sysctl.rst |7 Makefile |2 arch/arm/xen/p2m.c | 35 ++ arch/parisc/kernel/irq.c |4 arch/powerpc/lib/sstep.c | 79 - arch/riscv/mm/init.c | 21 - arch/x86/events/intel/core.c |3 arch/x86/include/asm/xen/page.h| 12 arch/x86/kernel/module.c |1 arch/x86/kernel/reboot.c |9 arch/x86/tools/relocs.c| 12 arch/x86/xen/p2m.c | 54 +++ arch/x86/xen/setup.c | 25 - crypto/tcrypt.c| 20 - drivers/block/nbd.c| 32 +- drivers/block/zram/zram_drv.c |2 drivers/bluetooth/hci_h5.c |5 drivers/edac/amd64_edac.c | 10 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |6 drivers/gpu/drm/amd/amdgpu/cz_ih.c | 37 +- drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 36 +- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 37 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c |5 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|1 drivers/gpu/drm/virtio/virtgpu_object.c|5 drivers/infiniband/ulp/rtrs/rtrs-clt.c | 15 - drivers/infiniband/ulp/rtrs/rtrs-srv.c |3 drivers/infiniband/ulp/rtrs/rtrs.c |4 drivers/input/mouse/elan_i2c.h | 16 + drivers/input/mouse/elan_i2c_core.c| 13 drivers/input/mouse/elan_i2c_smbus.c |8 drivers/input/mouse/elantech.c | 99 ++ drivers/input/mouse/elantech.h |4 drivers/media/rc/mceusb.c |9 drivers/media/usb/uvc/uvc_driver.c |7 drivers/media/v4l2-core/v4l2-ctrls.c |3 drivers/media/v4l2-core/v4l2-ioctl.c | 19 - drivers/net/ethernet/atheros/ag71xx.c |4 drivers/net/phy/sfp-bus.c | 15 + drivers/net/phy/sfp.c | 112 +++ drivers/net/tap.c |7 drivers/net/tun.c |5 drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/mac.c | 15 - drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 32 ++ drivers/net/wireless/mediatek/mt76/mt7615/mac.c| 20 + drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h |2 drivers/net/wireless/mediatek/mt76/mt7615/pci_init.c | 12 drivers/net/wireless/rsi/rsi_91x_hal.c |3 drivers/net/wireless/rsi/rsi_91x_sdio.c|6 drivers/net/wireless/rsi/rsi_91x_sdio_ops.c| 52 --- drivers/net/wireless/rsi/rsi_sdio.h|8 drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 - drivers/net/wireless/ti/wlcore/wlcore.h|3 drivers/net/xen-netback/netback.c | 12 drivers/nvme/host/core.c | 20 + drivers/nvme/host/nvme.h |2 drivers/nvme/host/rdma.c | 18 + drivers/nvme/host/tcp.c| 18 + drivers/pci/pci.c |
Re: Linux 5.4.103
diff --git a/Documentation/devicetree/bindings/net/btusb.txt
b/Documentation/devicetree/bindings/net/btusb.txt
index b1ad6ee68e90..c51dd99dc0d3 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -38,7 +38,7 @@ Following example uses irq pin number 3 of gpio0 for out of
band wake-on-bt:
compatible = "usb1286,204e";
reg = <1>;
interrupt-parent = <&gpio0>;
- interrupt-name = "wakeup";
+ interrupt-names = "wakeup";
interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
};
};
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index 0e7c31794ae6..4f78e9a6da60 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -190,6 +190,11 @@ properties:
Indicates that full-duplex is used. When absent, half
duplex is assumed.
+pause:
+ $ref: /schemas/types.yaml#definitions/flag
+ description:
+Indicates that pause should be enabled.
+
asym-pause:
$ref: /schemas/types.yaml#definitions/flag
description:
diff --git a/Documentation/filesystems/sysfs.txt
b/Documentation/filesystems/sysfs.txt
index ddf15b1b0d5a..33ec0a01450d 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -232,12 +232,10 @@ Other notes:
is 4096.
- show() methods should return the number of bytes printed into the
- buffer. This is the return value of scnprintf().
+ buffer.
-- show() must not use snprintf() when formatting the value to be
- returned to user space. If you can guarantee that an overflow
- will never happen you can use sprintf() otherwise you must use
- scnprintf().
+- show() should only use sysfs_emit() or sysfs_emit_at() when formatting
+ the value to be returned to user space.
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
diff --git a/Makefile b/Makefile
index 80ff67e5f73a..c95435d78fcb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 4
-SUBLEVEL = 102
+SUBLEVEL = 103
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index fd6e3aafe272..acb464547a54 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -93,12 +93,39 @@ int set_foreign_p2m_mapping(struct gnttab_map_grant_ref
*map_ops,
int i;
for (i = 0; i < count; i++) {
+ struct gnttab_unmap_grant_ref unmap;
+ int rc;
+
if (map_ops[i].status)
continue;
- if (unlikely(!set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
- map_ops[i].dev_bus_addr >>
XEN_PAGE_SHIFT))) {
- return -ENOMEM;
- }
+ if (likely(set_phys_to_machine(map_ops[i].host_addr >>
XEN_PAGE_SHIFT,
+ map_ops[i].dev_bus_addr >> XEN_PAGE_SHIFT)))
+ continue;
+
+ /*
+* Signal an error for this slot. This in turn requires
+* immediate unmapping.
+*/
+ map_ops[i].status = GNTST_general_error;
+ unmap.host_addr = map_ops[i].host_addr,
+ unmap.handle = map_ops[i].handle;
+ map_ops[i].handle = ~0;
+ if (map_ops[i].flags & GNTMAP_device_map)
+ unmap.dev_bus_addr = map_ops[i].dev_bus_addr;
+ else
+ unmap.dev_bus_addr = 0;
+
+ /*
+* Pre-populate the status field, to be recognizable in
+* the log message below.
+*/
+ unmap.status = 1;
+
+ rc = HYPERVISOR_grant_table_op(GNTTABOP_unmap_grant_ref,
+ &unmap, 1);
+ if (rc || unmap.status != GNTST_okay)
+ pr_err_once("gnttab unmap failed: rc=%d st=%d\n",
+ rc, unmap.status);
}
return 0;
diff --git a/arch/arm64/kernel/module.lds b/arch/arm64/kernel/module.lds
index 22e36a21c113..09a0eef71d12 100644
--- a/arch/arm64/kernel/module.lds
+++ b/arch/arm64/kernel/module.lds
@@ -1,5 +1,5 @@
SECTIONS {
- .plt (NOLOAD) : { BYTE(0) }
- .init.plt (NOLOAD) : { BYTE(0) }
- .text.ftrace_trampoline (NOLOAD) : { BYTE(0) }
+ .plt 0 (NOLOAD) : { BYTE(0) }
+ .init.plt 0 (NOLOAD) : { BYTE(0) }
+ .text.ftrace_trampoline 0 (NOLOAD) : { BYTE(0) }
}
diff --git a/arch/mips/include/asm/string.h b/arch/mips/include/asm/string.h
index 29030cb398ee..1de3bbce8e88
Linux 5.11.4
I'm announcing the release of the 5.11.4 kernel. All users of the 5.11 kernel series must upgrade. The updated 5.11.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.11.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/btusb.txt|2 Documentation/devicetree/bindings/net/ethernet-controller.yaml |5 Documentation/networking/ip-sysctl.rst |7 Makefile |2 arch/arm/xen/p2m.c | 35 ++ arch/parisc/kernel/irq.c |4 arch/riscv/mm/init.c | 21 - arch/x86/events/intel/core.c |3 arch/x86/include/asm/xen/page.h| 12 arch/x86/kernel/module.c |1 arch/x86/kernel/reboot.c |9 arch/x86/tools/relocs.c| 12 arch/x86/xen/p2m.c | 54 +++ arch/x86/xen/setup.c | 25 - crypto/tcrypt.c| 20 - drivers/block/nbd.c| 32 +- drivers/bluetooth/hci_h5.c |5 drivers/edac/amd64_edac.c | 10 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |6 drivers/gpu/drm/amd/amdgpu/cz_ih.c | 37 +- drivers/gpu/drm/amd/amdgpu/iceland_ih.c| 36 +- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 37 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c |5 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|1 drivers/infiniband/ulp/rtrs/rtrs-clt.c | 15 - drivers/infiniband/ulp/rtrs/rtrs-srv.c |3 drivers/infiniband/ulp/rtrs/rtrs.c |4 drivers/media/rc/mceusb.c |9 drivers/media/usb/uvc/uvc_driver.c |7 drivers/media/usb/zr364xx/zr364xx.c| 49 ++- drivers/media/v4l2-core/v4l2-ctrls.c |3 drivers/net/can/flexcan.c | 123 +++- drivers/net/ethernet/atheros/ag71xx.c |4 drivers/net/ipa/ipa_reg.h | 22 - drivers/net/phy/sfp-bus.c | 15 + drivers/net/phy/sfp.c | 17 + drivers/net/tap.c |7 drivers/net/tun.c |5 drivers/net/usb/qmi_wwan.c |1 drivers/net/wireless/ath/ath10k/ahb.c |5 drivers/net/wireless/ath/ath10k/core.c | 25 + drivers/net/wireless/ath/ath10k/core.h |5 drivers/net/wireless/ath/ath10k/mac.c | 15 - drivers/net/wireless/ath/ath10k/pci.c |7 drivers/net/wireless/ath/ath10k/sdio.c |5 drivers/net/wireless/ath/ath10k/snoc.c |6 drivers/net/wireless/broadcom/brcm80211/brcmfmac/dmi.c | 32 ++ drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 18 + drivers/net/wireless/intel/iwlwifi/iwl-config.h|3 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 26 + drivers/net/wireless/mediatek/mt76/mt7615/mac.c| 20 + drivers/net/wireless/mediatek/mt76/mt7615/mt7615.h |2 drivers/net/wireless/mediatek/mt76/mt7615/pci_init.c | 12 drivers/net/wireless/mediatek/mt76/mt7915/init.c | 18 - drivers/net/wireless/mediatek/mt76/mt7915/mac.c| 24 + drivers/net/wireless/mediatek/mt76/mt7915/mt7915.h |1 drivers/net/wireless/microchip/wilc1000/netdev.c |2 drivers/net/wireless/microchip/wilc1000/wlan.c | 15 - drivers/net/wireless/microchip/wilc1000/wlan.h |3 drivers/net/wireless/ti/wl12xx/main.c |3 drivers/net/wireless/ti/wlcore/main.c | 15 - drivers/net/wireless/ti/wlcore/wlcore.h|3 drivers/net/xen-netback/netback.c | 12 d
Re: [RFC PATCH v2 00/13] Add futex2 syscall
On Sun, 7 Mar 2021 at 22:35, Stefan Metzmacher wrote: > Instead of having a blocked futex_waitv() waiting on an fd (maybe a generic > eventfd() or a new futex2fd()) > would be a better interface? Like bring back FUTEX_FD? (which was removed back in 2.6.25)
Re: [PATCH 1/2] iio: cros_ec: do an early exit if not physical_device case
On Tue, 2 Mar 2021 11:46:06 +0100
Enric Balletbo i Serra wrote:
> Hi all,
>
> On 21/2/21 17:29, Jonathan Cameron wrote:
> > On Mon, 23 Nov 2020 16:40:16 +0200
> > Alexandru Ardelean wrote:
> >
> >> This whole code-block was put under one big if() condition/block.
> >> This change does an early return if the 'physical_device' boolean is false,
> >> thus unindenting the block by one level.
> >>
> >> No other functional change has been done.
> >>
> >> Signed-off-by: Alexandru Ardelean
> > @Gwendal, others This series from Alex has been outstanding for a while
> > but may well still apply.
> > Ideally looking for an ack.
> >
>
> This looks good to me.
>
> Acked-by: Enric Balletbo i Serra
Hi Enric, Ack or both patches or just this one?
@Alex, series needs a rebase. I'm not totally sure what's changed.
If you don't get to it I'll do it at somepoint but unlikely to
be terribly soon!
Jonathan
>
> Thanks,
> Enric
>
> > Thanks,
> >
> > Jonathan
> >
> >> ---
> >> .../cros_ec_sensors/cros_ec_sensors_core.c| 161 +-
> >> 1 file changed, 81 insertions(+), 80 deletions(-)
> >>
> >> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> index 5c6c4e6fec9b..9470014936f2 100644
> >> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> >> @@ -287,89 +287,90 @@ int cros_ec_sensors_core_init(struct platform_device
> >> *pdev,
> >>
> >>indio_dev->name = pdev->name;
> >>
> >> - if (physical_device) {
> >> - state->param.cmd = MOTIONSENSE_CMD_INFO;
> >> - state->param.info.sensor_num = sensor_platform->sensor_num;
> >> - ret = cros_ec_motion_send_host_cmd(state, 0);
> >> - if (ret) {
> >> - dev_warn(dev, "Can not access sensor info\n");
> >> + if (!physical_device)
> >> + return 0;
> >> +
> >> + state->param.cmd = MOTIONSENSE_CMD_INFO;
> >> + state->param.info.sensor_num = sensor_platform->sensor_num;
> >> + ret = cros_ec_motion_send_host_cmd(state, 0);
> >> + if (ret) {
> >> + dev_warn(dev, "Can not access sensor info\n");
> >> + return ret;
> >> + }
> >> + state->type = state->resp->info.type;
> >> + state->loc = state->resp->info.location;
> >> +
> >> + /* Set sign vector, only used for backward compatibility. */
> >> + memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
> >> +
> >> + for (i = CROS_EC_SENSOR_X; i < CROS_EC_SENSOR_MAX_AXIS; i++)
> >> + state->calib[i].scale = MOTION_SENSE_DEFAULT_SCALE;
> >> +
> >> + /* 0 is a correct value used to stop the device */
> >> + if (state->msg->version < 3) {
> >> + get_default_min_max_freq(state->resp->info.type,
> >> + &frequencies[1],
> >> + &frequencies[2],
> >> + &state->fifo_max_event_count);
> >> + } else {
> >> + frequencies[1] = state->resp->info_3.min_frequency;
> >> + frequencies[2] = state->resp->info_3.max_frequency;
> >> + state->fifo_max_event_count =
> >> + state->resp->info_3.fifo_max_event_count;
> >> + }
> >> + for (i = 0; i < ARRAY_SIZE(frequencies); i++) {
> >> + state->frequencies[2 * i] = frequencies[i] / 1000;
> >> + state->frequencies[2 * i + 1] =
> >> + (frequencies[i] % 1000) * 1000;
> >> + }
> >> +
> >> + if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE_FIFO)) {
> >> + /*
> >> + * Create a software buffer, feed by the EC FIFO.
> >> + * We can not use trigger here, as events are generated
> >> + * as soon as sample_frequency is set.
> >> + */
> >> + struct iio_buffer *buffer;
> >> +
> >> + buffer = devm_iio_kfifo_allocate(dev);
> >> + if (!buffer)
> >> + return -ENOMEM;
> >> +
> >> + iio_device_attach_buffer(indio_dev, buffer);
> >> + indio_dev->modes = INDIO_BUFFER_SOFTWARE;
> >> +
> >> + ret = cros_ec_sensorhub_register_push_data(
> >> + sensor_hub, sensor_platform->sensor_num,
> >> + indio_dev, push_data);
> >> + if (ret)
> >>return ret;
> >> - }
> >> - state->type = state->resp->info.type;
> >> - state->loc = state->resp->info.location;
> >>
> >> - /* Set sign vector, only used for backward compatibility. */
> >> - memset(state->sign, 1, CROS_EC_SENSOR_MAX_AXIS);
> >> + ret = devm_add_action_or_reset(
> >> + dev, cros_ec_sensors_core_clean, pdev);
> >> + if (ret)
> >> + return ret;
> >>
> >> - for (i = CROS_EC_SENSOR_X; i < CROS_EC_SENSOR_MAX_AXIS; i++)
> >> - state->calib[i].scale = MOTION_SENSE_DEFAULT_SCAL
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:1576:2: error: implicit declaration of function 'enable_kernel_vsx'
Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: a38fd8748464831584a19438cbb3082b5a2dab15 commit: 582e2ce5b4ece37055c6ebe58ab48a4817d30b10 drm/amdgpu/display: FP fixes for DCN3.x (v4) date: 4 months ago config: powerpc-randconfig-r003-20210307 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 4d90e460bcc7b3e5ff6c7e2e05e974772489c4b8) 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 # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=582e2ce5b4ece37055c6ebe58ab48a4817d30b10 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 582e2ce5b4ece37055c6ebe58ab48a4817d30b10 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): ^ :188:1: note: expanded from here DCN_BASE__INST0_SEG3 ^ drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:373:52: note: expanded from macro 'DCN_BASE__INST0_SEG3' #define DCN_BASE__INST0_SEG3 0x9000 ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:753:3: note: previous initialization is here HWSEQ_DCN30_REG_LIST() ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_hwseq.h:341:2: note: expanded from macro 'HWSEQ_DCN30_REG_LIST' HWSEQ_DCN2_REG_LIST(),\ ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_hwseq.h:244:2: note: expanded from macro 'HWSEQ_DCN2_REG_LIST' SR(MPC_CRC_RESULT_C), \ ^~~~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:247:15: note: expanded from macro 'SR' .reg_name = BASE(mm ## reg_name ## _BASE_IDX) + \ ^~ note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:242:25: note: expanded from macro 'BASE_INNER' #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg ^ :196:1: note: expanded from here DCN_BASE__INST0_SEG3 ^ drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:373:52: note: expanded from macro 'DCN_BASE__INST0_SEG3' #define DCN_BASE__INST0_SEG3 0x9000 ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:753:3: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] HWSEQ_DCN30_REG_LIST() ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_hwseq.h:357:2: note: expanded from macro 'HWSEQ_DCN30_REG_LIST' SR(MPC_CRC_RESULT_AR), \ ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:247:15: note: expanded from macro 'SR' .reg_name = BASE(mm ## reg_name ## _BASE_IDX) + \ ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:244:19: note: expanded from macro 'BASE' #define BASE(seg) BASE_INNER(seg) ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:242:25: note: expanded from macro 'BASE_INNER' #define BASE_INNER(seg) DCN_BASE__INST0_SEG ## seg ^ :192:1: note: expanded from here DCN_BASE__INST0_SEG3 ^ drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:373:52: note: expanded from macro 'DCN_BASE__INST0_SEG3' #define DCN_BASE__INST0_SEG3 0x9000 ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:753:3: note: previous initialization is here HWSEQ_DCN30_REG_LIST() ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dce_hwseq.h:341:2: note: expanded from macro 'HWSEQ_DCN30_REG_LIST' HWSEQ_DCN2_REG_LIST(),\ ^
Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support opening extra buffers for IIO device
On Sat, 6 Mar 2021 19:00:52 +0200
Alexandru Ardelean wrote:
> On Sun, Feb 28, 2021 at 9:00 PM Jonathan Cameron
> wrote:
> >
> > On Sun, 28 Feb 2021 16:51:51 +0100
> > Lars-Peter Clausen wrote:
> >
> > > On 2/28/21 3:34 PM, Jonathan Cameron wrote:
> > > > On Sun, 28 Feb 2021 09:51:38 +0100
> > > > Lars-Peter Clausen wrote:
> > > >
> > > >> On 2/15/21 11:40 AM, Alexandru Ardelean wrote:
> > > >>> With this change, an ioctl() call is added to open a character device
> > > >>> for a
> > > >>> buffer. The ioctl() number is 'i' 0x91, which follows the
> > > >>> IIO_GET_EVENT_FD_IOCTL ioctl.
> > > >>>
> > > >>> The ioctl() will return an FD for the requested buffer index. The
> > > >>> indexes
> > > >>> are the same from the /sys/iio/devices/iio:deviceX/bufferY (i.e. the Y
> > > >>> variable).
> > > >>>
> > > >>> Since there doesn't seem to be a sane way to return the FD for
> > > >>> buffer0 to
> > > >>> be the same FD for the /dev/iio:deviceX, this ioctl() will return
> > > >>> another
> > > >>> FD for buffer0 (or the first buffer). This duplicate FD will be able
> > > >>> to
> > > >>> access the same buffer object (for buffer0) as accessing directly the
> > > >>> /dev/iio:deviceX chardev.
> > > >>>
> > > >>> Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl() implemented, as
> > > >>> the
> > > >>> index for each buffer (and the count) can be deduced from the
> > > >>> '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the number of
> > > >>> bufferY folders).
> > > >>>
> > > >>> Used following C code to test this:
> > > >>> ---
> > > >>>
> > > >>>#include
> > > >>>#include
> > > >>>#include
> > > >>>#include
> > > >>>#include > > >>>#include
> > > >>>
> > > >>>#define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
> > > >>>
> > > >>> int main(int argc, char *argv[])
> > > >>> {
> > > >>> int fd;
> > > >>> int fd1;
> > > >>> int ret;
> > > >>>
> > > >>> if ((fd = open("/dev/iio:device0", O_RDWR))<0) {
> > > >>> fprintf(stderr, "Error open() %d errno %d\n",fd,
> > > >>> errno);
> > > >>> return -1;
> > > >>> }
> > > >>>
> > > >>> fprintf(stderr, "Using FD %d\n", fd);
> > > >>>
> > > >>> fd1 = atoi(argv[1]);
> > > >>>
> > > >>> ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, &fd1);
> > > >>> if (ret < 0) {
> > > >>> fprintf(stderr, "Error for buffer %d ioctl() %d
> > > >>> errno %d\n", fd1, ret, errno);
> > > >>> close(fd);
> > > >>> return -1;
> > > >>> }
> > > >>>
> > > >>> fprintf(stderr, "Got FD %d\n", fd1);
> > > >>>
> > > >>> close(fd1);
> > > >>> close(fd);
> > > >>>
> > > >>> return 0;
> > > >>> }
> > > >>> ---
> > > >>>
> > > >>> Results are:
> > > >>> ---
> > > >>># ./test 0
> > > >>>Using FD 3
> > > >>>Got FD 4
> > > >>>
> > > >>># ./test 1
> > > >>>Using FD 3
> > > >>>Got FD 4
> > > >>>
> > > >>># ./test 2
> > > >>>Using FD 3
> > > >>>Got FD 4
> > > >>>
> > > >>># ./test 3
> > > >>>Using FD 3
> > > >>>Got FD 4
> > > >>>
> > > >>># ls /sys/bus/iio/devices/iio\:device0
> > > >>>buffer buffer0 buffer1 buffer2 buffer3 dev
> > > >>>in_voltage_sampling_frequency in_voltage_scale
> > > >>>in_voltage_scale_available
> > > >>>name of_node power scan_elements subsystem uevent
> > > >>> ---
> > > >>>
> > > >>> iio:device0 has some fake kfifo buffers attached to an IIO device.
> > > >> For me there is one major problem with this approach. We only allow one
> > > >> application to open /dev/iio:deviceX at a time. This means we can't
> > > >> have
> > > >> different applications access different buffers of the same device. I
> > > >> believe this is a circuital feature.
> > > > Thats not quite true (I think - though I've not tested it). What we
> > > > don't
> > > > allow is for multiple processes to access them in an unaware fashion.
> > > > My assumption is we can rely on fork + fd passing via appropriate
> > > > sockets.
> > > >
> > > >> It is possible to open the chardev, get the annonfd, close the chardev
> > > >> and keep the annonfd open. Then the next application can do the same
> > > >> and
> > > >> get access to a different buffer. But this has room for race conditions
> > > >> when two applications try this at the very same time.
> > > >>
> > > >> We need to somehow address this.
> > > > I'd count this as a bug :). It could be safely done in a particular
> > > > custom
> > > > system but in general it opens a can of worm.
> > > >
> > > >> I'm also not much of a fan of using
[PATCH v6 2/8] security/brute: Define a LSM and manage statistical data
Add a new Kconfig file to define a menu entry under "Security options" to enable the "Fork brute force attack detection and mitigation" feature. For a correct management of a fork brute force attack it is necessary that all the tasks hold statistical data. The same statistical data needs to be shared between all the tasks that hold the same memory contents or in other words, between all the tasks that have been forked without any execve call. So, define a statistical data structure to hold all the necessary information shared by all the fork hierarchy processes. This info is basically the number of crashes, the last crash timestamp and the crash period's moving average. When a forked task calls the execve system call, the memory contents are set with new values. So, in this scenario the parent's statistical data no need to be shared. Instead, a new statistical data structure must be allocated to start a new hierarchy. The statistical data that is shared between all the fork hierarchy processes needs to be freed when this hierarchy disappears. So, based in all the previous information define a LSM with three hooks to manage all the commented cases. These hooks are "task_alloc" to do the fork management, "bprm_committing_creds" to do the execve management and "task_free" to release the resources. Also, add to the task_struct's security blob the pointer to the statistical data. This way, all the tasks will have access to this information. Signed-off-by: John Wood --- security/Kconfig| 11 +- security/Makefile | 4 + security/brute/Kconfig | 12 ++ security/brute/Makefile | 2 + security/brute/brute.c | 257 5 files changed, 281 insertions(+), 5 deletions(-) create mode 100644 security/brute/Kconfig create mode 100644 security/brute/Makefile create mode 100644 security/brute/brute.c diff --git a/security/Kconfig b/security/Kconfig index 7561f6f99f1d..204bb311b1f1 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -240,6 +240,7 @@ source "security/safesetid/Kconfig" source "security/lockdown/Kconfig" source "security/integrity/Kconfig" +source "security/brute/Kconfig" choice prompt "First legacy 'major LSM' to be initialized" @@ -277,11 +278,11 @@ endchoice config LSM string "Ordered list of enabled LSMs" - default "lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK - default "lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR - default "lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO - default "lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC - default "lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" + default "brute,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK + default "brute,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR + default "brute,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO + default "brute,lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC + default "brute,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf" help A comma-separated list of LSMs, in initialization order. Any LSMs left off this list will be ignored. This can be diff --git a/security/Makefile b/security/Makefile index 3baf435de541..1236864876da 100644 --- a/security/Makefile +++ b/security/Makefile @@ -36,3 +36,7 @@ obj-$(CONFIG_BPF_LSM) += bpf/ # Object integrity file lists subdir-$(CONFIG_INTEGRITY) += integrity obj-$(CONFIG_INTEGRITY)+= integrity/ + +# Object brute file lists +subdir-$(CONFIG_SECURITY_FORK_BRUTE) += brute +obj-$(CONFIG_SECURITY_FORK_BRUTE) += brute/ diff --git a/security/brute/Kconfig b/security/brute/Kconfig new file mode 100644 index ..1bd2df1e2dec --- /dev/null +++ b/security/brute/Kconfig @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0 +config SECURITY_FORK_BRUTE + bool "Fork brute force attack detection and mitigation" + depends on SECURITY + help + This is an LSM that stops any fork brute force attack against + vulnerable userspace processes. The detection method is based on + the application crash period and as a mitigation procedure all the + offending tasks are killed. Like capabilities, this security module + stacks with other LSMs. + + If you are unsure how to answer this question, answer N. diff --git a/security/brute/Makefile b/security/brute/Makefile new file mode 100644 index ..d3f233a132a9 --- /dev/null +++ b/security/brute/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-
Re: [PATCH] ath: ath6kl: fix error return code of ath6kl_htc_rx_bundle()
On Sun, Mar 07, 2021 at 05:31:01PM +0800, Jia-Ju Bai wrote: > Hi Leon, > > I am quite sorry for my incorrect patches... > My static analysis tool reports some possible bugs about error handling > code, and thus I write some patches for the bugs that seem to be true in my > opinion. > Because I am not familiar with many device drivers, some of my reported bugs > can be false positives... It will be much helpful if instead of writing new static analysis tool, you will invest time and improve existing well known tools, like smatch and sparse. Right now, you didn't report bugs, but sent bunch of patches that most of the time are incorrect. So it is not "some of my reported bugs can be false positives...", but "some of my patches can fix real bugs by chance". Thanks
Re: [PATCH] iio: kfifo: mask flags without zero-check in devm_iio_kfifo_buffer_setup()
On Sat, 6 Mar 2021 18:28:34 +0200
Alexandru Ardelean wrote:
> As pointed by Lars, this doesn't require a zero-check. Also, while looking
> at this a little closer at it (again), the masking can be done later, as
> there is a zero-check for 'mode_flags' anyway, which returns -EINVAL. And
> we only need the 'mode_flags' later in the logic.
>
> This change is more of a tweak.
>
> Fixes: ae9886d6aa29 ("iio: kfifo: add devm_iio_kfifo_buffer_setup() helper")
> Cc: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
I've applied this as a separate patch. Thanks,
Jonathan
> ---
>
> Apologies for the late-ness of this.
> I don't know if this makes sense to squash in the original, or to have
> as a fix commit.
> It is a bit messy now that the original is committed into the tree,
> and now we're fixing/tweaking it.
>
> drivers/iio/buffer/kfifo_buf.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/buffer/kfifo_buf.c b/drivers/iio/buffer/kfifo_buf.c
> index e8a434f84778..8e3a1a9e495c 100644
> --- a/drivers/iio/buffer/kfifo_buf.c
> +++ b/drivers/iio/buffer/kfifo_buf.c
> @@ -275,9 +275,6 @@ int devm_iio_kfifo_buffer_setup(struct device *dev,
> {
> struct iio_buffer *buffer;
>
> - if (mode_flags)
> - mode_flags &= kfifo_access_funcs.modes;
> -
> if (!mode_flags)
> return -EINVAL;
>
> @@ -285,6 +282,8 @@ int devm_iio_kfifo_buffer_setup(struct device *dev,
> if (!buffer)
> return -ENOMEM;
>
> + mode_flags &= kfifo_access_funcs.modes;
> +
> indio_dev->modes |= mode_flags;
> indio_dev->setup_ops = setup_ops;
>
Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers array
On Sat, 6 Mar 2021 18:47:10 +0200
Alexandru Ardelean wrote:
> Thanks to Lars for finding this.
> The free of the 'attached_buffers' array should be done as late as
> possible. This change moves it to iio_buffers_put(), which looks like
> the best place for it, since it takes place right before the IIO device
> data is free'd.
It feels a bit wrong to do direct freeing of stuff in a _put() call
given that kind of implies nothing will happen without some reference
count dropping to 0. We could think about renaming the function to
something like
iio_buffers_put_and_free_array() but is a bit long winded.
Otherwise, I'm fine with this but want to let it sit on list a tiny bit
longer before I take it as it's not totally trivial unlike the previous
one.
Jonathan
> The free of this array will be handled by calling iio_device_free().
>
> It looks like this issue was ocurring on the error path of
> iio_buffers_alloc_sysfs_and_mask() and in
> iio_buffers_free_sysfs_and_mask()
>
> Added a comment in the doc-header of iio_device_attach_buffer() to
> mention how this will be free'd in case anyone is reading the code
> and becoming confused about it.
>
> Fixes: 36f3118c414d ("iio: buffer: introduce support for attaching more IIO
> buffers")
> Reported-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/industrialio-buffer.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/industrialio-buffer.c
> b/drivers/iio/industrialio-buffer.c
> index 1a415e97174e..3d0712651d43 100644
> --- a/drivers/iio/industrialio-buffer.c
> +++ b/drivers/iio/industrialio-buffer.c
> @@ -336,6 +336,8 @@ void iio_buffers_put(struct iio_dev *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[i];
> iio_buffer_put(buffer);
> }
> +
> + kfree(iio_dev_opaque->attached_buffers);
> }
>
> static ssize_t iio_show_scan_index(struct device *dev,
> @@ -1764,7 +1766,6 @@ int iio_buffers_alloc_sysfs_and_mask(struct iio_dev
> *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[unwind_idx];
> __iio_buffer_free_sysfs_and_mask(buffer);
> }
> - kfree(iio_dev_opaque->attached_buffers);
> return ret;
> }
>
> @@ -1786,8 +1787,6 @@ void iio_buffers_free_sysfs_and_mask(struct iio_dev
> *indio_dev)
> buffer = iio_dev_opaque->attached_buffers[i];
> __iio_buffer_free_sysfs_and_mask(buffer);
> }
> -
> - kfree(iio_dev_opaque->attached_buffers);
> }
>
> /**
> @@ -2062,6 +2061,8 @@ static int iio_buffer_mmap(struct file *filep, struct
> vm_area_struct *vma)
> * This function attaches a buffer to a IIO device. The buffer stays
> attached to
> * the device until the device is freed. For legacy reasons, the first
> attached
> * buffer will also be assigned to 'indio_dev->buffer'.
> + * The array allocated here, will be free'd via the iio_buffers_put() call,
> + * which is handled by the iio_device_free().
> */
> int iio_device_attach_buffer(struct iio_dev *indio_dev,
>struct iio_buffer *buffer)
[PATCH v6 3/8] securtiy/brute: Detect a brute force attack
To detect a brute force attack it is necessary that the statistics
shared by all the fork hierarchy processes be updated in every fatal
crash and the most important data to update is the application crash
period. To do so, use the new "task_fatal_signal" LSM hook added in a
previous step.
The application crash period must be a value that is not prone to change
due to spurious data and follows the real crash period. So, to compute
it, the exponential moving average (EMA) is used.
There are two types of brute force attacks that need to be detected. The
first one is an attack that happens through the fork system call and the
second one is an attack that happens through the execve system call. The
first type uses the statistics shared by all the fork hierarchy
processes, but the second type cannot use this statistical data due to
these statistics disappear when the involved tasks finished. In this
last scenario the attack info should be tracked by the statistics of a
higher fork hierarchy (the hierarchy that contains the process that
forks before the execve system call).
Moreover, these two attack types have two variants. A slow brute force
attack that is detected if the maximum number of faults per fork
hierarchy is reached and a fast brute force attack that is detected if
the application crash period falls below a certain threshold.
Also, this patch adds locking to protect the statistics pointer hold by
every process.
Signed-off-by: John Wood
---
security/brute/brute.c | 498 +++--
1 file changed, 479 insertions(+), 19 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 99d099e45112..870db55332d4 100644
--- a/security/brute/brute.c
+++ b/security/brute/brute.c
@@ -11,9 +11,14 @@
#include
#include
#include
+#include
#include
#include
+#include
+#include
#include
+#include
+#include
#include
#include
#include
@@ -37,6 +42,11 @@ struct brute_stats {
u64 period;
};
+/*
+ * brute_stats_ptr_lock - Lock to protect the brute_stats structure pointer.
+ */
+static DEFINE_RWLOCK(brute_stats_ptr_lock);
+
/*
* brute_blob_sizes - LSM blob sizes.
*
@@ -74,7 +84,7 @@ static struct brute_stats *brute_new_stats(void)
{
struct brute_stats *stats;
- stats = kmalloc(sizeof(struct brute_stats), GFP_KERNEL);
+ stats = kmalloc(sizeof(struct brute_stats), GFP_ATOMIC);
if (!stats)
return NULL;
@@ -99,16 +109,17 @@ static struct brute_stats *brute_new_stats(void)
* It's mandatory to disable interrupts before acquiring the brute_stats::lock
* since the task_free hook can be called from an IRQ context during the
* execution of the task_alloc hook.
+ *
+ * Context: Must be called with interrupts disabled and brute_stats_ptr_lock
+ * held.
*/
static void brute_share_stats(struct brute_stats *src,
struct brute_stats **dst)
{
- unsigned long flags;
-
- spin_lock_irqsave(&src->lock, flags);
+ spin_lock(&src->lock);
refcount_inc(&src->refc);
*dst = src;
- spin_unlock_irqrestore(&src->lock, flags);
+ spin_unlock(&src->lock);
}
/**
@@ -126,26 +137,36 @@ static void brute_share_stats(struct brute_stats *src,
* this task and the new one being allocated. Otherwise, share the statistics
* that the current task already has.
*
+ * It's mandatory to disable interrupts before acquiring brute_stats_ptr_lock
+ * and brute_stats::lock since the task_free hook can be called from an IRQ
+ * context during the execution of the task_alloc hook.
+ *
* Return: -ENOMEM if the allocation of the new statistics structure fails.
Zero
* otherwise.
*/
static int brute_task_alloc(struct task_struct *task, unsigned long
clone_flags)
{
struct brute_stats **stats, **p_stats;
+ unsigned long flags;
stats = brute_stats_ptr(task);
p_stats = brute_stats_ptr(current);
+ write_lock_irqsave(&brute_stats_ptr_lock, flags);
if (likely(*p_stats)) {
brute_share_stats(*p_stats, stats);
+ write_unlock_irqrestore(&brute_stats_ptr_lock, flags);
return 0;
}
*stats = brute_new_stats();
- if (!*stats)
+ if (!*stats) {
+ write_unlock_irqrestore(&brute_stats_ptr_lock, flags);
return -ENOMEM;
+ }
brute_share_stats(*stats, p_stats);
+ write_unlock_irqrestore(&brute_stats_ptr_lock, flags);
return 0;
}
@@ -167,9 +188,9 @@ static int brute_task_alloc(struct task_struct *task,
unsigned long clone_flags)
* only one task (the task that calls the execve function) points to the data.
* In this case, the previous allocation is used but the statistics are reset.
*
- * It's mandatory to disable interrupts before acquiring the brute_stats::lock
- * since the task_free hook can be called from an IRQ context during the
- * execution of the bprm_comm
Re: [PATCH] blk-cgroup: Fix the recursive blkg rwstat
On Fri, Mar 05, 2021 at 11:32:05AM -0700, Jens Axboe wrote: > On 3/5/21 1:13 AM, Xunlei Pang wrote: > > The current blkio.throttle.io_service_bytes_recursive doesn't > > work correctly. > > > > As an example, for the following blkcg hierarchy: > > (Made 1GB READ in test1, 512MB READ in test2) > > test > > /\ > > test1 test2 > > > > $ head -n 1 test/test1/blkio.throttle.io_service_bytes_recursive > > 8:0 Read 1073684480 > > $ head -n 1 test/test2/blkio.throttle.io_service_bytes_recursive > > 8:0 Read 537448448 > > $ head -n 1 test/blkio.throttle.io_service_bytes_recursive > > 8:0 Read 537448448 > > > > Clearly, above data of "test" reflects "test2" not "test1"+"test2". > > > > Do the correct summary in blkg_rwstat_recursive_sum(). > > LGTM, Tejun? Gees, that's horrible. Thanks for fixing this. Acked-by: Tejun Heo -- tejun
Re: [syzbot] possible deadlock in io_sq_thread_finish
On 07/03/2021 09:49, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:a38fd874 Linux 5.12-rc2
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=143ee02ad0
> kernel config: https://syzkaller.appspot.com/x/.config?x=db9c6adb4986f2f2
> dashboard link: https://syzkaller.appspot.com/bug?extid=ac39856cb1b332dbbdda
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+ac39856cb1b332dbb...@syzkaller.appspotmail.com
Legit error, park() might take an sqd lock, and then we take it again.
I'll patch it up
>
>
> WARNING: possible recursive locking detected
> 5.12.0-rc2-syzkaller #0 Not tainted
>
> kworker/u4:7/7615 is trying to acquire lock:
> 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_stop
> fs/io_uring.c:7099 [inline]
> 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_put_sq_data
> fs/io_uring.c:7115 [inline]
> 888144a02870 (&sqd->lock){+.+.}-{3:3}, at:
> io_sq_thread_finish+0x408/0x650 fs/io_uring.c:7139
>
> but task is already holding lock:
> 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
> fs/io_uring.c:7088 [inline]
> 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park+0x63/0xc0
> fs/io_uring.c:7082
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(&sqd->lock);
> lock(&sqd->lock);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by kworker/u4:7/7615:
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> set_work_data kernel/workqueue.c:616 [inline]
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
> #0: 888010469138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
> process_one_work+0x871/0x1600 kernel/workqueue.c:2246
> #1: c900023a7da8 ((work_completion)(&ctx->exit_work)){+.+.}-{0:0}, at:
> process_one_work+0x8a5/0x1600 kernel/workqueue.c:2250
> #2: 888144a02870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
> fs/io_uring.c:7088 [inline]
> #2: 888144a02870 (&sqd->lock){+.+.}-{3:3}, at:
> io_sq_thread_park+0x63/0xc0 fs/io_uring.c:7082
>
> stack backtrace:
> CPU: 1 PID: 7615 Comm: kworker/u4:7 Not tainted 5.12.0-rc2-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events_unbound io_ring_exit_work
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> print_deadlock_bug kernel/locking/lockdep.c:2829 [inline]
> check_deadlock kernel/locking/lockdep.c:2872 [inline]
> validate_chain kernel/locking/lockdep.c:3661 [inline]
> __lock_acquire.cold+0x14c/0x3b4 kernel/locking/lockdep.c:4900
> lock_acquire kernel/locking/lockdep.c:5510 [inline]
> lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5475
> __mutex_lock_common kernel/locking/mutex.c:946 [inline]
> __mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1093
> io_sq_thread_stop fs/io_uring.c:7099 [inline]
> io_put_sq_data fs/io_uring.c:7115 [inline]
> io_sq_thread_finish+0x408/0x650 fs/io_uring.c:7139
> io_ring_ctx_free fs/io_uring.c:8408 [inline]
> io_ring_exit_work+0x82/0x9a0 fs/io_uring.c:8539
> process_one_work+0x98d/0x1600 kernel/workqueue.c:2275
> worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
> kthread+0x3b1/0x4a0 kernel/kthread.c:292
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
--
Pavel Begunkov
Re: [PATCH] iio: adc: axp20x_adc: fix charging current reporting on AXP22x
On Sun, 7 Mar 2021 02:52:38 +0300 Evgeny Boger wrote: > Both the charging and discharging currents on AXP22x are stored as > 12-bit integers, in accordance with the datasheet. > It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA). > > The scale factor of 0.5 is never mentioned in datasheet, nor in the > vendor source code. I think it was here to compensate for > erroneous additional bit in register width. > > Tested on custom A40i+AXP221s board with external ammeter as > a reference. > > Signed-off-by: Evgeny Boger +CC Quentin's bootlin address. One comment inline, Jonathan > --- > drivers/iio/adc/axp20x_adc.c | 14 ++ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c > index 3e0c0233b431..8db6699c20c3 100644 > --- a/drivers/iio/adc/axp20x_adc.c > +++ b/drivers/iio/adc/axp20x_adc.c > @@ -253,17 +253,7 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev, > struct axp20x_adc_iio *info = iio_priv(indio_dev); > int size; > > - /* > - * N.B.: Unlike the Chinese datasheets tell, the charging current is > - * stored on 12 bits, not 13 bits. Only discharging current is on 13 > - * bits. > - */ > - if (chan->type == IIO_CURRENT && chan->channel == AXP22X_BATT_DISCHRG_I) > - size = 13; > - else > - size = 12; > - > - *val = axp20x_read_variable_width(info->regmap, chan->address, size); > + *val = axp20x_read_variable_width(info->regmap, chan->address, 12); > if (*val < 0) > return *val; > > @@ -387,7 +377,7 @@ static int axp22x_adc_scale(struct iio_chan_spec const > *chan, int *val, > > case IIO_CURRENT: > *val = 0; > - *val2 = 50; > + *val2 = 100; > return IIO_VAL_INT_PLUS_MICRO; *val = 1; return IIO_VAL_INT; Should work if the scale factor is 1. Note that we could just have reported the channel as _processed in the first place, but given we didn't better to keep the ABI the same and just have a noop scale factor. > > case IIO_TEMP:
Re: [PATCH] media: platform: sunxi: sun6i-csi: fix error return code of sun6i_video_start_streaming()
On Sat, Mar 6, 2021 at 10:15 PM Jia-Ju Bai wrote:
>
> When sun6i_video_remote_subdev() returns NULL to subdev, no error return
> code of sun6i_video_start_streaming() is assigned.
> To fix this bug, ret is assigned with -EINVAL in this case.
>
> Reported-by: TOTE Robot
> Signed-off-by: Jia-Ju Bai
This should have the tag:
Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
Please try to add them when fixing bugs. And this should also be tagged
for stable, so
Cc:
Otherwise,
Acked-by: Chen-Yu Tsai
Re: [Patch v3 0/2] cgroup: New misc cgroup controller
Hello, On Thu, Mar 04, 2021 at 03:19:44PM -0800, Vipin Sharma wrote: > This patch series is creating a new misc cgroup controller for limiting > and tracking of resources which are not abstract like other cgroup > controllers. > > This controller was initially proposed as encryption_id but after > the feedbacks, it is now changed to misc cgroup. > https://lore.kernel.org/lkml/20210108012846.4134815-2-vipi...@google.com/ Vipin, thank you very much for your persistence and patience. The patchset looks good to me. Michal, as you've been reviewing the series, can you please take another look and ack them if you don't find anything objectionable? -- tejun
Re: [PATCH] iio: buffer: fix use-after-free for attached_buffers array
On 3/7/21 1:36 PM, Jonathan Cameron wrote: On Sat, 6 Mar 2021 18:47:10 +0200 Alexandru Ardelean wrote: Thanks to Lars for finding this. The free of the 'attached_buffers' array should be done as late as possible. This change moves it to iio_buffers_put(), which looks like the best place for it, since it takes place right before the IIO device data is free'd. It feels a bit wrong to do direct freeing of stuff in a _put() call given that kind of implies nothing will happen without some reference count dropping to 0. We could think about renaming the function to something like iio_buffers_put_and_free_array() but is a bit long winded. Otherwise, I'm fine with this but want to let it sit on list a tiny bit longer before I take it as it's not totally trivial unlike the previous one. Maybe to go with naming schema of iio_device_attach_buffer() call this function iio_device_detach_buffers(). We grab the reference in attach, and drop it in detach. - Lars
Re: [PATCH v9 1/3] ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
On Sun, Feb 14, 2021 at 02:13:48PM +0100, Oliver Graute wrote:
> This patch adds support for the i.MX6UL variant of the Variscite DART-6UL
> SoM Carrier-Board
>
> Signed-off-by: Oliver Graute
> Cc: Shawn Guo
> Cc: Neil Armstrong
> Cc: Marco Felsch
> Cc: Parthiban Nallathambi
> ---
> .../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 314
> +
Name imx6ul-var-dart-common.dtsi should be okay, as the file includes
imx6ul.dtsi?
> 1 file changed, 314 insertions(+)
>
> Changelog:
>
> v9:
> - added 3V and 5V regulator
> - move phy reset to subnode
> - added pwm-cells
> - fixed pad pin conflict
>
> v8:
> - remove can node
> - remove flexscan pinctrl
> - moved lcd and i2c pinctrl
> - sorted regulators
> - add dedicated pinctrl for dvfs regulator
>
> v7:
> - removed cpu0 node
> - fixed phy problem
>
> v6:
> - renamed touch regulator
> - renamed rmii clock
> - moved some muxing to baseboard
> - added pinctrl for gpio key
> - added bus-width to usdhc1
> - fixed missing subnode on partitions
>
> create mode 100644 arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
>
> diff --git a/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> new file mode 100644
> index ..b95fdc5
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-imx6ull-var-dart-common.dtsi
> @@ -0,0 +1,314 @@
> +// SPDX-License-Identifier: (GPL-2.0)
> +/dts-v1/;
> +
> +#include "imx6ul.dtsi"
Have a newline here.
> +/ {
> + chosen {
> + stdout-path = &uart1;
> + };
> +
> + memory@8000 {
> + device_type = "memory";
> + reg = <0x8000 0x2000>;
> + };
> +
> + clk_rmii_ref: clock-rmii-ref {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2500>;
> + clock-output-names = "rmii-ref";
> + };
> +
> + reg_3v3: regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "5V";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + reg_gpio_dvfs: regulator-gpio {
> + compatible = "regulator-gpio";
> + gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dvfs_reg>;
> + regulator-min-microvolt = <130>;
> + regulator-max-microvolt = <140>;
> + regulator-name = "gpio_dvfs";
> + regulator-type = "voltage";
> + enable-active-high;
Move this right after 'gpios'.
> + states = <130 0x1 140 0x0>;
> + };
> +
> + reg_sd1_vmmc: regulator-sd1-vmmc {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + reg_touch_3v3: regulator-touch-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "touch_3v3_supply";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + };
> +
Unneeded newline.
> +};
> +
> +&adc1 {
> + vref-supply = <®_touch_3v3>;
> +};
> +
> +&fec1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet1>;
> + phy-mode = "rmii";
> + phy-handle = <ðphy0>;
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethphy0: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + micrel,rmii-reference-clock-select-25-mhz;
> + clocks = <&clk_rmii_ref>;
> + clock-names = "rmii-ref";
> + reset-names = "phy";
> + reset-gpios=<&gpio5 10 1>;
Use define for polarity.
Shawn
> + reset-assert-us = <100>;
> + reg = <1>;
> + };
> +
> + ethphy1: ethernet-phy@3 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + micrel,rmii-reference-clock-select-25-mhz;
> + clocks = <&clk_rmii_ref>;
> + clock-names = "rmii-ref";
> + reg = <3>;
> + };
> + };
> +};
> +
> +&gpmi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpmi_nand>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + clock-frequency = <40>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> +};
> +
> +&pwm1 {
> + #pwm-cells = <2>;
> +
[GIT PULL] perf tools changes for v5.12: take 2
Hi Linus, Please consider pulling, rebased over v5.12-rc2, Best regards, - Arnaldo Test results at the end of this message. The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-tools-fixes-for-v5.12-2020-03-07 for you to fetch changes up to 6fc5baf5471700fd613f0b4e52ab4563f1942b78: perf cs-etm: Fix bitmap for option (2021-03-06 16:54:33 -0300) perf tools fixes for v5.12: - Fix wrong skipping for per-die aggregation in 'perf stat'. - Fix race in signal handling on large core count machines, setting up signal handlers earlier. - Fix -F for branch & mem modes in 'perf report'. - Fix the condition checks for max number of NUMA nodes in 'perf bench numa'. - Fix crash in 'perf diff' error path. - Fix filtering of empty build-ids in 'perf archive'. - Ensure read cmdlines from libtraceevent are null terminated. Recent regressions: - Fix control fifo permissions in 'perf daemon'. - Fix 'perf daemon' compile error with ASAN. - Fix running 'perf daemon' test for non root user. - Fix PERF_SAMPLE_WEIGHT_STRUCT 'perf test' failure on non-x86 arches. - Fix event's PMU name parsing related to new drm/i915/gt software-gt-awake-time event. Fixes from compiler instrumentation: - Fix leaks in 'perf test' entries, found using ASAN. - Fix use-after-free when 'perf stat -r' option is used. Arch specific: - Fix bitmap for option om ARM's CS-ETM. Documentation: - Fix documentation of verbose options. Build: - Clean 'generated' directory used for creating the syscall table on x86. - Fix ccache usage in $(CC) when generating arch errno table. - Cast (struct timeval).tv_sec when printing, fixing the build with MUSL libc. - Tighten snprintf() string precision to pass gcc check on some 32-bit arches. - Update UAPI copies from the kernel sources. - Fix regression on feature detection 'make clean' target. Signed-off-by: Arnaldo Carvalho de Melo Andreas Wendleder (1): perf tools: Clean 'generated' directory used for creating the syscall table on x86 Antonio Terceiro (1): perf build: Fix ccache usage in $(CC) when generating arch errno table Arnaldo Carvalho de Melo (12): tools headers UAPI: Update tools's copy of drm.h headers tools headers UAPI: Sync drm/i915_drm.h with the kernel sources tools headers UAPI: Sync openat2.h with the kernel sources perf arch powerpc: Sync powerpc syscall.tbl with the kernel sources tools headers UAPI s390: Sync ptrace.h kernel headers tools headers UAPI: Sync kvm.h headers with the kernel sources tools headers: Update syscall.tbl files to support mount_setattr tools headers UAPI: Update tools' copy of linux/coresight-pmu.h tools headers cpufeatures: Sync with the kernel sources tools headers UAPI: Sync KVM's kvm.h and vmx.h headers with the kernel sources perf tests x86: Move insn.h include to make sure it finds stddef.h perf map: Tighten snprintf() string precision to pass gcc check on some 32-bit arches Athira Rajeev (1): perf bench numa: Fix the condition checks for max number of NUMA nodes Dmitry Safonov (1): perf diff: Don't crash on freeing errno-session on the error path Ian Rogers (2): perf traceevent: Ensure read cmdlines are null terminated. perf tools: Fix documentation of verbose options Jin Yao (1): perf stat: Fix wrong skipping for per-die aggregation Jiri Olsa (4): perf build: Move feature cleanup under tools/build perf daemon: Fix control fifo permissions perf daemon: Fix running test for non root user perf tools: Fix event's PMU name parsing Kan Liang (2): perf test: Fix sample-parsing failure on non-x86 platforms perf test: Support the ins_lat check in the X86 specific test Michael Petlan (1): perf trace: Fix race in signal handling Namhyung Kim (14): perf test: Fix cpu and thread map leaks in basic mmap test perf test: Fix a memory leak in attr test perf test: Fix cpu and thread map leaks in task_exit test perf test: Fix cpu and thread map leaks in sw_clock_freq test perf test: Fix cpu and thread map leaks in code_reading test perf test: Fix cpu and thread map leaks in keep_tracking test perf test: Fix cpu and thread map leaks in switch_tracking test perf test: Fix a thread map leak in thread_map_synthesize test perf test: Fix a memory leak in thread_map_remove test perf test: Fix cpu map leaks in cpu_map_print test perf test: Fix cpu and thread map leaks in perf_time_to_tsc test libperf: Add perf_evlist__reset_id_hash() perf stat: Fix use-after-free when -r option is used perf
[PATCH v6 4/8] security/brute: Fine tuning the attack detection
To avoid false positives during the attack detection it is necessary to
narrow the possible cases. Only the following scenarios are taken into
account:
1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a
desirable memory layout is got (e.g. Stack Clash).
2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly
until a desirable memory layout is got (e.g. what CTFs do for simple
network service).
3.- Launching processes without exec() (e.g. Android Zygote) and exposing
state to attack a sibling.
4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly until
the previously shared memory layout of all the other children is
exposed (e.g. kind of related to HeartBleed).
In each case, a privilege boundary has been crossed:
Case 1: setuid/setgid process
Case 2: network to local
Case 3: privilege changes
Case 4: network to local
So, this patch checks if any of these privilege boundaries have been
crossed before to compute the application crash period.
Also, in every fatal crash only the signals delivered by the kernel are
taken into account with the exception of the SIGABRT signal since the
latter is used by glibc for stack canary, malloc, etc failures, which may
indicate that a mitigation has been triggered.
Signed-off-by: John Wood
---
security/brute/brute.c | 293 +++--
1 file changed, 280 insertions(+), 13 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 870db55332d4..38e5e050964a 100644
--- a/security/brute/brute.c
+++ b/security/brute/brute.c
@@ -3,15 +3,25 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
+#include
+#include
+#include
#include
#include
+#include
+#include
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -19,9 +29,35 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
#include
+#include
+
+/**
+ * struct brute_cred - Saved credentials.
+ * @uid: Real UID of the task.
+ * @gid: Real GID of the task.
+ * @suid: Saved UID of the task.
+ * @sgid: Saved GID of the task.
+ * @euid: Effective UID of the task.
+ * @egid: Effective GID of the task.
+ * @fsuid: UID for VFS ops.
+ * @fsgid: GID for VFS ops.
+ */
+struct brute_cred {
+ kuid_t uid;
+ kgid_t gid;
+ kuid_t suid;
+ kgid_t sgid;
+ kuid_t euid;
+ kgid_t egid;
+ kuid_t fsuid;
+ kgid_t fsgid;
+};
/**
* struct brute_stats - Fork brute force attack statistics.
@@ -30,6 +66,9 @@
* @faults: Number of crashes.
* @jiffies: Last crash timestamp.
* @period: Crash period's moving average.
+ * @saved_cred: Saved credentials.
+ * @network: Network activity flag.
+ * @bounds_crossed: Privilege bounds crossed flag.
*
* This structure holds the statistical data shared by all the fork hierarchy
* processes.
@@ -40,6 +79,9 @@ struct brute_stats {
unsigned char faults;
u64 jiffies;
u64 period;
+ struct brute_cred saved_cred;
+ unsigned char network : 1;
+ unsigned char bounds_crossed : 1;
};
/*
@@ -71,18 +113,25 @@ static inline struct brute_stats **brute_stats_ptr(struct
task_struct *task)
/**
* brute_new_stats() - Allocate a new statistics structure.
+ * @network_to_local: Network activity followed by a fork or execve system
call.
+ * @is_setid: The executable file has the setid flags set.
*
* If the allocation is successful the reference counter is set to one to
* indicate that there will be one task that points to this structure. Also,
the
* last crash timestamp is set to now. This way, it is possible to compute the
* application crash period at the first fault.
*
+ * Moreover, the credentials of the current task are saved. Also, the network
+ * and bounds_crossed flags are set based on the network_to_local and is_setid
+ * parameters.
+ *
* Return: NULL if the allocation fails. A pointer to the new allocated
* statistics structure if it success.
*/
-static struct brute_stats *brute_new_stats(void)
+static struct brute_stats *brute_new_stats(bool network_to_local, bool
is_setid)
{
struct brute_stats *stats;
+ const struct cred *cred = current_cred();
stats = kmalloc(sizeof(struct brute_stats), GFP_ATOMIC);
if (!stats)
@@ -93,6 +142,16 @@ static struct brute_stats *brute_new_stats(void)
stats->faults = 0;
stats->jiffies = get_jiffies_64();
stats->period = 0;
+ stats->saved_cred.uid = cred->uid;
+ stats->saved_cred.gid = cred->gid;
+ stats->saved_cred.suid = cred->suid;
+ stats->saved_cred.sgid = cred->sgid;
+ stats->saved_cred.euid = cred->euid;
+ stats->saved_cred.egid = cred->egid;
+ stats->saved_cred.fsuid = cred->fsuid;
+ stats->saved_cred.fsgid = cred->fsgid;
+ stats->network = netwo
Re: [PATCH] arm64: dts: imx8mn-beacon: Enable SDR104 on WiFi SDIO interface
On Sun, Feb 14, 2021 at 02:17:42PM -0600, Adam Ford wrote: > Enable 100Mhz and 200MHz pinmux and corrsesponding voltage supplies > to enable SDR104 on usdhc1 connecting the WiFi chip. > > Signed-off-by: Adam Ford Applied, thanks.
Re: [PATCH v2] clk: imx8mp: Remove the none exist pcie clocks
Copy Abel who is stepping up to maintain i.MX clock drivers.
Shawn
On Thu, Feb 18, 2021 at 04:33:46PM +0800, Richard Zhu wrote:
> In the i.MX8MP PCIe design, the PCIe PHY REF clock comes from external
> OSC or internal system PLL. It is configured in the IOMUX_GPR14 register
> directly, and can't be contolled by CCM at all.
> Remove the PCIE PHY clock from clock driver to clean up codes.
> There is only one PCIe in i.MX8MP, remove the none exist second PCIe
> related clocks.
> Remove the none exsits clocks IDs together.
>
> Signed-off-by: Richard Zhu
> Reviewed-by: Jason Liu
> ---
> drivers/clk/imx/clk-imx8mp.c | 15 ---
> include/dt-bindings/clock/imx8mp-clock.h | 3 ---
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> index 2f4e1d674e1c..afbeb6bf1909 100644
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -152,10 +152,6 @@ static const char * const imx8mp_can2_sels[] =
> {"osc_24m", "sys_pll2_200m", "sys
> "sys_pll1_160m",
> "sys_pll1_800m", "sys_pll3_out",
> "sys_pll2_250m",
> "audio_pll2_out", };
>
> -static const char * const imx8mp_pcie_phy_sels[] = {"osc_24m",
> "sys_pll2_100m", "sys_pll2_500m",
> - "clk_ext1", "clk_ext2",
> "clk_ext3",
> - "clk_ext4",
> "sys_pll1_400m", };
> -
> static const char * const imx8mp_pcie_aux_sels[] = {"osc_24m",
> "sys_pll2_200m", "sys_pll2_50m",
> "sys_pll3_out",
> "sys_pll2_100m", "sys_pll1_80m",
> "sys_pll1_160m",
> "sys_pll1_200m", };
> @@ -380,14 +376,6 @@ static const char * const imx8mp_memrepair_sels[] =
> {"osc_24m", "sys_pll2_100m",
> "sys_pll1_800m",
> "sys_pll2_1000m", "sys_pll3_out",
> "clk_ext3",
> "audio_pll2_out", };
>
> -static const char * const imx8mp_pcie2_ctrl_sels[] = {"osc_24m",
> "sys_pll2_250m", "sys_pll2_200m",
> - "sys_pll1_266m",
> "sys_pll1_800m", "sys_pll2_500m",
> - "sys_pll2_333m",
> "sys_pll3_out", };
> -
> -static const char * const imx8mp_pcie2_phy_sels[] = {"osc_24m",
> "sys_pll2_100m", "sys_pll2_500m",
> - "clk_ext1", "clk_ext2",
> "clk_ext3",
> - "clk_ext4",
> "sys_pll1_400m", };
> -
> static const char * const imx8mp_media_mipi_test_byte_sels[] = {"osc_24m",
> "sys_pll2_200m", "sys_pll2_50m",
> "sys_pll3_out",
> "sys_pll2_100m",
> "sys_pll1_80m",
> "sys_pll1_160m",
> @@ -585,7 +573,6 @@ static int imx8mp_clocks_probe(struct platform_device
> *pdev)
> hws[IMX8MP_CLK_VPU_G2] = imx8m_clk_hw_composite("vpu_g2",
> imx8mp_vpu_g2_sels, ccm_base + 0xa180);
> hws[IMX8MP_CLK_CAN1] = imx8m_clk_hw_composite("can1", imx8mp_can1_sels,
> ccm_base + 0xa200);
> hws[IMX8MP_CLK_CAN2] = imx8m_clk_hw_composite("can2", imx8mp_can2_sels,
> ccm_base + 0xa280);
> - hws[IMX8MP_CLK_PCIE_PHY] = imx8m_clk_hw_composite("pcie_phy",
> imx8mp_pcie_phy_sels, ccm_base + 0xa380);
> hws[IMX8MP_CLK_PCIE_AUX] = imx8m_clk_hw_composite("pcie_aux",
> imx8mp_pcie_aux_sels, ccm_base + 0xa400);
> hws[IMX8MP_CLK_I2C5] = imx8m_clk_hw_composite("i2c5", imx8mp_i2c5_sels,
> ccm_base + 0xa480);
> hws[IMX8MP_CLK_I2C6] = imx8m_clk_hw_composite("i2c6", imx8mp_i2c6_sels,
> ccm_base + 0xa500);
> @@ -643,8 +630,6 @@ static int imx8mp_clocks_probe(struct platform_device
> *pdev)
> hws[IMX8MP_CLK_MEDIA_CAM2_PIX] =
> imx8m_clk_hw_composite("media_cam2_pix", imx8mp_media_cam2_pix_sels, ccm_base
> + 0xbe80);
> hws[IMX8MP_CLK_MEDIA_LDB] = imx8m_clk_hw_composite("media_ldb",
> imx8mp_media_ldb_sels, ccm_base + 0xbf00);
> hws[IMX8MP_CLK_MEMREPAIR] =
> imx8m_clk_hw_composite_critical("mem_repair", imx8mp_memrepair_sels, ccm_base
> + 0xbf80);
> - hws[IMX8MP_CLK_PCIE2_CTRL] = imx8m_clk_hw_composite("pcie2_ctrl",
> imx8mp_pcie2_ctrl_sels, ccm_base + 0xc000);
> - hws[IMX8MP_CLK_PCIE2_PHY] = imx8m_clk_hw_composite("pcie2_phy",
> imx8mp_pcie2_phy_sels, ccm_base + 0xc080);
> hws[IMX8MP_CLK_MEDIA_MIPI_TEST_BYTE] =
> imx8m_clk_hw_composite("media_mipi_test_byte",
> imx8mp_media_mipi_test_byte_sels, ccm_base + 0xc100);
> hws[IMX8MP_CLK_ECSPI3] = imx8m_clk_hw_composite("ecspi3",
> imx8mp_ecspi3_sels, ccm_base + 0xc180);
> hws[IMX8MP_CLK_PDM] = imx8m_clk_hw_composite("pdm", imx8mp_pdm_sels,
> ccm_base + 0xc200);
> diff --git a/include/dt-bindings/cloc
Re: [PATCH] clk: imx8mq: Correct the pcie aux sels
+ Abel
On Thu, Feb 18, 2021 at 03:29:34PM +0800, Richard Zhu wrote:
> The sys2_pll_50m should be one of the clock sels of PCIE_AUX clock,
> Change the sys2_pll_500m to sys2_pll_50m.
>
> Signed-off-by: Richard Zhu
> ---
> drivers/clk/imx/clk-imx8mq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
> index 4dd4ae9d022b..93480d8858be 100644
> --- a/drivers/clk/imx/clk-imx8mq.c
> +++ b/drivers/clk/imx/clk-imx8mq.c
> @@ -118,7 +118,7 @@ static const char * const imx8mq_pcie1_ctrl_sels[] =
> {"osc_25m", "sys2_pll_250m"
> static const char * const imx8mq_pcie1_phy_sels[] = {"osc_25m",
> "sys2_pll_100m", "sys2_pll_500m", "clk_ext1", "clk_ext2",
> "clk_ext3", "clk_ext4", };
>
> -static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m",
> "sys2_pll_200m", "sys2_pll_500m", "sys3_pll_out",
> +static const char * const imx8mq_pcie1_aux_sels[] = {"osc_25m",
> "sys2_pll_200m", "sys2_pll_50m", "sys3_pll_out",
> "sys2_pll_100m", "sys1_pll_80m",
> "sys1_pll_160m", "sys1_pll_200m", };
>
> static const char * const imx8mq_dc_pixel_sels[] = {"osc_25m",
> "video_pll1_out", "audio_pll2_out", "audio_pll1_out", "sys1_pll_800m",
> "sys2_pll_1000m", "sys3_pll_out", "clk_ext4", };
> --
> 2.17.1
>
[PATCH 1/3] net: davicom: Fix regulator not turned off on failed probe
When the probe fails or requests to be defered, we must disable the
regulator that was previously enabled.
Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
Signed-off-by: Paul Cercueil
---
drivers/net/ethernet/davicom/dm9000.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c
b/drivers/net/ethernet/davicom/dm9000.c
index 3fdc70dab5c1..ae744826bb9e 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1449,7 +1449,7 @@ dm9000_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "failed to request reset gpio %d: %d\n",
reset_gpios, ret);
- return -ENODEV;
+ goto out_regulator_disable;
}
/* According to manual PWRST# Low Period Min 1ms */
@@ -1461,8 +1461,10 @@ dm9000_probe(struct platform_device *pdev)
if (!pdata) {
pdata = dm9000_parse_dt(&pdev->dev);
- if (IS_ERR(pdata))
- return PTR_ERR(pdata);
+ if (IS_ERR(pdata)) {
+ ret = PTR_ERR(pdata);
+ goto out_regulator_disable;
+ }
}
/* Init network device */
@@ -1703,6 +1705,10 @@ dm9000_probe(struct platform_device *pdev)
dm9000_release_board(pdev, db);
free_netdev(ndev);
+out_regulator_disable:
+ if (!IS_ERR(power))
+ regulator_disable(power);
+
return ret;
}
--
2.30.1
[PATCH 2/3] net: davicom: Fix regulator not turned off on driver removal
We must disable the regulator that was enabled in the probe function.
Fixes: 7994fe55a4a2 ("dm9000: Add regulator and reset support to dm9000")
Signed-off-by: Paul Cercueil
---
drivers/net/ethernet/davicom/dm9000.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c
b/drivers/net/ethernet/davicom/dm9000.c
index ae744826bb9e..a95e95ce9438 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -133,6 +133,8 @@ struct board_info {
u32 wake_state;
int ip_summed;
+
+ struct regulator *power_supply;
};
/* debug code */
@@ -1481,6 +1483,8 @@ dm9000_probe(struct platform_device *pdev)
db->dev = &pdev->dev;
db->ndev = ndev;
+ if (!IS_ERR(power))
+ db->power_supply = power;
spin_lock_init(&db->lock);
mutex_init(&db->addr_lock);
@@ -1766,10 +1770,13 @@ static int
dm9000_drv_remove(struct platform_device *pdev)
{
struct net_device *ndev = platform_get_drvdata(pdev);
+ struct board_info *dm = to_dm9000_board(ndev);
unregister_netdev(ndev);
- dm9000_release_board(pdev, netdev_priv(ndev));
+ dm9000_release_board(pdev, dm);
free_netdev(ndev); /* free device structure */
+ if (dm->power_supply)
+ regulator_disable(dm->power_supply);
dev_dbg(&pdev->dev, "released and freed device\n");
return 0;
--
2.30.1
[PATCH 3/3] net: davicom: Use platform_get_irq_optional()
The second IRQ line really is optional, so use
platform_get_irq_optional() to obtain it.
Signed-off-by: Paul Cercueil
---
drivers/net/ethernet/davicom/dm9000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/davicom/dm9000.c
b/drivers/net/ethernet/davicom/dm9000.c
index a95e95ce9438..252adfa5d837 100644
--- a/drivers/net/ethernet/davicom/dm9000.c
+++ b/drivers/net/ethernet/davicom/dm9000.c
@@ -1507,7 +1507,7 @@ dm9000_probe(struct platform_device *pdev)
goto out;
}
- db->irq_wake = platform_get_irq(pdev, 1);
+ db->irq_wake = platform_get_irq_optional(pdev, 1);
if (db->irq_wake >= 0) {
dev_dbg(db->dev, "wakeup irq %d\n", db->irq_wake);
--
2.30.1
[PATCH v6 5/8] security/brute: Mitigate a brute force attack
In order to mitigate a brute force attack all the offending tasks involved
in the attack must be killed. In other words, it is necessary to kill all
the tasks that share the fork and/or exec statistical data related to the
attack. Moreover, if the attack happens through the fork system call, the
processes that have the same group_leader that the current task (the task
that has crashed) must be avoided since they are in the path to be killed.
When the SIGKILL signal is sent to the offending tasks, the function
"brute_kill_offending_tasks" will be called in a recursive way from the
task_fatal_signal LSM hook due to a small crash period. So, to avoid kill
again the same tasks due to a recursive call of this function, it is
necessary to disable the attack detection for the involved hierarchies.
To disable the attack detection, set to zero the last crash timestamp and
avoid to compute the application crash period in this case.
Signed-off-by: John Wood
---
security/brute/brute.c | 141 ++---
1 file changed, 132 insertions(+), 9 deletions(-)
diff --git a/security/brute/brute.c b/security/brute/brute.c
index 38e5e050964a..36a3286a02dd 100644
--- a/security/brute/brute.c
+++ b/security/brute/brute.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,7 +65,7 @@ struct brute_cred {
* @lock: Lock to protect the brute_stats structure.
* @refc: Reference counter.
* @faults: Number of crashes.
- * @jiffies: Last crash timestamp.
+ * @jiffies: Last crash timestamp. If zero, the attack detection is disabled.
* @period: Crash period's moving average.
* @saved_cred: Saved credentials.
* @network: Network activity flag.
@@ -571,6 +572,125 @@ static inline void print_fork_attack_running(void)
pr_warn("Fork brute force attack detected [%s]\n", current->comm);
}
+/**
+ * brute_disabled() - Test if the brute force attack detection is disabled.
+ * @stats: Statistical data shared by all the fork hierarchy processes.
+ *
+ * The brute force attack detection enabling/disabling is based on the last
+ * crash timestamp. A zero timestamp indicates that this feature is disabled. A
+ * timestamp greater than zero indicates that the attack detection is enabled.
+ *
+ * The statistical data shared by all the fork hierarchy processes cannot be
+ * NULL.
+ *
+ * It's mandatory to disable interrupts before acquiring the brute_stats::lock
+ * since the task_free hook can be called from an IRQ context during the
+ * execution of the task_fatal_signal hook.
+ *
+ * Context: Must be called with interrupts disabled and brute_stats_ptr_lock
+ * held.
+ * Return: True if the brute force attack detection is disabled. False
+ * otherwise.
+ */
+static bool brute_disabled(struct brute_stats *stats)
+{
+ bool disabled;
+
+ spin_lock(&stats->lock);
+ disabled = !stats->jiffies;
+ spin_unlock(&stats->lock);
+
+ return disabled;
+}
+
+/**
+ * brute_disable() - Disable the brute force attack detection.
+ * @stats: Statistical data shared by all the fork hierarchy processes.
+ *
+ * To disable the brute force attack detection it is only necessary to set the
+ * last crash timestamp to zero. A zero timestamp indicates that this feature
is
+ * disabled. A timestamp greater than zero indicates that the attack detection
+ * is enabled.
+ *
+ * The statistical data shared by all the fork hierarchy processes cannot be
+ * NULL.
+ *
+ * Context: Must be called with interrupts disabled and brute_stats_ptr_lock
+ * and brute_stats::lock held.
+ */
+static inline void brute_disable(struct brute_stats *stats)
+{
+ stats->jiffies = 0;
+}
+
+/**
+ * enum brute_attack_type - Brute force attack type.
+ * @BRUTE_ATTACK_TYPE_FORK: Attack that happens through the fork system call.
+ * @BRUTE_ATTACK_TYPE_EXEC: Attack that happens through the execve system call.
+ */
+enum brute_attack_type {
+ BRUTE_ATTACK_TYPE_FORK,
+ BRUTE_ATTACK_TYPE_EXEC,
+};
+
+/**
+ * brute_kill_offending_tasks() - Kill the offending tasks.
+ * @attack_type: Brute force attack type.
+ * @stats: Statistical data shared by all the fork hierarchy processes.
+ *
+ * When a brute force attack is detected all the offending tasks involved in
the
+ * attack must be killed. In other words, it is necessary to kill all the tasks
+ * that share the same statistical data. Moreover, if the attack happens
through
+ * the fork system call, the processes that have the same group_leader that the
+ * current task must be avoided since they are in the path to be killed.
+ *
+ * When the SIGKILL signal is sent to the offending tasks, this function will
be
+ * called again from the task_fatal_signal hook due to a small crash period.
So,
+ * to avoid kill again the same tasks due to a recursive call of this function,
+ * it is necessary to disable the attack detection for this fork hierarchy.
+ *
+ * The statistical data shared by all t
