[PATCH] drm: sysfs: convert sysfs snprintf to sysfs_emit
From: Xuezhi Zhang Fix the following coccicheck warning: drivers/gpu/drm/drm_sysfs.c:172:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/drm_sysfs.c:185:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/drm_sysfs.c:159:8-16: WARNING: use scnprintf or sprintf Signed-off-by: Xuezhi Zhang --- drivers/gpu/drm/drm_sysfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index f0336c804..13142fd9d 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -156,7 +156,7 @@ static ssize_t status_show(struct device *device, status = READ_ONCE(connector->status); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", drm_get_connector_status_name(status)); } @@ -169,7 +169,7 @@ static ssize_t dpms_show(struct device *device, dpms = READ_ONCE(connector->dpms); - return snprintf(buf, PAGE_SIZE, "%s\n", + return sysfs_emit(buf, "%s\n", drm_get_dpms_name(dpms)); } @@ -182,7 +182,7 @@ static ssize_t enabled_show(struct device *device, enabled = READ_ONCE(connector->encoder); - return snprintf(buf, PAGE_SIZE, enabled ? "enabled\n" : "disabled\n"); + return sysfs_emit(buf, enabled ? "enabled\n" : "disabled\n"); } static ssize_t edid_show(struct file *filp, struct kobject *kobj, -- 2.25.1
arch/m68k/coldfire/pci.c:115:17: sparse: sparse: incorrect type in assignment (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 005b73d0dd83c9cb9420a196bea8070cde30ecac m68knommu: __force type casts for raw IO access date: 8 months ago config: m68k-randconfig-s032-20210403 (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=005b73d0dd83c9cb9420a196bea8070cde30ecac git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 005b73d0dd83c9cb9420a196bea8070cde30ecac # 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 >>) arch/m68k/coldfire/pci.c:80:26: sparse: sparse: cast to restricted __le16 arch/m68k/coldfire/pci.c:80:26: sparse: sparse: cast to restricted __le16 arch/m68k/coldfire/pci.c:80:26: sparse: sparse: cast to restricted __le16 arch/m68k/coldfire/pci.c:80:26: sparse: sparse: cast to restricted __le16 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:83:26: sparse: sparse: cast to restricted __le32 arch/m68k/coldfire/pci.c:112:17: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short volatile [usertype] @@ got restricted __le16 [usertype] @@ arch/m68k/coldfire/pci.c:112:17: sparse: expected unsigned short volatile [usertype] arch/m68k/coldfire/pci.c:112:17: sparse: got restricted __le16 [usertype] >> arch/m68k/coldfire/pci.c:115:17: sparse: sparse: incorrect type in >> assignment (different base types) @@ expected unsigned int volatile >> [usertype] @@ got restricted __le32 [usertype] @@ arch/m68k/coldfire/pci.c:115:17: sparse: expected unsigned int volatile [usertype] arch/m68k/coldfire/pci.c:115:17: sparse: got restricted __le32 [usertype] vim +115 arch/m68k/coldfire/pci.c bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 91 bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 92 static int mcf_pci_writeconfig(struct pci_bus *bus, unsigned int devfn, bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 93 int where, int size, u32 value) bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 94 { bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 95 unsigned long addr; bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 96 bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 97 if (bus->number == 0) { bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 98 if (mcf_host_slot2sid[PCI_SLOT(devfn)] == 0) bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 99 return PCIBIOS_SUCCESSFUL; bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 100 } bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 101 bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 102 addr = mcf_mk_pcicar(bus->number, devfn, where); bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 103 __raw_writel(PCICAR_E | addr, PCICAR); 082f55c4598450 arch/m68k/coldfire/pci.c Greg Ungerer 2018-04-11 104 __raw_readl(PCICAR); bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 105 addr = iospace + (where & 0x3); bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 106 bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 107 switch (size) { bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 108 case 1: bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 109 __raw_writeb(value, addr); bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05-29 110 break; bbdea849ed6ba6 arch/m68k/platform/coldfire/pci.c Greg Ungerer 2012-05
Re: [PATCH 3/5] crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
Le 03/04/2021 à 01:37, Sean Christopherson a écrit : Copy vmalloc'd data to an internal buffer instead of rejecting outright so that callers can put SEV command buffers on the stack without running afoul of CONFIG_VMAP_STACK=y. Currently, the largest supported command takes a 68 byte buffer, i.e. pretty much every command can be put on the stack. Because sev_cmd_mutex is held for the entirety of a transaction, only a single bounce buffer is required. Use a flexible array for the buffer, sized to hold the largest known command. Alternatively, the buffer could be a union of all known command structs, but that would incur a higher maintenance cost due to the need to update the union for every command in addition to updating the existing sev_cmd_buffer_len(). Align the buffer to an 8-byte boundary, mimicking the alignment that would be provided by the compiler if any of the structs were embedded directly. Note, sizeof() correctly incorporates this alignment. Cc: Brijesh Singh Cc: Borislav Petkov Cc: Tom Lendacky Signed-off-by: Sean Christopherson --- drivers/crypto/ccp/sev-dev.c | 33 +++-- drivers/crypto/ccp/sev-dev.h | 7 +++ 2 files changed, 34 insertions(+), 6 deletions(-) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index 4c513318f16a..6d5882290cfc 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -135,13 +135,14 @@ static int sev_cmd_buffer_len(int cmd) return 0; } -static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) +static int __sev_do_cmd_locked(int cmd, void *__data, int *psp_ret) { struct psp_device *psp = psp_master; struct sev_device *sev; unsigned int phys_lsb, phys_msb; unsigned int reg, ret = 0; int buf_len; + void *data; if (!psp || !psp->sev_data) return -ENODEV; @@ -152,11 +153,21 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) sev = psp->sev_data; buf_len = sev_cmd_buffer_len(cmd); - if (WARN_ON_ONCE(!!data != !!buf_len)) + if (WARN_ON_ONCE(!!__data != !!buf_len)) return -EINVAL; - if (WARN_ON_ONCE(data && is_vmalloc_addr(data))) - return -EINVAL; + if (__data && is_vmalloc_addr(__data)) { + /* +* If the incoming buffer is virtually allocated, copy it to +* the driver's scratch buffer as __pa() will not work for such +* addresses, vmalloc_to_page() is not guaranteed to succeed, +* and vmalloc'd data may not be physically contiguous. +*/ + data = sev->cmd_buf; + memcpy(data, __data, buf_len); + } else { + data = __data; + } I don't know how big commands are, but if they are small, it would probably be more efficient to inconditionnally copy them to the buffer rather then doing the test. /* Get the physical address of the command buffer */ phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0; @@ -204,6 +215,13 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) print_hex_dump_debug("(out): ", DUMP_PREFIX_OFFSET, 16, 2, data, buf_len, false); + /* +* Copy potential output from the PSP back to __data. Do this even on +* failure in case the caller wants to glean something from the error. +*/ + if (__data && data != __data) + memcpy(__data, data, buf_len); + return ret; } @@ -978,9 +996,12 @@ int sev_dev_init(struct psp_device *psp) { struct device *dev = psp->dev; struct sev_device *sev; - int ret = -ENOMEM; + int ret = -ENOMEM, cmd_buf_size = 0, i; - sev = devm_kzalloc(dev, sizeof(*sev), GFP_KERNEL); + for (i = 0; i < SEV_CMD_MAX; i++) + cmd_buf_size = max(cmd_buf_size, sev_cmd_buffer_len(i)); + + sev = devm_kzalloc(dev, sizeof(*sev) + cmd_buf_size, GFP_KERNEL); if (!sev) goto e_err; diff --git a/drivers/crypto/ccp/sev-dev.h b/drivers/crypto/ccp/sev-dev.h index dd5c4fe82914..b43283ce2d73 100644 --- a/drivers/crypto/ccp/sev-dev.h +++ b/drivers/crypto/ccp/sev-dev.h @@ -52,6 +52,13 @@ struct sev_device { u8 api_major; u8 api_minor; u8 build; + + /* +* Buffer used for incoming commands whose physical address cannot be +* resolved via __pa(), e.g. stack pointers when CONFIG_VMAP_STACK=y. +* Note, alignment isn't strictly required. +*/ + u8 cmd_buf[] __aligned(8); }; int sev_dev_init(struct psp_device *psp);
Re: [PATCH v3 00/30] staging: rtl8723bs: remove RT_TRACE logs in core/*
On Sat, Apr 03, 2021 at 01:02:04PM -0700, Joe Perches wrote: > 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. > > which tool provides an object code delta output suitable for a commit message? I dare a proposal apologizing in advance if this question should sound off topic, if it is please tell me how to ask it, is anyone of you all available being my mentor? I realized that what you told me in last weeks helps me a lot, and maybe a mentor can address me working towards more useful code bases. I choosed rtl8723bs quite by random, just to make experience in cleaning up code, and get more confident with required dev tools, but if there is some other task with higher priority that I could carry on, I will be glad to follow directives of a mentor. I really would like to become an expert kernel developer, and the way community works gets me more and more involved. Thank you again to all people helping me, fabio
[PATCH] net: ag71xx: Slightly simplify 'ag71xx_rx_packets()'
There is no need to use 'list_for_each_entry_safe' here, as nothing is removed from the list in the 'for' loop. Use 'list_for_each_entry' instead, it is slightly less verbose. Signed-off-by: Christophe JAILLET --- drivers/net/ethernet/atheros/ag71xx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c index a60ce9030581..7352f98123c7 100644 --- a/drivers/net/ethernet/atheros/ag71xx.c +++ b/drivers/net/ethernet/atheros/ag71xx.c @@ -1658,9 +1658,9 @@ static int ag71xx_rx_packets(struct ag71xx *ag, int limit) struct net_device *ndev = ag->ndev; int ring_mask, ring_size, done = 0; unsigned int pktlen_mask, offset; - struct sk_buff *next, *skb; struct ag71xx_ring *ring; struct list_head rx_list; + struct sk_buff *skb; ring = &ag->rx_ring; pktlen_mask = ag->dcfg->desc_pktlen_mask; @@ -1725,7 +1725,7 @@ static int ag71xx_rx_packets(struct ag71xx *ag, int limit) ag71xx_ring_rx_refill(ag); - list_for_each_entry_safe(skb, next, &rx_list, list) + list_for_each_entry(skb, &rx_list, list) skb->protocol = eth_type_trans(skb, ndev); netif_receive_skb_list(&rx_list); -- 2.27.0
Re: [PATCH 1/5] crypto: ccp: Detect and reject vmalloc addresses destined for PSP
Le 03/04/2021 à 01:36, Sean Christopherson a écrit : Explicitly reject vmalloc'd data as the source for SEV commands that are sent to the PSP. The PSP works with physical addresses, and __pa() will not return the correct address for a vmalloc'd pionter, which at best will cause the command to fail, and at worst lead to system instability. While it's unlikely that callers will deliberately use vmalloc() for SEV buffers, a caller can easily use a vmalloc'd pointer unknowingly when running with CONFIG_VMAP_STACK=y as it's not obvious that putting the command buffers on the stack would be bad. The command buffers are relative small and easily fit on the stack, and the APIs to do not document that the incoming pointer must be a physically contiguous, __pa() friendly pointer. Cc: Brijesh Singh Cc: Borislav Petkov Cc: Tom Lendacky Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Signed-off-by: Sean Christopherson --- drivers/crypto/ccp/sev-dev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c index cb9b4c4e371e..6556d220713b 100644 --- a/drivers/crypto/ccp/sev-dev.c +++ b/drivers/crypto/ccp/sev-dev.c @@ -150,6 +150,9 @@ static int __sev_do_cmd_locked(int cmd, void *data, int *psp_ret) sev = psp->sev_data; + if (data && WARN_ON_ONCE(is_vmalloc_addr(data))) + return -EINVAL; + I hadn't seen this patch when I commented the 2 other ones, I received it only this night. As commented in the other patches, is_vmalloc_addr() is not the best way to test that __pa() can be safely used. For that, you have virt_addr_valid() /* Get the physical address of the command buffer */ phys_lsb = data ? lower_32_bits(__psp_pa(data)) : 0; phys_msb = data ? upper_32_bits(__psp_pa(data)) : 0;
Re: [PATCH net 1/2] net: hns3: Remove the left over redundant check & assignment
On Sat, Apr 03, 2021 at 02:35:19AM +0100, Salil Mehta wrote: > This removes the left over check and assignment which is no longer used > anywhere in the function and should have been removed as part of the > below mentioned patch. > > Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling > reset_event") > Signed-off-by: Salil Mehta > --- > drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c > b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c > index e3f81c7e0ce7..7ad0722383f5 100644 > --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c > +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c > @@ -3976,8 +3976,6 @@ static void hclge_reset_event(struct pci_dev *pdev, > struct hnae3_handle *handle) >* want to make sure we throttle the reset request. Therefore, we will >* not allow it again before 3*HZ times. >*/ > - if (!handle) > - handle = &hdev->vport[0].nic; The comment above should be updated too, and probably the signature of hclge_reset_event() worth to be changed. Thanks > > if (time_before(jiffies, (hdev->last_reset_time + > HCLGE_RESET_INTERVAL))) { > -- > 2.17.1 >
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: ia64-allmodconfig (attached as .config) compiler: ia64-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=ia64 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) | ^~~~ >> drivers/thermal/qcom/tsens.c:922:1: warning: 'alias' attribute ignored >> [-Wattributes] 922 | MODULE_DEVICE_TABLE(of, tsens_table); | ^~~ drivers/thermal/qcom/tsens.c:925:14: error: initializer element is not constant 925 | .get_temp = tsens_get_temp, | ^~ drivers/thermal/qcom/tsens.c:925:14: note: (near initialization for 'tsens_of_ops.get_temp') drivers/thermal/qcom/tsens.c:926:15: error: initializer element is not constant 926 | .get_trend = tsens_get_trend, | ^~~ drivers/thermal/qcom/tsens.c:926:15: note: (near initialization for 'tsens_of_ops.get_trend') drivers/thermal/qcom/tsens.c:930:12: error: invalid storage class for function 'tsens_register_irq' 930 | static int tsens_register_irq(struct tsens_priv *priv, char *irqname, |^~ drivers/thermal/qcom/tsens.c:962:12: error: invalid storage class for function 'tsens_register' 962 | static int tsens_register(struct tsens_priv *priv) |^~ drivers/thermal/qcom/tsens.c:990:12: error: invalid storage class for function 'tsens_probe' 990 | static int tsens_probe(struct platform_device *pdev) |^~~ drivers/thermal/qcom/tsens.c:1064:12: error: invalid storage class for function 'tsens_remove' 1064 | static int tsens_remove(struct platform_device *pdev) |^~~~ drivers/thermal/qcom/tsens.c:1077:11: error: initializer element is not constant 1077 | .probe = tsens_probe, | ^~~ drivers/thermal/qcom/tsens.c:1077:11: note: (near initialization for 'tsens_driver.probe') drivers/thermal/qcom/tsens.c:1078:12: error: initializer element is not constant 1078 | .remove = tsens_remove, |^~~~ drivers/thermal/qcom/tsens.c:1078:12: note: (near initialization for 'tsens_driver.remove') In file included from include/linux/device.h:32, from include/linux/of_platform.h:9, from drivers/thermal/qcom/tsens.c:14: drivers/thermal/qcom/tsens.c:1085:24: error: invalid storage class for function 'tsens_driver_init' 1085 | module_platform_driver(tsens_driver); |^
Re: [PATCH net-next v1 4/9] net: dsa: qca: ar9331: make proper initial port defaults
Am 04.04.21 um 02:16 schrieb Vladimir Oltean: > 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. Sorry I overlooked this one > And the networking comment style is: > > /* CPU port should be allowed to communicate with all user >* ports. >*/ Aaa... networking part of kernel code... >> +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 > 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. ok. >> +/* 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. sounds good. Looks like there are few more driver need to be fixed: drivers/net/dsa/lan9303-core.c drivers/net/dsa/mv88e6xxx/chip.c > >> + | 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) >>
vdpa.c:undefined reference to `atomic64_read_386'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2023a53bdf41b7646b1d384b6816af06309f73a5 commit: 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1 vhost-vdpa: fix page pinning leakage in error path date: 6 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=7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1 # 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+0x322): undefined reference to `atomic64_set_386' /usr/bin/ld: kernel/futex.o: in function `get_futex_key': futex.c:(.text+0xc5a): undefined reference to `atomic64_read_386' /usr/bin/ld: futex.c:(.text+0xcc9): undefined reference to `atomic64_add_return_386' /usr/bin/ld: futex.c:(.text+0xcdc): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: mm/debug.o: in function `dump_mm': debug.c:(.text+0x275): 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+0x402): undefined reference to `atomic64_set_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_page_putback': z3fold.c:(.text+0x983): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_alloc': z3fold.c:(.text+0xd52): undefined reference to `atomic64_inc_386' /usr/bin/ld: z3fold.c:(.text+0x110d): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `z3fold_reclaim_page.constprop.0': z3fold.c:(.text+0x142f): undefined reference to `atomic64_dec_386' /usr/bin/ld: z3fold.c:(.text+0x18e5): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o: in function `do_compact_page': z3fold.c:(.text+0x1f93): undefined reference to `atomic64_dec_386' /usr/bin/ld: z3fold.c:(.text+0x23cc): undefined reference to `atomic64_dec_386' /usr/bin/ld: mm/z3fold.o:z3fold.c:(.text+0x2644): more undefined references to `atomic64_dec_386' follow /usr/bin/ld: fs/inode.o: in function `inode_init_always': inode.c:(.text+0x317): undefined reference to `atomic64_set_386' /usr/bin/ld: fs/inode.o: in function `generic_update_time': inode.c:(.text+0x1ffc): undefined reference to `atomic64_read_386' /usr/bin/ld: inode.c:(.text+0x203a): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: fs/inode.o: in function `file_update_time': inode.c:(.text+0x27ae): undefined reference to `atomic64_read_386' /usr/bin/ld: fs/namespace.o: in function `alloc_mnt_ns': namespace.c:(.text+0x23e): undefined reference to `atomic64_add_return_386' /usr/bin/ld: fs/io_uring.o: in function `io_account_mem': io_uring.c:(.text+0x112): undefined reference to `atomic64_add_386' /usr/bin/ld: fs/io_uring.o: in function `io_sqe_buffer_unregister': io_uring.c:(.text+0x79f): undefined reference to `atomic64_sub_386' /usr/bin/ld: fs/io_uring.o: in function `__se_sys_io_uring_register': io_uring.c:(.text+0xc987): undefined reference to `atomic64_sub_386' /usr/bin/ld: io_uring.c:(.text+0xcd73): undefined reference to `atomic64_sub_386' /usr/bin/ld: io_uring.c:(.text+0xcf0d): undefined reference to `atomic64_sub_386' /usr/bin/ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_iotlb_unmap': vdpa.c:(.text+0x1e2): undefined reference to `atomic64_sub_386' /usr/bin/ld: drivers/vhost/vdpa.o: in function `vhost_vdpa_process_iotlb_update': >> vdpa.c:(.text+0x491): undefined reference to `atomic64_read_386' /usr/bin/ld: vdpa.c:(.text+0x712): undefined reference to `atomic64_add_386' /usr/bin/ld: net/core/net_namespace.o: in function `net_gen_cookie': net_namespace.c:(.text+0x7ec): undefined reference to `atomic64_read_386' /usr/bin/ld: net_namespace.c:(.text+0x7fe): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: net_namespace.c:(.text+0x817): undefined reference to `cmpxchg8b_emu' /usr/bin/ld: net_namespace.c:(.text+0x81e): undefined reference to `atomic64_read_386' /usr/bin/ld: net/core/net_namespace.o: in function `net_ns_init': net_namespace.c:(.init.text+0x7b): undefined reference to `atomic64_read_386' /usr/bin/ld: net_namespace.c:(.init.text+0x268): undefined reference to `atomic64_inc_return_386' /usr/bin/ld: net_namespace.c:(.init.text+0x27f): undefined reference to `cmpxchg8b_emu' /usr/bi
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 flow
[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 = &Adapter->mlmepriv; @@ -156,10 +158,8 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter) Adapter->HalData->odmpriv.bLinked = bLinked; ODM_DMWatchdog(&Adapter->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(&ieee->skb_drv_aggQ[queue_index]) != 0) || + if ((skb_queue_len(&ieee->skb_drv_aggQ[queue_index]) != 0) #else - if ((skb_queue_len(&ieee->skb_waitQ[queue_index]) != 0) || + if ((skb_queue_len(&ieee->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 `atomic64_inc_3
[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], &ver_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: kernel
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 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() >> - ftrace_gra
/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' /usr
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 (&mm->mmap_lock#2){}-{3:3}, at: mmap_read_trylock include/linux/mmap_lock.h:136 [inline] #0: 8880129669d8 (&mm->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(&mask, 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
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' /usr/bin/ld:
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 `atomic64
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, &fdb->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, + &debugfs_devm_entry_ops); + if (IS_ERR(entry->dentry)) { + devres_free(entry); + return; + } - debugfs_create_file(name, S_IRUGO, parent, entry, - &debugfs_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, &f0); > + 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 = &priv->vdb[i]; > + break; > + } > + } > + > + ret = regmap_read(regmap, AR9331_SW_REG_VLAN_TABLE_FUNCTION1, &f1); > + 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 = &priv->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; >
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(&hugetlb_lock); >> + spin_lock_irq(&hugetlb_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: in
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' /usr/
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
onfig i386defconfig 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(&ctx->extcon_wq, sii8620_extcon_work); 688838442147d9 Maciej Purski2018-02-27 @2191ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->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(bridg
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 KFE
[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] = &cm_ops, + [RSMU_SABRE] = &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(&mode, 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(&state_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, &state); + mutex_unlock(rsmu->lock); + + state_request.state = state; + if (copy_to_user(arg, &state_request, sizeof(state_request))) + return -EFAULT; + + return err; +} + +static int +rsmu_get_dp
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 > &treq.req_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 > &treq.rsp_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, > &descp->req_header, > - &descp->input_param1, UFS_TSF_TM_INPUT); > + trace_ufshcd_upiu(dev_name(hba->dev), str_t, > + &descp->upiu_req.req_header, > + &descp->upiu_req.input_param1, > + UFS_TSF_TM_INPUT); > else > - trace_ufshcd_upiu(dev_name(hba->dev), str_t, > &descp->rsp_header, > - &descp->output_param1, UFS_TSF_TM_OUTPUT); > + trace_ufshcd_upiu(dev_name(hba->dev), str_t, > + &descp->upiu_rsp.rsp_header, > + &descp->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); > > er
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 (&iint->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 (&iint->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(&iint->mutex); lock(sb_writers#5); lock(&iint->mutex); lock(sb_writers#5); *** DEADLOCK *** 1 lock held by syz-executor144/9166: #0: 8880256d42c0 (&iint->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 i
[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 (&mm->mmap_lock#2){}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:87 [inline] #1: 8880286c0158 (&mm->mmap_lock#2){}-{3:3}, at: dup_mmap+0x87/0xde0 kernel/fork.c:480 #2: 8880286c2458 (&mm->mmap_lock/1){+.+.}-{3:3}, at: mmap_write_lock_nested include/linux/mmap_lock.h:78 [inline] #2: 8880286c2458 (&mm->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] 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] 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] 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` t
[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(&src_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(&src_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(&run->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(&run->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 a/drivers/staging/media/sunxi/cedru
[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:: |p{1.0cm}|p{5.6cm}
[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 v4l2_async
[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 f