[PATCH] drm/amd/display: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c:270:16-21: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c index 17e84f3..449fcd4 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c @@ -266,8 +266,7 @@ static bool dmub_psr_copy_settings(struct dmub_psr *dmub, copy_settings_data->frame_cap_ind = psr_context->psrFrameCaptureIndicationReq; copy_settings_data->init_sdp_deadline = psr_context->sdpTransmitLineNumDeadline; copy_settings_data->debug.u32All = 0; - copy_settings_data->debug.bitfields.visual_confirm = dc->dc->debug.visual_confirm == VISUAL_CONFIRM_PSR ? - true : false; + copy_settings_data->debug.bitfields.visual_confirm = dc->dc->debug.visual_confirm == VISUAL_CONFIRM_PSR; copy_settings_data->debug.bitfields.use_hw_lock_mgr = 1; dc_dmub_srv_cmd_queue(dc->dmub_srv, &cmd); -- 1.8.3.1
[PATCH] drm/amd/display/dc/core/dc_link_ddc: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:544:34-39: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c index c5936e0..45a59cf 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c @@ -541,7 +541,7 @@ bool dal_ddc_service_query_ddc_data( /* should not set mot (middle of transaction) to 0 * if there are pending read payloads */ - payload.mot = read_size == 0 ? false : true; + payload.mot = !(read_size == 0); payload.length = write_size; payload.data = write_buf; -- 1.8.3.1
Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform
On Sat, Feb 20, 2021 at 05:32:30PM +1100, Finn Thain wrote: > Nope. Interrupt priority masking is there to place an upper bound > interrupt latency. That's why this feature is shipping in contemporary > hardware (e.g. ARM GIC). If you care about real time workloads on arm64, > that may interest you. I don't know if it's still true today, but in the past there was a very noticeable difference in timer stability between the 68k macintosh models with the timer interrupt at IPL 1 as compared to the models where the timer interrupt was at IPL 6. The ability to preempt the other interrupt handlers made the difference between a usable clock and one that was pretty unreliable. Brad Boyer f...@allandria.com
WARNING in netlbl_cipsov4_add
Hello, syzbot found the following issue on: HEAD commit:4773acf3 b43: N-PHY: Fix the update of coef for the PHY re.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=13290cb0d0 kernel config: https://syzkaller.appspot.com/x/.config?x=8cb23303ddb9411f dashboard link: https://syzkaller.appspot.com/bug?extid=cdd51ee2e6b0b2e18c0d syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1267953cd0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10d98524d0 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1127cc82d0 final oops: https://syzkaller.appspot.com/x/report.txt?x=1327cc82d0 console output: https://syzkaller.appspot.com/x/log.txt?x=1527cc82d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+cdd51ee2e6b0b2e18...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 8425 at mm/page_alloc.c:4979 __alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:5014 Modules linked in: CPU: 0 PID: 8425 Comm: syz-executor629 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__alloc_pages_nodemask+0x5f8/0x730 mm/page_alloc.c:4979 Code: 00 00 0c 00 0f 85 a7 00 00 00 8b 3c 24 4c 89 f2 44 89 e6 c6 44 24 70 00 48 89 6c 24 58 e8 d0 d7 ff ff 49 89 c5 e9 ea fc ff ff <0f> 0b e9 b5 fd ff ff 89 74 24 14 4c 89 4c 24 08 4c 89 74 24 18 e8 RSP: 0018:c900017ef3e0 EFLAGS: 00010246 RAX: RBX: 1920002fde80 RCX: RDX: RSI: dc00 RDI: 00040dc0 RBP: 00040dc0 R08: R09: R10: 81b29ac1 R11: R12: 0015 R13: 0015 R14: R15: 88801209c980 FS: 01c35300() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fbf6f3656c0 CR3: 1db9e000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: alloc_pages_current+0x18c/0x2a0 mm/mempolicy.c:2267 alloc_pages include/linux/gfp.h:547 [inline] kmalloc_order+0x32/0xd0 mm/slab_common.c:837 kmalloc_order_trace+0x14/0x130 mm/slab_common.c:853 kmalloc_array include/linux/slab.h:592 [inline] kcalloc include/linux/slab.h:621 [inline] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:188 [inline] netlbl_cipsov4_add+0x5a9/0x23e0 net/netlabel/netlabel_cipso_v4.c:416 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2345 ___sys_sendmsg+0xf3/0x170 net/socket.c:2399 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x43fcc9 Code: 28 c3 e8 5a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ffdcdd33c48 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 004004a0 RCX: 0043fcc9 RDX: 4904 RSI: 2140 RDI: 0003 RBP: 00403730 R08: 0005 R09: 004004a0 R10: 0003 R11: 0246 R12: 004037c0 R13: R14: 004ad018 R15: 004004a0 --- 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. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: 5.10 LTS Kernel: 2 or 6 years?
On 2021/2/19 17:08, Greg Kroah-Hartman wrote: On Fri, Feb 19, 2021 at 04:54:24PM +0800, Hanjun Guo wrote: Hi Greg, On 2021/1/26 15:29, Greg Kroah-Hartman wrote: [...] I want to see companies _using_ the kernel, and most importantly, _updating_ their devices with it, to know if it is worth to keep around for longer than 2 years. I also, hopefully, want to see how those companies will help me out in the testing and maintenance of that kernel version in order to make supporting it for 6 years actually possible. So, are you planning on using 5.10? Will you will be willing to help out in testing the -rc releases I make to let me know if there are any problems, and to help in pointing out and backporting any specific patches that your platforms need for that kernel release? We(Huawei) are willing to commit resources to help out in testing the stable -rc releases, and to help to backport patches for stable kernels. Wonderful! 5.10 stable kernel will be used for openEuler [1] kernel and also inside Huawei. From customer's feedback, it's very important to see the stable kernel we used to be maintained for 6 years in the community, and we will use 5.10 kernel for at least 6 years, so we are willing to help you and help ourselves :) In specific, we will start from the testing work, using HULK robot (reports lots of bugs to mainline kernel) testing framework to test compile, reboot, functional testing, and will extend to basic performance regression testing in the future. Great! Do you all need an email notification when the -rc releases come out for the stable trees, or can you trigger off of the -rc stable git tree? Different CI systems work in different ways :) We can trigger the test when you updated the -rc stable git tree, by monitoring new commits for the stable branches. So if you push all the commits at once for -rc stable branches, then our CI system can work well. And if you can reply to the -rc release emails with a "Tested-by:" tag, I will be glad to add that to the release commit when that happens to show that you all have tested the release. Thanks, will reply "Tested-by:" with -rc releases. We are working on setting up the test farm and will report the test results in a week. And we will start from ARM64 and X86 architecture first, and then extend to other platforms. That's a good start, the useful ones :) For patch backporting, will send the bugfix patches (from mainline) we spotted, but I think this work may not doing in regular but will be triggered as needed. That's fine, it is not something that happens at a regular interval. Does this sound good to you? Yes it does, thank you so much. greg k-h Thanks Hanjun
Re: [PATCH] Staging: rtl8192e: fix kconfig dependency on CRYPTO
On Fri, Feb 19, 2021 at 06:14:57PM -0500, Julian Braha wrote: > commit 1a3f343027d7f5a6475a019aa20be89795b8c8e0 > Author: Julian Braha > Date: Fri Feb 19 17:02:24 2021 -0500 > > staging: rtl8192e: fix kconfig dependency on CRYPTO > > When RTLLIB_CRYPTO_TKIP is enabled and CRYPTO is disabled, > Kbuild gives the following warning: > > WARNING: unmet direct dependencies detected for CRYPTO_MICHAEL_MIC > Depends on [n]: CRYPTO [=n] > Selected by [m]: > - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] > > WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4 > Depends on [n]: CRYPTO [=n] > Selected by [m]: > - RTLLIB_CRYPTO_TKIP [=m] && STAGING [=y] && RTLLIB [=m] > - RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m] > > This is because RTLLIB_CRYPTO_TKIP selects CRYPTO_MICHAEL_MIC and > CRYPTO_LIB_ARC4, > without depending on or selecting CRYPTO, despite those config options > being subordinate to CRYPTO. > > Signed-off-by: Julian Braha > > diff --git a/drivers/staging/rtl8192e/Kconfig > b/drivers/staging/rtl8192e/Kconfig > index 03fcc23516fd..6e7d84ac06f5 100644 > --- a/drivers/staging/rtl8192e/Kconfig > +++ b/drivers/staging/rtl8192e/Kconfig > @@ -26,6 +26,7 @@ config RTLLIB_CRYPTO_CCMP > config RTLLIB_CRYPTO_TKIP > tristate "Support for rtllib TKIP crypto" > depends on RTLLIB > + select CRYPTO > select CRYPTO_LIB_ARC4 > select CRYPTO_MICHAEL_MIC > default y Odd indentation :(
[PATCH 1/1] net: fec: ptp: avoid register access when ipg clock is disabled
When accessing the timecounter register on an i.MX8MQ the kernel hangs. This is only the case when the interface is down. This can be reproduced by reading with 'phc_ctrl eth0 get'. Like described in the change in 91c0d987a9788dcc5fe26baafd73bf9242b68900 the igp clock is disabled when the interface is down and leads to a system hang. So we check if the ptp clock status before reading the timecounter register. Signed-off-by: Heiko Thiery --- drivers/net/ethernet/freescale/fec_ptp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c index 2e344aada4c6..c9882083da02 100644 --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -377,6 +377,9 @@ static int fec_ptp_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts) u64 ns; unsigned long flags; + /* Check the ptp clock */ + if (!adapter->ptp_clk_on) + return -EINVAL; spin_lock_irqsave(&adapter->tmreg_lock, flags); ns = timecounter_read(&adapter->tc); spin_unlock_irqrestore(&adapter->tmreg_lock, flags); -- 2.30.0
Re: [PATCH 3/3] media: mtk-vcodec: Separating mtk encoder driver
On Wed, 2021-02-03 at 19:44 +0900, Alexandre Courbot wrote:
> Hi Irui,
>
> Thanks for pushing this forward. I had two small conflicts when
> applying this patch to the media tree, so you may want to rebase
> before sending the next version. Please see the comments inline.
>
> On Thu, Jan 21, 2021 at 3:18 PM Irui Wang wrote:
> >
> > MTK H264 Encoder(VENC_SYS) and VP8 Encoder(VENC_LT_SYS) are two
> > independent hardware instance. They have their owner interrupt,
> > register mapping, and special clocks.
> >
> > This patch seperates them into two drivers:
>
> seperates -> separates
>
> Also the patch does not result in two drivers, but two devices.
>
> > User Call "VIDIOC_QUERYCAP":
> > H264 Encoder return driver name "mtk-vcodec-enc";
> > VP8 Encoder return driver name "mtk-venc-vp8.
>
> I wonder if we need to use two different names? The driver is the
> same, so it makes sense to me that both devices return
> "mtk-vcodec-enc". Userspace can then list the formats on the CAPTURE
> queue in order to query the supported codecs.
>
I'm afraid we can't, there is a symlink when chrome use the
encoder(50-media.rules):
ATTR{name} == "mtk-vcodec-enc", SYMLINK+="video-enc"
ATTR{name} == "mtk-venc-vp8", SYMLINK+="video-enc0"
if we use the same name,how userspace access the encoder? maybe there
will be some modifications are needed in VEA(for example)?
> >
> > Signed-off-by: Hsin-Yi Wang
> > Signed-off-by: Maoguang Meng
> > Signed-off-by: Irui Wang
> >
> > ---
> > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 10 +-
> > .../platform/mtk-vcodec/mtk_vcodec_enc.c | 23 +++-
> > .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 121 +++---
> > .../platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 40 +-
> > .../platform/mtk-vcodec/venc/venc_vp8_if.c| 4 +-
> > 5 files changed, 82 insertions(+), 116 deletions(-)
> >
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > index 3dd010cba23e..1594edcc706d 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> > @@ -19,6 +19,7 @@
> > #define MTK_VCODEC_DRV_NAME"mtk_vcodec_drv"
> > #define MTK_VCODEC_DEC_NAME"mtk-vcodec-dec"
> > #define MTK_VCODEC_ENC_NAME"mtk-vcodec-enc"
> > +#define MTK_VENC_VP8_NAME "mtk-venc-vp8"
> > #define MTK_PLATFORM_STR "platform:mt8173"
> >
> > #define MTK_VCODEC_MAX_PLANES 3
> > @@ -193,7 +194,6 @@ struct mtk_vcodec_pm {
> >
> > struct mtk_vcodec_clk venc_clk;
> > struct device *larbvenc;
> > - struct device *larbvenclt;
> > struct device *dev;
> > struct mtk_vcodec_dev *mtkdev;
> > };
> > @@ -311,25 +311,27 @@ enum mtk_chip {
> > * @chip: chip this encoder is compatible with
> > *
> > * @uses_ext: whether the encoder uses the extended firmware messaging
> > format
> > - * @has_lt_irq: whether the encoder uses the LT irq
> > + * @name: whether the encoder core is vp8
> > * @min_birate: minimum supported encoding bitrate
> > * @max_bitrate: maximum supported encoding bitrate
> > * @capture_formats: array of supported capture formats
> > * @num_capture_formats: number of entries in capture_formats
> > * @output_formats: array of supported output formats
> > * @num_output_formats: number of entries in output_formats
> > + * @core_id: stand for h264 or vp8 encode index
> > */
> > struct mtk_vcodec_enc_pdata {
> > enum mtk_chip chip;
> >
> > bool uses_ext;
> > - bool has_lt_irq;
> > + const char *name;
>
> This new member can be removed if we use the same name for both devices.
>
> > unsigned long min_bitrate;
> > unsigned long max_bitrate;
> > const struct mtk_video_fmt *capture_formats;
> > size_t num_capture_formats;
> > const struct mtk_video_fmt *output_formats;
> > size_t num_output_formats;
> > + int core_id;
> > };
> >
> > #define MTK_ENC_CTX_IS_EXT(ctx) ((ctx)->dev->venc_pdata->uses_ext)
> > @@ -361,7 +363,6 @@ struct mtk_vcodec_enc_pdata {
> > *
> > * @dec_irq: decoder irq resource
> > * @enc_irq: h264 encoder irq resource
> > - * @enc_lt_irq: vp8 encoder irq resource
> > *
> > * @dec_mutex: decoder hardware lock
> > * @enc_mutex: encoder hardware lock.
> > @@ -397,7 +398,6 @@ struct mtk_vcodec_dev {
> >
> > int dec_irq;
> > int enc_irq;
> > - int enc_lt_irq;
> >
> > struct mutex dec_mutex;
> > struct mutex enc_mutex;
> > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > index 21de1431cfcb..0da6871b4b39 100644
> > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> > @@ -9,6 +9,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "mtk_vcodec_drv.h"
> > #includ
Re: [RESEND PATCH v6 3/3] extcon: qcom-spmi: Add support for VBUS detection
Hi,
Please use get_maintainer.pl script when you send the patches.
I didn't receive the patches. I'll review.
Thanks,
Chanwoo Choi
On 21. 1. 26. 오전 9:38, Guru Das Srinagesh wrote:
From: Anirudh Ghayal
VBUS can be detected via a dedicated PMIC pin. Add support
for reporting the VBUS status.
Signed-off-by: Anirudh Ghayal
Signed-off-by: Kavya Nunna
Signed-off-by: Guru Das Srinagesh
---
drivers/extcon/extcon-qcom-spmi-misc.c | 99 +++---
1 file changed, 80 insertions(+), 19 deletions(-)
diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c
b/drivers/extcon/extcon-qcom-spmi-misc.c
index 6b836ae..9e8ccfb 100644
--- a/drivers/extcon/extcon-qcom-spmi-misc.c
+++ b/drivers/extcon/extcon-qcom-spmi-misc.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
/**
* extcon-qcom-spmi-misc.c - Qualcomm USB extcon driver to support USB ID
- * detection based on extcon-usb-gpio.c.
+ * and VBUS detection based on extcon-usb-gpio.c.
*
* Copyright (C) 2016 Linaro, Ltd.
* Stephen Boyd
@@ -21,30 +21,56 @@
struct qcom_usb_extcon_info {
struct extcon_dev *edev;
- int irq;
+ int id_irq;
+ int vbus_irq;
struct delayed_work wq_detcable;
unsigned long debounce_jiffies;
};
static const unsigned int qcom_usb_extcon_cable[] = {
+ EXTCON_USB,
EXTCON_USB_HOST,
EXTCON_NONE,
};
static void qcom_usb_extcon_detect_cable(struct work_struct *work)
{
- bool id;
+ bool state = false;
int ret;
+ union extcon_property_value val;
struct qcom_usb_extcon_info *info = container_of(to_delayed_work(work),
struct qcom_usb_extcon_info,
wq_detcable);
- /* check ID and update cable state */
- ret = irq_get_irqchip_state(info->irq, IRQCHIP_STATE_LINE_LEVEL, &id);
- if (ret)
- return;
+ if (info->id_irq > 0) {
+ /* check ID and update cable state */
+ ret = irq_get_irqchip_state(info->id_irq,
+ IRQCHIP_STATE_LINE_LEVEL, &state);
+ if (ret)
+ return;
+
+ if (!state) {
+ val.intval = true;
+ extcon_set_property(info->edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_SS, val);
+ }
+ extcon_set_state_sync(info->edev, EXTCON_USB_HOST, !state);
+ }
- extcon_set_state_sync(info->edev, EXTCON_USB_HOST, !id);
+ if (info->vbus_irq > 0) {
+ /* check VBUS and update cable state */
+ ret = irq_get_irqchip_state(info->vbus_irq,
+ IRQCHIP_STATE_LINE_LEVEL, &state);
+ if (ret)
+ return;
+
+ if (state) {
+ val.intval = true;
+ extcon_set_property(info->edev, EXTCON_USB,
+ EXTCON_PROP_USB_SS, val);
+ }
+ extcon_set_state_sync(info->edev, EXTCON_USB, state);
+ }
}
static irqreturn_t qcom_usb_irq_handler(int irq, void *dev_id)
@@ -79,21 +105,48 @@ static int qcom_usb_extcon_probe(struct platform_device
*pdev)
return ret;
}
+ ret = extcon_set_property_capability(info->edev,
+ EXTCON_USB, EXTCON_PROP_USB_SS);
+ ret |= extcon_set_property_capability(info->edev,
+ EXTCON_USB_HOST, EXTCON_PROP_USB_SS);
+ if (ret) {
+ dev_err(dev, "failed to register extcon props rc=%d\n",
+ ret);
+ return ret;
+ }
+
info->debounce_jiffies = msecs_to_jiffies(USB_ID_DEBOUNCE_MS);
INIT_DELAYED_WORK(&info->wq_detcable, qcom_usb_extcon_detect_cable);
- info->irq = platform_get_irq_byname(pdev, "usb_id");
- if (info->irq < 0)
- return info->irq;
+ info->id_irq = platform_get_irq_byname(pdev, "usb_id");
+ if (info->id_irq > 0) {
+ ret = devm_request_threaded_irq(dev, info->id_irq, NULL,
+ qcom_usb_irq_handler,
+ IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ pdev->name, info);
+ if (ret < 0) {
+ dev_err(dev, "failed to request handler for ID IRQ\n");
+ return ret;
+ }
+ }
- ret = devm_request_threaded_irq(dev, info->irq, NULL,
+ info->vbus_irq = platform_get_irq_byname(pdev, "usb_vbus");
+ if (info->vbus_irq > 0) {
+ ret = devm_request_threaded_irq(dev, info->vbus_irq, NULL,
Re: [PATCH 1/3] dt-bindings: media: mtk-vcodec: Separating mtk vcodec encoder node
On Tue, 2021-02-09 at 09:53 -0600, Rob Herring wrote:
> On Thu, Jan 21, 2021 at 02:18:02PM +0800, Irui Wang wrote:
> > Updates binding document since the avc and vp8 hardware encoder in
> > MT8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to
> > "mediatek,mt8173-vcodec-vp8-enc" and "mediatek,mt8173-vcodec-avc-enc".
>
> This is not a compatible change. You need to detail that and why that's
> okay (assuming it is).
>
this patch separates the two devices, it's a preparing patch for adding
device_link between the larbs and venc-device. It's mainly for fixing
the problem:
https://lkml.org/lkml/2019/9/3/316
> >
> > Signed-off-by: Hsin-Yi Wang
> > Signed-off-by: Maoguang Meng
> > Signed-off-by: Irui Wang
> >
> > ---
> > .../bindings/media/mediatek-vcodec.txt| 58 ++-
> > 1 file changed, 31 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > index 8217424fd4bd..f85276e629bf 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > @@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in
> > Mediatek SoCs which
> > supports high resolution encoding and decoding functionalities.
> >
> > Required properties:
> > -- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
> > +- compatible : must be one of the following string:
> > + "mediatek,mt8173-vcodec-vp8-enc" for mt8173 vp8 encoder.
> > + "mediatek,mt8173-vcodec-avc-enc" for mt8173 avc encoder.
> >"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
> >"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
> > - reg : Physical base address of the video codec registers and length of
> > @@ -13,10 +15,11 @@ Required properties:
> > - mediatek,larb : must contain the local arbiters in the current Socs.
> > - clocks : list of clock specifiers, corresponding to entries in
> >the clock-names property.
> > -- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
> > - "venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
> > - "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
> > - "venc_lt_sel", "vdec_bus_clk_src".
> > +- clock-names:
> > + avc venc must contain "venc_sel";
> > + vp8 venc must contain "venc_lt_sel";
> > + decoder must contain "vcodecpll", "univpll_d2", "clk_cci400_sel",
> > + "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", "vdec_bus_clk_src".
> > - iommus : should point to the respective IOMMU block with master port as
> >argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >for details.
> > @@ -80,14 +83,10 @@ vcodec_dec: vcodec@1600 {
> > assigned-clock-rates = <0>, <0>, <0>, <148200>, <8>;
> >};
> >
> > - vcodec_enc: vcodec@18002000 {
> > -compatible = "mediatek,mt8173-vcodec-enc";
> > -reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
> > - <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
> > -interrupts = ,
> > -;
> > -mediatek,larb = <&larb3>,
> > - <&larb5>;
> > +vcodec_enc: vcodec@18002000 {
> > +compatible = "mediatek,mt8173-vcodec-avc-enc";
> > +reg = <0 0x18002000 0 0x1000>;
> > +interrupts = ;
> > iommus = <&iommu M4U_PORT_VENC_RCPU>,
> > <&iommu M4U_PORT_VENC_REC>,
> > <&iommu M4U_PORT_VENC_BSDMA>,
> > @@ -98,8 +97,20 @@ vcodec_dec: vcodec@1600 {
> > <&iommu M4U_PORT_VENC_REF_LUMA>,
> > <&iommu M4U_PORT_VENC_REF_CHROMA>,
> > <&iommu M4U_PORT_VENC_NBM_RDMA>,
> > - <&iommu M4U_PORT_VENC_NBM_WDMA>,
> > - <&iommu M4U_PORT_VENC_RCPU_SET2>,
> > + <&iommu M4U_PORT_VENC_NBM_WDMA>;
> > +mediatek,larb = <&larb3>;
> > +mediatek,vpu = <&vpu>;
> > +clocks = <&topckgen CLK_TOP_VENC_SEL>;
> > +clock-names = "venc_sel";
> > +assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
> > +assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
> > + };
> > +
> > +vcodec_enc_lt: vcodec@19002000 {
> > +compatible = "mediatek,mt8173-vcodec-vp8-enc";
> > +reg = <0 0x19002000 0 0x1000>;/* VENC_LT_SYS */
> > +interrupts = ;
> > +iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
> > <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> > <&iommu M4U_PORT_VENC_BSDMA_SET2>,
> > <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
> > @@ -108,17 +119,10 @@ vcodec_dec: vcodec@1600 {
> > <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
> > <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
> > <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
> > +mediatek,larb = <&larb5>;
> > mediatek,vpu = <&vpu>;
> > -clocks = <&topckgen CLK_TOP_VENCPLL_D2>,
> > - <&topckgen CLK_TOP_VENC_SEL>,
> > - <&topckgen CLK
Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform
On Thu, 18 Feb 2021, Arnd Bergmann wrote: > On Thu, Feb 18, 2021 at 6:30 AM Finn Thain wrote: > > On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > > > > > That scenario seems a little contrived to me (drivers for two or > > > > more devices sharing state through their interrupt handlers). Is > > > > it real? I suppose every platform has its quirks. The irq lock in > > > > sonic_interrupt() is only there because of a platform quirk (the > > > > same device can trigger either of two IRQs). Anyway, no-one > > > > expects all drivers to work on all platforms; I don't know why it > > > > bothers you so much when platforms differ. > > > > > > Basically, we wrote drivers with the assumption that this driver > > > will be cross-platform. (Of course there are some drivers which can > > > only work on one platform, for example, if the IP of the device is > > > only used in one platform as an internal component of a specific > > > SoC.) > > > > > > So once a device has two or more interrupts, we need to consider one > > > interrupt might preempt another one on m68k on the same cpu if we > > > also want to support this driver on m68k. this usually doesn't > > > matter on other platforms. > > > > When users show up who desire to run your drivers on their platform, > > you can expect them to bring patches and a MAINTAINERS file entry. > > AFAIK, Linux development has always worked that way. > > This is only part of the picture though. We also also constantly trying > to generalize the internal interfaces, to make sure that platforms work > the same way and that it's possible to write drivers in a portable way > without having to rely on platform maintainers to point out the > differences. > > I think it would make a lot of sense to remove the architecture > differences here by making m68k work the same way as the others and > documenting that as the expected behavior. > If you had some great new feature that was incompatible with priority masking, or incompatible with existing drivers portable enough to support such features, then I would be more amenable to your plan to remove functionality. But there's no real justification here. You say platform maintainers should not have to "point out the differences". But is that not their job? > You are probably right that there are no specific bugs on m68k machines > that rely on the nested hardirqs today, but I think they only get away > with it because > > a) there is no SMP support on m68k, so it likely doesn't run into the >more subtle cases with lock ordering that you could get when you have >hardirq handlers on multiple CPUs in parallel > And that's relevant because SMP support is now mandatory? Is this the logical consequence of your intention to "remove the architecture differences"? > b) there is a very limited number of device drivers that are actually >used on m68k, in particular only M54xx has PCI support, but that in >turn has a different interrupt scheme. > Everyone is afraid of some mysterious bug somewhere, yet no one can point to it. Again, I submit that the bug doesn't exist. That's because there is no material difference in semantics between the irqs_disabled() implementation that says "all interrupts are disabled except for NMI (and some others that some ARM platform cares about)" and the implementation that says "interrupts are disabled except higher priority ones than you may be enabled". If you can point to code that cares about such semantics, I predict you've found either a coding anti-pattern or perhaps some obscure hardware design flaw. Either way, there is no justification for your plan. > Changing the behavior on m68k clearly has its own regression risk, but > it could be done as a configuration option that defaults to the > traditional behavior on machines that have not been verified to be > well-behaved without nested hardirqs, and hidden on machines that do not > need it (any more). > This plan will quantifiably increase interrupt latency. It's not some vague risk that you can hand-wave away. It's unavoidable. > As far as I can tell, the only reason you would actually need nested > hardirqs is when a low-priority interrupt has to perform expensive I/O > processing, but we've had countless other methods to do the same over > the years (at least bottom half, softirq, taskqueue, tasklet, keventd, > workqueue, kthread, threaded interrupt handlers and probably others). > Nope. Interrupt priority masking is there to place an upper bound interrupt latency. That's why this feature is shipping in contemporary hardware (e.g. ARM GIC). If you care about real time workloads on arm64, that may interest you. If you don't care about arm hardware or real time workloads, that's fine too, but here's the rub. Song Bao Hua's plan involves reworking the locking in existing drivers (which may be portable
[BUG] checkpatch: false positive unwrapped commit description
The next line leads to a false positive
Possible unwrapped commit description
(prefer a maximum 75 chars per line)
element type is ‘struct reg_info‘, not ‘u32‘ {aka ‘unsigned int‘}
+|+|+|+|+|+|+|
10203040506070
Unicode code point 0x2018 (‘) is counted as three characters
instead of one.
This code point is used in the GCC 11 warning sizeof-array-div.
Citing the warning verbatim lead to the observation.
Signed-off-by: Heinrich Schuchardt
---
foo.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo.txt
diff --git a/foo.txt b/foo.txt
new file mode 100644
index ..e69de29bb2d1
--
2.30.0
Re: [RFC] scripts: kernel-doc: fix array element capture in pointer-to-func parsing
On Wed, Feb 17, 2021 at 3:56 PM Aditya Srivastava wrote: > > Currently, kernel-doc causes an unexpected error when array element (i.e., > "type (*foo[bar])(args)") is present as pointer parameter in > pointer-to-function parsing. > > For e.g., running kernel-doc -none on kernel/gcov/gcc_4_7.c causes this > error: > "Use of uninitialized value $param in regexp compilation at ...", in > combination with: > "warning: Function parameter or member '' not described in 'gcov_info'" > > Here, the parameter parsing does not take into account the presence of > array element (i.e. square brackets) in $param. > > Provide a simple fix by adding square brackets in the regex, responsible > for capturing $param. > > A quick evaluation, by running 'kernel-doc -none' on entire kernel-tree, > reveals that no additional warning or error has been added or removed by > the fix. > > Suggested-by: Lukas Bulwahn > Signed-off-by: Aditya Srivastava > --- > * Applies perfectly over next-20210217 > Aditya, Jonathan, I have tested this change with: git ls-files | xargs ./scripts/kernel-doc -none 2>&1 | tee kernel-doc-output Applied the patch, and re-ran that command and compared the diff. First, I observed that ./scripts/kernel-doc is not fully deterministic on my machine, although I could not really pinpoint it to the exact reason where that comes in. Secondly, more importantly, the relevant diff affected by this patch is: < Use of uninitialized value $param in regexp compilation at ./scripts/kernel-doc line 1559, line 308. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 308. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 308. < Use of uninitialized value $param in substitution (s///) at ./scripts/kernel-doc line 1617, line 308. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1651, line 308. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1651, line 308. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1652, line 308. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1654, line 308. < Use of uninitialized value $param in concatenation (.) or string at ./scripts/kernel-doc line 1655, line 308. < drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.h:308: warning: Function parameter or member '' not described in 'brcmf_fweh_info' < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1672, line 308. < Use of uninitialized value $param in regexp compilation at ./scripts/kernel-doc line 1559, line 96. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 96. < Use of uninitialized value $actual in substitution (s///) at ./scripts/kernel-doc line 1523, line 96. < Use of uninitialized value $param in substitution (s///) at ./scripts/kernel-doc line 1617, line 96. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1651, line 96. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1651, line 96. < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1652, line 96. < Use of uninitialized value $param in pattern match (m//) at ./scripts/kernel-doc line 1654, line 96. < Use of uninitialized value $param in concatenation (.) or string at ./scripts/kernel-doc line 1655, line 96. < kernel/gcov/gcc_4_7.c:96: warning: Function parameter or member '' not described in 'gcov_info' < Use of uninitialized value $param in hash element at ./scripts/kernel-doc line 1672, line 96. So, I can confirm that the mentioned issue is really resolved with this patch, and that deserves a tag: Tested-by: Lukas Bulwahn Thanks, Aditya. When can we expect the next patch for ./scripts/kernel-doc? Looking forward to running the next test :) Lukas
Re: [PATCH 1/3] dt-bindings: media: mtk-vcodec: Separating mtk vcodec encoder node
On Wed, 2021-02-03 at 19:44 +0900, Alexandre Courbot wrote:
> On Thu, Jan 21, 2021 at 3:18 PM Irui Wang wrote:
> >
> > Updates binding document since the avc and vp8 hardware encoder in
> > MT8173 are now separated. Separate "mediatek,mt8173-vcodec-enc" to
> > "mediatek,mt8173-vcodec-vp8-enc" and "mediatek,mt8173-vcodec-avc-enc".
> >
> > Signed-off-by: Hsin-Yi Wang
> > Signed-off-by: Maoguang Meng
> > Signed-off-by: Irui Wang
> >
> > ---
> > .../bindings/media/mediatek-vcodec.txt| 58 ++-
> > 1 file changed, 31 insertions(+), 27 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > index 8217424fd4bd..f85276e629bf 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
> > @@ -4,7 +4,9 @@ Mediatek Video Codec is the video codec hw present in
> > Mediatek SoCs which
> > supports high resolution encoding and decoding functionalities.
> >
> > Required properties:
> > -- compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
> > +- compatible : must be one of the following string:
> > + "mediatek,mt8173-vcodec-vp8-enc" for mt8173 vp8 encoder.
> > + "mediatek,mt8173-vcodec-avc-enc" for mt8173 avc encoder.
>
> IMHO "mediatek,mt8173-vcodec-enc-vp8" and
> "mediatek,mt8173-vcodec-enc-avc" would be more logical. Also to keep a
> bit of backward compatibility, shall we also allow
> "mediatek,mt8173-vcodec-enc" to be an alias for
> "mediatek,mt8173-vcodec-enc-avc"? The line above would become
>
> "mediatek,mt8173-vcodec-enc-avc" or "mediatek,mt8173-vcodec-enc" for
> mt8173 avc encoder.
>
will be updated in the next version.
> >"mediatek,mt8183-vcodec-enc" for MT8183 encoder.
> >"mediatek,mt8173-vcodec-dec" for MT8173 decoder.
> > - reg : Physical base address of the video codec registers and length of
> > @@ -13,10 +15,11 @@ Required properties:
> > - mediatek,larb : must contain the local arbiters in the current Socs.
> > - clocks : list of clock specifiers, corresponding to entries in
> >the clock-names property.
> > -- clock-names: encoder must contain "venc_sel_src", "venc_sel",,
> > - "venc_lt_sel_src", "venc_lt_sel", decoder must contain "vcodecpll",
> > - "univpll_d2", "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll",
> > - "venc_lt_sel", "vdec_bus_clk_src".
> > +- clock-names:
> > + avc venc must contain "venc_sel";
> > + vp8 venc must contain "venc_lt_sel";
>
> Can't we use "venc_sel" for both avc and vp8, since they are different
> nodes now? That way we can just say
>
> encoder must contain "venc_sel"
>
> which is clearer and also simpler on the code side.
>
ditto
> > + decoder must contain "vcodecpll", "univpll_d2", "clk_cci400_sel",
> > + "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", "vdec_bus_clk_src".
> > - iommus : should point to the respective IOMMU block with master port as
> >argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> >for details.
> > @@ -80,14 +83,10 @@ vcodec_dec: vcodec@1600 {
> > assigned-clock-rates = <0>, <0>, <0>, <148200>, <8>;
> >};
> >
> > - vcodec_enc: vcodec@18002000 {
> > -compatible = "mediatek,mt8173-vcodec-enc";
> > -reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
> > - <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
> > -interrupts = ,
> > -;
> > -mediatek,larb = <&larb3>,
> > - <&larb5>;
> > +vcodec_enc: vcodec@18002000 {
>
> Let's use vcodec_enc_avc as a label?
ditto
>
> > +compatible = "mediatek,mt8173-vcodec-avc-enc";
> > +reg = <0 0x18002000 0 0x1000>;
> > +interrupts = ;
> > iommus = <&iommu M4U_PORT_VENC_RCPU>,
> > <&iommu M4U_PORT_VENC_REC>,
> > <&iommu M4U_PORT_VENC_BSDMA>,
> > @@ -98,8 +97,20 @@ vcodec_dec: vcodec@1600 {
> > <&iommu M4U_PORT_VENC_REF_LUMA>,
> > <&iommu M4U_PORT_VENC_REF_CHROMA>,
> > <&iommu M4U_PORT_VENC_NBM_RDMA>,
> > - <&iommu M4U_PORT_VENC_NBM_WDMA>,
> > - <&iommu M4U_PORT_VENC_RCPU_SET2>,
> > + <&iommu M4U_PORT_VENC_NBM_WDMA>;
> > +mediatek,larb = <&larb3>;
> > +mediatek,vpu = <&vpu>;
> > +clocks = <&topckgen CLK_TOP_VENC_SEL>;
> > +clock-names = "venc_sel";
> > +assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>;
> > +assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>;
> > + };
> > +
> > +vcodec_enc_lt: vcodec@19002000 {
>
> And here the label should probably be "vcodec_enc_vp8" for consistency.
ditto
>
>
>
> > +compatible = "mediatek,mt8173-vcodec-vp8-enc";
> > +reg = <0 0x19002000 0 0x1000>;/* VENC_LT_SYS */
> > +interrupts = ;
> > +iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>,
> > <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
> > <&iommu M4U_PORT_VE
[RESEND v3 2/2] drm/bridge: anx7625: disable regulators when power off
When suspending the driver, anx7625_power_standby() will be called to
turn off reset-gpios and enable-gpios. However, power supplies are not
disabled. To save power, the driver can get the power supply regulators
and turn off them in anx7625_power_standby().
Signed-off-by: Hsin-Yi Wang
---
Change:
v3: add delays between regulators power on
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 34 +++
drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 65cc05982f826..23283ba0c4f93 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -875,12 +876,25 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
static void anx7625_power_on(struct anx7625_data *ctx)
{
struct device *dev = &ctx->client->dev;
+ int ret, i;
if (!ctx->pdata.low_power_mode) {
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
return;
}
+ for (i = 0; i < ARRAY_SIZE(ctx->pdata.supplies); i++) {
+ ret = regulator_enable(ctx->pdata.supplies[i].consumer);
+ if (ret < 0) {
+ DRM_DEV_DEBUG_DRIVER(dev, "cannot enable supply %d:
%d\n",
+i, ret);
+ goto reg_err;
+ }
+ usleep_range(2000, 2100);
+ }
+
+ usleep_range(4000, 4100);
+
/* Power on pin enable */
gpiod_set_value(ctx->pdata.gpio_p_on, 1);
usleep_range(1, 11000);
@@ -889,11 +903,16 @@ static void anx7625_power_on(struct anx7625_data *ctx)
usleep_range(1, 11000);
DRM_DEV_DEBUG_DRIVER(dev, "power on !\n");
+ return;
+reg_err:
+ for (--i; i >= 0; i--)
+ regulator_disable(ctx->pdata.supplies[i].consumer);
}
static void anx7625_power_standby(struct anx7625_data *ctx)
{
struct device *dev = &ctx->client->dev;
+ int ret;
if (!ctx->pdata.low_power_mode) {
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode!\n");
@@ -904,6 +923,12 @@ static void anx7625_power_standby(struct anx7625_data *ctx)
usleep_range(1000, 1100);
gpiod_set_value(ctx->pdata.gpio_p_on, 0);
usleep_range(1000, 1100);
+
+ ret = regulator_bulk_disable(ARRAY_SIZE(ctx->pdata.supplies),
+ctx->pdata.supplies);
+ if (ret < 0)
+ DRM_DEV_DEBUG_DRIVER(dev, "cannot disable supplies %d\n", ret);
+
DRM_DEV_DEBUG_DRIVER(dev, "power down\n");
}
@@ -1742,6 +1767,15 @@ static int anx7625_i2c_probe(struct i2c_client *client,
platform->client = client;
i2c_set_clientdata(client, platform);
+ pdata->supplies[0].supply = "vdd10";
+ pdata->supplies[1].supply = "vdd18";
+ pdata->supplies[2].supply = "vdd33";
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pdata->supplies),
+ pdata->supplies);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "fail to get power supplies: %d\n", ret);
+ return ret;
+ }
anx7625_init_gpio(platform);
atomic_set(&platform->power_status, 0);
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index 193ad86c54503..e4a086b3a3d7b 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -350,6 +350,7 @@ struct s_edid_data {
struct anx7625_platform_data {
struct gpio_desc *gpio_p_on;
struct gpio_desc *gpio_reset;
+ struct regulator_bulk_data supplies[3];
struct drm_bridge *panel_bridge;
int intp_irq;
u32 low_power_mode;
--
2.30.0.617.g56c4b15f3c-goog
[RESEND v3 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
anx7625 requires 3 power supply regulators.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/analogix,anx7625.yaml | 15 +++
1 file changed, 15 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 60585a4fc22bc..3ae97d9523e56 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -34,6 +34,15 @@ properties:
description: used for reset chip control, RESET_N pin B7.
maxItems: 1
+ vdd10-supply:
+description: Regulator that provides the supply 1.0V power.
+
+ vdd18-supply:
+description: Regulator that provides the supply 1.8V power.
+
+ vdd33-supply:
+description: Regulator that provides the supply 3.3V power.
+
ports:
type: object
@@ -55,6 +64,9 @@ properties:
required:
- compatible
- reg
+ - vdd10-supply
+ - vdd18-supply
+ - vdd33-supply
- ports
additionalProperties: false
@@ -72,6 +84,9 @@ examples:
reg = <0x58>;
enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
+vdd10-supply = <&pp1000_mipibrdg>;
+vdd18-supply = <&pp1800_mipibrdg>;
+vdd33-supply = <&pp3300_mipibrdg>;
ports {
#address-cells = <1>;
--
2.30.0.617.g56c4b15f3c-goog
KASAN: out-of-bounds Read in leaf_paste_entries
Hello, syzbot found the following issue on: HEAD commit:f40ddce8 Linux 5.11 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=16c21204d0 kernel config: https://syzkaller.appspot.com/x/.config?x=51ab7ccac30c dashboard link: https://syzkaller.appspot.com/bug?extid=c31a48e6702ccb3d64c9 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10ede514d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13f9f338d0 Bisection is inconclusive: the issue happens on the oldest tested release. bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=141b8882d0 final oops: https://syzkaller.appspot.com/x/report.txt?x=161b8882d0 console output: https://syzkaller.appspot.com/x/log.txt?x=121b8882d0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+c31a48e6702ccb3d6...@syzkaller.appspotmail.com REISERFS (device loop0): journal params: device loop0, size 15748, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 REISERFS (device loop0): checking transaction log (loop0) REISERFS (device loop0): Using tea hash to sort names == BUG: KASAN: out-of-bounds in memmove include/linux/string.h:462 [inline] BUG: KASAN: out-of-bounds in leaf_paste_entries+0x449/0x910 fs/reiserfs/lbalance.c:1377 Read of size 18446744073709551584 at addr 888040a03fa4 by task syz-executor585/8424 CPU: 1 PID: 8424 Comm: syz-executor585 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2c6 mm/kasan/report.c:230 __kasan_report mm/kasan/report.c:396 [inline] kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413 check_memory_region_inline mm/kasan/generic.c:179 [inline] check_memory_region+0x13d/0x180 mm/kasan/generic.c:185 memmove+0x20/0x60 mm/kasan/shadow.c:53 memmove include/linux/string.h:462 [inline] leaf_paste_entries+0x449/0x910 fs/reiserfs/lbalance.c:1377 balance_leaf_finish_node_paste_dirent fs/reiserfs/do_balan.c:1295 [inline] balance_leaf_finish_node_paste fs/reiserfs/do_balan.c:1321 [inline] balance_leaf_finish_node fs/reiserfs/do_balan.c:1364 [inline] balance_leaf+0x951e/0xd8b0 fs/reiserfs/do_balan.c:1452 do_balance+0x315/0x810 fs/reiserfs/do_balan.c:1888 reiserfs_paste_into_item+0x762/0x8e0 fs/reiserfs/stree.c:2138 reiserfs_add_entry+0x8cb/0xcf0 fs/reiserfs/namei.c:566 reiserfs_mkdir+0x66e/0x980 fs/reiserfs/namei.c:858 create_privroot fs/reiserfs/xattr.c:889 [inline] reiserfs_xattr_init+0x4de/0xb60 fs/reiserfs/xattr.c:1011 reiserfs_fill_super+0x215d/0x2e00 fs/reiserfs/super.c:2177 mount_bdev+0x34d/0x410 fs/super.c:1366 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1496 do_new_mount fs/namespace.c:2881 [inline] path_mount+0x13ad/0x20c0 fs/namespace.c:3211 do_mount fs/namespace.c:3224 [inline] __do_sys_mount fs/namespace.c:3432 [inline] __se_sys_mount fs/namespace.c:3409 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3409 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x445b8a Code: 48 c7 c2 c0 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fff8c7af438 EFLAGS: 0286 ORIG_RAX: 00a5 RAX: ffda RBX: 7fff8c7af490 RCX: 00445b8a RDX: 2000 RSI: 2100 RDI: 7fff8c7af450 RBP: 7fff8c7af450 R08: 7fff8c7af490 R09: R10: R11: 0286 R12: 22a8 R13: 0003 R14: 0004 R15: 0007 The buggy address belongs to the page: page:8f17f20f refcount:3 mapcount:0 mapping:9acfcc32 index:0x3d97 pfn:0x40a03 aops:def_blk_aops ino:70 flags: 0xfff0002022(referenced|active|private) raw: 00fff0002022 dead0100 dead0122 88801795cb50 raw: 3d97 888038f7c4c8 0003 8881407ac000 page dumped because: kasan: bad access detected pages's memcg:8881407ac000 Memory state around the buggy address: 888040a03e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 888040a03f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >888040a03f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ 888040a04000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 888040a04080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff == --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for m
Re: [PATCH v2 1/1] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
On Sat, 2021-02-20 at 13:37 +0800, Liu Ying wrote:
> Hi Guido,
>
> On Wed, 2020-12-16 at 12:27 +0100, Guido Günther wrote:
> > This allows us to shut down the mipi power domain on the imx8. The
> > alternative would be to drop the dphy from the mipi power domain in the
> > SOCs device tree and only have the DSI host controller visible there but
> > since the PD is mostly about the PHY that would defeat it's purpose.
> >
> > This allows to shut off the power domain hen blanking the LCD panel:
> >
> > pm_genpd_summary before:
> >
> > domain status slaves
> > /device runtime status
> > --
> > mipion
> > /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy unsupported
> > /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended
> >
> > after:
> >
> > mipioff-0
> > /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy suspended
> > /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended
> >
> > Signed-off-by: Guido Günther
> > ---
> > .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 22 ++-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > index a95572b397ca..34e2d801e520 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > /* DPHY registers */
> > @@ -93,6 +94,7 @@ struct mixel_dphy_cfg {
> > };
> >
> > struct mixel_dphy_priv {
> > + struct device *dev;
> > struct mixel_dphy_cfg cfg;
> > struct regmap *regmap;
> > struct clk *phy_ref_clk;
> > @@ -382,6 +384,7 @@ static int mixel_dphy_power_on(struct phy *phy)
> > ret = clk_prepare_enable(priv->phy_ref_clk);
> > if (ret < 0)
> > return ret;
> > + pm_runtime_get_sync(priv->dev);
> >
> > phy_write(phy, PWR_ON, DPHY_PD_PLL);
> > ret = regmap_read_poll_timeout(priv->regmap, DPHY_LOCK, locked,
> > @@ -395,6 +398,7 @@ static int mixel_dphy_power_on(struct phy *phy)
> >
> > return 0;
> > clock_disable:
> > + pm_runtime_put(priv->dev);
> > clk_disable_unprepare(priv->phy_ref_clk);
> > return ret;
> > }
> > @@ -406,6 +410,7 @@ static int mixel_dphy_power_off(struct phy *phy)
> > phy_write(phy, PWR_OFF, DPHY_PD_PLL);
> > phy_write(phy, PWR_OFF, DPHY_PD_DPHY);
> >
> > + pm_runtime_put(priv->dev);
> > clk_disable_unprepare(priv->phy_ref_clk);
> >
> > return 0;
> > @@ -467,6 +472,7 @@ static int mixel_dphy_probe(struct platform_device
> > *pdev)
> > dev_dbg(dev, "phy_ref clock rate: %lu\n",
> > clk_get_rate(priv->phy_ref_clk));
> >
> > + priv->dev = dev;
> > dev_set_drvdata(dev, priv);
> >
> > phy = devm_phy_create(dev, np, &mixel_dphy_phy_ops);
> > @@ -477,12 +483,26 @@ static int mixel_dphy_probe(struct platform_device
> > *pdev)
> > phy_set_drvdata(phy, priv);
> >
> > phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> > + if (IS_ERR(phy_provider))
> > + return PTR_ERR(phy_provider);
> >
> > - return PTR_ERR_OR_ZERO(phy_provider);
> > + pm_runtime_enable(dev);
>
> If this enablement is done prior to devm_phy_create(), then the
> phy-core will manage runtime PM for this device. This way, this driver
> doesn't have to manage it by itself.
>
> Regards,
> Liu Ying
>
> > +
> > + return 0;
> > +}
> > +
> > +static int mixel_dphy_remove(struct platform_device *pdev)
> > +{
> > + struct mixel_dphy_priv *priv = platform_get_drvdata(pdev);
> > +
> > + pm_runtime_disable(priv->dev);
One more comment - 'pm_runtime_disable(&pdev->dev);' is fine.
Regards,
Liu Ying
> > +
> > + return 0;
> > }
> >
> > static struct platform_driver mixel_dphy_driver = {
> > .probe = mixel_dphy_probe,
> > + .remove = mixel_dphy_remove,
> > .driver = {
> > .name = "mixel-mipi-dphy",
> > .of_match_table = mixel_dphy_of_match,
Re: [PATCH v2 1/1] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
Hi Guido,
On Wed, 2020-12-16 at 12:27 +0100, Guido Günther wrote:
> This allows us to shut down the mipi power domain on the imx8. The
> alternative would be to drop the dphy from the mipi power domain in the
> SOCs device tree and only have the DSI host controller visible there but
> since the PD is mostly about the PHY that would defeat it's purpose.
>
> This allows to shut off the power domain hen blanking the LCD panel:
>
> pm_genpd_summary before:
>
> domain status slaves
> /device runtime status
> --
> mipion
> /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy unsupported
> /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended
>
> after:
>
> mipioff-0
> /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy suspended
> /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended
>
> Signed-off-by: Guido Günther
> ---
> .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 22 ++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> index a95572b397ca..34e2d801e520 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /* DPHY registers */
> @@ -93,6 +94,7 @@ struct mixel_dphy_cfg {
> };
>
> struct mixel_dphy_priv {
> + struct device *dev;
> struct mixel_dphy_cfg cfg;
> struct regmap *regmap;
> struct clk *phy_ref_clk;
> @@ -382,6 +384,7 @@ static int mixel_dphy_power_on(struct phy *phy)
> ret = clk_prepare_enable(priv->phy_ref_clk);
> if (ret < 0)
> return ret;
> + pm_runtime_get_sync(priv->dev);
>
> phy_write(phy, PWR_ON, DPHY_PD_PLL);
> ret = regmap_read_poll_timeout(priv->regmap, DPHY_LOCK, locked,
> @@ -395,6 +398,7 @@ static int mixel_dphy_power_on(struct phy *phy)
>
> return 0;
> clock_disable:
> + pm_runtime_put(priv->dev);
> clk_disable_unprepare(priv->phy_ref_clk);
> return ret;
> }
> @@ -406,6 +410,7 @@ static int mixel_dphy_power_off(struct phy *phy)
> phy_write(phy, PWR_OFF, DPHY_PD_PLL);
> phy_write(phy, PWR_OFF, DPHY_PD_DPHY);
>
> + pm_runtime_put(priv->dev);
> clk_disable_unprepare(priv->phy_ref_clk);
>
> return 0;
> @@ -467,6 +472,7 @@ static int mixel_dphy_probe(struct platform_device *pdev)
> dev_dbg(dev, "phy_ref clock rate: %lu\n",
> clk_get_rate(priv->phy_ref_clk));
>
> + priv->dev = dev;
> dev_set_drvdata(dev, priv);
>
> phy = devm_phy_create(dev, np, &mixel_dphy_phy_ops);
> @@ -477,12 +483,26 @@ static int mixel_dphy_probe(struct platform_device
> *pdev)
> phy_set_drvdata(phy, priv);
>
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
>
> - return PTR_ERR_OR_ZERO(phy_provider);
> + pm_runtime_enable(dev);
If this enablement is done prior to devm_phy_create(), then the
phy-core will manage runtime PM for this device. This way, this driver
doesn't have to manage it by itself.
Regards,
Liu Ying
> +
> + return 0;
> +}
> +
> +static int mixel_dphy_remove(struct platform_device *pdev)
> +{
> + struct mixel_dphy_priv *priv = platform_get_drvdata(pdev);
> +
> + pm_runtime_disable(priv->dev);
> +
> + return 0;
> }
>
> static struct platform_driver mixel_dphy_driver = {
> .probe = mixel_dphy_probe,
> + .remove = mixel_dphy_remove,
> .driver = {
> .name = "mixel-mipi-dphy",
> .of_match_table = mixel_dphy_of_match,
Re: [PATCH v3 0/1] phy: fsl-imx8-mipi-dphy: Hook into runtime pm
Hi Guido, On Fri, 2021-02-19 at 10:38 +0100, Guido Günther wrote: > Hi, > On Wed, Dec 16, 2020 at 07:22:32PM +0100, Guido Günther wrote: > > This allows us to shut down the mipi power domain on the imx8. The > > alternative > > would be to drop the dphy from the mipi power domain in the SOCs device tree > > and only have the DSI host controller visible there but since the PD is > > mostly > > about the PHY that would defeat it's purpose. > > Is there anything I can do to move that forward. I assume this needs to > go via the phy/ subsystem not drm? I cannot find patch 1/1 of v3 in my mailbox, so I'll provide comment on v2. Regards, Liu Ying > Cheers, > -- Guido > > > This is basically a resend from February 2020 which went without feedback. > > > > This allows to shut off the power domain hen blanking the LCD panel: > > > > pm_genpd_summary before: > > > > domain status slaves > > /device runtime status > > -- > > mipion > > /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy unsupported > > /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended > > > > after: > > > > mipioff-0 > > /devices/platform/soc@0/soc@0:bus@3080/30a00300.dphy suspended > > /devices/platform/soc@0/soc@0:bus@3080/30a0.mipi_dsi suspended > > > > Changes from v1: > > - Tweak commit message slightly > > > > Changes from v2: > > - As pre review comment by Lucas Stach > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-arm-kernel%2Fee22b072e0abe07559a3e6a63ccf6ece064a46cb.camel%40pengutronix.de%2F&data=04%7C01%7Cvictor.liu%40nxp.com%7Ccac0b14c892c4a35340508d8d4ba2e16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637493243396909710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PU5kegolJwKK%2BQ7nD7V9qjrKJ2fJ9eKoySoFihnFoD8%3D&reserved=0 > > Check for pm_runtime_get_sync failure > > > > Guido Günther (1): > > phy: fsl-imx8-mipi-dphy: Hook into runtime pm > > > > .../phy/freescale/phy-fsl-imx8-mipi-dphy.c| 25 ++- > > 1 file changed, 24 insertions(+), 1 deletion(-) > > > > -- > > 2.29.2 > > > > > > ___ > > linux-arm-kernel mailing list > > linux-arm-ker...@lists.infradead.org > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=04%7C01%7Cvictor.liu%40nxp.com%7Ccac0b14c892c4a35340508d8d4ba2e16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637493243396909710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kkC3Go0wvHemjxaKVHwU%2F6gWRsgVOFoVz7QEHB7Zqx0%3D&reserved=0
Re: [Linuxarm] Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
On Thu, 18 Feb 2021, Xiaofei Tan wrote: > On 2021/2/9 13:06, Finn Thain wrote: > > On Tue, 9 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > > > On Sun, 7 Feb 2021, Xiaofei Tan wrote: > > > > > > > > > Replace spin_lock_irqsave with spin_lock in hard IRQ of SCSI > > > > > drivers. There are no function changes, but may speed up if > > > > > interrupt happen too often. > > > > > > > > This change doesn't necessarily work on platforms that support > > > > nested interrupts. > > > > > > > > Were you able to measure any benefit from this change on some > > > > other platform? > > > > > > I think the code disabling irq in hardIRQ is simply wrong. > > > Since this commit > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e58aa3d2d0cc > > > genirq: Run irq handlers with interrupts disabled > > > > > > interrupt handlers are definitely running in a irq-disabled context > > > unless irq handlers enable them explicitly in the handler to permit > > > other interrupts. > > > > > > > Repeating the same claim does not somehow make it true. If you put > > your claim to the test, you'll see that that interrupts are not > > disabled on m68k when interrupt handlers execute. > > > > The Interrupt Priority Level (IPL) can prevent any given irq handler > > from being re-entered, but an irq with a higher priority level may be > > handled during execution of a lower priority irq handler. > > > > sonic_interrupt() uses an irq lock within an interrupt handler to > > avoid issues relating to this. This kind of locking may be needed in > > the drivers you are trying to patch. Or it might not. Apparently, > > no-one has looked. > > > > According to your discussion with Barry, it seems that m68k is a little > different from other architecture, and this kind of modification of this > patch cannot be applied to m68k. So, could help to point out which > driver belong to m68k architecture in this patch set of SCSI? I can > remove them. > If you would claim that "there are no function changes" in your patches (as above) then the onus is on you to support that claim. I assume that there are some platforms on which your assumptions hold. With regard to drivers for those platforms, you might want to explain why your patches should be applied there, given that the existing code is superior for being more portable. > BTW, sonic_interrupt() is from net driver natsemi, right? It would be > appreciative if only discuss SCSI drivers in this patch set. thanks. > The 'net' subsystem does have some different requirements than the 'scsi' subsystem. But I don't see how that's relevant. Perhaps you can explain it. Thanks.
Re: [PATCH net-next] net: dsa: Fix dependencies with HSR
On 2/19/2021 9:12 PM, Florian Fainelli wrote:
> The core DSA framework uses hsr_is_master() which would not resolve to a
> valid symbol if HSR is built-into the kernel and DSA is a module.
>
> Fixes: 18596f504a3e ("net: dsa: add support for offloading HSR")
> Reported-by: kernel test robot
> Signed-off-by: Florian Fainelli
> ---
> David, Jakub,
>
> This showed up in linux-next which means it will show up in Linus' tree
> soon as well when your pull request gets sent out.
I had initially considered making is_hsr_master() a static inline that
would compare dev->dev.type->name with "hsr" since the HSR master would
set a custom dev_type, however the xrs700x driver would still fail to
link because it calls hsr_get_version() and for that one there is no
easy solution.
--
Florian
Re: [PATCH] iommu/tegra-smmu: Fix mc errors on tegra124-nyan
19.02.2021 01:07, Nicolin Chen пишет:
> Commit 25938c73cd79 ("iommu/tegra-smmu: Rework tegra_smmu_probe_device()")
> removed certain hack in the tegra_smmu_probe() by relying on IOMMU core to
> of_xlate SMMU's SID per device, so as to get rid of tegra_smmu_find() and
> tegra_smmu_configure() that are typically done in the IOMMU core also.
>
> This approach works for both existing devices that have DT nodes and other
> devices (like PCI device) that don't exist in DT, on Tegra210 and Tegra3
> upon testing. However, Page Fault errors are reported on tegra124-Nyan:
>
> tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40:
>EMEM address decode error (SMMU translation error [--S])
> tegra-mc 70019000.memory-controller: display0a: read @0xfe056b40:
>Page fault (SMMU translation error [--S])
>
> After debugging, I found that the mentioned commit changed some function
> callback sequence of tegra-smmu's, resulting in enabling SMMU for display
> client before display driver gets initialized. I couldn't reproduce exact
> same issue on Tegra210 as Tegra124 (arm-32) differs at arch-level code.
Hello Nicolin,
Could you please explain in a more details what exactly makes the
difference for the callback sequence?
[PATCH net-next] net: dsa: Fix dependencies with HSR
The core DSA framework uses hsr_is_master() which would not resolve to a
valid symbol if HSR is built-into the kernel and DSA is a module.
Fixes: 18596f504a3e ("net: dsa: add support for offloading HSR")
Reported-by: kernel test robot
Signed-off-by: Florian Fainelli
---
David, Jakub,
This showed up in linux-next which means it will show up in Linus' tree
soon as well when your pull request gets sent out.
net/dsa/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index a45572cfb71a..3589224c8da9 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -9,6 +9,7 @@ menuconfig NET_DSA
tristate "Distributed Switch Architecture"
depends on HAVE_NET_DSA
depends on BRIDGE || BRIDGE=n
+ depends on HSR || HSR=n
select GRO_CELLS
select NET_SWITCHDEV
select PHYLINK
--
2.25.1
arch/arm/kernel/sys_oabi-compat.c:257:6: error: implicit declaration of function 'ep_op_has_event'
Hi Russell, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f40ddce88593482919761f74910f42f4b84c004b commit: c281634c865202e2776b0250678ff93c771947ff ARM: compat: remove KERNEL_DS usage in sys_oabi_epoll_ctl() date: 10 months ago config: arm-randconfig-r024-20210220 (attached as .config) compiler: arm-linux-gnueabi-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c281634c865202e2776b0250678ff93c771947ff git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout c281634c865202e2776b0250678ff93c771947ff # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arch/arm/kernel/sys_oabi-compat.c:142:17: warning: no previous prototype for 'sys_oabi_stat64' [-Wmissing-prototypes] 142 | asmlinkage long sys_oabi_stat64(const char __user * filename, | ^~~ arch/arm/kernel/sys_oabi-compat.c:152:17: warning: no previous prototype for 'sys_oabi_lstat64' [-Wmissing-prototypes] 152 | asmlinkage long sys_oabi_lstat64(const char __user * filename, | ^~~~ arch/arm/kernel/sys_oabi-compat.c:162:17: warning: no previous prototype for 'sys_oabi_fstat64' [-Wmissing-prototypes] 162 | asmlinkage long sys_oabi_fstat64(unsigned long fd, | ^~~~ arch/arm/kernel/sys_oabi-compat.c:172:17: warning: no previous prototype for 'sys_oabi_fstatat64' [-Wmissing-prototypes] 172 | asmlinkage long sys_oabi_fstatat64(int dfd, | ^~ arch/arm/kernel/sys_oabi-compat.c:229:17: warning: no previous prototype for 'sys_oabi_fcntl64' [-Wmissing-prototypes] 229 | asmlinkage long sys_oabi_fcntl64(unsigned int fd, unsigned int cmd, | ^~~~ arch/arm/kernel/sys_oabi-compat.c:251:17: warning: no previous prototype for 'sys_oabi_epoll_ctl' [-Wmissing-prototypes] 251 | asmlinkage long sys_oabi_epoll_ctl(int epfd, int op, int fd, | ^~ arch/arm/kernel/sys_oabi-compat.c: In function 'sys_oabi_epoll_ctl': >> arch/arm/kernel/sys_oabi-compat.c:257:6: error: implicit declaration of >> function 'ep_op_has_event' [-Werror=implicit-function-declaration] 257 | if (ep_op_has_event(op) && | ^~~ >> arch/arm/kernel/sys_oabi-compat.c:264:9: error: implicit declaration of >> function 'do_epoll_ctl'; did you mean 'sys_epoll_ctl'? >> [-Werror=implicit-function-declaration] 264 | return do_epoll_ctl(epfd, op, fd, &kernel, false); | ^~~~ | sys_epoll_ctl arch/arm/kernel/sys_oabi-compat.c: At top level: arch/arm/kernel/sys_oabi-compat.c:267:17: warning: no previous prototype for 'sys_oabi_epoll_wait' [-Wmissing-prototypes] 267 | asmlinkage long sys_oabi_epoll_wait(int epfd, | ^~~ arch/arm/kernel/sys_oabi-compat.c:309:17: warning: no previous prototype for 'sys_oabi_semtimedop' [-Wmissing-prototypes] 309 | asmlinkage long sys_oabi_semtimedop(int semid, | ^~~ arch/arm/kernel/sys_oabi-compat.c:352:17: warning: no previous prototype for 'sys_oabi_semop' [-Wmissing-prototypes] 352 | asmlinkage long sys_oabi_semop(int semid, struct oabi_sembuf __user *tsops, | ^~ arch/arm/kernel/sys_oabi-compat.c:358:16: warning: no previous prototype for 'sys_oabi_ipc' [-Wmissing-prototypes] 358 | asmlinkage int sys_oabi_ipc(uint call, int first, int second, int third, |^~~~ arch/arm/kernel/sys_oabi-compat.c:376:17: warning: no previous prototype for 'sys_oabi_bind' [-Wmissing-prototypes] 376 | asmlinkage long sys_oabi_bind(int fd, struct sockaddr __user *addr, int addrlen) | ^ arch/arm/kernel/sys_oabi-compat.c:386:17: warning: no previous prototype for 'sys_oabi_connect' [-Wmissing-prototypes] 386 | asmlinkage long sys_oabi_connect(int fd, struct sockaddr __user *addr, int addrlen) | ^~~~ arch/arm/kernel/sys_oabi-compat.c:396:17: warning: no previous prototype for 'sys_oabi_sendto' [-Wmissing-prototypes] 396 | asmlinkage long sys_oabi_sendto(int fd, void __user *buff, | ^~~ arch/arm/kernel/sys_oab
[PATCH RFC tools/memory-model] Add access-marking documentation
This commit adapts the "Concurrency bugs should fear the big bad data-race detector (part 2)" LWN article (https://lwn.net/Articles/816854/) to kernel-documentation form. This allows more easily updating the material as needed. Suggested-by: Thomas Gleixner [ paulmck: Apply Marco Elver feedback. ] Reviewed-by: Marco Elver Signed-off-by: Paul E. McKenney diff --git a/tools/memory-model/Documentation/access-marking.txt b/tools/memory-model/Documentation/access-marking.txt new file mode 100644 index 000..accb79f --- /dev/null +++ b/tools/memory-model/Documentation/access-marking.txt @@ -0,0 +1,474 @@ +MARKING SHARED-MEMORY ACCESSES +== + +This document provides guidelines for marking intentionally concurrent +normal accesses to shared memory, that is "normal" as in accesses that do +not use read-modify-write atomic operations. It also describes how to +document these accesses, both with comments and with special assertions +processed by the Kernel Concurrency Sanitizer (KCSAN). This discussion +builds on an earlier LWN article [1]. + + +ACCESS-MARKING OPTIONS +== + +The Linux kernel provides the following access-marking options: + +1. Plain C-language accesses (unmarked), for example, "a = b;" + +2. Data-race marking, for example, "data_race(a = b);" + +3. READ_ONCE(), for example, "a = READ_ONCE(b);" + The various forms of atomic_read() also fit in here. + +4. WRITE_ONCE(), for example, "WRITE_ONCE(a, b);" + The various forms of atomic_set() also fit in here. + + +These may be used in combination, as shown in this admittedly improbable +example: + + WRITE_ONCE(a, b + data_race(c + d) + READ_ONCE(e)); + +Neither plain C-language accesses nor data_race() (#1 and #2 above) place +any sort of constraint on the compiler's choice of optimizations [2]. +In contrast, READ_ONCE() and WRITE_ONCE() (#3 and #4 above) restrict the +compiler's use of code-motion and common-subexpression optimizations. +Therefore, if a given access is involved in an intentional data race, +using READ_ONCE() for loads and WRITE_ONCE() for stores is usually +preferable to data_race(), which in turn is usually preferable to plain +C-language accesses. + +KCSAN will complain about many types of data races involving plain +C-language accesses, but marking all accesses involved in a given data +race with one of data_race(), READ_ONCE(), or WRITE_ONCE(), will prevent +KCSAN from complaining. Of course, lack of KCSAN complaints does not +imply correct code. Therefore, please take a thoughtful approach +when responding to KCSAN complaints. Churning the code base with +ill-considered additions of data_race(), READ_ONCE(), and WRITE_ONCE() +is unhelpful. + +In fact, the following sections describe situations where use of +data_race() and even plain C-language accesses is preferable to +READ_ONCE() and WRITE_ONCE(). + + +Use of the data_race() Macro + + +Here are some situations where data_race() should be used instead of +READ_ONCE() and WRITE_ONCE(): + +1. Data-racy loads from shared variables whose values are used only + for diagnostic purposes. + +2. Data-racy reads whose values are checked against marked reload. + +3. Reads whose values feed into error-tolerant heuristics. + +4. Writes setting values that feed into error-tolerant heuristics. + + +Data-Racy Reads for Approximate Diagnostics + +Approximate diagnostics include lockdep reports, monitoring/statistics +(including /proc and /sys output), WARN*()/BUG*() checks whose return +values are ignored, and other situations where reads from shared variables +are not an integral part of the core concurrency design. + +In fact, use of data_race() instead READ_ONCE() for these diagnostic +reads can enable better checking of the remaining accesses implementing +the core concurrency design. For example, suppose that the core design +prevents any non-diagnostic reads from shared variable x from running +concurrently with updates to x. Then using plain C-language writes +to x allows KCSAN to detect reads from x from within regions of code +that fail to exclude the updates. In this case, it is important to use +data_race() for the diagnostic reads because otherwise KCSAN would give +false-positive warnings about these diagnostic reads. + +In theory, plain C-language loads can also be used for this use case. +In practice, doing so is an excellent way to generate KCSAN false +positives, because KCSAN does not know that the data race is intentional. + + +Data-Racy Reads That Are Checked Against Marked Reload + +The values from some reads are not implicitly trusted. They are instead +fed into some operation that checks the full value against a later marked +load from memory, which means that the occasional arbitrarily bogus value +is not a problem. For example, if a bogus value is fed into cmpxchg(), +all that happens is that this cmpxchg() fails, which norma
Re: [RFC PATCH v5 2/4] block: add simple copy support
On 2021/02/20 11:01, SelvaKumar S wrote:
> Add new BLKCOPY ioctl that offloads copying of one or more sources
> ranges to a destination in the device. Accepts a 'copy_range' structure
> that contains destination (in sectors), no of sources and pointer to the
> array of source ranges. Each source range is represented by 'range_entry'
> that contains start and length of source ranges (in sectors).
>
> Introduce REQ_OP_COPY, a no-merge copy offload operation. Create
> bio with control information as payload and submit to the device.
> REQ_OP_COPY(19) is a write op and takes zone_write_lock when submitted
> to zoned device.
>
> If the device doesn't support copy or copy offload is disabled, then
> copy operation is emulated by default. However, the copy-emulation is an
> opt-in feature. Caller can choose not to use the copy-emulation by
> specifying a flag 'BLKDEV_COPY_NOEMULATION'.
>
> Copy-emulation is implemented by allocating memory of total copy size.
> The source ranges are read into memory by chaining bio for each source
> ranges and submitting them async and the last bio waits for completion.
> After data is read, it is written to the destination.
>
> bio_map_kern() is used to allocate bio and add pages of copy buffer to
> bio. As bio->bi_private and bio->bi_end_io are needed for chaining the
> bio and gets over-written, invalidate_kernel_vmap_range() for read is
> called in the caller.
>
> Introduce queue limits for simple copy and other helper functions.
> Add device limits as sysfs entries.
> - copy_offload
> - max_copy_sectors
> - max_copy_ranges_sectors
> - max_copy_nr_ranges
>
> copy_offload(= 0) is disabled by default. This needs to be enabled if
> copy-offload needs to be used.
> max_copy_sectors = 0 indicates the device doesn't support native copy.
>
> Native copy offload is not supported for stacked devices and is done via
> copy emulation.
>
> Signed-off-by: SelvaKumar S
> Signed-off-by: Kanchan Joshi
> Signed-off-by: Nitesh Shetty
> Signed-off-by: Javier González
> Signed-off-by: Chaitanya Kulkarni
> ---
> block/blk-core.c | 102 --
> block/blk-lib.c | 222 ++
> block/blk-merge.c | 2 +
> block/blk-settings.c | 10 ++
> block/blk-sysfs.c | 47
> block/blk-zoned.c | 1 +
> block/bounce.c| 1 +
> block/ioctl.c | 33 ++
> include/linux/bio.h | 1 +
> include/linux/blk_types.h | 14 +++
> include/linux/blkdev.h| 15 +++
> include/uapi/linux/fs.h | 13 +++
> 12 files changed, 453 insertions(+), 8 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 7663a9b94b80..23e646e5ae43 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -720,6 +720,17 @@ static noinline int should_fail_bio(struct bio *bio)
> }
> ALLOW_ERROR_INJECTION(should_fail_bio, ERRNO);
>
> +static inline int bio_check_copy_eod(struct bio *bio, sector_t start,
> + sector_t nr_sectors, sector_t max_sect)
> +{
> + if (nr_sectors && max_sect &&
> + (nr_sectors > max_sect || start > max_sect - nr_sectors)) {
> + handle_bad_sector(bio, max_sect);
> + return -EIO;
> + }
> + return 0;
> +}
> +
> /*
> * Check whether this bio extends beyond the end of the device or partition.
> * This may well happen - the kernel calls bread() without checking the size
> of
> @@ -738,6 +749,75 @@ static inline int bio_check_eod(struct bio *bio,
> sector_t maxsector)
> return 0;
> }
>
> +/*
> + * Check for copy limits and remap source ranges if needed.
> + */
> +static int blk_check_copy(struct bio *bio)
> +{
> + struct blk_copy_payload *payload = bio_data(bio);
> + struct request_queue *q = bio->bi_disk->queue;
> + sector_t max_sect, start_sect, copy_size = 0;
> + sector_t src_max_sect, src_start_sect;
> + struct block_device *bd_part;
> + int i, ret = -EIO;
> +
> + rcu_read_lock();
> +
> + bd_part = __disk_get_part(bio->bi_disk, bio->bi_partno);
> + if (unlikely(!bd_part)) {
> + rcu_read_unlock();
> + goto out;
> + }
> +
> + max_sect = bdev_nr_sectors(bd_part);
> + start_sect = bd_part->bd_start_sect;
> +
> + src_max_sect = bdev_nr_sectors(payload->src_bdev);
> + src_start_sect = payload->src_bdev->bd_start_sect;
> +
> + if (unlikely(should_fail_request(bd_part, bio->bi_iter.bi_size)))
> + goto out;
> +
> + if (unlikely(bio_check_ro(bio, bd_part)))
> + goto out;
There is no rcu_unlock() in that out label. Did you test ?
> +
> + rcu_read_unlock();
> +
> + /* cannot handle copy crossing nr_ranges limit */
> + if (payload->copy_nr_ranges > q->limits.max_copy_nr_ranges)
> + goto out;
> +
> + for (i = 0; i < payload->copy_nr_ranges; i++) {
> + ret = bio_check_copy_eod(bio, payload->range[i].src,
> +
Re: linux-next: Fixes tag needs some work in the block tree
On 2/19/21 9:51 PM, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 76676c992506 ("io_uring: fix io_rsrc_ref_quiesce races")
>
> Fixes tag
>
> Fixes: 0ce4a72632317 ("io_uring: don't hold uring_lock when calling
> io_run_task_work*")
>
> has these problem(s):
>
> - Target SHA1 does not exist
>
> Maybe you meant
>
> Fixes: a4f2225d1cb2 ("io_uring: don't hold uring_lock when calling
> io_run_task_work*")
Fixed it up, thanks Stephen.
--
Jens Axboe
linux-next: Fixes tag needs some work in the block tree
Hi all,
In commit
76676c992506 ("io_uring: fix io_rsrc_ref_quiesce races")
Fixes tag
Fixes: 0ce4a72632317 ("io_uring: don't hold uring_lock when calling
io_run_task_work*")
has these problem(s):
- Target SHA1 does not exist
Maybe you meant
Fixes: a4f2225d1cb2 ("io_uring: don't hold uring_lock when calling
io_run_task_work*")
--
Cheers,
Stephen Rothwell
pgpOB8SLSghjl.pgp
Description: OpenPGP digital signature
[PATCH] arp: Remove the arp_hh_ops structure
The 'arp_hh_ops' structure is similar to the 'arp_generic_ops' structure.
So remove the 'arp_hh_ops' structure.
Signed-off-by: Yejune Deng
---
net/ipv4/arp.c | 19 +++
1 file changed, 3 insertions(+), 16 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 922dd73e5740..6d60d9b89286 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -135,14 +135,6 @@ static const struct neigh_ops arp_generic_ops = {
.connected_output = neigh_connected_output,
};
-static const struct neigh_ops arp_hh_ops = {
- .family = AF_INET,
- .solicit = arp_solicit,
- .error_report = arp_error_report,
- .output = neigh_resolve_output,
- .connected_output = neigh_resolve_output,
-};
-
static const struct neigh_ops arp_direct_ops = {
.family = AF_INET,
.output = neigh_direct_output,
@@ -277,15 +269,10 @@ static int arp_constructor(struct neighbour *neigh)
memcpy(neigh->ha, dev->broadcast, dev->addr_len);
}
- if (dev->header_ops->cache)
- neigh->ops = &arp_hh_ops;
- else
- neigh->ops = &arp_generic_ops;
-
- if (neigh->nud_state & NUD_VALID)
- neigh->output = neigh->ops->connected_output;
+ if (!dev->header_ops->cache && (neigh->nud_state & NUD_VALID))
+ neigh->output = arp_generic_ops.connected_output;
else
- neigh->output = neigh->ops->output;
+ neigh->output = arp_generic_ops.output;
}
return 0;
}
--
2.29.0
Re: [External] Re: [PATCH v16 4/9] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page
On Fri, Feb 19, 2021 at 10:12 PM Michal Hocko wrote: > > On Fri 19-02-21 18:49:49, Muchun Song wrote: > > When we free a HugeTLB page to the buddy allocator, we should allocate > > the vmemmap pages associated with it. But we may cannot allocate vmemmap > > pages when the system is under memory pressure, in this case, we just > > refuse to free the HugeTLB page instead of looping forever trying to > > allocate the pages. This changes some behavior (list below) on some > > corner cases. > > > > 1) Failing to free a huge page triggered by the user (decrease nr_pages). > > > > Need try again later by the user. > > > > 2) Failing to free a surplus huge page when freed by the application. > > > > Try again later when freeing a huge page next time. > > This means that surplus pages can accumulate right? This should be > rather unlikely because one released huge page could then be reused for > normal allocations - including vmemmap. Unlucky timing might still end > up in the accumulation though. Not something critical though. Agree. > > > 3) Failing to dissolve a free huge page on ZONE_MOVABLE via > > offline_pages(). > > > > This is a bit unfortunate if we have plenty of ZONE_MOVABLE memory > > but are low on kernel memory. For example, migration of huge pages > > would still work, however, dissolving the free page does not work. > > This is a corner cases. When the system is that much under memory > > pressure, offlining/unplug can be expected to fail. > > Please mention that this is unfortunate because it prevents from the > memory offlining which shouldn't happen for movable zones. People > depending on the memory hotplug and movable zone should carefuly > consider whether savings on unmovable memory are worth losing their > hotplug functionality in some situations. Make sense. I will mention this in the change log. Thanks. > > > 4) Failing to dissolve a huge page on CMA/ZONE_MOVABLE via > > alloc_contig_range() - once we have that handling in place. Mainly > > affects CMA and virtio-mem. > > What about hugetlb page poisoning on HW failure (resp. soft offlining)? If the HW poisoned hugetlb page failed to be dissolved, the page will go back to the free list with PG_HWPoison set. But the page will not be used, because we will check whether the page is HW poisoned when it is dequeued from the free list. If so, we will skip this page. > > > > > Similar to 3). virito-mem will handle migration errors gracefully. > > CMA might be able to fallback on other free areas within the CMA > > region. > > > > We do not want to use GFP_ATOMIC to allocate vmemmap pages. Because it > > grants access to memory reserves and we do not think it is reasonable > > to use memory reserves. We use GFP_KERNEL in alloc_huge_page_vmemmap(). > > This likely needs more context around. Maybe something like > " > Vmemmap pages are allocated from the page freeing context. In order for > those allocations to be not disruptive (e.g. trigger oom killer) > __GFP_NORETRY is used. hugetlb_lock is dropped for the allocation > because a non sleeping allocation would be too fragile and it could fail > too easily under memory pressure. GFP_ATOMIC or other modes to access > memory reserves is not used because we want to prevent consuming > reserves under heavy hugetlb freeing. > " Thanks. I will use this to the change log. > > I haven't gone through the patch in a great detail yet, from a high > level POV it looks good although the counter changes and reshuffling > seems little wild. That requires a more detailed look I do not have time > for right now. Mike would be much better for that anywya ;) Yeah. Hope Mike will review this (I believe he is good at this area). > > I do not see any check for an atomic context in free_huge_page path. I > have suggested to replace in_task by in_atomic check (with a gotcha that > the later doesn't work without preempt_count but there is a work to > address that). Sorry. I forgot it. I will replace in_task with in_atomic in the next version. Thanks for your suggestions. > -- > Michal Hocko > SUSE Labs
Re: [PATCH 1/1] [PATCH] Documentation/translations: Translate sound/hd-audio/controls.rst into Chinese
在 2021/2/19 下午10:48, hjh 写道: > +Documentation/sound/hd-audio/controls.rst 的中文翻译 > + > +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 > +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 > +译存在问题，请联系中文版维护者。 > + > +中文版维护者： 黄江慧 Huang Jianghui > +中文版翻译者： 黄江慧 Huang Jianghui > + > + better to reuse disclaimer-zh_CN.rst here. Thanks
Re: [RFC PATCH v5 3/4] nvme: add simple copy support
On Fri, Feb 19, 2021 at 06:15:16PM +0530, SelvaKumar S wrote:
> + struct nvme_copy_range *range = NULL;
[...]
> + range = kmalloc_array(nr_range, sizeof(*range),
> + GFP_ATOMIC | __GFP_NOWARN);
[...]
> + req->special_vec.bv_page = virt_to_page(range);
> + req->special_vec.bv_offset = offset_in_page(range);
> + req->special_vec.bv_len = sizeof(*range) * nr_range;
[...]
> +struct nvme_copy_range {
> + __le64 rsvd0;
> + __le64 slba;
> + __le16 nlb;
> + __le16 rsvd18;
> + __le32 rsvd20;
> + __le32 eilbrt;
> + __le16 elbat;
> + __le16 elbatm;
> +};
so ... at 32 bytes, you can get 128 per 4kB page. What happens if you
try to send down a command that attempts to copy 129 ranges?
Re: [PATCH v14 11/11] kdump: update Documentation about crashkernel
On 2021/2/18 16:40, Baoquan He wrote: > On 01/30/21 at 03:10pm, Chen Zhou wrote: >> For arm64, the behavior of crashkernel=X has been changed, which >> tries low allocation in DMA zone and fall back to high allocation >> if it fails. >> >> We can also use "crashkernel=X,high" to select a high region above >> DMA zone, which also tries to allocate at least 256M low memory in >> DMA zone automatically and "crashkernel=Y,low" can be used to allocate >> specified size low memory. >> >> So update the Documentation. > Nice document adding which also takes care of x86 code implementation, > thanks. By the way, maybe you can remove John's 'Tested-by' since it > doesn't make much sense to test a document patch. I will remove the Tested-by in next version. > > Acked-by: Baoquan He > >> Signed-off-by: Chen Zhou >> Tested-by: John Donnelly >> --- >> Documentation/admin-guide/kdump/kdump.rst | 22 --- >> .../admin-guide/kernel-parameters.txt | 11 -- >> 2 files changed, 28 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/admin-guide/kdump/kdump.rst >> b/Documentation/admin-guide/kdump/kdump.rst >> index 75a9dd98e76e..0877c76f8015 100644 >> --- a/Documentation/admin-guide/kdump/kdump.rst >> +++ b/Documentation/admin-guide/kdump/kdump.rst >> @@ -299,7 +299,16 @@ Boot into System Kernel >> "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory >> starting at physical address 0x0100 (16MB) for the dump-capture >> kernel. >> >> - On x86 and x86_64, use "crashkernel=64M@16M". >> + On x86 use "crashkernel=64M@16M". >> + >> + On x86_64, use "crashkernel=X" to select a region under 4G first, and >> + fall back to reserve region above 4G. And go for high allocation >> + directly if the required size is too large. >> + We can also use "crashkernel=X,high" to select a region above 4G, which >> + also tries to allocate at least 256M below 4G automatically and >> + "crashkernel=Y,low" can be used to allocate specified size low memory. >> + Use "crashkernel=Y@X" if you really have to reserve memory from specified >> + start address X. >> >> On ppc64, use "crashkernel=128M@32M". >> >> @@ -316,8 +325,15 @@ Boot into System Kernel >> kernel will automatically locate the crash kernel image within the >> first 512MB of RAM if X is not given. >> >> - On arm64, use "crashkernel=Y[@X]". Note that the start address of >> - the kernel, X if explicitly specified, must be aligned to 2MiB >> (0x20). >> + On arm64, use "crashkernel=X" to try low allocation in DMA zone and >> + fall back to high allocation if it fails. >> + We can also use "crashkernel=X,high" to select a high region above >> + DMA zone, which also tries to allocate at least 256M low memory in >> + DMA zone automatically. >> + "crashkernel=Y,low" can be used to allocate specified size low memory. >> + Use "crashkernel=Y@X" if you really have to reserve memory from >> + specified start address X. Note that the start address of the kernel, >> + X if explicitly specified, must be aligned to 2MiB (0x20). >> >> Load the Dump-capture Kernel >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt >> b/Documentation/admin-guide/kernel-parameters.txt >> index a10b545c2070..908e5c8b61ba 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -738,6 +738,9 @@ >> [KNL, X86-64] Select a region under 4G first, and >> fall back to reserve region above 4G when '@offset' >> hasn't been specified. >> +[KNL, arm64] Try low allocation in DMA zone and fall >> back >> +to high allocation if it fails when '@offset' hasn't >> been >> +specified. >> See Documentation/admin-guide/kdump/kdump.rst for >> further details. >> >> crashkernel=range1:size1[,range2:size2,...][@offset] >> @@ -754,6 +757,8 @@ >> Otherwise memory region will be allocated below 4G, if >> available. >> It will be ignored if crashkernel=X is specified. >> +[KNL, arm64] range in high memory. >> +Allow kernel to allocate physical memory region from >> top. >> crashkernel=size[KMG],low >> [KNL, X86-64] range under 4G. When crashkernel=X,high >> is passed, kernel could allocate physical memory region >> @@ -762,13 +767,15 @@ >> requires at least 64M+32K low memory, also enough extra >> low memory is needed to make sure DMA buffers for 32-bit >> devices won't run out. Kernel would try to allocate at >> -at least 256M below 4G automatically. >> +least 256M below 4G automa
Re: [PATCH v14 09/11] x86, arm64: Add ARCH_WANT_RESERVE_CRASH_KERNEL config
On 2021/2/18 16:35, Baoquan He wrote:
> On 01/30/21 at 03:10pm, Chen Zhou wrote:
>> We make the functions reserve_crashkernel[_low]() as generic for
>> x86 and arm64. Since reserve_crashkernel[_low]() implementations
>> are quite similar on other architectures as well, we can have more
>> users of this later.
>>
>> So have CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL in arch/Kconfig and
>> select this by X86 and ARM64.
> This looks much better with the help of
> CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL. And please take off the
> 'Suggested-by' tag from me, I just don't like the old CONFIG_X86 and
> CONFIG_ARM64 ifdeffery way in v13, Mike suggested this ARCH_WANT_
> option.
OK, i will delete this.
>
> And the two dummy function reserve_crashkernel() in x86 and arm64 looks
> not so good, but I don't have better idea. Maybe add
> CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL iddeffery in the call site of
> reserve_crashkernel() in each ARCH? Or just leave with it for now if no
> other people has concern or suggestion about it.
>
> Anyway, ack this one.
>
> Acked-by: Baoquan He
>
> Thanks
> Baoquan
>
>
>> Suggested-by: Mike Rapoport
>> Suggested-by: Baoquan He
>> Signed-off-by: Chen Zhou
>> ---
>> arch/Kconfig| 3 +++
>> arch/arm64/Kconfig | 1 +
>> arch/x86/Kconfig| 2 ++
>> kernel/crash_core.c | 7 ++-
>> 4 files changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 24862d15f3a3..0ca1ff5bb157 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -24,6 +24,9 @@ config KEXEC_ELF
>> config HAVE_IMA_KEXEC
>> bool
>>
>> +config ARCH_WANT_RESERVE_CRASH_KERNEL
>> +bool
>> +
>> config SET_FS
>> bool
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index f39568b28ec1..09365c7ff469 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -82,6 +82,7 @@ config ARM64
>> select ARCH_WANT_FRAME_POINTERS
>> select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES
>> && !ARM64_VA_BITS_36)
>> select ARCH_WANT_LD_ORPHAN_WARN
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select ARCH_HAS_UBSAN_SANITIZE_ALL
>> select ARM_AMBA
>> select ARM_ARCH_TIMER
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 21f851179ff0..e6926fcb4a40 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -12,6 +12,7 @@ config X86_32
>> depends on !64BIT
>> # Options that are inherently 32-bit kernel only:
>> select ARCH_WANT_IPC_PARSE_VERSION
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select CLKSRC_I8253
>> select CLONE_BACKWARDS
>> select GENERIC_VDSO_32
>> @@ -28,6 +29,7 @@ config X86_64
>> select ARCH_HAS_GIGANTIC_PAGE
>> select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
>> select ARCH_USE_CMPXCHG_LOCKREF
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select HAVE_ARCH_SOFT_DIRTY
>> select MODULES_USE_ELF_RELA
>> select NEED_DMA_MAP_STATE
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 8479be270c0b..2c5783985db5 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -320,9 +320,7 @@ int __init parse_crashkernel_low(char *cmdline,
>> * - Crashkernel reservation --
>> */
>>
>> -#ifdef CONFIG_KEXEC_CORE
>> -
>> -#if defined(CONFIG_X86) || defined(CONFIG_ARM64)
>> +#ifdef CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL
>> static int __init reserve_crashkernel_low(void)
>> {
>> #ifdef CONFIG_64BIT
>> @@ -450,8 +448,7 @@ void __init reserve_crashkernel(void)
>> crashk_res.start = crash_base;
>> crashk_res.end = crash_base + crash_size - 1;
>> }
>> -#endif
>> -#endif /* CONFIG_KEXEC_CORE */
>> +#endif /* CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL */
>>
>> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
>>void *data, size_t data_len)
>> --
>> 2.20.1
>>
> .
>
[PATCH v2] xfrm: Fix incorrect types in assignment
Fix the following sparse warnings:
net/xfrm/xfrm_policy.c:1303:22: warning: incorrect type in assignment
(different address spaces)
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
net/xfrm/xfrm_policy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index b74f28c..aac5e88 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1300,7 +1300,8 @@ static void xfrm_hash_rebuild(struct work_struct *work)
}
hmask = net->xfrm.policy_bydst[dir].hmask;
- odst = net->xfrm.policy_bydst[dir].table;
+ odst =
rcu_dereference_protected(net->xfrm.policy_bydst[dir].table,
+
lockdep_is_held(&net->xfrm.xfrm_policy_lock));
for (i = hmask; i >= 0; i--) {
hlist_for_each_entry_safe(policy, n, odst + i, bydst)
hlist_del_rcu(&policy->bydst);
--
1.8.3.1
Re: [PATCH 5/9] security: keys: trusted: Allow storage of PCR values in creation data
On Sat, Feb 20, 2021 at 01:32:51AM +, Matthew Garrett wrote: > When TPMs generate keys, they can also generate some information > describing the state of the PCRs at creation time. This data can then > later be certified by the TPM, allowing verification of the PCR values. > This allows us to determine the state of the system at the time a key > was generated. Add an additional argument to the trusted key creation > options, allowing the user to provide the set of PCRs that should have > their values incorporated into the creation data. > > Signed-off-by: Matthew Garrett LGTM too. Something popped into mind: could we make PCR 23 reservation dynamic instead of a config option. E.g. if the user space uses it, then it's dirty and hibernate will fail. I really dislike the static compilation time firewall on it. /Jarkko
Re: [PATCH 3/9] security: keys: trusted: Parse out individual components of the key blob
On Sat, Feb 20, 2021 at 01:32:49AM +, Matthew Garrett wrote: > Performing any sort of state validation of a sealed TPM blob requires > being able to access the individual members in the response. Parse the > blob sufficiently to be able to stash pointers to each member, along > with the length. > > Signed-off-by: Matthew Garrett I'll just say LGTM for now. Did not see anything obviously wrong in the code change (and does make sense to nitpick minor things just yet). Need to understand the whole use case just a little bit better. /Jarkko
Re: [PATCH 4/9] security: keys: trusted: Store the handle of a loaded key
On Sat, Feb 20, 2021 at 01:32:50AM +, Matthew Garrett wrote:
> Certain in-kernel operations using a trusted key (such as creation
> certification) require knowledge of the handle it's loaded at. Keep
> a copy of that in the payload.
>
> Signed-off-by: Matthew Garrett
This looks good to me as well *as a code change*.
/Jarkko
> ---
> include/keys/trusted-type.h | 1 +
> security/keys/trusted-keys/trusted_tpm2.c | 6 --
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index 020e01a99ea4..154d8a1769c3 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -21,6 +21,7 @@
>
> struct trusted_key_payload {
> struct rcu_head rcu;
> + unsigned int blob_handle;
> unsigned int key_len;
> unsigned int blob_len;
> unsigned int creation_len;
> diff --git a/security/keys/trusted-keys/trusted_tpm2.c
> b/security/keys/trusted-keys/trusted_tpm2.c
> index 6357a51a24e9..a3673fffd834 100644
> --- a/security/keys/trusted-keys/trusted_tpm2.c
> +++ b/security/keys/trusted-keys/trusted_tpm2.c
> @@ -272,11 +272,13 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
> }
>
> rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
> - if (!rc)
> + if (!rc) {
> *blob_handle = be32_to_cpup(
> (__be32 *) &buf.data[TPM_HEADER_SIZE]);
> - else
> + payload->blob_handle = *blob_handle;
> + } else {
> goto out;
> + }
>
> rc = tpm2_unpack_blob(payload);
> out:
> --
> 2.30.0.617.g56c4b15f3c-goog
>
>
[PATCH v2] PCI: imx6: Limit DBI register length for imx6qp PCIe
Define the length of the DBI registers and limit config space to its
length. This makes sure that the kernel does not access registers beyond
that point that otherwise would lead to an abort on the i.MX 6QuadPlus.
See commit 075af61c19cd ("PCI: imx6: Limit DBI register length") that
resolves a similar issue on the i.MX 6Quad PCIe.
Signed-off-by: Richard Zhu
Reviewed-by: Lucas Stach
Reviewed-by: Krzysztof Wilczyński
---
drivers/pci/controller/dwc/pci-imx6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 0cf1333c0440..853ea8e82952 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1175,6 +1175,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
.variant = IMX6QP,
.flags = IMX6_PCIE_FLAG_IMX6_PHY |
IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
+ .dbi_length = 0x200,
},
[IMX7D] = {
.variant = IMX7D,
--
2.17.1
Re: [PATCH 2/9] tpm: Allow PCR 23 to be restricted to kernel-only use
On Sat, Feb 20, 2021 at 01:32:48AM +, Matthew Garrett wrote:
> Under certain circumstances it might be desirable to enable the creation
> of TPM-backed secrets that are only accessible to the kernel. In an
> ideal world this could be achieved by using TPM localities, but these
> don't appear to be available on consumer systems. An alternative is to
> simply block userland from modifying one of the resettable PCRs, leaving
> it available to the kernel. If the kernel ensures that no userland can
> access the TPM while it is carrying out work, it can reset PCR 23,
> extend it to an arbitrary value, create or load a secret, and then reset
> the PCR again. Even if userland somehow obtains the sealed material, it
> will be unable to unseal it since PCR 23 will never be in the
> appropriate state.
Does this leave room to use them *if* they are available? Not saying
that this patch set must support them, but neither would like to
disclude them from unforseeable future.
>
> Signed-off-by: Matthew Garrett
> ---
> drivers/char/tpm/Kconfig | 10 +
> drivers/char/tpm/tpm-dev-common.c | 8 +++
> drivers/char/tpm/tpm.h| 21 +++
> drivers/char/tpm/tpm1-cmd.c | 35 +++
> drivers/char/tpm/tpm2-cmd.c | 22 +++
> drivers/char/tpm/tpm2-space.c | 2 +-
> 6 files changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
> index a18c314da211..bba30fb16a2e 100644
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -190,4 +190,14 @@ config TCG_FTPM_TEE
> This driver proxies for firmware TPM running in TEE.
>
> source "drivers/char/tpm/st33zp24/Kconfig"
> +
> +config TCG_TPM_RESTRICT_PCR
> + bool "Restrict userland access to PCR 23"
> + depends on TCG_TPM
> + help
> + If set, block userland from extending or resetting PCR 23. This
> + allows it to be restricted to in-kernel use, preventing userland
> + from being able to make use of data sealed to the TPM by the kernel.
> + This is required for secure hibernation support, but should be left
> + disabled if any userland may require access to PCR23.
> endif # TCG_TPM
> diff --git a/drivers/char/tpm/tpm-dev-common.c
> b/drivers/char/tpm/tpm-dev-common.c
> index 1784530b8387..d3db4fd76257 100644
> --- a/drivers/char/tpm/tpm-dev-common.c
> +++ b/drivers/char/tpm/tpm-dev-common.c
> @@ -193,6 +193,14 @@ ssize_t tpm_common_write(struct file *file, const char
> __user *buf,
> priv->response_read = false;
> *off = 0;
>
> + if (priv->chip->flags & TPM_CHIP_FLAG_TPM2)
> + ret = tpm2_cmd_restricted(priv->chip, priv->data_buffer, size);
> + else
> + ret = tpm1_cmd_restricted(priv->chip, priv->data_buffer, size);
> +
> + if (ret)
> + goto out;
> +
I have to admit my knowledge is limited here. I'm not sure how widely is 23
used by the pre-existing user space in the wild.
> /*
>* If in nonblocking mode schedule an async job to send
>* the command return the size.
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 746f7696bdc0..8eed5016d733 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -232,6 +232,8 @@ void tpm2_shutdown(struct tpm_chip *chip, u16
> shutdown_type);
> unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
> int tpm2_probe(struct tpm_chip *chip);
> int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip);
> +int tpm_find_and_validate_cc(struct tpm_chip *chip, struct tpm_space *space,
> + const void *buf, size_t bufsiz);
> int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
> int tpm2_init_space(struct tpm_space *space, unsigned int buf_size);
> void tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space);
> @@ -245,4 +247,23 @@ void tpm_bios_log_setup(struct tpm_chip *chip);
> void tpm_bios_log_teardown(struct tpm_chip *chip);
> int tpm_dev_common_init(void);
> void tpm_dev_common_exit(void);
> +
> +#ifdef CONFIG_TCG_TPM_RESTRICT_PCR
> +#define TPM_RESTRICTED_PCR 23
> +
> +int tpm1_cmd_restricted(struct tpm_chip *chip, u8 *buffer, size_t size);
> +int tpm2_cmd_restricted(struct tpm_chip *chip, u8 *buffer, size_t size);
> +#else
> +static inline int tpm1_cmd_restricted(struct tpm_chip *chip, u8 *buffer,
> + size_t size)
> +{
> + return 0;
> +}
> +
> +static inline int tpm2_cmd_restricted(struct tpm_chip *chip, u8 *buffer,
> + size_t size)
> +{
> + return 0;
> +}
> +#endif
> #endif
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index 36990e9d2dc1..2dab1647d89c 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -840,3 +840,38 @@ int tpm1_get_pcr_allocation(struct tpm_chip *chip)
>
> return 0;
> }
> +
> +#ifdef CONFIG
[PATCH] PCI: imx6: Limit DBI register length for imx6qp PCIe
Changes from v1 to v2: - Add reviewed by Lucas and Krzysztof. - Refine the subject and commit refer to Krzysztof comments. drivers/pci/controller/dwc/pci-imx6.c | 1 + 1 file changed, 1 insertion(+) [PATCH v2] PCI: imx6: Limit DBI register length for imx6qp PCIe
Re: [PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
On 2/19/2021 6:38 PM, Jason Wang wrote: Right now the value is exposed to userspace via GET_VRING_BASE, so only last_avail_idx is synced. If we need sync last_used_idx, we should also sync pending indices which requires more thoughts. Technically it doesn't sound right - crossing the boundary a bit even with simplified form of assumption. But depending on how userspace could make use of this API, it doesn't seem it breaks existing functionality for the moment. I don't get here, maybe you can explain a little bit more? Please refer to the email I just sent. https://lore.kernel.org/lkml/033b0806-4037-5755-a1fa-91dbb58ba...@oracle.com/ -Siwei
[PATCH v2] drm/amdgpu/swsmu/navi1x: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:900:47-52: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c index cd7efa9..58028a7 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c @@ -897,7 +897,7 @@ static bool navi10_is_support_fine_grained_dpm(struct smu_context *smu, enum smu dpm_desc = &pptable->DpmDescriptor[clk_index]; /* 0 - Fine grained DPM, 1 - Discrete DPM */ - return dpm_desc->SnapToDiscrete == 0 ? true : false; + return dpm_desc->SnapToDiscrete == 0; } static inline bool navi10_od_feature_is_supported(struct smu_11_0_overdrive_table *od_table, enum SMU_11_0_ODFEATURE_CAP cap) -- 1.8.3.1
Re: [PATCH 1/9] tpm: Add support for in-kernel resetting of PCRs
On Sat, Feb 20, 2021 at 01:32:47AM +, Matthew Garrett wrote:
Perhaps, prepend with a paragraph elaborating the background just a bit:
"When entering to hibernation, PCR 23 will be used to store a known value.
This value defines a policy for the decryption of the key used to encrypt
the hibernate image."
At minimum that. You can of course edit this however you see fit.
> Add an internal command for resetting a PCR.
>
> Signed-off-by: Matthew Garrett
> ---
> drivers/char/tpm/tpm-interface.c | 28 +
> drivers/char/tpm/tpm.h | 2 ++
> drivers/char/tpm/tpm1-cmd.c | 34 ++
> drivers/char/tpm/tpm2-cmd.c | 36
> include/linux/tpm.h | 7 +++
> 5 files changed, 107 insertions(+)
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index 1621ce818705..17b8643ee109 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -342,6 +342,34 @@ int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> }
> EXPORT_SYMBOL_GPL(tpm_pcr_extend);
>
> +/**
> + * tpm_pcr_reset - reset the specified PCR
> + * @chip:a &struct tpm_chip instance, %NULL for the default chip
> + * @pcr_idx: the PCR to be reset
> + *
> + * Return: same as with tpm_transmit_cmd()
> + */
> +int tpm_pcr_reset(struct tpm_chip *chip, u32 pcr_idx)
> +{
> + int rc;
> +
> + chip = tpm_find_get_ops(chip);
> + if (!chip)
> + return -ENODEV;
> +
> + if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> + rc = tpm2_pcr_reset(chip, pcr_idx);
> + goto out;
> + }
> +
> + rc = tpm1_pcr_reset(chip, pcr_idx, "attempting to reset a PCR");
> +
> +out:
> + tpm_put_ops(chip);
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(tpm_pcr_reset);
> +
> /**
> * tpm_send - send a TPM command
> * @chip:a &struct tpm_chip instance, %NULL for the default chip
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 947d1db0a5cc..746f7696bdc0 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -176,6 +176,7 @@ int tpm1_get_timeouts(struct tpm_chip *chip);
> unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
> int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash,
> const char *log_msg);
> +int tpm1_pcr_reset(struct tpm_chip *chip, u32 pcr_idx, const char *log_msg);
> int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
> ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> const char *desc, size_t min_cap_length);
> @@ -220,6 +221,7 @@ int tpm2_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
> struct tpm_digest *digest, u16 *digest_size_ptr);
> int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> struct tpm_digest *digests);
> +int tpm2_pcr_reset(struct tpm_chip *chip, u32 pcr_idx);
> int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
> ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
> u32 *value, const char *desc);
> diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
> index ca7158fa6e6c..36990e9d2dc1 100644
> --- a/drivers/char/tpm/tpm1-cmd.c
> +++ b/drivers/char/tpm/tpm1-cmd.c
> @@ -478,6 +478,40 @@ int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> const u8 *hash,
> return rc;
> }
>
> +struct tpm_pcr_selection {
> + u16 size_of_select;
> + u8 pcr_select[3];
> +} __packed;
> +
> +#define TPM_ORD_PCR_RESET 200
> +int tpm1_pcr_reset(struct tpm_chip *chip, u32 pcr_idx, const char *log_msg)
> +{
> + struct tpm_pcr_selection selection;
> + struct tpm_buf buf;
> + int i, rc;
> + char tmp;
> +
> + rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_RESET);
> + if (rc)
> + return rc;
> +
> + selection.size_of_select = 3;
> +
> + for (i = 0; i < selection.size_of_select; i++) {
> + tmp = 0;
> + if (pcr_idx / 3 == i) {
> + pcr_idx -= i * 8;
> + tmp |= 1 << pcr_idx;
> + }
> + selection.pcr_select[i] = tmp;
> + }
> + tpm_buf_append(&buf, (u8 *)&selection, sizeof(selection));
> +
> + rc = tpm_transmit_cmd(chip, &buf, sizeof(selection), log_msg);
> + tpm_buf_destroy(&buf);
> + return rc;
> +}
> +
> #define TPM_ORD_GET_CAP 101
> ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
> const char *desc, size_t min_cap_length)
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index eff1f12d981a..9609ae8086c6 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -269,6 +269,42 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> return rc;
> }
>
> +/**
> + * tpm2_pcr_reset() - reset a PCR
>
Apply for loan at 5% interest rate per year
BrightWay Finance offers Loans ranging from (R10, 000.00 - R60, 000,000.00). Loan duration is from 1 to 20 years (Maximum) No collateral, No ITC CHECK and Blacklisted are welcome. If you wish to apply kindly send your full names, ID number, email address and cellphone number to brightwayfinanceloa...@protonmail.com Yours in Service, Jane Cooper MARKETING TEAM Tel No: +27(0)622541582 BrightWay Finance Loan(PTY) LTD. brightwayfinanceloa...@protonmail.com
Re: [PATCH 1/2] vdpa/mlx5: Fix suspend/resume index restoration
On 2/17/2021 11:42 AM, Si-Wei Liu wrote:
On 2/16/2021 8:20 AM, Eli Cohen wrote:
When we suspend the VM, the VDPA interface will be reset. When the VM is
resumed again, clear_virtqueues() will clear the available and used
indices resulting in hardware virqtqueue objects becoming out of sync.
We can avoid this function alltogether since qemu will clear them if
required, e.g. when the VM went through a reboot.
Moreover, since the hw available and used indices should always be
identical on query and should be restored to the same value same value
for virtqueues that complete in order, we set the single value provided
by set_vq_state(). In get_vq_state() we return the value of hardware
used index.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
devices")
Signed-off-by: Eli Cohen
Acked-by: Si-Wei Liu
I'd take it back for the moment, according to Jason's latest comment.
Discussion still going.
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index b8e9d525d66c..a51b0f86afe2 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1169,6 +1169,7 @@ static void suspend_vq(struct mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtqueue *m
return;
}
mvq->avail_idx = attr.available_index;
+ mvq->used_idx = attr.used_index;
}
static void suspend_vqs(struct mlx5_vdpa_net *ndev)
@@ -1426,6 +1427,7 @@ static int mlx5_vdpa_set_vq_state(struct
vdpa_device *vdev, u16 idx,
return -EINVAL;
}
+ mvq->used_idx = state->avail_index;
mvq->avail_idx = state->avail_index;
This is where things starts getting interesting. According to Jason, the
original expectation of this API would be to restore the internal
last_avail_index in the hardware. With Mellanox network vDPA hardware
implementation, there's no such last_avail_index thing in the hardware
but only a single last_used_index representing both indices, which
should always be the same and in sync with each other. So from migration
point of view, it appears logical to restore the saved last_avail_index
to the last_used_index in the hardware, right? But what is the point to
restore mvq->avail_idx?
Actually, this code path is being repurposed to address the index reset
problem in the device reset scenario. Where the mvq->avail_idx and
mvq->used_idx are both reset to 0 once device is reset. This is a bit
crossing the boundary to me.
return 0;
}
@@ -1443,7 +1445,7 @@ static int mlx5_vdpa_get_vq_state(struct
vdpa_device *vdev, u16 idx, struct vdpa
* that cares about emulating the index after vq is stopped.
*/
if (!mvq->initialized) {
- state->avail_index = mvq->avail_idx;
+ state->avail_index = mvq->used_idx;
This is where the last_used_index gets loaded from the hardware (when
device is stopped).
return 0;
}
@@ -1452,7 +1454,7 @@ static int mlx5_vdpa_get_vq_state(struct
vdpa_device *vdev, u16 idx, struct vdpa
mlx5_vdpa_warn(mvdev, "failed to query virtqueue\n");
return err;
}
- state->avail_index = attr.available_index;
+ state->avail_index = attr.used_index;
This code path never gets called from userspace (when device is running).
-Siwei
return 0;
}
@@ -1532,16 +1534,6 @@ static void teardown_virtqueues(struct
mlx5_vdpa_net *ndev)
}
}
-static void clear_virtqueues(struct mlx5_vdpa_net *ndev)
-{
- int i;
-
- for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
- ndev->vqs[i].avail_idx = 0;
- ndev->vqs[i].used_idx = 0;
- }
-}
-
/* TODO: cross-endian support */
static inline bool mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev
*mvdev)
{
@@ -1777,7 +1769,6 @@ static void mlx5_vdpa_set_status(struct
vdpa_device *vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device reset\n");
teardown_driver(ndev);
- clear_virtqueues(ndev);
mlx5_vdpa_destroy_mr(&ndev->mvdev);
ndev->mvdev.status = 0;
++mvdev->generation;
Re: [PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
On 2021/2/20 10:05 上午, Si-Wei Liu wrote:
On 2/18/2021 7:10 PM, Jason Wang wrote:
On 2021/2/18 8:43 下午, Si-Wei Liu wrote:
On 2/17/2021 8:44 PM, Jason Wang wrote:
On 2021/2/10 下午4:59, Si-Wei Liu wrote:
On 2/9/2021 7:53 PM, Jason Wang wrote:
On 2021/2/10 上午10:30, Si-Wei Liu wrote:
On 2/8/2021 10:37 PM, Jason Wang wrote:
On 2021/2/9 下午2:12, Eli Cohen wrote:
On Tue, Feb 09, 2021 at 11:20:14AM +0800, Jason Wang wrote:
On 2021/2/8 下午6:04, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 05:04:27PM +0800, Jason Wang wrote:
On 2021/2/8 下午2:37, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 12:27:18PM +0800, Jason Wang wrote:
On 2021/2/6 上午7:07, Si-Wei Liu wrote:
On 2/3/2021 11:36 PM, Eli Cohen wrote:
When a change of memory map occurs, the hardware
resources are destroyed
and then re-created again with the new memory map. In
such case, we need
to restore the hardware available and used indices. The
driver failed to
restore the used index which is added here.
Also, since the driver also fails to reset the
available and used
indices upon device reset, fix this here to avoid
regression caused by
the fact that used index may not be zero upon device
reset.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for
supported mlx5
devices")
Signed-off-by: Eli Cohen
---
v0 -> v1:
Clear indices upon device reset
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 88dde3455bfd..b5fe6d2ad22f 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct
mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtque
obj_context =
MLX5_ADDR_OF(create_virtio_net_q_in, in,
obj_context);
MLX5_SET(virtio_net_q_object, obj_context,
hw_available_index,
mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context,
hw_used_index,
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context,
queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object,
obj_context,
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct
mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtqueue *m
struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+ u16 used_index;
};
static int query_virtqueue(struct mlx5_vdpa_net
*ndev, struct
mlx5_vdpa_virtqueue *mvq,
@@ -1052,6 +1056,7 @@ static int query_virtqueue(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object,
obj_context, state);
attr->available_index =
MLX5_GET(virtio_net_q_object,
obj_context, hw_available_index);
+ attr->used_index = MLX5_GET(virtio_net_q_object,
obj_context,
hw_used_index);
kfree(out);
return 0;
@@ -1535,6 +1540,16 @@ static void
teardown_virtqueues(struct
mlx5_vdpa_net *ndev)
}
}
+static void clear_virtqueues(struct mlx5_vdpa_net
*ndev)
+{
+ int i;
+
+ for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
+ ndev->vqs[i].avail_idx = 0;
+ ndev->vqs[i].used_idx = 0;
+ }
+}
+
/* TODO: cross-endian support */
static inline bool
mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev
*mvdev)
{
@@ -1610,6 +1625,7 @@ static int save_channel_info(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu
return err;
ri->avail_index = attr.available_index;
+ ri->used_index = attr.used_index;
ri->ready = mvq->ready;
ri->num_ent = mvq->num_ent;
ri->desc_addr = mvq->desc_addr;
@@ -1654,6 +1670,7 @@ static void
restore_channels_info(struct
mlx5_vdpa_net *ndev)
continue;
mvq->avail_idx = ri->avail_index;
+ mvq->used_idx = ri->used_index;
mvq->ready = ri->ready;
mvq->num_ent = ri->num_ent;
mvq->desc_addr = ri->desc_addr;
@@ -1768,6 +1785,7 @@ static void
mlx5_vdpa_set_status(struct
vdpa_device *vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device
reset\n");
teardown_driver(ndev);
+ clear_virtqueues(ndev);
The clearing looks fine at the first glance, as it
aligns with the other
state cleanups floating around at the same place.
However, the thing is
get_vq_state() is supposed to be called right after to
get sync'ed with
the latest internal avail_
RE: [PATCH 2/4] iommu/vt-d: Enable write protect propagation from guest
> From: Jacob Pan
> Sent: Saturday, February 20, 2021 1:09 AM
>
> Hi Kevin,
>
> On Fri, 19 Feb 2021 06:19:04 +, "Tian, Kevin"
> wrote:
>
> > > From: Jacob Pan
> > > Sent: Friday, February 19, 2021 5:31 AM
> > >
> > > Write protect bit, when set, inhibits supervisor writes to the read-only
> > > pages. In guest supervisor shared virtual addressing (SVA),
> > > write-protect should be honored upon guest bind supervisor PASID
> > > request.
> > >
> > > This patch extends the VT-d portion of the IOMMU UAPI to include WP bit.
> > > WPE bit of the supervisor PASID entry will be set to match CPU CR0.WP
> > > bit.
> > >
> > > Signed-off-by: Sanjay Kumar
> > > Signed-off-by: Jacob Pan
> > > ---
> > > drivers/iommu/intel/pasid.c | 5 +
> > > include/uapi/linux/iommu.h | 3 ++-
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
> > > index 0b7e0e726ade..c7a2ec930af4 100644
> > > --- a/drivers/iommu/intel/pasid.c
> > > +++ b/drivers/iommu/intel/pasid.c
> > > @@ -763,6 +763,11 @@ intel_pasid_setup_bind_data(struct
> intel_iommu
> > > *iommu, struct pasid_entry *pte,
> > > return -EINVAL;
> > > }
> > > pasid_set_sre(pte);
> > > + /* Enable write protect WP if guest requested */
> > > + if (pasid_data->flags & IOMMU_SVA_VTD_GPASID_WPE) {
> > > + if (pasid_enable_wpe(pte))
> > > + return -EINVAL;
> >
> > We should call pasid_set_wpe directly, as this binding is about guest
> > page table and suppose the guest has done whatever check required
> > (e.g. gcr0.wp) before setting this bit. pasid_enable_wpe has an
> > additional check on host cr0.wp thus is logically incorrect here.
> >
> If the host CPU does not support WP, can guest VCPU still support WP? If
> so, I agree.
>
If you change 'support' to 'enable', then the answer is yes.
Re: [PATCH 4/4] iommu/vt-d: Calculate and set flags for handle_mm_fault
On 2/19/21 5:31 AM, Jacob Pan wrote:
Page requests are originated from the user page fault. Therefore, we
shall set FAULT_FLAG_USER.
FAULT_FLAG_REMOTE indicates that we are walking an mm which is not
guaranteed to be the same as the current->mm and should not be subject
to protection key enforcement. Therefore, we should set FAULT_FLAG_REMOTE
to avoid faults when both SVM and PKEY are used.
References: commit 1b2ee1266ea6 ("mm/core: Do not enforce PKEY permissions on remote
mm access")
Reviewed-by: Raj Ashok
Signed-off-by: Jacob Pan
Acked-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel/svm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index ff7ae7cc17d5..7bfd20a24a60 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1086,6 +1086,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
struct intel_iommu *iommu = d;
struct intel_svm *svm = NULL;
int head, tail, handled = 0;
+ unsigned int flags = 0;
/* Clear PPR bit before reading head/tail registers, to
* ensure that we get a new interrupt if needed. */
@@ -1186,9 +1187,11 @@ static irqreturn_t prq_event_thread(int irq, void *d)
if (access_error(vma, req))
goto invalid;
- ret = handle_mm_fault(vma, address,
- req->wr_req ? FAULT_FLAG_WRITE : 0,
- NULL);
+ flags = FAULT_FLAG_USER | FAULT_FLAG_REMOTE;
+ if (req->wr_req)
+ flags |= FAULT_FLAG_WRITE;
+
+ ret = handle_mm_fault(vma, address, flags, NULL);
if (ret & VM_FAULT_ERROR)
goto invalid;
Re: [PATCH net] tcp: fix keepalive when data remain undelivered
On Fri, Feb 19, 2021 at 4:54 PM Enke Chen wrote:
>
> From: Enke Chen
>
> TCP keepalive does not timeout under the condition that network connection
> is lost and data remain undelivered (incl. retransmit). A very simple
> scenarios of the failure is to write data to a tcp socket after the network
> connection is lost.
AFAIK current Linux TCP KA implementation does not violate the
RFC793bis (Section 3.7.4 Keep-Alives)
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-20#section-3.7.4
We have even raised that in IETF tcpm list to get more clarity
https://mailarchive.ietf.org/arch/msg/tcpm/KxcEsLtDuDNhcP8UjbyPkJqpzsE/
I believe you interpret the keep-alive differently -- so this is
arguably a subjective "bug-fix". As Neal and I have expressed in our
private communications, current Linux KA has been implemented for more
than a decade. Changing this behavior may break many existing
applications even if it may benefit certain.
>
> Under the specified condition the keepalive timeout is not evaluated in
> the keepalive timer. That is the primary cause of the failure. In addition,
> the keepalive probe is not sent out in the keepalive timer. Although packet
> retransmit or 0-window probe can serve a similar purpose, they have their
> own timers and backoffs that are generally not aligned with the keepalive
> parameters for probes and timeout.
>
> As the timing and conditions of the events involved are random, the tcp
> keepalive can fail randomly. Given the randomness of the failures, fixing
> the issue would not cause any backward compatibility issues. As was well
> said, "Determinism is a special case of randomness".
>
> The fix in this patch consists of the following:
>
> a. Always evaluate the keepalive timeout in the keepalive timer.
>
> b. Always send out the keepalive probe in the keepalive timer (post the
> keepalive idle time). Given that the keepalive intervals are usually
> in the range of 30 - 60 seconds, there is no need for an optimization
> to further reduce the number of keepalive probes in the presence of
> packet retransmit.
>
> c. Use the elapsed time (instead of the 0-window probe counter) in
> evaluating tcp keepalive timeout.
>
> Thanks to Eric Dumazet, Neal Cardwell, and Yuchung Cheng for helpful
> discussions about the issue and options for fixing it.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2 Initial git repository build")
> Signed-off-by: Enke Chen
> ---
> net/ipv4/tcp_timer.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index 4ef08079ccfa..16a044da20db 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -708,29 +708,23 @@ static void tcp_keepalive_timer (struct timer_list *t)
> ((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_SYN_SENT)))
> goto out;
>
> - elapsed = keepalive_time_when(tp);
> -
> - /* It is alive without keepalive 8) */
> - if (tp->packets_out || !tcp_write_queue_empty(sk))
> - goto resched;
> -
> elapsed = keepalive_time_elapsed(tp);
>
> if (elapsed >= keepalive_time_when(tp)) {
> /* If the TCP_USER_TIMEOUT option is enabled, use that
> * to determine when to timeout instead.
> */
> - if ((icsk->icsk_user_timeout != 0 &&
> - elapsed >= msecs_to_jiffies(icsk->icsk_user_timeout) &&
> - icsk->icsk_probes_out > 0) ||
> - (icsk->icsk_user_timeout == 0 &&
> - icsk->icsk_probes_out >= keepalive_probes(tp))) {
> + u32 timeout = icsk->icsk_user_timeout ?
> + msecs_to_jiffies(icsk->icsk_user_timeout) :
> + keepalive_intvl_when(tp) * keepalive_probes(tp) +
> + keepalive_time_when(tp);
> +
> + if (elapsed >= timeout) {
> tcp_send_active_reset(sk, GFP_ATOMIC);
> tcp_write_err(sk);
> goto out;
> }
> if (tcp_write_wakeup(sk, LINUX_MIB_TCPKEEPALIVE) <= 0) {
> - icsk->icsk_probes_out++;
> elapsed = keepalive_intvl_when(tp);
> } else {
> /* If keepalive was lost due to local congestion,
> @@ -744,8 +738,6 @@ static void tcp_keepalive_timer (struct timer_list *t)
> }
>
> sk_mem_reclaim(sk);
> -
> -resched:
> inet_csk_reset_keepalive_timer (sk, elapsed);
> goto out;
>
> --
> 2.29.2
>
Greetings My Dear Friend,
Greetings My Dear Friend, Before I introduce myself, I wish to inform you that this letter is not a hoax mail and I urge you to treat it serious.This letter must come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business partners. Please I want you to read this letter very carefully and I must apologize for barging this message into your mail box without any formal introduction due to the urgency and confidentiality of this business and I know that this message will come to you as a surprise. Please this is not a joke and I will not like you to joke with it ok,With due respect to your person and much sincerity of purpose, I make this contact with you as I believe that you can be of great assistance to me. My name is Mr.Abderazack zebdani, from Burkina Faso, West Africa. I work in Bank Of Africa (BOA) as telex manager, please see this as a confidential message and do not reveal it to another person and let me know whether you can be of assistance regarding my proposal below because it is top secret. I am about to retire from active Banking service to start a new life but I am skeptical to reveal this particular secret to a stranger. You must assure me that everything will be handled confidentially because we are not going to suffer again in life. It has been 10 years now that most of the greedy African Politicians used our bank to launder money overseas through the help of their Political advisers. Most of the funds which they transferred out of the shores of Africa were gold and oil money that was supposed to have been used to develop the continent. Their Political advisers always inflated the amounts before transferring to foreign accounts, so I also used the opportunity to divert part of the funds hence I am aware that there is no official trace of how much was transferred as all the accounts used for such transfers were being closed after transfer. I acted as the Bank Officer to most of the politicians and when I discovered that they were using me to succeed in their greedy act; I also cleaned some of their banking records from the Bank files and no one cared to ask me because the money was too much for them to control. They laundered over $5billion Dollars during the process. Before I send this message to you, I have already diverted ($10.5million Dollars) to an escrow account belonging to no one in the bank. The bank is anxious now to know who the beneficiary to the funds is because they have made a lot of profits with the funds. It is more than Eight years now and most of the politicians are no longer using our bank to transfer funds overseas. The ($10.5million Dollars) has been laying waste in our bank and I don’t want to retire from the bank without transferring the funds to a foreign account to enable me share the proceeds with the receiver (a foreigner). The money will be shared 60% for me and 40% for you. There is no one coming to ask you about the funds because I secured everything. I only want you to assist me by providing a reliable bank account where the funds can be transferred. You are not to face any difficulties or legal implications as I am going to handle the transfer personally. If you are capable of receiving the funds, do let me know immediately to enable me give you a detailed information on what to do. For me, I have not stolen the money from anyone because the other people that took the whole money did not face any problems. This is my chance to grab my own life opportunity but you must keep the details of the funds secret to avoid any leakages as no one in the bank knows about my plans.Please get back to me if you are interested and capable to handle this project, I shall intimate you on what to do when I hear from your confirmation and acceptance.If you are capable of being my trusted associate, do declare your consent to me I am looking forward to hear from you immediately for further information, KINDLY REPLY THIS EMAIL (abderazack.zebd...@hotmail.com) Thanks with my best regards. Mr.Abderazack zebdani. Telex Manager Bank Of Africa (BOA) Burkina Faso.
Re: [PATCH 3/4] iommu/vt-d: Reject unsupported page request modes
On 2/19/21 5:31 AM, Jacob Pan wrote:
When supervisor/privilige mode SVM is used, we bind init_mm.pgd with
a supervisor PASID. There should not be any page fault for init_mm.
Execution request with DMA read is also not supported.
This patch checks PRQ descriptor for both unsupported configurations,
reject them both with invalid responses.
Signed-off-by: Jacob Pan
Fixes: 1c4f88b7f1f92 ("iommu/vt-d: Shared virtual address in scalable mode")
Acked-by: Lu Baolu
Best regards,
baolu
---
drivers/iommu/intel/svm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 23a1e4f58c54..ff7ae7cc17d5 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -1113,7 +1113,17 @@ static irqreturn_t prq_event_thread(int irq, void *d)
((unsigned long long *)req)[1]);
goto no_pasid;
}
-
+ /* We shall not receive page request for supervisor SVM */
+ if (req->pm_req && (req->rd_req | req->wr_req)) {
+ pr_err("Unexpected page request in Privilege Mode");
+ /* No need to find the matching sdev as for bad_req */
+ goto no_pasid;
+ }
+ /* DMA read with exec requeset is not supported. */
+ if (req->exe_req && req->rd_req) {
+ pr_err("Execution request not supported\n");
+ goto no_pasid;
+ }
if (!svm || svm->pasid != req->pasid) {
rcu_read_lock();
svm = ioasid_find(NULL, req->pasid, NULL);
Re: [PATCH 7/9] pm: hibernate: Optionally use TPM-backed keys to protect image integrity
Hi-- On 2/19/21 5:32 PM, Matthew Garrett wrote: > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > index a7320f07689d..0279cc10f319 100644 > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -92,6 +92,21 @@ config HIBERNATION_SNAPSHOT_DEV > > If in doubt, say Y. > > +config SECURE_HIBERNATION > + bool "Implement secure hibernation support" > + depends on HIBERNATION && TCG_TPM > + select KEYS > + select TRUSTED_KEYS > + select CRYPTO > + select CRYPTO_SHA256 > + select CRYPTO_AES > + select TCG_TPM_RESTRICT_PCR > + help > + Use a TPM-backed key to securely determine whether a hibernation > + image was written out by the kernel and has not been tampered with. > + This requires a TCG-compliant TPM2 device, which is present on most > + modern hardware. Please follow coding-style for Kconfig files: from Documentation/process/coding-style.rst, section 10): For all of the Kconfig* configuration files throughout the source tree, the indentation is somewhat different. Lines under a ``config`` definition are indented with one tab, while help text is indented an additional two spaces. Also, one feature should not be responsible for enabling other "subsystems," such as KEYS and CRYPTO. They should instead be listed as dependencies. -- ~Randy
[PATCH 2/3] arm64: dts: qcom: sc7180: trogdor: Add labels to charger thermal zone and ADC channel
Some revisions of trogdor boards use a thermistor for the charger
temperature which currently isn't supported by the PM6150 ADC
driver. Add labels for the charger thermal zone and ADC channel
to allow the removal of these nodes from affected boards and
avoid the use of bogus temperature values.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 07c8b2c926c0..fa996387715b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -15,7 +15,7 @@
/ {
thermal-zones {
- charger-thermal {
+ charger_thermal: charger-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
@@ -706,7 +706,7 @@ &mdss {
};
&pm6150_adc {
- charger-thermistor@4f {
+ pm6150_adc_charger_thm: charger-thermistor@4f {
reg = ;
qcom,ratiometric;
qcom,hw-settle-time = <200>;
@@ -716,7 +716,7 @@ charger-thermistor@4f {
&pm6150_adc_tm {
status = "okay";
- charger-thermistor@1 {
+ pm6150_adc_tm_charger_thm: charger-thermistor@1 {
reg = <1>;
io-channels = <&pm6150_adc ADC5_AMUX_THM3_100K_PU>;
qcom,ratiometric;
--
2.30.0.617.g56c4b15f3c-goog
[PATCH 3/3] arm64: dts: qcom: sc7180: Delete charger thermal zone and ADC channel for lazor <= rev3
Lazor rev3 and older are stuffed with a 47k NTC as thermistor for
the charger temperature which currently isn't supported by the
PM6150 ADC driver. Delete the charger thermal zone and ADC channel
to avoid the use of bogus temperature values.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts | 9 +
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts | 9 +
arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts | 9 +
3 files changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
index 30e3e769d2b4..0974dbd424e1 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
@@ -14,6 +14,15 @@ / {
compatible = "google,lazor-rev0", "qcom,sc7180";
};
+/*
+ * rev <= 3 are stuffed with a 47k NTC as charger thermistor which is currently
+ * not supported by the PM6150 ADC driver. Delete the thermal zone and ADC
+ * channel to avoid the use of bogus temperature values.
+ */
+/delete-node/ &charger_thermal;
+/delete-node/ &pm6150_adc_charger_thm;
+/delete-node/ &pm6150_adc_tm_charger_thm;
+
&pp3300_hub {
/* pp3300_l7c is used to power the USB hub */
/delete-property/regulator-always-on;
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
index c2ef06367baf..0381ca85ae97 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
@@ -14,6 +14,15 @@ / {
compatible = "google,lazor-rev1", "google,lazor-rev2", "qcom,sc7180";
};
+/*
+ * rev <= 3 are stuffed with a 47k NTC as charger thermistor which is currently
+ * not supported by the PM6150 ADC driver. Delete the thermal zone and ADC
+ * channel to avoid the use of bogus temperature values.
+ */
+/delete-node/ &charger_thermal;
+/delete-node/ &pm6150_adc_charger_thm;
+/delete-node/ &pm6150_adc_tm_charger_thm;
+
&pp3300_hub {
/* pp3300_l7c is used to power the USB hub */
/delete-property/regulator-always-on;
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
index 240c3e067fac..b9473bba8f4a 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
@@ -13,3 +13,12 @@ / {
model = "Google Lazor (rev3)";
compatible = "google,lazor-rev3", "qcom,sc7180";
};
+
+/*
+ * rev <= 3 are stuffed with a 47k NTC as charger thermistor which is currently
+ * not supported by the PM6150 ADC driver. Delete the thermal zone and ADC
+ * channel to avoid the use of bogus temperature values.
+ */
+/delete-node/ &charger_thermal;
+/delete-node/ &pm6150_adc_charger_thm;
+/delete-node/ &pm6150_adc_tm_charger_thm;
--
2.30.0.617.g56c4b15f3c-goog
[PATCH 1/3] arm64: dts: qcom: sc7180: Add lazor rev4
Lazor rev3 and older are stuffed with a 47k NTC thermistor for the
charger temperature which currently isn't supported by the PM6150 ADC
driver. A supported thermistor is used in rev4 and later revisions.
Add rev4 .dts files to be able to account for this.
Signed-off-by: Matthias Kaehlcke
---
arch/arm64/boot/dts/qcom/Makefile | 3 ++
.../dts/qcom/sc7180-trogdor-lazor-r3-kb.dts | 4 +--
.../dts/qcom/sc7180-trogdor-lazor-r3-lte.dts | 4 +--
.../boot/dts/qcom/sc7180-trogdor-lazor-r3.dts | 4 +--
.../dts/qcom/sc7180-trogdor-lazor-r4-kb.dts | 20 +
.../dts/qcom/sc7180-trogdor-lazor-r4-lte.dts | 28 +++
.../boot/dts/qcom/sc7180-trogdor-lazor-r4.dts | 16 +++
7 files changed, 73 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-kb.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-lte.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 549a7a2151d4..8a8ebca07b25 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -38,6 +38,9 @@ dtb-$(CONFIG_ARCH_QCOM) +=
sc7180-trogdor-lazor-r1-lte.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r3.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r3-kb.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r3-lte.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r4.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r4-kb.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r4-lte.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-r1-lte.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-ganges-kirin.dtb
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts
index 6985beb97e53..a578326ffbad 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-kb.dts
@@ -8,8 +8,8 @@
#include "sc7180-trogdor-lazor-r3.dts"
/ {
- model = "Google Lazor (rev3+) with KB Backlight";
- compatible = "google,lazor-sku2", "qcom,sc7180";
+ model = "Google Lazor (rev3) with KB Backlight";
+ compatible = "google,lazor-rev3-sku2", "qcom,sc7180";
};
&keyboard_backlight {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
index 0881f8dd02c9..40169b4a48a3 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3-lte.dts
@@ -9,8 +9,8 @@
#include "sc7180-trogdor-lte-sku.dtsi"
/ {
- model = "Google Lazor (rev3+) with LTE";
- compatible = "google,lazor-sku0", "qcom,sc7180";
+ model = "Google Lazor (rev3) with LTE";
+ compatible = "google,lazor-rev3-sku0", "qcom,sc7180";
};
&ap_sar_sensor {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
index 1b9d2f46359e..240c3e067fac 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r3.dts
@@ -10,6 +10,6 @@
#include "sc7180-trogdor-lazor.dtsi"
/ {
- model = "Google Lazor (rev3+)";
- compatible = "google,lazor", "qcom,sc7180";
+ model = "Google Lazor (rev3)";
+ compatible = "google,lazor-rev3", "qcom,sc7180";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-kb.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-kb.dts
new file mode 100644
index ..e8c6d3745fed
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-kb.dts
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Lazor board device tree source
+ *
+ * Copyright 2021 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sc7180-trogdor-lazor.dtsi"
+#include "sc7180-lite.dtsi"
+
+/ {
+ model = "Google Lazor (rev4+) with KB Backlight";
+ compatible = "google,lazor-sku2", "qcom,sc7180";
+};
+
+&keyboard_backlight {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-lte.dts
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-lte.dts
new file mode 100644
index ..b260bcf85d4c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r4-lte.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Lazor board device tree source
+ *
+ * Copyright 2021 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sc7180-trogdor-lazor.dtsi"
+#include "sc7180-trogdor-lte-sku.dtsi"
+
+/ {
+ model = "Google Lazor (rev4+) with LTE";
+ compatible = "google,lazor-sku0", "qcom,sc7180";
+};
+
+&ap_sar_sensor {
+ status = "okay";
+};
+
+&ap_sar_sensor_i2c {
+ status
Re: [PATCH 1/4] iommu/vt-d: Enable write protect for supervisor SVM
Hi Jacob and Sanjay,
On 2/19/21 5:31 AM, Jacob Pan wrote:
Write protect bit, when set, inhibits supervisor writes to the read-only
pages. In supervisor shared virtual addressing (SVA), where page tables
are shared between CPU and DMA, IOMMU PASID entry WPE bit should match
CR0.WP bit in the CPU.
This patch sets WPE bit for supervisor PASIDs if CR0.WP is set.
From reading the commit message, the intention of this patch is to match
PASID entry WPE bith with CPU CR0.WP if 1) SRE is set (supervisor
pasid); 2) page table is shared between CPU and IOMMU. Do I understand
it right?
But what the real code doing is failing pasid entry setup for first
level translation if CPU CR0.WP is not set. It's not consistent with
what described above.
What I am thinking is that, as long as SRE is set, we should always set
WPE in intel_pasid_setup_first_level(). For supervisor SVA case, we
should check CPU CR0.WP in intel_svm_bind_mm() and abort binding if
CR0.WP is not set.
Thought?
Best regards,
baolu
Signed-off-by: Sanjay Kumar
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/pasid.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index 0cceaabc3ce6..0b7e0e726ade 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -410,6 +410,15 @@ static inline void pasid_set_sre(struct pasid_entry *pe)
pasid_set_bits(&pe->val[2], 1 << 0, 1);
}
+/*
+ * Setup the WPE(Write Protect Enable) field (Bit 132) of a
+ * scalable mode PASID entry.
+ */
+static inline void pasid_set_wpe(struct pasid_entry *pe)
+{
+ pasid_set_bits(&pe->val[2], 1 << 4, 1 << 4);
+}
+
/*
* Setup the P(Present) field (Bit 0) of a scalable mode PASID
* entry.
@@ -553,6 +562,20 @@ static void pasid_flush_caches(struct intel_iommu *iommu,
}
}
+static inline int pasid_enable_wpe(struct pasid_entry *pte)
+{
+ unsigned long cr0 = read_cr0();
+
+ /* CR0.WP is normally set but just to be sure */
+ if (unlikely(!(cr0 & X86_CR0_WP))) {
+ pr_err_ratelimited("No CPU write protect!\n");
+ return -EINVAL;
+ }
+ pasid_set_wpe(pte);
+
+ return 0;
+};
+
/*
* Set up the scalable mode pasid table entry for first only
* translation type.
@@ -584,6 +607,9 @@ int intel_pasid_setup_first_level(struct intel_iommu *iommu,
return -EINVAL;
}
pasid_set_sre(pte);
+ if (pasid_enable_wpe(pte))
+ return -EINVAL;
+
}
if (flags & PASID_FLAG_FL5LP) {
Re: [PATCH v1] vdpa/mlx5: Restore the hardware used index after change map
On 2/18/2021 7:10 PM, Jason Wang wrote:
On 2021/2/18 8:43 下午, Si-Wei Liu wrote:
On 2/17/2021 8:44 PM, Jason Wang wrote:
On 2021/2/10 下午4:59, Si-Wei Liu wrote:
On 2/9/2021 7:53 PM, Jason Wang wrote:
On 2021/2/10 上午10:30, Si-Wei Liu wrote:
On 2/8/2021 10:37 PM, Jason Wang wrote:
On 2021/2/9 下午2:12, Eli Cohen wrote:
On Tue, Feb 09, 2021 at 11:20:14AM +0800, Jason Wang wrote:
On 2021/2/8 下午6:04, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 05:04:27PM +0800, Jason Wang wrote:
On 2021/2/8 下午2:37, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 12:27:18PM +0800, Jason Wang wrote:
On 2021/2/6 上午7:07, Si-Wei Liu wrote:
On 2/3/2021 11:36 PM, Eli Cohen wrote:
When a change of memory map occurs, the hardware
resources are destroyed
and then re-created again with the new memory map. In
such case, we need
to restore the hardware available and used indices. The
driver failed to
restore the used index which is added here.
Also, since the driver also fails to reset the available
and used
indices upon device reset, fix this here to avoid
regression caused by
the fact that used index may not be zero upon device reset.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for
supported mlx5
devices")
Signed-off-by: Eli Cohen
---
v0 -> v1:
Clear indices upon device reset
drivers/vdpa/mlx5/net/mlx5_vnet.c | 18
++
1 file changed, 18 insertions(+)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 88dde3455bfd..b5fe6d2ad22f 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -87,6 +87,7 @@ struct mlx5_vq_restore_info {
u64 device_addr;
u64 driver_addr;
u16 avail_index;
+ u16 used_index;
bool ready;
struct vdpa_callback cb;
bool restore;
@@ -121,6 +122,7 @@ struct mlx5_vdpa_virtqueue {
u32 virtq_id;
struct mlx5_vdpa_net *ndev;
u16 avail_idx;
+ u16 used_idx;
int fw_state;
/* keep last in the struct */
@@ -804,6 +806,7 @@ static int create_virtqueue(struct
mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtque
obj_context =
MLX5_ADDR_OF(create_virtio_net_q_in, in,
obj_context);
MLX5_SET(virtio_net_q_object, obj_context,
hw_available_index,
mvq->avail_idx);
+ MLX5_SET(virtio_net_q_object, obj_context,
hw_used_index,
mvq->used_idx);
MLX5_SET(virtio_net_q_object, obj_context,
queue_feature_bit_mask_12_3,
get_features_12_3(ndev->mvdev.actual_features));
vq_ctx = MLX5_ADDR_OF(virtio_net_q_object,
obj_context,
virtio_q_context);
@@ -1022,6 +1025,7 @@ static int connect_qps(struct
mlx5_vdpa_net
*ndev, struct mlx5_vdpa_virtqueue *m
struct mlx5_virtq_attr {
u8 state;
u16 available_index;
+ u16 used_index;
};
static int query_virtqueue(struct mlx5_vdpa_net
*ndev, struct
mlx5_vdpa_virtqueue *mvq,
@@ -1052,6 +1056,7 @@ static int query_virtqueue(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqueu
memset(attr, 0, sizeof(*attr));
attr->state = MLX5_GET(virtio_net_q_object,
obj_context, state);
attr->available_index =
MLX5_GET(virtio_net_q_object,
obj_context, hw_available_index);
+ attr->used_index = MLX5_GET(virtio_net_q_object,
obj_context,
hw_used_index);
kfree(out);
return 0;
@@ -1535,6 +1540,16 @@ static void
teardown_virtqueues(struct
mlx5_vdpa_net *ndev)
}
}
+static void clear_virtqueues(struct mlx5_vdpa_net
*ndev)
+{
+ int i;
+
+ for (i = ndev->mvdev.max_vqs - 1; i >= 0; i--) {
+ ndev->vqs[i].avail_idx = 0;
+ ndev->vqs[i].used_idx = 0;
+ }
+}
+
/* TODO: cross-endian support */
static inline bool
mlx5_vdpa_is_little_endian(struct mlx5_vdpa_dev
*mvdev)
{
@@ -1610,6 +1625,7 @@ static int save_channel_info(struct
mlx5_vdpa_net *ndev, struct mlx5_vdpa_virtqu
return err;
ri->avail_index = attr.available_index;
+ ri->used_index = attr.used_index;
ri->ready = mvq->ready;
ri->num_ent = mvq->num_ent;
ri->desc_addr = mvq->desc_addr;
@@ -1654,6 +1670,7 @@ static void
restore_channels_info(struct
mlx5_vdpa_net *ndev)
continue;
mvq->avail_idx = ri->avail_index;
+ mvq->used_idx = ri->used_index;
mvq->ready = ri->ready;
mvq->num_ent = ri->num_ent;
mvq->desc_addr = ri->desc_addr;
@@ -1768,6 +1785,7 @@ static void
mlx5_vdpa_set_status(struct
vdpa_device *vdev, u8 status)
if (!status) {
mlx5_vdpa_info(mvdev, "performing device
reset\n");
teardown_driver(ndev);
+ clear_virtqueues(ndev);
The clearing looks fine at the first glance, as it aligns
with the other
state cleanups floating around at the same place.
However, the thing is
get_vq_state() is supposed to be called right after to
get sync'ed with
the latest internal avail_index from device w
[RFC PATCH v5 2/4] block: add simple copy support
Add new BLKCOPY ioctl that offloads copying of one or more sources
ranges to a destination in the device. Accepts a 'copy_range' structure
that contains destination (in sectors), no of sources and pointer to the
array of source ranges. Each source range is represented by 'range_entry'
that contains start and length of source ranges (in sectors).
Introduce REQ_OP_COPY, a no-merge copy offload operation. Create
bio with control information as payload and submit to the device.
REQ_OP_COPY(19) is a write op and takes zone_write_lock when submitted
to zoned device.
If the device doesn't support copy or copy offload is disabled, then
copy operation is emulated by default. However, the copy-emulation is an
opt-in feature. Caller can choose not to use the copy-emulation by
specifying a flag 'BLKDEV_COPY_NOEMULATION'.
Copy-emulation is implemented by allocating memory of total copy size.
The source ranges are read into memory by chaining bio for each source
ranges and submitting them async and the last bio waits for completion.
After data is read, it is written to the destination.
bio_map_kern() is used to allocate bio and add pages of copy buffer to
bio. As bio->bi_private and bio->bi_end_io are needed for chaining the
bio and gets over-written, invalidate_kernel_vmap_range() for read is
called in the caller.
Introduce queue limits for simple copy and other helper functions.
Add device limits as sysfs entries.
- copy_offload
- max_copy_sectors
- max_copy_ranges_sectors
- max_copy_nr_ranges
copy_offload(= 0) is disabled by default. This needs to be enabled if
copy-offload needs to be used.
max_copy_sectors = 0 indicates the device doesn't support native copy.
Native copy offload is not supported for stacked devices and is done via
copy emulation.
Signed-off-by: SelvaKumar S
Signed-off-by: Kanchan Joshi
Signed-off-by: Nitesh Shetty
Signed-off-by: Javier González
Signed-off-by: Chaitanya Kulkarni
---
block/blk-core.c | 102 --
block/blk-lib.c | 222 ++
block/blk-merge.c | 2 +
block/blk-settings.c | 10 ++
block/blk-sysfs.c | 47
block/blk-zoned.c | 1 +
block/bounce.c| 1 +
block/ioctl.c | 33 ++
include/linux/bio.h | 1 +
include/linux/blk_types.h | 14 +++
include/linux/blkdev.h| 15 +++
include/uapi/linux/fs.h | 13 +++
12 files changed, 453 insertions(+), 8 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 7663a9b94b80..23e646e5ae43 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -720,6 +720,17 @@ static noinline int should_fail_bio(struct bio *bio)
}
ALLOW_ERROR_INJECTION(should_fail_bio, ERRNO);
+static inline int bio_check_copy_eod(struct bio *bio, sector_t start,
+ sector_t nr_sectors, sector_t max_sect)
+{
+ if (nr_sectors && max_sect &&
+ (nr_sectors > max_sect || start > max_sect - nr_sectors)) {
+ handle_bad_sector(bio, max_sect);
+ return -EIO;
+ }
+ return 0;
+}
+
/*
* Check whether this bio extends beyond the end of the device or partition.
* This may well happen - the kernel calls bread() without checking the size of
@@ -738,6 +749,75 @@ static inline int bio_check_eod(struct bio *bio, sector_t
maxsector)
return 0;
}
+/*
+ * Check for copy limits and remap source ranges if needed.
+ */
+static int blk_check_copy(struct bio *bio)
+{
+ struct blk_copy_payload *payload = bio_data(bio);
+ struct request_queue *q = bio->bi_disk->queue;
+ sector_t max_sect, start_sect, copy_size = 0;
+ sector_t src_max_sect, src_start_sect;
+ struct block_device *bd_part;
+ int i, ret = -EIO;
+
+ rcu_read_lock();
+
+ bd_part = __disk_get_part(bio->bi_disk, bio->bi_partno);
+ if (unlikely(!bd_part)) {
+ rcu_read_unlock();
+ goto out;
+ }
+
+ max_sect = bdev_nr_sectors(bd_part);
+ start_sect = bd_part->bd_start_sect;
+
+ src_max_sect = bdev_nr_sectors(payload->src_bdev);
+ src_start_sect = payload->src_bdev->bd_start_sect;
+
+ if (unlikely(should_fail_request(bd_part, bio->bi_iter.bi_size)))
+ goto out;
+
+ if (unlikely(bio_check_ro(bio, bd_part)))
+ goto out;
+
+ rcu_read_unlock();
+
+ /* cannot handle copy crossing nr_ranges limit */
+ if (payload->copy_nr_ranges > q->limits.max_copy_nr_ranges)
+ goto out;
+
+ for (i = 0; i < payload->copy_nr_ranges; i++) {
+ ret = bio_check_copy_eod(bio, payload->range[i].src,
+ payload->range[i].len, src_max_sect);
+ if (unlikely(ret))
+ goto out;
+
+ /* single source range length limit */
+ if (payload->range[i].len > q->limits.max_copy_range_sectors)
+
[RFC PATCH v5 3/4] nvme: add simple copy support
Add support for TP 4065a ("Simple Copy Command"), v2020.05.04
("Ratified")
For device supporting native simple copy, this implementation accepts
the payload passed from the block layer and convert payload to form
simple copy command and submit to the device.
Set the device copy limits to queue limits. By default copy_offload
is disabled.
End-to-end protection is done by setting both PRINFOR and PRINFOW
to 0.
Signed-off-by: SelvaKumar S
Signed-off-by: Kanchan Joshi
Signed-off-by: Nitesh Shetty
Signed-off-by: Javier González
---
drivers/nvme/host/core.c | 87
include/linux/nvme.h | 43 ++--
2 files changed, 127 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index f13eb4ded95f..ba4de2f36cd5 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -706,6 +706,63 @@ static inline void nvme_setup_flush(struct nvme_ns *ns,
cmnd->common.nsid = cpu_to_le32(ns->head->ns_id);
}
+static inline blk_status_t nvme_setup_copy(struct nvme_ns *ns,
+ struct request *req, struct nvme_command *cmnd)
+{
+ struct nvme_ctrl *ctrl = ns->ctrl;
+ struct nvme_copy_range *range = NULL;
+ struct blk_copy_payload *payload;
+ unsigned short nr_range = 0;
+ u16 control = 0, ssrl;
+ u32 dsmgmt = 0;
+ u64 slba;
+ int i;
+
+ payload = bio_data(req->bio);
+ nr_range = payload->copy_nr_ranges;
+
+ if (req->cmd_flags & REQ_FUA)
+ control |= NVME_RW_FUA;
+
+ if (req->cmd_flags & REQ_FAILFAST_DEV)
+ control |= NVME_RW_LR;
+
+ cmnd->copy.opcode = nvme_cmd_copy;
+ cmnd->copy.nsid = cpu_to_le32(ns->head->ns_id);
+ cmnd->copy.sdlba = cpu_to_le64(blk_rq_pos(req) >> (ns->lba_shift - 9));
+
+ range = kmalloc_array(nr_range, sizeof(*range),
+ GFP_ATOMIC | __GFP_NOWARN);
+ if (!range)
+ return BLK_STS_RESOURCE;
+
+ for (i = 0; i < nr_range; i++) {
+ slba = payload->range[i].src;
+ slba = slba >> (ns->lba_shift - 9);
+
+ ssrl = payload->range[i].len;
+ ssrl = ssrl >> (ns->lba_shift - 9);
+
+ range[i].slba = cpu_to_le64(slba);
+ range[i].nlb = cpu_to_le16(ssrl - 1);
+ }
+
+ cmnd->copy.nr_range = nr_range - 1;
+
+ req->special_vec.bv_page = virt_to_page(range);
+ req->special_vec.bv_offset = offset_in_page(range);
+ req->special_vec.bv_len = sizeof(*range) * nr_range;
+ req->rq_flags |= RQF_SPECIAL_PAYLOAD;
+
+ if (ctrl->nr_streams)
+ nvme_assign_write_stream(ctrl, req, &control, &dsmgmt);
+
+ cmnd->rw.control = cpu_to_le16(control);
+ cmnd->rw.dsmgmt = cpu_to_le32(dsmgmt);
+
+ return BLK_STS_OK;
+}
+
static blk_status_t nvme_setup_discard(struct nvme_ns *ns, struct request *req,
struct nvme_command *cmnd)
{
@@ -888,6 +945,9 @@ blk_status_t nvme_setup_cmd(struct nvme_ns *ns, struct
request *req,
case REQ_OP_DISCARD:
ret = nvme_setup_discard(ns, req, cmd);
break;
+ case REQ_OP_COPY:
+ ret = nvme_setup_copy(ns, req, cmd);
+ break;
case REQ_OP_READ:
ret = nvme_setup_rw(ns, req, cmd, nvme_cmd_read);
break;
@@ -1928,6 +1988,31 @@ static void nvme_config_discard(struct gendisk *disk,
struct nvme_ns *ns)
blk_queue_max_write_zeroes_sectors(queue, UINT_MAX);
}
+static void nvme_config_copy(struct gendisk *disk, struct nvme_ns *ns,
+ struct nvme_id_ns *id)
+{
+ struct nvme_ctrl *ctrl = ns->ctrl;
+ struct request_queue *queue = disk->queue;
+
+ if (!(ctrl->oncs & NVME_CTRL_ONCS_COPY)) {
+ queue->limits.copy_offload = 0;
+ queue->limits.max_copy_sectors = 0;
+ queue->limits.max_copy_range_sectors = 0;
+ queue->limits.max_copy_nr_ranges = 0;
+ blk_queue_flag_clear(QUEUE_FLAG_SIMPLE_COPY, queue);
+ return;
+ }
+
+ /* setting copy limits */
+ blk_queue_flag_test_and_set(QUEUE_FLAG_SIMPLE_COPY, queue);
+ queue->limits.copy_offload = 0;
+ queue->limits.max_copy_sectors = le64_to_cpu(id->mcl) *
+ (1 << (ns->lba_shift - 9));
+ queue->limits.max_copy_range_sectors = le32_to_cpu(id->mssrl) *
+ (1 << (ns->lba_shift - 9));
+ queue->limits.max_copy_nr_ranges = id->msrc + 1;
+}
+
static void nvme_config_write_zeroes(struct gendisk *disk, struct nvme_ns *ns)
{
u64 max_blocks;
@@ -2123,6 +2208,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
set_capacity_and_notify(disk, capacity);
nvme_config_discard(disk, ns);
+ nvme_config_copy(disk, ns, id);
nvme_config_write_zeroes(disk, ns);
if ((i
[RFC PATCH v5 4/4] dm kcopyd: add simple copy offload support
Introduce copy_jobs to use copy-offload if it is natively
supported (by underlying device) or else fall back to original method.
run_copy_jobs() calls block layer copy offload api with
BLKDEV_COPY_NOEMULATION. On successful completion, if only one destination
device was present, then jobs is queued for completion. If multiple
destinations were present, the completed destination is zeroed and
pushed to pages_jobs to process copy offload for other destinations. In
case of copy_offload failure, remaining destinations are processed via
regular copying mechanism.
Signed-off-by: SelvaKumar S
---
drivers/md/dm-kcopyd.c | 49 --
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm-kcopyd.c b/drivers/md/dm-kcopyd.c
index 1bbe4a34ef4c..2442c4870e97 100644
--- a/drivers/md/dm-kcopyd.c
+++ b/drivers/md/dm-kcopyd.c
@@ -74,18 +74,20 @@ struct dm_kcopyd_client {
atomic_t nr_jobs;
/*
- * We maintain four lists of jobs:
+ * We maintain five lists of jobs:
*
- * i) jobs waiting for pages
- * ii) jobs that have pages, and are waiting for the io to be issued.
- * iii) jobs that don't need to do any IO and just run a callback
- * iv) jobs that have completed.
+ * i) jobs waiting to try copy offload
+ * ii) jobs waiting for pages
+ * iii) jobs that have pages, and are waiting for the io to be issued.
+ * iv) jobs that don't need to do any IO and just run a callback
+ * v) jobs that have completed.
*
- * All four of these are protected by job_lock.
+ * All five of these are protected by job_lock.
*/
spinlock_t job_lock;
struct list_head callback_jobs;
struct list_head complete_jobs;
+ struct list_head copy_jobs;
struct list_head io_jobs;
struct list_head pages_jobs;
};
@@ -581,6 +583,36 @@ static int run_io_job(struct kcopyd_job *job)
return r;
}
+static int run_copy_job(struct kcopyd_job *job)
+{
+ int r, i, count = 0;
+ unsigned long flags = 0;
+ struct range_entry srange;
+
+ flags |= BLKDEV_COPY_NOEMULATION;
+ for (i = 0; i < job->num_dests; i++) {
+ srange.src = job->source.sector;
+ srange.len = job->source.count;
+
+ r = blkdev_issue_copy(job->source.bdev, 1, &srange,
+ job->dests[i].bdev, job->dests[i].sector, GFP_KERNEL,
flags);
+ if (r)
+ break;
+
+ job->dests[i].count = 0;
+ count++;
+ }
+
+ if (count == job->num_dests) {
+ push(&job->kc->complete_jobs, job);
+ } else {
+ push(&job->kc->pages_jobs, job);
+ r = 0;
+ }
+
+ return r;
+}
+
static int run_pages_job(struct kcopyd_job *job)
{
int r;
@@ -662,6 +694,7 @@ static void do_work(struct work_struct *work)
spin_unlock_irqrestore(&kc->job_lock, flags);
blk_start_plug(&plug);
+ process_jobs(&kc->copy_jobs, kc, run_copy_job);
process_jobs(&kc->complete_jobs, kc, run_complete_job);
process_jobs(&kc->pages_jobs, kc, run_pages_job);
process_jobs(&kc->io_jobs, kc, run_io_job);
@@ -679,6 +712,8 @@ static void dispatch_job(struct kcopyd_job *job)
atomic_inc(&kc->nr_jobs);
if (unlikely(!job->source.count))
push(&kc->callback_jobs, job);
+ else if (job->source.bdev->bd_disk == job->dests[0].bdev->bd_disk)
+ push(&kc->copy_jobs, job);
else if (job->pages == &zero_page_list)
push(&kc->io_jobs, job);
else
@@ -919,6 +954,7 @@ struct dm_kcopyd_client *dm_kcopyd_client_create(struct
dm_kcopyd_throttle *thro
spin_lock_init(&kc->job_lock);
INIT_LIST_HEAD(&kc->callback_jobs);
INIT_LIST_HEAD(&kc->complete_jobs);
+ INIT_LIST_HEAD(&kc->copy_jobs);
INIT_LIST_HEAD(&kc->io_jobs);
INIT_LIST_HEAD(&kc->pages_jobs);
kc->throttle = throttle;
@@ -974,6 +1010,7 @@ void dm_kcopyd_client_destroy(struct dm_kcopyd_client *kc)
BUG_ON(!list_empty(&kc->callback_jobs));
BUG_ON(!list_empty(&kc->complete_jobs));
+ BUG_ON(!list_empty(&kc->copy_jobs));
BUG_ON(!list_empty(&kc->io_jobs));
BUG_ON(!list_empty(&kc->pages_jobs));
destroy_workqueue(kc->kcopyd_wq);
--
2.25.1
[RFC PATCH v5 1/4] block: make bio_map_kern() non static
Make bio_map_kern() non static, so that copy offload emulation can use
it to add vmalloced memory to bio.
Signed-off-by: SelvaKumar S
Signed-off-by: Chaitanya Kulkarni
---
block/blk-map.c| 2 +-
include/linux/blkdev.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index 21630dccac62..17381b1643b8 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -378,7 +378,7 @@ static void bio_map_kern_endio(struct bio *bio)
* Map the kernel address into a bio suitable for io to a block
* device. Returns an error pointer in case of error.
*/
-static struct bio *bio_map_kern(struct request_queue *q, void *data,
+struct bio *bio_map_kern(struct request_queue *q, void *data,
unsigned int len, gfp_t gfp_mask)
{
unsigned long kaddr = (unsigned long)data;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index f94ee3089e01..699ace6b25ff 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -944,6 +944,8 @@ extern int blk_rq_map_user(struct request_queue *, struct
request *,
struct rq_map_data *, void __user *, unsigned long,
gfp_t);
extern int blk_rq_unmap_user(struct bio *);
+struct bio *bio_map_kern(struct request_queue *q, void *data, unsigned int len,
+ gfp_t gfp_mask);
extern int blk_rq_map_kern(struct request_queue *, struct request *, void *,
unsigned int, gfp_t);
extern int blk_rq_map_user_iov(struct request_queue *, struct request *,
struct rq_map_data *, const struct iov_iter *,
--
2.25.1
[RFC PATCH v5 0/4] add simple copy support
This patchset tries to add support for TP4065a ("Simple Copy Command"),
v2020.05.04 ("Ratified")
The Specification can be found in following link.
https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
Simple copy command is a copy offloading operation and is used to copy
multiple contiguous ranges (source_ranges) of LBA's to a single destination
LBA within the device reducing traffic between host and device.
This implementation doesn't add native copy offload support for stacked
devices rather copy offload is done through emulation. Possible use
cases are F2FS gc and BTRFS relocation/balance.
*blkdev_issue_copy* takes source bdev, no of sources, array of source
ranges (in sectors), destination bdev and destination offset(in sectors).
If both source and destination block devices are same and copy_offload = 1,
then copy is done through native copy offloading. Copy emulation is used
in other cases.
As SCSI XCOPY can take two different block devices and no of source range is
equal to 1, this interface can be extended in future to support SCSI XCOPY.
For devices supporting native simple copy, attach the control information
as payload to the bio and submit to the device. For devices without native
copy support, copy emulation is done by reading each source range into memory
and writing it to the destination. Caller can choose not to try
emulation if copy offload is not supported by setting
BLKDEV_COPY_NOEMULATION flag.
Following limits are added to queue limits and are exposed in sysfs
to userspace
- *copy_offload* controls copy_offload. set 0 to disable copy
offload, 1 to enable native copy offloading support.
- *max_copy_sectors* limits the sum of all source_range length
- *max_copy_nr_ranges* limits the number of source ranges
- *max_copy_range_sectors* limit the maximum number of sectors
that can constitute a single source range.
max_copy_sectors = 0 indicates the device doesn't support copy
offloading.
*copy offload* sysfs entry is configurable and can be used toggle
between emulation and native support depending upon the usecase.
Changes from v4
1. Extend dm-kcopyd to leverage copy-offload, while copying within the
same device. The other approach was to have copy-emulation by moving
dm-kcopyd to block layer. But it also required moving core dm-io infra,
causing a massive churn across multiple dm-targets.
2. Remove export in bio_map_kern()
3. Change copy_offload sysfs to accept 0 or else
4. Rename copy support flag to QUEUE_FLAG_SIMPLE_COPY
5. Rename payload entries, add source bdev field to be used while
partition remapping, remove copy_size
6. Change the blkdev_issue_copy() interface to accept destination and
source values in sector rather in bytes
7. Add payload to bio using bio_map_kern() for copy_offload case
8. Add check to return error if one of the source range length is 0
9. Add BLKDEV_COPY_NOEMULATION flag to allow user to not try copy
emulation incase of copy offload is not supported. Caller can his use
his existing copying logic to complete the io.
10. Bug fix copy checks and reduce size of rcu_lock()
Planned for next:
- adding blktests
- handling larger (than device limits) copy
- decide on ioctl interface (man-page etc.)
Changes from v3
1. gfp_flag fixes.
2. Export bio_map_kern() and use it to allocate and add pages to bio.
3. Move copy offload, reading to buf, writing from buf to separate functions.
4. Send read bio of copy offload by chaining them and submit asynchronously.
5. Add gendisk->part0 and part->bd_start_sect changes to blk_check_copy().
6. Move single source range limit check to blk_check_copy()
7. Rename __blkdev_issue_copy() to blkdev_issue_copy and remove old helper.
8. Change blkdev_issue_copy() interface generic to accepts destination bdev
to support XCOPY as well.
9. Add invalidate_kernel_vmap_range() after reading data for vmalloc'ed memory.
10. Fix buf allocoation logic to allocate buffer for the total size of copy.
11. Reword patch commit description.
Changes from v2
1. Add emulation support for devices not supporting copy.
2. Add *copy_offload* sysfs entry to enable and disable copy_offload
in devices supporting simple copy.
3. Remove simple copy support for stacked devices.
Changes from v1:
1. Fix memory leak in __blkdev_issue_copy
2. Unmark blk_check_copy inline
3. Fix line break in blk_check_copy_eod
4. Remove p checks and made code more readable
5. Don't use bio_set_op_attrs and remove op and set
bi_opf directly
6. Use struct_size to calculate total_size
7. Fix partition remap of copy destination
8. Remove mcl,mssrl,msrc from nvme_ns
9. Initialize copy queue limits to 0 in nvme_config_copy
10. Remove return in QUEUE_FLAG_COPY check
11. Remove unused OCFS
SelvaKumar S (4):
block: make bio_map_kern() non static
block: add simple copy support
nvme: add simple copy support
dm kcopyd: add simple copy offload support
block
Re: [f2fs-dev] [PATCH] f2fs/checkpoint: fix a spacing coding style
On 2021/2/19 20:46, jiahao wrote: Add a space before the plus. Signed-off-by: jiahao Reviewed-by: Chao Yu Thanks,
Re: [PATCH] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN
On 2021/2/19 6:13 下午, Christoph Hellwig wrote: On Fri, Feb 19, 2021 at 03:45:09AM -0500, Jason Wang wrote: We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a lot of confusion. E.g it may break various default configs which want virtio devices. So this patch fixes this by hide the prompot and document the dependency. Is there any good reason to keep the symbol at all? The plan is to convert IFCVF driver to use this module (select it). Thanks
Re: [PATCH v5 3/3] bus: mhi: core: Process execution environment changes serially
Hi Bhaumik,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.11 next-20210219]
[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/Bhaumik-Bhatt/Serialize-execution-environment-changes-for-MHI/20210220-071426
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
f40ddce88593482919761f74910f42f4b84c004b
config: mips-randconfig-r033-20210219 (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/e38872b38ede9c5c1706cd11bf5792f8dc436fcf
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Bhaumik-Bhatt/Serialize-execution-environment-changes-for-MHI/20210220-071426
git checkout e38872b38ede9c5c1706cd11bf5792f8dc436fcf
# 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 warnings (new ones prefixed by >>):
drivers/bus/mhi/core/main.c: In function 'mhi_intvec_threaded_handler':
>> drivers/bus/mhi/core/main.c:436:17: warning: this statement may fall through
>> [-Wimplicit-fallthrough=]
436 | mhi_cntrl->ee = ee;
| ~~^~~~
drivers/bus/mhi/core/main.c:438:2: note: here
438 | default:
| ^~~
vim +436 drivers/bus/mhi/core/main.c
392
393 irqreturn_t mhi_intvec_threaded_handler(int irq_number, void *priv)
394 {
395 struct mhi_controller *mhi_cntrl = priv;
396 struct device *dev = &mhi_cntrl->mhi_dev->dev;
397 enum mhi_state state = MHI_STATE_MAX;
398 enum mhi_pm_state pm_state = 0;
399 enum mhi_ee_type ee = MHI_EE_MAX;
400
401 write_lock_irq(&mhi_cntrl->pm_lock);
402 if (!MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
403 write_unlock_irq(&mhi_cntrl->pm_lock);
404 goto exit_intvec;
405 }
406
407 state = mhi_get_mhi_state(mhi_cntrl);
408 ee = mhi_get_exec_env(mhi_cntrl);
409 dev_dbg(dev, "local ee:%s device ee:%s dev_state:%s\n",
410 TO_MHI_EXEC_STR(mhi_cntrl->ee), TO_MHI_EXEC_STR(ee),
411 TO_MHI_STATE_STR(state));
412
413 if (state == MHI_STATE_SYS_ERR) {
414 dev_dbg(dev, "System error detected\n");
415 pm_state = mhi_tryset_pm_state(mhi_cntrl,
416 MHI_PM_SYS_ERR_DETECT);
417 }
418 write_unlock_irq(&mhi_cntrl->pm_lock);
419
420 if (pm_state != MHI_PM_SYS_ERR_DETECT || ee == mhi_cntrl->ee)
421 goto exit_intvec;
422
423 switch (ee) {
424 case MHI_EE_RDDM:
425 /* proceed if power down is not already in progress */
426 if (mhi_cntrl->rddm_image && mhi_is_active(mhi_cntrl)) {
427 mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_EE_RDDM);
428 mhi_cntrl->ee = ee;
429 wake_up_all(&mhi_cntrl->state_event);
430 }
431 break;
432 case MHI_EE_PBL:
433 case MHI_EE_EDL:
434 case MHI_EE_PTHRU:
435 mhi_cntrl->status_cb(mhi_cntrl, MHI_CB_FATAL_ERROR);
> 436 mhi_cntrl->ee = ee;
437 /* continue */
438 default:
439 mhi_pm_sys_err_handler(mhi_cntrl);
440 wake_up_all(&mhi_cntrl->state_event);
441 break;
442 }
443
444 exit_intvec:
445
446 return IRQ_HANDLED;
447 }
448
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH 9/9] pm: hibernate: seal the encryption key with a PCR policy
The key blob is not secret, and by default the TPM will happily unseal
it regardless of system state. We can protect against that by sealing
the secret with a PCR policy - if the current PCR state doesn't match,
the TPM will refuse to release the secret. For now let's just seal it to
PCR 23. In the long term we may want a more flexible policy around this,
such as including PCR 7.
Signed-off-by: Matthew Garrett
---
include/linux/tpm.h | 4 ++
kernel/power/tpm.c | 161 ++--
2 files changed, 160 insertions(+), 5 deletions(-)
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index f6970986b097..2e0141978c87 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -225,18 +225,22 @@ enum tpm2_command_codes {
TPM2_CC_CONTEXT_LOAD= 0x0161,
TPM2_CC_CONTEXT_SAVE= 0x0162,
TPM2_CC_FLUSH_CONTEXT = 0x0165,
+ TPM2_CC_START_AUTH_SESSION = 0x0176,
TPM2_CC_VERIFY_SIGNATURE= 0x0177,
TPM2_CC_GET_CAPABILITY = 0x017A,
TPM2_CC_GET_RANDOM = 0x017B,
TPM2_CC_PCR_READ= 0x017E,
+ TPM2_CC_POLICY_PCR = 0x017F,
TPM2_CC_PCR_EXTEND = 0x0182,
TPM2_CC_EVENT_SEQUENCE_COMPLETE = 0x0185,
TPM2_CC_HASH_SEQUENCE_START = 0x0186,
+ TPM2_CC_POLICY_GET_DIGEST = 0x0189,
TPM2_CC_CREATE_LOADED = 0x0191,
TPM2_CC_LAST= 0x0193, /* Spec 1.36 */
};
enum tpm2_permanent_handles {
+ TPM2_RH_NULL= 0x4007,
TPM2_RS_PW = 0x4009,
};
diff --git a/kernel/power/tpm.c b/kernel/power/tpm.c
index 34e6cfb98ce4..5de27c2f08be 100644
--- a/kernel/power/tpm.c
+++ b/kernel/power/tpm.c
@@ -125,6 +125,118 @@ static int swsusp_enc_dec(struct trusted_key_payload
*payload, char *buf,
return ret;
}
+static int tpm_setup_policy(struct tpm_chip *chip, int *session_handle)
+{
+ struct tpm_header *head;
+ struct tpm_buf buf;
+ char nonce[32] = {0x00};
+ int rc;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS,
+ TPM2_CC_START_AUTH_SESSION);
+ if (rc)
+ return rc;
+
+ /* Decrypt key */
+ tpm_buf_append_u32(&buf, TPM2_RH_NULL);
+
+ /* Auth entity */
+ tpm_buf_append_u32(&buf, TPM2_RH_NULL);
+
+ /* Nonce - blank is fine here */
+ tpm_buf_append_u16(&buf, sizeof(nonce));
+ tpm_buf_append(&buf, nonce, sizeof(nonce));
+
+ /* Encrypted secret - empty */
+ tpm_buf_append_u16(&buf, 0);
+
+ /* Policy type - session */
+ tpm_buf_append_u8(&buf, 0x01);
+
+ /* Encryption type - NULL */
+ tpm_buf_append_u16(&buf, TPM_ALG_NULL);
+
+ /* Hash type - SHA256 */
+ tpm_buf_append_u16(&buf, TPM_ALG_SHA256);
+
+ rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
+
+ if (rc)
+ goto out;
+
+ head = (struct tpm_header *)buf.data;
+
+ if (be32_to_cpu(head->length) != sizeof(struct tpm_header) +
+ sizeof(int) + sizeof(u16) + sizeof(nonce)) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ *session_handle = be32_to_cpu(*(int *)&buf.data[10]);
+ memcpy(nonce, &buf.data[16], sizeof(nonce));
+
+ tpm_buf_destroy(&buf);
+
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_POLICY_PCR);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, *session_handle);
+
+ /* PCR digest - read from the PCR, we'll verify creation data later */
+ tpm_buf_append_u16(&buf, 0);
+
+ /* One PCR */
+ tpm_buf_append_u32(&buf, 1);
+
+ /* SHA256 banks */
+ tpm_buf_append_u16(&buf, TPM_ALG_SHA256);
+
+ /* Select PCR 23 */
+ tpm_buf_append_u32(&buf, 0x0380);
+
+ rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
+
+ if (rc)
+ goto out;
+
+out:
+ tpm_buf_destroy(&buf);
+ return rc;
+}
+
+static int tpm_policy_get_digest(struct tpm_chip *chip, int handle,
+char *digest)
+{
+ struct tpm_header *head;
+ struct tpm_buf buf;
+ int rc;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_POLICY_GET_DIGEST);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, handle);
+
+ rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
+
+ if (rc)
+ goto out;
+
+ head = (struct tpm_header *)buf.data;
+ if (be32_to_cpu(head->length) != sizeof(struct tpm_header) +
+ sizeof(u16) + SHA256_DIGEST_SIZE) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ memcpy(digest, &buf.data[12], SHA256_DIGEST_SIZE);
+out:
+ tpm_buf_destroy(&buf);
+
+ return rc;
+}
+
static int tpm_certify_creationdata(struct tpm_chip *chip,
st
[PATCH 5/9] security: keys: trusted: Allow storage of PCR values in creation data
When TPMs generate keys, they can also generate some information
describing the state of the PCRs at creation time. This data can then
later be certified by the TPM, allowing verification of the PCR values.
This allows us to determine the state of the system at the time a key
was generated. Add an additional argument to the trusted key creation
options, allowing the user to provide the set of PCRs that should have
their values incorporated into the creation data.
Signed-off-by: Matthew Garrett
---
.../security/keys/trusted-encrypted.rst | 4 +++
include/keys/trusted-type.h | 1 +
security/keys/trusted-keys/trusted_tpm1.c | 9 +++
security/keys/trusted-keys/trusted_tpm2.c | 25 +--
4 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/security/keys/trusted-encrypted.rst
b/Documentation/security/keys/trusted-encrypted.rst
index 1da879a68640..27bc43463ec8 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -72,6 +72,10 @@ Usage::
policyhandle= handle to an authorization policy session that defines the
same policy and with the same hash algorithm as was used
to
seal the key.
+ creationpcrs= hex integer representing the set of PCR values to be
+ included in the PCR creation data. The bit corresponding
+to each PCR should be 1 to be included, 0 to be ignored.
+TPM2 only.
"keyctl print" returns an ascii hex copy of the sealed key, which is in
standard
TPM_STORED_DATA format. The key length for new keys are always in bytes.
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 154d8a1769c3..875e05f33b84 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -47,6 +47,7 @@ struct trusted_key_options {
uint32_t policydigest_len;
unsigned char policydigest[MAX_DIGEST_SIZE];
uint32_t policyhandle;
+ uint32_t creation_pcrs;
};
extern struct key_type key_type_trusted;
diff --git a/security/keys/trusted-keys/trusted_tpm1.c
b/security/keys/trusted-keys/trusted_tpm1.c
index 74d82093cbaa..3d371ab3441f 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -709,6 +709,7 @@ enum {
Opt_hash,
Opt_policydigest,
Opt_policyhandle,
+ Opt_creationpcrs,
};
static const match_table_t key_tokens = {
@@ -724,6 +725,7 @@ static const match_table_t key_tokens = {
{Opt_hash, "hash=%s"},
{Opt_policydigest, "policydigest=%s"},
{Opt_policyhandle, "policyhandle=%s"},
+ {Opt_creationpcrs, "creationpcrs=%s"},
{Opt_err, NULL}
};
@@ -834,6 +836,13 @@ static int getoptions(char *c, struct trusted_key_payload
*pay,
return -EINVAL;
opt->policyhandle = handle;
break;
+ case Opt_creationpcrs:
+ if (!tpm2)
+ return -EINVAL;
+ res = kstrtoint(args[0].from, 16, &opt->creation_pcrs);
+ if (res < 0)
+ return -EINVAL;
+ break;
default:
return -EINVAL;
}
diff --git a/security/keys/trusted-keys/trusted_tpm2.c
b/security/keys/trusted-keys/trusted_tpm2.c
index a3673fffd834..282f956ad610 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -124,7 +124,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
unsigned int offset;
struct tpm_buf buf;
u32 hash;
- int i;
+ int i, j;
int rc;
for (i = 0; i < ARRAY_SIZE(tpm2_hash_map); i++) {
@@ -181,7 +181,28 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
tpm_buf_append_u16(&buf, 0);
/* creation PCR */
- tpm_buf_append_u32(&buf, 0);
+ if (options->creation_pcrs) {
+ /* One bank */
+ tpm_buf_append_u32(&buf, 1);
+ /* Which bank to use */
+ tpm_buf_append_u16(&buf, hash);
+ /* Length of the PCR bitmask */
+ tpm_buf_append_u8(&buf, 3);
+ /* PCR bitmask */
+ for (i = 0; i < 3; i++) {
+ char tmp = 0;
+
+ for (j = 0; j < 8; j++) {
+ char bit = (i * 8) + j;
+
+ if (options->creation_pcrs & (1 << bit))
+ tmp |= (1 << j);
+ }
+ tpm_buf_append_u8(&buf, tmp);
+ }
+ } else {
+ tpm_buf_append_u32(&buf, 0);
+ }
if (buf.flags & TPM_BUF_OVERFLOW) {
rc = -E2BIG;
--
2.30.0.617.g56c
[PATCH 8/9] pm: hibernate: Verify the digest encryption key
We want to ensure that the key used to encrypt the digest was created by
the kernel during hibernation. To do this we request that the TPM include
information about the value of PCR 23 at the time of key creation in the
sealed blob. On resume, we can ask the TPM to certify that the creation
data is accurate and then make sure that the PCR information in the blob
corresponds to the expected value. Since only the kernel can touch PCR
23, if an attacker generates a key themselves the value of PCR 23 will
have been different, allowing us to reject the key and boot normally
instead of resuming.
Signed-off-by: Matthew Garrett
---
include/linux/tpm.h | 1 +
kernel/power/tpm.c | 150 +++-
2 files changed, 148 insertions(+), 3 deletions(-)
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index e2075e2242a0..f6970986b097 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -216,6 +216,7 @@ enum tpm2_command_codes {
TPM2_CC_SELF_TEST = 0x0143,
TPM2_CC_STARTUP = 0x0144,
TPM2_CC_SHUTDOWN= 0x0145,
+ TPM2_CC_CERTIFYCREATION = 0x014A,
TPM2_CC_NV_READ = 0x014E,
TPM2_CC_CREATE = 0x0153,
TPM2_CC_LOAD= 0x0157,
diff --git a/kernel/power/tpm.c b/kernel/power/tpm.c
index 953dcbdc56d8..34e6cfb98ce4 100644
--- a/kernel/power/tpm.c
+++ b/kernel/power/tpm.c
@@ -14,6 +14,12 @@ static struct tpm_digest digest = { .alg_id = TPM_ALG_SHA256,
0xf1, 0x22, 0x38, 0x6c, 0x33, 0xb1, 0x14, 0xb7, 0xec, 0x05,
0x5f, 0x49}};
+/* sha256(sha256(empty_pcr | digest)) */
+static char expected_digest[] = {0x2f, 0x96, 0xf2, 0x1b, 0x70, 0xa9, 0xe8,
+ 0x42, 0x25, 0x8e, 0x66, 0x07, 0xbe, 0xbc, 0xe3, 0x1f, 0x2c, 0x84, 0x4a,
+ 0x3f, 0x85, 0x17, 0x31, 0x47, 0x9a, 0xa5, 0x53, 0xbb, 0x23, 0x0c, 0x32,
+ 0xf3};
+
struct skcipher_def {
struct scatterlist sg;
struct crypto_skcipher *tfm;
@@ -21,6 +27,39 @@ struct skcipher_def {
struct crypto_wait wait;
};
+static int sha256_data(char *buf, int size, char *output)
+{
+ struct crypto_shash *tfm;
+ struct shash_desc *desc;
+ int ret;
+
+ tfm = crypto_alloc_shash("sha256", 0, 0);
+ if (IS_ERR(tfm))
+ return PTR_ERR(tfm);
+
+ desc = kmalloc(sizeof(struct shash_desc) +
+ crypto_shash_descsize(tfm), GFP_KERNEL);
+ if (!desc) {
+ crypto_free_shash(tfm);
+ return -ENOMEM;
+ }
+
+ desc->tfm = tfm;
+ ret = crypto_shash_init(desc);
+ if (ret != 0) {
+ crypto_free_shash(tfm);
+ kfree(desc);
+ return ret;
+ }
+
+ crypto_shash_update(desc, buf, size);
+ crypto_shash_final(desc, output);
+ crypto_free_shash(desc->tfm);
+ kfree(desc);
+
+ return 0;
+}
+
static int swsusp_enc_dec(struct trusted_key_payload *payload, char *buf,
int enc)
{
@@ -86,6 +125,58 @@ static int swsusp_enc_dec(struct trusted_key_payload
*payload, char *buf,
return ret;
}
+static int tpm_certify_creationdata(struct tpm_chip *chip,
+ struct trusted_key_payload *payload)
+{
+ struct tpm_header *head;
+ struct tpm_buf buf;
+ int rc;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_CERTIFYCREATION);
+ if (rc)
+ return rc;
+
+ /* Use TPM_RH_NULL for signHandle */
+ tpm_buf_append_u32(&buf, 0x4007);
+
+ /* Object handle */
+ tpm_buf_append_u32(&buf, payload->blob_handle);
+
+ /* Auth */
+ tpm_buf_append_u32(&buf, 9);
+ tpm_buf_append_u32(&buf, TPM2_RS_PW);
+ tpm_buf_append_u16(&buf, 0);
+ tpm_buf_append_u8(&buf, 0);
+ tpm_buf_append_u16(&buf, 0);
+
+ /* Qualifying data */
+ tpm_buf_append_u16(&buf, 0);
+
+ /* Creation data hash */
+ tpm_buf_append_u16(&buf, payload->creation_hash_len);
+ tpm_buf_append(&buf, payload->creation_hash,
+ payload->creation_hash_len);
+
+ /* signature scheme */
+ tpm_buf_append_u16(&buf, TPM_ALG_NULL);
+
+ /* creation ticket */
+ tpm_buf_append(&buf, payload->tk, payload->tk_len);
+
+ rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
+ if (rc)
+ goto out;
+
+ head = (struct tpm_header *)buf.data;
+
+ if (head->return_code != 0)
+ rc = -EINVAL;
+out:
+ tpm_buf_destroy(&buf);
+
+ return rc;
+}
+
int swsusp_encrypt_digest(struct swsusp_header *header)
{
const struct cred *cred = current_cred();
@@ -95,7 +186,7 @@ int swsusp_encrypt_digest(struct swsusp_header *header)
struct key *key;
int ret, i;
- char *keyinfo = "new\t32\tkeyhandle=0x8101";
+ char *keyinfo =
"ne
[PATCH 7/9] pm: hibernate: Optionally use TPM-backed keys to protect image integrity
A plain hash protects the hibernation image against accidental
modification, but in the face of an active attack the hash can simply be
updated to match the new image. Generate a random AES key and seal this
with the TPM, and use it to encrypt the hash. On resume, the key can be
unsealed and used to decrypt the hash. By setting PCR 23 to a specific
value we can verify that the key used was generated by the kernel during
hibernation and prevent an attacker providing their own key.
Signed-off-by: Matthew Garrett
---
kernel/power/Kconfig | 15 ++
kernel/power/Makefile| 1 +
kernel/power/hibernate.c | 11 +-
kernel/power/swap.c | 99 +++--
kernel/power/swap.h | 38 +
kernel/power/tpm.c | 294 +++
kernel/power/tpm.h | 37 +
7 files changed, 417 insertions(+), 78 deletions(-)
create mode 100644 kernel/power/swap.h
create mode 100644 kernel/power/tpm.c
create mode 100644 kernel/power/tpm.h
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index a7320f07689d..0279cc10f319 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -92,6 +92,21 @@ config HIBERNATION_SNAPSHOT_DEV
If in doubt, say Y.
+config SECURE_HIBERNATION
+ bool "Implement secure hibernation support"
+ depends on HIBERNATION && TCG_TPM
+ select KEYS
+ select TRUSTED_KEYS
+ select CRYPTO
+ select CRYPTO_SHA256
+ select CRYPTO_AES
+ select TCG_TPM_RESTRICT_PCR
+ help
+ Use a TPM-backed key to securely determine whether a hibernation
+image was written out by the kernel and has not been tampered with.
+This requires a TCG-compliant TPM2 device, which is present on most
+modern hardware.
+
config PM_STD_PARTITION
string "Default resume partition"
depends on HIBERNATION
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 5899260a8bef..2edfef897607 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SUSPEND) += suspend.o
obj-$(CONFIG_PM_TEST_SUSPEND) += suspend_test.o
obj-$(CONFIG_HIBERNATION) += hibernate.o snapshot.o swap.o
obj-$(CONFIG_HIBERNATION_SNAPSHOT_DEV) += user.o
+obj-$(CONFIG_SECURE_HIBERNATION) += tpm.o
obj-$(CONFIG_PM_AUTOSLEEP) += autosleep.o
obj-$(CONFIG_PM_WAKELOCKS) += wakelock.o
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index da0b41914177..608bfbee38f5 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -34,6 +34,7 @@
#include
#include "power.h"
+#include "tpm.h"
static int nocompress;
@@ -81,7 +82,11 @@ void hibernate_release(void)
bool hibernation_available(void)
{
- return nohibernate == 0 && !security_locked_down(LOCKDOWN_HIBERNATION);
+ if (security_locked_down(LOCKDOWN_HIBERNATION) &&
+ !secure_hibernation_available())
+ return false;
+
+ return nohibernate == 0;
}
/**
@@ -752,7 +757,9 @@ int hibernate(void)
flags |= SF_NOCOMPRESS_MODE;
else
flags |= SF_CRC32_MODE;
-
+#ifdef CONFIG_SECURE_HIBERNATION
+ flags |= SF_VERIFY_IMAGE;
+#endif
pm_pr_dbg("Writing hibernation image.\n");
error = swsusp_write(flags);
swsusp_free();
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index a13241a20567..eaa585731314 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -32,9 +32,10 @@
#include
#include
#include
-#include
#include "power.h"
+#include "swap.h"
+#include "tpm.h"
#define HIBERNATE_SIG "S1SUSPEND"
@@ -89,34 +90,6 @@ struct swap_map_page_list {
struct swap_map_page_list *next;
};
-/**
- * The swap_map_handle structure is used for handling swap in
- * a file-alike way
- */
-
-struct swap_map_handle {
- struct swap_map_page *cur;
- struct swap_map_page_list *maps;
- struct shash_desc *desc;
- sector_t cur_swap;
- sector_t first_sector;
- unsigned int k;
- unsigned long reqd_free_pages;
- u32 crc32;
- u8 digest[SHA256_DIGEST_SIZE];
-};
-
-struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
- sizeof(u32) - SHA256_DIGEST_SIZE];
- u32 crc32;
- u8 digest[SHA256_DIGEST_SIZE];
- sector_t image;
- unsigned int flags; /* Flags to pass to the "boot" kernel */
- charorig_sig[10];
- charsig[10];
-} __packed;
-
static struct swsusp_header *swsusp_header;
/**
@@ -337,6 +310,9 @@ static int mark_swapfiles(struct swap_map_handle *handle,
unsigned int flags)
swsusp_header->crc32 = handle->crc32;
memcpy(swsusp_header->digest, handle->digest,
SHA256_DIGEST_SIZE);
+ error = swsusp_encrypt_digest(swsusp_header);
+
[PATCH 6/9] pm: hibernate: Optionally store and verify a hash of the image
Calculate and store a cryptographically secure hash of the hibernation
image if SF_VERIFY_IMAGE is set in the hibernation flags. This allows
detection of a corrupt image, but has the disadvantage that it requires
the blocks be read in in linear order.
Signed-off-by: Matthew Garrett
---
kernel/power/power.h | 1 +
kernel/power/swap.c | 131 +++
2 files changed, 110 insertions(+), 22 deletions(-)
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 778bf431ec02..b8e00b9dcee8 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -168,6 +168,7 @@ extern int swsusp_swap_in_use(void);
#define SF_PLATFORM_MODE 1
#define SF_NOCOMPRESS_MODE 2
#define SF_CRC32_MODE 4
+#define SF_VERIFY_IMAGE 8
/* kernel/power/hibernate.c */
extern int swsusp_check(void);
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 72e33054a2e1..a13241a20567 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -31,6 +31,8 @@
#include
#include
#include
+#include
+#include
#include "power.h"
@@ -95,17 +97,20 @@ struct swap_map_page_list {
struct swap_map_handle {
struct swap_map_page *cur;
struct swap_map_page_list *maps;
+ struct shash_desc *desc;
sector_t cur_swap;
sector_t first_sector;
unsigned int k;
unsigned long reqd_free_pages;
u32 crc32;
+ u8 digest[SHA256_DIGEST_SIZE];
};
struct swsusp_header {
char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
- sizeof(u32)];
+ sizeof(u32) - SHA256_DIGEST_SIZE];
u32 crc32;
+ u8 digest[SHA256_DIGEST_SIZE];
sector_t image;
unsigned int flags; /* Flags to pass to the "boot" kernel */
charorig_sig[10];
@@ -305,6 +310,9 @@ static blk_status_t hib_wait_io(struct hib_bio_batch *hb)
* We are relying on the behavior of blk_plug that a thread with
* a plug will flush the plug list before sleeping.
*/
+ if (!hb)
+ return 0;
+
wait_event(hb->wait, atomic_read(&hb->count) == 0);
return blk_status_to_errno(hb->error);
}
@@ -327,6 +335,8 @@ static int mark_swapfiles(struct swap_map_handle *handle,
unsigned int flags)
swsusp_header->flags = flags;
if (flags & SF_CRC32_MODE)
swsusp_header->crc32 = handle->crc32;
+ memcpy(swsusp_header->digest, handle->digest,
+ SHA256_DIGEST_SIZE);
error = hib_submit_io(REQ_OP_WRITE, REQ_SYNC,
swsusp_resume_block, swsusp_header, NULL);
} else {
@@ -417,6 +427,7 @@ static void release_swap_writer(struct swap_map_handle
*handle)
static int get_swap_writer(struct swap_map_handle *handle)
{
int ret;
+ struct crypto_shash *tfm;
ret = swsusp_swap_check();
if (ret) {
@@ -437,7 +448,28 @@ static int get_swap_writer(struct swap_map_handle *handle)
handle->k = 0;
handle->reqd_free_pages = reqd_free_pages();
handle->first_sector = handle->cur_swap;
+
+ tfm = crypto_alloc_shash("sha256", 0, 0);
+ if (IS_ERR(tfm)) {
+ ret = -EINVAL;
+ goto err_rel;
+ }
+ handle->desc = kmalloc(sizeof(struct shash_desc) +
+ crypto_shash_descsize(tfm), GFP_KERNEL);
+ if (!handle->desc) {
+ ret = -ENOMEM;
+ goto err_rel;
+ }
+
+ handle->desc->tfm = tfm;
+
+ ret = crypto_shash_init(handle->desc);
+ if (ret != 0)
+ goto err_free;
+
return 0;
+err_free:
+ kfree(handle->desc);
err_rel:
release_swap_writer(handle);
err_close:
@@ -446,7 +478,7 @@ static int get_swap_writer(struct swap_map_handle *handle)
}
static int swap_write_page(struct swap_map_handle *handle, void *buf,
- struct hib_bio_batch *hb)
+ struct hib_bio_batch *hb, bool hash)
{
int error = 0;
sector_t offset;
@@ -454,6 +486,7 @@ static int swap_write_page(struct swap_map_handle *handle,
void *buf,
if (!handle->cur)
return -EINVAL;
offset = alloc_swapdev_block(root_swap);
+ crypto_shash_update(handle->desc, buf, PAGE_SIZE);
error = write_page(buf, offset, hb);
if (error)
return error;
@@ -496,6 +529,7 @@ static int flush_swap_writer(struct swap_map_handle *handle)
static int swap_writer_finish(struct swap_map_handle *handle,
unsigned int flags, int error)
{
+ crypto_shash_final(handle->desc, handle->digest);
if (!error) {
pr_info("S");
error = mark_swapfiles(handle, flags);
@@ -560,7 +594,7 @@ static int save_image(struct swap_map_handle *handle,
ret = snapshot_read_next(snapshot);
[PATCH 4/9] security: keys: trusted: Store the handle of a loaded key
Certain in-kernel operations using a trusted key (such as creation
certification) require knowledge of the handle it's loaded at. Keep
a copy of that in the payload.
Signed-off-by: Matthew Garrett
---
include/keys/trusted-type.h | 1 +
security/keys/trusted-keys/trusted_tpm2.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index 020e01a99ea4..154d8a1769c3 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -21,6 +21,7 @@
struct trusted_key_payload {
struct rcu_head rcu;
+ unsigned int blob_handle;
unsigned int key_len;
unsigned int blob_len;
unsigned int creation_len;
diff --git a/security/keys/trusted-keys/trusted_tpm2.c
b/security/keys/trusted-keys/trusted_tpm2.c
index 6357a51a24e9..a3673fffd834 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -272,11 +272,13 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
}
rc = tpm_send(chip, buf.data, tpm_buf_length(&buf));
- if (!rc)
+ if (!rc) {
*blob_handle = be32_to_cpup(
(__be32 *) &buf.data[TPM_HEADER_SIZE]);
- else
+ payload->blob_handle = *blob_handle;
+ } else {
goto out;
+ }
rc = tpm2_unpack_blob(payload);
out:
--
2.30.0.617.g56c4b15f3c-goog
[PATCH 0/9] Enable hibernation when Lockdown is enabled
Lockdown in integrity mode aims to ensure that arbitrary code cannot end up in ring 0 without owner approval. The combination of module signing and secure boot gets most of the way there, but various other features are disabled by lockdown in order to avoid more convoluted approaches that would enable unwanted code to end up in kernel space. One of these is hibernation, since at present the kernel performs no verification of the code it's resuming. If hibernation were permitted, an attacker with root (but not kernel) privileges could disable swap, write a valid hibernation image containing code of their own choosing to the swap partition, and then reboot. On reboot, the kernel would happily resume the provided code. This patchset aims to provide a secure implementation of hibernation. It is based on the presumption that simply storing a key in-kernel is insufficient, since if Lockdown is merely in integrity (rather than confidentiality) mode we assume that root is able to read kernel memory and so would be able to obtain these secrets. It also aims to be unspoofable - an attacker should not be able to write out a hibernation image using cryptographic material under their control. TPMs can be used to generate key material that is encrypted with a key that does not leave the TPM. This means that we can generate an AES key, encrypt the image hash with it, encrypt it with a TPM-backed key, and store the encrypted key in the hibernation image. On resume, we pass the key back to the TPM, receive the unencrypted AES key, and use that to validate the image. However, this is insufficient. Nothing prevents anyone else with access to the TPM asking it to decrypt the key. We need to be able to distinguish between accesses that come from the kernel directly and accesses that come from userland. TPMs have several Platform Configuration Registers (PCRs) which are used for different purposes. PCRs are initialised to a known value, and cannot be modified directly by the platform. Instead, the platform can provide a hash of some data to the TPM. The TPM combines the existing PCR value with the new hash, and stores the hash of this combination in the PCR. Most PCRs can only be extended, which means that the only way to achieve a specific value for a TPM is to perform the same series of writes. When secrets are encrypted by the TPM, they can be accompanied by a policy that describes the state the TPM must be in in order for it to decrypt them. If the TPM is not in this state, it will refuse to decrypt the material even if it is otherwise capable of doing so. This allows keys to be tied to specific system state - if the system is not in that state, the TPM will not grant access. PCR 23 is special in that it can be reset on demand. This patchset re-purposes PCR 23 and blocks userland's ability to extend or reset it. The kernel is then free to impose policy by resetting PCR 23 to a known starting point, extending it with a known value, encrypting key material with a policy that ties it to PCR 23, and then resetting it. Even if userland has access to the encrypted blob, it cannot decrypt it since it has no way to force PCR 23 to be in the same state. So. During hibernation we freeze userland. We then reset PCR 23 and extend it to a known value. We generate a key, use it and then encrypt it with the TPM. When we encrypt it, we define a policy which states that the TPM must have the same PCR 23 value as it presently does. We also store the current PCR 23 value in the key metadata. On resume, we again freeze userland, reset PCR 23 and extend it to the same value. We decrypt the key, and verify from the metadata that it was created when PCR 23 had the expected value. If so, we use it to decrypt the hash used to verify the hibernation image and ensure that the image matches it. If everything looks good, we resume. If not, we return to userland. Either way, we reset PCR 23 before any userland code runs again. This all works on my machine, but it's imperfect - there's a meaningful performance hit on resume forced by reading all the blocks in-order, and it probably makes more sense to do that after reads are complete instead but I wanted to get the other components of this out for review first. It's also not ideal from a security perspective until there's more ecosystem integration - we need a kernel to be able to assert to a signed bootloader that it implements this, since otherwise an attacker can simply downgrade to a kernel that doesn't implement this policy and gain access to PCR 23 themselves. There's ongoing work in the UEFI bootloader space that would make this possible.
[PATCH 3/9] security: keys: trusted: Parse out individual components of the key blob
Performing any sort of state validation of a sealed TPM blob requires
being able to access the individual members in the response. Parse the
blob sufficiently to be able to stash pointers to each member, along
with the length.
Signed-off-by: Matthew Garrett
---
include/keys/trusted-type.h | 8 +++
security/keys/trusted-keys/trusted_tpm2.c | 67 ++-
2 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index a94c03a61d8f..020e01a99ea4 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -16,14 +16,22 @@
#define MAX_BLOB_SIZE 512
#define MAX_PCRINFO_SIZE 64
#define MAX_DIGEST_SIZE64
+#define MAX_CREATION_DATA 412
+#define MAX_TK 76
struct trusted_key_payload {
struct rcu_head rcu;
unsigned int key_len;
unsigned int blob_len;
+ unsigned int creation_len;
+ unsigned int creation_hash_len;
+ unsigned int tk_len;
unsigned char migratable;
unsigned char key[MAX_KEY_SIZE + 1];
unsigned char blob[MAX_BLOB_SIZE];
+ unsigned char *creation;
+ unsigned char *creation_hash;
+ unsigned char *tk;
};
struct trusted_key_options {
diff --git a/security/keys/trusted-keys/trusted_tpm2.c
b/security/keys/trusted-keys/trusted_tpm2.c
index 08ec7f48f01d..6357a51a24e9 100644
--- a/security/keys/trusted-keys/trusted_tpm2.c
+++ b/security/keys/trusted-keys/trusted_tpm2.c
@@ -50,6 +50,63 @@ static void tpm2_buf_append_auth(struct tpm_buf *buf, u32
session_handle,
tpm_buf_append(buf, hmac, hmac_len);
}
+static int tpm2_unpack_blob(struct trusted_key_payload *payload)
+{
+ int tmp, offset;
+
+ /* Find the length of the private data */
+ tmp = be16_to_cpup((__be16 *) &payload->blob[0]);
+ offset = tmp + 2;
+ if (offset > payload->blob_len)
+ return -EFAULT;
+
+ /* Find the length of the public data */
+ tmp = be16_to_cpup((__be16 *) &payload->blob[offset]);
+ offset += tmp + 2;
+ if (offset > payload->blob_len)
+ return -EFAULT;
+
+ /* Find the length of the creation data and store it */
+ tmp = be16_to_cpup((__be16 *) &payload->blob[offset]);
+ if (tmp > MAX_CREATION_DATA)
+ return -E2BIG;
+
+ if ((offset + tmp + 2) > payload->blob_len)
+ return -EFAULT;
+
+ payload->creation = &payload->blob[offset + 2];
+ payload->creation_len = tmp;
+ offset += tmp + 2;
+
+ /* Find the length of the creation hash and store it */
+ tmp = be16_to_cpup((__be16 *) &payload->blob[offset]);
+ if (tmp > MAX_DIGEST_SIZE)
+ return -E2BIG;
+
+ if ((offset + tmp + 2) > payload->blob_len)
+ return -EFAULT;
+
+ payload->creation_hash = &payload->blob[offset + 2];
+ payload->creation_hash_len = tmp;
+ offset += tmp + 2;
+
+ /*
+* Store the creation ticket. TPMT_TK_CREATION is two bytes of tag,
+* four bytes of handle, and then the digest length and digest data
+*/
+ tmp = be16_to_cpup((__be16 *) &payload->blob[offset + 6]);
+ if (tmp > MAX_TK)
+ return -E2BIG;
+
+ if ((offset + tmp + 8) > payload->blob_len)
+ return -EFAULT;
+
+ payload->tk = &payload->blob[offset];
+ payload->tk_len = tmp + 8;
+
+ return 0;
+}
+
/**
* tpm2_seal_trusted() - seal the payload of a trusted key
*
@@ -64,6 +121,7 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
struct trusted_key_options *options)
{
unsigned int blob_len;
+ unsigned int offset;
struct tpm_buf buf;
u32 hash;
int i;
@@ -139,14 +197,16 @@ int tpm2_seal_trusted(struct tpm_chip *chip,
rc = -E2BIG;
goto out;
}
- if (tpm_buf_length(&buf) < TPM_HEADER_SIZE + 4 + blob_len) {
+ offset = TPM_HEADER_SIZE + 4;
+ if (tpm_buf_length(&buf) < offset + blob_len) {
rc = -EFAULT;
goto out;
}
- memcpy(payload->blob, &buf.data[TPM_HEADER_SIZE + 4], blob_len);
+ memcpy(payload->blob, &buf.data[offset], blob_len);
payload->blob_len = blob_len;
+ rc = tpm2_unpack_blob(payload);
out:
tpm_buf_destroy(&buf);
@@ -215,7 +275,10 @@ static int tpm2_load_cmd(struct tpm_chip *chip,
if (!rc)
*blob_handle = be32_to_cpup(
(__be32 *) &buf.data[TPM_HEADER_SIZE]);
+ else
+ goto out;
+ rc = tpm2_unpack_blob(payload);
out:
tpm_buf_destroy(&buf);
--
2.30.0.617.g56c4b15f3c-goog
[PATCH 1/9] tpm: Add support for in-kernel resetting of PCRs
Add an internal command for resetting a PCR.
Signed-off-by: Matthew Garrett
---
drivers/char/tpm/tpm-interface.c | 28 +
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm1-cmd.c | 34 ++
drivers/char/tpm/tpm2-cmd.c | 36
include/linux/tpm.h | 7 +++
5 files changed, 107 insertions(+)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1621ce818705..17b8643ee109 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -342,6 +342,34 @@ int tpm_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
}
EXPORT_SYMBOL_GPL(tpm_pcr_extend);
+/**
+ * tpm_pcr_reset - reset the specified PCR
+ * @chip: a &struct tpm_chip instance, %NULL for the default chip
+ * @pcr_idx: the PCR to be reset
+ *
+ * Return: same as with tpm_transmit_cmd()
+ */
+int tpm_pcr_reset(struct tpm_chip *chip, u32 pcr_idx)
+{
+ int rc;
+
+ chip = tpm_find_get_ops(chip);
+ if (!chip)
+ return -ENODEV;
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2) {
+ rc = tpm2_pcr_reset(chip, pcr_idx);
+ goto out;
+ }
+
+ rc = tpm1_pcr_reset(chip, pcr_idx, "attempting to reset a PCR");
+
+out:
+ tpm_put_ops(chip);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_pcr_reset);
+
/**
* tpm_send - send a TPM command
* @chip: a &struct tpm_chip instance, %NULL for the default chip
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 947d1db0a5cc..746f7696bdc0 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -176,6 +176,7 @@ int tpm1_get_timeouts(struct tpm_chip *chip);
unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx, const u8 *hash,
const char *log_msg);
+int tpm1_pcr_reset(struct tpm_chip *chip, u32 pcr_idx, const char *log_msg);
int tpm1_pcr_read(struct tpm_chip *chip, u32 pcr_idx, u8 *res_buf);
ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length);
@@ -220,6 +221,7 @@ int tpm2_pcr_read(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digest, u16 *digest_size_ptr);
int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
struct tpm_digest *digests);
+int tpm2_pcr_reset(struct tpm_chip *chip, u32 pcr_idx);
int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
u32 *value, const char *desc);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index ca7158fa6e6c..36990e9d2dc1 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -478,6 +478,40 @@ int tpm1_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
const u8 *hash,
return rc;
}
+struct tpm_pcr_selection {
+ u16 size_of_select;
+ u8 pcr_select[3];
+} __packed;
+
+#define TPM_ORD_PCR_RESET 200
+int tpm1_pcr_reset(struct tpm_chip *chip, u32 pcr_idx, const char *log_msg)
+{
+ struct tpm_pcr_selection selection;
+ struct tpm_buf buf;
+ int i, rc;
+ char tmp;
+
+ rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCR_RESET);
+ if (rc)
+ return rc;
+
+ selection.size_of_select = 3;
+
+ for (i = 0; i < selection.size_of_select; i++) {
+ tmp = 0;
+ if (pcr_idx / 3 == i) {
+ pcr_idx -= i * 8;
+ tmp |= 1 << pcr_idx;
+ }
+ selection.pcr_select[i] = tmp;
+ }
+ tpm_buf_append(&buf, (u8 *)&selection, sizeof(selection));
+
+ rc = tpm_transmit_cmd(chip, &buf, sizeof(selection), log_msg);
+ tpm_buf_destroy(&buf);
+ return rc;
+}
+
#define TPM_ORD_GET_CAP 101
ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length)
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index eff1f12d981a..9609ae8086c6 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -269,6 +269,42 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
return rc;
}
+/**
+ * tpm2_pcr_reset() - reset a PCR
+ *
+ * @chip: TPM chip to use.
+ * @pcr_idx: index of the PCR.
+ *
+ * Return: Same as with tpm_transmit_cmd.
+ */
+int tpm2_pcr_reset(struct tpm_chip *chip, u32 pcr_idx)
+{
+ struct tpm_buf buf;
+ struct tpm2_null_auth_area auth_area;
+ int rc;
+
+ rc = tpm_buf_init(&buf, TPM2_ST_SESSIONS, TPM2_CC_PCR_RESET);
+ if (rc)
+ return rc;
+
+ tpm_buf_append_u32(&buf, pcr_idx);
+
+ auth_area.handle = cpu_to_be32(TPM2_RS_PW);
+ auth_area.nonce_size = 0;
+ auth_area.attributes
[PATCH 2/9] tpm: Allow PCR 23 to be restricted to kernel-only use
Under certain circumstances it might be desirable to enable the creation
of TPM-backed secrets that are only accessible to the kernel. In an
ideal world this could be achieved by using TPM localities, but these
don't appear to be available on consumer systems. An alternative is to
simply block userland from modifying one of the resettable PCRs, leaving
it available to the kernel. If the kernel ensures that no userland can
access the TPM while it is carrying out work, it can reset PCR 23,
extend it to an arbitrary value, create or load a secret, and then reset
the PCR again. Even if userland somehow obtains the sealed material, it
will be unable to unseal it since PCR 23 will never be in the
appropriate state.
Signed-off-by: Matthew Garrett
---
drivers/char/tpm/Kconfig | 10 +
drivers/char/tpm/tpm-dev-common.c | 8 +++
drivers/char/tpm/tpm.h| 21 +++
drivers/char/tpm/tpm1-cmd.c | 35 +++
drivers/char/tpm/tpm2-cmd.c | 22 +++
drivers/char/tpm/tpm2-space.c | 2 +-
6 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index a18c314da211..bba30fb16a2e 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -190,4 +190,14 @@ config TCG_FTPM_TEE
This driver proxies for firmware TPM running in TEE.
source "drivers/char/tpm/st33zp24/Kconfig"
+
+config TCG_TPM_RESTRICT_PCR
+ bool "Restrict userland access to PCR 23"
+ depends on TCG_TPM
+ help
+ If set, block userland from extending or resetting PCR 23. This
+ allows it to be restricted to in-kernel use, preventing userland
+ from being able to make use of data sealed to the TPM by the kernel.
+ This is required for secure hibernation support, but should be left
+ disabled if any userland may require access to PCR23.
endif # TCG_TPM
diff --git a/drivers/char/tpm/tpm-dev-common.c
b/drivers/char/tpm/tpm-dev-common.c
index 1784530b8387..d3db4fd76257 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -193,6 +193,14 @@ ssize_t tpm_common_write(struct file *file, const char
__user *buf,
priv->response_read = false;
*off = 0;
+ if (priv->chip->flags & TPM_CHIP_FLAG_TPM2)
+ ret = tpm2_cmd_restricted(priv->chip, priv->data_buffer, size);
+ else
+ ret = tpm1_cmd_restricted(priv->chip, priv->data_buffer, size);
+
+ if (ret)
+ goto out;
+
/*
* If in nonblocking mode schedule an async job to send
* the command return the size.
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 746f7696bdc0..8eed5016d733 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -232,6 +232,8 @@ void tpm2_shutdown(struct tpm_chip *chip, u16
shutdown_type);
unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
int tpm2_probe(struct tpm_chip *chip);
int tpm2_get_cc_attrs_tbl(struct tpm_chip *chip);
+int tpm_find_and_validate_cc(struct tpm_chip *chip, struct tpm_space *space,
+const void *buf, size_t bufsiz);
int tpm2_find_cc(struct tpm_chip *chip, u32 cc);
int tpm2_init_space(struct tpm_space *space, unsigned int buf_size);
void tpm2_del_space(struct tpm_chip *chip, struct tpm_space *space);
@@ -245,4 +247,23 @@ void tpm_bios_log_setup(struct tpm_chip *chip);
void tpm_bios_log_teardown(struct tpm_chip *chip);
int tpm_dev_common_init(void);
void tpm_dev_common_exit(void);
+
+#ifdef CONFIG_TCG_TPM_RESTRICT_PCR
+#define TPM_RESTRICTED_PCR 23
+
+int tpm1_cmd_restricted(struct tpm_chip *chip, u8 *buffer, size_t size);
+int tpm2_cmd_restricted(struct tpm_chip *chip, u8 *buffer, size_t size);
+#else
+static inline int tpm1_cmd_restricted(struct tpm_chip *chip, u8 *buffer,
+ size_t size)
+{
+ return 0;
+}
+
+static inline int tpm2_cmd_restricted(struct tpm_chip *chip, u8 *buffer,
+ size_t size)
+{
+ return 0;
+}
+#endif
#endif
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 36990e9d2dc1..2dab1647d89c 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -840,3 +840,38 @@ int tpm1_get_pcr_allocation(struct tpm_chip *chip)
return 0;
}
+
+#ifdef CONFIG_TCG_TPM_RESTRICT_PCR
+int tpm1_cmd_restricted(struct tpm_chip *chip, u8 *buffer, size_t size)
+{
+ struct tpm_header *header = (struct tpm_header *)buffer;
+ char len, offset;
+ u32 *pcr;
+ int pos;
+
+ switch (be32_to_cpu(header->ordinal)) {
+ case TPM_ORD_PCR_EXTEND:
+ if (size < (TPM_HEADER_SIZE + sizeof(u32)))
+ return -EINVAL;
+ pcr = (u32 *)&buffer[TPM_HEADER_SIZE];
+ if (be32_to_cpu(*pcr) == TPM_RESTRICTED_PCR)
+
RE: [EXT] Re: [PATCH] PCI: imx6: Limit DBI register length for imx6qp pcie
> -Original Message-
> From: Krzysztof Wilczyński
> Sent: Friday, February 19, 2021 1:34 AM
> To: Richard Zhu
> Cc: l.st...@pengutronix.de; helg...@kernel.org; ste...@agner.ch;
> lorenzo.pieral...@arm.com; linux-...@vger.kernel.org; dl-linux-imx
> ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; ker...@pengutronix.de
> Subject: [EXT] Re: [PATCH] PCI: imx6: Limit DBI register length for imx6qp
> pcie
> [...]
> > > Refer to commit 075af61c19cd ("PCI: imx6: Limit DBI register
> > > length"), i.MX6QP PCIe has the similar issue.
> > > Define the length of the DBI registers and limit config space to its
> > > length for i.MX6QP PCIe too.
> >
> > You could probably flip these two sentences around to make the commit
> > message read slightly better, so what about this (a suggestion):
> >
> > Define the length of the DBI registers and limit config space to its
> > length. This makes sure that the kernel does not access registers
> > beyond that point that otherwise would lead to an abort on a i.MX
> 6QuadPlus.
> >
> > See commit 075af61c19cd ("PCI: imx6: Limit DBI register length") that
> > resolves a similar issue on a i.MX 6Quad PCIe.
> [...]
>
> If you do decide to send another version, then also use "PCIe" in the subject,
> rather than "pcie". I forgot to mention this in the previous message,
> apologies.
>
[Richard Zhu] Never mind. Thanks a lot for your comments.
Would issue another version a moment later.
Best Regards
Richard Zhu
> Krzysztof
Re: [PATCH v5 4/9] cxl/mem: Add basic IOCTL interface
..snip..
> +static int handle_mailbox_cmd_from_user(struct cxl_mem *cxlm,
> + const struct cxl_mem_command *cmd,
> + u64 in_payload, u64 out_payload,
> + s32 *size_out, u32 *retval)
> +{
> + struct device *dev = &cxlm->pdev->dev;
> + struct mbox_cmd mbox_cmd = {
> + .opcode = cmd->opcode,
> + .size_in = cmd->info.size_in,
> + .size_out = cmd->info.size_out,
> + };
> + int rc;
> +
> + if (cmd->info.size_out) {
> + mbox_cmd.payload_out = kvzalloc(cmd->info.size_out, GFP_KERNEL);
> + if (!mbox_cmd.payload_out)
> + return -ENOMEM;
> + }
> +
> + if (cmd->info.size_in) {
> + mbox_cmd.payload_in = vmemdup_user(u64_to_user_ptr(in_payload),
> +cmd->info.size_in);
> + if (IS_ERR(mbox_cmd.payload_in))
> + return PTR_ERR(mbox_cmd.payload_in);
Not that this should happen, but what if info.size_out was set? Should
you also free mbox_cmd.payload_out?
> + }
> +
> + rc = cxl_mem_mbox_get(cxlm);
> + if (rc)
> + goto out;
> +
> + dev_dbg(dev,
> + "Submitting %s command for user\n"
> + "\topcode: %x\n"
> + "\tsize: %ub\n",
> + cxl_command_names[cmd->info.id].name, mbox_cmd.opcode,
> + cmd->info.size_in);
> +
> + rc = __cxl_mem_mbox_send_cmd(cxlm, &mbox_cmd);
> + cxl_mem_mbox_put(cxlm);
> + if (rc)
> + goto out;
> +
> + /*
> + * @size_out contains the max size that's allowed to be written back out
> + * to userspace. While the payload may have written more output than
> + * this it will have to be ignored.
> + */
> + if (mbox_cmd.size_out) {
> + dev_WARN_ONCE(dev, mbox_cmd.size_out > *size_out,
> + "Invalid return size\n");
> + if (copy_to_user(u64_to_user_ptr(out_payload),
> + mbox_cmd.payload_out, mbox_cmd.size_out)) {
> + rc = -EFAULT;
> + goto out;
> + }
> + }
> +
> + *size_out = mbox_cmd.size_out;
> + *retval = mbox_cmd.return_code;
> +
> +out:
> + kvfree(mbox_cmd.payload_in);
> + kvfree(mbox_cmd.payload_out);
> + return rc;
> +}
..snip..
> +static int cxl_query_cmd(struct cxl_memdev *cxlmd,
> + struct cxl_mem_query_commands __user *q)
> +{
> + struct device *dev = &cxlmd->dev;
> + struct cxl_mem_command *cmd;
> + u32 n_commands;
> + int j = 0;
How come it is 'j' instead of the usual 'i'?
> +
> + dev_dbg(dev, "Query IOCTL\n");
> +
> + if (get_user(n_commands, &q->n_commands))
> + return -EFAULT;
> +
> + /* returns the total number if 0 elements are requested. */
> + if (n_commands == 0)
> + return put_user(cxl_cmd_count, &q->n_commands);
> +
> + /*
> + * otherwise, return max(n_commands, total commands) cxl_command_info
> + * structures.
> + */
> + cxl_for_each_cmd(cmd) {
> + const struct cxl_command_info *info = &cmd->info;
> +
> + if (copy_to_user(&q->commands[j++], info, sizeof(*info)))
> + return -EFAULT;
> +
> + if (j == n_commands)
> + break;
> + }
> +
> + return 0;
> +}
> +
Re: [PATCH v5 7/9] cxl/mem: Add set of informational commands
On Tue, Feb 16, 2021 at 08:09:56PM -0800, Ben Widawsky wrote:
> Add initial set of formal commands beyond basic identify and command
> enumeration.
>
> Signed-off-by: Ben Widawsky
> Reviewed-by: Dan Williams
Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Jonathan Cameron (v2)
> ---
> drivers/cxl/mem.c| 9 +
> include/uapi/linux/cxl_mem.h | 5 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index e31b3045e231..6d7d3870b5da 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -45,12 +45,16 @@
> enum opcode {
> CXL_MBOX_OP_INVALID = 0x,
> CXL_MBOX_OP_RAW = CXL_MBOX_OP_INVALID,
> + CXL_MBOX_OP_GET_FW_INFO = 0x0200,
> CXL_MBOX_OP_ACTIVATE_FW = 0x0202,
> CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
> CXL_MBOX_OP_GET_LOG = 0x0401,
> CXL_MBOX_OP_IDENTIFY= 0x4000,
> + CXL_MBOX_OP_GET_PARTITION_INFO = 0x4100,
> CXL_MBOX_OP_SET_PARTITION_INFO = 0x4101,
> + CXL_MBOX_OP_GET_LSA = 0x4102,
> CXL_MBOX_OP_SET_LSA = 0x4103,
> + CXL_MBOX_OP_GET_HEALTH_INFO = 0x4200,
> CXL_MBOX_OP_SET_SHUTDOWN_STATE = 0x4204,
> CXL_MBOX_OP_SCAN_MEDIA = 0x4304,
> CXL_MBOX_OP_GET_SCAN_MEDIA = 0x4305,
> @@ -171,6 +175,11 @@ static struct cxl_mem_command mem_commands[] = {
> CXL_CMD(RAW, ~0, ~0, 0),
> #endif
> CXL_CMD(GET_SUPPORTED_LOGS, 0, ~0, CXL_CMD_FLAG_FORCE_ENABLE),
> + CXL_CMD(GET_FW_INFO, 0, 0x50, 0),
> + CXL_CMD(GET_PARTITION_INFO, 0, 0x20, 0),
> + CXL_CMD(GET_LSA, 0x8, ~0, 0),
> + CXL_CMD(GET_HEALTH_INFO, 0, 0x12, 0),
> + CXL_CMD(GET_LOG, 0x18, ~0, CXL_CMD_FLAG_FORCE_ENABLE),
> };
>
> /*
> diff --git a/include/uapi/linux/cxl_mem.h b/include/uapi/linux/cxl_mem.h
> index 59227f82a4c1..3155382dfc9b 100644
> --- a/include/uapi/linux/cxl_mem.h
> +++ b/include/uapi/linux/cxl_mem.h
> @@ -24,6 +24,11 @@
> ___C(IDENTIFY, "Identify Command"), \
> ___C(RAW, "Raw device command"), \
> ___C(GET_SUPPORTED_LOGS, "Get Supported Logs"), \
> + ___C(GET_FW_INFO, "Get FW Info"), \
> + ___C(GET_PARTITION_INFO, "Get Partition Information"),\
> + ___C(GET_LSA, "Get Label Storage Area"), \
> + ___C(GET_HEALTH_INFO, "Get Health Info"), \
> + ___C(GET_LOG, "Get Log"), \
> ___C(MAX, "invalid / last command")
>
> #define ___C(a, b) CXL_MEM_COMMAND_ID_##a
> --
> 2.30.1
>
Re: [PATCH v5 6/9] cxl/mem: Enable commands via CEL
> +static inline struct cxl_mem_command *cxl_mem_find_command(u16 opcode)
> +{
> + struct cxl_mem_command *c;
> +
> + cxl_for_each_cmd(c)
Would you be amenable to adding {
> + if (c->opcode == opcode)
> + return c;
> +
and } here
(and in the code below as well where cxl_for_each_cmd is used?)
Regardless of that:
Reviewed-by: Konrad Rzeszutek Wilk
Re: [PATCH v5 5/9] cxl/mem: Add a "RAW" send command
On Tue, Feb 16, 2021 at 08:09:54PM -0800, Ben Widawsky wrote: > The CXL memory device send interface will have a number of supported > commands. The raw command is not such a command. Raw commands allow > userspace to send a specified opcode to the underlying hardware and > bypass all driver checks on the command. The primary use for this > command is to [begrudgingly] allow undocumented vendor specific hardware > commands. > > While not the main motivation, it also allows prototyping new hardware > commands without a driver patch and rebuild. > > While this all sounds very powerful it comes with a couple of caveats: > 1. Bug reports using raw commands will not get the same level of >attention as bug reports using supported commands (via taint). > 2. Supported commands will be rejected by the RAW command. > > With this comes new debugfs knob to allow full access to your toes with > your weapon of choice. > > Cc: Ariel Sibley > Signed-off-by: Ben Widawsky > Reviewed-by: Dan Williams (v2) > Reviewed-by: Jonathan Cameron Reviewed-by: Konrad Rzeszutek Wilk
[PATCH net] tcp: fix keepalive when data remain undelivered
From: Enke Chen
TCP keepalive does not timeout under the condition that network connection
is lost and data remain undelivered (incl. retransmit). A very simple
scenarios of the failure is to write data to a tcp socket after the network
connection is lost.
Under the specified condition the keepalive timeout is not evaluated in
the keepalive timer. That is the primary cause of the failure. In addition,
the keepalive probe is not sent out in the keepalive timer. Although packet
retransmit or 0-window probe can serve a similar purpose, they have their
own timers and backoffs that are generally not aligned with the keepalive
parameters for probes and timeout.
As the timing and conditions of the events involved are random, the tcp
keepalive can fail randomly. Given the randomness of the failures, fixing
the issue would not cause any backward compatibility issues. As was well
said, "Determinism is a special case of randomness".
The fix in this patch consists of the following:
a. Always evaluate the keepalive timeout in the keepalive timer.
b. Always send out the keepalive probe in the keepalive timer (post the
keepalive idle time). Given that the keepalive intervals are usually
in the range of 30 - 60 seconds, there is no need for an optimization
to further reduce the number of keepalive probes in the presence of
packet retransmit.
c. Use the elapsed time (instead of the 0-window probe counter) in
evaluating tcp keepalive timeout.
Thanks to Eric Dumazet, Neal Cardwell, and Yuchung Cheng for helpful
discussions about the issue and options for fixing it.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2 Initial git repository build")
Signed-off-by: Enke Chen
---
net/ipv4/tcp_timer.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index 4ef08079ccfa..16a044da20db 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -708,29 +708,23 @@ static void tcp_keepalive_timer (struct timer_list *t)
((1 << sk->sk_state) & (TCPF_CLOSE | TCPF_SYN_SENT)))
goto out;
- elapsed = keepalive_time_when(tp);
-
- /* It is alive without keepalive 8) */
- if (tp->packets_out || !tcp_write_queue_empty(sk))
- goto resched;
-
elapsed = keepalive_time_elapsed(tp);
if (elapsed >= keepalive_time_when(tp)) {
/* If the TCP_USER_TIMEOUT option is enabled, use that
* to determine when to timeout instead.
*/
- if ((icsk->icsk_user_timeout != 0 &&
- elapsed >= msecs_to_jiffies(icsk->icsk_user_timeout) &&
- icsk->icsk_probes_out > 0) ||
- (icsk->icsk_user_timeout == 0 &&
- icsk->icsk_probes_out >= keepalive_probes(tp))) {
+ u32 timeout = icsk->icsk_user_timeout ?
+ msecs_to_jiffies(icsk->icsk_user_timeout) :
+ keepalive_intvl_when(tp) * keepalive_probes(tp) +
+ keepalive_time_when(tp);
+
+ if (elapsed >= timeout) {
tcp_send_active_reset(sk, GFP_ATOMIC);
tcp_write_err(sk);
goto out;
}
if (tcp_write_wakeup(sk, LINUX_MIB_TCPKEEPALIVE) <= 0) {
- icsk->icsk_probes_out++;
elapsed = keepalive_intvl_when(tp);
} else {
/* If keepalive was lost due to local congestion,
@@ -744,8 +738,6 @@ static void tcp_keepalive_timer (struct timer_list *t)
}
sk_mem_reclaim(sk);
-
-resched:
inet_csk_reset_keepalive_timer (sk, elapsed);
goto out;
--
2.29.2
Re: [PATCH v5 1/9] cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints
On Tue, Feb 16, 2021 at 08:09:50PM -0800, Ben Widawsky wrote: > From: Dan Williams > > The CXL.mem protocol allows a device to act as a provider of "System > RAM" and/or "Persistent Memory" that is fully coherent as if the memory > was attached to the typical CPU memory controller. > > With the CXL-2.0 specification a PCI endpoint can implement a "Type-3" > device interface and give the operating system control over "Host > Managed Device Memory". See section 2.3 Type 3 CXL Device. > > The memory range exported by the device may optionally be described by > the platform firmware memory map, or by infrastructure like LIBNVDIMM to > provision persistent memory capacity from one, or more, CXL.mem devices. > > A pre-requisite for Linux-managed memory-capacity provisioning is this > cxl_mem driver that can speak the mailbox protocol defined in section > 8.2.8.4 Mailbox Registers. > > For now just land the initial driver boiler-plate and Documentation/ > infrastructure. > > Link: https://www.computeexpresslink.org/download-the-specification > Cc: Jonathan Corbet > Signed-off-by: Dan Williams > Signed-off-by: Ben Widawsky > Acked-by: David Rientjes (v1) Reviewed-by: Konrad Rzeszutek Wilk Albeit you may want to modify 2020 to 2021 in the Copyright sections.
[PATCH v2] powerpc/kexec_file: Restore FDT size estimation for kdump kernel
Commit 2377c92e37fe ("powerpc/kexec_file: fix FDT size estimation for kdump
kernel") fixed how elf64_load() estimates the FDT size needed by the
crashdump kernel.
At the same time, commit 130b2d59cec0 ("powerpc: Use common
of_kexec_alloc_and_setup_fdt()") changed the same code to use the generic
function of_kexec_alloc_and_setup_fdt() to calculate the FDT size. That
change made the code overestimate it a bit by counting twice the space
required for the kernel command line and /chosen properties.
Therefore change kexec_fdt_totalsize_ppc64() to calculate just the extra
space needed by the kdump kernel, and change the function name so that it
better reflects what the function is now doing.
Signed-off-by: Thiago Jung Bauermann
Reviewed-by: Lakshmi Ramasubramanian
---
arch/powerpc/include/asm/kexec.h | 2 +-
arch/powerpc/kexec/elf_64.c | 2 +-
arch/powerpc/kexec/file_load_64.c | 26 --
3 files changed, 10 insertions(+), 20 deletions(-)
Applies on top of next-20210219.
Changes since v1:
- Adjusted comment describing kexec_extra_fdt_size_ppc64() as suggested
by Lakshmi.
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index baab158e215c..5a11cc8d2350 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -128,7 +128,7 @@ int load_crashdump_segments_ppc64(struct kimage *image,
int setup_purgatory_ppc64(struct kimage *image, const void *slave_code,
const void *fdt, unsigned long kernel_load_addr,
unsigned long fdt_load_addr);
-unsigned int kexec_fdt_totalsize_ppc64(struct kimage *image);
+unsigned int kexec_extra_fdt_size_ppc64(struct kimage *image);
int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
unsigned long initrd_load_addr,
unsigned long initrd_len, const char *cmdline);
diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index 0492ca6003f3..5a569bb51349 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -104,7 +104,7 @@ static void *elf64_load(struct kimage *image, char
*kernel_buf,
fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
initrd_len, cmdline,
- kexec_fdt_totalsize_ppc64(image));
+ kexec_extra_fdt_size_ppc64(image));
if (!fdt) {
pr_err("Error setting up the new device tree.\n");
ret = -EINVAL;
diff --git a/arch/powerpc/kexec/file_load_64.c
b/arch/powerpc/kexec/file_load_64.c
index 3609de30a170..297f73795a1f 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -927,37 +927,27 @@ int setup_purgatory_ppc64(struct kimage *image, const
void *slave_code,
}
/**
- * kexec_fdt_totalsize_ppc64 - Return the estimated size needed to setup FDT
- * for kexec/kdump kernel.
- * @image: kexec image being loaded.
+ * kexec_extra_fdt_size_ppc64 - Return the estimated additional size needed to
+ * setup FDT for kexec/kdump kernel.
+ * @image: kexec image being loaded.
*
- * Returns the estimated size needed for kexec/kdump kernel FDT.
+ * Returns the estimated extra size needed for kexec/kdump kernel FDT.
*/
-unsigned int kexec_fdt_totalsize_ppc64(struct kimage *image)
+unsigned int kexec_extra_fdt_size_ppc64(struct kimage *image)
{
- unsigned int fdt_size;
u64 usm_entries;
- /*
-* The below estimate more than accounts for a typical kexec case where
-* the additional space is to accommodate things like kexec cmdline,
-* chosen node with properties for initrd start & end addresses and
-* a property to indicate kexec boot..
-*/
- fdt_size = fdt_totalsize(initial_boot_params) + (2 * COMMAND_LINE_SIZE);
if (image->type != KEXEC_TYPE_CRASH)
- return fdt_size;
+ return 0;
/*
-* For kdump kernel, also account for linux,usable-memory and
+* For kdump kernel, account for linux,usable-memory and
* linux,drconf-usable-memory properties. Get an approximate on the
* number of usable memory entries and use for FDT size estimation.
*/
usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
(2 * (resource_size(&crashk_res) / drmem_lmb_size(;
- fdt_size += (unsigned int)(usm_entries * sizeof(u64));
-
- return fdt_size;
+ return (unsigned int)(usm_entries * sizeof(u64));
}
/**
Re: [RFC][PATCH 6/6] objtool,x86: Rewrite retpoline thunk calls
On Fri, Feb 19, 2021 at 11:01:58PM +0100, Peter Zijlstra wrote: > We could, but it so happens Joerg is also wanting negative features. Juergen. > So I was thikning that perhaps we can convince Boris they're not > really all that aweful after all :-) Well, I'm not crazy about this, TBH - I totally agree with Josh: "with objtool generating code, it's going to be a maze to figure out where the generated code is coming from" and without a real good reason to do this, what's the point? I know, because we can. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] memcg: charge before adding to swapcache on swapin
On Fri, Feb 19, 2021 at 02:44:05PM -0800, Shakeel Butt wrote:
> Currently the kernel adds the page, allocated for swapin, to the
> swapcache before charging the page. This is fine but now we want a
> per-memcg swapcache stat which is essential for folks who wants to
> transparently migrate from cgroup v1's memsw to cgroup v2's memory and
> swap counters.
>
> To correctly maintain the per-memcg swapcache stat, one option which
> this patch has adopted is to charge the page before adding it to
> swapcache. One challenge in this option is the failure case of
> add_to_swap_cache() on which we need to undo the mem_cgroup_charge().
> Specifically undoing mem_cgroup_uncharge_swap() is not simple.
>
> This patch circumvent this specific issue by removing the failure path
> of add_to_swap_cache() by providing __GFP_NOFAIL. Please note that in
> this specific situation ENOMEM was the only possible failure of
> add_to_swap_cache() which is removed by using __GFP_NOFAIL.
>
> Another option was to use __mod_memcg_lruvec_state(NR_SWAPCACHE) in
> mem_cgroup_charge() but then we need to take of the do_swap_page() case
> where synchronous swap devices bypass the swapcache. The do_swap_page()
> already does hackery to set and reset PageSwapCache bit to make
> mem_cgroup_charge() execute the swap accounting code and then we would
> need to add additional parameter to tell to not touch NR_SWAPCACHE stat
> as that code patch bypass swapcache.
>
> This patch added memcg charging API explicitly foe swapin pages and
> cleaned up do_swap_page() to not set and reset PageSwapCache bit.
>
> Signed-off-by: Shakeel Butt
The patch makes sense to me. While it extends the charge interface, I
actually quite like that it charges the page earlier - before putting
it into wider circulation. It's a step in the right direction.
But IMO the semantics of mem_cgroup_charge_swapin_page() are a bit too
fickle: the __GFP_NOFAIL in add_to_swap_cache() works around it, but
having a must-not-fail-after-this line makes the code tricky to work
on and error prone.
It would be nicer to do a proper transaction sequence.
> @@ -497,16 +497,15 @@ struct page *__read_swap_cache_async(swp_entry_t entry,
> gfp_t gfp_mask,
> __SetPageLocked(page);
> __SetPageSwapBacked(page);
>
> - /* May fail (-ENOMEM) if XArray node allocation failed. */
> - if (add_to_swap_cache(page, entry, gfp_mask & GFP_RECLAIM_MASK,
> &shadow)) {
> - put_swap_page(page, entry);
> + if (mem_cgroup_charge_swapin_page(page, NULL, gfp_mask, entry))
> goto fail_unlock;
> - }
>
> - if (mem_cgroup_charge(page, NULL, gfp_mask)) {
> - delete_from_swap_cache(page);
> - goto fail_unlock;
> - }
> + /*
> + * Use __GFP_NOFAIL to not worry about undoing the changes done by
> + * mem_cgroup_charge_swapin_page() on failure of add_to_swap_cache().
> + */
> + add_to_swap_cache(page, entry,
> + (gfp_mask|__GFP_NOFAIL) & GFP_RECLAIM_MASK, &shadow);
How about:
mem_cgroup_charge_swapin_page()
add_to_swap_cache()
mem_cgroup_finish_swapin_page()
where finish_swapin_page() only uncharges the swap entry (on cgroup1)
once the swap->memory transition is complete?
Otherwise the patch looks good to me.
Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays
On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote:
>> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote:
>>> So one thing that has been on my mind for a while: I'd really like
>>> to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb
>>> to swiotlb the main difference seems to be:
>>>
>>> - additional reasons to bounce I/O vs the plain DMA capable
>>> - the possibility to do a hypercall on arm/arm64
>>> - an extra translation layer before doing the phys_to_dma and vice
>>>versa
>>> - an special memory allocator
>>>
>>> I wonder if inbetween a few jump labels or other no overhead enablement
>>> options and possibly better use of the dma_range_map we could kill
>>> off most of swiotlb-xen instead of maintaining all this code duplication?
>> So I looked at this a bit more.
>>
>> For x86 with XENFEAT_auto_translated_physmap (how common is that?)
> Juergen, Boris please correct me if I am wrong, but that
> XENFEAT_auto_translated_physmap
> only works for PVH guests?
That's both HVM and PVH (for dom0 it's only PVH).
-boris
>
>> pfn_to_gfn is a nop, so plain phys_to_dma/dma_to_phys do work as-is.
>>
>> xen_arch_need_swiotlb always returns true for x86, and
>> range_straddles_page_boundary should never be true for the
>> XENFEAT_auto_translated_physmap case.
> Correct. The kernel should have no clue of what the real MFNs are
> for PFNs.
>> So as far as I can tell the mapping fast path for the
>> XENFEAT_auto_translated_physmap can be trivially reused from swiotlb.
>>
>> That leaves us with the next more complicated case, x86 or fully cache
>> coherent arm{,64} without XENFEAT_auto_translated_physmap. In that case
>> we need to patch in a phys_to_dma/dma_to_phys that performs the MFN
>> lookup, which could be done using alternatives or jump labels.
>> I think if that is done right we should also be able to let that cover
>> the foreign pages in is_xen_swiotlb_buffer/is_swiotlb_buffer, but
>> in that worst case that would need another alternative / jump label.
>>
>> For non-coherent arm{,64} we'd also need to use alternatives or jump
>> labels to for the cache maintainance ops, but that isn't a hard problem
>> either.
>>
>>
Re: [GIT PULL] cifs fixes
Hi Linus, >> Do you know about the Zen3 status, I was thinking to replace the system >> by this one with AMD Ryzen 9 5950X: > > I have heard nothing but good things about Zen3 so far (apart from > apparently people complaining about availability), but it's only been > out a few months, so obviously coverage is somewhat limited. > > I wish AMD hadn't decimated their Linux team (several years ago), and > they definitely had some embarrassing issues early on with Zen (apart > from the Zen 1 stability issues, they've screwed up rdrand at least > three times, iirc). But I've yet to hear of any Zen 3 issues, and I > suspect I'll upgrade when Threadripper comes out (I've become quite > spoiled by the build speeds of my Threadripper 3970X - the only thing > I miss is the better 'perf' support from Intel PEBS). > > Note that I'm not necessarily the person who would hear about any > issues first, though, so take the above with a pinch of salt. Thanks for the hints! While we're waiting for the Ryzen 9 5950X machine to get ready, I upgraded the Ryzen Threadripper 2950X to a 5.10 kernel and we didn't had a freeze yet again. Do you think 5.10 would be good for the Ryzen 9 5950X too? Thanks! metze signature.asc Description: OpenPGP digital signature
[PATCH] drivers: firmware: fix kconfig dependency on CRYPTO
commit 72304490d9df7d6af2e6851cc5762908abd52889 Author: Julian Braha Date: Fri Feb 19 18:36:22 2021 -0500 drivers: firmware: fix kconfig dependency on CRYPTO When EFI_EMBEDDED_FIRMWARE is enabled and CRYPTO is disabled, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for CRYPTO_LIB_SHA256 Depends on [n]: CRYPTO [=n] Selected by [y]: - EFI_EMBEDDED_FIRMWARE [=y] && EFI [=y] This is because EFI_EMBEDDED_FIRMWARE selects CRYPTO_LIB_SHA256, without depending on or selecting CRYPTO, despite that config option being subordinate to CRYPTO. Signed-off-by: Julian Braha diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig index 2c3dac5ecb36..f914da9845ac 100644 --- a/drivers/firmware/efi/Kconfig +++ b/drivers/firmware/efi/Kconfig @@ -248,6 +248,7 @@ endmenu config EFI_EMBEDDED_FIRMWARE bool depends on EFI + select CRYPTO select CRYPTO_LIB_SHA256 config UEFI_CPER
Re: [PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux
On 2/19/21 1:52 PM, Lyude Paul wrote:
> Since we're about to be adding some more fields and update this
> documentation, let's rewrap it to the new column limit of 100 beforehand.
> No actual doc or functional changes are made here.
>
The preferred column limit is still 80.
For some (exceptional) cases, going up to 100 is OK,
but I don't see any reason here to go beyond 80.
> Signed-off-by: Lyude Paul
> ---
> include/drm/drm_dp_helper.h | 42 -
> 1 file changed, 18 insertions(+), 24 deletions(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index edffd1dcca3e..2891a98eebc8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1839,34 +1839,28 @@ struct drm_dp_aux_cec {
> * @crc_count: counter of captured frame CRCs
> * @transfer: transfers a message representing a single AUX transaction
> *
> - * The .dev field should be set to a pointer to the device that implements
> - * the AUX channel.
> + * The .dev field should be set to a pointer to the device that implements
> the AUX channel.
> *
> - * The .name field may be used to specify the name of the I2C adapter. If
> set to
> - * NULL, dev_name() of .dev will be used.
> + * The .name field may be used to specify the name of the I2C adapter. If
> set to NULL, dev_name() of
> + * .dev will be used.
> *
> - * Drivers provide a hardware-specific implementation of how transactions
> - * are executed via the .transfer() function. A pointer to a drm_dp_aux_msg
> - * structure describing the transaction is passed into this function. Upon
> - * success, the implementation should return the number of payload bytes
> - * that were transferred, or a negative error-code on failure. Helpers
> - * propagate errors from the .transfer() function, with the exception of
> - * the -EBUSY error, which causes a transaction to be retried. On a short,
> - * helpers will return -EPROTO to make it simpler to check for failure.
> + * Drivers provide a hardware-specific implementation of how transactions
> are executed via the
> + * .transfer() function. A pointer to a drm_dp_aux_msg structure describing
> the transaction is
> + * passed into this function. Upon success, the implementation should return
> the number of payload
> + * bytes that were transferred, or a negative error-code on failure. Helpers
> propagate errors from
> + * the .transfer() function, with the exception of the -EBUSY error, which
> causes a transaction to
> + * be retried. On a short, helpers will return -EPROTO to make it simpler to
> check for failure.
> *
> - * An AUX channel can also be used to transport I2C messages to a sink. A
> - * typical application of that is to access an EDID that's present in the
> - * sink device. The .transfer() function can also be used to execute such
> - * transactions. The drm_dp_aux_register() function registers an I2C
> - * adapter that can be passed to drm_probe_ddc(). Upon removal, drivers
> - * should call drm_dp_aux_unregister() to remove the I2C adapter.
> - * The I2C adapter uses long transfers by default; if a partial response is
> - * received, the adapter will drop down to the size given by the partial
> - * response for this transaction only.
> + * An AUX channel can also be used to transport I2C messages to a sink. A
> typical application of
> + * that is to access an EDID that's present in the sink device. The
> .transfer() function can also be
> + * used to execute such transactions. The drm_dp_aux_register() function
> registers an I2C adapter
> + * that can be passed to drm_probe_ddc(). Upon removal, drivers should call
> drm_dp_aux_unregister()
> + * to remove the I2C adapter. The I2C adapter uses long transfers by
> default; if a partial response
> + * is received, the adapter will drop down to the size given by the partial
> response for this
> + * transaction only.
> *
> - * Note that the aux helper code assumes that the .transfer() function
> - * only modifies the reply field of the drm_dp_aux_msg structure. The
> - * retry logic and i2c helpers assume this is the case.
> + * Note that the aux helper code assumes that the .transfer() function only
> modifies the reply field
> + * of the drm_dp_aux_msg structure. The retry logic and i2c helpers assume
> this is the case.
> */
> struct drm_dp_aux {
> const char *name;
>
--
~Randy
Re: [PATCH] powerpc/kexec_file: Restore FDT size estimation for kdump kernel
Lakshmi Ramasubramanian writes: > On 2/19/21 6:25 AM, Thiago Jung Bauermann wrote: > > One small nit in the function header (please see below), but otherwise the > change looks good. > > Reviewed-by: Lakshmi Ramasubramanian Thanks for your review. I incorporated your suggestion and will send v2 shortly. >> --- a/arch/powerpc/kexec/file_load_64.c >> +++ b/arch/powerpc/kexec/file_load_64.c >> @@ -927,37 +927,27 @@ int setup_purgatory_ppc64(struct kimage *image, const >> void *slave_code, >> } >> /** >> - * kexec_fdt_totalsize_ppc64 - Return the estimated size needed to setup FDT >> - * for kexec/kdump kernel. >> - * @image: kexec image being loaded. >> + * kexec_extra_fdt_size_ppc63 - Return the estimated size needed to setup >> FDT > > Perhaps change to > > "Return the estimated additional size needed to setup FDT for kexec/kdump > kernel"? That's better indeed. I also hadn't noticed that I changed ppc64 to ppc63. Fixed as well. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH 02/30] drm/dp: Fixup kernel docs for struct drm_dp_aux
On 2/19/21 1:52 PM, Lyude Paul wrote: > * Make sure that struct members are referred to using @, otherwise they > won't be formatted as such > * Make sure to refer to other struct types using & so they link back to > each struct's definition > * Make sure to precede constant values with % so they're formatted > correctly > > Signed-off-by: Lyude Paul Acked-by: Randy Dunlap Thanks. > --- > include/drm/drm_dp_helper.h | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > -- ~Randy
[PATCH 9/9] ASoC: fsl: p1022_ds: remove useless assignment
cppcheck warning: sound/soc/fsl/p1022_ds.c:344:6: style: Redundant initialization for 'ret'. The initialized value is overwritten before it is read. [redundantInitialization] ret = fsl_asoc_get_dma_channel(np, "fsl,playback-dma", &mdata->dai[0], ^ sound/soc/fsl/p1022_ds.c:203:10: note: ret is initialized int ret = -ENODEV; ^ sound/soc/fsl/p1022_ds.c:344:6: note: ret is overwritten ret = fsl_asoc_get_dma_channel(np, "fsl,playback-dma", &mdata->dai[0], ^ Signed-off-by: Pierre-Louis Bossart --- sound/soc/fsl/p1022_ds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c index ac68d2238045..317c767b0099 100644 --- a/sound/soc/fsl/p1022_ds.c +++ b/sound/soc/fsl/p1022_ds.c @@ -200,7 +200,7 @@ static int p1022_ds_probe(struct platform_device *pdev) struct device_node *codec_np = NULL; struct machine_data *mdata; struct snd_soc_dai_link_component *comp; - int ret = -ENODEV; + int ret; const char *sprop; const u32 *iprop; -- 2.25.1
[PATCH 6/9] ASoC: fsl: imx-hdmi: remove unused structure members
cppcheck warning:
sound/soc/fsl/imx-hdmi.c:21:16: style: struct member
'cpu_priv::sysclk_freq' is never used. [unusedStructMember]
unsigned long sysclk_freq[2];
^
Additional checks show the sysclk_dir member is also not used.
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/fsl/imx-hdmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
index dbbb7618351c..1ebcb9a2336b 100644
--- a/sound/soc/fsl/imx-hdmi.c
+++ b/sound/soc/fsl/imx-hdmi.c
@@ -10,16 +10,12 @@
/**
* struct cpu_priv - CPU private data
- * @sysclk_freq: SYSCLK rates for set_sysclk()
- * @sysclk_dir: SYSCLK directions for set_sysclk()
* @sysclk_id: SYSCLK ids for set_sysclk()
* @slot_width: Slot width of each frame
*
* Note: [1] for tx and [0] for rx
*/
struct cpu_priv {
- unsigned long sysclk_freq[2];
- u32 sysclk_dir[2];
u32 sysclk_id[2];
u32 slot_width;
};
--
2.25.1
[PATCH 7/9] ASoC: fsl: mpc5200: signed parameter in snprintf format
cppcheck warning: sound/soc/fsl/mpc5200_dma.c:414:2: warning: %u in format string (no. 1) requires 'unsigned int' but the argument type is 'signed int'. [invalidPrintfArgType_uint] snprintf(psc_dma->name, sizeof psc_dma->name, "PSC%u", psc_dma->id); ^ Also fix sizeof use, missing parentheses reported by checkpatch.pl Signed-off-by: Pierre-Louis Bossart --- sound/soc/fsl/mpc5200_dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c index 231984882176..6c65cd858b0b 100644 --- a/sound/soc/fsl/mpc5200_dma.c +++ b/sound/soc/fsl/mpc5200_dma.c @@ -411,7 +411,7 @@ int mpc5200_audio_dma_create(struct platform_device *op) psc_dma->dev = &op->dev; psc_dma->playback.psc_dma = psc_dma; psc_dma->capture.psc_dma = psc_dma; - snprintf(psc_dma->name, sizeof psc_dma->name, "PSC%u", psc_dma->id); + snprintf(psc_dma->name, sizeof(psc_dma->name), "PSC%d", psc_dma->id); /* Find the address of the fifo data registers and setup the * DMA tasks */ -- 2.25.1
[PATCH 8/9] ASoC: fsl: mpc8610: remove useless assignment
cppcheck warning: sound/soc/fsl/mpc8610_hpcd.c:333:6: style: Redundant initialization for 'ret'. The initialized value is overwritten before it is read. [redundantInitialization] ret = fsl_asoc_get_dma_channel(np, "fsl,playback-dma", ^ sound/soc/fsl/mpc8610_hpcd.c:193:10: note: ret is initialized int ret = -ENODEV; ^ sound/soc/fsl/mpc8610_hpcd.c:333:6: note: ret is overwritten ret = fsl_asoc_get_dma_channel(np, "fsl,playback-dma", ^ Signed-off-by: Pierre-Louis Bossart --- sound/soc/fsl/mpc8610_hpcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c index eccc833390d4..58b9ca3c4da0 100644 --- a/sound/soc/fsl/mpc8610_hpcd.c +++ b/sound/soc/fsl/mpc8610_hpcd.c @@ -190,7 +190,7 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev) struct device_node *codec_np = NULL; struct mpc8610_hpcd_data *machine_data; struct snd_soc_dai_link_component *comp; - int ret = -ENODEV; + int ret; const char *sprop; const u32 *iprop; -- 2.25.1
[PATCH 4/9] ASoC: fsl: fsl_esai: clarify expression
cppcheck warning:
sound/soc/fsl/fsl_esai.c:307:16: style: Clarify calculation precedence
for '%' and '?'. [clarifyCalculation]
clk_id % 2 ? "extal" : "fsys");
^
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/fsl/fsl_esai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 08056fa0a0fa..41b154417b92 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -304,7 +304,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai,
int clk_id,
if (IS_ERR(clksrc)) {
dev_err(dai->dev, "no assigned %s clock\n",
- clk_id % 2 ? "extal" : "fsys");
+ (clk_id % 2) ? "extal" : "fsys");
return PTR_ERR(clksrc);
}
clk_rate = clk_get_rate(clksrc);
--
2.25.1
[PATCH 3/9] ASoC: fsl: fsl_easrc: remove useless assignments
cppcheck warnings:
sound/soc/fsl/fsl_easrc.c:751:53: style: Variable 'st2_mem_alloc' is
assigned a value that is never used. [unreadVariable]
int st1_chanxexp, st1_mem_alloc = 0, st2_mem_alloc = 0;
^
sound/soc/fsl/fsl_easrc.c:1331:11: style: Variable 'size' is assigned
a value that is never used. [unreadVariable]
int size = 0;
^
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/fsl/fsl_easrc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index 636a702f37a6..725a5d3aaa02 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -710,7 +710,7 @@ static int fsl_easrc_max_ch_for_slot(struct fsl_asrc_pair
*ctx,
struct fsl_easrc_slot *slot)
{
struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
- int st1_mem_alloc = 0, st2_mem_alloc = 0;
+ int st1_mem_alloc = 0, st2_mem_alloc;
int pf_mem_alloc = 0;
int max_channels = 8 - slot->num_channel;
int channels = 0;
@@ -748,7 +748,7 @@ static int fsl_easrc_config_one_slot(struct fsl_asrc_pair
*ctx,
{
struct fsl_asrc *easrc = ctx->asrc;
struct fsl_easrc_ctx_priv *ctx_priv = ctx->private;
- int st1_chanxexp, st1_mem_alloc = 0, st2_mem_alloc = 0;
+ int st1_chanxexp, st1_mem_alloc = 0, st2_mem_alloc;
unsigned int reg0, reg1, reg2, reg3;
unsigned int addr;
@@ -1328,7 +1328,7 @@ static int fsl_easrc_stop_context(struct fsl_asrc_pair
*ctx)
{
struct fsl_asrc *easrc = ctx->asrc;
int val, i;
- int size = 0;
+ int size;
int retry = 200;
regmap_read(easrc->regmap, REG_EASRC_CC(ctx->index), &val);
--
2.25.1
[PATCH 5/9] ASoC: fsl: fsl_ssi: remove unnecessary tests
cppcheck warnings:
sound/soc/fsl/fsl_ssi.c:767:34: style: Condition 'div2' is always
false [knownConditionTrueFalse]
stccr = SSI_SxCCR_PM(pm + 1) | (div2 ? SSI_SxCCR_DIV2 : 0) |
^
sound/soc/fsl/fsl_ssi.c:722:9: note: Assignment 'div2=0', assigned value is 0
div2 = 0;
^
sound/soc/fsl/fsl_ssi.c:767:34: note: Condition 'div2' is always false
stccr = SSI_SxCCR_PM(pm + 1) | (div2 ? SSI_SxCCR_DIV2 : 0) |
^
sound/soc/fsl/fsl_ssi.c:768:4: style: Condition 'psr' is always false
[knownConditionTrueFalse]
(psr ? SSI_SxCCR_PSR : 0);
^
sound/soc/fsl/fsl_ssi.c:721:8: note: Assignment 'psr=0', assigned
value is 0
psr = 0;
^
sound/soc/fsl/fsl_ssi.c:768:4: note: Condition 'psr' is always false
(psr ? SSI_SxCCR_PSR : 0);
^
Upon further analysis, the variables 'div2' and 'psr' are set to zero
and never modified. All the tests can be removed.
Signed-off-by: Pierre-Louis Bossart
---
sound/soc/fsl/fsl_ssi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 57811743c294..c57d0428c0a3 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -747,7 +747,7 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
sub *= 10;
do_div(sub, freq);
- if (sub < savesub && !(i == 0 && psr == 0 && div2 == 0)) {
+ if (sub < savesub && !(i == 0)) {
baudrate = tmprate;
savesub = sub;
pm = i;
@@ -764,8 +764,7 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream
*substream,
return -EINVAL;
}
- stccr = SSI_SxCCR_PM(pm + 1) | (div2 ? SSI_SxCCR_DIV2 : 0) |
- (psr ? SSI_SxCCR_PSR : 0);
+ stccr = SSI_SxCCR_PM(pm + 1);
mask = SSI_SxCCR_PM_MASK | SSI_SxCCR_DIV2 | SSI_SxCCR_PSR;
/* STCCR is used for RX in synchronous mode */
--
2.25.1
