Re: [PATCH] thermal/drivers/tsens: fix missing put_device error
Hi, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc5 next-20210401] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/zhuguangqing83-gmail-com/thermal-drivers-tsens-fix-missing-put_device-error/20210404-123439 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 2023a53bdf41b7646b1d384b6816af06309f73a5 config: arm64-randconfig-r004-20210404 (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/8c940b4ee5ee1d96be026eee71f0c682262f94e4 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review zhuguangqing83-gmail-com/thermal-drivers-tsens-fix-missing-put_device-error/20210404-123439 git checkout 8c940b4ee5ee1d96be026eee71f0c682262f94e4 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All error/warnings (new ones prefixed by >>): drivers/thermal/qcom/tsens.c: In function 'init_common': >> drivers/thermal/qcom/tsens.c:856:12: error: invalid storage class for >> function 'tsens_get_temp' 856 | static int tsens_get_temp(void *data, int *temp) |^~ >> drivers/thermal/qcom/tsens.c:856:1: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] 856 | static int tsens_get_temp(void *data, int *temp) | ^~ >> drivers/thermal/qcom/tsens.c:864:12: error: invalid storage class for >> function 'tsens_get_trend' 864 | static int tsens_get_trend(void *data, int trip, enum thermal_trend *trend) |^~~ >> drivers/thermal/qcom/tsens.c:875:28: error: invalid storage class for >> function 'tsens_suspend' 875 | static int __maybe_unused tsens_suspend(struct device *dev) |^ >> drivers/thermal/qcom/tsens.c:885:27: error: invalid storage class for >> function 'tsens_resume' 885 | static int __maybe_unused tsens_resume(struct device *dev) | ^~~~ In file included from include/linux/device.h:25, from include/linux/of_platform.h:9, from drivers/thermal/qcom/tsens.c:14: >> drivers/thermal/qcom/tsens.c:895:40: error: initializer element is not >> constant 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); |^ include/linux/pm.h:306:13: note: in definition of macro 'SET_SYSTEM_SLEEP_PM_OPS' 306 | .suspend = suspend_fn, \ | ^~ drivers/thermal/qcom/tsens.c:895:8: note: in expansion of macro 'SIMPLE_DEV_PM_OPS' 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); |^ drivers/thermal/qcom/tsens.c:895:40: note: (near initialization for 'tsens_pm_ops.suspend') 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); |^ include/linux/pm.h:306:13: note: in definition of macro 'SET_SYSTEM_SLEEP_PM_OPS' 306 | .suspend = suspend_fn, \ | ^~ drivers/thermal/qcom/tsens.c:895:8: note: in expansion of macro 'SIMPLE_DEV_PM_OPS' 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); |^ drivers/thermal/qcom/tsens.c:895:55: error: initializer element is not constant 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); | ^~~~ include/linux/pm.h:307:12: note: in definition of macro 'SET_SYSTEM_SLEEP_PM_OPS' 307 | .resume = resume_fn, \ |^ drivers/thermal/qcom/tsens.c:895:8: note: in expansion of macro 'SIMPLE_DEV_PM_OPS' 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); |^ drivers/thermal/qcom/tsens.c:895:55: note: (near initialization for 'tsens_pm_ops.resume') 895 | static SIMPLE_DEV_PM_OPS(tsens_pm_ops, tsens_suspend, tsens_resume); | ^~~~ include/linux/pm.h:307:12: note: in definition of macro 'SET_SYSTEM_SLEEP_PM_OPS' 307 | .resume = resume_fn, \ |
Re: [PATCH net-next v1 1/9] net: dsa: add rcv_post call back
Am 04.04.21 um 01:21 schrieb Vladimir Oltean:
> On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote:
>> On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote:
>>> Some switches (for example ar9331) do not provide enough information
>>> about forwarded packets. If the switch decision was made based on IPv4
>>> or IPv6 header, we need to analyze it and set proper flag.
>>>
>>> Potentially we can do it in existing rcv path, on other hand we can
>>> avoid part of duplicated work and let the dsa framework set skb header
>>> pointers and then use preprocessed skb one step later withing the rcv_post
>>> call back.
>>>
>>> This patch is needed for ar9331 switch.
>>>
>>> Signed-off-by: Oleksij Rempel
>>> ---
>>
>> I don't necessarily disagree with this, perhaps we can even move
>> Florian's dsa_untag_bridge_pvid() call inside a rcv_post() method
>> implemented by the DSA_TAG_PROTO_BRCM_LEGACY, DSA_TAG_PROTO_BRCM_PREPEND
>> and DSA_TAG_PROTO_BRCM taggers. Or even better, because Oleksij's
>> rcv_post is already prototype-compatible with dsa_untag_bridge_pvid, we
>> can already do:
>>
>> .rcv_post = dsa_untag_bridge_pvid,
>>
>> This should be generally useful for stuff that DSA taggers need to do
>> which is easiest done after eth_type_trans() was called.
>
> I had some fun with an alternative method of parsing the frame for IGMP
> so that you can clear skb->offload_fwd_mark, which doesn't rely on the
> introduction of a new method in DSA. It should also have several other
> advantages compared to your solution such as the fact that it should
> work with VLAN-tagged packets.
>
> Background: we made Receive Packet Steering work on DSA master interfaces
> (echo 3 > /sys/class/net/eth0/queues/rx-1/rps_cpus) even when the DSA
> tag shifts to the right the IP headers and everything that comes
> afterwards. The flow dissector had to be patched for that, just grep for
> DSA in net/core/flow_dissector.c.
>
> The problem you're facing is that you can't parse the IP and IGMP
> headers in the tagger's rcv() method, since the network header,
> transport header offsets and skb->protocol are all messed up, since
> eth_type_trans hasn't been called yet.
>
> And that's the trick right there, you're between a rock and a hard
> place: too early because eth_type_trans wasn't called yet, and too late
> because skb->dev was changed and no longer points to the DSA master, so
> the flow dissector adjustment we made doesn't apply.
>
> But if you call the flow dissector _before_ you call "skb->dev =
> dsa_master_find_slave" (and yes, while the DSA tag is still there), then
> it's virtually as if you had called that while the skb belonged to the
> DSA master, so it should work with __skb_flow_dissect.
>
> In fact I prototyped this idea below. I wanted to check whether I can
> match something as fine-grained as an IGMPv2 Membership Report message,
> and I could.
>
> I prototyped it inside the ocelot tagging protocol driver because that's
> what I had handy. I used __skb_flow_dissect with my own flow dissector
> which had to be initialized at the tagger module_init time, even though
> I think I could have probably just called skb_flow_dissect_flow_keys
> with a standard dissector, and that would have removed the need for the
> custom module_init in tag_ocelot.c. One thing that is interesting is
> that I had to add the bits for IGMP parsing to the flow dissector
> myself (based on the existing ICMP code). I was too lazy to do that for
> MLD as well, but it is really not hard. Or even better, if you don't
> need to look at all inside the IGMP/MLD header, I think you can even
> omit adding this parsing code to the flow dissector and just look at
> basic.n_proto and basic.ip_proto.
>
> See the snippet below. Hope it helps.
>
> -[ cut here ]-
> diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
> index ffd386ea0dbb..4c25fa47637a 100644
> --- a/include/net/flow_dissector.h
> +++ b/include/net/flow_dissector.h
> @@ -190,6 +190,20 @@ struct flow_dissector_key_icmp {
> u16 id;
> };
>
> +/**
> + * flow_dissector_key_igmp:
> + * type: indicates the message type, see include/uapi/linux/igmp.h
> + * code: Max Resp Code, the maximum time in 1/10 second
> + * increments before sending a responding report
> + * group: the multicast address being queried when sending a
> + * Group-Specific or Group-and-Source-Specific Query.
> + */
> +struct flow_dissector_key_igmp {
> + u8 type;
> + u8 code; /* Max Resp Time in IGMPv2 */
> + __be32 group;
> +};
> +
> /**
> * struct flow_dissector_key_eth_addrs:
> * @src: source Ethernet address
> @@ -259,6 +273,7 @@ enum flow_dissector_key_id {
> FLOW_DISSECTOR_KEY_PORTS, /* struct flow_dissector_key_ports */
> FLOW_DISSECTOR_KEY_PORTS_RANGE, /* struct flow_dissector_key_ports */
> FLOW_DISSECTOR_KEY_ICMP, /* struct
[PATCH] staging: rtl8188eu: replace goto with direct return
To conform with Linux kernel coding style, replace goto statement that does no cleanup with a direct return. To preserve meaning, copy comments from the original goto statement to the return statement. Identified by the checkpatch warning: WARNING: void function return statements are not generally useful. Signed-off-by: Deborah Brouwer --- drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c index 391c59490718..d21f21857c20 100644 --- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c +++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c @@ -139,7 +139,9 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) hw_init_completed = Adapter->hw_init_completed; if (!hw_init_completed) - goto skip_dm; + /* Check GPIO to determine current RF on/off and Pbc status. */ + /* Check Hardware Radio ON/OFF or not */ + return; /* ODM */ pmlmepriv = >mlmepriv; @@ -156,10 +158,8 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) Adapter->HalData->odmpriv.bLinked = bLinked; ODM_DMWatchdog(>HalData->odmpriv); -skip_dm: /* Check GPIO to determine current RF on/off and Pbc status. */ /* Check Hardware Radio ON/OFF or not */ - return; } void rtw_hal_dm_init(struct adapter *Adapter) -- 2.17.1
Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets
Am 04.04.21 um 02:02 schrieb Vladimir Oltean:
> On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
>> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
@@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff
*skb,
__le16 *phdr;
u16 hdr;
+ if (dp->stp_state == BR_STATE_BLOCKING) {
+ /* TODO: should we reflect it in the stats? */
+ netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
+ __func__, __LINE__);
+ return NULL;
+ }
+
phdr = skb_push(skb, AR9331_HDR_LEN);
hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
>>>
>>> Hi Oleksij
>>>
>>> This change does not seem to fit with what this patch is doing.
>>
>> done
>>
>>> I also think it is wrong. You still need BPDU to pass through a
>>> blocked port, otherwise spanning tree protocol will be unstable.
>>
>> We need a better filter, otherwise, in case of software based STP, we are
>> leaking packages on
>> blocked port. For example DHCP do trigger lots of spam in the kernel log.
>
> I have no idea whatsoever what 'software based STP' is, if you have
> hardware-accelerated forwarding.
I do not mean hardware-accelerated forwarding, i mean
hardware-accelerated STP port state helpers.
>> I'll drop STP patch for now, it will be better to make a generic soft STP
>> for all switches without
>> HW offloading. For example ksz9477 is doing SW based STP in similar way.
>
> How about we discuss first about what your switch is not doing properly?
> Have you debugged more than just watching the bridge change port states?
> As Andrew said, a port needs to accept and send link-local frames
> regardless of the STP state. In the BLOCKING state it must send no other
> frames and have address learning disabled. Is this what's happening, is
> the switch forwarding frames towards a BLOCKING port?
The switch is not forwarding BPDU frame to the CPU port. So, the linux
bridge will stack by cycling different state of the port where loop was
detected.
--
Regards,
Oleksij
metric.c:undefined reference to `atomic64_read_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 18f473b384a64cef69f166a3e2b73d3d2eca82c6 ceph: periodically send perf metrics to MDSes date: 8 months ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=18f473b384a64cef69f166a3e2b73d3d2eca82c6 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 18f473b384a64cef69f166a3e2b73d3d2eca82c6 # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: inode.c:(.text+0x352a): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x353d): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3571): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x357e): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3587): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x359c): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_fill_trace': inode.c:(.text+0x397b): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3bc0): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3dde): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3dec): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3e3e): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/inode.o:inode.c:(.text+0x3f1e): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: fs/ceph/inode.o: in function `ceph_readdir_prepopulate': inode.c:(.text+0x48c8): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x48e4): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4b31): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4b72): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_prune': dir.c:(.text+0xb3): undefined reference to `atomic64_inc_386' /usr/bin/ld: dir.c:(.text+0xde): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_release': dir.c:(.text+0x1b5): undefined reference to `atomic64_dec_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_init': dir.c:(.text+0x294): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `__dcache_find_get_entry': dir.c:(.text+0x503): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x512): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x556): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x565): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_async_unlink_cb': dir.c:(.text+0x9b6): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_lookup': dir.c:(.text+0x1b6f): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x1b7f): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_revalidate': dir.c:(.text+0x295b): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_readdir': dir.c:(.text+0x3459): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x3468): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x347e): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x348d): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x3f12): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o:dir.c:(.text+0x3f92): more undefined references to `atomic64_read_386' follow /usr/bin/ld: fs/ceph/dir.o: in function `ceph_readdir': dir.c:(.text+0x3fc8): undefined reference to `atomic64_set_386' /usr/bin/ld: dir.c:(.text+0x3fdb): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/file.o: in function `ceph_finish_async_create': file.c:(.text+0x68d): undefined reference to `atomic64_inc_386' /usr/bin/ld: file.c:(.text+0x6ce): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/file.o: in function `ceph_async_create_cb': file.c:(.text+0x1ffe): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/file.o: in function `ceph_write_iter': file.c:(.text+0x33fb): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/file.o: in function
[PATCH] Staging: rtl8192u: ieee80211: fixed a trailing statements coding style issue.
From: Dmitrii Wolf
Signed-off-by: Dmitrii Wolf
---
drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index 690b664df8fa..29a6ce20e2bd 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -2048,12 +2048,12 @@ void ieee80211_softmac_xmit(struct ieee80211_txb *txb,
struct ieee80211_device *
/* if xmit available, just xmit it immediately, else just insert it to
the wait queue */
for (i = 0; i < txb->nr_frags; i++) {
#ifdef USB_TX_DRIVER_AGGREGATION_ENABLE
- if ((skb_queue_len(>skb_drv_aggQ[queue_index]) != 0) ||
+ if ((skb_queue_len(>skb_drv_aggQ[queue_index]) != 0)
#else
- if ((skb_queue_len(>skb_waitQ[queue_index]) != 0) ||
+ if ((skb_queue_len(>skb_waitQ[queue_index]) != 0)
#endif
- (!ieee->check_nic_enough_desc(ieee->dev, queue_index)) || \
- (ieee->queue_stop)) {
+|| (!ieee->check_nic_enough_desc(ieee->dev, queue_index)) \
+|| (ieee->queue_stop)) {
/* insert the skb packet to the wait queue */
/* as for the completion function, it does not need
* to check it any more.
--
2.25.1
Re: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
On 4/3/21 10:46 PM, Madhavan T. Venkataraman wrote: >> I'm somewhat arm-ignorant, so take the following comments with a grain >> of salt. >> >> >> I don't think changing these to 'bl' is necessary, unless you wanted >> __primary_switched() and __secondary_switched() to show up in the >> stacktrace for some reason? If so, that seems like a separate patch. >> > The problem is with __secondary_switched. If you trace the code back to where > a secondary CPU is started, I don't see any calls anywhere. There are only > branches if I am not mistaken. So, the return address register never gets > set up with a proper address. The stack trace shows some hexadecimal value > instead of a symbol name. > Actually, I take that back. There are calls in that code path. But I did only see some hexadecimal value instead of a proper address in the stack trace. Sorry about that confusion. My reason to convert the branches to calls is this - the value of the return address register at that point is the return PC of the previous branch and link instruction wherever that happens to be. I think that is a little arbitrary. Instead, if I call start_kernel() and secondary_start_kernel(), the return address gets set up to the next instruction which, IMHO, is better. But I am open to other suggestions. Madhavan
caps.c:undefined reference to `atomic64_dec_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 4f1d756def68588b88068af1d5a4a3b6dc7e6e2a ceph: add global total_caps to count the mdsc's total caps number date: 8 months ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f1d756def68588b88068af1d5a4a3b6dc7e6e2a git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 4f1d756def68588b88068af1d5a4a3b6dc7e6e2a # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_link_inc': syscall.c:(.text+0x4b0b): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_link_put': syscall.c:(.text+0x4b1d): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_raw_tracepoint_open': syscall.c:(.text+0x4ddf): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_link_get_from_fd': syscall.c:(.text+0x4f53): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_get_curr_or_next': syscall.c:(.text+0x4fad): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x4fe6): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_by_id': syscall.c:(.text+0x5085): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x50b8): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `__do_sys_bpf': syscall.c:(.text+0x56a7): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x56ec): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: syscall.c:(.text+0x5d99): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x5de2): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: syscall.c:(.text+0x5e27): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/bpf_iter.o: in function `prepare_seq_file.isra.0': bpf_iter.c:(.text+0x155): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_set_ino_cb': inode.c:(.text+0x9c): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_alloc_inode': inode.c:(.text+0x143c): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1444): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x144e): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1456): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_fill_inode': inode.c:(.text+0x28f1): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x2914): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: inode.c:(.text+0x352a): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x353d): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3571): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x357e): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3587): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x359c): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_fill_trace': inode.c:(.text+0x397b): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3bc0): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3dde): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3dec): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3e3e): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/inode.o:inode.c:(.text+0x3f1e): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: fs/ceph/inode.o: in function `ceph_readdir_prepopulate': inode.c:(.text+0x48c8): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x48e4): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4b31): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4b72): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_prune': dir.c:(.text+0xb3): undefined reference to `atomic64_inc_386' /usr/bin/ld: dir.c:(.text+0xde): undefined reference to
[PATCH] thermal/drivers/tsens: fix missing put_device error
From: Guangqing Zhu
Fixes coccicheck error:
drivers/thermal/qcom/tsens.c:759:4-10: ERROR: missing put_device; call
of_find_device_by_node on line 715, but without a corresponding object
release within this function.
Fixes: a7ff82976122 ("drivers: thermal: tsens: Merge tsens-common.c into
tsens.c")
Signed-off-by: Guangqing Zhu
---
drivers/thermal/qcom/tsens.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index d8ce3a687b80..cc4c6a9853a4 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -755,9 +755,10 @@ int __init init_common(struct tsens_priv *priv)
for (i = VER_MAJOR; i <= VER_STEP; i++) {
priv->rf[i] = devm_regmap_field_alloc(dev,
priv->srot_map,
priv->fields[i]);
- if (IS_ERR(priv->rf[i]))
- return PTR_ERR(priv->rf[i]);
- }
+ if (IS_ERR(priv->rf[i])) {
+ ret = PTR_ERR(priv->rf[i]);
+ goto err_put_device;
+ }
ret = regmap_field_read(priv->rf[VER_MINOR], _minor);
if (ret)
goto err_put_device;
--
2.17.1
[syzbot] WARNING: suspicious RCU usage in getname_flags
Hello, syzbot found the following issue on: HEAD commit:2bb25b3a Merge tag 'mips-fixes_5.12_3' of git://git.kernel.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1284cc31d0 kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890 dashboard link: https://syzkaller.appspot.com/bug?extid=dde0cc33951735441301 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+dde0cc33951735441...@syzkaller.appspotmail.com WARNING: suspicious RCU usage 5.12.0-rc5-syzkaller #0 Not tainted - kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical section! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 0 no locks held by systemd-udevd/4825. stack backtrace: CPU: 0 PID: 4825 Comm: systemd-udevd Not tainted 5.12.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294 __might_fault+0x6e/0x180 mm/memory.c:5018 strncpy_from_user+0x2f/0x3e0 lib/strncpy_from_user.c:117 getname_flags.part.0+0x95/0x4f0 fs/namei.c:149 getname_flags fs/namei.c:2733 [inline] user_path_at_empty+0xa1/0x100 fs/namei.c:2733 user_path_at include/linux/namei.h:60 [inline] do_faccessat+0x127/0x850 fs/open.c:425 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f840445f9c7 Code: 83 c4 08 48 3d 01 f0 ff ff 73 01 c3 48 8b 0d c8 d4 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 b8 15 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d4 2b 00 f7 d8 64 89 01 48 RSP: 002b:7ffdc40178d8 EFLAGS: 0246 ORIG_RAX: 0015 RAX: ffda RBX: 564d558c9760 RCX: 7f840445f9c7 RDX: 00746e657665752f RSI: RDI: 7ffdc40178e0 RBP: 7ffdc4017960 R08: 4400 R09: 1010 R10: 0020 R11: 0246 R12: 564d557b1856 R13: 564d558ed190 R14: 7ffdc40178e0 R15: 564d558fe590 --- 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.
dir.c:undefined reference to `atomic64_dec_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: f9009efac49c830460f55b9f6c08ee0d76f31b0d ceph: add dentry lease metric support date: 10 months ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9009efac49c830460f55b9f6c08ee0d76f31b0d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout f9009efac49c830460f55b9f6c08ee0d76f31b0d # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: net/netfilter/ipset/ip_set_bitmap_ipmac.o: in function `bitmap_ipmac_add': ip_set_bitmap_ipmac.c:(.text+0x934): undefined reference to `atomic64_set_386' /usr/bin/ld: ip_set_bitmap_ipmac.c:(.text+0x94e): undefined reference to `atomic64_set_386' /usr/bin/ld: net/netfilter/ipset/ip_set_hash_ip.o: in function `hash_ip6_add': ip_set_hash_ip.c:(.text+0x3c32): undefined reference to `atomic64_set_386' /usr/bin/ld: net/netfilter/ipset/ip_set_hash_ip.o:ip_set_hash_ip.c:(.text+0x3c4c): more undefined references to `atomic64_set_386' follow /usr/bin/ld: net/ceph/osd_client.o: in function `__submit_request': osd_client.c:(.text+0x5a7a): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: net/ceph/osd_client.o: in function `handle_timeout': osd_client.c:(.text+0x8fd5): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: net/ceph/osd_client.o: in function `ceph_osdc_sync': osd_client.c:(.text+0xaa92): undefined reference to `atomic64_read_386' /usr/bin/ld: kernel/trace/trace_clock.o: in function `trace_clock_counter': trace_clock.c:(.text+0xcd): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/bpf/core.o: in function `___bpf_prog_run': core.c:(.text+0x1e78): undefined reference to `atomic64_add_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_prog_get': syscall.c:(.text+0x35d): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_map_put.constprop.0': syscall.c:(.text+0x2605): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_put_with_uref': syscall.c:(.text+0x269d): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `map_create': syscall.c:(.text+0x2902): undefined reference to `atomic64_set_386' /usr/bin/ld: syscall.c:(.text+0x2910): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc': syscall.c:(.text+0x2c5a): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc_with_uref': syscall.c:(.text+0x2c70): undefined reference to `atomic64_inc_386' /usr/bin/ld: syscall.c:(.text+0x2c7b): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_get': syscall.c:(.text+0x2cd7): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_get_with_uref': syscall.c:(.text+0x2d4e): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o:syscall.c:(.text+0x2d59): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc_not_zero': syscall.c:(.text+0x2d9b): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x2dd5): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_prog_put.constprop.0': syscall.c:(.text+0x3c58): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_load': syscall.c:(.text+0x3f5d): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_add': syscall.c:(.text+0x4410): undefined reference to `atomic64_add_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_sub': syscall.c:(.text+0x4426): undefined reference to `atomic64_sub_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_inc': syscall.c:(.text+0x445d): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_inc_not_zero': syscall.c:(.text+0x4476): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x44ab): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_link_init': syscall.c:(.text+0x455d): undefined reference to `atomic64_set_386' /usr/bin/ld:
Re: [RFC PATCH v2 1/1] arm64: Implement stack trace termination record
On 4/3/21 10:59 AM, Josh Poimboeuf wrote:
> On Thu, Apr 01, 2021 at 10:24:04PM -0500, madve...@linux.microsoft.com wrote:
>> From: "Madhavan T. Venkataraman"
>> @@ -447,9 +464,9 @@ SYM_FUNC_START_LOCAL(__primary_switched)
>> #endif
>> bl switch_to_vhe // Prefer VHE if possible
>> add sp, sp, #16
>> -mov x29, #0
>> -mov x30, #0
>> -b start_kernel
>> +setup_final_frame
>> +bl start_kernel
>> +nop
>> SYM_FUNC_END(__primary_switched)
>>
>> .pushsection ".rodata", "a"
>> @@ -606,14 +623,14 @@ SYM_FUNC_START_LOCAL(__secondary_switched)
>> cbz x2, __secondary_too_slow
>> msr sp_el0, x2
>> scs_load x2, x3
>> -mov x29, #0
>> -mov x30, #0
>> +setup_final_frame
>>
>> #ifdef CONFIG_ARM64_PTR_AUTH
>> ptrauth_keys_init_cpu x2, x3, x4, x5
>> #endif
>>
>> -b secondary_start_kernel
>> +bl secondary_start_kernel
>> +nop
>> SYM_FUNC_END(__secondary_switched)
>
> I'm somewhat arm-ignorant, so take the following comments with a grain
> of salt.
>
>
> I don't think changing these to 'bl' is necessary, unless you wanted
> __primary_switched() and __secondary_switched() to show up in the
> stacktrace for some reason? If so, that seems like a separate patch.
>
The problem is with __secondary_switched. If you trace the code back to where
a secondary CPU is started, I don't see any calls anywhere. There are only
branches if I am not mistaken. So, the return address register never gets
set up with a proper address. The stack trace shows some hexadecimal value
instead of a symbol name.
On ARM64, the call instruction is actually a branch instruction IIUC. The
only extra thing it does is to load the link register (return address register)
with the return address. That is all.
Instead of the link register pointing to some arbitrary code in startup that
did not call start_kernel() or secondary_start_kernel(), I wanted to set it
up as shown above.
>
> Also, why are nops added after the calls? My guess would be because,
> since these are basically tail calls to "noreturn" functions, the stack
> dump code would otherwise show the wrong function, i.e. whatever
> function happens to be after the 'bl'.
>
That is correct. The stack trace shows something arbitrary.
> We had the same issue for x86. It can be fixed by using '%pB' instead
> of '%pS' when printing the address in dump_backtrace_entry(). See
> sprint_backtrace() for more details.
>
> BTW I think the same issue exists for GCC-generated code. The following
> shows several such cases:
>
> objdump -dr vmlinux |awk '/bl / {bl=1;l=$0;next} bl == 1 && /^$/ {print
> l; print} // {bl=0}'
>
>
> However, looking at how arm64 unwinds through exceptions in kernel
> space, using '%pB' might have side effects when the exception LR
> (elr_el1) points to the beginning of a function. Then '%pB' would show
> the end of the previous function, instead of the function which was
> interrupted.
>
> So you may need to rethink how to unwind through in-kernel exceptions.
>
> Basically, when printing a stack return address, you want to use '%pB'
> for a call return address and '%pS' for an interrupted address.
>
> On x86, with the frame pointer unwinder, we encode the frame pointer by
> setting a bit in %rbp which tells the unwinder that it's a special
> pt_regs frame. Then instead of treating it like a normal call frame,
> the stack dump code prints the registers, and the return address
> (regs->ip) gets printed with '%pS'.
>
Yes. But there are objections to that kind of encoding.
Having the nop above does not do any harm. It just adds 4 bytes to the function
text.
I would rather keep this simple right now because this is only for getting a
sensible
stack trace for idle tasks.
Is there any other problem that you can see?
>> SYM_FUNC_START_LOCAL(__secondary_too_slow)
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 325c83b1a24d..906baa232a89 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -437,6 +437,11 @@ int copy_thread(unsigned long clone_flags, unsigned
>> long stack_start,
>> }
>> p->thread.cpu_context.pc = (unsigned long)ret_from_fork;
>> p->thread.cpu_context.sp = (unsigned long)childregs;
>> +/*
>> + * For the benefit of the unwinder, set up childregs->stackframe
>> + * as the final frame for the new task.
>> + */
>> +p->thread.cpu_context.fp = (unsigned long)childregs->stackframe;
>>
>> ptrace_hw_copy_thread(p);
>>
>> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
>> index ad20981dfda4..72f5af8c69dc 100644
>> --- a/arch/arm64/kernel/stacktrace.c
>> +++ b/arch/arm64/kernel/stacktrace.c
>> @@ -44,16 +44,16 @@ int notrace unwind_frame(struct task_struct *tsk, struct
>> stackframe *frame)
>> unsigned long fp = frame->fp;
>> struct stack_info
Re: [RFC PATCH v1 0/4] arm64: Implement stack trace reliability checks
On 4/3/21 12:01 PM, Josh Poimboeuf wrote: > On Tue, Mar 30, 2021 at 02:09:51PM -0500, madve...@linux.microsoft.com wrote: >> From: "Madhavan T. Venkataraman" >> >> There are a number of places in kernel code where the stack trace is not >> reliable. Enhance the unwinder to check for those cases and mark the >> stack trace as unreliable. Once all of the checks are in place, the unwinder >> can be used for livepatching. > > This assumes all such places are known. That's a big assumption, as > > a) hand-written asm code may inadvertantly skip frame pointer setup; > > b) for inline asm which calls a function, the compiler may blindly >insert it into a function before the frame pointer setup. > > That's where objtool stack validation would come in. > Yes. I meant that the reliable stack trace in the kernel is necessary. I did not imply that it was sufficient. Clearly, it is not sufficient. It relies on the frame pointer being setup correctly for all functions. That has to be guaranteed by another entity such as objtool. So, I will improve the wording and make it clear in the next version. >> Detect EL1 exception frame >> == >> >> EL1 exceptions can happen on any instruction including instructions in >> the frame pointer prolog or epilog. Depending on where exactly they happen, >> they could render the stack trace unreliable. >> >> Add all of the EL1 exception handlers to special_functions[]. >> >> - el1_sync() >> - el1_irq() >> - el1_error() >> - el1_sync_invalid() >> - el1_irq_invalid() >> - el1_fiq_invalid() >> - el1_error_invalid() > > A possibly more robust alternative would be to somehow mark el1 > exception frames so the unwinder can detect them more generally. > > For example, as described in my previous email, encode the frame pointer > so the unwinder can detect el1 frames automatically. > Encoding the frame pointer by setting the LSB (like X86) was my first solution. Mark Rutland NAKed it. His objection was that it would confuse the debuggers which are expecting the last 4 bits of the frame pointer to be 0. I agree with this objection. My problem with the encoding was also that it is not possible to know if the LSB was set because of encoding or because of stack corruption. My second attempt was to encode the frame pointer indirectly. That is, make pt_regs->stackframe the exception frame and use other fields in the pt_regs (including a frame type encoding field) for verification. Mark Rutland NAKed it. His objection (if I am rephrasing it correctly) was that garbage on the stack may accidentally match the values the unwinder checks in the pt_regs (however unlikely that match might be). The consensus was that the return PC must be checked against special functions to recognize those special cases as the special functions are only invoked in those special contexts and nowhere else. As an aside, Mark Brown suggested (if I recall correctly) that the exception functions could be placed in a special exception section so the unwinder can check a return PC against the section bounds instead of individual functions. I did consider implementing this. But I needed a way to address FTRACE trampolines and KPROBE trampolines as well. So, I did not do that. >> Detect ftrace frame >> === >> >> When FTRACE executes at the beginning of a traced function, it creates two >> frames and calls the tracer function: >> >> - One frame for the traced function >> >> - One frame for the caller of the traced function >> >> That gives a sensible stack trace while executing in the tracer function. >> When FTRACE returns to the traced function, the frames are popped and >> everything is back to normal. >> >> However, in cases like live patch, the tracer function redirects execution >> to a different function. When FTRACE returns, control will go to that target >> function. A stack trace taken in the tracer function will not show the target >> function. The target function is the real function that we want to track. >> So, the stack trace is unreliable. > > I don't think this is a real problem. Livepatch only checks the stacks > of blocked tasks (and the task calling into livepatch). So the > reliability of unwinding from the livepatch tracer function itself > (klp_ftrace_handler) isn't a concern since it doesn't sleep. > My thinking was - arch_stack_walk_reliable() should provide a reliable stack trace and not assume anything about its consumers. It should not assume that livepatch is the only consumer although it might be. Theoretically, there can be a tracer function that calls some kernel function F() that can go to sleep. Is this not allowed? Or, F() could call arch_stack_walk_reliable() on the current task for debugging or tracing purposes. It should still work correctly. >> To detect FTRACE in a stack trace, add the following to special_functions[]: >> >> - ftrace_graph_call() >> -
/usr/bin/ld: file.c:undefined reference to `atomic64_inc_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 9a8d03ca2e2c334d08ee91a3e07dcce31a02fdc6 ceph: attempt to do async create when possible date: 1 year ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a8d03ca2e2c334d08ee91a3e07dcce31a02fdc6 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 9a8d03ca2e2c334d08ee91a3e07dcce31a02fdc6 # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): syscall.c:(.text+0x18d): undefined reference to `atomic64_inc_386' /usr/bin/ld: syscall.c:(.text+0x198): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_mmap_open': syscall.c:(.text+0x200): undefined reference to `atomic64_inc_386' /usr/bin/ld: syscall.c:(.text+0x20b): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_prog_get': syscall.c:(.text+0x2ca): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_map_put.constprop.0': syscall.c:(.text+0x252a): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_put_with_uref': syscall.c:(.text+0x25bb): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `map_create': syscall.c:(.text+0x2878): undefined reference to `atomic64_set_386' /usr/bin/ld: syscall.c:(.text+0x2886): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc': syscall.c:(.text+0x2bd0): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc_with_uref': syscall.c:(.text+0x2be6): undefined reference to `atomic64_inc_386' /usr/bin/ld: syscall.c:(.text+0x2bf1): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_get_with_uref': syscall.c:(.text+0x2c4d): undefined reference to `atomic64_inc_386' /usr/bin/ld: syscall.c:(.text+0x2c58): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_map_inc_not_zero': syscall.c:(.text+0x2c9a): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x2cd4): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `__bpf_prog_put.constprop.0': syscall.c:(.text+0x3b2c): undefined reference to `atomic64_dec_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_load': syscall.c:(.text+0x3f37): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_add': syscall.c:(.text+0x43d4): undefined reference to `atomic64_add_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_sub': syscall.c:(.text+0x43ea): undefined reference to `atomic64_sub_return_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_inc': syscall.c:(.text+0x4421): undefined reference to `atomic64_inc_386' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_inc_not_zero': syscall.c:(.text+0x443a): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x446f): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `bpf_prog_by_id': syscall.c:(.text+0x4554): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x4587): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: kernel/bpf/syscall.o: in function `__do_sys_bpf': syscall.c:(.text+0x4c7c): undefined reference to `atomic64_read_386' /usr/bin/ld: syscall.c:(.text+0x4cc3): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: syscall.c:(.text+0x4d08): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_set_ino_cb': inode.c:(.text+0x9c): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_alloc_inode': inode.c:(.text+0x116f): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1177): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1181): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1189): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_fill_inode': inode.c:(.text+0x25ff): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x2622): undefined reference to `cmpxchg8b_emu'
Re: [syzbot] WARNING in mntput_no_expire (2)
On Sun, Apr 04, 2021 at 02:34:08AM +, Al Viro wrote: > I really wonder what mount is it happening to. BTW, how painful would > it be to teach syzcaller to turn those cascades of > NONFAILING(*(uint8_t*)0x2080 = 0x12); > NONFAILING(*(uint8_t*)0x2081 = 0); > NONFAILING(*(uint16_t*)0x2082 = 0); > NONFAILING(*(uint32_t*)0x2084 = 0xff9c); > NONFAILING(*(uint64_t*)0x2088 = 0); > NONFAILING(*(uint64_t*)0x2090 = 0x2180); > NONFAILING(memcpy((void*)0x2180, "./file0\000", 8)); > NONFAILING(*(uint32_t*)0x2098 = 0); > NONFAILING(*(uint32_t*)0x209c = 0x80); > NONFAILING(*(uint64_t*)0x20a0 = 0x23456); > > NONFAILING(syz_io_uring_submit(r[1], r[2], 0x2080, 0)); > into something more readable? Bloody annoyance every time... Sure, I can > manually translate it into > struct io_uring_sqe *sqe = (void *)0x2080; > char *s = (void *)0x2180; > memset(sqe, '\0', sizeof(*sqe)); > sqe->opcode = 0x12; // IORING_OP_OPENAT? > sqe->fd = -100; // AT_FDCWD? > sqe->addr = s; > strcpy(s, "./file0"); > sqe->open_flags = 0x80; // O_EXCL??? > sqe->user_data = 0x23456; // random tag? > syz_io_uring_submit(r[1], r[2], (unsigned long)p, 0); > but it's really annoying as hell, especially since syz_io_uring_submit() > comes from syzcaller and the damn thing _knows_ that the third argument > is sodding io_uring_sqe, and never passed to anything other than > memcpy() in there, at that, so the exact address can't matter. ... especially since the native syzcaller reproducer clearly *does* have that information. Simply putting that into comments side-by-side with what gets put into C reproducer would be nice, especially if it goes with field names...
[syzbot] WARNING: suspicious RCU usage in clear_huge_page
Hello,
syzbot found the following issue on:
HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1611e681d0
kernel config: https://syzkaller.appspot.com/x/.config?x=78ef1d159159890
dashboard link: https://syzkaller.appspot.com/bug?extid=7a0c25f9520c969c15f5
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7a0c25f9520c969c1...@syzkaller.appspotmail.com
=
WARNING: suspicious RCU usage
5.12.0-rc5-syzkaller #0 Not tainted
-
kernel/sched/core.c:8294 Illegal context switch in RCU-bh read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
1 lock held by syz-executor.2/10002:
#0: 8880129669d8 (>mmap_lock#2){}-{3:3}, at: mmap_read_trylock
include/linux/mmap_lock.h:136 [inline]
#0: 8880129669d8 (>mmap_lock#2){}-{3:3}, at:
do_user_addr_fault+0x285/0x1210 arch/x86/mm/fault.c:1331
stack backtrace:
CPU: 0 PID: 10002 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
process_huge_page mm/memory.c:5051 [inline]
clear_huge_page+0x9c/0x560 mm/memory.c:5112
__do_huge_pmd_anonymous_page mm/huge_memory.c:607 [inline]
do_huge_pmd_anonymous_page+0x60e/0x2570 mm/huge_memory.c:772
create_huge_pmd mm/memory.c:4189 [inline]
__handle_mm_fault+0x2e59/0x4f70 mm/memory.c:4424
handle_mm_fault+0x1bc/0x7e0 mm/memory.c:4551
do_user_addr_fault+0x483/0x1210 arch/x86/mm/fault.c:1390
handle_page_fault arch/x86/mm/fault.c:1475 [inline]
exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1531
asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:577
RIP: 0033:0x461b6d
Code: 48 01 d0 eb 0b 0f 1f 84 00 00 00 00 00 48 89 f8 48 83 fa 20 72 49 48 83
fa 40 0f 87 9f 00 00 00 c5 fe 6f 06 c5 fe 6f 4c 16 e0 fe 7f 07 c5 fe 7f 4c
17 e0 c5 f8 77 c3 48 3b 15 7e 8e 04 01 0f
RSP: 002b:7fffc28c60c8 EFLAGS: 00010287
RAX: 2080 RBX: 0003 RCX: 0057
RDX: 002b RSI: 00570020 RDI: 2080
RBP: 7fffc28c6188 R08: 0097 R09: 7fffc2907090
R10: a8e8 R11: R12: 0001
R13: R14: 0056bf60 R15: 00035790
---
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.
Re: [syzbot] WARNING in mntput_no_expire (2)
On Thu, Apr 01, 2021 at 07:11:12PM +, Al Viro wrote:
> > I _think_ I see what the issue is. It seems that an assumption made in
> > this commit might be wrong and we're missing a mnt_add_count() bump that
> > we would otherwise have gotten if we've moved the failure handling into
> > the unlazy helpers themselves.
> >
> > Al, does that sound plausible?
>
> mnt_add_count() on _what_? Failure in legitimize_links() ends up with
> nd->path.mnt zeroed, in both callers. So which vfsmount would be
> affected?
Could you turn that WARN_ON(count < 0) into
if (WARN_ON(count < 0))
printk(KERN_ERR "id = %d, dev = %s, count = %d\n",
mnt->mnt_id,
mnt->mnt_sb->s_id,
count);
add system("cat /proc/self/mountinfo"); right after sandbox_common()
call and try to reproduce that?
I really wonder what mount is it happening to. BTW, how painful would
it be to teach syzcaller to turn those cascades of
NONFAILING(*(uint8_t*)0x2080 = 0x12);
NONFAILING(*(uint8_t*)0x2081 = 0);
NONFAILING(*(uint16_t*)0x2082 = 0);
NONFAILING(*(uint32_t*)0x2084 = 0xff9c);
NONFAILING(*(uint64_t*)0x2088 = 0);
NONFAILING(*(uint64_t*)0x2090 = 0x2180);
NONFAILING(memcpy((void*)0x2180, "./file0\000", 8));
NONFAILING(*(uint32_t*)0x2098 = 0);
NONFAILING(*(uint32_t*)0x209c = 0x80);
NONFAILING(*(uint64_t*)0x20a0 = 0x23456);
NONFAILING(syz_io_uring_submit(r[1], r[2], 0x2080, 0));
into something more readable? Bloody annoyance every time... Sure, I can
manually translate it into
struct io_uring_sqe *sqe = (void *)0x2080;
char *s = (void *)0x2180;
memset(sqe, '\0', sizeof(*sqe));
sqe->opcode = 0x12; // IORING_OP_OPENAT?
sqe->fd = -100; // AT_FDCWD?
sqe->addr = s;
strcpy(s, "./file0");
sqe->open_flags = 0x80; // O_EXCL???
sqe->user_data = 0x23456; // random tag?
syz_io_uring_submit(r[1], r[2], (unsigned long)p, 0);
but it's really annoying as hell, especially since syz_io_uring_submit()
comes from syzcaller and the damn thing _knows_ that the third argument
is sodding io_uring_sqe, and never passed to anything other than
memcpy() in there, at that, so the exact address can't matter.
Incidentally, solitary O_EXCL (without O_CREAT) is... curious. Does that
sucker still trigger without it? I.e. with store to 0x209c replaced
with storing 0?
Re: [PATCH net-next v1 1/9] net: dsa: add rcv_post call back
On 4/3/2021 16:21, Vladimir Oltean wrote: On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote: On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote: Some switches (for example ar9331) do not provide enough information about forwarded packets. If the switch decision was made based on IPv4 or IPv6 header, we need to analyze it and set proper flag. Potentially we can do it in existing rcv path, on other hand we can avoid part of duplicated work and let the dsa framework set skb header pointers and then use preprocessed skb one step later withing the rcv_post call back. This patch is needed for ar9331 switch. Signed-off-by: Oleksij Rempel --- I don't necessarily disagree with this, perhaps we can even move Florian's dsa_untag_bridge_pvid() call inside a rcv_post() method implemented by the DSA_TAG_PROTO_BRCM_LEGACY, DSA_TAG_PROTO_BRCM_PREPEND and DSA_TAG_PROTO_BRCM taggers. Or even better, because Oleksij's rcv_post is already prototype-compatible with dsa_untag_bridge_pvid, we can already do: .rcv_post = dsa_untag_bridge_pvid, This should be generally useful for stuff that DSA taggers need to do which is easiest done after eth_type_trans() was called. I had some fun with an alternative method of parsing the frame for IGMP so that you can clear skb->offload_fwd_mark, which doesn't rely on the introduction of a new method in DSA. It should also have several other advantages compared to your solution such as the fact that it should work with VLAN-tagged packets. Background: we made Receive Packet Steering work on DSA master interfaces (echo 3 > /sys/class/net/eth0/queues/rx-1/rps_cpus) even when the DSA tag shifts to the right the IP headers and everything that comes afterwards. The flow dissector had to be patched for that, just grep for DSA in net/core/flow_dissector.c. The problem you're facing is that you can't parse the IP and IGMP headers in the tagger's rcv() method, since the network header, transport header offsets and skb->protocol are all messed up, since eth_type_trans hasn't been called yet. And that's the trick right there, you're between a rock and a hard place: too early because eth_type_trans wasn't called yet, and too late because skb->dev was changed and no longer points to the DSA master, so the flow dissector adjustment we made doesn't apply. But if you call the flow dissector _before_ you call "skb->dev = dsa_master_find_slave" (and yes, while the DSA tag is still there), then it's virtually as if you had called that while the skb belonged to the DSA master, so it should work with __skb_flow_dissect. In fact I prototyped this idea below. I wanted to check whether I can match something as fine-grained as an IGMPv2 Membership Report message, and I could. I prototyped it inside the ocelot tagging protocol driver because that's what I had handy. I used __skb_flow_dissect with my own flow dissector which had to be initialized at the tagger module_init time, even though I think I could have probably just called skb_flow_dissect_flow_keys with a standard dissector, and that would have removed the need for the custom module_init in tag_ocelot.c. One thing that is interesting is that I had to add the bits for IGMP parsing to the flow dissector myself (based on the existing ICMP code). I was too lazy to do that for MLD as well, but it is really not hard. Or even better, if you don't need to look at all inside the IGMP/MLD header, I think you can even omit adding this parsing code to the flow dissector and just look at basic.n_proto and basic.ip_proto. See the snippet below. Hope it helps. This looks a lot better than introducing hooks at various points in dsa_switch_rcv(). -- Florian
Re: [PATCH v3] cpu/hotplug: wait for cpuset_hotplug_work to finish on cpu onlining
On Sat, Mar 27, 2021 at 9:01 PM Thomas Gleixner wrote:
Lovely that you eventually found time to take a look at this since
first RFC patch was sent.
> Alexey,
>
> On Wed, Mar 17 2021 at 00:36, Alexey Klimov wrote:
> > When a CPU offlined and onlined via device_offline() and device_online()
> > the userspace gets uevent notification. If, after receiving "online" uevent,
> > userspace executes sched_setaffinity() on some task trying to move it
> > to a recently onlined CPU, then it sometimes fails with -EINVAL. Userspace
> > needs to wait around 5..30 ms before sched_setaffinity() will succeed for
> > recently onlined CPU after receiving uevent.
> >
> > Cpusets used in guarantee_online_cpus() are updated using workqueue from
> > cpuset_update_active_cpus() which in its turn is called from cpu hotplug
> > callback
> > sched_cpu_activate() hence it may not be observable by sched_setaffinity()
> > if
> > it is called immediately after uevent.
>
> And because cpusets are using a workqueue just to deal with their
> backwards lock order we need to cure the symptom in the CPU hotplug
> code, right?
Feel free to suggest a better place.
> > Out of line uevent can be avoided if we will ensure that cpuset_hotplug_work
> > has run to completion using cpuset_wait_for_hotplug() after onlining the
> > cpu in cpu_device_up() and in cpuhp_smt_enable().
>
> It can also be avoided by fixing the root cause which is _NOT_ in the
> CPU hotplug code at all.
>
> The fundamental assumption of CPU hotplug is that if the state machine
> reaches a given state, which might have user space visible effects or
> even just kernel visible effects, the overall state of the system has to
> be consistent.
>
> cpusets violate this assumption. And they do so since 2013 due to commit
> 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()").
>
> If that cannot be fixed in cgroups/cpusets with out rewriting the whole
> cpusets/cgroups muck, then this want's to be explained and justified in the
> changelog.
>
> Looking at the changelog of 3a5a6d0c2b03 it's entirely clear that this
> is non trivial because that changelog clearly states that the lock order
> is a design decision and that design decision required that workqueue
> workaround
>
> See? Now we suddenly have a proper root cause and not just a description
> of the symptom with some hidden hint about workqueues. And we have an
> argument why fixing the root cause is close to impossible.
Thank you for this educational scolding here and below. I see that
problem here is more fundamental than I thought before and my commit
messages standards are too low for you.
Good to see that bug that may exist since 2013 could be fixed finally.
> > int cpu_device_up(struct device *dev)
> > {
> > - return cpu_up(dev->id, CPUHP_ONLINE);
> > + int err;
> > +
> > + err = cpu_up(dev->id, CPUHP_ONLINE);
> > + /*
> > + * Wait for cpuset updates to cpumasks to finish. Later on this path
> > + * may generate uevents whose consumers rely on the updates.
> > + */
> > + if (!err)
> > + cpuset_wait_for_hotplug();
>
> No. Quite some people wasted^Wspent a considerable amount of time to get
> the hotplug trainwreck cleaned up and we are not sprinkling random
> workarounds all over the place again.
>
> > int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
> > {
> > - int cpu, ret = 0;
> > + cpumask_var_t mask;
> > + int cpu, ret;
> >
> > + if (!zalloc_cpumask_var(, GFP_KERNEL))
> > + return -ENOMEM;
> > +
> > + ret = 0;
> > cpu_maps_update_begin();
> > for_each_online_cpu(cpu) {
> > if (topology_is_primary_thread(cpu))
> > @@ -2093,31 +2109,42 @@ int cpuhp_smt_disable(enum cpuhp_smt_control
> > ctrlval)
> > ret = cpu_down_maps_locked(cpu, CPUHP_OFFLINE);
> > if (ret)
> > break;
> > - /*
> > - * As this needs to hold the cpu maps lock it's impossible
> > - * to call device_offline() because that ends up calling
> > - * cpu_down() which takes cpu maps lock. cpu maps lock
> > - * needs to be held as this might race against in kernel
> > - * abusers of the hotplug machinery (thermal management).
> > - *
> > - * So nothing would update device:offline state. That would
> > - * leave the sysfs entry stale and prevent onlining after
> > - * smt control has been changed to 'off' again. This is
> > - * called under the sysfs hotplug lock, so it is properly
> > - * serialized against the regular offline usage.
> > - */
> > - cpuhp_offline_cpu_device(cpu);
> > +
> > + cpumask_set_cpu(cpu, mask);
> > }
> > if (!ret)
> > cpu_smt_control = ctrlval;
> > cpu_maps_update_done();
> > +
> > + /*
> > + * When the cpu maps lock
Re: [PATCH net-next v1 7/9] net: dsa: qca: ar9331: add bridge support
On 4/3/2021 04:48, Oleksij Rempel wrote:
This switch is providing forwarding matrix, with it we can configure
individual bridges. Potentially we can configure more then one not VLAN
s/then/than/
based bridge on this HW.
Signed-off-by: Oleksij Rempel
---
drivers/net/dsa/qca/ar9331.c | 73
1 file changed, 73 insertions(+)
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index b2c22ba924f0..bf9588574205 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -40,6 +40,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1134,6 +1135,76 @@ static int ar9331_sw_set_ageing_time(struct dsa_switch
*ds,
val);
}
+static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
+ struct net_device *br)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int port_mask = BIT(priv->cpu_port);
+ int i, ret;
+ u32 val;
+
+ for (i = 0; i < ds->num_ports; i++) {
+ if (dsa_to_port(ds, i)->bridge_dev != br)
+ continue;
+
+ if (!dsa_is_user_port(ds, port))
+ continue;
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER,
BIT(port));
+ ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
+ if (ret)
+ goto error;
+
+ if (i != port)
+ port_mask |= BIT(i);
+ }
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask);
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
This is not called more than once per port and per bridge join operation
so I would drop the rate limiting here. With that fixed:
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH net-next v1 6/9] net: dsa: qca: ar9331: add ageing time support
On 4/3/2021 04:48, Oleksij Rempel wrote: This switch provides global ageing time configuration, so let DSA use it. Signed-off-by: Oleksij Rempel Reviewed-by: Florian Fainelli -- Florian
vdpa.c:undefined reference to `atomic64_sub_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 4c8cf31885f69e86be0b5b9e6677a26797365e1d vhost: introduce vDPA-based backend date: 1 year ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c8cf31885f69e86be0b5b9e6677a26797365e1d git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 4c8cf31885f69e86be0b5b9e6677a26797365e1d # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: kernel/fork.o: in function `mm_init.isra.0': fork.c:(.text+0x3c5): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/futex.o: in function `get_futex_key': futex.c:(.text+0xcfe): undefined reference to `atomic64_read_386' /usr/bin/ld: futex.c:(.text+0xd68): undefined reference to `atomic64_add_return_386' /usr/bin/ld: futex.c:(.text+0xd7b): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: mm/debug.o: in function `dump_mm': debug.c:(.text+0x2ca): undefined reference to `atomic64_read_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_zpool_total_size': z3fold.c:(.text+0x8a): undefined reference to `atomic64_read_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_zpool_create': z3fold.c:(.text+0x3f9): undefined reference to `atomic64_set_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_page_putback': z3fold.c:(.text+0x93f): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_alloc': z3fold.c:(.text+0xcf9): undefined reference to `atomic64_inc_386' /usr/bin/ld: z3fold.c:(.text+0x10e8): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_reclaim_page.constprop.0': z3fold.c:(.text+0x1403): undefined reference to `atomic64_dec_386' /usr/bin/ld: z3fold.c:(.text+0x18dd): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `do_compact_page': z3fold.c:(.text+0x1f41): undefined reference to `atomic64_dec_386' /usr/bin/ld: z3fold.c:(.text+0x2390): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o:z3fold.c:(.text+0x25f7): more undefined references to `atomic64_dec_386' follow /usr/bin/ld: fs/inode.o: in function `inode_init_always': inode.c:(.text+0x310): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/inode.o: in function `generic_update_time': inode.c:(.text+0x1d34): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x1d72): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/inode.o: in function `file_update_time': inode.c:(.text+0x24e6): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/namespace.o: in function `alloc_mnt_ns': namespace.c:(.text+0x222): undefined reference to `atomic64_add_return_386' /usr/bin/ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_iotlb_unmap': >> vdpa.c:(.text+0x19f): undefined reference to `atomic64_sub_386' /usr/bin/ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_process_iotlb_msg': vdpa.c:(.text+0x515): undefined reference to `atomic64_add_return_386' /usr/bin/ld: vdpa.c:(.text+0x6c2): undefined reference to `atomic64_sub_386' /usr/bin/ld: net/core/sock_diag.o: in function `sock_gen_cookie': sock_diag.c:(.text+0x30c): undefined reference to `atomic64_read_386' /usr/bin/ld: sock_diag.c:(.text+0x31e): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: sock_diag.c:(.text+0x337): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: sock_diag.c:(.text+0x33e): undefined reference to `atomic64_read_386' /usr/bin/ld: net/core/sock_diag.o: in function `sock_diag_check_cookie': sock_diag.c:(.text+0x36e): undefined reference to `atomic64_read_386' /usr/bin/ld: sock_diag.c:(.text+0x382): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: sock_diag.c:(.text+0x399): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: sock_diag.c:(.text+0x3a0): undefined reference to `atomic64_read_386' /usr/bin/ld: net/core/sock_diag.o: in function `sock_diag_save_cookie': sock_diag.c:(.text+0x3e6): undefined reference to `atomic64_read_386' /usr/bin/ld: sock_diag.c:(.text+0x3f8): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: sock_diag.c:(.text+0x40f): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: sock_diag.c:(.text+0x416): undefined reference to `atomic64_read_386' /usr/bin/ld: net/sched/sch_cbs.o: in function `cbs_set_port_rate': sch_cbs.c:(.text+0x1d6): undefined reference to `atomic64_set_386'
Re: [PATCH net-next v1 3/9] net: dsa: qca: ar9331: reorder MDIO write sequence
On 4/3/2021 04:48, Oleksij Rempel wrote: In case of this switch we work with 32bit registers on top of 16bit bus. Some registers (for example access to forwarding database) have trigger bit on the first 16bit half of request and the result + configuration of request in the second half. Without this this patch, we would trigger database operation and overwrite result in one run. To make it work properly, we should do the second part of transfer before the first one is done. So far, this rule seems to work for all registers on this switch. Signed-off-by: Oleksij Rempel Seems like you could send this as a separate bugfix for the "net" tree along with a Fixes tag? -- Florian
[PATCH] MIPS: ralink: rt288x: select MIPS_AUTO_PFN_OFFSET
RT288X systems may have a non-zero ramstart causing problems with memory reservations and boot hangs, as well as messages like: Wasting 1048576 bytes for tracking 32768 unused pages Both are alleviated by selecting MIPS_AUTO_PFN_OFFSET for such platforms. Tested on a Belkin F5D8235 v1 RT2880 device. Link: https://lore.kernel.org/linux-mips/20180820233111.xww5232dxbuouf4n@pburton-laptop/ Signed-off-by: Ilya Lipnitskiy Cc: Mike Rapoport --- arch/mips/ralink/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/mips/ralink/Kconfig b/arch/mips/ralink/Kconfig index c20c44788b62..7c6de7f8484e 100644 --- a/arch/mips/ralink/Kconfig +++ b/arch/mips/ralink/Kconfig @@ -31,6 +31,7 @@ choice config SOC_RT288X bool "RT288x" + select MIPS_AUTO_PFN_OFFSET select MIPS_L1_CACHE_SHIFT_4 select HAVE_LEGACY_CLK select HAVE_PCI -- 2.31.1
Re: [PATCH] MIPS: fix memory reservation for non-usermem setups
Hi Mike,
On Tue, Mar 16, 2021 at 11:33 PM Mike Rapoport wrote:
>
> Hi Ilya,
>
> On Tue, Mar 16, 2021 at 10:10:09PM -0700, Ilya Lipnitskiy wrote:
> > Hi Thomas,
> >
> > On Fri, Mar 12, 2021 at 7:19 AM Thomas Bogendoerfer
> > wrote:
> > >
> > > On Sun, Mar 07, 2021 at 11:40:30AM -0800, Ilya Lipnitskiy wrote:
> > > > From: Tobias Wolf
> > > >
> > > > Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced
> > > > a new
> > > > issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated
> > > > "ramstart" is
> > > > not. As the prerequisite of custom memory map has been removed, this
> > > > results
> > > > in the full memory range of 0x0 - 0x800 to be marked as reserved
> > > > for this
> > > > platform.
> > >
> > > and where is the problem here ?
> > Turns out this was already attempted to be upstreamed - not clear why
> > it wasn't merged. Context:
> > https://lore.kernel.org/linux-mips/6504517.U6H5IhoIOn@loki/
> >
> > I hope the thread above helps you understand the problem.
>
> The memory initialization was a bit different then. Do you still see the
> same problem?
Thanks for asking. I obtained a RT2880 device and gave it a try. It
hangs at boot without this patch, however selecting
MIPS_AUTO_PFN_OFFSET fixes it. Also, no more messages like "Wasting
1048576 bytes for tracking 32768 unused pages". MIPS_AUTO_PFN_OFFSET
was suggested by Paul Burton here:
https://lore.kernel.org/linux-mips/20180820233111.xww5232dxbuouf4n@pburton-laptop/
I will supersede this patch with one that simply selects
MIPS_AUTO_PFN_OFFSET for this SOC.
Ilya
nf_conntrack_core.c:undefined reference to `atomic64_add_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 9312eabab4a68348af5b4482cc7cc6f151ff1c3f netfilter: conntrack: add nf_ct_acct_add() date: 1 year ago config: um-randconfig-r016-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9312eabab4a68348af5b4482cc7cc6f151ff1c3f git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 9312eabab4a68348af5b4482cc7cc6f151ff1c3f # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: inode.c:(.text+0x115c): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x1164): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `fill_inode': inode.c:(.text+0x257f): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x25a2): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: inode.c:(.text+0x31b0): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x31c3): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x31f2): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3200): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x3209): undefined reference to `atomic64_set_386' /usr/bin/ld: inode.c:(.text+0x321e): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/inode.o: in function `ceph_fill_trace': inode.c:(.text+0x35ed): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3832): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3a45): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3a53): undefined reference to `atomic64_inc_386' /usr/bin/ld: inode.c:(.text+0x3aa5): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/inode.o:inode.c:(.text+0x3b85): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: fs/ceph/inode.o: in function `ceph_readdir_prepopulate': inode.c:(.text+0x4529): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4545): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x4793): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x47d4): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_prune': dir.c:(.text+0xb3): undefined reference to `atomic64_inc_386' /usr/bin/ld: dir.c:(.text+0xde): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `__dcache_find_get_entry': dir.c:(.text+0x4c9): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x4d8): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x51c): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x52b): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_lookup': dir.c:(.text+0x17fd): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o:dir.c:(.text+0x180d): more undefined references to `atomic64_read_386' follow /usr/bin/ld: fs/ceph/dir.o: in function `ceph_d_revalidate': dir.c:(.text+0x261e): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/dir.o: in function `ceph_readdir': dir.c:(.text+0x306a): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x3079): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x308f): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x309e): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x3b23): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ceph/dir.o:dir.c:(.text+0x3ba3): more undefined references to `atomic64_read_386' follow /usr/bin/ld: fs/ceph/dir.o: in function `ceph_readdir': dir.c:(.text+0x3bd9): undefined reference to `atomic64_set_386' /usr/bin/ld: dir.c:(.text+0x3bec): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ceph/file.o: in function `ceph_write_iter': file.c:(.text+0x2cd0): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/file.o: in function `__ceph_copy_file_range': file.c:(.text+0x44b0): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/addr.o: in function `ceph_page_mkwrite': addr.c:(.text+0x61de): undefined reference to `atomic64_inc_386' /usr/bin/ld: fs/ceph/caps.o: in function `__send_cap': caps.c:(.text+0x1965): undefined reference to
Hi,
Hello dear how are you today? I hope you did receive the message I sent to you Last time?. I am waiting. Привет дорогая, как ты сегодня? Надеюсь, вы получили сообщение, которое я отправил вам в прошлый раз? Я ожидаю.
Re: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support
> > Plus, i'm not actually sure we should be issuing warnings here. What
> > does the bridge code do in this case? Is it silent and just does it,
> > or does it issue a warning?
>
> :D
>
> What Oleksij doesn't know, I bet, is that he's using the bridge bypass
> commands:
>
> bridge fdb add dev lan0 00:01:02:03:04:05
>
> That is the deprecated way of managing FDB entries, and has several
> disadvantages such as:
> - the bridge software FDB never gets updated with this entry, so other
> drivers which might be subscribed to DSA's FDB (imagine a non-DSA
> driver having the same logic as our ds->assisted_learning_on_cpu_port)
> will never see these FDB entries
> - you have to manage duplicates yourself
I was actually meaning a pure software bridge, with unaccelerated
interfaces. It has a dynamic MAC address in its tables, and the user
adds a static. Ideally, we want the same behaviour.
And i think the answer is:
static int fdb_insert(struct net_bridge *br, struct net_bridge_port *source,
const unsigned char *addr, u16 vid)
{
struct net_bridge_fdb_entry *fdb;
if (!is_valid_ether_addr(addr))
return -EINVAL;
fdb = br_fdb_find(br, addr, vid);
if (fdb) {
/* it is okay to have multiple ports with same
* address, just use the first one.
*/
if (test_bit(BR_FDB_LOCAL, >flags))
return 0;
br_warn(br, "adding interface %s with same address as a
received packet (addr:%pM, vlan:%u)\n",
source ? source->dev->name : br->dev->name, addr, vid);
fdb_delete(br, fdb, true);
}
fdb = fdb_create(br, source, addr, vid,
BIT(BR_FDB_LOCAL) | BIT(BR_FDB_STATIC));
if (!fdb)
return -ENOMEM;
fdb_add_hw_addr(br, addr);
fdb_notify(br, fdb, RTM_NEWNEIGH, true);
return 0;
}
So it looks like it warns and then replaces the dynamic entry.
So having the DSA driver also warn is maybe O.K. Having said that, i
don't think any other DSA driver does.
Andrew
[PATCH] debugfs: Fix use-after-free in debugfs_create_devm_seqfile()
This function uses devres to clean up its allocation, but it never removes the
file referencing that allocation. This causes a use-after-free and an oops if
the file is accessed after the owning device is removed.
Fixes: 98210b7f73f1d ("debugfs: add helper function to create device related
seq_file")
Fixes: 0d519cbf38eed ("debugfs: remove return value of
debugfs_create_devm_seqfile()")
Signed-off-by: Samuel Holland
---
fs/debugfs/file.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 686e0ad28788..64f1f918e119 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -1100,6 +1100,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_regset32);
struct debugfs_devm_entry {
int (*read)(struct seq_file *seq, void *data);
struct device *dev;
+ struct dentry *dentry;
};
static int debugfs_devm_entry_open(struct inode *inode, struct file *f)
@@ -1117,6 +1118,13 @@ static const struct file_operations
debugfs_devm_entry_ops = {
.llseek = seq_lseek
};
+static void debugfs_devm_entry_release(struct device *dev, void *res)
+{
+ struct debugfs_devm_entry *entry = res;
+
+ debugfs_remove(entry->dentry);
+}
+
/**
* debugfs_create_devm_seqfile - create a debugfs file that is bound to device.
*
@@ -1136,14 +1144,19 @@ void debugfs_create_devm_seqfile(struct device *dev,
const char *name,
if (IS_ERR(parent))
return;
- entry = devm_kzalloc(dev, sizeof(*entry), GFP_KERNEL);
+ entry = devres_alloc(debugfs_devm_entry_release, sizeof(*entry),
GFP_KERNEL);
if (!entry)
return;
entry->read = read_fn;
entry->dev = dev;
+ entry->dentry = debugfs_create_file(name, S_IRUGO, parent, entry,
+ _devm_entry_ops);
+ if (IS_ERR(entry->dentry)) {
+ devres_free(entry);
+ return;
+ }
- debugfs_create_file(name, S_IRUGO, parent, entry,
- _devm_entry_ops);
+ devres_add(dev, entry);
}
EXPORT_SYMBOL_GPL(debugfs_create_devm_seqfile);
--
2.26.2
Re: [PATCH net-next v1 9/9] net: dsa: qca: ar9331: add vlan support
On Sat, Apr 03, 2021 at 01:48:48PM +0200, Oleksij Rempel wrote:
> This switch provides simple VLAN resolution database for 16 entries (VLANs).
> With this database we can cover typical functionalities as port based
> VLANs, untagged and tagged egress. Port based ingress filtering.
>
> The VLAN database is working on top of forwarding database. So,
Define 'on top'.
> potentially, we can have multiple VLANs on top of multiple bridges.
> Hawing one VLAN on top of multiple bridges will fail on different
s/Hawing/Having/
> levels, most probably DSA framework should warn if some one wont to make
s/wont/wants/
s/some one/someone/
> something likes this.
Finally, why should the DSA framework warn?
Even in the default configuration of two bridges, the default_pvid (1)
will be the same. What problems do you have with that?
In commit 0ee2af4ebbe3 ("net: dsa: set configure_vlan_while_not_filtering
to true by default"), I did not notice that ar9331 does not have VLAN
operations, and I mistakenly set ds->configure_vlan_while_not_filtering
= false for your driver. Could you please delete that line and ensure the
following works?
ip link add br0 type bridge
ip link set lan0 master br0
bridge vlan add dev lan0 vid 100
ip link set br0 type bridge vlan_filtering 1
# make sure you can receive traffic with VLAN 100
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/dsa/qca/ar9331.c | 255 +++
> 1 file changed, 255 insertions(+)
>
> +static int ar9331_sw_vt_wait(struct ar9331_sw_priv *priv, u32 *f0)
> +{
> + struct regmap *regmap = priv->regmap;
> +
> + return regmap_read_poll_timeout(regmap,
> + AR9331_SW_REG_VLAN_TABLE_FUNCTION0,
> + *f0, !(*f0 & AR9331_SW_VT0_BUSY),
> + 100, 2000);
> +}
> +
> +static int ar9331_sw_port_vt_rmw(struct ar9331_sw_priv *priv, u16 vid,
> + u8 port_mask_set, u8 port_mask_clr)
> +{
> + struct regmap *regmap = priv->regmap;
> + u32 f0, f1, port_mask = 0, port_mask_new, func;
> + struct ar9331_sw_vlan_db *vdb = NULL;
> + int ret, i;
> +
> + if (!vid)
> + return 0;
> +
> + ret = ar9331_sw_vt_wait(priv, );
> + if (ret)
> + return ret;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION0, 0);
> + if (ret)
> + goto error;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, 0);
> + if (ret)
> + goto error;
> +
> + for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
> + if (priv->vdb[i].vid == vid) {
> + vdb = >vdb[i];
> + break;
> + }
> + }
> +
> + ret = regmap_read(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, );
> + if (ret)
> + return ret;
> +
> + if (vdb) {
> + port_mask = vdb->port_mask;
> + }
> +
> + port_mask_new = port_mask & ~port_mask_clr;
> + port_mask_new |= port_mask_set;
> +
> + if (port_mask_new && port_mask_new == port_mask) {
> + dev_info(priv->dev, "%s: no need to overwrite existing valid
> entry on %x\n",
> + __func__, port_mask_new);
With VLANs, the bridge is indeed much less strict compared to FDBs, due
to the old API having ranges baked in (which were never used).
That being said, is there actually any value in this message? Would you
mind deleting it (I see how it could annoy a user)?
You might want to look at devlink regions if you want to debug the VLAN
table of the hardware.
> + return 0;
> + }
> +
> + if (port_mask_new) {
> + func = AR9331_SW_VT0_FUNC_LOAD_ENTRY;
> + } else {
> + func = AR9331_SW_VT0_FUNC_PURGE_ENTRY;
> + port_mask_new = port_mask;
> + }
> +
> + if (vdb) {
> + vdb->port_mask = port_mask_new;
> +
> + if (!port_mask_new)
> + vdb->vid = 0;
> + } else {
> + for (i = 0; i < ARRAY_SIZE(priv->vdb); i++) {
> + if (!priv->vdb[i].vid) {
> + vdb = >vdb[i];
> + break;
> + }
> + }
> +
> + if (!vdb) {
> + dev_err_ratelimited(priv->dev, "Local VDB is full\n");
You have a netlink extack at your disposal, use it.
> + return -ENOMEM;
> + }
> + vdb->vid = vid;
> + vdb->port_mask = port_mask_new;
> + }
> +
> + f0 = FIELD_PREP(AR9331_SW_VT0_VID, vid) |
> + FIELD_PREP(AR9331_SW_VT0_FUNC, func) |
> + AR9331_SW_VT0_BUSY;
> + f1 = FIELD_PREP(AR9331_SW_VT1_VID_MEM, port_mask_new) |
> + AR9331_SW_VT1_VALID;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, f1);
> + if (ret)
> + return ret;
> +
> + ret =
Re: [PATCH net-next v1 4/9] net: dsa: qca: ar9331: make proper initial port defaults
On Sat, Apr 03, 2021 at 01:48:43PM +0200, Oleksij Rempel wrote:
> Make sure that all external port are actually isolated from each other,
> so no packets are leaked.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/dsa/qca/ar9331.c | 145 ++-
> 1 file changed, 143 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
> index 9a5035b2f0ff..a3de3598fbf5 100644
> --- a/drivers/net/dsa/qca/ar9331.c
> +++ b/drivers/net/dsa/qca/ar9331.c
> @@ -60,10 +60,19 @@
>
> /* MIB registers */
> #define AR9331_MIB_COUNTER(x)(0x2 + ((x) *
> 0x100))
>
> @@ -229,6 +278,7 @@ struct ar9331_sw_priv {
> struct regmap *regmap;
> struct reset_control *sw_reset;
> struct ar9331_sw_port port[AR9331_SW_PORTS];
> + int cpu_port;
> };
>
> static struct ar9331_sw_priv *ar9331_sw_port_to_priv(struct ar9331_sw_port
> *port)
> @@ -371,12 +421,72 @@ static int ar9331_sw_mbus_init(struct ar9331_sw_priv
> *priv)
> return 0;
> }
>
> -static int ar9331_sw_setup(struct dsa_switch *ds)
> +static int ar9331_sw_setup_port(struct dsa_switch *ds, int port)
> {
> struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> struct regmap *regmap = priv->regmap;
> + u32 port_mask, port_ctrl, val;
> int ret;
>
> + /* Generate default port settings */
> + port_ctrl = FIELD_PREP(AR9331_SW_PORT_CTRL_PORT_STATE,
> +AR9331_SW_PORT_CTRL_PORT_STATE_DISABLED);
> +
> + if (dsa_is_cpu_port(ds, port)) {
> + /*
> + * CPU port should be allowed to communicate with all user
> + * ports.
> + */
> + //port_mask = dsa_user_ports(ds);
Code commented out should ideally not be part of a submitted patch.
And the networking comment style is:
/* CPU port should be allowed to communicate with all user
* ports.
*/
> + port_mask = 0;
> + /*
> + * Enable atheros header on CPU port. This will allow us
> + * communicate with each port separately
> + */
> + port_ctrl |= AR9331_SW_PORT_CTRL_HEAD_EN;
> + port_ctrl |= AR9331_SW_PORT_CTRL_LEARN_EN;
> + } else if (dsa_is_user_port(ds, port)) {
> + /*
> + * User ports should communicate only with the CPU port.
> + */
> + port_mask = BIT(priv->cpu_port);
For all you care, the CPU port here is dsa_to_port(ds, port)->cpu_dp->index,
no need to go to those lengths in order to find it. DSA does not have a
fixed number for the CPU port but a CPU port pointer per port in order
to not close the door for the future support of multiple CPU ports.
> + /* Enable unicast address learning by default */
> + port_ctrl |= AR9331_SW_PORT_CTRL_LEARN_EN
> + /* IGMP snooping seems to work correctly, let's use it */
> + | AR9331_SW_PORT_CTRL_IGMP_MLD_EN
I don't really like this ad-hoc enablement of IGMP/MLD snooping from the driver,
please add the pass-through in DSA for SWITCHDEV_ATTR_ID_BRIDGE_MC_DISABLED
(dsa_slave_port_attr_set, dsa_port_switchdev_sync, dsa_port_switchdev_unsync
should all call a dsa_switch_ops :: port_snoop_igmp_mld function) and then
toggle this bit from there.
> + | AR9331_SW_PORT_CTRL_SINGLE_VLAN_EN;
> + } else {
> + /* Other ports do not need to communicate at all */
> + port_mask = 0;
> + }
> +
> + val = FIELD_PREP(AR9331_SW_PORT_VLAN_8021Q_MODE,
> + AR9331_SW_8021Q_MODE_NONE) |
> + FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask) |
> + FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID,
> +AR9331_SW_PORT_VLAN_PORT_VID_DEF);
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_PORT_VLAN(port), val);
> + if (ret)
> + goto error;
> +
> + ret = regmap_write(regmap, AR9331_SW_REG_PORT_CTRL(port), port_ctrl);
> + if (ret)
> + goto error;
> +
> + return 0;
> +error:
> + dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
> +
> + return ret;
> +}
> +
> +static int ar9331_sw_setup(struct dsa_switch *ds)
> +{
> + struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
> + struct regmap *regmap = priv->regmap;
> + int ret, i;
> +
> ret = ar9331_sw_reset(priv);
> if (ret)
> return ret;
> @@ -390,7 +500,8 @@ static int ar9331_sw_setup(struct dsa_switch *ds)
>
> /* Do not drop broadcast frames */
> ret = regmap_write_bits(regmap, AR9331_SW_REG_FLOOD_MASK,
> - AR9331_SW_FLOOD_MASK_BROAD_TO_CPU,
> + AR9331_SW_FLOOD_MASK_BROAD_TO_CPU
> + | AR9331_SW_FLOOD_MASK_MULTI_FLOOD_DP,
>
Re: [PATCH net-next v1 2/9] net: dsa: tag_ar9331: detect IGMP and MLD packets
On Sat, Apr 03, 2021 at 07:14:56PM +0200, Oleksij Rempel wrote:
> Am 03.04.21 um 16:49 schrieb Andrew Lunn:
> >> @@ -31,6 +96,13 @@ static struct sk_buff *ar9331_tag_xmit(struct sk_buff
> >> *skb,
> >>__le16 *phdr;
> >>u16 hdr;
> >>
> >> + if (dp->stp_state == BR_STATE_BLOCKING) {
> >> + /* TODO: should we reflect it in the stats? */
> >> + netdev_warn_once(dev, "%s:%i dropping blocking packet\n",
> >> + __func__, __LINE__);
> >> + return NULL;
> >> + }
> >> +
> >>phdr = skb_push(skb, AR9331_HDR_LEN);
> >>
> >>hdr = FIELD_PREP(AR9331_HDR_VERSION_MASK, AR9331_HDR_VERSION);
> >
> > Hi Oleksij
> >
> > This change does not seem to fit with what this patch is doing.
>
> done
>
> > I also think it is wrong. You still need BPDU to pass through a
> > blocked port, otherwise spanning tree protocol will be unstable.
>
> We need a better filter, otherwise, in case of software based STP, we are
> leaking packages on
> blocked port. For example DHCP do trigger lots of spam in the kernel log.
I have no idea whatsoever what 'software based STP' is, if you have
hardware-accelerated forwarding.
> I'll drop STP patch for now, it will be better to make a generic soft STP for
> all switches without
> HW offloading. For example ksz9477 is doing SW based STP in similar way.
How about we discuss first about what your switch is not doing properly?
Have you debugged more than just watching the bridge change port states?
As Andrew said, a port needs to accept and send link-local frames
regardless of the STP state. In the BLOCKING state it must send no other
frames and have address learning disabled. Is this what's happening, is
the switch forwarding frames towards a BLOCKING port?
Re: [External] [PATCH v3 7/8] hugetlb: make free_huge_page irq safe
On 4/2/21 10:59 PM, Muchun Song wrote:
> On Sat, Apr 3, 2021 at 4:56 AM Mike Kravetz wrote:
>>
>> On 4/2/21 5:47 AM, Muchun Song wrote:
>>> On Wed, Mar 31, 2021 at 11:42 AM Mike Kravetz
>>> wrote:
Commit c77c0a8ac4c5 ("mm/hugetlb: defer freeing of huge pages if in
non-task context") was added to address the issue of free_huge_page
being called from irq context. That commit hands off free_huge_page
processing to a workqueue if !in_task. However, this doesn't cover
all the cases as pointed out by 0day bot lockdep report [1].
: Possible interrupt unsafe locking scenario:
:
:CPU0CPU1
:
: lock(hugetlb_lock);
:local_irq_disable();
:lock(slock-AF_INET);
:lock(hugetlb_lock);
:
: lock(slock-AF_INET);
Shakeel has later explained that this is very likely TCP TX zerocopy
from hugetlb pages scenario when the networking code drops a last
reference to hugetlb page while having IRQ disabled. Hugetlb freeing
path doesn't disable IRQ while holding hugetlb_lock so a lock dependency
chain can lead to a deadlock.
This commit addresses the issue by doing the following:
- Make hugetlb_lock irq safe. This is mostly a simple process of
changing spin_*lock calls to spin_*lock_irq* calls.
- Make subpool lock irq safe in a similar manner.
- Revert the !in_task check and workqueue handoff.
[1]
https://lore.kernel.org/linux-mm/f1c03b05bc43a...@google.com/
Signed-off-by: Mike Kravetz
Acked-by: Michal Hocko
Reviewed-by: Muchun Song
>>>
>>> Hi Mike,
>>>
>>> Today I pulled the newest code (next-20210401). I found that
>>> alloc_and_dissolve_huge_page is not updated. In this function,
>>> hugetlb_lock is still non-irq safe. Maybe you or Oscar need
>>> to fix.
>>>
>>> Thanks.
>>
>> Thank you Muchun,
>>
>> Oscar's changes were not in Andrew's tree when I started on this series
>> and I failed to notice their inclusion. In addition,
>> isolate_or_dissolve_huge_page also needs updating as well as a change in
>> set_max_huge_pages that was omitted while rebasing.
>>
>> Andrew, the following patch addresses those missing changes. Ideally,
>> the changes should be combined/included in this patch. If you want me
>> to sent another version of this patch or another series, let me know.
>>
>> From 450593eb3cea895f499ddc343c22424c552ea502 Mon Sep 17 00:00:00 2001
>> From: Mike Kravetz
>> Date: Fri, 2 Apr 2021 13:18:13 -0700
>> Subject: [PATCH] hugetlb: fix irq locking omissions
>>
>> The pach "hugetlb: make free_huge_page irq safe" changed spin_*lock
>> calls to spin_*lock_irq* calls. However, it missed several places
>> in the file hugetlb.c. Add the overlooked changes.
>>
>> Signed-off-by: Mike Kravetz
>
> Thanks MIke. But there are still some places that need
> improvement. See below.
>
Correct. My apologies again for not fully taking into account the new
code from Oscar's series when working on this.
>> ---
>> mm/hugetlb.c | 16
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index c22111f3da20..a6bfc6bcbc81 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -2284,7 +2284,7 @@ static int alloc_and_dissolve_huge_page(struct hstate
>> *h, struct page *old_page,
>> */
>> page_ref_dec(new_page);
>> retry:
>> - spin_lock(_lock);
>> + spin_lock_irq(_lock);
>> if (!PageHuge(old_page)) {
>> /*
>> * Freed from under us. Drop new_page too.
>> @@ -2297,7 +2297,7 @@ static int alloc_and_dissolve_huge_page(struct hstate
>> *h, struct page *old_page,
>> * Fail with -EBUSY if not possible.
>> */
>> update_and_free_page(h, new_page);
>
> Now update_and_free_page can be called without holding
> hugetlb_lock. We can move it out of hugetlb_lock. In this
> function, there are 3 places which call update_and_free_page().
> We can move all of them out of hugetlb_lock. Right?
We will need to do more than that.
The call to update_and_free_page in alloc_and_dissolve_huge_page
assumes old functionality. i.e. It assumes h->nr_huge_pages will be
decremented in update_and_free_page. This is no longer the case.
This will need to be fixed in patch 4 of my series which changes the
functionality of update_and_free_page. I'm afraid a change there will
end up requiring changes in subsequent patches due to context.
I will have an update on Monday.
--
Mike Kravetz
xfs_trace.c:undefined reference to `atomic64_read_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d83e98f9d8c88cbae1b05fa5751bddfcf0e222b2 commit: 166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 xfs: stop CONFIG_XFS_DEBUG from changing compiler flags date: 11 months ago config: um-randconfig-r034-20210403 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): pids.c:(.text+0x2c): undefined reference to `atomic64_read_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_max_write': pids.c:(.text+0xdd): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_css_alloc': pids.c:(.text+0x12d): undefined reference to `atomic64_set_386' /usr/bin/ld: pids.c:(.text+0x13d): undefined reference to `atomic64_set_386' /usr/bin/ld: pids.c:(.text+0x14a): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_events_show': pids.c:(.text+0x171): undefined reference to `atomic64_read_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_can_attach': pids.c:(.text+0x23d): undefined reference to `atomic64_add_386' /usr/bin/ld: pids.c:(.text+0x262): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_cancel_attach': pids.c:(.text+0x2be): undefined reference to `atomic64_add_386' /usr/bin/ld: pids.c:(.text+0x2e3): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_release': pids.c:(.text+0x32e): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_can_fork': pids.c:(.text+0x3c2): undefined reference to `atomic64_add_return_386' /usr/bin/ld: pids.c:(.text+0x3d2): undefined reference to `atomic64_read_386' /usr/bin/ld: pids.c:(.text+0x3ff): undefined reference to `atomic64_add_return_386' /usr/bin/ld: pids.c:(.text+0x414): undefined reference to `atomic64_add_return_386' /usr/bin/ld: pids.c:(.text+0x41f): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_cancel_fork': pids.c:(.text+0x4e0): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/trace/trace_clock.o: in function `trace_clock_counter': trace_clock.c:(.text+0xcc): undefined reference to `atomic64_add_return_386' /usr/bin/ld: fs/proc/task_mmu.o: in function `task_mem': task_mmu.c:(.text+0x4ec): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/balloc.o: in function `ext4_has_free_clusters': balloc.c:(.text+0x54): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/dir.o: in function `ext4_dir_llseek': dir.c:(.text+0x256): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/dir.o: in function `ext4_readdir': dir.c:(.text+0x4fc): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x52c): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x555): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: dir.c:(.text+0x8d9): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x931): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x95a): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/ialloc.o: in function `get_orlov_stats': ialloc.c:(.text+0x239): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/inline.o: in function `ext4_add_dirent_to_inline.isra.0': inline.c:(.text+0x3ed): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x425): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inline.o: in function `ext4_read_inline_dir': inline.c:(.text+0x1d7d): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x1dd5): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x1dfe): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inode.o: in function `inode_maybe_inc_iversion.constprop.0': inode.c:(.text+0xeb2): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0xeea): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inode.o: in function `ext4_do_update_inode': inode.c:(.text+0x2318): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x231f): undefined ref
Re: [PATCH] kfence: unpoison pool region before use
On Sun, Apr 4, 2021 at 12:31 AM Marco Elver wrote: > > However, given the above, I think we need to explain this in the > commit message (which also makes the dependency between these 2 > patches clear) and add a comment above the new kasan_unpoison_range(). > That is, if we still think this is the right fix -- I'm not entirely > sure it is. > > Because what I gather from "kasan: initialize shadow to TAG_INVALID > for SW_TAGS", is the requirement that "0xFF pointer tag is a match-all > tag, it doesn't matter what tag the accessed memory has". > > While KFENCE memory is accessible through the slab API, and in this > case ksize() calling kasan_check_byte() leading to a failure, the > kasan_check_byte() call is part of the public KASAN API. Which means > that if some subsystem decides to memblock_alloc() some memory, and > wishes to use kasan_check_byte() on that memory but with an untagged > pointer, will get the same problem as KFENCE: with generic and HW_TAGS > mode everything is fine, but with SW_TAGS mode things break. It makes sense to allow this function to operate on any kind of memory, including memory that hasn't been previously marked by KASAN. > To me this indicates the fix is not with KFENCE, but should be in > mm/kasan/sw_tags.c:kasan_byte_accessible(), which should not load the > shadow when the pointer is untagged. The problem isn't in accessing shadow per se. Looking at kasan_byte_accessible() (in both sw_tags.c and kasan.h), the return statement there seems just wrong and redundant. The KASAN_TAG_KERNEL check should come first: return tag == KASAN_TAG_KERNEL || (shadow_byte != KASAN_TAG_INVALID && tag == shadow_byte); This way, if the pointer tag is KASAN_TAG_KERNEL, the memory is accessible no matter what the memory tag is. But then the KASAN_TAG_INVALID check isn't needed, as this value is never assigned to a pointer tag. Which brings us to: return tag == KASAN_TAG_KERNEL || tag == shadow_byte; Which is essentially the same check that kasan_check_range() performs. Although, kasan_check_range() also checks that the shadow is < KASAN_SHADOW_START. It makes makes sense to add this check into kasan_byte_accessible() as well, before accessing shadow. Thanks!
Re: [PATCH net-next v1 5/9] net: dsa: qca: ar9331: add forwarding database support
On Sat, Apr 03, 2021 at 05:25:16PM +0200, Andrew Lunn wrote:
> > +static int ar9331_sw_port_fdb_rmw(struct ar9331_sw_priv *priv,
> > + const unsigned char *mac,
> > + u8 port_mask_set,
> > + u8 port_mask_clr)
> > +{
> > + port_mask = FIELD_GET(AR9331_SW_AT_DES_PORT, f2);
> > + status = FIELD_GET(AR9331_SW_AT_STATUS, f2);
> > + if (status > 0 && status < AR9331_SW_AT_STATUS_STATIC) {
> > + dev_err_ratelimited(priv->dev, "%s: found existing dynamic
> > entry on %x\n",
> > + __func__, port_mask);
> > +
> > + if (port_mask_set && port_mask_set != port_mask)
> > + dev_err_ratelimited(priv->dev, "%s: found existing
> > dynamic entry on %x, replacing it with static on %x\n",
> > + __func__, port_mask, port_mask_set);
> > + port_mask = 0;
> > + } else if (!status && !port_mask_set) {
> > + return 0;
> > + }
>
> As a generate rule of thumb, use rate limiting where you have no
> control of the number of prints, e.g. it is triggered by packet
> processing, and there is potentially a lot of them, which could DOS
> the box by a remote or unprivileged attacker.
>
> FDB changes should not happen often. Yes, root my be able to DOS the
> box by doing bridge fdb add commands in a loop, but only root should
> be able to do that.
+1
The way I see it, rate limiting should only be done when the user can't
stop the printing from spamming the console, and they just go "argh,
kill it with fire!!!" and throw the box away. As a side note, most of
the time when I can't stop the kernel from printing in a loop, the rate
limit isn't enough to stop me from wanting to throw the box out the
window, but I digress.
> Plus, i'm not actually sure we should be issuing warnings here. What
> does the bridge code do in this case? Is it silent and just does it,
> or does it issue a warning?
:D
What Oleksij doesn't know, I bet, is that he's using the bridge bypass
commands:
bridge fdb add dev lan0 00:01:02:03:04:05
That is the deprecated way of managing FDB entries, and has several
disadvantages such as:
- the bridge software FDB never gets updated with this entry, so other
drivers which might be subscribed to DSA's FDB (imagine a non-DSA
driver having the same logic as our ds->assisted_learning_on_cpu_port)
will never see these FDB entries
- you have to manage duplicates yourself
The correct way to install a static bridge FDB entry is:
bridge fdb add dev lan0 00:01:02:03:04:05 master static
That will error out on duplicates for you.
>From my side I would even go as far as deleting the bridge bypass
operations (.ndo_fdb_add and .ndo_fdb_del). The more integration we add
between DSA and the bridge/switchdev, the worse it will be when users
just keep using the bridge bypass. To start that process, I guess we
should start emitting a deprecation warning and then pull the trigger
after a few kernel release cycles.
> > +
> > + port_mask_new = port_mask & ~port_mask_clr;
> > + port_mask_new |= port_mask_set;
> > +
> > + if (port_mask_new == port_mask &&
> > + status == AR9331_SW_AT_STATUS_STATIC) {
> > + dev_info(priv->dev, "%s: no need to overwrite existing valid
> > entry on %x\n",
> > + __func__, port_mask_new);
>
> This one should probably be dev_dbg().
Or deleted, along with the overwrite logic.
/usr/bin/ld: core.c:undefined reference to `cmpxchg8b_emu'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 5ffa25502b5ab3d639829a2d1e316cff7f59a41e bpf: Add instructions for atomic_[cmp]xchg date: 3 months ago config: um-randconfig-c003-20210404 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ffa25502b5ab3d639829a2d1e316cff7f59a41e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 5ffa25502b5ab3d639829a2d1e316cff7f59a41e # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): algapi.c:(.text+0x19e3): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x19f3): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1a1a): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_akcipher_decrypt': algapi.c:(.text+0x1a70): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1a80): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1aa7): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_akcipher_sign': algapi.c:(.text+0x1b01): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1b2b): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_akcipher_verify': algapi.c:(.text+0x1b8b): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1bb5): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o:algapi.c:(.text+0x1c11): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_compress': algapi.c:(.text+0x1c21): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1c48): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_decompress': algapi.c:(.text+0x1c9e): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1cae): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1cd5): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_ahash_update': algapi.c:(.text+0x1d30): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1d57): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_ahash_final': algapi.c:(.text+0x1dad): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1dbd): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x1de4): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_kpp_set_secret': algapi.c:(.text+0x1e35): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1e78): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_kpp_generate_public_key': algapi.c:(.text+0x1eb6): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x1ef9): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o:algapi.c:(.text+0x1f37): more undefined references to `atomic64_inc_386' follow /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_rng_generate': algapi.c:(.text+0x2057): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x207e): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_skcipher_encrypt': algapi.c:(.text+0x20d4): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x20e4): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x210b): undefined reference to `atomic64_inc_386' /usr/bin/ld: crypto/algapi.o: in function `crypto_stats_skcipher_decrypt': algapi.c:(.text+0x2161): undefined reference to `atomic64_inc_386' /usr/bin/ld: algapi.c:(.text+0x2171): undefined reference to `atomic64_add_386' /usr/bin/ld: algapi.c:(.text+0x2198): undefined reference to `atomic64_inc_386' /usr/bin/ld: drivers/phy/ingenic/phy-ingenic-usb.o: in function `ingenic_usb_phy_probe': phy-ingenic-usb.c:(.text+0x336): undefined reference to `devm_platform_ioremap_resource' /usr/bin/ld: net/core/net_namespace.o: in function `__net_gen_cookie': net_namespace.c:(.text+0x965): undefined reference to `atomic64_read_386' /usr/bin/ld: net_namespace.c:(.text+0x9aa): undefined reference to `cmpxchg8b_emu'
Re: [PATCH net-next v1 1/9] net: dsa: add rcv_post call back
On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote:
> On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote:
> > Some switches (for example ar9331) do not provide enough information
> > about forwarded packets. If the switch decision was made based on IPv4
> > or IPv6 header, we need to analyze it and set proper flag.
> >
> > Potentially we can do it in existing rcv path, on other hand we can
> > avoid part of duplicated work and let the dsa framework set skb header
> > pointers and then use preprocessed skb one step later withing the rcv_post
> > call back.
> >
> > This patch is needed for ar9331 switch.
> >
> > Signed-off-by: Oleksij Rempel
> > ---
>
> I don't necessarily disagree with this, perhaps we can even move
> Florian's dsa_untag_bridge_pvid() call inside a rcv_post() method
> implemented by the DSA_TAG_PROTO_BRCM_LEGACY, DSA_TAG_PROTO_BRCM_PREPEND
> and DSA_TAG_PROTO_BRCM taggers. Or even better, because Oleksij's
> rcv_post is already prototype-compatible with dsa_untag_bridge_pvid, we
> can already do:
>
> .rcv_post = dsa_untag_bridge_pvid,
>
> This should be generally useful for stuff that DSA taggers need to do
> which is easiest done after eth_type_trans() was called.
I had some fun with an alternative method of parsing the frame for IGMP
so that you can clear skb->offload_fwd_mark, which doesn't rely on the
introduction of a new method in DSA. It should also have several other
advantages compared to your solution such as the fact that it should
work with VLAN-tagged packets.
Background: we made Receive Packet Steering work on DSA master interfaces
(echo 3 > /sys/class/net/eth0/queues/rx-1/rps_cpus) even when the DSA
tag shifts to the right the IP headers and everything that comes
afterwards. The flow dissector had to be patched for that, just grep for
DSA in net/core/flow_dissector.c.
The problem you're facing is that you can't parse the IP and IGMP
headers in the tagger's rcv() method, since the network header,
transport header offsets and skb->protocol are all messed up, since
eth_type_trans hasn't been called yet.
And that's the trick right there, you're between a rock and a hard
place: too early because eth_type_trans wasn't called yet, and too late
because skb->dev was changed and no longer points to the DSA master, so
the flow dissector adjustment we made doesn't apply.
But if you call the flow dissector _before_ you call "skb->dev =
dsa_master_find_slave" (and yes, while the DSA tag is still there), then
it's virtually as if you had called that while the skb belonged to the
DSA master, so it should work with __skb_flow_dissect.
In fact I prototyped this idea below. I wanted to check whether I can
match something as fine-grained as an IGMPv2 Membership Report message,
and I could.
I prototyped it inside the ocelot tagging protocol driver because that's
what I had handy. I used __skb_flow_dissect with my own flow dissector
which had to be initialized at the tagger module_init time, even though
I think I could have probably just called skb_flow_dissect_flow_keys
with a standard dissector, and that would have removed the need for the
custom module_init in tag_ocelot.c. One thing that is interesting is
that I had to add the bits for IGMP parsing to the flow dissector
myself (based on the existing ICMP code). I was too lazy to do that for
MLD as well, but it is really not hard. Or even better, if you don't
need to look at all inside the IGMP/MLD header, I think you can even
omit adding this parsing code to the flow dissector and just look at
basic.n_proto and basic.ip_proto.
See the snippet below. Hope it helps.
-[ cut here ]-
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index ffd386ea0dbb..4c25fa47637a 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -190,6 +190,20 @@ struct flow_dissector_key_icmp {
u16 id;
};
+/**
+ * flow_dissector_key_igmp:
+ * type: indicates the message type, see include/uapi/linux/igmp.h
+ * code: Max Resp Code, the maximum time in 1/10 second
+ * increments before sending a responding report
+ * group: the multicast address being queried when sending a
+ *Group-Specific or Group-and-Source-Specific Query.
+ */
+struct flow_dissector_key_igmp {
+ u8 type;
+ u8 code; /* Max Resp Time in IGMPv2 */
+ __be32 group;
+};
+
/**
* struct flow_dissector_key_eth_addrs:
* @src: source Ethernet address
@@ -259,6 +273,7 @@ enum flow_dissector_key_id {
FLOW_DISSECTOR_KEY_PORTS, /* struct flow_dissector_key_ports */
FLOW_DISSECTOR_KEY_PORTS_RANGE, /* struct flow_dissector_key_ports */
FLOW_DISSECTOR_KEY_ICMP, /* struct flow_dissector_key_icmp */
+ FLOW_DISSECTOR_KEY_IGMP, /* struct flow_dissector_key_igmp */
FLOW_DISSECTOR_KEY_ETH_ADDRS, /* struct flow_dissector_key_eth_addrs */
[tip:master] BUILD SUCCESS cba793347389e4beafac9f2ee6ecd3e74d8715c1
defconfig mips allyesconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20210404 i386 randconfig-a003-20210404 i386 randconfig-a001-20210404 i386 randconfig-a004-20210404 i386 randconfig-a005-20210404 i386 randconfig-a002-20210404 i386 randconfig-a006-20210403 i386 randconfig-a003-20210403 i386 randconfig-a001-20210403 i386 randconfig-a004-20210403 i386 randconfig-a002-20210403 i386 randconfig-a005-20210403 x86_64 randconfig-a014-20210403 x86_64 randconfig-a015-20210403 x86_64 randconfig-a011-20210403 x86_64 randconfig-a013-20210403 x86_64 randconfig-a012-20210403 x86_64 randconfig-a016-20210403 i386 randconfig-a014-20210404 i386 randconfig-a016-20210404 i386 randconfig-a011-20210404 i386 randconfig-a012-20210404 i386 randconfig-a015-20210404 i386 randconfig-a013-20210404 i386 randconfig-a014-20210403 i386 randconfig-a011-20210403 i386 randconfig-a016-20210403 i386 randconfig-a012-20210403 i386 randconfig-a013-20210403 i386 randconfig-a015-20210403 x86_64 randconfig-a004-20210404 x86_64 randconfig-a003-20210404 x86_64 randconfig-a005-20210404 x86_64 randconfig-a001-20210404 x86_64 randconfig-a002-20210404 x86_64 randconfig-a006-20210404 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64rhel-8.3-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a004-20210403 x86_64 randconfig-a005-20210403 x86_64 randconfig-a003-20210403 x86_64 randconfig-a001-20210403 x86_64 randconfig-a002-20210403 x86_64 randconfig-a006-20210403 x86_64 randconfig-a014-20210404 x86_64 randconfig-a015-20210404 x86_64 randconfig-a013-20210404 x86_64 randconfig-a011-20210404 x86_64 randconfig-a012-20210404 x86_64 randconfig-a016-20210404 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [GIT PULL] OpenRISC fixes for 5.12-rc5
The pull request you sent on Sun, 4 Apr 2021 06:29:44 +0900: > git://github.com/openrisc/linux.git tags/for-linus has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2023a53bdf41b7646b1d384b6816af06309f73a5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH] staging: rtl8188eu: core: replace spaces with a tab
To conform to Linux kernel coding style, a tab replaces the two spaces
that were previously used to indent brackets. Identified by the
checkpatch warning: WARNING: please, no spaces at the start of a line.
Signed-off-by: Deborah Brouwer
---
drivers/staging/rtl8188eu/core/rtw_security.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index da26a3c705f8..617f89842c81 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -425,9 +425,9 @@ static const unsigned short Sbox1[2][256] = { /* Sbox for
hash (can be in ROM)
0x2DB6, 0x3C22, 0x1592, 0xC920, 0x8749, 0xAAFF, 0x5078, 0xA57A,
0x038F, 0x59F8, 0x0980, 0x1A17, 0x65DA, 0xD731, 0x84C6, 0xD0B8,
0x82C3, 0x29B0, 0x5A77, 0x1E11, 0x7BCB, 0xA8FC, 0x6DD6, 0x2C3A,
- },
+ },
- { /* second half of table is unsigned char-reversed version of first! */
+ { /* second half of table is unsigned char-reversed version of first!
*/
0xA5C6, 0x84F8, 0x99EE, 0x8DF6, 0x0DFF, 0xBDD6, 0xB1DE, 0x5491,
0x5060, 0x0302, 0xA9CE, 0x7D56, 0x19E7, 0x62B5, 0xE64D, 0x9AEC,
0x458F, 0x9D1F, 0x4089, 0x87FA, 0x15EF, 0xEBB2, 0xC98E, 0x0BFB,
@@ -460,7 +460,7 @@ static const unsigned short Sbox1[2][256] = { /* Sbox for
hash (can be in ROM)
0xB62D, 0x223C, 0x9215, 0x20C9, 0x4987, 0xFFAA, 0x7850, 0x7AA5,
0x8F03, 0xF859, 0x8009, 0x171A, 0xDA65, 0x31D7, 0xC684, 0xB8D0,
0xC382, 0xB029, 0x775A, 0x111E, 0xCB7B, 0xFCA8, 0xD66D, 0x3A2C,
- }
+ }
};
/**
--
2.17.1
drivers/gpu/drm/bridge/sil-sii8620.c:2355: undefined reference to `extcon_unregister_notifier'
Hi Masahiro,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8e29be3468d4565dd95fbb098df0d7a79ee60d71
commit: def2fbffe62c00c330c7f41584a356001179c59c kconfig: allow symbols implied
by y to become m
date: 1 year, 1 month ago
config: i386-randconfig-a003-20210404 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=def2fbffe62c00c330c7f41584a356001179c59c
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout def2fbffe62c00c330c7f41584a356001179c59c
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_remove':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2355: undefined reference to
>> `extcon_unregister_notifier'
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_init':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2179: undefined reference to
>> `extcon_find_edev_by_node'
>> ld: drivers/gpu/drm/bridge/sil-sii8620.c:2191: undefined reference to
>> `extcon_register_notifier'
ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_work':
>> drivers/gpu/drm/bridge/sil-sii8620.c:2139: undefined reference to
>> `extcon_get_state'
vim +2355 drivers/gpu/drm/bridge/sil-sii8620.c
688838442147d9 Maciej Purski2018-02-27 2162
688838442147d9 Maciej Purski2018-02-27 2163 static int
sii8620_extcon_init(struct sii8620 *ctx)
688838442147d9 Maciej Purski2018-02-27 2164 {
688838442147d9 Maciej Purski2018-02-27 2165struct extcon_dev *edev;
688838442147d9 Maciej Purski2018-02-27 2166struct device_node
*musb, *muic;
688838442147d9 Maciej Purski2018-02-27 2167int ret;
688838442147d9 Maciej Purski2018-02-27 2168
688838442147d9 Maciej Purski2018-02-27 2169/* get micro-USB
connector node */
688838442147d9 Maciej Purski2018-02-27 2170musb =
of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
688838442147d9 Maciej Purski2018-02-27 2171/* next get micro-USB
Interface Controller node */
688838442147d9 Maciej Purski2018-02-27 2172muic =
of_get_next_parent(musb);
688838442147d9 Maciej Purski2018-02-27 2173
688838442147d9 Maciej Purski2018-02-27 2174if (!muic) {
688838442147d9 Maciej Purski2018-02-27 2175
dev_info(ctx->dev, "no extcon found, switching to 'always on' mode\n");
688838442147d9 Maciej Purski2018-02-27 2176return 0;
688838442147d9 Maciej Purski2018-02-27 2177}
688838442147d9 Maciej Purski2018-02-27 2178
688838442147d9 Maciej Purski2018-02-27 @2179edev =
extcon_find_edev_by_node(muic);
688838442147d9 Maciej Purski2018-02-27 2180of_node_put(muic);
688838442147d9 Maciej Purski2018-02-27 2181if (IS_ERR(edev)) {
688838442147d9 Maciej Purski2018-02-27 2182if
(PTR_ERR(edev) == -EPROBE_DEFER)
688838442147d9 Maciej Purski2018-02-27 2183return
-EPROBE_DEFER;
688838442147d9 Maciej Purski2018-02-27 2184
dev_err(ctx->dev, "Invalid or missing extcon\n");
688838442147d9 Maciej Purski2018-02-27 2185return
PTR_ERR(edev);
688838442147d9 Maciej Purski2018-02-27 2186}
688838442147d9 Maciej Purski2018-02-27 2187
688838442147d9 Maciej Purski2018-02-27 2188ctx->extcon = edev;
688838442147d9 Maciej Purski2018-02-27 2189
ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
688838442147d9 Maciej Purski2018-02-27 2190
INIT_WORK(>extcon_wq, sii8620_extcon_work);
688838442147d9 Maciej Purski2018-02-27 @2191ret =
extcon_register_notifier(edev, EXTCON_DISP_MHL, >extcon_nb);
688838442147d9 Maciej Purski2018-02-27 2192if (ret) {
688838442147d9 Maciej Purski2018-02-27 2193
dev_err(ctx->dev, "failed to register notifier for MHL\n");
688838442147d9 Maciej Purski2018-02-27 2194return ret;
688838442147d9 Maciej Purski2018-02-27 2195}
688838442147d9 Maciej Purski2018-02-27 2196
688838442147d9 Maciej Purski2018-02-27 2197return 0;
688838442147d9 Maciej Purski2018-02-27 2198 }
688838442147d9 Maciej Purski2018-02-27 2199
ce6e153f414a73 Andrzej Hajda2016-10-10 2200 static inline struct sii8620
*bridge_to_sii8620(struct drm_bridge *bridge)
ce6e153f414a73 Andrzej Hajda2016-10-10 2201 {
ce6e153f414a73 Andrzej Hajda2016-10-10 2202return
container_of(bridge, struct
Re: [PATCH] kfence: unpoison pool region before use
On Sat, 3 Apr 2021 at 22:40, Peter Collingbourne wrote: > On Sat, Apr 3, 2021 at 3:03 AM Marco Elver wrote: > > On Sat, 3 Apr 2021 at 07:13, Peter Collingbourne wrote: > > > If the memory region allocated by KFENCE had previously been poisoned, > > > any validity checks done using kasan_byte_accessible() will fail. Fix > > > it by unpoisoning the memory before using it as the pool region. > > > > > > Link: > > > https://linux-review.googlesource.com/id/I0af99e9f1c25eaf7e1ec295836b5d148d76940c5 > > > Signed-off-by: Peter Collingbourne > > > > Thanks, at a high level this seems reasonable, because we always want > > to ensure that KFENCE memory remains unpoisoned with KASAN on. FWIW I > > subjected a config with KFENCE+KASAN (generic, SW_TAGS, and HW_TAGS) > > to syzkaller testing and ran kfence_test: > > > > Tested-by: Marco Elver > > > > > > However, it is unclear to me under which circumstances we actually > > need this, i.e. something would grab some memblock memory, somehow > > poison it, and then release the memory back during early boot (note, > > kfence_alloc_pool() is called before slab setup). If we can somehow > > understand what actually did this, perhaps it'd help tell us if this > > actually needs fixing in KFENCE or it's the other thing that needs a > > fix. > > > > Given all this is happening during really early boot, I'd expect no or > > very few calls to kasan_poison() until kfence_alloc_pool() is called. > > We can probably debug it more by having kasan_poison() do a "if > > (!__kfence_pool) dump_stack();" somewhere. Can you try this on the > > system where you can repro the problem? I tried this just now on the > > latest mainline kernel, and saw 0 calls until kfence_alloc_pool(). > > I looked into the issue some more, and it turned out that the memory > wasn't getting poisoned by kasan_poison() but rather by the calls to > kasan_map_populate() in kasan_init_shadow(). Starting with the patch > "kasan: initialize shadow to TAG_INVALID for SW_TAGS", > KASAN_SHADOW_INIT is set to 0xFE rather than 0xFF, which caused the > failure. The Android kernel branch for 5.10 (and the downstream kernel > I was working with) already have this patch, but it isn't in the > mainline kernel yet. > > Now that I understand the cause of the issue, I can reproduce it using > the KFENCE unit tests on a db845c board, using both the Android 5.10 > and mainline branches if I cherry-pick that change. Here's an example > crash from the unit tests (the failure was originally also observed > from ksize in the downstream kernel): > > [ 46.692195][ T175] BUG: KASAN: invalid-access in test_krealloc+0x1c4/0xf98 > [ 46.699282][ T175] Read of size 1 at addr ff80e9e7b000 by task > kunit_try_catch/175 > [ 46.707400][ T175] Pointer tag: [ff], memory tag: [fe] > [ 46.712710][ T175] > [ 46.714955][ T175] CPU: 4 PID: 175 Comm: kunit_try_catch Tainted: > GB 5.12.0-rc5-mainline-09505-ga2ab5b26d445-dirty #1 > [ 46.727193][ T175] Hardware name: Thundercomm Dragonboard 845c (DT) > [ 46.733636][ T175] Call trace: > [ 46.736841][ T175] dump_backtrace+0x0/0x2f8 > [ 46.741295][ T175] show_stack+0x2c/0x3c > [ 46.745388][ T175] dump_stack+0x124/0x1bc > [ 46.749668][ T175] print_address_description+0x7c/0x308 > [ 46.755178][ T175] __kasan_report+0x1a8/0x398 > [ 46.759816][ T175] kasan_report+0x50/0x7c > [ 46.764103][ T175] __kasan_check_byte+0x3c/0x54 > [ 46.768916][ T175] ksize+0x4c/0x94 > [ 46.772573][ T175] test_krealloc+0x1c4/0xf98 > [ 46.777108][ T175] kunit_try_run_case+0x94/0x1c4 > [ 46.781990][ T175] kunit_generic_run_threadfn_adapter+0x30/0x44 > [ 46.788196][ T175] kthread+0x20c/0x234 > [ 46.792213][ T175] ret_from_fork+0x10/0x30 > > Since "kasan: initialize shadow to TAG_INVALID for SW_TAGS" hasn't > landed in mainline yet, it seems like we should insert this patch > before that one rather than adding a Fixes: tag. Thanks for getting to the bottom of it. However, given the above, I think we need to explain this in the commit message (which also makes the dependency between these 2 patches clear) and add a comment above the new kasan_unpoison_range(). That is, if we still think this is the right fix -- I'm not entirely sure it is. Because what I gather from "kasan: initialize shadow to TAG_INVALID for SW_TAGS", is the requirement that "0xFF pointer tag is a match-all tag, it doesn't matter what tag the accessed memory has". While KFENCE memory is accessible through the slab API, and in this case ksize() calling kasan_check_byte() leading to a failure, the kasan_check_byte() call is part of the public KASAN API. Which means that if some subsystem decides to memblock_alloc() some memory, and wishes to use kasan_check_byte() on that memory but with an untagged pointer, will get the same problem as KFENCE: with generic and HW_TAGS mode everything is fine, but with SW_TAGS mode things break. To me this indicates the fix is not with
[PATCH next 1/2] mfd: Add Renesas Synchronization Management Unit (SMU) support
From: Min Li
Add support for ClockMatrix(TM) and 82P33xxx families of timing
and synchronization devices. The access interface can be either
SPI or I2C. Currently, it will create 2 types of MFD devices,
which are to be used by the corresponding rsmu character device
driver and the PTP hardware clock driver, respectively.
Signed-off-by: Min Li
---
drivers/mfd/Kconfig | 27 ++
drivers/mfd/Makefile | 3 +
drivers/mfd/rsmu_i2c.c | 344 +
drivers/mfd/rsmu_private.h | 32 ++
drivers/mfd/rsmu_spi.c | 371 ++
include/linux/mfd/idt82p33_reg.h | 116 ++
include/linux/mfd/idt8a340_reg.h | 817 +++
include/linux/mfd/rsmu.h | 42 ++
8 files changed, 1752 insertions(+)
create mode 100644 drivers/mfd/rsmu_i2c.c
create mode 100644 drivers/mfd/rsmu_private.h
create mode 100644 drivers/mfd/rsmu_spi.c
create mode 100644 include/linux/mfd/idt82p33_reg.h
create mode 100644 include/linux/mfd/idt8a340_reg.h
create mode 100644 include/linux/mfd/rsmu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21a131d..ab5e13c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2172,5 +2172,32 @@ config MFD_INTEL_M10_BMC
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_RSMU_I2C
+ tristate "Renesas Synchronization Management Unit with I2C"
+ depends on I2C && OF
+ depends on MFD_RSMU_SPI=n
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports I2C as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
+config MFD_RSMU_SPI
+ tristate "Renesas Synchronization Management Unit with SPI"
+ depends on SPI && OF
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports SPI as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4f6d2b8..4ab32ef 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -271,3 +271,6 @@ obj-$(CONFIG_MFD_INTEL_M10_BMC) += intel-m10-bmc.o
obj-$(CONFIG_MFD_ATC260X) += atc260x-core.o
obj-$(CONFIG_MFD_ATC260X_I2C) += atc260x-i2c.o
+
+obj-$(CONFIG_MFD_RSMU_I2C) += rsmu_i2c.o
+obj-$(CONFIG_MFD_RSMU_SPI) += rsmu_spi.o
diff --git a/drivers/mfd/rsmu_i2c.c b/drivers/mfd/rsmu_i2c.c
new file mode 100644
index 000..06f582b
--- /dev/null
+++ b/drivers/mfd/rsmu_i2c.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Multi-function driver for the IDT ClockMatrix(TM) and 82P33xxx families of
+ * timing and synchronization devices.
+ *
+ * Copyright (C) 2019 Integrated Device Technology, Inc., a Renesas Company.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rsmu_private.h"
+
+/*
+ * 16-bit register address: the lower 8 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_CM_PAGE_ADDR 0xFD
+#defineRSMU_CM_PAGE_WINDOW 256
+
+/*
+ * 15-bit register address: the lower 7 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_SABRE_PAGE_ADDR0x7F
+#defineRSMU_SABRE_PAGE_WINDOW 128
+
+static bool rsmu_cm_volatile_reg(struct device *dev, unsigned int reg);
+static bool rsmu_sabre_volatile_reg(struct device *dev, unsigned int reg);
+
+/* Current mfd device index */
+static atomic_t rsmu_ndevs = ATOMIC_INIT(0);
+
+/* Platform data */
+static struct rsmu_pdata rsmu_pdata[RSMU_MAX_MFD_DEV];
+
+/* clockmatrix phc devices */
+static struct mfd_cell rsmu_cm_pdev[RSMU_MAX_MFD_DEV] = {
+ [0] = {
+ .name = "idtcm-ptp0",
+ .of_compatible = "renesas,idtcm-ptp0",
+ },
+ [1] = {
+ .name = "idtcm-ptp1",
+ .of_compatible = "renesas,idtcm-ptp1",
+ },
+ [2] = {
+ .name = "idtcm-ptp2",
+ .of_compatible = "renesas,idtcm-ptp2",
+ },
+ [3] = {
+ .name = "idtcm-ptp3",
+ .of_compatible = "renesas,idtcm-ptp3",
+ },
+};
+
+/* sabre phc devices */
+static struct mfd_cell rsmu_sabre_pdev[RSMU_MAX_MFD_DEV] = {
+ [0] = {
+ .name = "idt82p33-ptp0",
+
[PATCH next 1/2] mfd: Add Renesas Synchronization Management Unit (SMU) support
From: Min Li
Add support for ClockMatrix(TM) and 82P33xxx families of timing
and synchronization devices. The access interface can be either
SPI or I2C. Currently, it will create 2 types of MFD devices,
which are to be used by the corresponding rsmu character device
driver and the PTP hardware clock driver, respectively.
Signed-off-by: Min Li
---
drivers/mfd/Kconfig | 27 ++
drivers/mfd/Makefile | 3 +
drivers/mfd/rsmu_i2c.c | 344 +
drivers/mfd/rsmu_private.h | 32 ++
drivers/mfd/rsmu_spi.c | 371 ++
include/linux/mfd/idt82p33_reg.h | 116 ++
include/linux/mfd/idt8a340_reg.h | 817 +++
include/linux/mfd/rsmu.h | 42 ++
8 files changed, 1752 insertions(+)
create mode 100644 drivers/mfd/rsmu_i2c.c
create mode 100644 drivers/mfd/rsmu_private.h
create mode 100644 drivers/mfd/rsmu_spi.c
create mode 100644 include/linux/mfd/idt82p33_reg.h
create mode 100644 include/linux/mfd/idt8a340_reg.h
create mode 100644 include/linux/mfd/rsmu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21a131d..ab5e13c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2172,5 +2172,32 @@ config MFD_INTEL_M10_BMC
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_RSMU_I2C
+ tristate "Renesas Synchronization Management Unit with I2C"
+ depends on I2C && OF
+ depends on MFD_RSMU_SPI=n
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports I2C as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
+config MFD_RSMU_SPI
+ tristate "Renesas Synchronization Management Unit with SPI"
+ depends on SPI && OF
+ select MFD_CORE
+ help
+ Support for the Renesas synchronization management unit, such as
+ Clockmatrix and 82P33XXX series. This option supports SPI as
+ the control interface.
+
+ This driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4f6d2b8..4ab32ef 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -271,3 +271,6 @@ obj-$(CONFIG_MFD_INTEL_M10_BMC) += intel-m10-bmc.o
obj-$(CONFIG_MFD_ATC260X) += atc260x-core.o
obj-$(CONFIG_MFD_ATC260X_I2C) += atc260x-i2c.o
+
+obj-$(CONFIG_MFD_RSMU_I2C) += rsmu_i2c.o
+obj-$(CONFIG_MFD_RSMU_SPI) += rsmu_spi.o
diff --git a/drivers/mfd/rsmu_i2c.c b/drivers/mfd/rsmu_i2c.c
new file mode 100644
index 000..06f582b
--- /dev/null
+++ b/drivers/mfd/rsmu_i2c.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Multi-function driver for the IDT ClockMatrix(TM) and 82P33xxx families of
+ * timing and synchronization devices.
+ *
+ * Copyright (C) 2019 Integrated Device Technology, Inc., a Renesas Company.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "rsmu_private.h"
+
+/*
+ * 16-bit register address: the lower 8 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_CM_PAGE_ADDR 0xFD
+#defineRSMU_CM_PAGE_WINDOW 256
+
+/*
+ * 15-bit register address: the lower 7 bits of the register address come
+ * from the offset addr byte and the upper 8 bits come from the page register.
+ */
+#defineRSMU_SABRE_PAGE_ADDR0x7F
+#defineRSMU_SABRE_PAGE_WINDOW 128
+
+static bool rsmu_cm_volatile_reg(struct device *dev, unsigned int reg);
+static bool rsmu_sabre_volatile_reg(struct device *dev, unsigned int reg);
+
+/* Current mfd device index */
+static atomic_t rsmu_ndevs = ATOMIC_INIT(0);
+
+/* Platform data */
+static struct rsmu_pdata rsmu_pdata[RSMU_MAX_MFD_DEV];
+
+/* clockmatrix phc devices */
+static struct mfd_cell rsmu_cm_pdev[RSMU_MAX_MFD_DEV] = {
+ [0] = {
+ .name = "idtcm-ptp0",
+ .of_compatible = "renesas,idtcm-ptp0",
+ },
+ [1] = {
+ .name = "idtcm-ptp1",
+ .of_compatible = "renesas,idtcm-ptp1",
+ },
+ [2] = {
+ .name = "idtcm-ptp2",
+ .of_compatible = "renesas,idtcm-ptp2",
+ },
+ [3] = {
+ .name = "idtcm-ptp3",
+ .of_compatible = "renesas,idtcm-ptp3",
+ },
+};
+
+/* sabre phc devices */
+static struct mfd_cell rsmu_sabre_pdev[RSMU_MAX_MFD_DEV] = {
+ [0] = {
+ .name = "idt82p33-ptp0",
+
[PATCH next 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support
From: Min Li
This driver is developed for the IDT ClockMatrix(TM) and 82P33xxx families
of timing and synchronization devices.It will be used by Renesas PTP Clock
Manager for Linux (pcm4l) software to provide support to GNSS assisted
partial timing support (APTS) and other networking timing functions.
Current version provides kernel API's to support the following functions
-set combomode to enable SYNCE clock support
-read dpll's state to determine if the dpll is locked to the GNSS channel
-read dpll's ffo (fractional frequency offset) in ppqt
Signed-off-by: Min Li
---
Change log
-rebase change to linux-next tree
-remove uncessary condition checks suggested by Greg
-fix compile error for x86_64
drivers/misc/Kconfig | 9 ++
drivers/misc/Makefile | 2 +
drivers/misc/rsmu_cdev.c | 321 ++
drivers/misc/rsmu_cdev.h | 72 +++
drivers/misc/rsmu_cm.c| 166
drivers/misc/rsmu_sabre.c | 128 ++
include/uapi/linux/rsmu.h | 64 +
7 files changed, 762 insertions(+)
create mode 100644 drivers/misc/rsmu_cdev.c
create mode 100644 drivers/misc/rsmu_cdev.h
create mode 100644 drivers/misc/rsmu_cm.c
create mode 100644 drivers/misc/rsmu_sabre.c
create mode 100644 include/uapi/linux/rsmu.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index f532c59..49b523a 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -445,6 +445,15 @@ config HISI_HIKEY_USB
switching between the dual-role USB-C port and the USB-A host ports
using only one USB controller.
+config RSMU
+ tristate "Renesas Synchronization Management Unit (SMU)"
+ help
+ This option enables support for the IDT ClockMatrix(TM) and 82P33xxx
+ families of timing and synchronization devices. It will be used by
+ Renesas PTP Clock Manager for Linux (pcm4l) software to provide
support
+ for GNSS assisted partial timing support (APTS) and other networking
+ timing functions.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 99b6f15..21b8ed4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,5 @@ obj-$(CONFIG_HABANA_AI) += habanalabs/
obj-$(CONFIG_UACCE)+= uacce/
obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
+rsmu-objs := rsmu_cdev.o rsmu_cm.o rsmu_sabre.o
+obj-$(CONFIG_RSMU) += rsmu.o
diff --git a/drivers/misc/rsmu_cdev.c b/drivers/misc/rsmu_cdev.c
new file mode 100644
index 000..2df5788
--- /dev/null
+++ b/drivers/misc/rsmu_cdev.c
@@ -0,0 +1,321 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * This driver is developed for the IDT ClockMatrix(TM) and 82P33xxx families
+ * of timing and synchronization devices. It will be used by Renesas PTP Clock
+ * Manager for Linux (pcm4l) software to provide support to GNSS assisted
+ * partial timing support (APTS) and other networking timing functions.
+ *
+ * Please note it must work with Renesas MFD driver to access device through
+ * I2C/SPI.
+ *
+ * Copyright (C) 2019 Integrated Device Technology, Inc., a Renesas Company.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rsmu_cdev.h"
+
+#define DRIVER_NAME"rsmu"
+#define DRIVER_MAX_DEV BIT(MINORBITS)
+
+static struct class *rsmu_class;
+static dev_t rsmu_cdevt;
+static struct rsmu_ops *ops_array[] = {
+ [RSMU_CM] = _ops,
+ [RSMU_SABRE] = _ops,
+};
+
+static int
+rsmu_set_combomode(struct rsmu_cdev *rsmu, void __user *arg)
+{
+ struct rsmu_ops *ops = rsmu->ops;
+ struct rsmu_combomode mode;
+ int err;
+
+ if (copy_from_user(, arg, sizeof(mode)))
+ return -EFAULT;
+
+ if (ops->set_combomode == NULL)
+ return -ENOTSUPP;
+
+ mutex_lock(rsmu->lock);
+ err = ops->set_combomode(rsmu, mode.dpll, mode.mode);
+ mutex_unlock(rsmu->lock);
+
+ return err;
+}
+
+static int
+rsmu_get_dpll_state(struct rsmu_cdev *rsmu, void __user *arg)
+{
+ struct rsmu_ops *ops = rsmu->ops;
+ struct rsmu_get_state state_request;
+ u8 state;
+ int err;
+
+ if (copy_from_user(_request, arg, sizeof(state_request)))
+ return -EFAULT;
+
+ if (ops->get_dpll_state == NULL)
+ return -ENOTSUPP;
+
+ mutex_lock(rsmu->lock);
+ err = ops->get_dpll_state(rsmu, state_request.dpll, );
+ mutex_unlock(rsmu->lock);
+
+ state_request.state = state;
+ if (copy_to_user(arg, _request, sizeof(state_request)))
+ return -EFAULT;
+
+ return err;
+}
+
+static int
+rsmu_get_dpll_ffo(struct rsmu_cdev *rsmu,
RE: [PATCH next 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support
> > Then the patches are independant and they should be sent as such, > otherwise it causes confusion and our tools get messed up when trying to > grab the whole "series" of patches. > > Can you please fix this up and just send two independant patches? > Hi Greg These 2 patches are not independent. Patch 2/2 depends on patch 1/2 to build and work successfully. They just belong to different domain, patch 1/2 belongs to MFD while patch 2/2 belongs to MISC. That is why I wasn't sure if I should send both patches to you in the first place. Anyways, I just sent both patches again. Thanks Min
Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: core: add comma within a comment
On Sat, Apr 03, 2021 at 11:16:16PM +0200, Julia Lawall wrote: > > > On Sat, 3 Apr 2021, Deborah Brouwer wrote: > > > Add a comma to separate repeated words in a comment. The comma preserves > > the meaning of the comment while also stopping the checkpatch warning: > > WARNING: Possible repeated word: 'very'. > > Thanks. That is more understandable. Isn't this a v2? If so, there > should be v2 after PATCH and an explanation of the change under the --- > > julia Hi Julia, no this is not a v2. I found the same comment, generating the same error, in a different file. Since I changed it in rtl8723bs/core/rtw_xmit.c [1], I thought I should be consistent and change it here as well. [1] https://lore.kernel.org/r/2944d1a0e8769edb489bb336423625a61d314d05.1617229359.git.deborahbrouwer3...@gmail.com > > > > > > Signed-off-by: Deborah Brouwer > > --- > > drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c > > b/drivers/staging/rtl8188eu/core/rtw_xmit.c > > index ed81cbc5e191..99e44b2c6f36 100644 > > --- a/drivers/staging/rtl8188eu/core/rtw_xmit.c > > +++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c > > @@ -1243,7 +1243,7 @@ s32 rtw_free_xmitbuf(struct xmit_priv *pxmitpriv, > > struct xmit_buf *pxmitbuf) > > * If we turn on USE_RXTHREAD, then, no need for critical section. > > * Otherwise, we must use _enter/_exit critical to protect > > free_xmit_queue... > > * > > - * Must be very very cautious... > > + * Must be very, very cautious... > > * > > */ > > > > -- > > 2.17.1 > > > > -- > > You received this message because you are subscribed to the Google Groups > > "outreachy-kernel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to outreachy-kernel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/outreachy-kernel/20210403210930.17781-1-deborahbrouwer3563%40gmail.com. > >
Re: [PATCH 2/2] staging:r8188eu: remove dummy handlers from OnAction()
On 4/2/21 4:04 PM, Greg Kroah-Hartman wrote:
On Sun, Mar 28, 2021 at 07:33:25PM +0300, Ivan Safonov wrote:
on_action_spct() do nothing, because rtw_get_stainfo() has no side
effects. Other action handlers are trivial.
Signed-off-by: Ivan Safonov
Same here, wrong driver name :(
Driver name is "r8188eu"...
$ grep 'r8188eu' drivers/staging/rtl8188eu/include/drv_types.h
#define DRV_NAME "r8188eu"
$ grep 'r8188eu' drivers/staging/rtl8188eu/os_dep/usb_intf.c -B1 -A7
static struct usb_driver rtl8188e_usb_drv = {
.name = "r8188eu",
.probe = rtw_drv_init,
.disconnect = rtw_dev_remove,
.id_table = rtw_usb_id_tbl,
.suspend = rtw_suspend,
.resume = rtw_resume,
.reset_resume = rtw_resume,
};
$ cat drivers/staging/rtl8188eu/Kconfig
# SPDX-License-Identifier: GPL-2.0
config R8188EU
tristate "Realtek RTL8188EU Wireless LAN NIC driver"
depends on WLAN && USB && CFG80211
depends on m
select WIRELESS_EXT
select WEXT_PRIV
select LIB80211
select LIB80211_CRYPT_WEP
select LIB80211_CRYPT_CCMP
help
This option adds the Realtek RTL8188EU USB device such as
TP-Link TL-WN725N.
If built as a module, it will be called r8188eu.
if R8188EU
config 88EU_AP_MODE
bool "Realtek RTL8188EU AP mode"
default y
help
This option enables Access Point mode. Unless you know that
your system
will never be used as an AP, or the target system has limited
memory,
"Y" should be selected.
endif
[GIT PULL] OpenRISC fixes for 5.12-rc5
Hi Linus, Please consider for pull, The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3: Linux 5.12-rc5 (2021-03-28 15:48:16 -0700) are available in the Git repository at: git://github.com/openrisc/linux.git tags/for-linus for you to fetch changes up to 1683f7de65dbf0a2c6a7d639173fe92430a28930: soc: litex: Remove duplicated header file inclusion (2021-04-04 05:46:46 +0900) OpenRISC fix for 5.12 Includes: - Fix duplicate header include in Litex SOC driver Zhen Lei (1): soc: litex: Remove duplicated header file inclusion drivers/soc/litex/litex_soc_ctrl.c | 1 - 1 file changed, 1 deletion(-)
Re: [Outreachy kernel] [PATCH] staging: rtl8188eu: core: add comma within a comment
On Sat, 3 Apr 2021, Deborah Brouwer wrote: > Add a comma to separate repeated words in a comment. The comma preserves > the meaning of the comment while also stopping the checkpatch warning: > WARNING: Possible repeated word: 'very'. Thanks. That is more understandable. Isn't this a v2? If so, there should be v2 after PATCH and an explanation of the change under the --- julia > > Signed-off-by: Deborah Brouwer > --- > drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c > b/drivers/staging/rtl8188eu/core/rtw_xmit.c > index ed81cbc5e191..99e44b2c6f36 100644 > --- a/drivers/staging/rtl8188eu/core/rtw_xmit.c > +++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c > @@ -1243,7 +1243,7 @@ s32 rtw_free_xmitbuf(struct xmit_priv *pxmitpriv, > struct xmit_buf *pxmitbuf) > * If we turn on USE_RXTHREAD, then, no need for critical section. > * Otherwise, we must use _enter/_exit critical to protect free_xmit_queue... > * > - * Must be very very cautious... > + * Must be very, very cautious... > * > */ > > -- > 2.17.1 > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20210403210930.17781-1-deborahbrouwer3563%40gmail.com. >
[PATCH] staging: rtl8188eu: core: add comma within a comment
Add a comma to separate repeated words in a comment. The comma preserves the meaning of the comment while also stopping the checkpatch warning: WARNING: Possible repeated word: 'very'. Signed-off-by: Deborah Brouwer --- drivers/staging/rtl8188eu/core/rtw_xmit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c b/drivers/staging/rtl8188eu/core/rtw_xmit.c index ed81cbc5e191..99e44b2c6f36 100644 --- a/drivers/staging/rtl8188eu/core/rtw_xmit.c +++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c @@ -1243,7 +1243,7 @@ s32 rtw_free_xmitbuf(struct xmit_priv *pxmitpriv, struct xmit_buf *pxmitbuf) * If we turn on USE_RXTHREAD, then, no need for critical section. * Otherwise, we must use _enter/_exit critical to protect free_xmit_queue... * - * Must be very very cautious... + * Must be very, very cautious... * */ -- 2.17.1
drivers/memstick/host/r592.c:83:9: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8e29be3468d4565dd95fbb098df0d7a79ee60d71
commit: d4aa8affa1e9e51c237a1ec47a97e96dce76c98c m68knommu: fix use of
cpu_to_le() on IO access
date: 8 months ago
config: m68k-randconfig-s032-20210404 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-279-g6d5d9b42-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4aa8affa1e9e51c237a1ec47a97e96dce76c98c
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout d4aa8affa1e9e51c237a1ec47a97e96dce76c98c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/memstick/host/r592.c:47:12: sparse: sparse: symbol
'memstick_debug_get_tpc_name' was not declared. Should it be static?
>> drivers/memstick/host/r592.c:83:9: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned int volatile
>> [usertype] @@ got restricted __be32 [usertype] @@
drivers/memstick/host/r592.c:83:9: sparse: expected unsigned int
volatile [usertype]
drivers/memstick/host/r592.c:83:9: sparse: got restricted __be32
[usertype]
>> drivers/memstick/host/r592.c:83:9: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned int volatile
>> [usertype] @@ got restricted __be32 [usertype] @@
drivers/memstick/host/r592.c:83:9: sparse: expected unsigned int
volatile [usertype]
drivers/memstick/host/r592.c:83:9: sparse: got restricted __be32
[usertype]
>> drivers/memstick/host/r592.c:83:9: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned int volatile
>> [usertype] @@ got restricted __be32 [usertype] @@
drivers/memstick/host/r592.c:83:9: sparse: expected unsigned int
volatile [usertype]
drivers/memstick/host/r592.c:83:9: sparse: got restricted __be32
[usertype]
drivers/memstick/host/r592.c:75:16: sparse: sparse: cast to restricted __be32
drivers/memstick/host/r592.c:75:16: sparse: sparse: cast to restricted __be32
vim +83 drivers/memstick/host/r592.c
9263412501022f Maxim Levitsky 2011-03-25 77
9263412501022f Maxim Levitsky 2011-03-25 78 /* Writes a big endian DWORD
register */
9263412501022f Maxim Levitsky 2011-03-25 79 static inline void
r592_write_reg_raw_be(struct r592_device *dev,
9263412501022f Maxim Levitsky 2011-03-25 80
int address, u32 value)
9263412501022f Maxim Levitsky 2011-03-25 81 {
9263412501022f Maxim Levitsky 2011-03-25 82dbg_reg("reg #%02d <- 0x%08x",
address, value);
9263412501022f Maxim Levitsky 2011-03-25 @83
__raw_writel(cpu_to_be32(value), dev->mmio + address);
9263412501022f Maxim Levitsky 2011-03-25 84 }
9263412501022f Maxim Levitsky 2011-03-25 85
:: The code at line 83 was first introduced by commit
:: 9263412501022fecef844907129ee2513b5a89de memstick: add driver for Ricoh
R5C592 card reader
:: TO: Maxim Levitsky
:: CC: Linus Torvalds
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] soc: litex: Remove duplicated header file inclusion
On Wed, Mar 31, 2021 at 03:06:43PM +0200, Mateusz Holenko wrote: > From: Zhen Lei > > The header file is already included above and can be > removed here. > > Signed-off-by: Zhen Lei > Signed-off-by: Mateusz Holenko Thanks, I have staged this. -Stafford
Re: [PATCH] kfence: unpoison pool region before use
On Sat, Apr 3, 2021 at 3:03 AM Marco Elver wrote: > > On Sat, 3 Apr 2021 at 07:13, Peter Collingbourne wrote: > > If the memory region allocated by KFENCE had previously been poisoned, > > any validity checks done using kasan_byte_accessible() will fail. Fix > > it by unpoisoning the memory before using it as the pool region. > > > > Link: > > https://linux-review.googlesource.com/id/I0af99e9f1c25eaf7e1ec295836b5d148d76940c5 > > Signed-off-by: Peter Collingbourne > > Thanks, at a high level this seems reasonable, because we always want > to ensure that KFENCE memory remains unpoisoned with KASAN on. FWIW I > subjected a config with KFENCE+KASAN (generic, SW_TAGS, and HW_TAGS) > to syzkaller testing and ran kfence_test: > > Tested-by: Marco Elver > > > However, it is unclear to me under which circumstances we actually > need this, i.e. something would grab some memblock memory, somehow > poison it, and then release the memory back during early boot (note, > kfence_alloc_pool() is called before slab setup). If we can somehow > understand what actually did this, perhaps it'd help tell us if this > actually needs fixing in KFENCE or it's the other thing that needs a > fix. > > Given all this is happening during really early boot, I'd expect no or > very few calls to kasan_poison() until kfence_alloc_pool() is called. > We can probably debug it more by having kasan_poison() do a "if > (!__kfence_pool) dump_stack();" somewhere. Can you try this on the > system where you can repro the problem? I tried this just now on the > latest mainline kernel, and saw 0 calls until kfence_alloc_pool(). I looked into the issue some more, and it turned out that the memory wasn't getting poisoned by kasan_poison() but rather by the calls to kasan_map_populate() in kasan_init_shadow(). Starting with the patch "kasan: initialize shadow to TAG_INVALID for SW_TAGS", KASAN_SHADOW_INIT is set to 0xFE rather than 0xFF, which caused the failure. The Android kernel branch for 5.10 (and the downstream kernel I was working with) already have this patch, but it isn't in the mainline kernel yet. Now that I understand the cause of the issue, I can reproduce it using the KFENCE unit tests on a db845c board, using both the Android 5.10 and mainline branches if I cherry-pick that change. Here's an example crash from the unit tests (the failure was originally also observed from ksize in the downstream kernel): [ 46.692195][ T175] BUG: KASAN: invalid-access in test_krealloc+0x1c4/0xf98 [ 46.699282][ T175] Read of size 1 at addr ff80e9e7b000 by task kunit_try_catch/175 [ 46.707400][ T175] Pointer tag: [ff], memory tag: [fe] [ 46.712710][ T175] [ 46.714955][ T175] CPU: 4 PID: 175 Comm: kunit_try_catch Tainted: GB 5.12.0-rc5-mainline-09505-ga2ab5b26d445-dirty #1 [ 46.727193][ T175] Hardware name: Thundercomm Dragonboard 845c (DT) [ 46.733636][ T175] Call trace: [ 46.736841][ T175] dump_backtrace+0x0/0x2f8 [ 46.741295][ T175] show_stack+0x2c/0x3c [ 46.745388][ T175] dump_stack+0x124/0x1bc [ 46.749668][ T175] print_address_description+0x7c/0x308 [ 46.755178][ T175] __kasan_report+0x1a8/0x398 [ 46.759816][ T175] kasan_report+0x50/0x7c [ 46.764103][ T175] __kasan_check_byte+0x3c/0x54 [ 46.768916][ T175] ksize+0x4c/0x94 [ 46.772573][ T175] test_krealloc+0x1c4/0xf98 [ 46.777108][ T175] kunit_try_run_case+0x94/0x1c4 [ 46.781990][ T175] kunit_generic_run_threadfn_adapter+0x30/0x44 [ 46.788196][ T175] kthread+0x20c/0x234 [ 46.792213][ T175] ret_from_fork+0x10/0x30 Since "kasan: initialize shadow to TAG_INVALID for SW_TAGS" hasn't landed in mainline yet, it seems like we should insert this patch before that one rather than adding a Fixes: tag. Peter
Re: [PATCH v3 00/30] staging: rtl8723bs: remove RT_TRACE logs in core/*
On Sat, 2021-04-03 at 19:28 +0200, Fabio Aiuto wrote: > On Sat, Apr 03, 2021 at 09:17:37AM -0700, Joe Perches wrote: > > On Sat, 2021-04-03 at 17:21 +0200, Fabio Aiuto wrote: > > > On Sat, Apr 03, 2021 at 08:02:25AM -0700, Joe Perches wrote: > > > > On Sat, 2021-04-03 at 11:13 +0200, Fabio Aiuto wrote: > > > > > This patchset removes all RT_TRACE usages in core/ files. > > > > > > > > and hal and include and os_dep > > > > > > Hi, > > > > > > I was just about to send the second patchset relative to hal/ files. > > > The whole has been split up in directories in order to reduce the > > > number of patch per patchset > > > > > It's a good idea, but the patches relative to RT_TRACE removal > > > could be huge > > > > That's really not a significant issue. > > Simplicity in review is also important. > > Mechanization of patch creation can reduce review efforts. > > Maybe I wrongly associated simplicity with patch dimensions, but maybe > for patches this simple have expert reviewers some tool for > automatic review? Coccinelle is a relatively trusted tool and using it as a scripting mechanism where the script is shown as part of the commit message gives confidence that the change it produces can be applied without significant doubt. To improve confidence that any change that does not have an output object code delta, comparing the object code produced before and after the change is useful. Showing that the code has been both compiled and compared in the commit message also improves confidence that the change is useful and can be applied.
RE: [PATCH][next] scsi: ufs: Fix out-of-bounds warnings in ufshcd_exec_raw_upiu_cmd
> > Fix the following out-of-bounds warnings by enclosing > some structure members into new structure objects upiu_req > and upiu_rsp: > > include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [29, > 48] from the object at 'treq' is out of the bounds of referenced subobject > 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] > include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [61, > 80] from the object at 'treq' is out of the bounds of referenced subobject > 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] > arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset > [29, 48] from the object at 'treq' is out of the bounds of referenced > subobject > 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds] > arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset > [61, 80] from the object at 'treq' is out of the bounds of referenced > subobject > 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds] > > Refactor the code by making it more structured. > > The problem is that the original code is trying to copy data into a > bunch of struct members adjacent to each other in a single call to > memcpy(). Now that a new struct _upiu_req_ enclosing all those adjacent > members is introduced, memcpy() doesn't overrun the length of > _header, because the address of the new struct object > _upiu_req_ is used as the destination, instead. The same problem > is present when memcpy() overruns the length of the source > _header; in this case the address of the new struct > object _upiu_rsp_ is used, instead. > > Also, this helps with the ongoing efforts to enable -Warray-bounds > and avoid confusing the compiler. > > Link: https://github.com/KSPP/linux/issues/109 > Reported-by: kernel test robot > Build-tested-by: kernel test robot > Link: > https://lore.kernel.org/lkml/60640558.lsaxik6otpwto9rv%25...@intel.com/ > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Avri Altman Thanks, Avri > --- > drivers/scsi/ufs/ufshcd.c | 28 > drivers/scsi/ufs/ufshci.h | 22 +- > 2 files changed, 29 insertions(+), 21 deletions(-) > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > index 7539a4ee9494..324eb641e66f 100644 > --- a/drivers/scsi/ufs/ufshcd.c > +++ b/drivers/scsi/ufs/ufshcd.c > @@ -336,11 +336,15 @@ static void ufshcd_add_tm_upiu_trace(struct > ufs_hba *hba, unsigned int tag, > return; > > if (str_t == UFS_TM_SEND) > - trace_ufshcd_upiu(dev_name(hba->dev), str_t, > >req_header, > - >input_param1, UFS_TSF_TM_INPUT); > + trace_ufshcd_upiu(dev_name(hba->dev), str_t, > + >upiu_req.req_header, > + >upiu_req.input_param1, > + UFS_TSF_TM_INPUT); > else > - trace_ufshcd_upiu(dev_name(hba->dev), str_t, > >rsp_header, > - >output_param1, UFS_TSF_TM_OUTPUT); > + trace_ufshcd_upiu(dev_name(hba->dev), str_t, > + >upiu_rsp.rsp_header, > + >upiu_rsp.output_param1, > + UFS_TSF_TM_OUTPUT); > } > > static void ufshcd_add_uic_command_trace(struct ufs_hba *hba, > @@ -6420,7 +6424,7 @@ static int __ufshcd_issue_tm_cmd(struct ufs_hba > *hba, > spin_lock_irqsave(host->host_lock, flags); > task_tag = hba->nutrs + free_slot; > > - treq->req_header.dword_0 |= cpu_to_be32(task_tag); > + treq->upiu_req.req_header.dword_0 |= cpu_to_be32(task_tag); > > memcpy(hba->utmrdl_base_addr + free_slot, treq, sizeof(*treq)); > ufshcd_vops_setup_task_mgmt(hba, free_slot, tm_function); > @@ -6493,16 +6497,16 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba > *hba, int lun_id, int task_id, > treq.header.dword_2 = cpu_to_le32(OCS_INVALID_COMMAND_STATUS); > > /* Configure task request UPIU */ > - treq.req_header.dword_0 = cpu_to_be32(lun_id << 8) | > + treq.upiu_req.req_header.dword_0 = cpu_to_be32(lun_id << 8) | > cpu_to_be32(UPIU_TRANSACTION_TASK_REQ << > 24); > - treq.req_header.dword_1 = cpu_to_be32(tm_function << 16); > + treq.upiu_req.req_header.dword_1 = cpu_to_be32(tm_function << 16); > > /* > * The host shall provide the same value for LUN field in the basic > * header and for Input Parameter. > */ > - treq.input_param1 = cpu_to_be32(lun_id); > - treq.input_param2 = cpu_to_be32(task_id); > + treq.upiu_req.input_param1 = cpu_to_be32(lun_id); > + treq.upiu_req.input_param2 = cpu_to_be32(task_id); > > err = __ufshcd_issue_tm_cmd(hba, , tm_function); > if (err ==
Re: [PATCH] net: initialize local variables in net/ipv6/mcast.c and net/ipv4/igmp.c
On Fri, Apr 02, 2021 at 11:12:36PM +0200, Eric Dumazet wrote: > > > On 4/2/21 10:53 PM, Eric Dumazet wrote: > > > > > > On 4/2/21 8:10 PM, Phillip Potter wrote: > >> On Fri, Apr 02, 2021 at 07:49:44PM +0200, Eric Dumazet wrote: > >>> > >>> > >>> On 4/2/21 7:36 PM, Phillip Potter wrote: > Use memset to initialize two local buffers in net/ipv6/mcast.c, > and another in net/ipv4/igmp.c. Fixes a KMSAN found uninit-value > bug reported by syzbot at: > https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51 > >>> > >>> > >>> According to this link, the bug no longer triggers. > >>> > >>> Please explain why you think it is still there. > >>> > >> > >> Dear Eric, > >> > >> It definitely still triggers, tested it on the master branch of > >> https://github.com/google/kmsan last night. The patch which fixes the > >> crash on that page is the same patch I've sent in. > > > > Please send the full report (stack trace) > > I think your patch just silences the real problem. > > The issue at hand is that TUNSETLINK changes dev->type without making > any change to dev->addr_len > > This is the real issue. > > If you care about this, please fix tun driver. > Dear Eric, Thank you for pointing me in the right direction. I will do as you suggest. Regards, Phil
Re: [GIT PULL] RISC-V Fixes for 5.12-rc6
The pull request you sent on Sat, 03 Apr 2021 11:39:36 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git > tags/riscv-for-linus-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7fd7d5c20129d2227b95cbe567b24559f144b77c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] gfs2 fixes for v5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 19:19:14 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git > tags/gfs2-v5.12-rc2-fixes2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/8e29be3468d4565dd95fbb098df0d7a79ee60d71 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [syzbot] possible deadlock in ovl_maybe_copy_up
syzbot has found a reproducer for the following issue on:
HEAD commit:454c576c Add linux-next specific files for 20210401
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1616e07ed0
kernel config: https://syzkaller.appspot.com/x/.config?x=920cc274cae812a5
dashboard link: https://syzkaller.appspot.com/bug?extid=c18f2f6a7b08c51e3025
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13da365ed0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13ca9d16d0
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c18f2f6a7b08c51e3...@syzkaller.appspotmail.com
==
WARNING: possible circular locking dependency detected
5.12.0-rc5-next-20210401-syzkaller #0 Not tainted
--
syz-executor144/9166 is trying to acquire lock:
888144cf0460 (sb_writers#5){.+.+}-{0:0}, at: ovl_maybe_copy_up+0x11f/0x190
fs/overlayfs/copy_up.c:995
but task is already holding lock:
8880256d42c0 (>mutex){+.+.}-{3:3}, at:
process_measurement+0x3a8/0x17e0 security/integrity/ima/ima_main.c:253
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (>mutex){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:949 [inline]
__mutex_lock+0x139/0x1120 kernel/locking/mutex.c:1096
process_measurement+0x3a8/0x17e0 security/integrity/ima/ima_main.c:253
ima_file_check+0xb9/0x100 security/integrity/ima/ima_main.c:499
do_open fs/namei.c:3361 [inline]
path_openat+0x15b5/0x27e0 fs/namei.c:3492
do_filp_open+0x17e/0x3c0 fs/namei.c:3519
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_open fs/open.c:1211 [inline]
__se_sys_open fs/open.c:1207 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1207
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
-> #0 (sb_writers#5){.+.+}-{0:0}:
check_prev_add kernel/locking/lockdep.c:2938 [inline]
check_prevs_add kernel/locking/lockdep.c:3061 [inline]
validate_chain kernel/locking/lockdep.c:3676 [inline]
__lock_acquire+0x2a17/0x5230 kernel/locking/lockdep.c:4902
lock_acquire kernel/locking/lockdep.c:5512 [inline]
lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5477
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1758 [inline]
sb_start_write include/linux/fs.h:1828 [inline]
mnt_want_write+0x6e/0x3e0 fs/namespace.c:375
ovl_maybe_copy_up+0x11f/0x190 fs/overlayfs/copy_up.c:995
ovl_open+0xba/0x270 fs/overlayfs/file.c:149
do_dentry_open+0x4b9/0x11b0 fs/open.c:826
vfs_open fs/open.c:940 [inline]
dentry_open+0x132/0x1d0 fs/open.c:956
ima_calc_file_hash+0x2d2/0x4b0 security/integrity/ima/ima_crypto.c:557
ima_collect_measurement+0x4ca/0x570 security/integrity/ima/ima_api.c:252
process_measurement+0xd1c/0x17e0 security/integrity/ima/ima_main.c:330
ima_file_check+0xb9/0x100 security/integrity/ima/ima_main.c:499
do_open fs/namei.c:3361 [inline]
path_openat+0x15b5/0x27e0 fs/namei.c:3492
do_filp_open+0x17e/0x3c0 fs/namei.c:3519
do_sys_openat2+0x16d/0x420 fs/open.c:1187
do_sys_open fs/open.c:1203 [inline]
__do_sys_open fs/open.c:1211 [inline]
__se_sys_open fs/open.c:1207 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1207
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(>mutex);
lock(sb_writers#5);
lock(>mutex);
lock(sb_writers#5);
*** DEADLOCK ***
1 lock held by syz-executor144/9166:
#0: 8880256d42c0 (>mutex){+.+.}-{3:3}, at:
process_measurement+0x3a8/0x17e0 security/integrity/ima/ima_main.c:253
stack backtrace:
CPU: 1 PID: 9166 Comm: syz-executor144 Not tainted
5.12.0-rc5-next-20210401-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
check_noncircular+0x25f/0x2e0 kernel/locking/lockdep.c:2129
check_prev_add kernel/locking/lockdep.c:2938 [inline]
check_prevs_add kernel/locking/lockdep.c:3061 [inline]
validate_chain kernel/locking/lockdep.c:3676 [inline]
__lock_acquire+0x2a17/0x5230 kernel/locking/lockdep.c:4902
lock_acquire kernel/locking/lockdep.c:5512 [inline]
lock_acquire+0x1ab/0x740 kernel/locking/lockdep.c:5477
percpu_down_read include/linux/percpu-rwsem.h:51 [inline]
__sb_start_write include/linux/fs.h:1758
[syzbot] WARNING: suspicious RCU usage in copy_pte_range
Hello,
syzbot found the following issue on:
HEAD commit:1e43c377 Merge tag 'xtensa-20210329' of git://github.com/j..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15604986d0
kernel config: https://syzkaller.appspot.com/x/.config?x=71a75beb62b62a34
dashboard link: https://syzkaller.appspot.com/bug?extid=c2d2a6e2af34adb88749
compiler: Debian clang version 11.0.1-2
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c2d2a6e2af34adb88...@syzkaller.appspotmail.com
=
WARNING: suspicious RCU usage
5.12.0-rc5-syzkaller #0 Not tainted
-
kernel/sched/core.c:8294 Illegal context switch in RCU-sched read-side critical
section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
3 locks held by syz-executor.2/8400:
#0: 8c796770 (dup_mmap_sem){.+.+}-{0:0}, at: dup_mmap+0x73/0xde0
kernel/fork.c:479
#1: 8880286c0158 (>mmap_lock#2){}-{3:3}, at:
mmap_write_lock_killable include/linux/mmap_lock.h:87 [inline]
#1: 8880286c0158 (>mmap_lock#2){}-{3:3}, at: dup_mmap+0x87/0xde0
kernel/fork.c:480
#2: 8880286c2458 (>mmap_lock/1){+.+.}-{3:3}, at:
mmap_write_lock_nested include/linux/mmap_lock.h:78 [inline]
#2: 8880286c2458 (>mmap_lock/1){+.+.}-{3:3}, at: dup_mmap+0xd1/0xde0
kernel/fork.c:489
stack backtrace:
CPU: 1 PID: 8400 Comm: syz-executor.2 Not tainted 5.12.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x176/0x24e lib/dump_stack.c:120
___might_sleep+0xb4/0x530 kernel/sched/core.c:8294
copy_pte_range+0x255b/0x2a20 mm/memory.c:1010
copy_pmd_range mm/memory.c:1064 [inline]
copy_pud_range mm/memory.c:1101 [inline]
copy_p4d_range mm/memory.c:1125 [inline]
copy_page_range+0xba9/0xff0 mm/memory.c:1198
dup_mmap+0x9aa/0xde0 kernel/fork.c:594
dup_mm+0x8c/0x310 kernel/fork.c:1368
copy_mm kernel/fork.c:1424 [inline]
copy_process+0x24c1/0x5690 kernel/fork.c:2113
kernel_clone+0x1a6/0x6c0 kernel/fork.c:2500
__do_sys_clone kernel/fork.c:2617 [inline]
__se_sys_clone kernel/fork.c:2601 [inline]
__x64_sys_clone+0x1d5/0x220 kernel/fork.c:2601
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x464a4b
Code: ed 0f 85 60 01 00 00 64 4c 8b 0c 25 10 00 00 00 45 31 c0 4d 8d 91 d0 02
00 00 31 d2 31 f6 bf 11 00 20 01 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87
89 00 00 00 41 89 c5 85 c0 0f 85 90 00 00
RSP: 002b:7ffc64260880 EFLAGS: 0246 ORIG_RAX: 0038
RAX: ffda RBX: RCX: 00464a4b
RDX: RSI: RDI: 01200011
RBP: 0001 R08: R09: 03070400
R10: 030706d0 R11: 0246 R12: 0001
R13: R14: 0001 R15: 7ffc64260970
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[GIT PULL] RISC-V Fixes for 5.12-rc6
The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3: Linux 5.12-rc5 (2021-03-28 15:48:16 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-5.12-rc6 for you to fetch changes up to 1adbc2941eee8acbe3c7dc6b51cdbc5a9bf19565: riscv: Make NUMA depend on MMU (2021-04-01 21:37:08 -0700) RISC-V Fixes for 5.12-rc6 I have a handful of fixes for 5.12: * A fix for a stack tracing regression related to "const register asm" variables, which have unexpected behavior. * A fix to put_user() that ensures the value to be written is evaluated before enabling access to userspace memory.. * A fix to align the exception vector table correctly, so we don't rely on the firmware's handling of unaligned accesses. * A build fix to make NUMA depend on MMU, which triggers some randconfigs. Ben Dooks (1): riscv: evaluate put_user() arg before enabling user access Kefeng Wang (2): riscv: Drop const annotation for sp riscv: Make NUMA depend on MMU Yang Li (1): riscv: remove unneeded semicolon Zihao Yu (1): riscv,entry: fix misaligned base for excp_vect_table arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/uaccess.h | 7 +-- arch/riscv/kernel/entry.S| 1 + arch/riscv/kernel/stacktrace.c | 2 +- arch/riscv/mm/kasan_init.c | 2 +- 5 files changed, 9 insertions(+), 5 deletions(-)
Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception
On Thu, 1 Apr 2021, Masami Hiramatsu wrote: > > > > Current riscv's kprobe handlers are run with both preemption and > > > > interrupt enabled, this violates kprobe requirements. Fix this issue > > > > by keeping interrupts disabled for BREAKPOINT exception. > > > > > > Not only while the breakpoint exception but also until the end of > > > the single step (maybe you are using __BUG_INSN_32 ??) need to be > > > disable interrupts. Can this do that? > > > > > > > interrupt is disabled during "single step" by kprobes_save_local_irqflag() > > and kprobes_restore_local_irqflag(). The code flow looks like: > > > > do_trap_break() // for bp > > kprobe_breakpoint_handler() > > setup_singlestep() > > kprobes_restore_local_irqflag() > > > > do_trap_break() // for ss > > kprobe_single_step_handler() > > kprobes_restore_local_irqflag() > > OK, thanks for the confirmation! Is this approach guaranteed to keep interrupt handling latency low enough for the system not to be negatively affected, e.g. for the purpose of NTP timekeeping? Maciej
Re: [PATCH] apparmor: avoid -Wempty-body warning
On 3/22/21 4:00 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with 'make W=1' shows a warning for an empty macro:
>
> security/apparmor/label.c: In function '__label_update':
> security/apparmor/label.c:2096:59: error: suggest braces around empty body in
> an 'else' statement [-Werror=empty-body]
> 2096 | AA_BUG(labels_ns(label) != labels_ns(new));
>
> Change the macro defintion to use no_printk(), which improves
> format string checking and avoids the warning.
>
> Signed-off-by: Arnd Bergmann
Aked-by: John Johansen
I have pulled it into the apparmor tree
> ---
> security/apparmor/include/lib.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/apparmor/include/lib.h b/security/apparmor/include/lib.h
> index 7d27db740bc2..67fbb81a11f3 100644
> --- a/security/apparmor/include/lib.h
> +++ b/security/apparmor/include/lib.h
> @@ -36,7 +36,7 @@
> #define AA_BUG_FMT(X, fmt, args...) \
> WARN((X), "AppArmor WARN %s: (" #X "): " fmt, __func__, ##args)
> #else
> -#define AA_BUG_FMT(X, fmt, args...)
> +#define AA_BUG_FMT(X, fmt, args...) no_printk(fmt, ##args)
> #endif
>
> #define AA_ERROR(fmt, args...)
> \
>
Re: [GIT PULL] Char/Misc driver fixes for 5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 12:52:14 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > tags/char-misc-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a443930a3e8eaf70c8768cc2c923d1d85b71262f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Driver core fix for 5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 12:51:54 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > tags/driver-core-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f5664825fc2055ed9a0e4988cfc3aeb199dce520 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Hyper-V fixes for 5.12-rc6
The pull request you sent on Fri, 2 Apr 2021 21:55:33 +: > ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git > tags/hyperv-fixes-signed-20210402 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/fa16199500c8863da145870f01d61617d967b6c3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Staging driver fix for 5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 12:51:29 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > tags/staging-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3e707eb6b8aa715847c17279f9c17c8dca2d639b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Serial driver fix for 5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 12:51:02 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git tags/tty-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0d2c5a9e15179806fd9ff24409d2c0d689fc422f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] USB driver fixes for 5.12-rc6
The pull request you sent on Sat, 3 Apr 2021 12:50:29 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.12-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/de879a8d37ff86b8111f94a64fc82c81c189 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.12-5 tag
The pull request you sent on Sat, 03 Apr 2021 22:48:02 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.12-5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9c2ef23e4dae122d2b18e834d90f8bd4dda48fe6 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH 6/7] staging: media: zoran: Rename 'We' to 'we'
Rename variable 'We' to 'we' to eliminate camelcase. Reported by checkpatch.pl. Signed-off-by: Zhansaya Bagdauletkyzy --- drivers/staging/media/zoran/zoran_device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/zoran/zoran_device.c b/drivers/staging/media/zoran/zoran_device.c index 49e0efcc0062..007d8855178e 100644 --- a/drivers/staging/media/zoran/zoran_device.c +++ b/drivers/staging/media/zoran/zoran_device.c @@ -295,7 +295,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, unsigned int disp_mode; unsigned int vid_win_wid, vid_win_ht; unsigned int hcrop1, hcrop2, vcrop1, vcrop2; - unsigned int wa, We, ha, He; + unsigned int wa, we, ha, He; unsigned int X, Y, hor_dcm, ver_dcm; u32 reg; @@ -318,10 +318,10 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, /* horizontal */ vid_win_wid = video_width; X = DIV_ROUND_UP(vid_win_wid * 64, tvn->wa); - We = (vid_win_wid * 64) / X; + we = (vid_win_wid * 64) / X; hor_dcm = 64 - X; - hcrop1 = 2 * ((tvn->wa - We) / 4); - hcrop2 = tvn->wa - We - hcrop1; + hcrop1 = 2 * ((tvn->wa - we) / 4); + hcrop2 = tvn->wa - we - hcrop1; h_start = tvn->h_start ? tvn->h_start : 1; /* (Ronald) Original comment: * "| 1 Doesn't have any effect, tested on both a DC10 and a DC10+" -- 2.25.1
[PATCH 7/7] staging: media: zoran: Rename 'He' to 'he'
Rename variable 'He' to 'he' to eliminate camelcase. Reported by checkpatch.pl. Signed-off-by: Zhansaya Bagdauletkyzy --- drivers/staging/media/zoran/zoran_device.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/zoran/zoran_device.c b/drivers/staging/media/zoran/zoran_device.c index 007d8855178e..cf788d9cd1df 100644 --- a/drivers/staging/media/zoran/zoran_device.c +++ b/drivers/staging/media/zoran/zoran_device.c @@ -295,7 +295,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, unsigned int disp_mode; unsigned int vid_win_wid, vid_win_ht; unsigned int hcrop1, hcrop2, vcrop1, vcrop2; - unsigned int wa, we, ha, He; + unsigned int wa, we, ha, he; unsigned int X, Y, hor_dcm, ver_dcm; u32 reg; @@ -344,10 +344,10 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, disp_mode = !(video_height > BUZ_MAX_HEIGHT / 2); vid_win_ht = disp_mode ? video_height : video_height / 2; Y = DIV_ROUND_UP(vid_win_ht * 64 * 2, tvn->ha); - He = (vid_win_ht * 64) / Y; + he = (vid_win_ht * 64) / Y; ver_dcm = 64 - Y; - vcrop1 = (tvn->ha / 2 - He) / 2; - vcrop2 = tvn->ha / 2 - He - vcrop1; + vcrop1 = (tvn->ha / 2 - he) / 2; + vcrop2 = tvn->ha / 2 - he - vcrop1; v_start = tvn->v_start; v_end = v_start + tvn->ha / 2; // - 1; FIXME SnapShot times out with -1 in 768*576 on the DC10 - LP v_start += vcrop1; -- 2.25.1
[PATCH 5/7] staging: media: zoran: Rename 'VidWinHt' to 'vid_win_ht'
Rename 'VidWinHt' to 'vid_win_ht' to eliminate camelcase. Reported by checkpatch.pl. Signed-off-by: Zhansaya Bagdauletkyzy --- drivers/staging/media/zoran/zoran_device.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/zoran/zoran_device.c b/drivers/staging/media/zoran/zoran_device.c index f0344f4a4727..49e0efcc0062 100644 --- a/drivers/staging/media/zoran/zoran_device.c +++ b/drivers/staging/media/zoran/zoran_device.c @@ -293,7 +293,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, const struct tvnorm *tvn; unsigned int h_start, h_end, v_start, v_end; unsigned int disp_mode; - unsigned int vid_win_wid, VidWinHt; + unsigned int vid_win_wid, vid_win_ht; unsigned int hcrop1, hcrop2, vcrop1, vcrop2; unsigned int wa, We, ha, He; unsigned int X, Y, hor_dcm, ver_dcm; @@ -342,9 +342,9 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, /* Vertical */ disp_mode = !(video_height > BUZ_MAX_HEIGHT / 2); - VidWinHt = disp_mode ? video_height : video_height / 2; - Y = DIV_ROUND_UP(VidWinHt * 64 * 2, tvn->ha); - He = (VidWinHt * 64) / Y; + vid_win_ht = disp_mode ? video_height : video_height / 2; + Y = DIV_ROUND_UP(vid_win_ht * 64 * 2, tvn->ha); + He = (vid_win_ht * 64) / Y; ver_dcm = 64 - Y; vcrop1 = (tvn->ha / 2 - He) / 2; vcrop2 = tvn->ha / 2 - He - vcrop1; @@ -383,7 +383,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, /* display configuration */ reg = (16 << ZR36057_VDCR_MIN_PIX) - | (VidWinHt << ZR36057_VDCR_VID_WIN_HT) + | (vid_win_ht << ZR36057_VDCR_VID_WIN_HT) | (vid_win_wid << ZR36057_VDCR_VID_WIN_WID); if (pci_pci_problems & PCIPCI_TRITON) // || zr->revision < 1) // Revision 1 has also Triton support -- 2.25.1
[PATCH 3/7] staging: media: zoran: Rename 'DispMode' to 'disp_mode'
Rename variable 'DispMode' to 'disp_mode' to eliminate camelcase.
Reported by checkpatch.pl.
Signed-off-by: Zhansaya Bagdauletkyzy
---
drivers/staging/media/zoran/zoran_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/zoran/zoran_device.c
b/drivers/staging/media/zoran/zoran_device.c
index 6764b51fc595..8891f11f6276 100644
--- a/drivers/staging/media/zoran/zoran_device.c
+++ b/drivers/staging/media/zoran/zoran_device.c
@@ -292,7 +292,7 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
{
const struct tvnorm *tvn;
unsigned int h_start, h_end, v_start, v_end;
- unsigned int DispMode;
+ unsigned int disp_mode;
unsigned int VidWinWid, VidWinHt;
unsigned int hcrop1, hcrop2, vcrop1, vcrop2;
unsigned int wa, We, ha, He;
@@ -341,8 +341,8 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
btwrite(reg, ZR36057_VFEHCR);
/* Vertical */
- DispMode = !(video_height > BUZ_MAX_HEIGHT / 2);
- VidWinHt = DispMode ? video_height : video_height / 2;
+ disp_mode = !(video_height > BUZ_MAX_HEIGHT / 2);
+ VidWinHt = disp_mode ? video_height : video_height / 2;
Y = DIV_ROUND_UP(VidWinHt * 64 * 2, tvn->ha);
He = (VidWinHt * 64) / Y;
ver_dcm = 64 - Y;
@@ -362,7 +362,7 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
reg = 0;
reg |= (hor_dcm << ZR36057_VFESPFR_HOR_DCM);
reg |= (ver_dcm << ZR36057_VFESPFR_VER_DCM);
- reg |= (DispMode << ZR36057_VFESPFR_DISP_MODE);
+ reg |= (disp_mode << ZR36057_VFESPFR_DISP_MODE);
/* RJ: I don't know, why the following has to be the opposite
* of the corresponding ZR36060 setting, but only this way
* we get the correct colors when uncompressing to the screen */
--
2.25.1
[PATCH 4/7] staging: media: zoran: Rename 'VidWinWid' to 'vid_win_wid'
Rename variable 'VidWinWid' to 'vid_win_wid' to eliminate camelcase. Reported by checkpatch.pl. Signed-off-by: Zhansaya Bagdauletkyzy --- drivers/staging/media/zoran/zoran_device.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/zoran/zoran_device.c b/drivers/staging/media/zoran/zoran_device.c index 8891f11f6276..f0344f4a4727 100644 --- a/drivers/staging/media/zoran/zoran_device.c +++ b/drivers/staging/media/zoran/zoran_device.c @@ -293,7 +293,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, const struct tvnorm *tvn; unsigned int h_start, h_end, v_start, v_end; unsigned int disp_mode; - unsigned int VidWinWid, VidWinHt; + unsigned int vid_win_wid, VidWinHt; unsigned int hcrop1, hcrop2, vcrop1, vcrop2; unsigned int wa, We, ha, He; unsigned int X, Y, hor_dcm, ver_dcm; @@ -316,9 +316,9 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, / zr36057 / /* horizontal */ - VidWinWid = video_width; - X = DIV_ROUND_UP(VidWinWid * 64, tvn->wa); - We = (VidWinWid * 64) / X; + vid_win_wid = video_width; + X = DIV_ROUND_UP(vid_win_wid * 64, tvn->wa); + We = (vid_win_wid * 64) / X; hor_dcm = 64 - X; hcrop1 = 2 * ((tvn->wa - We) / 4); hcrop2 = tvn->wa - We - hcrop1; @@ -384,7 +384,7 @@ static void zr36057_set_vfe(struct zoran *zr, int video_width, int video_height, /* display configuration */ reg = (16 << ZR36057_VDCR_MIN_PIX) | (VidWinHt << ZR36057_VDCR_VID_WIN_HT) - | (VidWinWid << ZR36057_VDCR_VID_WIN_WID); + | (vid_win_wid << ZR36057_VDCR_VID_WIN_WID); if (pci_pci_problems & PCIPCI_TRITON) // || zr->revision < 1) // Revision 1 has also Triton support reg &= ~ZR36057_VDCR_TRITON; -- 2.25.1
[PATCH 1/7] staging: media: zoran: Rename 'HEnd' to 'h_end'
Rename variable 'HEnd' to 'h_end' to eliminate camelcase
Reported by checkpatch.pl.
Signed-off-by: Zhansaya Bagdauletkyzy
---
drivers/staging/media/zoran/zoran_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/zoran/zoran_device.c
b/drivers/staging/media/zoran/zoran_device.c
index e569a1341d01..415b3cf4826e 100644
--- a/drivers/staging/media/zoran/zoran_device.c
+++ b/drivers/staging/media/zoran/zoran_device.c
@@ -291,7 +291,7 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
const struct zoran_format *format)
{
const struct tvnorm *tvn;
- unsigned int h_start, HEnd, v_start, VEnd;
+ unsigned int h_start, h_end, v_start, VEnd;
unsigned int DispMode;
unsigned int VidWinWid, VidWinHt;
unsigned int hcrop1, hcrop2, vcrop1, vcrop2;
@@ -331,11 +331,11 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
* However, the DC10 has '0' as h_start, but does need |1, so we
* use a dirty check...
*/
- HEnd = h_start + tvn->wa - 1;
+ h_end = h_start + tvn->wa - 1;
h_start += hcrop1;
- HEnd -= hcrop2;
+ h_end -= hcrop2;
reg = ((h_start & ZR36057_VFEHCR_HMASK) << ZR36057_VFEHCR_H_START)
- | ((HEnd & ZR36057_VFEHCR_HMASK) << ZR36057_VFEHCR_H_END);
+ | ((h_end & ZR36057_VFEHCR_HMASK) << ZR36057_VFEHCR_H_END);
if (zr->card.vfe_pol.hsync_pol)
reg |= ZR36057_VFEHCR_HS_POL;
btwrite(reg, ZR36057_VFEHCR);
--
2.25.1
[PATCH 2/7] staging: media: zoran: Rename 'VEnd' to 'v_end'
Rename variable 'VEnd' to 'v_end' to eliminate camelcase.
Reported by checkpatch.pl.
Signed-off-by: Zhansaya Bagdauletkyzy
---
drivers/staging/media/zoran/zoran_device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/zoran/zoran_device.c
b/drivers/staging/media/zoran/zoran_device.c
index 415b3cf4826e..6764b51fc595 100644
--- a/drivers/staging/media/zoran/zoran_device.c
+++ b/drivers/staging/media/zoran/zoran_device.c
@@ -291,7 +291,7 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
const struct zoran_format *format)
{
const struct tvnorm *tvn;
- unsigned int h_start, h_end, v_start, VEnd;
+ unsigned int h_start, h_end, v_start, v_end;
unsigned int DispMode;
unsigned int VidWinWid, VidWinHt;
unsigned int hcrop1, hcrop2, vcrop1, vcrop2;
@@ -349,11 +349,11 @@ static void zr36057_set_vfe(struct zoran *zr, int
video_width, int video_height,
vcrop1 = (tvn->ha / 2 - He) / 2;
vcrop2 = tvn->ha / 2 - He - vcrop1;
v_start = tvn->v_start;
- VEnd = v_start + tvn->ha / 2; // - 1; FIXME SnapShot times out with
-1 in 768*576 on the DC10 - LP
+ v_end = v_start + tvn->ha / 2; // - 1; FIXME SnapShot times out with
-1 in 768*576 on the DC10 - LP
v_start += vcrop1;
- VEnd -= vcrop2;
+ v_end -= vcrop2;
reg = ((v_start & ZR36057_VFEVCR_VMASK) << ZR36057_VFEVCR_V_START)
- | ((VEnd & ZR36057_VFEVCR_VMASK) << ZR36057_VFEVCR_V_END);
+ | ((v_end & ZR36057_VFEVCR_VMASK) << ZR36057_VFEVCR_V_END);
if (zr->card.vfe_pol.vsync_pol)
reg |= ZR36057_VFEVCR_VS_POL;
btwrite(reg, ZR36057_VFEVCR);
--
2.25.1
[PATCH 0/7] staging: media: zoran: Eliminate camelcase
This patchset fixes 'avoid camelcase' warning by converting local variables to lowercase and separating words using '_'. Renaming of each variable is implemented in separate patches. Zhansaya Bagdauletkyzy (7): Rename 'HEnd' to 'h_end' Rename 'VEnd' to 'v_end' Rename 'DispMode' to 'disp_mode' Rename 'VidWinWid' to 'vid_win_wid' Rename 'VidWinHt' to 'vid_win_ht' Rename 'We' to 'we' Rename 'He' to 'he' drivers/staging/media/zoran/zoran_device.c | 48 +++--- 1 file changed, 24 insertions(+), 24 deletions(-) -- 2.25.1
[PATCH v5 10/10] media: uapi: move MPEG-2 stateless controls out of staging
Until now, the MPEG-2 V4L2 API was not exported as a public API,
and only defined in a private media header (media/mpeg2-ctrls.h).
After reviewing the MPEG-2 specification in detail, and reworking
the controls so they match the MPEG-2 semantics properly,
we can consider it ready.
Signed-off-by: Ezequiel Garcia
---
.../media/v4l/ext-ctrls-codec-stateless.rst | 218 +
.../media/v4l/ext-ctrls-codec.rst | 219 --
.../media/v4l/pixfmt-compressed.rst | 10 +-
.../media/v4l/vidioc-g-ext-ctrls.rst | 12 +
drivers/media/v4l2-core/v4l2-ctrls.c | 12 +-
drivers/staging/media/hantro/hantro_drv.c | 6 +-
.../media/hantro/hantro_g1_mpeg2_dec.c| 6 +-
.../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 6 +-
drivers/staging/media/sunxi/cedrus/cedrus.c | 6 +-
.../staging/media/sunxi/cedrus/cedrus_dec.c | 6 +-
include/media/mpeg2-ctrls.h | 128 --
include/media/v4l2-ctrls.h| 1 -
include/uapi/linux/v4l2-controls.h| 114 +
include/uapi/linux/videodev2.h| 3 +
14 files changed, 373 insertions(+), 374 deletions(-)
delete mode 100644 include/media/mpeg2-ctrls.h
diff --git
a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
index 3fc04daa9ffb..c38826024c58 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst
@@ -1244,3 +1244,221 @@ FWHT Flags
* - __u8
- ``padding[3]``
- Applications and drivers must set this to zero.
+
+.. _v4l2-codec-stateless-mpeg2:
+
+``V4L2_CID_STATELESS_MPEG2_SEQUENCE (struct)``
+Specifies the sequence parameters (as extracted from the bitstream) for the
+associated MPEG-2 slice data. This includes fields matching the syntax
+elements from the sequence header and sequence extension parts of the
+bitstream as specified by :ref:`mpeg2part2`.
+
+.. c:type:: v4l2_ctrl_mpeg2_sequence
+
+.. raw:: latex
+
+\small
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}|
+
+.. flat-table:: struct v4l2_ctrl_mpeg2_sequence
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u16
+ - ``horizontal_size``
+ - The width of the displayable part of the frame's luminance component.
+* - __u16
+ - ``vertical_size``
+ - The height of the displayable part of the frame's luminance component.
+* - __u32
+ - ``vbv_buffer_size``
+ - Used to calculate the required size of the video buffering verifier,
+ defined (in bits) as: 16 * 1024 * vbv_buffer_size.
+* - __u16
+ - ``profile_and_level_indication``
+ - The current profile and level indication as extracted from the
+ bitstream.
+* - __u8
+ - ``chroma_format``
+ - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
+* - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
+* - __u32
+ - ``flags``
+ - See :ref:`MPEG-2 Sequence Flags `.
+
+.. _mpeg2_sequence_flags:
+
+``MPEG-2 Sequence Flags``
+
+.. cssclass:: longtable
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE``
+ - 0x0001
+ - Indication that all the frames for the sequence are progressive instead
+ of interlaced.
+
+.. raw:: latex
+
+\normalsize
+
+``V4L2_CID_STATELESS_MPEG2_PICTURE (struct)``
+Specifies the picture parameters (as extracted from the bitstream) for the
+associated MPEG-2 slice data. This includes fields matching the syntax
+elements from the picture header and picture coding extension parts of the
+bitstream as specified by :ref:`mpeg2part2`.
+
+.. c:type:: v4l2_ctrl_mpeg2_picture
+
+.. raw:: latex
+
+\small
+
+.. cssclass:: longtable
+
+.. tabularcolumns:: |p{1.0cm}|p{5.6cm}|p{10.7cm}|
+
+.. flat-table:: struct v4l2_ctrl_mpeg2_picture
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u64
+ - ``backward_ref_ts``
+ - Timestamp of the V4L2 capture buffer to use as backward reference, used
+with B-coded and P-coded frames. The timestamp refers to the
+ ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+ :c:func:`v4l2_timeval_to_ns()` function to convert the struct
+ :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+* - __u64
+ - ``forward_ref_ts``
+ - Timestamp for the V4L2 capture buffer to use as forward reference, used
+with B-coded frames. The timestamp refers to the ``timestamp`` field in
+ struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
+ function to convert the struct :c:type:`timeval` in struct
+ :c:type:`v4l2_buffer`
[PATCH v5 09/10] media: uapi: Move the MPEG-2 stateless control type out of staging
Move the MPEG-2 stateless control types out of staging,
and re-number it to avoid any confusion.
Signed-off-by: Ezequiel Garcia
---
include/media/mpeg2-ctrls.h| 4
include/uapi/linux/videodev2.h | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/media/mpeg2-ctrls.h b/include/media/mpeg2-ctrls.h
index 2b0084b2519b..0b0ac8fcd220 100644
--- a/include/media/mpeg2-ctrls.h
+++ b/include/media/mpeg2-ctrls.h
@@ -16,10 +16,6 @@
#define V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE
(V4L2_CID_CODEC_BASE+253)
/* enum v4l2_ctrl_type type values */
-#define V4L2_CTRL_TYPE_MPEG2_QUANTISATION 0x0131
-#define V4L2_CTRL_TYPE_MPEG2_SEQUENCE 0x0132
-#define V4L2_CTRL_TYPE_MPEG2_PICTURE 0x0133
-
#define V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE0x0001
/**
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8d15f6ccc4b4..2206f3cd28a4 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1804,6 +1804,10 @@ enum v4l2_ctrl_type {
V4L2_CTRL_TYPE_FWHT_PARAMS = 0x0220,
V4L2_CTRL_TYPE_VP8_FRAME= 0x0240,
+
+ V4L2_CTRL_TYPE_MPEG2_QUANTISATION = 0x0250,
+ V4L2_CTRL_TYPE_MPEG2_SEQUENCE = 0x0251,
+ V4L2_CTRL_TYPE_MPEG2_PICTURE= 0x0252,
};
/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
--
2.30.0
[PATCH v5 08/10] media: controls: Log MPEG-2 stateless control in .std_log
Simply print the type of the control.
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-ctrls.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 575553ee7e4a..722a208c647e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1826,6 +1826,15 @@ static void std_log(const struct v4l2_ctrl *ctrl)
case V4L2_CTRL_TYPE_VP8_FRAME:
pr_cont("VP8_FRAME");
break;
+ case V4L2_CTRL_TYPE_MPEG2_QUANTISATION:
+ pr_cont("MPEG2_QUANTISATION");
+ break;
+ case V4L2_CTRL_TYPE_MPEG2_SEQUENCE:
+ pr_cont("MPEG2_SEQUENCE");
+ break;
+ case V4L2_CTRL_TYPE_MPEG2_PICTURE:
+ pr_cont("MPEG2_PICTURE");
+ break;
default:
pr_cont("unknown type %d", ctrl->type);
break;
--
2.30.0
[PATCH v5 07/10] media: uapi: mpeg2: Remove V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS
The Hantro and Cedrus drivers work in frame-mode,
meaning they expect all the slices in a picture (either frame
or field structure) to be passed in each OUTPUT buffer.
These two are the only V4L2 MPEG-2 stateless decoders currently
supported. Given the VA-API drivers also work per-frame,
coalescing all the MPEG-2 slices in a buffer before the decoding
operation, it makes sense to not expect slice-mode drivers and
therefore remove V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS.
This is done to avoid carrying an unused interface. If needed,
this control can be added without breaking backwards compatibility.
Note that this would mean introducing a enumerator control to
specify the decoding mode (see V4L2_CID_STATELESS_H264_DECODE_MODE).
Signed-off-by: Ezequiel Garcia
Co-developed-by: Nicolas Dufresne
Signed-off-by: Nicolas Dufresne
---
.../media/v4l/ext-ctrls-codec.rst | 35 ---
.../media/v4l/pixfmt-compressed.rst | 6 ++--
.../media/v4l/vidioc-queryctrl.rst| 6
.../media/videodev2.h.rst.exceptions | 1 -
drivers/media/v4l2-core/v4l2-ctrls.c | 19 --
drivers/staging/media/hantro/hantro_drv.c | 5 ---
.../media/hantro/hantro_g1_mpeg2_dec.c| 9 ++---
.../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 8 ++---
drivers/staging/media/sunxi/cedrus/cedrus.c | 6
drivers/staging/media/sunxi/cedrus/cedrus.h | 1 -
.../staging/media/sunxi/cedrus/cedrus_dec.c | 2 --
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 2 --
include/media/mpeg2-ctrls.h | 16 -
include/media/v4l2-ctrls.h| 2 --
14 files changed, 7 insertions(+), 111 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index ebed3d8570f4..7d3bfdbed4ec 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1575,41 +1575,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
.. _v4l2-mpeg-mpeg2:
-``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS (struct)``
-Specifies the slice parameters (as extracted from the bitstream) for the
-associated MPEG-2 slice data. This includes the necessary parameters for
-configuring a stateless hardware decoding pipeline for MPEG-2.
-The bitstream parameters are defined according to :ref:`mpeg2part2`.
-
-.. note::
-
- This compound control is not yet part of the public kernel API and
- it is expected to change.
-
-.. c:type:: v4l2_ctrl_mpeg2_slice_params
-
-.. tabularcolumns:: |p{5.6cm}|p{4.6cm}|p{7.1cm}|
-
-.. cssclass:: longtable
-
-.. flat-table:: struct v4l2_ctrl_mpeg2_slice_params
-:header-rows: 0
-:stub-columns: 0
-:widths: 1 1 2
-
-* - __u32
- - ``bit_size``
- - Size (in bits) of the current slice data.
-* - __u32
- - ``data_bit_offset``
- - Offset (in bits) to the video data in the current slice data.
-* - __u32
- - ``quantiser_scale_code``
- - Code used to determine the quantization scale to use for the IDCT.
-* - __u8
- - ``reserved``
- - Applications and drivers must set this to zero.
-
``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)``
Specifies the sequence parameters (as extracted from the bitstream) for the
associated MPEG-2 slice data. This includes fields matching the syntax
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
index bbbacbd65d6f..6c10a062adac 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
@@ -114,9 +114,9 @@ Compressed Formats
This format is adapted for stateless video decoders that implement a
MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`).
Metadata associated with the frame to decode is required to be passed
- through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE``,
-``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE``, and
``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS``
-controls. Quantisation matrices can optionally be specified through the
+ through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE`` and
+``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE`` controls.
+Quantisation matrices can optionally be specified through the
``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control.
See the :ref:`associated Codec Control IDs `.
Exactly one output and one capture buffer must be provided for use with
diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
index afc1505a3a7e..07e54029e1e9 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst
@@ -417,12 +417,6
[PATCH v5 06/10] media: hantro/cedrus: Remove unneeded slice size and slice offset
The MPEG2_SLICE_PARAMS control is designed to refer to a single slice. However, the Hantro and Cedrus drivers operate in per-frame mode, and so does the current Ffmpeg and GStreamer implementations that are tested with these two drivers. In other words, the drivers are expecting all the slices in a picture (with either frame or field structure) to be contained in the OUTPUT buffer, which means the slice size and offset shouldn't be used. Signed-off-by: Ezequiel Garcia --- drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c | 4 ++-- drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c | 4 ++-- drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c | 7 +++ 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c index d35071e88116..c4040fba7c80 100644 --- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c +++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c @@ -203,7 +203,7 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx) G1_REG_TOPFIELDFIRST_E(pic->flags & V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST); vdpu_write_relaxed(vpu, reg, G1_SWREG(4)); - reg = G1_REG_STRM_START_BIT(slice_params->data_bit_offset) | + reg = G1_REG_STRM_START_BIT(0) | G1_REG_QSCALE_TYPE(pic->flags & V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE) | G1_REG_CON_MV_E(pic->flags & V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV) | G1_REG_INTRA_DC_PREC(pic->intra_dc_precision) | @@ -212,7 +212,7 @@ void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx) vdpu_write_relaxed(vpu, reg, G1_SWREG(5)); reg = G1_REG_INIT_QP(1) | - G1_REG_STREAM_LEN(slice_params->bit_size >> 3); + G1_REG_STREAM_LEN(vb2_get_plane_payload(_buf->vb2_buf, 0)); vdpu_write_relaxed(vpu, reg, G1_SWREG(6)); reg = G1_REG_ALT_SCAN_FLAG_E(pic->flags & V4L2_MPEG2_PIC_FLAG_ALT_SCAN) | diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c index 18bd14704ebf..314269811244 100644 --- a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c +++ b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c @@ -177,7 +177,7 @@ void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx) vdpu_write_relaxed(vpu, reg, VDPU_SWREG(50)); reg = VDPU_REG_INIT_QP(1) | - VDPU_REG_STREAM_LEN(slice_params->bit_size >> 3); + VDPU_REG_STREAM_LEN(vb2_get_plane_payload(_buf->vb2_buf, 0)); vdpu_write_relaxed(vpu, reg, VDPU_SWREG(51)); reg = VDPU_REG_APF_THRESHOLD(8) | @@ -220,7 +220,7 @@ void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx) VDPU_REG_TOPFIELDFIRST_E(pic->flags & V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST); vdpu_write_relaxed(vpu, reg, VDPU_SWREG(120)); - reg = VDPU_REG_STRM_START_BIT(slice_params->data_bit_offset) | + reg = VDPU_REG_STRM_START_BIT(0) | VDPU_REG_QSCALE_TYPE(pic->flags & V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE) | VDPU_REG_CON_MV_E(pic->flags & V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV) | VDPU_REG_INTRA_DC_PREC(pic->intra_dc_precision) | diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c index 16e99792cf42..fd71cb175318 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c +++ b/drivers/staging/media/sunxi/cedrus/cedrus_mpeg2.c @@ -152,10 +152,9 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, struct cedrus_run *run) /* Source offset and length in bits. */ - cedrus_write(dev, VE_DEC_MPEG_VLD_OFFSET, -slice_params->data_bit_offset); + cedrus_write(dev, VE_DEC_MPEG_VLD_OFFSET, 0); - reg = slice_params->bit_size - slice_params->data_bit_offset; + reg = vb2_get_plane_payload(>src->vb2_buf, 0) * 8; cedrus_write(dev, VE_DEC_MPEG_VLD_LEN, reg); /* Source beginning and end addresses. */ @@ -169,7 +168,7 @@ static void cedrus_mpeg2_setup(struct cedrus_ctx *ctx, struct cedrus_run *run) cedrus_write(dev, VE_DEC_MPEG_VLD_ADDR, reg); - reg = src_buf_addr + DIV_ROUND_UP(slice_params->bit_size, 8); + reg = src_buf_addr + vb2_get_plane_payload(>src->vb2_buf, 0); cedrus_write(dev, VE_DEC_MPEG_VLD_END_ADDR, reg); /* Macroblock address: start at the beginning. */ -- 2.30.0
[PATCH v5 05/10] media: uapi: mpeg2: Move reference buffer fields
The forward and backwards references are specified per-picture
and not per-slice. Move it to V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE.
Signed-off-by: Ezequiel Garcia
---
.../media/v4l/ext-ctrls-codec.rst | 28 +--
.../media/hantro/hantro_g1_mpeg2_dec.c| 6 ++--
.../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 6 ++--
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 4 +--
include/media/mpeg2-ctrls.h | 16 +--
5 files changed, 28 insertions(+), 32 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 8a0d6139db34..ebed3d8570f4 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1603,20 +1603,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - __u32
- ``data_bit_offset``
- Offset (in bits) to the video data in the current slice data.
-* - __u64
- - ``backward_ref_ts``
- - Timestamp of the V4L2 capture buffer to use as backward reference, used
-with B-coded and P-coded frames. The timestamp refers to the
- ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
- :c:func:`v4l2_timeval_to_ns()` function to convert the struct
- :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
-* - __u64
- - ``forward_ref_ts``
- - Timestamp for the V4L2 capture buffer to use as forward reference, used
-with B-coded frames. The timestamp refers to the ``timestamp`` field in
- struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
- function to convert the struct :c:type:`timeval` in struct
- :c:type:`v4l2_buffer` to a __u64.
* - __u32
- ``quantiser_scale_code``
- Code used to determine the quantization scale to use for the IDCT.
@@ -1712,6 +1698,20 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
:stub-columns: 0
:widths: 1 1 2
+* - __u64
+ - ``backward_ref_ts``
+ - Timestamp of the V4L2 capture buffer to use as backward reference, used
+with B-coded and P-coded frames. The timestamp refers to the
+ ``timestamp`` field in struct :c:type:`v4l2_buffer`. Use the
+ :c:func:`v4l2_timeval_to_ns()` function to convert the struct
+ :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64.
+* - __u64
+ - ``forward_ref_ts``
+ - Timestamp for the V4L2 capture buffer to use as forward reference, used
+with B-coded frames. The timestamp refers to the ``timestamp`` field in
+ struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()`
+ function to convert the struct :c:type:`timeval` in struct
+ :c:type:`v4l2_buffer` to a __u64.
* - __u8
- ``picture_coding_type``
- Picture coding type for the frame covered by the current slice
diff --git a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
index f3494a70aa12..d35071e88116 100644
--- a/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/hantro_g1_mpeg2_dec.c
@@ -101,12 +101,10 @@ hantro_g1_mpeg2_dec_set_buffers(struct hantro_dev *vpu,
struct hantro_ctx *ctx,
switch (pic->picture_coding_type) {
case V4L2_MPEG2_PIC_CODING_TYPE_B:
- backward_addr = hantro_get_ref(ctx,
- slice_params->backward_ref_ts);
+ backward_addr = hantro_get_ref(ctx, pic->backward_ref_ts);
fallthrough;
case V4L2_MPEG2_PIC_CODING_TYPE_P:
- forward_addr = hantro_get_ref(ctx,
- slice_params->forward_ref_ts);
+ forward_addr = hantro_get_ref(ctx, pic->forward_ref_ts);
}
/* Source bitstream buffer */
diff --git a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
index 5b383906af59..18bd14704ebf 100644
--- a/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
+++ b/drivers/staging/media/hantro/rk3399_vpu_hw_mpeg2_dec.c
@@ -104,12 +104,10 @@ rk3399_vpu_mpeg2_dec_set_buffers(struct hantro_dev *vpu,
switch (pic->picture_coding_type) {
case V4L2_MPEG2_PIC_CODING_TYPE_B:
- backward_addr = hantro_get_ref(ctx,
- slice_params->backward_ref_ts);
+ backward_addr = hantro_get_ref(ctx, pic->backward_ref_ts);
fallthrough;
case V4L2_MPEG2_PIC_CODING_TYPE_P:
- forward_addr = hantro_get_ref(ctx,
- slice_params->forward_ref_ts);
+ forward_addr = hantro_get_ref(ctx, pic->forward_ref_ts);
}
/* Source bitstream buffer */
diff --git
[PATCH v5 04/10] media: uapi: mpeg2: Split sequence and picture parameters
Typically, bitstreams are composed of a sequence header,
followed by a number of picture header and picture coding extension
headers. Each picture can be composed by a number of slices.
Let's split the MPEG-2 uAPI to follow these semantics more closely,
allowing more usage flexibility. Having these controls splitted
allows applications to set a sequence control at the beginning
of a sequence, and then set a picture control for each frame.
While here add padding fields where needed, and document
the uAPI header thoroughly.
Note that the V4L2_CTRL_TYPE_{} defines had to be moved because
it clashes with existing ones. This is not really an issue
since they will be re-defined when the controls are moved
out of staging.
Signed-off-by: Ezequiel Garcia
Tested-by: Jonas Karlman
---
.../media/v4l/ext-ctrls-codec.rst | 47 ++---
.../media/v4l/pixfmt-compressed.rst | 5 +-
.../media/v4l/vidioc-queryctrl.rst| 12 +++
.../media/videodev2.h.rst.exceptions | 2 +
drivers/media/v4l2-core/v4l2-ctrls.c | 57 ---
drivers/staging/media/hantro/hantro_drv.c | 10 ++
.../media/hantro/hantro_g1_mpeg2_dec.c| 14 +--
.../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 14 +--
drivers/staging/media/sunxi/cedrus/cedrus.c | 12 +++
drivers/staging/media/sunxi/cedrus/cedrus.h | 2 +
.../staging/media/sunxi/cedrus/cedrus_dec.c | 4 +
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 8 +-
include/media/mpeg2-ctrls.h | 97 +++
include/media/v4l2-ctrls.h| 4 +
14 files changed, 228 insertions(+), 60 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 7d5ac7fb6579..8a0d6139db34 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1603,14 +1603,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - __u32
- ``data_bit_offset``
- Offset (in bits) to the video data in the current slice data.
-* - struct :c:type:`v4l2_mpeg2_sequence`
- - ``sequence``
- - Structure with MPEG-2 sequence metadata, merging relevant fields from
- the sequence header and sequence extension parts of the bitstream.
-* - struct :c:type:`v4l2_mpeg2_picture`
- - ``picture``
- - Structure with MPEG-2 picture metadata, merging relevant fields from
- the picture header and picture coding extension parts of the bitstream.
* - __u64
- ``backward_ref_ts``
- Timestamp of the V4L2 capture buffer to use as backward reference, used
@@ -1628,14 +1620,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - __u32
- ``quantiser_scale_code``
- Code used to determine the quantization scale to use for the IDCT.
+* - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
-.. c:type:: v4l2_mpeg2_sequence
+``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)``
+Specifies the sequence parameters (as extracted from the bitstream) for the
+associated MPEG-2 slice data. This includes fields matching the syntax
+elements from the sequence header and sequence extension parts of the
+bitstream as specified by :ref:`mpeg2part2`.
+
+.. note::
+
+ This compound control is not yet part of the public kernel API and
+ it is expected to change.
+
+.. c:type:: v4l2_ctrl_mpeg2_sequence
.. cssclass:: longtable
.. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}|
-.. flat-table:: struct v4l2_mpeg2_sequence
+.. flat-table:: struct v4l2_ctrl_mpeg2_sequence
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
@@ -1657,6 +1663,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
* - __u8
- ``chroma_format``
- The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
+* - __u8
+ - ``reserved``
+ - Applications and drivers must set this to zero.
* - __u32
- ``flags``
- See :ref:`MPEG-2 Sequence Flags `.
@@ -1677,7 +1686,18 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
- Indication that all the frames for the sequence are progressive instead
of interlaced.
-.. c:type:: v4l2_mpeg2_picture
+``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE (struct)``
+Specifies the picture parameters (as extracted from the bitstream) for the
+associated MPEG-2 slice data. This includes fields matching the syntax
+elements from the picture header and picture coding extension parts of the
+bitstream as specified by :ref:`mpeg2part2`.
+
+.. note::
+
+ This compound control is not yet part of the public kernel API and
+ it is expected to change.
+
+.. c:type:: v4l2_ctrl_mpeg2_picture
.. raw:: latex
@@ -1687,7 +1707,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
.. tabularcolumns::
[PATCH v5 03/10] media: uapi: mpeg2: Cleanup flags
Our current MPEG-2 uAPI uses 1-byte fields for MPEG-2 boolean syntax elements. Clean these by adding a 'flags' field and flag macro for each boolean syntax element. A follow-up change will refactor this uAPI so we don't need to add padding fields just yet. Signed-off-by: Ezequiel Garcia Tested-by: Jonas Karlman --- .../media/v4l/ext-ctrls-codec.rst | 77 +- drivers/media/v4l2-core/v4l2-async-core.c | 880 ++ drivers/media/v4l2-core/v4l2-ctrls.c | 14 +- .../media/hantro/hantro_g1_mpeg2_dec.c| 76 +- .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 76 +- .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 38 +- include/media/mpeg2-ctrls.h | 36 +- 7 files changed, 1055 insertions(+), 142 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-async-core.c diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index d9546f0aa2e8..7d5ac7fb6579 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -1654,13 +1654,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``profile_and_level_indication`` - The current profile and level indication as extracted from the bitstream. -* - __u8 - - ``progressive_sequence`` - - Indication that all the frames for the sequence are progressive instead - of interlaced. * - __u8 - ``chroma_format`` - The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4). +* - __u32 + - ``flags`` + - See :ref:`MPEG-2 Sequence Flags `. + +.. _mpeg2_sequence_flags: + +``MPEG-2 Sequence Flags`` + +.. cssclass:: longtable + +.. flat-table:: +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE`` + - 0x0001 + - Indication that all the frames for the sequence are progressive instead + of interlaced. .. c:type:: v4l2_mpeg2_picture @@ -1693,29 +1708,45 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type - - ``picture_structure`` - Picture structure (1: interlaced top field, 2: interlaced bottom field, 3: progressive frame). -* - __u8 - - ``top_field_first`` - - If set to 1 and interlaced stream, top field is output first. -* - __u8 - - ``frame_pred_frame_dct`` - - If set to 1, only frame-DCT and frame prediction are used. -* - __u8 - - ``concealment_motion_vectors`` - - If set to 1, motion vectors are coded for intra macroblocks. -* - __u8 - - ``q_scale_type`` +* - __u32 + - ``flags`` + - See :ref:`MPEG-2 Picture Flags `. + + +.. _mpeg2_picture_flags: + +``MPEG-2 Picture Flags`` + +.. cssclass:: longtable + +.. flat-table:: +:header-rows: 0 +:stub-columns: 0 +:widths: 1 1 2 + +* - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST`` + - 0x0001 + - If set and it's an interlaced stream, top field is output first. +* - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT`` + - 0x0002 + - If set only frame-DCT and frame prediction are used. +* - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV`` + - 0x0004 + - If set motion vectors are coded for intra macroblocks. +* - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE`` + - 0x0008 - This flag affects the inverse quantization process. -* - __u8 - - ``intra_vlc_format`` +* - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC`` + - 0x0010 - This flag affects the decoding of transform coefficient data. -* - __u8 - - ``alternate_scan`` +* - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN`` + - 0x0020 - This flag affects the decoding of transform coefficient data. -* - __u8 - - ``repeat_first_field`` +* - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST`` + - 0x0040 - This flag affects the decoding process of progressive frames. -* - __u16 - - ``progressive_frame`` +* - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE`` + - 0x0080 - Indicates whether the current frame is progressive. .. raw:: latex diff --git a/drivers/media/v4l2-core/v4l2-async-core.c b/drivers/media/v4l2-core/v4l2-async-core.c new file mode 100644 index ..cd9e78c63791 --- /dev/null +++ b/drivers/media/v4l2-core/v4l2-async-core.c @@ -0,0 +1,880 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * V4L2 asynchronous subdevice registration API + * + * Copyright (C) 2012-2013, Guennadi Liakhovetski + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +static int v4l2_async_notifier_call_bound(struct v4l2_async_notifier *n, + struct v4l2_subdev *subdev, + struct
[PATCH v5 02/10] media: uapi: mpeg2: rework quantisation matrices semantics
As stated in the MPEG-2 specification, section 6.3.7 "Quant matrix
extension":
Each quantisation matrix has a default set of values. When a
sequence_header_code is decoded all matrices shall be reset to
their default values. User defined matrices may be downloaded
and this can occur in a sequence_header() or in a
quant_matrix_extension().
The load_intra_quantiser_matrix syntax elements are transmitted
in the bistream headers, signalling that a quantisation matrix
needs to be loaded and used for pictures transmitted afterwards
(until the matrices are reset).
This "load" semantics are implemented in the V4L2 interface
without the need of any "load" flags: passing the control
is effectively a load.
Therefore, rework the V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION
semantics to match the MPEG-2 semantics. Quantisation matrices
values are now initialized by the V4L2 control core to their
reset default value, and applications are expected to reset
their values as specified.
The quantisation control is therefore optional, and used to
load bitstream-defined values in the quantisation matrices.
Signed-off-by: Ezequiel Garcia
Co-developed-by: Nicolas Dufresne
Signed-off-by: Nicolas Dufresne
---
.../media/v4l/ext-ctrls-codec.rst | 17 -
drivers/media/v4l2-core/v4l2-ctrls.c | 21 ++
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 38 +--
include/media/mpeg2-ctrls.h | 5 ---
4 files changed, 23 insertions(+), 58 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 151d1c676b6e..d9546f0aa2e8 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1746,23 +1746,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
:stub-columns: 0
:widths: 1 1 2
-* - __u8
- - ``load_intra_quantiser_matrix``
- - One bit to indicate whether to load the ``intra_quantiser_matrix``
data.
-* - __u8
- - ``load_non_intra_quantiser_matrix``
- - One bit to indicate whether to load the ``non_intra_quantiser_matrix``
- data.
-* - __u8
- - ``load_chroma_intra_quantiser_matrix``
- - One bit to indicate whether to load the
- ``chroma_intra_quantiser_matrix`` data, only relevant for non-4:2:0 YUV
- formats.
-* - __u8
- - ``load_chroma_non_intra_quantiser_matrix``
- - One bit to indicate whether to load the
- ``chroma_non_intra_quantiser_matrix`` data, only relevant for non-4:2:0
- YUV formats.
* - __u8
- ``intra_quantiser_matrix[64]``
- The quantisation matrix coefficients for intra-coded frames, in zigzag
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 74f5ca1a5f6c..5d92a2b33a6e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -57,6 +57,18 @@ static bool is_new_manual(const struct v4l2_ctrl *master)
return master->is_auto && master->val == master->manual_mode_value;
}
+/* Default MPEG-2 quantisation coefficients, from the specification. */
+static const u8 mpeg2_intra_quant_matrix[64] = {
+ 8, 16, 16, 19, 16, 19, 22, 22,
+ 22, 22, 22, 22, 26, 24, 26, 27,
+ 27, 27, 26, 26, 26, 26, 27, 27,
+ 27, 29, 29, 29, 34, 34, 34, 29,
+ 29, 29, 27, 27, 29, 29, 32, 32,
+ 34, 34, 37, 38, 37, 35, 35, 34,
+ 35, 38, 38, 40, 40, 40, 48, 48,
+ 46, 46, 56, 56, 58, 69, 69, 83
+};
+
/* Returns NULL or a character pointer array containing the menu for
the given control ID. The pointer array ends with a NULL pointer.
An empty string signifies a menu entry that is invalid. This allows
@@ -1656,6 +1668,7 @@ static void std_init_compound(const struct v4l2_ctrl
*ctrl, u32 idx,
union v4l2_ctrl_ptr ptr)
{
struct v4l2_ctrl_mpeg2_slice_params *p_mpeg2_slice_params;
+ struct v4l2_ctrl_mpeg2_quantisation *p_mpeg2_quant;
struct v4l2_ctrl_vp8_frame *p_vp8_frame;
struct v4l2_ctrl_fwht_params *p_fwht_params;
void *p = ptr.p + idx * ctrl->elem_size;
@@ -1680,6 +1693,14 @@ static void std_init_compound(const struct v4l2_ctrl
*ctrl, u32 idx,
p_mpeg2_slice_params->picture.picture_coding_type =
V4L2_MPEG2_PICTURE_CODING_TYPE_I;
break;
+ case V4L2_CTRL_TYPE_MPEG2_QUANTISATION:
+ p_mpeg2_quant = p;
+
+ memcpy(p_mpeg2_quant->intra_quantiser_matrix,
+ mpeg2_intra_quant_matrix,
+ ARRAY_SIZE(mpeg2_intra_quant_matrix));
+ memset(p_mpeg2_quant->non_intra_quantiser_matrix, 16, 64);
+ break;
case V4L2_CTRL_TYPE_VP8_FRAME:
p_vp8_frame = p;
p_vp8_frame->num_dct_parts = 1;
diff
[PATCH v5 01/10] media: uapi: mpeg2: Rename "quantization" to "quantisation"
The MPEG-2 specification refers to the quantisation matrices
using the word "quantisation". Make the V4L2 interface more
ergonomic by matching the MPEG-2 spec.
Signed-off-by: Ezequiel Garcia
---
.../media/v4l/ext-ctrls-codec.rst | 16 ++--
.../media/v4l/pixfmt-compressed.rst | 4 +--
.../media/v4l/vidioc-queryctrl.rst| 6 ++---
.../media/videodev2.h.rst.exceptions | 2 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 12 -
drivers/staging/media/hantro/hantro_drv.c | 2 +-
.../media/hantro/hantro_g1_mpeg2_dec.c| 17 +---
drivers/staging/media/hantro/hantro_hw.h | 2 +-
drivers/staging/media/hantro/hantro_mpeg2.c | 2 +-
.../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 14 +-
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus.h | 2 +-
.../staging/media/sunxi/cedrus/cedrus_dec.c | 4 +--
.../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 26 +--
include/media/mpeg2-ctrls.h | 6 ++---
include/media/v4l2-ctrls.h| 4 +--
16 files changed, 58 insertions(+), 63 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
index 188aef8e40d0..151d1c676b6e 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
@@ -1722,8 +1722,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
\normalsize
-``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION (struct)``
-Specifies quantization matrices (as extracted from the bitstream) for the
+``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION (struct)``
+Specifies quantisation matrices (as extracted from the bitstream) for the
associated MPEG-2 slice data.
.. note::
@@ -1731,7 +1731,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
This compound control is not yet part of the public kernel API and
it is expected to change.
-.. c:type:: v4l2_ctrl_mpeg2_quantization
+.. c:type:: v4l2_ctrl_mpeg2_quantisation
.. tabularcolumns:: |p{0.8cm}|p{8.0cm}|p{8.5cm}|
@@ -1741,7 +1741,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
\small
-.. flat-table:: struct v4l2_ctrl_mpeg2_quantization
+.. flat-table:: struct v4l2_ctrl_mpeg2_quantisation
:header-rows: 0
:stub-columns: 0
:widths: 1 1 2
@@ -1765,24 +1765,24 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
YUV formats.
* - __u8
- ``intra_quantiser_matrix[64]``
- - The quantization matrix coefficients for intra-coded frames, in zigzag
+ - The quantisation matrix coefficients for intra-coded frames, in zigzag
scanning order. It is relevant for both luma and chroma components,
although it can be superseded by the chroma-specific matrix for
non-4:2:0 YUV formats.
* - __u8
- ``non_intra_quantiser_matrix[64]``
- - The quantization matrix coefficients for non-intra-coded frames, in
+ - The quantisation matrix coefficients for non-intra-coded frames, in
zigzag scanning order. It is relevant for both luma and chroma
components, although it can be superseded by the chroma-specific matrix
for non-4:2:0 YUV formats.
* - __u8
- ``chroma_intra_quantiser_matrix[64]``
- - The quantization matrix coefficients for the chominance component of
+ - The quantisation matrix coefficients for the chominance component of
intra-coded frames, in zigzag scanning order. Only relevant for
non-4:2:0 YUV formats.
* - __u8
- ``chroma_non_intra_quantiser_matrix[64]``
- - The quantization matrix coefficients for the chrominance component of
+ - The quantisation matrix coefficients for the chrominance component of
non-intra-coded frames, in zigzag scanning order. Only relevant for
non-4:2:0 YUV formats.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
index 6dba70da822b..cba607f789f0 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst
@@ -115,8 +115,8 @@ Compressed Formats
MPEG-2 pipeline (using the :ref:`mem2mem` and :ref:`media-request-api`).
Metadata associated with the frame to decode is required to be passed
through the ``V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS`` control and
- quantization matrices can optionally be specified through the
- ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION`` control.
+ quantisation matrices can optionally be specified through the
+ ``V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION`` control.
See the :ref:`associated Codec Control IDs `.
Exactly one output and one capture buffer must be provided
[PATCH v5 00/10] MPEG-2 stateless API cleanup and destaging
Hi everyone, Over the last few weeks Daniel Almeida and Nicolas Dufresne have been working on GStreamer v4l2codecs support for stateless MPEG-2 decoding. This allowed us to re-review the MPEG-2 specification and re-discuss the API with some additional insight. The API now looks quite cleaner, and hopefully ready for destaging. This series is mostly thanks to Daniel and Nicolas! Patches 1 to 7 cleanup the API, and patches 8 to 10 move it out of staging. This is tested on i.MX8M and RK3399 platforms, using GStreamer v4l2codecs, which will be upstream very soon. v5: * Rename "quantization" to "quantisation", so the terminology matches the MPEG-2 specification. This is the only change in v5, compared to v4. v4: * Rework and clarify quantization matrices control semantics. * Move reference buffer fields to the picture parameter control. * Remove slice parameters control. This can be added back in the future if needed, but for now it's not used. See patch 6/9 for details. * Destage the API. v3: * No API changes, just minor boilerplate fixes for the new controls to be properly exposed, initialized and validated. v2: * Fixed bad use of boolean negation in a flag, which was fortunately reported by 0day bot. Ezequiel Garcia (10): media: uapi: mpeg2: Rename "quantization" to "quantisation" media: uapi: mpeg2: rework quantisation matrices semantics media: uapi: mpeg2: Cleanup flags media: uapi: mpeg2: Split sequence and picture parameters media: uapi: mpeg2: Move reference buffer fields media: hantro/cedrus: Remove unneeded slice size and slice offset media: uapi: mpeg2: Remove V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS media: controls: Log MPEG-2 stateless control in .std_log media: uapi: Move the MPEG-2 stateless control type out of staging media: uapi: move MPEG-2 stateless controls out of staging .../media/v4l/ext-ctrls-codec-stateless.rst | 218 + .../media/v4l/ext-ctrls-codec.rst | 217 - .../media/v4l/pixfmt-compressed.rst | 11 +- .../media/v4l/vidioc-g-ext-ctrls.rst | 12 + .../media/v4l/vidioc-queryctrl.rst| 18 +- .../media/videodev2.h.rst.exceptions | 5 +- drivers/media/v4l2-core/v4l2-async-core.c | 880 ++ drivers/media/v4l2-core/v4l2-ctrls.c | 118 ++- drivers/staging/media/hantro/hantro_drv.c | 9 +- .../media/hantro/hantro_g1_mpeg2_dec.c| 110 +-- drivers/staging/media/hantro/hantro_hw.h | 2 +- drivers/staging/media/hantro/hantro_mpeg2.c | 2 +- .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 106 +-- drivers/staging/media/sunxi/cedrus/cedrus.c | 10 +- drivers/staging/media/sunxi/cedrus/cedrus.h | 5 +- .../staging/media/sunxi/cedrus/cedrus_dec.c | 10 +- .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 97 +- include/media/mpeg2-ctrls.h | 82 -- include/media/v4l2-ctrls.h| 11 +- include/uapi/linux/v4l2-controls.h| 114 +++ include/uapi/linux/videodev2.h| 7 + 21 files changed, 1492 insertions(+), 552 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-async-core.c delete mode 100644 include/media/mpeg2-ctrls.h -- 2.30.0
xfs_sysfs.c:undefined reference to `atomic64_read_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d93a0d43e3d0ba9e19387be4dae4a8d5b175a8d7 commit: 166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 xfs: stop CONFIG_XFS_DEBUG from changing compiler flags date: 11 months ago config: um-randconfig-r034-20210403 (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 166405f6b53b7d7eecb7939aa4a79bc7c1e0ed68 # save the attached .config to linux build tree make W=1 ARCH=um If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): /usr/bin/ld: pids.c:(.text+0x41f): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: kernel/cgroup/pids.o: in function `pids_cancel_fork': pids.c:(.text+0x4e0): undefined reference to `atomic64_add_return_386' /usr/bin/ld: kernel/trace/trace_clock.o: in function `trace_clock_counter': trace_clock.c:(.text+0xcc): undefined reference to `atomic64_add_return_386' /usr/bin/ld: fs/proc/task_mmu.o: in function `task_mem': task_mmu.c:(.text+0x4ec): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/balloc.o: in function `ext4_has_free_clusters': balloc.c:(.text+0x54): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/dir.o: in function `ext4_dir_llseek': dir.c:(.text+0x256): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/dir.o: in function `ext4_readdir': dir.c:(.text+0x4fc): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x52c): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x555): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: dir.c:(.text+0x8d9): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x931): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x95a): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/ialloc.o: in function `get_orlov_stats': ialloc.c:(.text+0x239): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/inline.o: in function `ext4_add_dirent_to_inline.isra.0': inline.c:(.text+0x3ed): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x425): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inline.o: in function `ext4_read_inline_dir': inline.c:(.text+0x1d7d): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x1dd5): undefined reference to `atomic64_read_386' /usr/bin/ld: inline.c:(.text+0x1dfe): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inode.o: in function `inode_maybe_inc_iversion.constprop.0': inode.c:(.text+0xeb2): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0xeea): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/inode.o: in function `ext4_do_update_inode': inode.c:(.text+0x2318): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x231f): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/ext4/inode.o: in function `__ext4_iget': inode.c:(.text+0x3f91): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ext4/ioctl.o: in function `swap_inode_boot_loader': ioctl.c:(.text+0xdac): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ext4/namei.o: in function `inode_inc_iversion': namei.c:(.text+0x365): undefined reference to `atomic64_read_386' /usr/bin/ld: namei.c:(.text+0x39d): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext4/resize.o: in function `ext4_flex_group_add': resize.c:(.text+0x25c4): undefined reference to `atomic64_add_386' /usr/bin/ld: fs/ext4/xattr.o: in function `ext4_xattr_inode_update_ref': xattr.c:(.text+0x6ae): undefined reference to `atomic64_read_386' /usr/bin/ld: xattr.c:(.text+0x6e2): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ext4/xattr.o: in function `ext4_xattr_inode_iget': xattr.c:(.text+0xae1): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ext4/xattr.o: in function `ext4_xattr_inode_lookup_create': xattr.c:(.text+0x12b5): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/ext2/dir.o: in function `ext2_commit_chunk': dir.c:(.text+0xb9): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0xf1): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/ext2/dir.o: in function `ext2_readdir': dir.c:(.text+0x3ec): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x5cd): undefined reference to `atomic64_read_386' /usr/bin/ld: dir.c:(.text+0x5f9): undefined reference to `cmpxchg
Re: [PATCH bpf-next 3/5] libbpf: add low level TC-BPF API
On Sat, Apr 03, 2021 at 12:38:06AM +0530, Kumar Kartikeya Dwivedi wrote:
> On Sat, Apr 03, 2021 at 12:02:14AM IST, Alexei Starovoitov wrote:
> > On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwivedi
> > wrote:
> > > [...]
> >
> > All of these things are messy because of tc legacy. bpf tried to follow tc
> > style
> > with cls and act distinction and it didn't quite work. cls with
> > direct-action is the only
> > thing that became mainstream while tc style attach wasn't really addressed.
> > There were several incidents where tc had tens of thousands of progs
> > attached
> > because of this attach/query/index weirdness described above.
> > I think the only way to address this properly is to introduce bpf_link
> > style of
> > attaching to tc. Such bpf_link would support ingress/egress only.
> > direction-action will be implied. There won't be any index and query
> > will be obvious.
>
> Note that we already have bpf_link support working (without support for
> pinning
> ofcourse) in a limited way. The ifindex, protocol, parent_id, priority,
> handle,
> chain_index tuple uniquely identifies a filter, so we stash this in the
> bpf_link
> and are able to operate on the exact filter during release.
Except they're not unique. The library can stash them, but something else
doing detach via iproute2 or their own netlink calls will detach the prog.
This other app can attach to the same spot a different prog and now
bpf_link__destroy will be detaching somebody else prog.
> > So I would like to propose to take this patch set a step further from
> > what Daniel said:
> > int bpf_tc_attach(prog_fd, ifindex, {INGRESS,EGRESS}):
> > and make this proposed api to return FD.
> > To detach from tc ingress/egress just close(fd).
>
> You mean adding an fd-based TC API to the kernel?
yes.
> > The user processes will not conflict with each other and will not accidently
> > detach bpf program that was attached by another user process.
> > Such api will address the existing tc query/attach/detach race race
> > conditions.
>
> Hmm, I think we do solve the race condition by returning the id. As long as
> you
> don't misuse the interface and go around deleting filters arbitrarily (i.e.
> only
> detach using the id), programs won't step over each other's filters. Storing
> the
> id from the netlink response received during detach also eliminates any
> ambigiuity from probing through get_info after attach. Same goes for actions,
> and the same applies to the bpf_link returning API (which stashes id/index).
There are plenty of tools and libraries out there that do attach/detach of bpf
to tc. Everyone is not going to convert to this new libbpf api overnight.
So 'miuse of the interface' is not a misuse. It's a reality that is going to
keep
happening unless the kernel guarantees ownership of the attachment via FD.
> The only advantage of fd would be the possibility of pinning it, and extending
> lifetime of the filter.
Pinning is one of the advantages. The main selling point of FD is ownership
of the attachment.
[rcu:rcu/next] BUILD SUCCESS 69f68579fdceac1651a312a71fe11115399369c6
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next branch HEAD: 69f68579fdceac1651a312a71fe5399369c6 rcu: Improve tree.c comments and add code cleanups elapsed time: 725m configs tested: 145 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc powernv_defconfig mips malta_kvm_defconfig m68kmvme16x_defconfig powerpc ppc40x_defconfig mips tb0226_defconfig ia64 allmodconfig m68k amcore_defconfig m68k bvme6000_defconfig arm spear13xx_defconfig powerpc ppa8548_defconfig sh sh03_defconfig powerpc g5_defconfig powerpc katmai_defconfig armmini2440_defconfig shmigor_defconfig arm socfpga_defconfig sh espt_defconfig s390 allmodconfig xtensa nommu_kc705_defconfig sh kfr2r09-romimage_defconfig sh sdk7780_defconfig powerpc ep8248e_defconfig powerpc ppc64e_defconfig arm lpc32xx_defconfig m68km5272c3_defconfig h8300alldefconfig sh se7712_defconfig powerpc tqm8555_defconfig arm mv78xx0_defconfig mipsbcm47xx_defconfig xtensa iss_defconfig arm pxa910_defconfig powerpcsam440ep_defconfig mips bmips_stb_defconfig arm rpc_defconfig archsdk_defconfig mipsqi_lb60_defconfig arc alldefconfig powerpc ep88xc_defconfig pariscgeneric-32bit_defconfig mips mpc30x_defconfig sh sh2007_defconfig arm hackkit_defconfig arm moxart_defconfig arm stm32_defconfig shhp6xx_defconfig mips ip22_defconfig m68k alldefconfig sh r7780mp_defconfig mips rbtx49xx_defconfig m68k apollo_defconfig powerpc lite5200b_defconfig armhisi_defconfig x86_64 defconfig powerpcicon_defconfig sh sh7770_generic_defconfig riscv nommu_k210_sdcard_defconfig arm h5000_defconfig riscv rv32_defconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20210403 i386 randconfig-a003-20210403 i386 randconfig-a001-20210403 i386
Re: [PATCH 08/10] powerpc/signal32: Convert restore_[tm]_user_regs() to user access block
Le 19/03/2021 à 12:06, Christophe Leroy a écrit :
Convert restore_user_regs() and restore_tm_user_regs()
to use user_access_read_begin/end blocks.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ptrace.h | 2 +-
arch/powerpc/kernel/signal_32.c | 141 +++---
2 files changed, 72 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 088c83853026..0b1a6f53e553 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -567,19 +569,22 @@ static long restore_user_regs(struct pt_regs *regs,
regs->msr &= ~MSR_SPE;
if (msr & MSR_SPE) {
/* restore spe registers from the stack */
- if (__copy_from_user(current->thread.evr, >mc_vregs,
-ELF_NEVRREG * sizeof(u32)))
- return 1;
+ unsafe_copy_from_user(current->thread.evr, >mc_vregs,
+ ELF_NEVRREG * sizeof(u32));
Missing the , failed); here at the end of the line.
Michael can you add it ?
Thanks
Christophe
[PATCH] habanalabs: use strscpy instead of sprintf and strlcpy
Prefer the use of strscpy when copying the ASIC name into a char array,
to prevent accidentally exceeding the array's length.
In addition, strlcpy is frowned upon so replace it.
Signed-off-by: Oded Gabbay
---
drivers/misc/habanalabs/common/device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/habanalabs/common/device.c
b/drivers/misc/habanalabs/common/device.c
index e64c60d48d42..2ed4f2bedc08 100644
--- a/drivers/misc/habanalabs/common/device.c
+++ b/drivers/misc/habanalabs/common/device.c
@@ -321,11 +321,11 @@ static int device_early_init(struct hl_device *hdev)
switch (hdev->asic_type) {
case ASIC_GOYA:
goya_set_asic_funcs(hdev);
- strlcpy(hdev->asic_name, "GOYA", sizeof(hdev->asic_name));
+ strscpy(hdev->asic_name, "GOYA", sizeof(hdev->asic_name));
break;
case ASIC_GAUDI:
gaudi_set_asic_funcs(hdev);
- sprintf(hdev->asic_name, "GAUDI");
+ strscpy(hdev->asic_name, "GAUDI", sizeof(hdev->asic_name));
break;
default:
dev_err(hdev->dev, "Unrecognized ASIC type %d\n",
--
2.25.1
Re: [PATCH v3 00/30] staging: rtl8723bs: remove RT_TRACE logs in core/*
On Sat, Apr 03, 2021 at 09:17:37AM -0700, Joe Perches wrote: > On Sat, 2021-04-03 at 17:21 +0200, Fabio Aiuto wrote: > > On Sat, Apr 03, 2021 at 08:02:25AM -0700, Joe Perches wrote: > > > On Sat, 2021-04-03 at 11:13 +0200, Fabio Aiuto wrote: > > > > This patchset removes all RT_TRACE usages in core/ files. > > > > > > and hal and include and os_dep > > > > Hi, > > > > I was just about to send the second patchset relative to hal/ files. > > The whole has been split up in directories in order to reduce the > > number of patch per patchset > > > It's a good idea, but the patches relative to RT_TRACE removal > > could be huge > > That's really not a significant issue. > Simplicity in review is also important. > Mechanization of patch creation can reduce review efforts. Maybe I wrongly associated simplicity with patch dimensions, but maybe for patches this simple have expert reviewers some tool for automatic review? Is automatic review possible? > > Few people are actively working on this particular codebase. > As far as I can tell no logical defect is being corrected here. > None of this is likely to be backported. > > Applying each individual patch has a 'cost' in maintainer time > and review effort. got it > > Fewer patches create lower overall costs. > > Good luck... > I like your idea, and sure I will work in that direction, for this particular case I wait maintainer's opinion. If patchsets will be rejected again I will apply the scheme you proposed, if it will be accepted I will apply the scheme for next patchsets. Thank you, fabio
Re: [RFC v1 00/26] Add TDX Guest Support
On Sat, Apr 03, 2021 at 09:26:24AM -0700, Dave Hansen wrote: > On 4/2/21 2:32 PM, Andi Kleen wrote: > >> If we go this route, what are the rules and restrictions? Do we have to > >> say "no MMIO in #VE"? > > > > All we have to say is "No MMIO in #VE before getting thd TDVEINFO arguments" > > After that it can nest without problems. > > Well, not exactly. You still can't do things that will could cause a n > unbounded recusive #VE. > It doesn't seem *that* far fetched to think that someone might try to > defer some work or dump data to the console. I believe the main console code has reentry protection. I'm not sure about early_printk (with keep), buf it that's the case it probably should be fixed anyways. I can take a look at that. Not sure why deferring something would cause another #VE? > > If you nest before that the TDX will cause a triple fault. > > > > The code that cannot do it is a few lines in the early handler which > > runs with interrupts off. > > >> Which brings up another related point: How do you debug TD guests? Does > >> earlyprintk work? > > > > Today it works actually because serial ports are allowed. But I expect it to > > be closed eventually because serial code is a lot of code to audit. > > But you can always disable the filtering with a command line option and > > then it will always work for debugging. > > Do we need a TDX-specific earlyprintk? I would imagine it's pretty easy > to implement. Don't see a need at this point, the existing mechanisms work. Maybe if we ever have a problem that only happen in lockdown *and* happens early, but that's not very likely since lock down primarily changes code behavior later. There are also other debug mechanisms for such cases: in TDX if you configure the TD for debug mode supports using the gdb stub on the hypervisor. -Andi
[GIT PULL] gfs2 fixes for v5.12-rc6
Hi Linus, please consider pulling the following two gfs2 fixes for v5.12-rc6. Thanks, Andreas The following changes since commit b77b5fdd052e7ee61b35164abb10e8433d3160e8: Merge tag 'gfs2-v5.12-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2 (2021-03-12 11:46:09 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git tags/gfs2-v5.12-rc2-fixes2 for you to fetch changes up to ff132c5f93c06bd4432bbab5c369e468653bdec4: gfs2: report "already frozen/thawed" errors (2021-03-25 18:53:38 +0100) Two more gfs2 fixes Andrew Price (1): gfs2: Flag a withdraw if init_threads() fails Bob Peterson (1): gfs2: report "already frozen/thawed" errors fs/gfs2/super.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-)
Re: [PATCH v4 1/9] media: uapi: mpeg2: Rework quantization matrices semantics
Hi Nicolas, On Mon, 2021-03-29 at 16:53 -0400, Nicolas Dufresne wrote: > Le lundi 29 mars 2021 à 15:13 -0300, Ezequiel Garcia a écrit : > > As stated in the MPEG-2 specification, section 6.3.7 "Quant matrix > > extension": > > > > Each quantisation matrix has a default set of values. When a > > sequence_header_code is decoded all matrices shall be reset to > > their default values. User defined matrices may be downloaded > > and this can occur in a sequence_header() or in a > > quant_matrix_extension(). > > > > The load_intra_quantiser_matrix syntax elements are transmitted > > in the bistream headers, signalling that a quantization matrix > quantisation > > Not really a typo, just a suggestion to follow the specification spelling. I > would like to see concistant spelling the API. My rational is that you can > copy > and paste the strings when searching inside the specification PDF, and you > don't > mix both in the API like we do now. > Absolutely. Thanks for spotting this. > > needs to be loaded and used for pictures transmitted afterwards > > (until the matrices are reset). > > > > These "load" semantics are implemented in the V4L2 interface > > without the need of any "load" flags: passing the control > > is effectively a load. > > > > Therefore, rework the V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION > S > > > semantics to match the MPEG-2 semantics. Quantization matrices > s > > etc. > > > values are now initialized by the V4L2 control core to their > > reset default value, and applications are expected to reset > > their values as specified. > > > > The quantization control is therefore optional, and used to > > load bitstream-defined values in the quantization matrices. > > Perhaps: > > "The quantisation controls is therefore optional for decoding streams that > uses > the default matrices." > > A stack that would not handle the default, would have to read the control at > least once in order to avoid overriding valid values with 0s, not sure if that > is worth mentioning ? > Hm, not entirely sure. If application calls S_EXT_CTRL with 0s, then that's what will happen. Thanks, Ezequiel
