[PATCH] [v2] evm: Fix memleak in init_desc
When kmalloc() fails, tmp_tfm allocated by
crypto_alloc_shash() has not been freed, which
leads to memleak.
Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove checks against tmp_tfm before freeing.
---
security/integrity/evm/evm_crypto.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/security/integrity/evm/evm_crypto.c
b/security/integrity/evm/evm_crypto.c
index 168c3b78ac47..a6dd47eb086d 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, uint8_t
hash_algo)
{
long rc;
const char *algo;
- struct crypto_shash **tfm, *tmp_tfm;
+ struct crypto_shash **tfm, *tmp_tfm = NULL;
struct shash_desc *desc;
if (type == EVM_XATTR_HMAC) {
@@ -118,13 +118,16 @@ static struct shash_desc *init_desc(char type, uint8_t
hash_algo)
alloc:
desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
GFP_KERNEL);
- if (!desc)
+ if (!desc) {
+ crypto_free_shash(tmp_tfm);
return ERR_PTR(-ENOMEM);
+ }
desc->tfm = *tfm;
rc = crypto_shash_init(desc);
if (rc) {
+ crypto_free_shash(tmp_tfm);
kfree(desc);
return ERR_PTR(rc);
}
--
2.17.1
Re: [PATCH v4] driver core: Fix device link device name collision
On Sat, Jan 09, 2021 at 02:45:06PM -0800, Saravana Kannan wrote:
> The device link device's name was of the form:
> --
>
> This can cause name collision as reported here [1] as device names are
> not globally unique. Since device names have to be unique within the
> bus/class, add the bus/class name as a prefix to the device names used to
> construct the device link device name.
>
> So the devuce link device's name will be of the form:
> :--:
>
> [1] - https://lore.kernel.org/lkml/20201229033440.32142-1-mich...@walle.cc/
>
> Cc: sta...@vger.kernel.org
> Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
> Reported-by: Michael Walle
> Signed-off-by: Saravana Kannan
> ---
> Documentation/ABI/testing/sysfs-class-devlink | 4 +--
> .../ABI/testing/sysfs-devices-consumer| 5 ++--
> .../ABI/testing/sysfs-devices-supplier| 5 ++--
> drivers/base/core.c | 27 ++-
> include/linux/device.h| 12 +
> 5 files changed, 35 insertions(+), 18 deletions(-)
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for what needs to be done
here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
Re: [PATCH] dts64: mt7622: fix slow sd card access
I guess issue is caused by incompatible setting in uboot,but have not found which exactly so i handled it like emmc. If patch is ready to be applied please add Cc: sta...@vger.kernel.org because all kernel versions are affected (tested at least in 5.4 and 5.9). If i need to create a v2,i will add it @sean/ryder/wenbin can you tell me if sd on mt7622/bpi-r64 is maybe capable of hs400? regards Frank
Re: [PATCH] selftests: netfilter: Pass family parameter "-f" to conntrack tool
On Tue, Jan 05, 2021 at 11:31:20PM +0800, Chen Yi wrote: > Fix nft_conntrack_helper.sh false fail report: > > 1) Conntrack tool need "-f ipv6" parameter to show out ipv6 traffic items. > > 2) Sleep 1 second after background nc send packet, to make sure check > is after this statement executed. > > False report: > FAIL: ns1-lkjUemYw did not show attached helper ip set via ruleset > PASS: ns1-lkjUemYw connection on port 2121 has ftp helper attached > ... > > After fix: > PASS: ns1-2hUniwU2 connection on port 2121 has ftp helper attached > PASS: ns2-2hUniwU2 connection on port 2121 has ftp helper attached > ... Applied.
Re: [PATCH v4 1/2] misc: pvpanic: introduce device capability
On Sun, Jan 10, 2021 at 01:37:18PM +0800, zhenwei pi wrote:
> According to pvpanic spec:
> https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
>
> The guest should determine pvpanic capability by RDPT, so initialize
> capability during device probing. There is no need to register panic
> notifier callback function if no events supported.
>
> Before sending event to host side, check capability firstly.
>
> Suggested by Greg KH, use sysfs to expose capability to user space,
> also add new sysfs attribute in document.
>
> Signed-off-by: zhenwei pi
> ---
> .../ABI/testing/sysfs-bus-pci-devices-pvpanic | 7
> drivers/misc/pvpanic.c| 33 ---
> 2 files changed, 35 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> new file mode 100644
> index ..57d014a2c339
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> @@ -0,0 +1,7 @@
> +What:/sys/devices/pci:00/*/QEMU0001:00/capability
> +Date:Jan 2021
> +Contact: zhenwei pi
> +Description:
> + Read-only attribute. Capabilities of pvpanic device
> + which are supported by QEMU.
> + Format: %s.
Again, you are not saying exactly what the %s is, shouldn't you? And
this does NOT match with the code below :(
> diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
> index 951b37da5e3c..c2f6a9e866b3 100644
> --- a/drivers/misc/pvpanic.c
> +++ b/drivers/misc/pvpanic.c
> @@ -19,6 +19,22 @@
> #include
>
> static void __iomem *base;
> +static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
> +
> +static ssize_t capability_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%s%s",
> + capability & PVPANIC_PANICKED ? "PANICKED[BIT 0]\n" : "",
> + capability & PVPANIC_CRASH_LOADED ? "CRASH_LOADED[BIT 1]\n" :
> "");
Why do you have "BIT X" in here? Why would userspace care?
The rule for sysfs is "one value per file". You just printed out
multiple lines. Not good, and totally not allowed.
Also please use sysfs_emit().
thanks,
greg k-h
Re: [PATCH] netfilter: Fix memleak in nf_nat_init
On Sat, Jan 09, 2021 at 08:01:21PM +0800, Dinghao Liu wrote: > When register_pernet_subsys() fails, nf_nat_bysource > should be freed just like when nf_ct_extend_register() > fails. Applied, thanks.
Re: [PATCH v4 2/2] misc: pvpanic: introduce events device attribue
On Sun, Jan 10, 2021 at 01:37:19PM +0800, zhenwei pi wrote:
> Suggested by Paolo & Greg, add 'events' device attribute that can be
> used to limit which capabilities the driver uses.
>
> Finally, the pvpanic guest driver works by the limitation of both
> device capability and user setting.
>
> Signed-off-by: zhenwei pi
> ---
> .../ABI/testing/sysfs-bus-pci-devices-pvpanic | 7 +
> drivers/misc/pvpanic.c| 26 ++-
> 2 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> index 57d014a2c339..4750cfa0af2b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> @@ -5,3 +5,10 @@ Description:
> Read-only attribute. Capabilities of pvpanic device
> which are supported by QEMU.
> Format: %s.
> +
> +What: /sys/devices/pci:00/*/QEMU0001:00/events
> +Date: Jan 2021
> +Contact: zhenwei pi
> +Description:
> + RW attribute. Set/get which features in-use.
> + Format: %x.
Please describe the allowed values.
> diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
> index c2f6a9e866b3..07a008e15bd2 100644
> --- a/drivers/misc/pvpanic.c
> +++ b/drivers/misc/pvpanic.c
> @@ -19,8 +19,31 @@
> #include
>
> static void __iomem *base;
> +static unsigned int events = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
> static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
>
> +static ssize_t events_show(struct device *dev, struct device_attribute
> *attr, char *buf)
> +{
> + return sprintf(buf, "%x\n", events);
> +}
> +
> +static ssize_t events_store(struct device *dev, struct device_attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + unsigned int tmp;
> + int err;
> +
> + err = kstrtouint(buf, 16, );
> + if (err)
> + return err;
> +
> + events = tmp;
> +
> + return count;
> +
> +}
> +static DEVICE_ATTR_RW(events);
> +
> static ssize_t capability_show(struct device *dev,
> struct device_attribute *attr, char *buf)
> {
> @@ -32,6 +55,7 @@ static DEVICE_ATTR_RO(capability);
>
> static struct attribute *pvpanic_dev_attrs[] = {
> _attr_capability.attr,
> + _attr_events.attr,
> NULL
> };
> ATTRIBUTE_GROUPS(pvpanic_dev);
> @@ -43,7 +67,7 @@ MODULE_LICENSE("GPL");
> static void
> pvpanic_send_event(unsigned int event)
> {
> - if (event & capability)
> + if (event & capability & events)
That's just going to be so crazy to try to figure out, I'm glad I'm not
a user trying to configure this.
User apis are hard.
thanks,
greg k-h
Re: Old platforms: bring out your dead
On Sun, Jan 10, 2021 at 12:12 AM Andrew Lunn wrote: > > > Then there are ARM platforms that are old but have still seen some work > > in the past years. If I hear nothing, these will all stay, but if > > maintainers > > may want to drop them anyway, I can help with that: > > Hi Arnd > > I notice orion5x is not on this list. Is that because of Debian still > building for it? No, it was a mistake on my end, it should have been in the second list of platforms that are fairly old but still updated and possibly have users. > I just blew the dust out of my orion5x RDK and booted 5.11-rc2 on it. > orion5x_defconfig needs a few updates, but otherwise it seems to work > O.K. > > But i have no idea if there are any real users out there running > modern kernels. For this platform, I'm most interested in whether there are still users that rely on board files instead of DT. AFAIU we could just fold the DT variant into arch-mvebu like kirkwood was, right? Arnd
Re: upstream build error (11)
On Sat, Jan 9, 2021 at 11:34 PM Andrew Morton wrote: > > On Sat, 9 Jan 2021 21:41:23 +0100 Dmitry Vyukov wrote: > > > On Wed, Oct 28, 2020 at 9:31 AM syzbot > > wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit:4d09c1d9 Merge tag 'devicetree-fixes-for-5.10-1' of > > > git://.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1615899c50 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=a5c844e56cc50cdb > > > dashboard link: > > > https://syzkaller.appspot.com/bug?extid=5b0d0de84d6c65b8dd2b > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the > > > commit: > > > Reported-by: syzbot+5b0d0de84d6c65b8d...@syzkaller.appspotmail.com > > > > > > mm/process_vm_access.c:277:5: error: implicit declaration of function > > > 'in_compat_syscall'; did you mean 'in_ia32_syscall'? > > > [-Werror=implicit-function-declaration] > > > > Other build failures are piling behind this. > > > > #syz fix: mm/process_vm_access: Add missing #include /\/\/\/\/\/\/\/\ This was already fixed by this commit: https://www.spinics.net/lists/linux-mm/msg232500.html > For some reason I cant reproduce this with that .config, but presumably > this is the fix? > > > From: Andrew Morton > Subject: mm/process_vm_access.c: include compat.h > > mm/process_vm_access.c:277:5: error: implicit declaration of function > 'in_compat_syscall'; did you mean 'in_ia32_syscall'? > [-Werror=implicit-function-declaration] > > Fixes: 38dc5079da7081e "Fix compat regression in process_vm_rw()" > Reported-by: syzbot+5b0d0de84d6c65b8d...@syzkaller.appspotmail.com > Cc: Kyle Huey > Cc: Jens Axboe > Cc: Al Viro > Cc: Christoph Hellwig > Signed-off-by: Andrew Morton > --- > > mm/process_vm_access.c |1 + > 1 file changed, 1 insertion(+) > > --- a/mm/process_vm_access.c~a > +++ a/mm/process_vm_access.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > #include > #include > #include > _ > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/20210109143410.eed9923407f73c00535bb450%40linux-foundation.org.
[PATCH] scsi: ufs: A tad optimization in query upiu trace
Remove a redundant if clause in ufshcd_add_query_upiu_trace.
Signed-off-by: Avri Altman
---
drivers/scsi/ufs/ufshcd.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 53fd59ce50b2..678a520b303e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -316,19 +316,13 @@ static void ufshcd_add_cmd_upiu_trace(struct ufs_hba
*hba, unsigned int tag,
UFS_TSF_CDB);
}
-static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba, unsigned int tag,
- enum ufs_trace_str_t str_t)
+static void ufshcd_add_query_upiu_trace(struct ufs_hba *hba,
+ enum ufs_trace_str_t str_t,
+ struct utp_upiu_req *rq_rsp)
{
- struct utp_upiu_req *rq_rsp;
-
if (!trace_ufshcd_upiu_enabled())
return;
- if (str_t == UFS_QUERY_SEND)
- rq_rsp = hba->lrb[tag].ucd_req_ptr;
- else
- rq_rsp = (struct utp_upiu_req *)hba->lrb[tag].ucd_rsp_ptr;
-
trace_ufshcd_upiu(dev_name(hba->dev), str_t, _rsp->header,
_rsp->qr, UFS_TSF_OSF);
}
@@ -2876,7 +2870,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
hba->dev_cmd.complete =
- ufshcd_add_query_upiu_trace(hba, tag, UFS_QUERY_SEND);
+ ufshcd_add_query_upiu_trace(hba, UFS_QUERY_SEND, lrbp->ucd_req_ptr);
/* Make sure descriptors are ready before ringing the doorbell */
wmb();
spin_lock_irqsave(hba->host->host_lock, flags);
@@ -2886,8 +2880,8 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout);
out:
- ufshcd_add_query_upiu_trace(hba, tag,
- err ? UFS_QUERY_ERR : UFS_QUERY_COMP);
+ ufshcd_add_query_upiu_trace(hba, err ? UFS_QUERY_ERR : UFS_QUERY_COMP,
+ (struct utp_upiu_req *)lrbp->ucd_rsp_ptr);
out_put_tag:
blk_put_request(req);
--
2.25.1
Re: memory leak in mcba_usb_probe
#syz test: https://github.com/minhbq-99/linux.git 080e743dff190ee8ebec63a13ac33fe8b7e4fc9e
[PATCH] can: mcba_usb: Fix memory leak when cancelling urb
In mcba_usb_read_bulk_callback(), when we don't resubmit the urb, we need to deallocate the transfer buffer that is allocated in mcba_usb_start(). Reported-by: syzbot+57281c762a3922e14...@syzkaller.appspotmail.com Signed-off-by: Bui Quang Minh --- drivers/net/can/usb/mcba_usb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/can/usb/mcba_usb.c b/drivers/net/can/usb/mcba_usb.c index df54eb7d4b36..7375c384cbd2 100644 --- a/drivers/net/can/usb/mcba_usb.c +++ b/drivers/net/can/usb/mcba_usb.c @@ -584,6 +584,8 @@ static void mcba_usb_read_bulk_callback(struct urb *urb) case -EPIPE: case -EPROTO: case -ESHUTDOWN: + usb_free_coherent(urb->dev, urb->transfer_buffer_length, + urb->transfer_buffer, urb->transfer_dma); return; default: -- 2.17.1
Re: memory leak in mcba_usb_probe
Hello, syzbot has tested the proposed patch but the reproducer is still triggering an issue: memory leak in rxrpc_lookup_local BUG: memory leak unreferenced object 0x888118b2f300 (size 256): comm "syz-executor.5", pid 8860, jiffies 4294944050 (age 373.640s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 80 c3 18 81 88 ff ff backtrace: [<799c996d>] kmalloc include/linux/slab.h:552 [inline] [<799c996d>] kzalloc include/linux/slab.h:682 [inline] [<799c996d>] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline] [<799c996d>] rxrpc_lookup_local+0x1c1/0x760 net/rxrpc/local_object.c:244 [] rxrpc_bind+0x174/0x240 net/rxrpc/af_rxrpc.c:149 [ ] afs_open_socket+0xdb/0x200 fs/afs/rxrpc.c:64 [<29791b25>] afs_net_init+0x2b4/0x340 fs/afs/main.c:126 [<5937929d>] ops_init+0x4e/0x190 net/core/net_namespace.c:152 [<64e0e1db>] setup_net+0xde/0x2d0 net/core/net_namespace.c:342 [ ] copy_net_ns+0x19f/0x3e0 net/core/net_namespace.c:483 [<29feabb4>] create_new_namespaces+0x199/0x4f0 kernel/nsproxy.c:110 [<5ce44751>] unshare_nsproxy_namespaces+0x9b/0x120 kernel/nsproxy.c:226 [<3c257699>] ksys_unshare+0x2fe/0x5c0 kernel/fork.c:2957 [<1788a4be>] __do_sys_unshare kernel/fork.c:3025 [inline] [<1788a4be>] __se_sys_unshare kernel/fork.c:3023 [inline] [<1788a4be>] __x64_sys_unshare+0x12/0x20 kernel/fork.c:3023 [ ] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<52c5dd81>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888118afb200 (size 256): comm "syz-executor.0", pid 8858, jiffies 4294944054 (age 373.600s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 92 18 81 88 ff ff backtrace: [<799c996d>] kmalloc include/linux/slab.h:552 [inline] [<799c996d>] kzalloc include/linux/slab.h:682 [inline] [<799c996d>] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline] [<799c996d>] rxrpc_lookup_local+0x1c1/0x760 net/rxrpc/local_object.c:244 [ ] rxrpc_bind+0x174/0x240 net/rxrpc/af_rxrpc.c:149 [ ] afs_open_socket+0xdb/0x200 fs/afs/rxrpc.c:64 [<29791b25>] afs_net_init+0x2b4/0x340 fs/afs/main.c:126 [<5937929d>] ops_init+0x4e/0x190 net/core/net_namespace.c:152 [<64e0e1db>] setup_net+0xde/0x2d0 net/core/net_namespace.c:342 [ ] copy_net_ns+0x19f/0x3e0 net/core/net_namespace.c:483 [<29feabb4>] create_new_namespaces+0x199/0x4f0 kernel/nsproxy.c:110 [<5ce44751>] unshare_nsproxy_namespaces+0x9b/0x120 kernel/nsproxy.c:226 [<3c257699>] ksys_unshare+0x2fe/0x5c0 kernel/fork.c:2957 [<1788a4be>] __do_sys_unshare kernel/fork.c:3025 [inline] [<1788a4be>] __se_sys_unshare kernel/fork.c:3023 [inline] [<1788a4be>] __x64_sys_unshare+0x12/0x20 kernel/fork.c:3023 [ ] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<52c5dd81>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x8881189f4800 (size 256): comm "syz-executor.6", pid 8856, jiffies 4294944054 (age 373.600s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 c0 56 18 81 88 ff ff ..V. backtrace: [<799c996d>] kmalloc include/linux/slab.h:552 [inline] [<799c996d>] kzalloc include/linux/slab.h:682 [inline] [<799c996d>] rxrpc_alloc_local net/rxrpc/local_object.c:79 [inline] [<799c996d>] rxrpc_lookup_local+0x1c1/0x760 net/rxrpc/local_object.c:244 [ ] rxrpc_bind+0x174/0x240 net/rxrpc/af_rxrpc.c:149 [ ] afs_open_socket+0xdb/0x200 fs/afs/rxrpc.c:64 [<29791b25>] afs_net_init+0x2b4/0x340 fs/afs/main.c:126 [<5937929d>] ops_init+0x4e/0x190 net/core/net_namespace.c:152 [<64e0e1db>] setup_net+0xde/0x2d0 net/core/net_namespace.c:342 [ ] copy_net_ns+0x19f/0x3e0 net/core/net_namespace.c:483 [<29feabb4>] create_new_namespaces+0x199/0x4f0 kernel/nsproxy.c:110 [<5ce44751>] unshare_nsproxy_namespaces+0x9b/0x120 kernel/nsproxy.c:226 [<3c257699>] ksys_unshare+0x2fe/0x5c0 kernel/fork.c:2957 [<1788a4be>] __do_sys_unshare kernel/fork.c:3025 [inline] [<1788a4be>] __se_sys_unshare kernel/fork.c:3023 [inline] [<1788a4be>] __x64_sys_unshare+0x12/0x20 kernel/fork.c:3023 [ ] do_syscall_64+0x2d/0x70
[PATCH] writeback: Remove useless comment for __wakeup_flusher_threads_bdi()
From: Liao Pingfang
Remove useless comment for __wakeup_flusher_threads_bdi(), as
argument 'nr_pages' was removed.
Fixes: e8e8a0c6c9bf ("writeback: move nr_pages == 0 logic to one location")
Signed-off-by: Liao Pingfang
---
fs/fs-writeback.c | 4
1 file changed, 4 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index acfb558..05eee22 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -2099,10 +2099,6 @@ void wb_workfn(struct work_struct *work)
current->flags &= ~PF_SWAPWRITE;
}
-/*
- * Start writeback of `nr_pages' pages on this bdi. If `nr_pages' is zero,
- * write back the whole world.
- */
static void __wakeup_flusher_threads_bdi(struct backing_dev_info *bdi,
enum wb_reason reason)
{
--
1.8.3.1
Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness
On Mon, 4 Jan 2021 at 20:09, Ard Biesheuvel wrote:
>
> On Tue, 17 Nov 2020 at 14:33, Ard Biesheuvel wrote:
> >
> > On Wed, 11 Nov 2020 at 09:19, Ard Biesheuvel wrote:
> > >
> > > (+ Eric)
> > >
> > > On Thu, 5 Nov 2020 at 16:29, Ard Biesheuvel wrote:
> > > >
> > > > When reseeding the CRNG periodically, arch_get_random_seed_long() is
> > > > called to obtain entropy from an architecture specific source if one
> > > > is implemented. In most cases, these are special instructions, but in
> > > > some cases, such as on ARM, we may want to back this using firmware
> > > > calls, which are considerably more expensive.
> > > >
> > > > Another call to arch_get_random_seed_long() exists in the CRNG driver,
> > > > in add_interrupt_randomness(), which collects entropy by capturing
> > > > inter-interrupt timing and relying on interrupt jitter to provide
> > > > random bits. This is done by keeping a per-CPU state, and mixing in
> > > > the IRQ number, the cycle counter and the return address every time an
> > > > interrupt is taken, and mixing this per-CPU state into the entropy pool
> > > > every 64 invocations, or at least once per second. The entropy that is
> > > > gathered this way is credited as 1 bit of entropy. Every time this
> > > > happens, arch_get_random_seed_long() is invoked, and the result is
> > > > mixed in as well, and also credited with 1 bit of entropy.
> > > >
> > > > This means that arch_get_random_seed_long() is called at least once
> > > > per second on every CPU, which seems excessive, and doesn't really
> > > > scale, especially in a virtualization scenario where CPUs may be
> > > > oversubscribed: in cases where arch_get_random_seed_long() is backed
> > > > by an instruction that actually goes back to a shared hardware entropy
> > > > source (such as RNDRRS on ARM), we will end up hitting it hundreds of
> > > > times per second.
> > > >
> > > > So let's drop the call to arch_get_random_seed_long() from
> > > > add_interrupt_randomness(), and instead, rely on crng_reseed() to call
> > > > the arch hook to get random seed material from the platform.
> > > >
> > > > Signed-off-by: Ard Biesheuvel
> > > > ---
> > > > drivers/char/random.c | 15 +--
> > > > 1 file changed, 1 insertion(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > > > index 2a41b21623ae..a9c393c1466d 100644
> > > > --- a/drivers/char/random.c
> > > > +++ b/drivers/char/random.c
> > > > @@ -1261,8 +1261,6 @@ void add_interrupt_randomness(int irq, int
> > > > irq_flags)
> > > > cycles_tcycles = random_get_entropy();
> > > > __u32 c_high, j_high;
> > > > __u64 ip;
> > > > - unsigned long seed;
> > > > - int credit = 0;
> > > >
> > > > if (cycles == 0)
> > > > cycles = get_reg(fast_pool, regs);
> > > > @@ -1298,23 +1296,12 @@ void add_interrupt_randomness(int irq, int
> > > > irq_flags)
> > > >
> > > > fast_pool->last = now;
> > > > __mix_pool_bytes(r, _pool->pool, sizeof(fast_pool->pool));
> > > > -
> > > > - /*
> > > > -* If we have architectural seed generator, produce a seed and
> > > > -* add it to the pool. For the sake of paranoia don't let the
> > > > -* architectural seed generator dominate the input from the
> > > > -* interrupt noise.
> > > > -*/
> > > > - if (arch_get_random_seed_long()) {
> > > > - __mix_pool_bytes(r, , sizeof(seed));
> > > > - credit = 1;
> > > > - }
> > > > spin_unlock(>lock);
> > > >
> > > > fast_pool->count = 0;
> > > >
> > > > /* award one bit for the contents of the fast pool */
> > > > - credit_entropy_bits(r, credit + 1);
> > > > + credit_entropy_bits(r, 1);
> > > > }
> > > > EXPORT_SYMBOL_GPL(add_interrupt_randomness);
> > > >
> > > > --
> > > > 2.17.1
> > > >
> >
> > Ping?
>
> Ping?
Ping again?
Ted,
Acceptance of this patch is now blocking RNG related work that is in
flight for ARM and arm64. [0]
So please shout if you have any objections to this patch, or if you
don't, please ack it so it can be taken through one of the ARM trees.
Thanks,
Ard.
[0]
https://lore.kernel.org/kvmarm/20210106103453.152275-1-andre.przyw...@arm.com/
KMSAN: kernel-infoleak in move_addr_to_user (4)
Hello, syzbot found the following issue on: HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=15c8b8c750 kernel config: https://syzkaller.appspot.com/x/.config?x=2cdf4151c9653e32 dashboard link: https://syzkaller.appspot.com/bug?extid=057884e2f453e8afebc8 compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101520c750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=100b8f4f50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+057884e2f453e8afe...@syzkaller.appspotmail.com = BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 CPU: 0 PID: 8245 Comm: syz-executor868 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 kmsan_internal_check_memory+0x202/0x520 mm/kmsan/kmsan.c:402 kmsan_copy_to_user+0x9c/0xb0 mm/kmsan/kmsan_hooks.c:249 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0x1af/0x270 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:209 [inline] move_addr_to_user+0x3a2/0x640 net/socket.c:237 __sys_getsockname+0x407/0x5d0 net/socket.c:1906 __do_sys_getsockname net/socket.c:1917 [inline] __se_sys_getsockname+0x91/0xb0 net/socket.c:1914 __x64_sys_getsockname+0x4a/0x70 net/socket.c:1914 do_syscall_64+0x9f/0x140 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x441219 Code: e8 fc ab 02 00 48 83 c4 18 c3 0f 1f 80 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 0f 83 1b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffe3c24eaf8 EFLAGS: 0246 ORIG_RAX: 0033 RAX: ffda RBX: RCX: 00441219 RDX: 2000 RSI: 2100 RDI: 0003 RBP: 006cb018 R08: 004002c8 R09: 004002c8 R10: 0004 R11: 0246 R12: 00401fc0 R13: 00402050 R14: R15: Local variable address@__sys_getsockname created at: __sys_getsockname+0x91/0x5d0 net/socket.c:1891 __sys_getsockname+0x91/0x5d0 net/socket.c:1891 Bytes 2-3 of 20 are uninitialized Memory access of size 20 starts at 888124bbbdf0 Data copied to user address 2100 = --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: depmod fixes for linux-stable releases
On Sat, Jan 09, 2021 at 05:23:22PM -0800, Linus Torvalds wrote:
Ack, I think 436e980e2ed5 ("kbuild: don't hardcode depmod path") is
stable material even if it doesn't fix a bug.
Not only does the fix for that commit not make sense without the
commit in the first place, but any environment that sets depmod
somewhere else might well be an environment that still wants stable
kernels.
It may not be the traditional case, but there's little reason for the
kernel build to force that /sbin/depmod location.
I'll take it, thanks!
--
Thanks,
Sasha
Re: [PATCH v2] dt-bindings: timer: nuvoton: Clarify that interrupt of timer 0 should be specified
On Fri, Jan 8, 2021 at 6:30 PM Jonathan Neuschäfer wrote: > > The NPCM750 Timer/Watchdog Controller has multiple interrupt lines, > connected to multiple timers. The driver uses timer 0 for timer > interrupts, so the interrupt line corresponding to timer 0 should be > specified in DT. > > I removed the mention of "flags for falling edge", because the timer > controller uses high-level interrupts rather than falling-edge > interrupts, and whether flags should be specified is up the interrupt > controller's DT binding. > > Signed-off-by: Jonathan Neuschäfer Reviewed-by Avi Fishman > --- > > v2: > - Fix a typo in the word "watchdog" > --- > .../devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt| 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > index ea22dfe485bee..97258f1a1505b 100644 > --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt > @@ -6,8 +6,7 @@ timer counters. > Required properties: > - compatible : "nuvoton,npcm750-timer" for Poleg NPCM750. > - reg : Offset and length of the register set for the device. > -- interrupts : Contain the timer interrupt with flags for > -falling edge. > +- interrupts : Contain the timer interrupt of timer 0. > - clocks : phandle of timer reference clock (usually a 25 MHz > clock). > > Example: > -- > 2.29.2 > -- Regards, Avi
Re: [PATCH] irqchip: mips-cpu: set IPI domain parent chip
On Thu, 7 Jan 2021 22:36:03 +0100, Mathias Kresin wrote:
> Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
> irq_data hierarchy") the irq_data chain is valided.
>
> The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
> domain hierarchy as valid, since the ipi domain has the irq domain set
> as parent, but the parent domain has no chip set. Hence the boot ends in
> a kernel panic.
>
> [...]
Applied to irq/irqchip-next, thanks!
[1/1] irqchip: mips-cpu: set IPI domain parent chip
commit: 599b3063adf4bf041a87a69244ee36aded0d878f
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
Re: [PATCH] irqchip: Simplify the TI_PRUSS_INTC Kconfig
On Fri, 8 Jan 2021 10:29:01 -0600, Suman Anna wrote: > The TI PRUSS INTC irqchip driver handles the local interrupt controller > which is a child device of it's parent PRUSS/ICSSG device. The driver > was upstreamed in parallel with the PRUSS platform driver, and was > configurable independently previously. The PRUSS interrupt controller > is an integral part of the overall PRUSS software architecture, and is > not useful at all by itself. > > [...] Applied to irq/irqchip-next, thanks! [1/1] irqchip: Simplify the TI_PRUSS_INTC Kconfig commit: b8e594fa20d2e33d40c7a8c7c106549a35c38972 Cheers, M. -- Without deviation from the norm, progress is not possible.
[irqchip: irq/irqchip-next] irqchip/mips-cpu: Set IPI domain parent chip
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: 599b3063adf4bf041a87a69244ee36aded0d878f
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/599b3063adf4bf041a87a69244ee36aded0d878f
Author:Mathias Kresin
AuthorDate:Thu, 07 Jan 2021 22:36:03 +01:00
Committer: Marc Zyngier
CommitterDate: Sun, 10 Jan 2021 10:20:24
irqchip/mips-cpu: Set IPI domain parent chip
Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of
irq_data hierarchy") the irq_data chain is valided.
The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi
domain hierarchy as valid, since the ipi domain has the irq domain set
as parent, but the parent domain has no chip set. Hence the boot ends in
a kernel panic.
Set the chip for the parent domain as it is done in the mips gic irq
driver, to have a valid irq_data chain.
Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support")
Cc: # v5.10+
Signed-off-by: Mathias Kresin
Signed-off-by: Marc Zyngier
Link: https://lore.kernel.org/r/20210107213603.1637781-1-...@kresin.me
---
drivers/irqchip/irq-mips-cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/irqchip/irq-mips-cpu.c b/drivers/irqchip/irq-mips-cpu.c
index 95d4fd8..0bbb0b2 100644
--- a/drivers/irqchip/irq-mips-cpu.c
+++ b/drivers/irqchip/irq-mips-cpu.c
@@ -197,6 +197,13 @@ static int mips_cpu_ipi_alloc(struct irq_domain *domain,
unsigned int virq,
if (ret)
return ret;
+ ret = irq_domain_set_hwirq_and_chip(domain->parent, virq + i,
hwirq,
+ _mt_cpu_irq_controller,
+ NULL);
+
+ if (ret)
+ return ret;
+
ret = irq_set_irq_type(virq + i, IRQ_TYPE_LEVEL_HIGH);
if (ret)
return ret;
[irqchip: irq/irqchip-next] irqchip/pruss: Simplify the TI_PRUSS_INTC Kconfig
The following commit has been merged into the irq/irqchip-next branch of irqchip: Commit-ID: b8e594fa20d2e33d40c7a8c7c106549a35c38972 Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/b8e594fa20d2e33d40c7a8c7c106549a35c38972 Author:Suman Anna AuthorDate:Fri, 08 Jan 2021 10:29:01 -06:00 Committer: Marc Zyngier CommitterDate: Sun, 10 Jan 2021 10:19:14 irqchip/pruss: Simplify the TI_PRUSS_INTC Kconfig The TI PRUSS INTC irqchip driver handles the local interrupt controller which is a child device of it's parent PRUSS/ICSSG device. The driver was upstreamed in parallel with the PRUSS platform driver, and was configurable independently previously. The PRUSS interrupt controller is an integral part of the overall PRUSS software architecture, and is not useful at all by itself. Simplify the TI_PRUSS_INTC Kconfig dependencies by making it silent and selected automatically when the TI_PRUSS platform driver is enabled. Signed-off-by: Suman Anna Reviewed-by: David Lechner Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210108162901.6003-1-s-a...@ti.com --- drivers/irqchip/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 94920a5..b147f22 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -493,8 +493,9 @@ config TI_SCI_INTA_IRQCHIP TI System Controller, say Y here. Otherwise, say N. config TI_PRUSS_INTC - tristate "TI PRU-ICSS Interrupt Controller" - depends on ARCH_DAVINCI || SOC_AM33XX || SOC_AM43XX || SOC_DRA7XX || ARCH_KEYSTONE || ARCH_K3 + tristate + depends on TI_PRUSS + default TI_PRUSS select IRQ_DOMAIN help This enables support for the PRU-ICSS Local Interrupt Controller
[GIT PULL] x86/urgent for v5.11-rc3
Hi Linus, as expected, fixes started trickling in after the holidays so please pull the accumulated pile of x86 urgent fixes for 5.11. Thx. --- The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tags/x86_urgent_for_v5.11_rc3 for you to fetch changes up to a0195f314a25582b38993bf30db11c300f4f4611: x86/resctrl: Don't move a task to the same resource group (2021-01-08 09:08:03 +0100) - A fix for fanotify_mark() missing the conversion of x86_32 native syscalls which take 64-bit arguments to the compat handlers due to former having a general compat handler. (Brian Gerst) - Add a forgotten pmd page destructor call to pud_free_pmd_page() where a pmd page is freed. (Dan Williams) - Make IN/OUT insns with an u8 immediate port operand handling for SEV-ES guests more precise by using only the single port byte and not the whole s32 value of the insn decoder. (Peter Gonda) - Correct a straddling end range check before returning the proper MTRR type, when the end address is the same as top of memory. (Ying-Tsun Huang) - Change PQR_ASSOC MSR update scheme when moving a task to a resctrl resource group to avoid significant performance overhead with some resctrl workloads. (Fenghua Yu) - Avoid the actual task move overhead when the task is already in the resource group. (Fenghua Yu) Brian Gerst (1): fanotify: Fix sys_fanotify_mark() on native x86-32 Dan Williams (1): x86/mm: Fix leak of pmd ptlock Fenghua Yu (2): x86/resctrl: Use an IPI instead of task_work_add() to update PQR_ASSOC MSR x86/resctrl: Don't move a task to the same resource group Peter Gonda (1): x86/sev-es: Fix SEV-ES OUT/IN immediate opcode vc handling Ying-Tsun Huang (1): x86/mtrr: Correct the range check before performing MTRR type lookups arch/Kconfig | 6 ++ arch/x86/Kconfig | 1 + arch/x86/kernel/cpu/mtrr/generic.c | 6 +- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 117 ++--- arch/x86/kernel/sev-es-shared.c| 4 +- arch/x86/mm/pgtable.c | 2 + fs/notify/fanotify/fanotify_user.c | 17 ++--- include/linux/syscalls.h | 24 +++ 8 files changed, 94 insertions(+), 83 deletions(-) -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
[PATCH 0/1] Add software TX timestamps to the CAN devices
With the ongoing work to add BQL to Socket CAN, I figured out that it would be nice to have an easy way to mesure the latency. And one easy way to do so it to check the round trip time of the packet by doing the difference between the software rx timestamp and the software tx timestamp. rx timestamps are already available. This patch gives the missing piece: add a tx software timestamp feature to the CAN devices. Of course, the tx software timestamp might also be used for other purposes such as performance measurements of the different queuing disciplines (e.g. by checking the difference between the kernel tx software timestamp and the userland tx software timestamp). Vincent Mailhol (1): can: dev: add software tx timestamps drivers/net/can/dev.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.26.2
[PATCH 1/1] can: dev: add software tx timestamps
Call skb_tx_timestamp() within can_put_echo_skb() so that a software
tx timestamp gets attached on the skb.
There two main reasons to include this call in can_put_echo_skb():
* It easily allow to enable the tx timestamp on all devices with
just one small change.
* According to Documentation/networking/timestamping.rst, the tx
timestamps should be generated in the device driver as close as
possible, but always prior to passing the packet to the network
interface. During the call to can_put_echo_skb(), the skb gets
cloned meaning that the driver should not dereference the skb
variable anymore after can_put_echo_skb() returns. This makes
can_put_echo_skb() the very last place we can use the skb without
having to access the echo_skb[] array.
Remarks:
* By default, skb_tx_timestamp() does nothing. It needs to be
activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either
through socket options or control messages.
* The hardware rx timestamp of a local loopback message is the
hardware tx timestamp. This means that there are no needs to
implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets.
References:
Support for the error queue in CAN RAW sockets (which is needed for tx
timestamps) was introduced in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96
Signed-off-by: Vincent Mailhol
---
drivers/net/can/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 3486704c8a95..3904e0874543 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -484,6 +484,8 @@ int can_put_echo_skb(struct sk_buff *skb, struct net_device
*dev,
/* save this skb for tx interrupt echo handling */
priv->echo_skb[idx] = skb;
+
+ skb_tx_timestamp(skb);
} else {
/* locking problem with netif_stop_queue() ?? */
netdev_err(dev, "%s: BUG! echo_skb %d is occupied!\n",
__func__, idx);
--
2.26.2
Re: Old platforms: bring out your dead
On Sun, Jan 10, 2021 at 07:21:13AM +0100, Willy Tarreau wrote: > On Sat, Jan 09, 2021 at 10:52:53PM +0100, Arnd Bergmann wrote: > (... i486 ...) > > As with the other older platforms, the main question to ask is: > > Are there users that are better off running a future LTS kernel on this > > hardware than the v5.10.y version or something older? > > I think this is the most important part of the question. Because the > possible use case I've described actually doesn't correspond to a > "prod" machine but to a machine that's powered on every 5 years for > some old data recovery. In such a case users just start with an old > system (possibly the one that's still on them if present), and this > doesn't warrant an up-to-date OS. > > Moreover, just as I experienced when maintaining 2.4, there's a point > where support for old stuff starts to break again by lack of testing. > And just because of this, users shouldn't always expect to see their > old machines boot fine on a recent kernel. Sometimes there may even be > difficulties setting up a compatible toolchain. > > So actually the question shouldn't be "does anyone want such old > machines to still be supported" but "does anyone *need* them to be > supported". And I suspect that for most of them the response is "no", > it's just a convenience. What about feature obsolescence? Consider that old ssh (supporting only the v1 protocol) will no longer connect to new sshd (supporting only the v2 protocol) or older NFS supporting UDP only trying to connect to new NFS supporting only TCP. Or older NFS that does buggily support TCP and won't talk to newer machines. At one time, the suggestion would've been to use a DOS formatted floppy to transfer the data... but modern machines tend not to have floppy drives. USB pendrive? Maybe the older machine doesn't have USB. I suppose you'd have to resort to FTP at that point to move data off the old machine, or via email if you have email setup on it. Having a machine that's able to boot an old installation just means it can run, but it doesn't guarantee that it will be useful once booted to move old data onto newer machines. Over Christmas, I booted my Acorn A5000 (the very first machine to run Linux on ARM) to retrieve some old data off it - thankfully I still have an Acorn Ether1 card with an AUI interface and a 10baseT MAU to connect to my network. Sadly, support for running Linux on it has long since passed - with only 8MB and 32KiB pages, modern Linux would struggle with it, which is really the reason why support was dropped. Linux outgrew the hardware. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [RFC PATCH 1/8] rcu: Remove superfluous rdp fetch
On Sat, Jan 09, 2021 at 10:03:33AM +0100, Greg KH wrote: > On Sat, Jan 09, 2021 at 03:05:29AM +0100, Frederic Weisbecker wrote: > > Signed-off-by: Frederic Weisbecker > > Cc: Paul E. McKenney > > Cc: Rafael J. Wysocki > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > --- > > kernel/rcu/tree.c | 1 - > > 1 file changed, 1 deletion(-) > > I know I will not take patches without any changelog comments, maybe > other maintainers are more lax. Please write something real. I must admit I've been lazy. Also I shoudn't have Cc'ed stable on this one. Only a few commits are tagged for stable in this set. I'll fix that on the next round. Thanks! > > And as for sending this to stable@vger, here's my form letter: > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > >
[GIT PULL] irqchip fixes for 5.11, take #1
Hi Thomas, Happy New Year! This is the first set of fixes from the irqchip (and related) department for 5.11. On the menu this time, three notable fixes: a MIPS CPU hierarchy violation, a fix for the on-stack init of msi_alloc_info (or lack thereof), and a fix for the RPi2/3 IPI irqchip that broke on QEMU. The rest is a bunch of smaller cleanups and fixes. Please pull, M. The following changes since commit 2f5fbc4305d07725bfebaedb09e57271315691ef: irqchip/qcom-pdc: Fix phantom irq when changing between rising/falling (2020-12-12 10:46:02 +) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git tags/irqchip-fixes-5.11-1 for you to fetch changes up to 599b3063adf4bf041a87a69244ee36aded0d878f: irqchip/mips-cpu: Set IPI domain parent chip (2021-01-10 10:20:24 +) irqchip fixes for 5.11, take #1 - Fix the MIPS CPU interrupt controller hierarchy - Simplify the PRUSS Kconfig entry - Eliminate trivial build warnings on the MIPS Loongson liointc - Fix error path in devm_platform_get_irqs_affinity() - Turn the BCM2836 IPI irq_eoi callback into irq_ack - Fix initialisation of on-stack msi_alloc_info - Cleanup spurious comma in irq-sl28cpld Huacai Chen (1): irqchip/loongson-liointc: Fix build warnings John Garry (1): driver core: platform: Add extra error check in devm_platform_get_irqs_affinity() Marc Zyngier (1): irqchip/bcm2836: Fix IPI acknowledgement after conversion to handle_percpu_devid_irq Mathias Kresin (1): irqchip/mips-cpu: Set IPI domain parent chip Suman Anna (1): irqchip/pruss: Simplify the TI_PRUSS_INTC Kconfig Zenghui Yu (1): genirq/msi: Initialize msi_alloc_info before calling msi_domain_prepare_irqs() Zheng Yongjun (1): irqchip/irq-sl28cpld: Convert comma to semicolon drivers/base/platform.c| 2 ++ drivers/irqchip/Kconfig| 5 +++-- drivers/irqchip/irq-bcm2836.c | 4 ++-- drivers/irqchip/irq-loongson-liointc.c | 4 ++-- drivers/irqchip/irq-mips-cpu.c | 7 +++ drivers/irqchip/irq-sl28cpld.c | 2 +- kernel/irq/msi.c | 2 +- 7 files changed, 18 insertions(+), 8 deletions(-)
[PATCH] fs: Remove the comment for argument "cred" of vfs_open()
From: Liao Pingfang
Remove the comment for argument "cred" of vfs_open(), as
it was removed.
Fixes: ae2bb293a3e8 ("get rid of cred argument of vfs_open() and
do_dentry_open()")
Signed-off-by: Liao Pingfang
---
fs/open.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/open.c b/fs/open.c
index 1e06e44..6935570 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -923,7 +923,6 @@ char *file_path(struct file *filp, char *buf, int buflen)
* vfs_open - open the file at the given path
* @path: path to open
* @file: newly allocated file with f_flag initialized
- * @cred: credentials to use
*/
int vfs_open(const struct path *path, struct file *file)
{
--
1.8.3.1
Re: [PATCH v5 09/15] lib/test_printf.c: Use helper function to unwind array of software_nodes
Hi Andy, On Sat, Jan 09, 2021 at 11:07:33AM +0200, Andy Shevchenko wrote: > On Saturday, January 9, 2021, Laurent Pinchart wrote: > > > Hi Peter, Steven and Sergey, > > > > Could you please let us know if you're fine with this patch getting > > merged in v5.12 through the linux-media tree ? The cover letter contains > > additional details (in a nutshell, this is a cross-tree series and we > > would like to avoid topic branches if possible). > > There is already a tag by Petr. I saw that, but looking at the corresponding e-mail, there was no clear acknowledgement that we could merge this patch through a different tree. > > On Thu, Jan 07, 2021 at 01:28:32PM +, Daniel Scally wrote: > > > Use the software_node_unregister_nodes() helper function to unwind this > > > array in a cleaner way. > > > > > > Acked-by: Petr Mladek > > > Reviewed-by: Andy Shevchenko > > > Reviewed-by: Laurent Pinchart > > > Reviewed-by: Sergey Senozhatsky > > > Suggested-by: Andy Shevchenko > > > Signed-off-by: Daniel Scally > > > --- > > > Changes in v5: > > > > > > - None > > > > > > lib/test_printf.c | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/lib/test_printf.c b/lib/test_printf.c > > > index 7ac87f18a10f..7d60f24240a4 100644 > > > --- a/lib/test_printf.c > > > +++ b/lib/test_printf.c > > > @@ -644,9 +644,7 @@ static void __init fwnode_pointer(void) > > > test(second_name, "%pfwP", software_node_fwnode([1])); > > > test(third_name, "%pfwP", software_node_fwnode([2])); > > > > > > - software_node_unregister([2]); > > > - software_node_unregister([1]); > > > - software_node_unregister([0]); > > > + software_node_unregister_nodes(softnodes); > > > } > > > > > > static void __init -- Regards, Laurent Pinchart
Re: [PATCH 1/1] can: dev: add software tx timestamps
Hello Vincent,
On 1/10/21 11:35 AM, Vincent Mailhol wrote:
Call skb_tx_timestamp() within can_put_echo_skb() so that a software
tx timestamp gets attached on the skb.
[..]
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 3486704c8a95..3904e0874543 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -484,6 +484,8 @@ int can_put_echo_skb(struct sk_buff *skb, struct net_device
*dev,
/* save this skb for tx interrupt echo handling */
priv->echo_skb[idx] = skb;
+
+ skb_tx_timestamp(skb);
} else {
/* locking problem with netif_stop_queue() ?? */
netdev_err(dev, "%s: BUG! echo_skb %d is occupied!\n",
__func__, idx);
Personally, I would put the skb_tx_timestamp, before adding it to the array:
/* make settings for echo to reduce code in irq context */
skb->pkt_type = PACKET_BROADCAST;
skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->dev = dev;
+ skb_tx_timestamp(skb);
/* save this skb for tx interrupt echo handling */
priv->echo_skb[idx] = skb;
I don't think it actually matters though.
Regards,
Jeroen
Re: [PATCH 5.10 00/20] 5.10.6-rc1 review
On Thu, Jan 07, 2021 at 06:10:15PM -0700, Shuah Khan wrote: > On 1/7/21 7:33 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.6 release. > > There are 20 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat, 09 Jan 2021 14:30:35 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.6-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.10.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. > > Tested-by: Shuah Khan Thanks for testing them and letting me know. greg k-h
Re: [PATCH 5.10 00/20] 5.10.6-rc1 review
On Fri, Jan 08, 2021 at 09:41:19AM -0800, Guenter Roeck wrote: > On Thu, Jan 07, 2021 at 03:33:55PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.10.6 release. > > There are 20 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat, 09 Jan 2021 14:30:35 +. > > Anything received after that time might be too late. > > > > Build results: > total: 154 pass: 154 fail: 0 > Qemu test results: > total: 427 pass: 427 fail: 0 > > Tested-by: Guenter Roeck Thanks for testing them all and letting me know. greg k-h
Re: [PATCH 5.10 00/20] 5.10.6-rc1 review
On Fri, Jan 08, 2021 at 07:32:54AM +0530, Naresh Kamboju wrote: > On Thu, 7 Jan 2021 at 20:03, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.10.6 release. > > There are 20 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat, 09 Jan 2021 14:30:35 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.6-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.10.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. > > Tested-by: Linux Kernel Functional Testing Great, thansk for letting me know. greg k-h
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
Hi Thomas, Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer a écrit : On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > Hi Thomas, > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > Any idea what could be happening? not yet, kernel crash log of a Malta QEMU is below. update: This dirty hack lets the Malta QEMU boot again: diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point. Yes, I can confirm that your workaround works here too. Cheers, -Paul
[PATCH] arm64: dts: imx8mm-beacon: add more pinctrl states for usdhc1
The WiFi chip is capable of communication at SDR104 speeds.
Enable 100Mhz and 200MHz pinmux to support this.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index d897913537ca..988f8ab679ad 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -256,8 +256,10 @@ bluetooth {
{
#address-cells = <1>;
#size-cells = <0>;
- pinctrl-names = "default";
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <_usdhc1>;
+ pinctrl-1 = <_usdhc1_100mhz>;
+ pinctrl-2 = <_usdhc1_200mhz>;
bus-width = <4>;
non-removable;
cap-power-off-card;
--
2.25.1
[PATCH v5 mips-next 0/9] MIPS: vmlinux.lds.S sections fixes & cleanup
This series hunts the problems discovered after manual enabling of ARCH_WANT_LD_ORPHAN_WARN. Notably: - adds the missing PAGE_ALIGNED_DATA() section affecting VDSO placement (marked for stable); - stops blind catching of orphan text sections with .text.* directive; - properly stops .eh_frame section generation. Compile and runtime tested on MIPS32R2 CPS board with no issues using two different toolkits: - Binutils 2.35.1, GCC 10.2.1 (with Alpine patches); - LLVM stack: 11.0.0 and from latest Git snapshot. Since v4 [3]: - new: drop redundant .text.cps-vec creation and blind inclusion of orphan text sections via .text.* directive in vmlinux.lds.S; - don't assert SIZEOF(.rel.dyn) as it's reported that it may be not empty on certain machines and compilers (Thomas); - align GOT table like it's done for ARM64; - new: catch UBSAN's "unnamed data" sections in generic definitions when building with LD_DEAD_CODE_DATA_ELIMINATION; - collect Reviewed-bys (Kees, Nathan). Since v3 [2]: - fix the third patch as GNU stack emits .rel.dyn into VDSO for some reason if .cfi_sections is specified. Since v2 [1]: - stop discarding .eh_frame and just prevent it from generating (Kees); - drop redundant sections assertions (Fangrui); - place GOT table in .text instead of asserting as it's not empty when building with LLVM (Nathan); - catch compound literals in generic definitions when building with LD_DEAD_CODE_DATA_ELIMINATION (Kees); - collect two Reviewed-bys (Kees). Since v1 [0]: - catch .got entries too as LLD may produce it (Nathan); - check for unwanted sections to be zero-sized instead of discarding (Fangrui). [0] https://lore.kernel.org/linux-mips/20210104121729.46981-1-aloba...@pm.me [1] https://lore.kernel.org/linux-mips/20210106200713.31840-1-aloba...@pm.me [2] https://lore.kernel.org/linux-mips/20210107115120.281008-1-aloba...@pm.me [3] https://lore.kernel.org/linux-mips/20210107123331.354075-1-aloba...@pm.me Alexander Lobakin (9): MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section MIPS: CPS: don't create redundant .text.cps-vec section MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS MIPS: properly stop .eh_frame generation MIPS: vmlinux.lds.S: explicitly catch .rel.dyn symbols MIPS: vmlinux.lds.S: explicitly declare .got table vmlinux.lds.h: catch compound literals into data and BSS vmlinux.lds.h: catch UBSAN's "unnamed data" into data MIPS: select ARCH_WANT_LD_ORPHAN_WARN arch/mips/Kconfig | 1 + arch/mips/include/asm/asm.h | 18 ++ arch/mips/kernel/cps-vec.S| 1 - arch/mips/kernel/vmlinux.lds.S| 11 +-- include/asm-generic/vmlinux.lds.h | 6 +++--- 5 files changed, 31 insertions(+), 6 deletions(-) -- 2.30.0
[PATCH] arm64: dts: imx8mn-beacon-som: Configure RTC aliases
On the i.MX8MN Beacon SOM, there is an RTC chip which is fed power
from the baseboard during power off. The SNVS RTC integrated into
the SoC is not fed power. Depending on the order the modules are
loaded, this can be a problem if the external RTC isn't rtc0.
Make the alias for rtc0 point to the external RTC all the time and
rtc1 point to the SVNS in order to correctly hold date/time over
a power-cycle.
Signed-off-by: Adam Ford
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
index 67e5e5b9ddea..2120e6485393 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-beacon-som.dtsi
@@ -4,6 +4,11 @@
*/
/ {
+ aliases {
+ rtc0 =
+ rtc1 = _rtc;
+ };
+
usdhc1_pwrseq: usdhc1_pwrseq {
compatible = "mmc-pwrseq-simple";
pinctrl-names = "default";
@@ -212,7 +217,7 @@ eeprom@50 {
reg = <0x50>;
};
- rtc@51 {
+ rtc: rtc@51 {
compatible = "nxp,pcf85263";
reg = <0x51>;
};
--
2.25.1
[PATCH v5 1/2] misc: pvpanic: introduce device capability
According to pvpanic spec:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
The guest should determine pvpanic capability by RDPT, so initialize
capability during device probing. There is no need to register panic
notifier callback function if no events supported.
Before sending event to host side, check capability firstly.
Suggested by Greg KH, use sysfs to expose capability to user space,
also add new sysfs attribute in document.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 12 +++
drivers/misc/pvpanic.c| 31 ---
2 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
new file mode 100644
index ..79b7dc31cd55
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
@@ -0,0 +1,12 @@
+What: /sys/devices/pci:00/*/QEMU0001:00/capability
+Date: Jan 2021
+Contact: zhenwei pi
+Description:
+ Read-only attribute. Capabilities of pvpanic device which
+ are supported by QEMU.
+
+ Format: %x.
+
+ Detailed bit definition refers to section
+ from pvpanic device specification:
+
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 951b37da5e3c..7e5254e8af1f 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -19,6 +19,20 @@
#include
static void __iomem *base;
+static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
+
+static ssize_t capability_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sysfs_emit(buf, "%x", capability);
+}
+static DEVICE_ATTR_RO(capability);
+
+static struct attribute *pvpanic_dev_attrs[] = {
+ _attr_capability.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(pvpanic_dev);
MODULE_AUTHOR("Hu Tao ");
MODULE_DESCRIPTION("pvpanic device driver");
@@ -27,7 +41,8 @@ MODULE_LICENSE("GPL");
static void
pvpanic_send_event(unsigned int event)
{
- iowrite8(event, base);
+ if (event & capability)
+ iowrite8(event, base);
}
static int
@@ -62,8 +77,12 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
if (IS_ERR(base))
return PTR_ERR(base);
- atomic_notifier_chain_register(_notifier_list,
- _panic_nb);
+ /* initlize capability by RDPT */
+ capability &= ioread8(base);
+
+ if (capability)
+ atomic_notifier_chain_register(_notifier_list,
+ _panic_nb);
return 0;
}
@@ -71,8 +90,9 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
static int pvpanic_mmio_remove(struct platform_device *pdev)
{
- atomic_notifier_chain_unregister(_notifier_list,
-_panic_nb);
+ if (capability)
+ atomic_notifier_chain_unregister(_notifier_list,
+_panic_nb);
return 0;
}
@@ -93,6 +113,7 @@ static struct platform_driver pvpanic_mmio_driver = {
.name = "pvpanic-mmio",
.of_match_table = pvpanic_mmio_match,
.acpi_match_table = pvpanic_device_ids,
+ .dev_groups = pvpanic_dev_groups,
},
.probe = pvpanic_mmio_probe,
.remove = pvpanic_mmio_remove,
--
2.25.1
[PATCH v5 2/2] misc: pvpanic: introduce events device attribue
Suggested by Paolo & Greg, add 'events' device attribute that can be
used to limit which capabilities the driver uses.
Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 12
drivers/misc/pvpanic.c| 30 ++-
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
index 79b7dc31cd55..1936f7324155 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
+++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
@@ -10,3 +10,15 @@ Description:
Detailed bit definition refers to section
from pvpanic device specification:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
+
+What: /sys/devices/pci:00/*/QEMU0001:00/events
+Date: Jan 2021
+Contact: zhenwei pi
+Description:
+ RW attribute. Set/get which features in-use. This attribute
+ is used to enable/disable feature(s) of pvpanic device.
+ Notice that this value should be a subset of capability.
+
+ Format: %x.
+
+ Also refer to pvpanic device specification.
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
index 7e5254e8af1f..a9ac26c7b11f 100644
--- a/drivers/misc/pvpanic.c
+++ b/drivers/misc/pvpanic.c
@@ -20,6 +20,7 @@
static void __iomem *base;
static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
+static unsigned int events;
static ssize_t capability_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -28,8 +29,34 @@ static ssize_t capability_show(struct device *dev,
}
static DEVICE_ATTR_RO(capability);
+static ssize_t events_show(struct device *dev, struct device_attribute *attr,
char *buf)
+{
+ return sysfs_emit(buf, "%x", events);
+}
+
+static ssize_t events_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ unsigned int tmp;
+ int err;
+
+ err = kstrtouint(buf, 16, );
+ if (err)
+ return err;
+
+ if ((tmp & capability) != tmp)
+ return -EINVAL;
+
+ events = tmp;
+
+ return count;
+
+}
+static DEVICE_ATTR_RW(events);
+
static struct attribute *pvpanic_dev_attrs[] = {
_attr_capability.attr,
+ _attr_events.attr,
NULL
};
ATTRIBUTE_GROUPS(pvpanic_dev);
@@ -41,7 +68,7 @@ MODULE_LICENSE("GPL");
static void
pvpanic_send_event(unsigned int event)
{
- if (event & capability)
+ if (event & capability & events)
iowrite8(event, base);
}
@@ -79,6 +106,7 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
/* initlize capability by RDPT */
capability &= ioread8(base);
+ events = capability;
if (capability)
atomic_notifier_chain_register(_notifier_list,
--
2.25.1
[PATCH v5 0/2] misc: pvpanic: introduce capability & event attribute
v4 -> v5: Use sysfs_emit to export attribute value. Only allow subset of capability to set on events. Add more detailed infomation in document. v3 -> v4: Use event sysfs attribute instead of module parameter. Use driver dev_groups instead of creating files by sysfs_* API. v2 -> v3: Seperate the function to 2 parts: 1, use sysfs to expose device capability. 2, add a module parameter to set limitation by user. v1 -> v2: Remove device info log, use module parameter to expose capability. v1: The guest sides determines pvpanic capability by RDPT, before kicking host side, check the event is supported or not. zhenwei pi (2): misc: pvpanic: introduce device capability misc: pvpanic: introduce module parameter 'events' .../ABI/testing/sysfs-bus-pci-devices-pvpanic | 14 + drivers/misc/pvpanic.c| 58 +-- 2 files changed, 67 insertions(+), 5 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic -- 2.25.1
[PATCH v5 mips-next 4/9] MIPS: properly stop .eh_frame generation
Commit 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly") added
-fno-asynchronous-unwind-tables to KBUILD_CFLAGS to prevent compiler
from emitting .eh_frame symbols.
However, as MIPS heavily uses CFI, that's not enough. Use the
approach taken for x86 (as it also uses CFI) and explicitly put CFI
symbols into the .debug_frame section (except for VDSO).
This allows us to drop .eh_frame from DISCARDS as it's no longer
being generated.
Fixes: 866b6a89c6d1 ("MIPS: Add DWARF unwinding to assembly")
Suggested-by: Kees Cook
Signed-off-by: Alexander Lobakin
Reviewed-by: Kees Cook
Reviewed-by: Nathan Chancellor
---
arch/mips/include/asm/asm.h| 18 ++
arch/mips/kernel/vmlinux.lds.S | 1 -
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/asm.h b/arch/mips/include/asm/asm.h
index 3682d1a0bb80..ea4b62ece336 100644
--- a/arch/mips/include/asm/asm.h
+++ b/arch/mips/include/asm/asm.h
@@ -20,10 +20,27 @@
#include
#include
+#ifndef __VDSO__
+/*
+ * Emit CFI data in .debug_frame sections, not .eh_frame sections.
+ * We don't do DWARF unwinding at runtime, so only the offline DWARF
+ * information is useful to anyone. Note we should change this if we
+ * ever decide to enable DWARF unwinding at runtime.
+ */
+#define CFI_SECTIONS .cfi_sections .debug_frame
+#else
+ /*
+ * For the vDSO, emit both runtime unwind information and debug
+ * symbols for the .dbg file.
+ */
+#define CFI_SECTIONS
+#endif
+
/*
* LEAF - declare leaf routine
*/
#define LEAF(symbol) \
+ CFI_SECTIONS; \
.globl symbol; \
.align 2; \
.type symbol, @function; \
@@ -36,6 +53,7 @@ symbol: .frame sp, 0, ra;
\
* NESTED - declare nested routine entry point
*/
#define NESTED(symbol, framesize, rpc) \
+ CFI_SECTIONS; \
.globl symbol; \
.align 2; \
.type symbol, @function; \
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 09669a8fddec..10d8f0dcb76b 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -224,6 +224,5 @@ SECTIONS
*(.options)
*(.pdr)
*(.reginfo)
- *(.eh_frame)
}
}
--
2.30.0
[PATCH v5 mips-next 3/9] MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS
Discard GNU attributes (MIPS FP type, GNU Hash etc.) at link time as kernel doesn't use it at all. Solves a dozen of the following ld warnings (one per every file): mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' from `arch/mips/kernel/head.o' being placed in section `.gnu.attributes' mips-alpine-linux-musl-ld: warning: orphan section `.gnu.attributes' from `init/main.o' being placed in section `.gnu.attributes' Signed-off-by: Alexander Lobakin Reviewed-by: Nathan Chancellor --- arch/mips/kernel/vmlinux.lds.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index ae1d0b4bdd60..09669a8fddec 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -220,6 +220,7 @@ SECTIONS /* ABI crap starts here */ *(.MIPS.abiflags) *(.MIPS.options) + *(.gnu.attributes) *(.options) *(.pdr) *(.reginfo) -- 2.30.0
[PATCH v5 mips-next 1/9] MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section
MIPS uses its own declaration of rwdata, and thus it should be kept
in sync with the asm-generic one. Currently PAGE_ALIGNED_DATA() is
missing from the linker script, which emits the following ld
warnings:
mips-alpine-linux-musl-ld: warning: orphan section
`.data..page_aligned' from `arch/mips/kernel/vdso.o' being placed
in section `.data..page_aligned'
mips-alpine-linux-musl-ld: warning: orphan section
`.data..page_aligned' from `arch/mips/vdso/vdso-image.o' being placed
in section `.data..page_aligned'
Add the necessary declaration, so the mentioned structures will be
placed in vmlinux as intended:
80630580 D __end_once
80630580 D __start___dyndbg
80630580 D __start_once
80630580 D __stop___dyndbg
80634000 d mips_vdso_data
80638000 d vdso_data
80638580 D _gp
8063c000 T __init_begin
8063c000 D _edata
8063c000 T _sinittext
->
805a4000 D __end_init_task
805a4000 D __nosave_begin
805a4000 D __nosave_end
805a4000 d mips_vdso_data
805a8000 d vdso_data
805ac000 D mmlist_lock
805ac080 D tasklist_lock
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Cc: sta...@vger.kernel.org # 4.4+
Signed-off-by: Alexander Lobakin
Reviewed-by: Kees Cook
Reviewed-by: Nathan Chancellor
---
arch/mips/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 5e97e9d02f98..83e27a181206 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -90,6 +90,7 @@ SECTIONS
INIT_TASK_DATA(THREAD_SIZE)
NOSAVE_DATA
+ PAGE_ALIGNED_DATA(PAGE_SIZE)
CACHELINE_ALIGNED_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
READ_MOSTLY_DATA(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
DATA_DATA
--
2.30.0
[PATCH v5 mips-next 9/9] MIPS: select ARCH_WANT_LD_ORPHAN_WARN
Now, after that all the sections are explicitly described and declared in vmlinux.lds.S, we can enable ld orphan warnings to prevent from missing any new sections in future. Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor --- arch/mips/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d68df1febd25..d3e64cc0932b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -18,6 +18,7 @@ config MIPS select ARCH_USE_QUEUED_SPINLOCKS select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU select ARCH_WANT_IPC_PARSE_VERSION + select ARCH_WANT_LD_ORPHAN_WARN select BUILDTIME_TABLE_SORT select CLONE_BACKWARDS select CPU_NO_EFFICIENT_FFS if (TARGET_ISA_REV < 1) -- 2.30.0
[PATCH v5 mips-next 2/9] MIPS: CPS: don't create redundant .text.cps-vec section
A number of symbols from arch/mips/kernel/cps-vec.S is explicitly placed into '.text.cps-vec' section. There are no direct references to this section, so there's no need to form it. '.balign 0x1000' directive will work anyway. Moreover, this section was being placed in vmlinux differently depending on CONFIG_LD_DEAD_CODE_DATA_ELIMINATION: - with this option enabled, '.text.cps-vec' was being caught by '.text.[0-9a-zA-Z_]*' from include/asm-generic/vmlinux.lds.h; - without this option, '.text.cps-vec' was being caught by discouraging '.text.*' from arch/mips/kernel/vmlinux.lds.S. '.text.*' should not be used in vmlinux linker scripts at all as it silently catches any orphan text sections. So, remove both '.section .text.cps-vec' and '.text.*' from cps-vec.S and vmlinux.lds.S respectively. As said, this does not affect related functions alignment: 80116000 T mips_cps_core_entry 80116028 t not_nmi 80116200 T excep_tlbfill 80116280 T excep_xtlbfill 80116300 T excep_cache 80116380 T excep_genex 80116400 T excep_intex 80116480 T excep_ejtag 80116490 T mips_cps_core_init Signed-off-by: Alexander Lobakin --- arch/mips/kernel/cps-vec.S | 1 - arch/mips/kernel/vmlinux.lds.S | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S index 4db7ff055c9f..975343240148 100644 --- a/arch/mips/kernel/cps-vec.S +++ b/arch/mips/kernel/cps-vec.S @@ -91,7 +91,6 @@ .setpop .endm -.section .text.cps-vec .balign 0x1000 LEAF(mips_cps_core_entry) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 83e27a181206..ae1d0b4bdd60 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -66,7 +66,6 @@ SECTIONS KPROBES_TEXT IRQENTRY_TEXT SOFTIRQENTRY_TEXT - *(.text.*) *(.fixup) *(.gnu.warning) } :text = 0 -- 2.30.0
[PATCH v5 mips-next 6/9] MIPS: vmlinux.lds.S: explicitly declare .got table
LLVM stack generates GOT table when building the kernel: ld.lld: warning: :(.got) is being placed in '.got' According to the debug assertions, it's not zero-sized and thus can't be handled the way it's done for x86. Also use the ARM64 path here and place it at the end of .text section. Reported-by: Nathan Chancellor Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor --- arch/mips/kernel/vmlinux.lds.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S index 70bba1ff08da..c1c345be04ff 100644 --- a/arch/mips/kernel/vmlinux.lds.S +++ b/arch/mips/kernel/vmlinux.lds.S @@ -68,6 +68,8 @@ SECTIONS SOFTIRQENTRY_TEXT *(.fixup) *(.gnu.warning) + . = ALIGN(16); + *(.got) /* Global offset table */ } :text = 0 _etext = .; /* End of text section */ -- 2.30.0
[PATCH v5 mips-next 5/9] MIPS: vmlinux.lds.S: explicitly catch .rel.dyn symbols
According to linker warnings, both GCC and LLVM generate '.rel.dyn'
symbols:
mips-alpine-linux-musl-ld: warning: orphan section `.rel.dyn'
from `init/main.o' being placed in section `.rel.dyn'
Link-time assertion shows that this section is sometimes empty,
sometimes not, depending on machine bitness and the compiler [0]:
LD .tmp_vmlinux.kallsyms1
mips64-linux-gnu-ld: Unexpected run-time relocations (.rel) detected!
Just use the ARM64 approach and declare it in vmlinux.lds.S closer
to __init_end.
[0] https://lore.kernel.org/linux-mips/20210109111259.ga4...@alpha.franken.de
Reported-by: Thomas Bogendoerfer
Signed-off-by: Alexander Lobakin
---
arch/mips/kernel/vmlinux.lds.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
index 10d8f0dcb76b..70bba1ff08da 100644
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -137,6 +137,11 @@ SECTIONS
PERCPU_SECTION(1 << CONFIG_MIPS_L1_CACHE_SHIFT)
#endif
+ .rel.dyn : ALIGN(8) {
+ *(.rel)
+ *(.rel*)
+ }
+
#ifdef CONFIG_MIPS_ELF_APPENDED_DTB
.appended_dtb : AT(ADDR(.appended_dtb) - LOAD_OFFSET) {
*(.appended_dtb)
--
2.30.0
[PATCH v5 mips-next 8/9] vmlinux.lds.h: catch UBSAN's "unnamed data" into data
When building kernel with both LD_DEAD_CODE_DATA_ELIMINATION and UBSAN, LLVM stack generates lots of "unnamed data" sections: ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_2) is being placed in '.data.$__unnamed_2' ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_3) is being placed in '.data.$__unnamed_3' ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_4) is being placed in '.data.$__unnamed_4' ld.lld: warning: net/built-in.a(netfilter/utils.o): (.data.$__unnamed_5) is being placed in '.data.$__unnamed_5' [...] Also handle this by adding the related sections to generic definitions. Signed-off-by: Alexander Lobakin --- include/asm-generic/vmlinux.lds.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 5f2f5b1db84f..cc659e77fcb0 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -95,7 +95,7 @@ */ #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral* +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral* .data.$__unnamed_* #define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]* #define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L* #define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral* -- 2.30.0
[PATCH v5 mips-next 7/9] vmlinux.lds.h: catch compound literals into data and BSS
When building kernel with LD_DEAD_CODE_DATA_ELIMINATION, LLVM stack generates separate sections for compound literals, just like in case with enabled LTO [0]: ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o): (.data..compoundliteral.14) is being placed in '.data..compoundliteral.14' ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o): (.data..compoundliteral.15) is being placed in '.data..compoundliteral.15' ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o): (.data..compoundliteral.16) is being placed in '.data..compoundliteral.16' ld.lld: warning: drivers/built-in.a(mtd/nand/spi/gigadevice.o): (.data..compoundliteral.17) is being placed in '.data..compoundliteral.17' [...] Handle this by adding the related sections to generic definitions as suggested by Sami [0]. [0] https://lore.kernel.org/lkml/20201211184633.3213045-3-samitolva...@google.com Suggested-by: Sami Tolvanen Suggested-by: Kees Cook Signed-off-by: Alexander Lobakin Reviewed-by: Kees Cook Reviewed-by: Nathan Chancellor --- include/asm-generic/vmlinux.lds.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index b2b3d81b1535..5f2f5b1db84f 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -95,10 +95,10 @@ */ #ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION #define TEXT_MAIN .text .text.[0-9a-zA-Z_]* -#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX* +#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..L* .data..compoundliteral* #define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]* -#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* -#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* +#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]* .rodata..L* +#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]* .bss..compoundliteral* #define SBSS_MAIN .sbss .sbss.[0-9a-zA-Z_]* #else #define TEXT_MAIN .text -- 2.30.0
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
> Am 10.01.2021 um 12:35 schrieb Paul Cercueil : > > Hi Thomas, > > Le sam. 9 janv. 2021 à 1:33, Thomas Bogendoerfer > a écrit : >> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: >>> On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: >>> > Hi Thomas, >>> > >>> > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. Just for completeness, I have no such problems booting CI20/jz4780 or Skytone400/jz4730 (unpublished work) with 5.11-rc2. But may depend on board capabilites (ram size, memory layout or something else). >>> > >>> > Any idea what could be happening? >>> not yet, kernel crash log of a Malta QEMU is below. >> update: >> This dirty hack lets the Malta QEMU boot again: >> diff --git a/mm/highmem.c b/mm/highmem.c >> index c3a9ea7875ef..190cdda1149d 100644 >> --- a/mm/highmem.c >> +++ b/mm/highmem.c >> @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t >> prot) >> vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); >> BUG_ON(!pte_none(*(kmap_pte - idx))); >> pteval = pfn_pte(pfn, prot); >> -set_pte_at(_mm, vaddr, kmap_pte - idx, pteval); >> +set_pte(kmap_pte - idx, pteval); >> arch_kmap_local_post_map(vaddr, pteval); >> current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; >> preempt_enable(); >> set_pte_at() tries to update cache and could do an kmap_atomic() there. >> Not sure, if this is allowed at this point. > > Yes, I can confirm that your workaround works here too. > > Cheers, > -Paul > >
Re: [PATCH] arm64: dts: ls1028a: fix the offset of the reset register
On Tue, Dec 15, 2020 at 10:26:22PM +0100, Michael Walle wrote:
> The offset of the reset request register is 0, the absolute address is
> 0x1e6. Boards without PSCI support will fail to perform a reset:
>
> [ 26.734700] reboot: Restarting system
> [ 27.743259] Unable to restart system
> [ 27.746845] Reboot failed -- System halted
>
> Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC")
> Signed-off-by: Michael Walle
Applied, thanks.
Re: Re: [PATCH] arm/kasan:fix the arry size of kasan_early_shadow_pte
On Sun, Jan 10, 2021 at 11:21 AM hailong wrote: > >> +#ifndef PTE_HWTABLE_PTRS > >> +#define PTE_HWTABLE_PTRS 0 > >> +#endif > > > >Can this even happen? We have either pgtable-2level.h or > >pgtable-3level.h, both of which define PTE_HWTABLE_PTRS. > > > > I guess not for arm. But I'm not sure for other ARCHs. Oh it's a generic include. Sorry for the confusion. All good then! Yours, Linus Walleij
[PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org
The bugtracker on kernel.org is not working very well and might be a
disservice to the community, as discussed on the maintainers summit 2017
and explained below in detail. For most of the kernel it was never the
preferred place to report issues anyway, as the MAINTAINERS file and the
recently added text Documentation/admin-guide/reporting-issues.rst show.
Hence, remove the two points in the kernel's English documentation that
suggest submitting all sorts of bugs in bugzilla.kernel.org. That gets
rid of known inconsistencies with
Documentation/admin-guide/reporting-issues.rst, which is the reason for
one 'this needs further discussion' warning in there. Hence, remove that
warning as well to make the approach it describes the official one. A
few files in the Documentation continue referring to bugzilla.kernel.org
and sometimes even suggest filing issues there, but those references are
fine for now (see below for details).
Why bugzilla.kernel.org isn't working well
==
Find below the good, the bad and the ugly aspects of
bugzilla.kernel.org.
The good
Bugzilla.kernel.org is useful tool sometimes:
* About 15 of the ~2225 section entries in Linux's MAINTAINERS file
point to bugzilla.kernel.org as the official place to report bugs.
from a brief look it seems the developers of those areas take care of
issues filed in the bug tracker; sometimes they even file bugs there
themselves to keep track of things.
* For a few other subsystems the bug tracker also works as intended: the
maintainer gets reports and comments by mail. Some act upon those.
Gregkh is one of those, who often replies with standard text like "you
should report this to your distro" or "Please report this to the
following mailing list instead".
* The bug tracker sometimes brings users together: someone files a bug
which other users find and join; the users sometimes help each other
and occasionally even manage to get the right developers involved,
even in cases where those don't get a copy of the report by mail.
* It's a place where users can upload files they don't want or can't
send to mailing lists.
The bad
---
The list of products and components in bugzilla.kernel.org is widely
incomplete, outdated in sometimes plain wrong. The same is true for the
list of default assignees and the email addresses to which newly filed
reports get send to.
This leads to several problems. To see some of them one needs to look
closer at the products and components, for example by browsing the web
(https://bugzilla.kernel.org/describecomponents.cgi) or by using the
REST interface to get it as JSON
(https://bugzilla.kernel.org//rest/product?type=accessible [to get the
email addresses one needs to provide login credentials as well]).
That JSON output will list about 20 products with nearly 200 components.
* The majority of the ~2225 section entries and subsystems listed in
the MAINTAINERS file have no corresponding entry in bugzilla, hence
it's not a tool to contact the people users need to contact in case
of problems.
* About 66 of those ~200 components will assign bugs to email addresses
that look valid, but 125 of them end with @kernel-bugs.osdl.org or
@kernel-bugs.kernel.org. Those domains do not exist anymore, mails
sent there bounce ('Unrouteable address'). It's possible that the
server might be rewriting those domain names and nevertheless
delivers new reports and comments by mails to some human; but it
seems more like they never get mailed to anyone and thus just linger
in the database; no wonder quite a few of bugs filed against such
components never get a single reply (see below).
The ugly
Bugzilla.kernel.org might look like the official place to report all
sorts of kernel bugs, but it was never. That itself would be just bad,
what makes it ugly is this:
The front page doesn't make this aspect obvious and not even point to
Documentation/admin-guide/reporting-bugs.rst to help those that want to
properly report a bug. Only the FAQ mentions it, albeit only indirectly:
'The subsystem maintainers in kernel tracker are volunteers to help
track bugs in an area they are interested in. Sometimes they are the
same person as on kernel.org sometimes they are not. There are still
some categories with no maintainers so more volunteers are needed.'
It looks like those volunteers were never found; the outdated list of
components and products (see 'the bad' above) also shows that the
volunteers seem to not really take care of things.
In the end that's the reasons why quite a few (a lot?) reports never get
a reply from someone. During a randomly selected 2 week window at the
end of November 2020(¹) there were 60 public bugs and a bit more than
half of them by the end of the year never got a single comment by anyone
except maybe the reporter.
(¹) bugs created between 2020-11-21 and 2020-12-05 23:59:59; that's
about one week before the merge window of
Re: [stable 4.9.y 0/4] scripts/gdb Fixes for stable 4.9
On Thu, Jan 07, 2021 at 02:52:25PM -0800, Florian Fainelli wrote: Hi Greg, Sasha, This series contains some scripts/gdb/ fixes that are already present in newer stable kernels. Queued up, thanks! -- Thanks, Sasha
[PATCH 2/5] rtlwifi: rtl8192c-common: fix bool comparison in expressions
There are certain conditional expressions in rtl8192c-common, where a
boolean variable is compared with true/false, in forms such as
(foo == true) or (false != bar), which does not comply with checkpatch.pl
(CHECK: BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c,
"else if (initialized == false) {" can be replaced with
"else if (!initialized) {"
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c
index 265a1a336304..0b6a15c2e5cc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c
@@ -380,7 +380,7 @@ static void rtl92c_dm_initial_gain_multi_sta(struct
ieee80211_hw *hw)
initialized = false;
dm_digtable->dig_ext_port_stage = DIG_EXT_PORT_STAGE_MAX;
return;
- } else if (initialized == false) {
+ } else if (!initialized) {
initialized = true;
dm_digtable->dig_ext_port_stage = DIG_EXT_PORT_STAGE_0;
dm_digtable->cur_igvalue = 0x20;
@@ -509,7 +509,7 @@ static void rtl92c_dm_dig(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
- if (rtlpriv->dm.dm_initialgain_enable == false)
+ if (!rtlpriv->dm.dm_initialgain_enable)
return;
if (!(rtlpriv->dm.dm_flag & DYNAMIC_FUNC_DIG))
return;
--
2.17.1
[PATCH 4/5] rtlwifi: rtl8192se: fix bool comparison in expressions
There are certain conditional expressions in rtl8192se, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
index 47fabce5c235..73a5d8a068fc 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c
@@ -458,7 +458,7 @@ static u8 _rtl92se_halset_sysclk(struct ieee80211_hw *hw,
u8 data)
tmpvalue = rtl_read_byte(rtlpriv, SYS_CLKR + 1);
bresult = ((tmpvalue & BIT(7)) == (data & BIT(7)));
- if ((data & (BIT(6) | BIT(7))) == false) {
+ if (!(data & (BIT(6) | BIT(7 {
waitcount = 100;
tmpvalue = 0;
@@ -1268,7 +1268,7 @@ static u8 _rtl92s_set_sysclk(struct ieee80211_hw *hw, u8
data)
tmp = rtl_read_byte(rtlpriv, SYS_CLKR + 1);
result = ((tmp & BIT(7)) == (data & BIT(7)));
- if ((data & (BIT(6) | BIT(7))) == false) {
+ if (!(data & (BIT(6) | BIT(7 {
waitcnt = 100;
tmp = 0;
--
2.17.1
[PATCH 0/5] rtlwifi: fix bool comparison in expressions
This patch series fixes the bool comparison in conditional expressions for all the drivers in rtlwifi. There are certain conditional expressions in rtlwifi drivers, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c, "if (mac->act_scanning == true)" can be replaced with "if (mac->act_scanning)" Fix all such expressions with the bool variables appropriately for all the drivers in rtlwifi * The changes made are compile tested. * The patches apply perfectly on next-20210108 Aditya Srivastava (5): rtlwifi: rtl_pci: fix bool comparison in expressions rtlwifi: rtl8192c-common: fix bool comparison in expressions rtlwifi: rtl8188ee: fix bool comparison in expressions rtlwifi: rtl8192se: fix bool comparison in expressions rtlwifi: rtl8821ae: fix bool comparison in expressions drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++-- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 8 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 4 ++-- drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c | 4 ++-- drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 4 ++-- drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 8 6 files changed, 16 insertions(+), 16 deletions(-) -- 2.17.1
Re: [PATCH v2 0/3] Mainline Webasto ccbv2 board
On Wed, Dec 16, 2020 at 05:24:29PM +0100, Rouven Czerwinski wrote: > Add Webasto ccbv2 device tree. > > v2: > - add correct mailing lists to cc > - add commit message for vendor-prefix and dt-bindings > > Rouven Czerwinski (3): > dt-bindings: vendor-prefixes: add Webasto SE I did not receive this one. Shawn > ARM: dts: add Webasto ccbv2 > dt-bindings: arm: fsl: add Webasto ccbv2 > > .../devicetree/bindings/arm/fsl.yaml | 1 + > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > arch/arm/boot/dts/Makefile| 1 + > arch/arm/boot/dts/imx6ul-webasto-ccbv2.dts| 472 ++ > 4 files changed, 476 insertions(+) > create mode 100644 arch/arm/boot/dts/imx6ul-webasto-ccbv2.dts > > > base-commit: 2c85ebc57b3e1817b6ce1a6b703928e113a90442 > -- > 2.29.2 >
[PATCH 1/5] rtlwifi: rtl_pci: fix bool comparison in expressions
There are certain conditional expressions in rtl_pci, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c,
"if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)"
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c
b/drivers/net/wireless/realtek/rtlwifi/ps.c
index f99882255d48..629c03271bde 100644
--- a/drivers/net/wireless/realtek/rtlwifi/ps.c
+++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
@@ -798,9 +798,9 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void
*data,
ie += 3 + noa_len;
}
- if (find_p2p_ie == true) {
+ if (find_p2p_ie) {
if ((p2pinfo->p2p_ps_mode > P2P_PS_NONE) &&
- (find_p2p_ps_ie == false))
+ (!find_p2p_ps_ie))
rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
}
}
--
2.17.1
[PATCH 3/5] rtlwifi: rtl8188ee: fix bool comparison in expressions
There are certain conditional expressions in rtl8188ee, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c,
"if (mac->act_scanning == true)" can be replaced with
"if (mac->act_scanning)"
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c | 8
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
index d10c14c694da..6f61d6a10627 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c
@@ -474,11 +474,11 @@ static void rtl88e_dm_dig(struct ieee80211_hw *hw)
u8 dm_dig_max, dm_dig_min;
u8 current_igi = dm_dig->cur_igvalue;
- if (rtlpriv->dm.dm_initialgain_enable == false)
+ if (!rtlpriv->dm.dm_initialgain_enable)
return;
- if (dm_dig->dig_enable_flag == false)
+ if (!dm_dig->dig_enable_flag)
return;
- if (mac->act_scanning == true)
+ if (mac->act_scanning)
return;
if (mac->link_state >= MAC80211_LINKED)
@@ -1637,7 +1637,7 @@ static void rtl88e_dm_fast_ant_training(struct
ieee80211_hw *hw)
}
}
- if (bpkt_filter_match == false) {
+ if (!bpkt_filter_match) {
rtl_set_bbreg(hw, DM_REG_TXAGC_A_1_MCS32_11N,
BIT(16), 0);
rtl_set_bbreg(hw, DM_REG_IGI_A_11N, BIT(7), 0);
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
index bd9160b166c5..861cc663ca93 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c
@@ -1269,12 +1269,12 @@ void rtl88ee_set_check_bssid(struct ieee80211_hw *hw,
bool check_bssid)
if (rtlpriv->psc.rfpwr_state != ERFON)
return;
- if (check_bssid == true) {
+ if (check_bssid) {
reg_rcr |= (RCR_CBSSID_DATA | RCR_CBSSID_BCN);
rtlpriv->cfg->ops->set_hw_reg(hw, HW_VAR_RCR,
(u8 *)(_rcr));
_rtl88ee_set_bcn_ctrl_reg(hw, 0, BIT(4));
- } else if (check_bssid == false) {
+ } else if (!check_bssid) {
reg_rcr &= (~(RCR_CBSSID_DATA | RCR_CBSSID_BCN));
_rtl88ee_set_bcn_ctrl_reg(hw, BIT(4), 0);
rtlpriv->cfg->ops->set_hw_reg(hw,
--
2.17.1
[PATCH 5/5] rtlwifi: rtl8821ae: fix bool comparison in expressions
There are certain conditional expressions in rtl8821ae, where a boolean
variable is compared with true/false, in forms such as (foo == true) or
(false != bar), which does not comply with checkpatch.pl (CHECK:
BOOL_COMPARISON), according to which boolean variables should be
themselves used in the condition, rather than comparing with true/false
E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c,
"if (rtlefuse->autoload_failflag == false)" can be replaced with
"if (!rtlefuse->autoload_failflag)"
Replace all such expressions with the bool variables appropriately
Signed-off-by: Aditya Srivastava
---
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index 372d6f8caf06..e214b9062cc1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -1812,7 +1812,7 @@ static bool _rtl8821ae_phy_bb8821a_config_parafile(struct
ieee80211_hw *hw)
return false;
}
_rtl8821ae_phy_init_tx_power_by_rate(hw);
- if (rtlefuse->autoload_failflag == false) {
+ if (!rtlefuse->autoload_failflag) {
rtstatus = _rtl8821ae_phy_config_bb_with_pgheaderfile(hw,
BASEBAND_CONFIG_PHY_REG);
}
@@ -3980,7 +3980,7 @@ static void _rtl8821ae_iqk_tx(struct ieee80211_hw *hw,
enum radio_path path)
}
}
- if (tx0iqkok == false)
+ if (!tx0iqkok)
break; /* TXK fail,
Don't do RXK */
if (vdf_enable == 1) {
@@ -4090,7 +4090,7 @@ static void _rtl8821ae_iqk_tx(struct ieee80211_hw *hw,
enum radio_path path)
}
}
- if (tx0iqkok == false) { /* If RX
mode TXK fail, then take TXK Result */
+ if (!tx0iqkok) { /* If RX mode TXK
fail, then take TXK Result */
tx_x0_rxk[cal] = tx_x0[cal];
tx_y0_rxk[cal] = tx_y0[cal];
tx0iqkok = true;
@@ -4249,7 +4249,7 @@ static void _rtl8821ae_iqk_tx(struct ieee80211_hw *hw,
enum radio_path path)
}
}
- if (tx0iqkok == false) { /* If RX mode TXK
fail, then take TXK Result */
+ if (!tx0iqkok) { /* If RX mode TXK fail, then
take TXK Result */
tx_x0_rxk[cal] = tx_x0[cal];
tx_y0_rxk[cal] = tx_y0[cal];
tx0iqkok = true;
--
2.17.1
Re: [PATCH v2 2/4] arm64: dts: imx8mq-librem5-devkit: Tweak pmic regulators
On Thu, Dec 17, 2020 at 04:13:13PM +0100, Guido Günther wrote: > BUCK3 needs a regulator-enable-ramp-delay since otherwise the board > freezes on etnaviv probe. With this pgc_gpu suspends and resumes as > expected. This must have been always broken since gpcv2 support was > enabled. > > We also enable all the regulators needed for Deep Sleep Mode (DSM) as > always-on: > > - VDD_SOC supplied by BUCK1 > - VDDA_1P8 supplied by BUCK7 > - VDDA_0P9 supplied by LDO4 > - VDDA_DRAM supplied by LDO3 > - NVCC_DRAM supplied by BUCK8 > - VDD_DRAM supplied by BUCK5 > > Finally LDO5 and LDO6 provide VDD_PHY_1V8 and VDD_PHY_0V9 used by the > SOCs MIPI, HDMI and USB IP cores. While we would in theory be able to > turn these off (and I've tested that or LDO6 and mipi with USB disabled) > it is of little practical use atm since USB doesn't runtime suspend so > let's revisit this at a later point. > > Signed-off-by: Guido Günther Applied, thanks.
Re: [PATCH v2 4/4] arm64: dts: imx8mq-librem5-devkit: Drop custom clock settings
On Thu, Dec 17, 2020 at 04:13:15PM +0100, Guido Günther wrote: > Otherwise the boot hangs early on and the resulting clock tree without > this already closely matches the selected rates (722534400 and > 786432000). > > audio_pll2 000 722534397 0 > 0 5 > audio_pll2_bypass000 722534397 0 > 0 5 > audio_pll2_out000 722534397 0 > 0 5 > audio_pll1 110 786431998 0 > 0 5 > audio_pll1_bypass110 786431998 0 > 0 5 > audio_pll1_out110 786431998 0 > 0 5 >sai2 11024576000 0 > 0 5 > sai2_root_clk 11024576000 0 >0 5 >sai6 00024576000 0 > 0 5 > sai6_root_clk 00024576000 0 >0 5 > > Signed-off-by: Guido Günther Applied, thanks.
Re: [PATCH v2 3/4] arm64: dts: imx8mq-librem5-devkit: Disable snvs_rtc
On Thu, Dec 17, 2020 at 04:13:14PM +0100, Guido Günther wrote: > The board has it's own RTC chip which is backed by the (optional) > battery and hence preserves data/time on poweroff when that is inserted. > > Signed-off-by: Guido Günther Applied, thanks.
Re: [PATCH v2 0/4] Config and device tree updates for the Librem 5 devkit
On Thu, Dec 17, 2020 at 04:13:11PM +0100, Guido Günther wrote: > This enables more components to get a working display, panel, audio and > sensors. It also updates some device tree bits to make mainline boot. > > I've skipped wifi (which needs some more driver work) and devfreq (since > Martin > is working on that). > > The config changes don't depend on the DT parts so could be applied > independently. The series was tested against next-20201214 and i made sure the > defconfig changes also apply on top of shawnguo/imx/defconfig. Sorry. It doesn't apply any more. Shawn
Re: [PATCH 1/1] can: dev: add software tx timestamps
Hello Jeroen,
On Sun. 10 Jan 2021 at 20:29, Jeroen Hofstee wrote:
>
> Hello Vincent,
>
> On 1/10/21 11:35 AM, Vincent Mailhol wrote:
> > Call skb_tx_timestamp() within can_put_echo_skb() so that a software
> > tx timestamp gets attached on the skb.
> >
> [..]
> >
> > diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> > index 3486704c8a95..3904e0874543 100644
> > --- a/drivers/net/can/dev.c
> > +++ b/drivers/net/can/dev.c
> > @@ -484,6 +484,8 @@ int can_put_echo_skb(struct sk_buff *skb, struct
> > net_device *dev,
> >
> > /* save this skb for tx interrupt echo handling */
> > priv->echo_skb[idx] = skb;
> > +
> > + skb_tx_timestamp(skb);
> > } else {
> > /* locking problem with netif_stop_queue() ?? */
> > netdev_err(dev, "%s: BUG! echo_skb %d is occupied!\n",
> > __func__, idx);
>
> Personally, I would put the skb_tx_timestamp, before adding it to the array:
>
> /* make settings for echo to reduce code in irq context */
> skb->pkt_type = PACKET_BROADCAST;
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> skb->dev = dev;
> + skb_tx_timestamp(skb);
>
> /* save this skb for tx interrupt echo handling */
> priv->echo_skb[idx] = skb;
I agree that it is better like that from an aesthetic point of
view. The reason to put it at the very end was to really to
blindly follow the doc and do the timestamp as late as possible.
>
> I don't think it actually matters though.
Indeed, but will still follow your suggestion though. Putting it
before would just delay the timestamp by a few assembly
instructions: it is negligible enough.
Yours sincerely,
Vincent Mailhol
Re: [PATCH 1/2] ARM: dts: imx6q-logicpd: Drop unused clock-names reference
On Thu, Dec 17, 2020 at 11:25:28AM -0600, Adam Ford wrote: > The wlf,wm8962 driver does not use the clock-names property. > Drop it. > > Signed-off-by: Adam Ford Applied both, thanks.
[PATCH v3 0/6] Fix some bugs about HugeTLB code
This patch series aims to fix some bugs and add some improvements. Changelog since v2 -> v3: - Update commit log. - Using head[3].private to indicate the page is freed in patch #3. Changelog since v1 -> v2: - Export set_page_huge_active() in patch #2 to fix. - Using head[3].mapping to indicate the page is freed in patch #3. - Flush @free_hpage_work in patch #4. Muchun Song (6): mm: migrate: do not migrate HugeTLB page whose refcount is one mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page mm: hugetlb: fix a race between freeing and dissolving the page mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page mm: hugetlb: fix a race between isolating and freeing page mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active fs/hugetlbfs/inode.c| 3 ++- include/linux/hugetlb.h | 2 ++ mm/hugetlb.c| 59 + mm/migrate.c| 6 + 4 files changed, 60 insertions(+), 10 deletions(-) -- 2.11.0
[PATCH v3 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one
If the refcount is one when it is migrated, it means that the page
was freed from under us. So we are done and do not need to migrate.
This optimization is consistent with the regular pages, just like
unmap_and_move() does.
Signed-off-by: Muchun Song
Reviewed-by: Mike Kravetz
Acked-by: Yang Shi
---
mm/migrate.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/mm/migrate.c b/mm/migrate.c
index 4385f2fb5d18..a6631c4eb6a6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1279,6 +1279,12 @@ static int unmap_and_move_huge_page(new_page_t
get_new_page,
return -ENOSYS;
}
+ if (page_count(hpage) == 1) {
+ /* page was freed from under us. So we are done. */
+ putback_active_hugepage(hpage);
+ return MIGRATEPAGE_SUCCESS;
+ }
+
new_hpage = get_new_page(hpage, private);
if (!new_hpage)
return -ENOMEM;
--
2.11.0
[PATCH v3 2/6] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page
If a new hugetlb page is allocated during fallocate it will not be
marked as active (set_page_huge_active) which will result in a later
isolate_huge_page failure when the page migration code would like to
move that page. Such a failure would be unexpected and wrong.
Only export set_page_huge_active, just leave clear_page_huge_active
as static. Because there are no external users.
Fixes: 70c3547e36f5 (hugetlbfs: add hugetlbfs_fallocate())
Signed-off-by: Muchun Song
Cc: sta...@vger.kernel.org
---
fs/hugetlbfs/inode.c| 3 ++-
include/linux/hugetlb.h | 2 ++
mm/hugetlb.c| 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index b5c109703daa..21c20fd5f9ee 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -735,9 +735,10 @@ static long hugetlbfs_fallocate(struct file *file, int
mode, loff_t offset,
mutex_unlock(_fault_mutex_table[hash]);
+ set_page_huge_active(page);
/*
* unlock_page because locked by add_to_page_cache()
-* page_put due to reference from alloc_huge_page()
+* put_page() due to reference from alloc_huge_page()
*/
unlock_page(page);
put_page(page);
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index ebca2ef02212..b5807f23caf8 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -770,6 +770,8 @@ static inline void huge_ptep_modify_prot_commit(struct
vm_area_struct *vma,
}
#endif
+void set_page_huge_active(struct page *page);
+
#else /* CONFIG_HUGETLB_PAGE */
struct hstate {};
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 1f3bf1710b66..4741d60f8955 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1348,7 +1348,7 @@ bool page_huge_active(struct page *page)
}
/* never called for tail page */
-static void set_page_huge_active(struct page *page)
+void set_page_huge_active(struct page *page)
{
VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
SetPagePrivate([1]);
--
2.11.0
[PATCH v3 5/6] mm: hugetlb: fix a race between isolating and freeing page
There is a race between isolate_huge_page() and __free_huge_page().
CPU0: CPU1:
if (PageHuge(page))
put_page(page)
__free_huge_page(page)
spin_lock(_lock)
update_and_free_page(page)
set_compound_page_dtor(page,
NULL_COMPOUND_DTOR)
spin_unlock(_lock)
isolate_huge_page(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHead(page), page)
spin_lock(_lock)
page_huge_active(page)
// trigger BUG_ON
VM_BUG_ON_PAGE(!PageHuge(page), page)
spin_unlock(_lock)
When we isolate a HugeTLB page on CPU0. Meanwhile, we free it to the
buddy allocator on CPU1. Then, we can trigger a BUG_ON on CPU0. Because
it is already freed to the buddy allocator.
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
hugepage")
Signed-off-by: Muchun Song
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
Cc: sta...@vger.kernel.org
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a176ceed55f1..e7ed30afbb8f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5575,9 +5575,9 @@ bool isolate_huge_page(struct page *page, struct
list_head *list)
{
bool ret = true;
- VM_BUG_ON_PAGE(!PageHead(page), page);
spin_lock(_lock);
- if (!page_huge_active(page) || !get_page_unless_zero(page)) {
+ if (!PageHeadHuge(page) || !page_huge_active(page) ||
+ !get_page_unless_zero(page)) {
ret = false;
goto unlock;
}
--
2.11.0
[PATCH v3 6/6] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active
The page_huge_active() can be called from scan_movable_pages() which
do not hold a reference count to the HugeTLB page. So when we call
page_huge_active() from scan_movable_pages(), the HugeTLB page can
be freed parallel. Then we will trigger a BUG_ON which is in the
page_huge_active() when CONFIG_DEBUG_VM is enabled. Just remove the
VM_BUG_ON_PAGE.
Fixes: 7e1f049efb86 ("mm: hugetlb: cleanup using paeg_huge_active()")
Signed-off-by: Muchun Song
Reviewed-by: Mike Kravetz
Acked-by: Michal Hocko
Cc: sta...@vger.kernel.org
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index e7ed30afbb8f..5940bf0c49b9 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1360,8 +1360,7 @@ struct hstate *size_to_hstate(unsigned long size)
*/
bool page_huge_active(struct page *page)
{
- VM_BUG_ON_PAGE(!PageHuge(page), page);
- return PageHead(page) && PagePrivate([1]);
+ return PageHeadHuge(page) && PagePrivate([1]);
}
/* never called for tail page */
--
2.11.0
[PATCH v2 0/1] Add software TX timestamps to the CAN devices
With the ongoing work to add BQL to Socket CAN, I figured out that it would be nice to have an easy way to mesure the latency. And one easy way to do so it to check the round trip time of the packet by doing the difference between the software rx timestamp and the software tx timestamp. rx timestamps are already available. This patch gives the missing piece: add a tx software timestamp feature to the CAN devices. Of course, the tx software timestamp might also be used for other purposes such as performance measurements of the different queuing disciplines (e.g. by checking the difference between the kernel tx software timestamp and the userland tx software timestamp). v2 reflects the comments that Jeroen made in https://lkml.org/lkml/2021/1/10/54 Vincent Mailhol (1): can: dev: add software tx timestamps drivers/net/can/dev.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.26.2
[PATCH v3 3/6] mm: hugetlb: fix a race between freeing and dissolving the page
There is a race condition between __free_huge_page()
and dissolve_free_huge_page().
CPU0: CPU1:
// page_count(page) == 1
put_page(page)
__free_huge_page(page)
dissolve_free_huge_page(page)
spin_lock(_lock)
// PageHuge(page) && !page_count(page)
update_and_free_page(page)
// page is freed to the buddy
spin_unlock(_lock)
spin_lock(_lock)
clear_page_huge_active(page)
enqueue_huge_page(page)
// It is wrong, the page is already freed
spin_unlock(_lock)
The race windows is between put_page() and dissolve_free_huge_page().
We should make sure that the page is already on the free list
when it is dissolved.
Fixes: c8721bbbdd36 ("mm: memory-hotplug: enable memory hotplug to handle
hugepage")
Signed-off-by: Muchun Song
Cc: sta...@vger.kernel.org
---
mm/hugetlb.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4741d60f8955..4a9011e12175 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -79,6 +79,21 @@ DEFINE_SPINLOCK(hugetlb_lock);
static int num_fault_mutexes;
struct mutex *hugetlb_fault_mutex_table cacheline_aligned_in_smp;
+static inline bool PageHugeFreed(struct page *head)
+{
+ return page_private(head + 4) == -1UL;
+}
+
+static inline void SetPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, -1UL);
+}
+
+static inline void ClearPageHugeFreed(struct page *head)
+{
+ set_page_private(head + 4, 0);
+}
+
/* Forward declaration */
static int hugetlb_acct_memory(struct hstate *h, long delta);
@@ -1028,6 +1043,7 @@ static void enqueue_huge_page(struct hstate *h, struct
page *page)
list_move(>lru, >hugepage_freelists[nid]);
h->free_huge_pages++;
h->free_huge_pages_node[nid]++;
+ SetPageHugeFreed(page);
}
static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
@@ -1044,6 +1060,7 @@ static struct page *dequeue_huge_page_node_exact(struct
hstate *h, int nid)
list_move(>lru, >hugepage_activelist);
set_page_refcounted(page);
+ ClearPageHugeFreed(page);
h->free_huge_pages--;
h->free_huge_pages_node[nid]--;
return page;
@@ -1504,6 +1521,7 @@ static void prep_new_huge_page(struct hstate *h, struct
page *page, int nid)
spin_lock(_lock);
h->nr_huge_pages++;
h->nr_huge_pages_node[nid]++;
+ ClearPageHugeFreed(page);
spin_unlock(_lock);
}
@@ -1770,6 +1788,14 @@ int dissolve_free_huge_page(struct page *page)
int nid = page_to_nid(head);
if (h->free_huge_pages - h->resv_huge_pages == 0)
goto out;
+
+ /*
+* We should make sure that the page is already on the free list
+* when it is dissolved.
+*/
+ if (unlikely(!PageHugeFreed(head)))
+ goto out;
+
/*
* Move PageHWPoison flag from head page to the raw error page,
* which makes any subpages rather than the error page reusable.
--
2.11.0
[PATCH v3 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
There is a race between dissolve_free_huge_page() and put_page(),
and the race window is quite small. Theoretically, we should return
-EBUSY when we encounter this race. In fact, we have a chance to
successfully dissolve the page if we do a retry. Because the race
window is quite small. If we seize this opportunity, it is an
optimization for increasing the success rate of dissolving page.
If we free a HugeTLB page from a non-task context, it is deferred
through a workqueue. In this case, we need to flush the work.
The dissolve_free_huge_page() can be called from memory hotplug,
the caller aims to free the HugeTLB page to the buddy allocator
so that the caller can unplug the page successfully.
Signed-off-by: Muchun Song
---
mm/hugetlb.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4a9011e12175..a176ceed55f1 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1763,10 +1763,11 @@ static int free_pool_huge_page(struct hstate *h,
nodemask_t *nodes_allowed,
* nothing for in-use hugepages and non-hugepages.
* This function returns values like below:
*
- * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
- * (allocated or reserved.)
- * 0: successfully dissolved free hugepages or the page is not a
- * hugepage (considered as already dissolved)
+ * -EAGAIN: race with __free_huge_page() and can do a retry
+ * -EBUSY: failed to dissolved free hugepages or the hugepage is in-use
+ * (allocated or reserved.)
+ * 0: successfully dissolved free hugepages or the page is not a
+ * hugepage (considered as already dissolved)
*/
int dissolve_free_huge_page(struct page *page)
{
@@ -1793,8 +1794,10 @@ int dissolve_free_huge_page(struct page *page)
* We should make sure that the page is already on the free list
* when it is dissolved.
*/
- if (unlikely(!PageHugeFreed(head)))
+ if (unlikely(!PageHugeFreed(head))) {
+ rc = -EAGAIN;
goto out;
+ }
/*
* Move PageHWPoison flag from head page to the raw error page,
@@ -1813,6 +1816,14 @@ int dissolve_free_huge_page(struct page *page)
}
out:
spin_unlock(_lock);
+
+ /*
+* If the freeing of the HugeTLB page is put on a work queue, we should
+* flush the work before retrying.
+*/
+ if (unlikely(rc == -EAGAIN))
+ flush_work(_hpage_work);
+
return rc;
}
@@ -1835,7 +1846,12 @@ int dissolve_free_huge_pages(unsigned long start_pfn,
unsigned long end_pfn)
for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) {
page = pfn_to_page(pfn);
+retry:
rc = dissolve_free_huge_page(page);
+ if (rc == -EAGAIN) {
+ cpu_relax();
+ goto retry;
+ }
if (rc)
break;
}
--
2.11.0
[PATCH v2 1/1] can: dev: add software tx timestamps
Call skb_tx_timestamp() within can_put_echo_skb() so that a software
tx timestamp gets attached on the skb.
There two main reasons to include this call in can_put_echo_skb():
* It easily allow to enable the tx timestamp on all devices with
just one small change.
* According to Documentation/networking/timestamping.rst, the tx
timestamps should be generated in the device driver as close as
possible, but always prior to passing the packet to the network
interface. During the call to can_put_echo_skb(), the skb gets
cloned meaning that the driver should not dereference the skb
variable anymore after can_put_echo_skb() returns. This makes
can_put_echo_skb() the very last place we can use the skb without
having to access the echo_skb[] array.
Remarks:
* By default, skb_tx_timestamp() does nothing. It needs to be
activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either
through socket options or control messages.
* The hardware rx timestamp of a local loopback message is the
hardware tx timestamp. This means that there are no needs to
implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets.
References:
Support for the error queue in CAN RAW sockets (which is needed for tx
timestamps) was introduced in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96
Put the call to skb_tx_timestamp() just before adding it to the array:
https://lkml.org/lkml/2021/1/10/54
Signed-off-by: Vincent Mailhol
---
drivers/net/can/dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 3486704c8a95..3904e0874543 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -484,6 +484,8 @@ int can_put_echo_skb(struct sk_buff *skb, struct net_device
*dev,
/* save this skb for tx interrupt echo handling */
priv->echo_skb[idx] = skb;
+
+ skb_tx_timestamp(skb);
} else {
/* locking problem with netif_stop_queue() ?? */
netdev_err(dev, "%s: BUG! echo_skb %d is occupied!\n",
__func__, idx);
--
2.26.2
Re: [PATCH] arm64: dts: imx8mq: Add clock parents for mipi dphy
On Fri, Dec 18, 2020 at 06:50:05PM +0100, Guido Günther wrote:
> This makes sure the clock tree setup for the dphy is not dependent on
> other components.
>
> Without this change bringing up the display can fail like
>
> kernel: phy phy-30a00300.dphy.2: Invalid CM/CN/CO values: 165/217/1
> kernel: phy phy-30a00300.dphy.2: for hs_clk/ref_clk=451656000/59398 ~
> 165/217
>
> if LCDIF doesn't set up that part of the clock tree first. This was
> noticed when testing the Librem 5 devkit with defconfig. It doesn't
> happen when modules are built in.
>
> Signed-off-by: Guido Günther
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index a841a023e8e0..ca0847e8f13c 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1016,9 +1016,14 @@ dphy: dphy@30a00300 {
> reg = <0x30a00300 0x100>;
> clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
> clock-names = "phy_ref";
> - assigned-clocks = < IMX8MQ_CLK_DSI_PHY_REF>;
> - assigned-clock-parents = <
> IMX8MQ_VIDEO_PLL1_OUT>;
> - assigned-clock-rates = <2400>;
> + assigned-clocks = <
> IMX8MQ_VIDEO_PLL1_REF_SEL>,
> + <
> IMX8MQ_VIDEO_PLL1_BYPASS>,
> + < IMX8MQ_CLK_DSI_PHY_REF>,
> + < IMX8MQ_VIDEO_PLL1>;
You do not seem to set parent or rate on IMX8MQ_VIDEO_PLL1. Why do you
have it here?
Shawn
> + assigned-clock-parents = < IMX8MQ_CLK_25M>,
> + < IMX8MQ_VIDEO_PLL1>,
> + < IMX8MQ_VIDEO_PLL1_OUT>;
> + assigned-clock-rates = <0>, <0>, <2400>;
> #phy-cells = <0>;
> power-domains = <_mipi>;
> status = "disabled";
> --
> 2.29.2
>
[PATCH v3 0/1] Add software TX timestamps to the CAN devices
With the ongoing work to add BQL to Socket CAN, I figured out that it would be nice to have an easy way to mesure the latency. And one easy way to do so it to check the round trip time of the packet by doing the difference between the software rx timestamp and the software tx timestamp. rx timestamps are already available. This patch gives the missing piece: add a tx software timestamp feature to the CAN devices. Of course, the tx software timestamp might also be used for other purposes such as performance measurements of the different queuing disciplines (e.g. by checking the difference between the kernel tx software timestamp and the userland tx software timestamp). v2 was a mistake, please ignore it (fogot to do git add, changes were not reflected...) v3 reflects the comments that Jeroen made in https://lkml.org/lkml/2021/1/10/54 Vincent Mailhol (1): can: dev: add software tx timestamps drivers/net/can/dev.c | 1 + 1 file changed, 1 insertion(+) -- 2.26.2
[PATCH v3 1/1] can: dev: add software tx timestamps
Call skb_tx_timestamp() within can_put_echo_skb() so that a software tx timestamp gets attached on the skb. There two main reasons to include this call in can_put_echo_skb(): * It easily allow to enable the tx timestamp on all devices with just one small change. * According to Documentation/networking/timestamping.rst, the tx timestamps should be generated in the device driver as close as possible, but always prior to passing the packet to the network interface. During the call to can_put_echo_skb(), the skb gets cloned meaning that the driver should not dereference the skb variable anymore after can_put_echo_skb() returns. This makes can_put_echo_skb() the very last place we can use the skb without having to access the echo_skb[] array. Remarks: * By default, skb_tx_timestamp() does nothing. It needs to be activated by passing the SOF_TIMESTAMPING_TX_SOFTWARE flag either through socket options or control messages. * The hardware rx timestamp of a local loopback message is the hardware tx timestamp. This means that there are no needs to implement SOF_TIMESTAMPING_TX_HARDWARE for CAN sockets. References: Support for the error queue in CAN RAW sockets (which is needed for tx timestamps) was introduced in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb88531bdbfaafb827192d1fc6c5a3fcc4fadd96 Put the call to skb_tx_timestamp() just before adding it to the array: https://lkml.org/lkml/2021/1/10/54 Signed-off-by: Vincent Mailhol --- drivers/net/can/dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index 3486704c8a95..850759c7677f 100644 --- a/drivers/net/can/dev.c +++ b/drivers/net/can/dev.c @@ -481,6 +481,7 @@ int can_put_echo_skb(struct sk_buff *skb, struct net_device *dev, skb->pkt_type = PACKET_BROADCAST; skb->ip_summed = CHECKSUM_UNNECESSARY; skb->dev = dev; + skb_tx_timestamp(skb); /* save this skb for tx interrupt echo handling */ priv->echo_skb[idx] = skb; -- 2.26.2
[GIT PULL] Please pull powerpc/linux.git powerpc-5.11-3 tag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull a couple of powerpc fixes for 5.11:
The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:
Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
tags/powerpc-5.11-3
for you to fetch changes up to 3ce47d95b7346dcafd9bed3556a8d072cb2b8571:
powerpc: Handle .text.{hot,unlikely}.* in linker script (2021-01-06 21:59:04
+1100)
- --
powerpc fixes for 5.11 #3
A fix for machine check handling with VMAP stack on 32-bit.
A clang build fix.
Thanks to:
Christophe Leroy, Nathan Chancellor.
- --
Christophe Leroy (1):
powerpc/32s: Fix RTAS machine check with VMAP stack
Nathan Chancellor (1):
powerpc: Handle .text.{hot,unlikely}.* in linker script
arch/powerpc/kernel/head_book3s_32.S | 9 +
arch/powerpc/kernel/vmlinux.lds.S| 2 +-
2 files changed, 10 insertions(+), 1 deletion(-)
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/696oACgkQUevqPMjh
pYDNEg/+POcwQFJL0807yN0tbEmdWx0QJSTEyhSczSQfArqAr6Wjl5cAUf8VIqm1
cj3zze6syGuC/geCAYTYPc9BTb7st50w2XEj1LIR1S8YMk4sS+TcnWxYr++pliUZ
vcVFf5Xab5ZTOMODDyYR4C4KCu/FyF7pHYSap3XdJ4HjiDtSSNWowydTrAXxsm0d
OvfsXqoBZ/6CHquIeGy1qFkC1vWPTeZSBOxLelxaY3LUdBIku7zolHawSvVaubyz
f6CjFiQQ9HUc4clezqmMtL5f6KZh4q5xiynNFZRBeajGqYjWsd1qZbs7Ankw55qb
X7XLjbihVjpAzR+x/nZycGTKLCWsQ74vxpbFXg/DsV2ThfXUG23zhmt2qC8il/1Q
0R1CEPDoE/q3enroDJAfec1ANg0c/o/G/l+n4mK6OKt3fDRYc+BQED78dYWfzZPu
KwXnXRdAugLNqk3Fp4YOZl3kk/4JvYnguaUiIxWoD94UXf67BESJICS84hMZ2ytT
x5irkTM9LFwempJ0t+ayfR+4EWH4GkvsnBhfpcZ5KqFF1ttSjhs8ETdWFq7cOn8n
xHC+6Ed8f36pOzeBv9FIYvRbgMgxQXtVMk90PIPQdRepXzPRm9Ik/n+kq0F8GFEG
CqX4LpI3lUIkFwei4F9DfUPW01xiHELT7vFM3hFpo6O7M6NR8Rg=
=S2EG
-END PGP SIGNATURE-
Re: [PATCH] scsi: ufs: A tad optimization in query upiu trace
On Sun, 2021-01-10 at 10:46 +0200, Avri Altman wrote: > Remove a redundant if clause in ufshcd_add_query_upiu_trace. > > Signed-off-by: Avri Altman Looks good to me, thanks. Reviewed-by: Bean Huo
[PATCH V4 0/3] Decouple config data for configfs
This patchset aims to lay down some prep work before configfs can be implemented for the vkms driver. The first patch in the series adds a new type vkms_config to track device configuration. The second and third patch add module testing support for writeback operations. The first patch is developed by Daniel Vetter. Daniel Vetter (1): drm/vkms: Add vkms_config type Sumera Priyadarsini (3): drm/vkms: Add vkms_config type drm/vkms: Add support for writeback module drm/vkms: Add information about module options Documentation/gpu/vkms.rst | 10 +++ drivers/gpu/drm/vkms/vkms_drv.c| 45 -- drivers/gpu/drm/vkms/vkms_drv.h| 13 +++-- drivers/gpu/drm/vkms/vkms_output.c | 13 + 4 files changed, 66 insertions(+), 15 deletions(-) --- Changes in v2: - add Co-developed-by tag Changes in v3: - correct usage of Co-developed by tag(Melissa) - add enable_writeback_feature(Melissa) - modify commit message(Melissa) Changes in v4: - split previous patch into patchset(Melissa) - fix checkpatch issue(Melissa) - update docs(Daniel) -- 2.25.1
[PATCH V4 1/3] drm/vkms: Add vkms_config type
Currently, data for the device instance is held by vkms_device.
Add a separate type, vkms_config to contain configuration details
for the device and various modes to be later used by configfs.
This config data stays constant once the device is created.
Accordingly, add vkms_create and vkms_destroy to initialize/destroy
device through configfs. Currently, they are being called from vkms_init
and vkms_exit, but will be evoked from configfs later on. When configfs
is added, device configuration will be tracked by configfs and only vkms
device lifetime will be handled by vkms_init and vkms_exit functions.
Modify usage of enable_cursor feature to reflect the changes in
relevant files.
Co-developed-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Signed-off-by: Sumera Priyadarsini
---
drivers/gpu/drm/vkms/vkms_drv.c| 40 --
drivers/gpu/drm/vkms/vkms_drv.h| 12 +++--
drivers/gpu/drm/vkms/vkms_output.c | 4 +--
3 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index aef29393b811..6b33975a5cb2 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -34,9 +34,9 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static struct vkms_device *vkms_device;
+static struct vkms_config *default_config;
-bool enable_cursor = true;
+static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
@@ -122,10 +122,11 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
return vkms_output_init(vkmsdev, 0);
}
-static int __init vkms_init(void)
+static int vkms_create(struct vkms_config *config)
{
int ret;
struct platform_device *pdev;
+ struct vkms_device *vkms_device;
pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
if (IS_ERR(pdev))
@@ -143,6 +144,8 @@ static int __init vkms_init(void)
goto out_devres;
}
vkms_device->platform = pdev;
+ vkms_device->config = config;
+ config->dev = vkms_device;
ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
DMA_BIT_MASK(64));
@@ -179,21 +182,42 @@ static int __init vkms_init(void)
return ret;
}
-static void __exit vkms_exit(void)
+static int __init vkms_init(void)
+{
+ struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
+
+ default_config = config;
+
+ config->cursor = enable_cursor;
+
+ return vkms_create(config);
+}
+
+static void vkms_destroy(struct vkms_config *config)
{
struct platform_device *pdev;
- if (!vkms_device) {
+ if (!config->dev) {
DRM_INFO("vkms_device is NULL.\n");
return;
}
- pdev = vkms_device->platform;
+ pdev = config->dev->platform;
- drm_dev_unregister(_device->drm);
- drm_atomic_helper_shutdown(_device->drm);
+ drm_dev_unregister(>dev->drm);
+ drm_atomic_helper_shutdown(>dev->drm);
devres_release_group(>dev, NULL);
platform_device_unregister(pdev);
+
+ config->dev = NULL;
+}
+
+static void __exit vkms_exit(void)
+{
+ if (default_config->dev)
+ vkms_destroy(default_config);
+
+ kfree(default_config);
}
module_init(vkms_init);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5ed91ff08cb3..6a27bd8875f2 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -19,8 +19,6 @@
#define XRES_MAX 8192
#define YRES_MAX 8192
-extern bool enable_cursor;
-
struct vkms_composer {
struct drm_framebuffer fb;
struct drm_rect src, dst;
@@ -82,10 +80,19 @@ struct vkms_output {
spinlock_t composer_lock;
};
+struct vkms_device;
+
+struct vkms_config {
+ bool cursor;
+ /* only set when instantiated */
+ struct vkms_device *dev;
+};
+
struct vkms_device {
struct drm_device drm;
struct platform_device *platform;
struct vkms_output output;
+ const struct vkms_config *config;
};
#define drm_crtc_to_vkms_output(target) \
@@ -124,3 +131,4 @@ void vkms_set_composer(struct vkms_output *out, bool
enabled);
int vkms_enable_writeback_connector(struct vkms_device *vkmsdev);
#endif /* _VKMS_DRV_H_ */
+
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 4a1848b0318f..8f3ffb28b9d1 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -46,7 +46,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
if (IS_ERR(primary))
return PTR_ERR(primary);
- if (enable_cursor) {
+ if (vkmsdev->config->cursor) {
cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
[PATCH V4 2/3] drm/vkms: Add support for writeback module
Add enable_writeback feature to vkms_config as a module.
Signed-off-by: Sumera Priyadarsini
---
drivers/gpu/drm/vkms/vkms_drv.c| 5 +
drivers/gpu/drm/vkms/vkms_drv.h| 1 +
drivers/gpu/drm/vkms/vkms_output.c | 9 ++---
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 6b33975a5cb2..708f7f54001d 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -40,6 +40,10 @@ static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
+static bool enable_writeback = true;
+module_param_named(enable_writeback, enable_writeback, bool, 0444);
+MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector
support");
+
DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
static void vkms_release(struct drm_device *dev)
@@ -189,6 +193,7 @@ static int __init vkms_init(void)
default_config = config;
config->cursor = enable_cursor;
+ config->writeback = enable_writeback;
return vkms_create(config);
}
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 6a27bd8875f2..b9b4e2bc11c0 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -83,6 +83,7 @@ struct vkms_output {
struct vkms_device;
struct vkms_config {
+ bool writeback;
bool cursor;
/* only set when instantiated */
struct vkms_device *dev;
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 8f3ffb28b9d1..f5f6f15c362c 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -41,6 +41,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
struct drm_crtc *crtc = >crtc;
struct drm_plane *primary, *cursor = NULL;
int ret;
+ int writeback;
primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
if (IS_ERR(primary))
@@ -80,9 +81,11 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
goto err_attach;
}
- ret = vkms_enable_writeback_connector(vkmsdev);
- if (ret)
- DRM_ERROR("Failed to init writeback connector\n");
+ if (vkmsdev->config->writeback) {
+ writeback = vkms_enable_writeback_connector(vkmsdev);
+ if (writeback)
+ DRM_ERROR("Failed to init writeback connector\n");
+ }
drm_mode_config_reset(dev);
--
2.25.1
[PATCH V4 3/3] drm/vkms: Add information about module options
Update vkms documentation to contain usage of `modinfo` command and steps to load vkms with module options enabled. Signed-off-by: Sumera Priyadarsini --- Documentation/gpu/vkms.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 9e030c74a82e..45fe02f643a8 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -35,6 +35,16 @@ Now, to load the driver, use:: On running the lsmod command now, the VKMS driver will appear listed. You can also observe the driver being loaded in the dmesg logs. +You can use the `modinfo` command to see module options for vkms:: + + modinfo vkms + +Module options are helpful when testing, and enabling modules +can be done while loading vkms. For example, to load vkms with cursor enabled, +use:: + + sudo modprobe vkms enable_cursor=1 + To disable the driver, use :: sudo modprobe -r vkms -- 2.25.1
[GIT PULL] Char/Misc driver fixes for 5.11-rc3
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git tags/char-misc-5.11-rc3 for you to fetch changes up to 384b77fd48fd683a82760bc88bef8611cba997fc: Fonts: font_ter16x32: Update font with new upstream Terminus release (2021-01-07 21:06:25 +0100) Char/Misc driver fixes for 5.11-rc3 Here are some small char and misc driver fixes for 5.11-rc3. the majority here are fixes for the habanalabs drivers, but also in here are: - crypto driver fix - pvpanic driver fix - updated font file - interconnect driver fixes All of these have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Alon Mizrahi (5): habanalabs: add comment for pll frequency ioctl opcode habanalabs: fetch PSOC PLL frequency from F/W in goya habanalabs: remove generic gaudi get_pll_freq function habanalabs/gaudi: do not set EB in collective slave queues habanalabs: add validation cs counter, fix misplaced counters Amanoel Dawod (1): Fonts: font_ter16x32: Update font with new upstream Terminus release Andy Shevchenko (1): misc: pvpanic: Check devm_ioport_map() for NULL Arnd Bergmann (1): interconnect: qcom: fix rpmh link failures Christophe JAILLET (2): interconnect: imx: Add a missing of_node_put after of_device_is_available interconnect: imx: Remove a useless test Dinghao Liu (1): habanalabs: Fix memleak in hl_device_reset Georgi Djakov (1): MAINTAINERS: Update Georgi's email address Greg Kroah-Hartman (3): Merge tag 'misc-habanalabs-fixes-2020-12-30' of https://git.kernel.org/.../ogabbay/linux into char-misc-linus crypto: asym_tpm: correct zero out potential secrets Merge tag 'icc-5.11-rc3' of git://git.kernel.org/.../djakov/icc into char-misc-linus Martin Kepplinger (1): interconnect: imx8mq: Use icc_sync_state Oded Gabbay (7): habanalabs/gaudi: disable CGM at HW initialization habanalabs/gaudi: enhance reset message habanalabs: update comment in hl_boot_if.h habanalabs: adjust pci controller init to new firmware habanalabs/gaudi: retry loading TPC f/w on -EINTR habanalabs: register to pci shutdown callback habanalabs: fix order of status check Ofir Bitton (2): habanalabs: preboot hard reset support habanalabs: full FW hard reset support Samuel Thibault (1): speakup: Add github repository URL and bug tracker Tomer Tayar (2): habanalabs: Fix a missing-braces warning habanalabs: Revise comment to align with mirror list name MAINTAINERS| 4 +- crypto/asymmetric_keys/asym_tpm.c | 2 +- drivers/interconnect/imx/imx.c | 3 +- drivers/interconnect/imx/imx8mq.c | 2 + drivers/interconnect/qcom/Kconfig | 23 ++- .../misc/habanalabs/common/command_submission.c| 77 +++-- drivers/misc/habanalabs/common/device.c| 8 +- drivers/misc/habanalabs/common/firmware_if.c | 60 +-- drivers/misc/habanalabs/common/habanalabs.h| 4 +- drivers/misc/habanalabs/common/habanalabs_drv.c| 1 + drivers/misc/habanalabs/common/habanalabs_ioctl.c | 7 +- drivers/misc/habanalabs/common/hw_queue.c | 5 +- drivers/misc/habanalabs/common/pci.c | 28 +-- drivers/misc/habanalabs/gaudi/gaudi.c | 191 + drivers/misc/habanalabs/gaudi/gaudiP.h | 7 - drivers/misc/habanalabs/gaudi/gaudi_coresight.c| 3 +- drivers/misc/habanalabs/goya/goya.c| 75 .../misc/habanalabs/include/common/hl_boot_if.h| 9 +- drivers/misc/pvpanic.c | 19 +- include/uapi/misc/habanalabs.h | 5 + lib/fonts/font_ter16x32.c | 6 +- 21 files changed, 322 insertions(+), 217 deletions(-)
[GIT PULL] Staging driver fixes for 5.11-rc3
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.11-rc3 for you to fetch changes up to 00b8c557d096f0930d5c07df618223d3d06902d6: staging: ION: remove some references to CONFIG_ION (2021-01-06 17:39:38 +0100) Staging driver fixes for 5.11-rc3 Here are some small staging driver fixes for 5.11-rc3. Nothing major, just resolving some reported issues: - cleanup some remaining mentions of the ION drivers that were removed in 5.11-rc1 - comedi driver bugfix - 2 error path memory leak fixes All have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Christophe JAILLET (2): staging: spmi: hisi-spmi-controller: Fix some error handling paths staging: mt7621-dma: Fix a resource leak in an error handling path Dan Carpenter (1): Staging: comedi: Return -EFAULT if copy_to_user() fails Matthias Maennich (1): staging: ION: remove some references to CONFIG_ION drivers/staging/comedi/comedi_fops.c | 4 +++- drivers/staging/hikey9xx/hisi-spmi-controller.c| 21 +++-- drivers/staging/media/atomisp/pci/atomisp_subdev.c | 20 drivers/staging/mt7621-dma/mtk-hsdma.c | 4 +++- kernel/configs/android-recommended.config | 1 - 5 files changed, 21 insertions(+), 29 deletions(-)
[GIT PULL] USB driver fixes for 5.11-rc3
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.11-rc3 for you to fetch changes up to a5c768210e42928d73de1c9e1e02d2b14c2e: usb: dwc3: gadget: Clear wait flag on dequeue (2021-01-07 14:24:35 +0100) USB fixes for 5.11-rc3 Here are a number of small USB driver fixes for 5.11-rc3. Include in here are: - USB gadget driver fixes for reported issues - new usb-serial driver ids - dma from stack bugfixes - typec bugfixes - dwc3 bugfixes - xhci driver bugfixes - other small misc usb driver bugfixes All of these have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman Alan Stern (1): USB: Gadget: dummy-hcd: Fix shift-out-of-bounds bug Andrey Konovalov (1): kcov, usb: hide in_serving_softirq checks in __usb_hcd_giveback_urb Arnd Bergmann (1): usb: gadget: select CONFIG_CRC32 Aswath Govindraju (1): dt-bindings: usb: Add new compatible string for AM64 SoC Bjørn Mork (1): USB: serial: option: add Quectel EM160R-GL Chandana Kishori Chiluveru (1): usb: gadget: configfs: Preserve function ordering after bind failure Daniel Palmer (1): USB: serial: option: add LongSung M5710 module support Eddie Hung (1): usb: gadget: configfs: Fix use-after-free issue with udc_name Fabio Estevam (1): usb: gadget: fsl_mxc_udc: Remove the driver Greg Kroah-Hartman (1): Merge tag 'usb-serial-5.11-rc3' of https://git.kernel.org/.../johan/usb-serial into usb-linus Jerome Brunet (1): usb: gadget: f_uac2: reset wMaxPacketSize Johan Hovold (3): USB: yurex: fix control-URB timeout handling USB: serial: iuu_phoenix: fix DMA from stack USB: usblp: fix DMA to stack Madhusudanarao Amara (1): usb: typec: intel_pmc_mux: Configure HPD first for HPD+IRQ request Manish Narani (1): usb: gadget: u_ether: Fix MTU size mismatch with RX packet size Michael Grzeschik (1): USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set Peter Chen (1): usb: gadget: core: change the comment for usb_gadget_connect Peter Robinson (1): usb: typec: Fix copy paste error for NVIDIA alt-mode description Prashant Malani (1): usb: typec: Send uevent for num_altmodes update Randy Dunlap (1): usb: usbip: vhci_hcd: protect shift size Roger Quadros (1): MAINTAINERS: Update address for Cadence USB3 driver Sean Young (1): USB: cdc-acm: blacklist another IR Droid device Serge Semin (3): usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regression Sriharsha Allenki (1): usb: gadget: Fix spinlock lockup on usb_function_deactivate Tetsuo Handa (1): USB: cdc-wdm: Fix use after free in service_outstanding_interrupt(). Thinh Nguyen (2): usb: uas: Add PNY USB Portable SSD to unusual_uas usb: dwc3: gadget: Clear wait flag on dequeue Wesley Cheng (1): usb: dwc3: gadget: Restart DWC3 gadget when enabling pullup Yang Yingliang (1): USB: gadget: legacy: fix return error code in acm_ms_bind() Yu Kuai (1): usb: chipidea: ci_hdrc_imx: add missing put_device() call in usbmisc_get_init_data() Zheng Zengkai (1): usb: dwc3: meson-g12a: disable clk on error handling path in probe Zqiang (1): usb: gadget: function: printer: Fix a memory leak for interface descriptor taehyun.cho (1): usb: gadget: enable super speed plus .../devicetree/bindings/usb/ti,j721e-usb.yaml | 6 +- MAINTAINERS| 2 +- drivers/usb/chipidea/ci_hdrc_imx.c | 6 +- drivers/usb/class/cdc-acm.c| 4 + drivers/usb/class/cdc-wdm.c| 16 ++- drivers/usb/class/usblp.c | 21 +++- drivers/usb/core/hcd.c | 8 +- drivers/usb/dwc3/core.h| 1 + drivers/usb/dwc3/dwc3-meson-g12a.c | 2 +- drivers/usb/dwc3/gadget.c | 16 +-- drivers/usb/dwc3/ulpi.c| 38 --- drivers/usb/gadget/Kconfig | 2 + drivers/usb/gadget/composite.c | 10 +- drivers/usb/gadget/configfs.c | 19 +++- drivers/usb/gadget/function/f_printer.c| 1 + drivers/usb/gadget/function/f_uac2.c | 69 +--- drivers/usb/gadget/function/u_ether.c | 9 +- drivers/usb/gadget/legacy/acm_ms.c |
[PATCH mips-fixes] MIPS: relocatable: fix possible boot hangup with KASLR enabled
LLVM-built Linux triggered a boot hangup with KASLR enabled.
arch/mips/kernel/relocate.c:get_random_boot() uses linux_banner,
which is a string constant, as a random seed, but accesses it
as an array of unsigned long (in rotate_xor()).
When the address of linux_banner is not aligned to sizeof(long),
such access emits unaligned access exception and hangs the kernel.
Use PTR_ALIGN() to align input address to sizeof(long) and also
align down the input length to prevent possible access-beyond-end.
Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
Cc: sta...@vger.kernel.org # 4.7+
Signed-off-by: Alexander Lobakin
---
arch/mips/kernel/relocate.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/mips/kernel/relocate.c b/arch/mips/kernel/relocate.c
index 47aeb3350a76..0e365b7c742d 100644
--- a/arch/mips/kernel/relocate.c
+++ b/arch/mips/kernel/relocate.c
@@ -187,8 +187,14 @@ static int __init relocate_exception_table(long offset)
static inline __init unsigned long rotate_xor(unsigned long hash,
const void *area, size_t size)
{
- size_t i;
- unsigned long *ptr = (unsigned long *)area;
+ const typeof(hash) *ptr = PTR_ALIGN(area, sizeof(hash));
+ size_t diff, i;
+
+ diff = (void *)ptr - area;
+ if (unlikely(size < diff + sizeof(hash)))
+ return hash;
+
+ size = ALIGN_DOWN(size - diff, sizeof(hash));
for (i = 0; i < size / sizeof(hash); i++) {
/* Rotate by odd number of bits and XOR. */
--
2.30.0
Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander
Il 10/01/21 01:24, Linus Walleij ha scritto:
On Sun, Jan 10, 2021 at 12:11 AM AngeloGioacchino Del Regno
wrote:
Il 09/01/21 23:11, Linus Walleij ha scritto:
The major review comment is that it'd be nice if you look into
using regmaps register cache instead of rolling your own,
and also possibly using regmaps locking rather than your own
as a result of that.
Actually, I really tried to use regmap's FLAT register cache and after
many, many tries... I had to give up. I just couldn't get it working. :(
This needs to be root-caused. The register cache in regmap is for
using not for decoration.
What is the problems you are seeing?
If it is fundamentally so that regmap has limitations that is one thing,
but I want to rule out that we're just not using it wrong or that there
is a bug in it that we should fix.
Looping in Mark Brown the regmap maintainer.
Yours,
Linus Walleij
Oh don't misunderstand me, I would really be happy to make use of the
regmap register cache, it's a nice one.
So, I've retried some basic usage of the regcache, relevant snippets here:
static bool aw9523_volatile_reg(struct device *dev, unsigned int reg)
{
return reg == AW9523_REG_IN_STATE(0) ||
reg == AW9523_REG_IN_STATE(AW9523_PINS_PER_PORT) ||
reg == AW9523_REG_CHIPID;
}
static const struct regmap_config aw9523_regmap = {
.volatile_reg = aw9523_volatile_reg,
.cache_type = REGCACHE_FLAT,
}
Since REG_IN_STATE is used to read the GPIO input level, it's not
cacheable, then CHIPID was set as not cacheable for safety: that may be
avoided, but that may make no sense.. since it's a one-time readout for
init putposes, it'd be useless to keep it cached.
Then, the set_bit/clear_bit in aw9523_irq_mask(), aw9523_irq_unmask were
replaced with calls to regmap_update_bits_async, example:
regmap_update_bits_async(awi->regmap,
AW9523_REG_INTR_DIS(d->hwirq),
BIT(n), BIT(n));
Where of course the value is either BIT(n) or 0 for mask and unmask
respectively.
Also, the bus_sync_unlock callback was changed as follows:
static void aw9523_irq_mask(struct irq_data *d)
{
struct aw9523 *awi =
gpiochip_get_data(irq_data_get_irq_chip_data(d));
unsigned int n = d->hwirq % AW9523_PINS_PER_PORT;
regmap_update_bits_async(awi->regmap,
AW9523_REG_INTR_DIS(d->hwirq),
BIT(n), BIT(n));
}
One of the biggest / oddest issues that I get when trying to use
regcache is that I'm getting badbadbad scheduling while atomic warnings
all over and I don't get why, since regcache_default_sync is just
calling _regmap_write, which is exactly what (non _prefix) regmap_write
also calls...
As a reference, this is one out of "many" (as you can imagine) stacktraces:
<3>[1.061428] BUG: scheduling while atomic: kworker/3:1/119/0x
<4>[1.061575] Modules linked in:
<4>[1.061716] CPU: 3 PID: 119 Comm: kworker/3:1 Tainted: GW
5.10.0-rc3-31949-ge1680e3101bc-dirty #1162
<4>[1.061956] Hardware name: F(x)tec Pro1 (QX1000) (DT)
<4>[1.062081] Workqueue: events deferred_probe_work_func
<4>[1.062205] Call trace:
<4>[1.062333] dump_backtrace+0x0/0x1e0
<4>[1.062439] show_stack+0x14/0x60
<4>[1.062539] dump_stack+0xd4/0x12c
<4>[1.062680] __schedule_bug+0x50/0x70
<4>[1.062785] __schedule+0x618/0x650
<4>[1.062888] schedule+0x6c/0xf8
<4>[1.062985] schedule_timeout+0x1d0/0x260
<4>[1.063134] wait_for_completion_timeout+0x8c/0x110
<4>[1.063257] qup_i2c_wait_for_complete.isra.18+0x1c/0x80
<4>[1.063429] qup_i2c_xfer_v2_msg+0x2d4/0x3f0
<4>[1.063543] qup_i2c_xfer_v2+0x290/0xa28
<4>[1.063652] __i2c_transfer+0x16c/0x380
<4>[1.063798] i2c_transfer+0x5c/0x138
<4>[1.063903] i2c_transfer_buffer_flags+0x58/0x80
<4>[1.064060] regmap_i2c_write+0x1c/0x50
<4>[1.064168] _regmap_raw_write_impl+0x35c/0x688
<4>[1.064285] _regmap_bus_raw_write+0x64/0x80
<4>[1.064440] _regmap_write+0x58/0xa8
<4>[1.064545] regcache_default_sync+0xcc/0x1a0
<4>[1.064660] regcache_sync_region+0xdc/0xe8
<4>[1.064811] aw9523_irq_bus_sync_unlock+0x30/0x48
<4>[1.064931] __setup_irq+0x798/0x890
<4>[1.065034] request_threaded_irq+0xe0/0x198
<4>[1.065188] devm_request_threaded_irq+0x78/0xf8
<4>[1.065311] gpio_keyboard_probe+0x2a8/0x468
<4>[1.065465] platform_drv_probe+0x50/0xa0
<4>[1.065576] really_probe+0x290/0x4e8
<4>[1.065682] driver_probe_device+0xf4/0x160
<4>[1.065834] __device_attach_driver+0x98/0x110
<4>[1.065950] bus_for_each_drv+0x64/0xc8
<4>[1.066063] __device_attach+0xe4/0x168
<4>[1.066211] device_initial_probe+0x10/0x18
<4>[1.066325] bus_probe_device+0x90/0x98
<4>[1.066434]
[PATCH net-next] net: mvpp2: prs: improve ipv4 parse flow
From: Stefan Chulski Patch didn't fix any issue, just improve parse flow and align ipv4 parse flow with ipv6 parse flow. Currently ipv4 kenguru parser first check IP protocol(TCP/UDP) and then destination IP address. Patch introduce reverse ipv4 parse, first destination IP address parsed and only then IP protocol. This would allow extend capability for packet L4 parsing and align ipv4 parsing flow with ipv6. Suggested-by: Liron Himi Signed-off-by: Stefan Chulski --- drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c | 64 1 file changed, 39 insertions(+), 25 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c index 5692c60..b9e5b08 100644 --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_prs.c @@ -882,15 +882,15 @@ static int mvpp2_prs_ip4_proto(struct mvpp2 *priv, unsigned short proto, mvpp2_prs_tcam_lu_set(, MVPP2_PRS_LU_IP4); pe.index = tid; - /* Set next lu to IPv4 */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_sram_shift_set(, 12, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); + /* Finished: go to flowid generation */ + mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_FLOWS); + mvpp2_prs_sram_bits_set(, MVPP2_PRS_SRAM_LU_GEN_BIT, 1); + /* Set L4 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L4, sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_UDF_ADD); - mvpp2_prs_sram_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, -MVPP2_PRS_IPV4_DIP_AI_BIT); + mvpp2_prs_sram_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); mvpp2_prs_sram_ri_update(, ri, ri_mask | MVPP2_PRS_RI_IP_FRAG_MASK); mvpp2_prs_tcam_data_byte_set(, 2, 0x00, @@ -899,7 +899,8 @@ static int mvpp2_prs_ip4_proto(struct mvpp2 *priv, unsigned short proto, MVPP2_PRS_TCAM_PROTO_MASK); mvpp2_prs_tcam_data_byte_set(, 5, proto, MVPP2_PRS_TCAM_PROTO_MASK); - mvpp2_prs_tcam_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); + mvpp2_prs_tcam_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, +MVPP2_PRS_IPV4_DIP_AI_BIT); /* Unmask all ports */ mvpp2_prs_tcam_port_map_set(, MVPP2_PRS_PORT_MASK); @@ -967,12 +968,17 @@ static int mvpp2_prs_ip4_cast(struct mvpp2 *priv, unsigned short l3_cast) return -EINVAL; } - /* Finished: go to flowid generation */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_FLOWS); - mvpp2_prs_sram_bits_set(, MVPP2_PRS_SRAM_LU_GEN_BIT, 1); + /* Go again to ipv4 */ + mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_tcam_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, + mvpp2_prs_sram_ai_update(, MVPP2_PRS_IPV4_DIP_AI_BIT, MVPP2_PRS_IPV4_DIP_AI_BIT); + + /* Shift back to IPv4 proto */ + mvpp2_prs_sram_shift_set(, -12, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); + + mvpp2_prs_tcam_ai_update(, 0, MVPP2_PRS_IPV4_DIP_AI_BIT); + /* Unmask all ports */ mvpp2_prs_tcam_port_map_set(, MVPP2_PRS_PORT_MASK); @@ -1392,8 +1398,9 @@ static int mvpp2_prs_etype_init(struct mvpp2 *priv) mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); mvpp2_prs_sram_ri_update(, MVPP2_PRS_RI_L3_IP4, MVPP2_PRS_RI_L3_PROTO_MASK); - /* Skip eth_type + 4 bytes of IP header */ - mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 4, + /* goto ipv4 dest-address (skip eth_type + IP-header-size - 4) */ + mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + +sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); /* Set L3 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L3, @@ -1597,8 +1604,9 @@ static int mvpp2_prs_pppoe_init(struct mvpp2 *priv) mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); mvpp2_prs_sram_ri_update(, MVPP2_PRS_RI_L3_IP4_OPT, MVPP2_PRS_RI_L3_PROTO_MASK); - /* Skip eth_type + 4 bytes of IP header */ - mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + 4, + /* goto ipv4 dest-address (skip eth_type + IP-header-size - 4) */ + mvpp2_prs_sram_shift_set(, MVPP2_ETH_TYPE_LEN + +sizeof(struct iphdr) - 4, MVPP2_PRS_SRAM_OP_SEL_SHIFT_ADD); /* Set L3 offset */ mvpp2_prs_sram_offset_set(, MVPP2_PRS_SRAM_UDF_TYPE_L3, @@ -1727,19 +1735,20 @@ static int mvpp2_prs_ip4_init(struct mvpp2 *priv) mvpp2_prs_tcam_lu_set(, MVPP2_PRS_LU_IP4); pe.index = MVPP2_PE_IP4_PROTO_UN; - /* Set next lu to IPv4 */ - mvpp2_prs_sram_next_lu_set(, MVPP2_PRS_LU_IP4); - mvpp2_prs_sram_shift_set(, 12,
Re: [PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
Hi Chen-Yu,
Some comments, have a look if it is useful...
On 1/10/21 4:58 AM, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai
>
> Radxa ROCK Pi E is a router oriented SBC based on Rockchip's RK3328 SoC.
> As the official wiki page puts it, "E for Ethernets".
>
> It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both
> directly served by Ethernet controllers in the SoC, a USB 3.0 host port,
> a power-only USB type-C port, a 3.5mm headphone jack for audio output,
> two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT
> and PoE header.
>
> The board comes in multiple configurations, differing in the amount of
> onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac
> 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants
> can all share the same device tree.
>
> The USB 2.0 OTG controller is available on the 40-pin header. This is
> not enabled in the device tree, since it is possible to use it in a
> host-only configuration, or in OTG mode with an extra pin from the
> header as the ID pin.
>
> The device tree is based on the one of the Rock64, with various parts
> modified to match the ROCK Pi E, and some parts updated to newer styles,
> such as the gmac2io node's mdio sub-node.
>
> Add a new device tree file for the new board.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3328-rock-pi-e.dts| 369 ++
> 2 files changed, 370 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index 622d320ddd13..62d3abc17a24 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -11,6 +11,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> new file mode 100644
> index ..7818d2e8180c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> @@ -0,0 +1,369 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * (C) Copyright 2020 Chen-Yu Tsai
> + *
> + * Based on ./rk3328-rock64.dts, which is
> + *
> + * Copyright (c) 2017 PINE64
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include
> +#include "rk3328.dtsi"
> +
> +/ {
> + model = "Radxa ROCK Pi E";
> + compatible = "radxa,rockpi-e", "rockchip,rk3328";
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + gmac_clkin: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <12500>;
> + clock-output-names = "gmac_clkin";
> + #clock-cells = <0>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <_pin>;
> + pinctrl-names = "default";
> +
> + led-0 {
> + /* schematic say green but the actual thing is blue */
In rockpie-v1.2-20200427-sch.pdf this led is already called "LED_BLUE",
so comment maybe not needed anymore?
> + color = ;
> + gpios = < RK_PA5 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "heartbeat";
> + };> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin>;
> + regulator-boot-on;
> + regulator-name = "vcc_sd";
regulator-name above other regulator properties
regulator voltage missing
make things as complete as possible
from fixed-regulator.yaml:
description:
Any property defined as part of the core regulator binding, defined in
regulator.yaml, can also be used. However a fixed voltage regulator is
expected to have the regulator-min-microvolt and regulator-max-microvolt
to be the same.
> + vin-supply = <_io>;
> + };
> +
> + vcc_host_5v: vcc-host-5v-regulator {
> + compatible = "regulator-fixed";
> + gpio = < RK_PA7 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_host_drv>;
> + enable-active-high;
> + regulator-name = "vcc_host_5v";
idem limits
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <_sys>;
> + };
For Heiko: ?? remove ??
usb3 has no
Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander
Il 10/01/21 15:32, AngeloGioacchino Del Regno ha scritto:
Il 10/01/21 01:24, Linus Walleij ha scritto:
On Sun, Jan 10, 2021 at 12:11 AM AngeloGioacchino Del Regno
wrote:
Il 09/01/21 23:11, Linus Walleij ha scritto:
The major review comment is that it'd be nice if you look into
using regmaps register cache instead of rolling your own,
and also possibly using regmaps locking rather than your own
as a result of that.
Actually, I really tried to use regmap's FLAT register cache and after
many, many tries... I had to give up. I just couldn't get it working. :(
This needs to be root-caused. The register cache in regmap is for
using not for decoration.
What is the problems you are seeing?
If it is fundamentally so that regmap has limitations that is one thing,
but I want to rule out that we're just not using it wrong or that there
is a bug in it that we should fix.
Looping in Mark Brown the regmap maintainer.
Yours,
Linus Walleij
Oh don't misunderstand me, I would really be happy to make use of the
regmap register cache, it's a nice one.
So, I've retried some basic usage of the regcache, relevant snippets here:
static bool aw9523_volatile_reg(struct device *dev, unsigned int reg)
{
return reg == AW9523_REG_IN_STATE(0) ||
reg == AW9523_REG_IN_STATE(AW9523_PINS_PER_PORT) ||
reg == AW9523_REG_CHIPID;
}
static const struct regmap_config aw9523_regmap = {
.volatile_reg = aw9523_volatile_reg,
.cache_type = REGCACHE_FLAT,
}
Since REG_IN_STATE is used to read the GPIO input level, it's not
cacheable, then CHIPID was set as not cacheable for safety: that may be
avoided, but that may make no sense.. since it's a one-time readout for
init putposes, it'd be useless to keep it cached.
Then, the set_bit/clear_bit in aw9523_irq_mask(), aw9523_irq_unmask were
replaced with calls to regmap_update_bits_async, example:
regmap_update_bits_async(awi->regmap,
AW9523_REG_INTR_DIS(d->hwirq),
BIT(n), BIT(n));
Where of course the value is either BIT(n) or 0 for mask and unmask
respectively.
Also, the bus_sync_unlock callback was changed as follows:
static void aw9523_irq_mask(struct irq_data *d)
{
struct aw9523 *awi =
gpiochip_get_data(irq_data_get_irq_chip_data(d));
unsigned int n = d->hwirq % AW9523_PINS_PER_PORT;
regmap_update_bits_async(awi->regmap,
AW9523_REG_INTR_DIS(d->hwirq),
BIT(n), BIT(n));
}
Sorry, wrong paste! This is the right one:
static void aw9523_irq_bus_sync_unlock(struct irq_data *d)
{
struct aw9523 *awi = gpiochip_get_data(irq_data_get_irq_chip_data(d));
regcache_mark_dirty(awi->regmap);
regcache_sync_region(awi->regmap, AW9523_REG_INTR_DIS(0),
AW9523_REG_INTR_DIS(AW9523_PINS_PER_PORT));
mutex_unlock(>irq->lock);
}
One of the biggest / oddest issues that I get when trying to use
regcache is that I'm getting badbadbad scheduling while atomic warnings
all over and I don't get why, since regcache_default_sync is just
calling _regmap_write, which is exactly what (non _prefix) regmap_write
also calls...
As a reference, this is one out of "many" (as you can imagine) stacktraces:
<3>[ 1.061428] BUG: scheduling while atomic: kworker/3:1/119/0x
<4>[ 1.061575] Modules linked in:
<4>[ 1.061716] CPU: 3 PID: 119 Comm: kworker/3:1 Tainted: G W
5.10.0-rc3-31949-ge1680e3101bc-dirty #1162
<4>[ 1.061956] Hardware name: F(x)tec Pro1 (QX1000) (DT)
<4>[ 1.062081] Workqueue: events deferred_probe_work_func
<4>[ 1.062205] Call trace:
<4>[ 1.062333] dump_backtrace+0x0/0x1e0
<4>[ 1.062439] show_stack+0x14/0x60
<4>[ 1.062539] dump_stack+0xd4/0x12c
<4>[ 1.062680] __schedule_bug+0x50/0x70
<4>[ 1.062785] __schedule+0x618/0x650
<4>[ 1.062888] schedule+0x6c/0xf8
<4>[ 1.062985] schedule_timeout+0x1d0/0x260
<4>[ 1.063134] wait_for_completion_timeout+0x8c/0x110
<4>[ 1.063257] qup_i2c_wait_for_complete.isra.18+0x1c/0x80
<4>[ 1.063429] qup_i2c_xfer_v2_msg+0x2d4/0x3f0
<4>[ 1.063543] qup_i2c_xfer_v2+0x290/0xa28
<4>[ 1.063652] __i2c_transfer+0x16c/0x380
<4>[ 1.063798] i2c_transfer+0x5c/0x138
<4>[ 1.063903] i2c_transfer_buffer_flags+0x58/0x80
<4>[ 1.064060] regmap_i2c_write+0x1c/0x50
<4>[ 1.064168] _regmap_raw_write_impl+0x35c/0x688
<4>[ 1.064285] _regmap_bus_raw_write+0x64/0x80
<4>[ 1.064440] _regmap_write+0x58/0xa8
<4>[ 1.064545] regcache_default_sync+0xcc/0x1a0
<4>[ 1.064660] regcache_sync_region+0xdc/0xe8
<4>[ 1.064811] aw9523_irq_bus_sync_unlock+0x30/0x48
<4>[ 1.064931] __setup_irq+0x798/0x890
<4>[ 1.065034] request_threaded_irq+0xe0/0x198
<4>[ 1.065188] devm_request_threaded_irq+0x78/0xf8
<4>[ 1.065311] gpio_keyboard_probe+0x2a8/0x468
<4>[ 1.065465] platform_drv_probe+0x50/0xa0
<4>[
[PATCH] drivers: base: change 'driver_create_groups' to 'driver_add_groups' in printk
driver_create_groups doesn't seem to have ever existed. Change its
mention in a printk to 'driver_add_groups'.
Signed-off-by: Joe Pater <02joepate...@gmail.com>
---
drivers/base/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index a9c23ecebc7c..a34ba825bad7 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -633,7 +633,7 @@ int bus_add_driver(struct device_driver *drv)
error = driver_add_groups(drv, bus->drv_groups);
if (error) {
/* How the hell do we get out of this pickle? Give up */
- printk(KERN_ERR "%s: driver_create_groups(%s) failed\n",
+ printk(KERN_ERR "%s: driver_add_groups(%s) failed\n",
__func__, drv->name);
}
base-commit: 2ff90100ace886895e4fbb2850b8d5e49d931ed6
--
2.29.2
Re: [PATCH v8 04/20] dlb: add device ioctl layer and first three ioctls
On Sat, Jan 09, 2021 at 01:49:42PM -0800, Dan Williams wrote:
> On Sat, Jan 9, 2021 at 12:34 AM Greg KH wrote:
> >
> > On Sat, Jan 09, 2021 at 07:49:24AM +, Chen, Mike Ximing wrote:
> > > > > +static int dlb_ioctl_arg_size[NUM_DLB_CMD] = {
> > > > > + sizeof(struct dlb_get_device_version_args),
> > > > > + sizeof(struct dlb_create_sched_domain_args),
> > > > > + sizeof(struct dlb_get_num_resources_args)
> > > >
> > > > That list.
> > > >
> > > > Ugh, no. that's no way to write maintainable code that you will be able
> > > > to understand in 2 years.
> > > >
> > >
> > > dlb_ioctl() was implemented with switch-case and real function calls
> > > previously.
> > > We changed to the table/list implementation during a code restructure. I
> > > will move
> > > back to the old implementation.
> >
> > Who said to change this? And why did they say that? Please go back to
> > those developers and point them at this thread so that doesn't happen
> > again...
> >
> > > > > +{
> > > > > + struct dlb *dlb;
> > > > > + dlb_ioctl_fn_t fn;
> > > > > + u32 cmd_nr;
> > > > > + void *karg;
> > > > > + int size;
> > > > > + int ret;
> > > > > +
> > > > > + dlb = f->private_data;
> > > > > +
> > > > > + if (!dlb) {
> > > > > + pr_err("dlb: [%s()] Invalid DLB data\n", __func__);
> > > > > + return -EFAULT;
> > > >
> > > > This error value is only allowed if you really do have a memory fault.
> > > >
> > > > Hint, you do not here.
> > > >
> > > > How can that value ever be NULL?
> > > >
> > >
> > > It is targeted at some very rare cases, in which an ioctl command are
> > > called immediately after a device unbind (by a different
> > > process/application).
> >
> > And how can that happen? If it really can happen, where is the lock
> > that you are holding to keep that pointer from becoming "stale" right
> > after you assign it?
> >
> > So either this never can happen, or your logic here for this type of
> > thing is totally wrong. Please work to determine which it is.
>
> I would have preferred a chance to offer a reviewed-by on this set
> before it went out (per the required process) to validate that the
> feedback on the lifetime handling was properly addressed, it wasn't,
> but lets deal with this on the list now.
>
> The race to handle is the one identified by cdev_del():
>
> * NOTE: This guarantees that cdev device will no longer be able to be
> * opened, however any cdevs already open will remain and their fops will
> * still be callable even after cdev_del returns.
>
> This means that the dlb->private_data is pointing to a live device, a
> dying device, or NULL. Without revalidating to the dlb pointer under a
> lock, or some other coordinated reference cout, it can transition
> states underneath the running ioctl.
But, that's only the case if this is the last cdev reference held here,
right? How can a close be called if a filehandle is still open such
that an ioctl can be called?
This should just be a "simple" char device operation, with no need to be
fancy or anything odd like that, right? If not, then yes, this really
does need a real lock.
> Greg, I'm thinking of taking a shot at a document, "botching up device
> lifetimes", in the same spirit as
> Documentation/process/botching-up-ioctls.rst to lay out the different
> schemes for revalidating driver private data in ioctls.
Sure, but again, it should be "simple" in that an ioctl can't be called
after close() happens.
> It strikes me that a helper like this might address many of the common
> patterns:
>
> +/**
> + * get_live_device() - increment reference count for device iff !dead
> + * @dev: device.
> + *
> + * Forward the call to get_device() if the device is still alive. If
> + * this is called with the device_lock() held then the device is
> + * guaranteed to not die until the device_lock() is dropped.
> + */
> +struct device *get_live_device(struct device *dev)
> +{
> + return dev && !dev->p->dead ? get_device(dev) : NULL;
> +}
> +EXPORT_SYMBOL_GPL(get_live_device);
Ick, no, that's still racy :(
And a cdev is not a "real" struct device, despite looking like one if
you squint at it. The patches from Christoph should be merged soon that
remove the last remants of the logic that kind of looked like a struct
device operation (with a kobject), and after that, I will clean it out
to keep it from looking like it ties into the driver model entirely, as
many people get this wrong, because it does not.
> Alternatively, if device_lock() is too awkward for a driver it could
> use its own lock and kill_device().
>
> ...am I off base thinking that cdev_del vs fops liveness is a
> widespread problem worth documenting new design patterns?
It shouldn't be a problem, again, because who would be able to close a
char device node and still be able to call ioctl on it? The VFS layer
should prevent that from happening, right?
thanks,
greg k-h
Re: [PATCH v5 00/15] Add functionality to ipu3-cio2 driver allowing software_node connections to sensors on platforms designed for Windows
On Sat, Jan 09, 2021 at 04:08:04AM +0200, Laurent Pinchart wrote: > Hi Greg, > > On Thu, Jan 07, 2021 at 01:28:23PM +, Daniel Scally wrote: > > > > Hello all > > > > v4: > > https://lore.kernel.org/linux-media/20210103231235.792999-1-djrsca...@gmail.com/T/#m11b7cb977e1b73fba1e625c3d6a189e2943a7783 > > v3: > > https://lore.kernel.org/linux-media/20201224010907.263125-1-djrsca...@gmail.com/T/#m37b831bb2b406917d6db5da9acf9ed35df65d72d > > v2: > > https://lore.kernel.org/linux-media/20201217234337.1983732-1-djrsca...@gmail.com/T/#md93fd090009b42a6a98aed892aff0d38cf07e0cd > > v1: > > https://lore.kernel.org/linux-media/20201130133129.1024662-1-djrsca...@gmail.com/T/#m91934e12e3d033da2e768e952ea3b4a125ee3e67 > > > > This series is to start adding support for webcams on laptops with ACPI > > tables > > designed for use with CIO2 on Windows. This series extends the ipu3-cio2 > > driver to allow for patching the firmware via software_nodes if endpoints > > aren't defined by ACPI. > > > > I'm hopeful that most or all of this series could get picked up for 5.12. > > We touch a few different areas (listed below), but I think the easiest > > approach would be to merge everything through media tree. Rafael, Greg, > > Mauro and Sergey; are you ok with that plan, or would you prefer a > > different approach? Mauro; if that plan is ok (and of course assuming that > > the rest of the patches are acked by their respective maintainers) could > > we get a dedicated feature branch just in case the following series ends > > up being ready in time too? > > > > lib > > lib/test_printf.c: Use helper function to unwind array of > > software_nodes > > > > base > > software_node: Fix refcounts in software_node_get_next_child() > > property: Return true in fwnode_device_is_available for NULL ops > > property: Call fwnode_graph_get_endpoint_by_id() for fwnode->secondary > > software_node: Enforce parent before child ordering of nodes arrays > > software_node: unregister software_nodes in reverse order > > Could you please let us know with an Acked-by if these patches can be > merged through the linux-media tree for v5.12 ? This is a cross-tree > series and we would like to avoid topic branches if possible. Yes, they are all fine with me, will go provide my ack, sorry for the delay. greg k-h
Re: [PATCH v5 08/15] software_node: Add support for fwnode_graph*() family of functions
On Thu, Jan 07, 2021 at 01:28:31PM +, Daniel Scally wrote: > From: Heikki Krogerus > > This implements the remaining .graph_*() callbacks in the fwnode > operations structure for the software nodes. That makes the > fwnode_graph_*() functions available in the drivers also when software > nodes are used. > > The implementation tries to mimic the "OF graph" as much as possible, but > there is no support for the "reg" device property. The ports will need to > have the index in their name which starts with "port@" (for example > "port@0", "port@1", ...) and endpoints will use the index of the software > node that is given to them during creation. The port nodes can also be > grouped under a specially named "ports" subnode, just like in DT, if > necessary. > > The remote-endpoints are reference properties under the endpoint nodes > that are named "remote-endpoint". > > Reviewed-by: Laurent Pinchart > Reviewed-by: Andy Shevchenko > Signed-off-by: Heikki Krogerus > Co-developed-by: Daniel Scally > Signed-off-by: Daniel Scally > --- > Changes in v5: > > - Cosmetic changes only Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 0/4] Config and device tree updates for the Librem 5 devkit
Hi Shawn, On Sun, Jan 10, 2021 at 08:26:18PM +0800, Shawn Guo wrote: > On Thu, Dec 17, 2020 at 04:13:11PM +0100, Guido Günther wrote: > > This enables more components to get a working display, panel, audio and > > sensors. It also updates some device tree bits to make mainline boot. > > > > I've skipped wifi (which needs some more driver work) and devfreq (since > > Martin > > is working on that). > > > > The config changes don't depend on the DT parts so could be applied > > independently. The series was tested against next-20201214 and i made sure > > the > > defconfig changes also apply on top of shawnguo/imx/defconfig. > > Sorry. It doesn't apply any more. v3 of this patch https://lore.kernel.org/linux-arm-kernel/5636a3d6e3217475e2a479248250d5c0e0a50e26.1610110514.git@sigxcpu.org/) applies for me on top of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/log/?h=imx/defconfig (which is at 773fcbcdf9d66b4aec964238b613e93804cba24c) - am i looking at the wrong tree? Cheers and sorry for any inconvenience, -- Guido > > Shawn >
Re: [PATCH v5 06/15] software_node: unregister software_nodes in reverse order
On Thu, Jan 07, 2021 at 01:28:29PM +, Daniel Scally wrote: > To maintain consistency with software_node_unregister_nodes(), reverse > the order in which the software_node_unregister_node_group() function > unregisters nodes. > > Reported-by: kernel test robot > Reported-by: Dan Carpenter > Reviewed-by: Laurent Pinchart > Reviewed-by: Sakari Ailus > Suggested-by: Andy Shevchenko > Signed-off-by: Daniel Scally Acked-by: Greg Kroah-Hartman
