Re: [PATCH] wl1251: Fix possible buffer overflow in wl1251_cmd_scan
Lee Gibson writes: > Function wl1251_cmd_scan calls memcpy without checking the length. > A user could control that length and trigger a buffer overflow. > Fix by checking the length is within the maximum allowed size. > > Signed-off-by: Lee Gibson Please fix the commit log, the user cannot control this length as cfg80211 checks it before handling it to wl1251. Unless I'm missing something. > --- > drivers/net/wireless/ti/wl1251/cmd.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ti/wl1251/cmd.c > b/drivers/net/wireless/ti/wl1251/cmd.c > index 498c8db2eb48..e4d028a53d91 100644 > --- a/drivers/net/wireless/ti/wl1251/cmd.c > +++ b/drivers/net/wireless/ti/wl1251/cmd.c > @@ -455,8 +455,11 @@ int wl1251_cmd_scan(struct wl1251 *wl, u8 *ssid, size_t > ssid_len, > } > > cmd->params.ssid_len = ssid_len; If you are checking the length, you should also check ssid_len here. > - if (ssid) > - memcpy(cmd->params.ssid, ssid, ssid_len); > + if (ssid) { > + int len = min_t(int, ssid_len, IEEE80211_MAX_SSID_LEN); > + > + memcpy(cmd->params.ssid, ssid, len); > + } Please use clamp_val(). Also another (and IMHO better) way to cleanup this is to provide a pointer to struct cfg80211_ssid, which makes it clear that the length can be trusted and not length checking is not needed. So something like this: int wl1251_cmd_scan(struct wl1251 *wl, const struct cfg80211_ssid *ssid, struct ieee80211_channel *channels[], unsigned int n_channels, unsigned int n_probes) -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2 00/16] Multigenerational LRU Framework
On Thu, Apr 15, 2021 at 01:13:13AM -0600, Yu Zhao wrote: > Page table scanning doesn't replace the existing rmap walk. It is > complementary and only happens when it is likely that most of the > pages on a system under pressure have been referenced, i.e., out of > *inactive* pages, by definition of the existing implementation. Under > such a condition, scanning *active* pages one by one with the rmap is > likely to cost more than scanning them all at once via page tables. > When we evict *inactive* pages, we still use the rmap and share a > common path with the existing code. > > Page table scanning falls back to the rmap walk if the page tables of > a process are apparently sparse, i.e., rss < size of the page tables. Could you expand a bit more as to how page table scanning and rmap scanning coexist ? Say, there is some memory pressure and you want to identify good candidate pages to recaim. You could scan processes with the page table scanning method, or you could scan the lru list through the rmap method. How do you mix the two - when you use the lru/rmap method, won't you encounter both pages that are mapped in "dense" processes where scanning page tables would have been better, and pages that are mapped in "sparse" processes where you are happy to be using rmap, and even pges that are mapped into both types of processes at once ? Or, can you change the lru/rmap scan so that it will efficiently skip over all dense processes when you use it ? Thanks, -- Michel "walken" Lespinasse
Re: [PATCH] bcma: remove unused function
Jiapeng Chong wrote: > Fix the following clang warning: > > drivers/bcma/driver_mips.c:55:20: warning: unused function > 'mips_write32' [-Wunused-function]. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Patch applied to wireless-drivers-next.git, thanks. fa84df705260 bcma: remove unused function -- https://patchwork.kernel.org/project/linux-wireless/patch/1618382354-866-1-git-send-email-jiapeng.ch...@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] wil6210: wmi: Remove useless code
Jiapeng Chong wrote: > Fix the following whitescan warning: > > An unsigned value can never be less than 0. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Patch applied to wireless-drivers-next.git, thanks. 5e6087559e85 wil6210: wmi: Remove useless code -- https://patchwork.kernel.org/project/linux-wireless/patch/1617788766-91433-1-git-send-email-jiapeng.ch...@linux.alibaba.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] carl9170: remove get_tid_h
Christophe JAILLET wrote: > 'get_tid_h()' is the same as 'ieee80211_get_tid()'. > So this function can be removed to save a few lines of code. > > Signed-off-by: Christophe JAILLET > Acked-by: Christian Lamparter Patch applied to wireless-drivers-next.git, thanks. cf366b154704 carl9170: remove get_tid_h -- https://patchwork.kernel.org/project/linux-wireless/patch/68efad7a597159e22771d37fc8b4a8a613866d60.1617399010.git.christophe.jail...@wanadoo.fr/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwl8k: Fix a double Free in mwl8k_probe_hw
Lv Yunlong wrote: > In mwl8k_probe_hw, hw->priv->txq is freed at the first time by > dma_free_coherent() in the call chain: > if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i). > > Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed > at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent(). > > My patch set txq->txd to NULL after the first free to avoid the > double free. > > Fixes: a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver") > Signed-off-by: Lv Yunlong Patch applied to wireless-drivers-next.git, thanks. a8e083ee8e2a mwl8k: Fix a double Free in mwl8k_probe_hw -- https://patchwork.kernel.org/project/linux-wireless/patch/20210402182627.4256-1-lyl2...@mail.ustc.edu.cn/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [1/4] brcmfmac: Remove duplicate struct declaration
Wan Jiabing wrote: > struct brcmf_bus is declared twice. One has been declared > at 37th line. Remove the duplicate. > > Signed-off-by: Wan Jiabing 2 patches applied to wireless-drivers-next.git, thanks. d663bc3317c9 brcmfmac: Remove duplicate struct declaration 444a9af68b5c wilc1000: Remove duplicate struct declaration -- https://patchwork.kernel.org/project/linux-wireless/patch/20210331023557.2804128-2-wanjiab...@vivo.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [2/2] wl3501: fix typo of 'Networks' in comment
Eric Lin wrote: > Signed-off-by: Eric Lin > Reported-by: Gustavo A. R. Silva Patch applied to wireless-drivers-next.git, thanks. 7f50ddc5d4fe wl3501: fix typo of 'Networks' in comment -- https://patchwork.kernel.org/project/linux-wireless/patch/20210331010418.1632816-2-dslin1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: libertas: struct lbs_private is declared duplicately
Wan Jiabing wrote: > struct lbs_private has been declared at 22nd line. > Remove the duplicate. > > Signed-off-by: Wan Jiabing Patch applied to wireless-drivers-next.git, thanks. d3240418a662 libertas: struct lbs_private is declared duplicately -- https://patchwork.kernel.org/project/linux-wireless/patch/20210325064154.854245-1-wanjiab...@vivo.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] brcmfmac: A typo fix
Bhaskar Chowdhury wrote: > s/revsion/revision/ > > Signed-off-by: Bhaskar Chowdhury Patch applied to wireless-drivers-next.git, thanks. 705b5cfab183 brcmfmac: A typo fix -- https://patchwork.kernel.org/project/linux-wireless/patch/20210323043657.1466296-1-unixbhas...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v2] rsi: fix comment syntax in file headers
Aditya Srivastava wrote: > The opening comment mark '/**' is used for highlighting the beginning of > kernel-doc comments. > There are some files in drivers/net/wireless/rsi which follow this syntax > in their file headers, i.e. start with '/**' like comments, which causes > unexpected warnings from kernel-doc. > > E.g., running scripts/kernel-doc -none on drivers/net/wireless/rsi/rsi_coex.h > causes this warning: > "warning: wrong kernel-doc identifier on line: > * Copyright (c) 2018 Redpine Signals Inc." > > Similarly for other files too. > > Provide a simple fix by replacing such occurrences with general comment > format, i.e., "/*", to prevent kernel-doc from parsing it. > > Signed-off-by: Aditya Srivastava > Reviewed-by: Randy Dunlap Patch applied to wireless-drivers-next.git, thanks. 3051946056c3 rsi: fix comment syntax in file headers -- https://patchwork.kernel.org/project/linux-wireless/patch/20210315173259.8757-1-yashsri...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] hostap: Fix memleak in prism2_config
Dinghao Liu wrote: > When prism2_hw_config() fails, we just return an error code > without any resource release, which may lead to memleak. > > Signed-off-by: Dinghao Liu Nobody reviewed this, so dropping the patch. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210329085246.24586-1-dinghao@zju.edu.cn/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] brcmsmac: fix shift on 4 bit masked value
Colin King wrote: > From: Colin Ian King > > The calculation of offtune_val seems incorrect, the u16 value in > pi->tx_rx_cal_radio_saveregs[2] is being masked with 0xf0 and then > shifted 8 places right so that always ends up as a zero result. I > believe the intended shift was 4 bits to the right. Fix this. > > [Note: not tested, I don't have the H/W] > > Addresses-Coverity: ("Operands don't affect result") > Fixes: 5b435de0d786 ("net: wireless: add brcm80211 drivers") > Signed-off-by: Colin Ian King I think this needs review from someone familiar with the hardware. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210318164513.19600-1-colin.k...@canonical.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] base: power: runtime.c: Remove a unnecessary space
Remove a redundant space to improve the quality of the comment. Signed-off-by: Sebastian Fricke --- Side-note: I found this while reading the code, I don't believe it is important but I thought it doesn't hurt to fix it. --- drivers/base/power/runtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 18b82427d0cb..499434b84171 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -786,7 +786,7 @@ static int rpm_resume(struct device *dev, int rpmflags) } /* -* See if we can skip waking up the parent. This is safe only if +* See if we can skip waking up the parent. This is safe only if * power.no_callbacks is set, because otherwise we don't know whether * the resume will actually succeed. */ -- 2.25.1
[PATCH v2 2/2] mmc: block: Update ext_csd.cache_ctrl if it was written
The cache function can be turned ON and OFF by writing to the CACHE_CTRL byte (EXT_CSD byte [33]). However, card->ext_csd.cache_ctrl is only set on init if cache size > 0. Fix that by explicitly setting ext_csd.cache_ctrl on ext-csd write. Signed-off-by: Avri Altman --- drivers/mmc/core/block.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index 6800feb70c92..0372702231ce 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -572,6 +572,18 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md, main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK; } + /* +* Make sure to update CACHE_CTRL in case it was changed. The cache +* will get turned back on if the card is re-initialized, e.g. +* suspend/resume or hw reset in recovery. +*/ + if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_CACHE_CTRL) && + (cmd.opcode == MMC_SWITCH)) { + u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg) & 1; + + card->ext_csd.cache_ctrl = value; + } + /* * According to the SD specs, some commands require a delay after * issuing the command. -- 2.25.1
[PATCH v2 1/2] mmc: block: Issue flush only if allowed
The cache may be flushed to the nonvolatile storage by writing to FLUSH_CACHE byte (EXT_CSD byte [32]). When in command queueing mode, the cache may be flushed by issuing a CMDQ_TASK_ DEV_MGMT (CMD48) with a FLUSH_CACHE op-code. Either way, verify that The cache function is turned ON before doing so. fixes: 1e8e55b67030 (mmc: block: Add CQE support) Reported-by: Brendan Peter Tested-by: Brendan Peter Signed-off-by: Avri Altman --- drivers/mmc/core/block.c | 7 +++ drivers/mmc/core/mmc_ops.c | 4 +--- drivers/mmc/core/mmc_ops.h | 5 + 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c index fe5892d30778..6800feb70c92 100644 --- a/drivers/mmc/core/block.c +++ b/drivers/mmc/core/block.c @@ -1476,6 +1476,11 @@ static int mmc_blk_cqe_issue_flush(struct mmc_queue *mq, struct request *req) struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req); struct mmc_request *mrq = mmc_blk_cqe_prep_dcmd(mqrq, req); + if (mmc_card_mmc(mq->card) && !mmc_flush_allowed(mq->card)) { + blk_mq_end_request(req, BLK_STS_OK); + return -EPERM; + } + mrq->cmd->opcode = MMC_SWITCH; mrq->cmd->arg = (MMC_SWITCH_MODE_WRITE_BYTE << 24) | (EXT_CSD_FLUSH_CACHE << 16) | @@ -2226,6 +2231,8 @@ enum mmc_issued mmc_blk_mq_issue_rq(struct mmc_queue *mq, struct request *req) switch (req_op(req)) { case REQ_OP_FLUSH: ret = mmc_blk_cqe_issue_flush(mq, req); + if (ret == -EPERM) + return MMC_REQ_FINISHED; break; case REQ_OP_READ: case REQ_OP_WRITE: diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index f413474f0f80..9c2a665be034 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -967,9 +967,7 @@ int mmc_flush_cache(struct mmc_card *card) { int err = 0; - if (mmc_card_mmc(card) && - (card->ext_csd.cache_size > 0) && - (card->ext_csd.cache_ctrl & 1)) { + if (mmc_card_mmc(card) && mmc_flush_allowed(card)) { err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_FLUSH_CACHE, 1, MMC_CACHE_FLUSH_TIMEOUT_MS); diff --git a/drivers/mmc/core/mmc_ops.h b/drivers/mmc/core/mmc_ops.h index 632009260e51..bf2b315addd7 100644 --- a/drivers/mmc/core/mmc_ops.h +++ b/drivers/mmc/core/mmc_ops.h @@ -19,6 +19,11 @@ enum mmc_busy_cmd { struct mmc_host; struct mmc_card; +static inline bool mmc_flush_allowed(struct mmc_card *card) +{ + return card->ext_csd.cache_size > 0 && (card->ext_csd.cache_ctrl & 1); +} + int mmc_select_card(struct mmc_card *card); int mmc_deselect_cards(struct mmc_host *host); int mmc_set_dsr(struct mmc_host *host); -- 2.25.1
[PATCH v2 0/2] Do not flush cache when it is disabled
v1 -> v2: - Attend Adrian's comments Cache is a temporary storage space in an eMMC device. Volatile by nature, the cache should in typical case reduce the access time compared to an access to the main nonvolatile storage. The cache function can be turned ON and OFF. Once OFF, the host is not expected to issue a flush-cache command to the device. Avri Altman (2): mmc: block: Issue flush only if allowed mmc: block: Update ext_csd.cache_ctrl if it was written drivers/mmc/core/block.c | 19 +++ drivers/mmc/core/mmc_ops.c | 4 +--- drivers/mmc/core/mmc_ops.h | 5 + 3 files changed, 25 insertions(+), 3 deletions(-) -- 2.25.1
Re: [PATCH] rtl8xxxu: Fix device info for RTL8192EU devices
Pascal Terjan wrote: > Based on 2001:3319 and 2357:0109 which I used to test the fix and > 0bda:818b and 2357:0108 for which I found efuse dumps online. > > == 2357:0109 == > === Before === > Vendor: Realtek > Product: \x03802.11n NI > Serial: > === After === > Vendor: Realtek > Product: 802.11n NIC > Serial not available. > > == 2001:3319 == > === Before === > Vendor: Realtek > Product: Wireless N > Serial: no USB Adap > === After === > Vendor: Realtek > Product: Wireless N Nano USB Adapter > Serial not available. > > Signed-off-by: Pascal Terjan Can someone review this, please? Patch set to Deferred. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210323193617.3748164-1-pter...@google.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rsi: fix error return code of rsi_load_9116_firmware()
Jia-Ju Bai wrote: > When kmemdup() returns NULL to ta_firmware, no error return code of > rsi_load_9116_firmware() is assigned. > To fix this bug, status is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307083445.21322-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_cmd_build_ps_poll()
Jia-Ju Bai wrote: > When ieee80211_pspoll_get() returns NULL to skb, no error return code of > wl1271_cmd_build_ps_poll() is assigned. > To fix this bug, ret is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210307082906.20950-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] ti: wlcore: fix error return code of wl1271_suspend()
Jia-Ju Bai wrote: > When wl is NULL, no error return code of wl1271_suspend() is assigned. > To fix this bug, ret is assigned with -EINVAL in this case. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210306143600.19676-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] marvell: libertas_tf: fix error return code of if_usb_prog_firmware()
Jia-Ju Bai wrote: > When check_fwfile_format() fails, no error return code of > if_usb_prog_firmware() is assigned. > To fix this bug, ret is assigned with -EINVAL as error return code. > > Reported-by: TOTE Robot > Signed-off-by: Jia-Ju Bai Someone needs to review this. Patch set to Changes Requested. -- https://patchwork.kernel.org/project/linux-wireless/patch/20210305033115.6015-1-baijiaju1...@gmail.com/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH 2/2] kconfig: highlight xconfig 'comment' lines with '***'
Mark Kconfig "comment" lines with "*** ***" so that it is clear that these lines are comments and not some kconfig item that cannot be modified. This is helpful in some menus to be able to provide a menu "sub-heading" for groups of similar config items. This also makes the comments be presented in a way that is similar to menuconfig and nconfig. Signed-off-by: Randy Dunlap Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org --- scripts/kconfig/qconf.cc |1 + 1 file changed, 1 insertion(+) --- linux-next-20210416.orig/scripts/kconfig/qconf.cc +++ linux-next-20210416/scripts/kconfig/qconf.cc @@ -122,6 +122,7 @@ void ConfigItem::updateMenu(void) goto set_prompt; case P_COMMENT: setIcon(promptColIdx, QIcon()); + prompt = "*** " + prompt + " ***"; goto set_prompt; default: ;
[PATCH 1/2] kconfig: highlight gconfig 'comment' lines with '***'
Mark Kconfig "comment" lines with "*** ***" so that it is clear that these lines are comments and not some kconfig item that cannot be modified. This is helpful in some menus to be able to provide a menu "sub-heading" for groups of similar config items. This also makes the comments be presented in a way that is similar to menuconfig and nconfig. Signed-off-by: Randy Dunlap Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org --- scripts/kconfig/gconf.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- linux-next-20210416.orig/scripts/kconfig/gconf.c +++ linux-next-20210416/scripts/kconfig/gconf.c @@ -1048,8 +1048,13 @@ static gchar **fill_row(struct menu *men g_free(row[i]); bzero(row, sizeof(row)); + ptype = menu->prompt ? menu->prompt->type : P_UNKNOWN; + row[COL_OPTION] = - g_strdup_printf("%s %s", menu_get_prompt(menu), + g_strdup_printf("%s %s %s %s", + ptype == P_COMMENT ? "***" : "", + menu_get_prompt(menu), + ptype == P_COMMENT ? "***" : "", sym && !sym_has_value(sym) ? "(NEW)" : ""); if (opt_mode == OPT_ALL && !menu_is_visible(menu)) @@ -1060,7 +1065,6 @@ static gchar **fill_row(struct menu *men else row[COL_COLOR] = g_strdup("Black"); - ptype = menu->prompt ? menu->prompt->type : P_UNKNOWN; switch (ptype) { case P_MENU: row[COL_PIXBUF] = (gchar *) xpm_menu;
Re: [PATCH 1/2] srcu: Fix broken node geometry after early ssp init
On Sat, Apr 17, 2021 at 03:16:49PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 14, 2021 at 08:55:38AM -0700, Paul E. McKenney wrote: > > > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h > > > index 75ed367d5b60..24db97cbf76b 100644 > > > --- a/kernel/rcu/rcu.h > > > +++ b/kernel/rcu/rcu.h > > > @@ -278,6 +278,7 @@ extern void resched_cpu(int cpu); > > > extern int rcu_num_lvls; > > > extern int num_rcu_lvl[]; > > > extern int rcu_num_nodes; > > > +extern bool rcu_geometry_initialized; > > > > Can this be a static local variable inside rcu_init_geometry()? > > > > After all, init_srcu_struct() isn't called all that often, and its overhead > > is such that an extra function call and check is going to hurt it. This > > of course requires removing __init from rcu_init_geometry(), but it is not > > all that large, so why not just remove the __init? > > > > But if we really are worried about reclaiming rcu_init_geometry()'s > > instructions (maybe we are?), then rcu_init_geometry() can be split > > into a function that just does the check (which is not __init) and the > > remainder of the function, which could remain __init. > > There you go: Queued, thank you! Thanx, Paul > --- > From: Frederic Weisbecker > Date: Wed, 31 Mar 2021 16:10:36 +0200 > Subject: [PATCH] srcu: Fix broken node geometry after early ssp init > > An ssp initialized before rcu_init_geometry() will have its snp hierarchy > based on CONFIG_NR_CPUS. > > Once rcu_init_geometry() is called, the nodes distribution is shrinked > and optimized toward meeting the actual possible number of CPUs detected > on boot. > > Later on, the ssp that was initialized before rcu_init_geometry() is > confused and sometimes refers to its initial CONFIG_NR_CPUS based node > hierarchy, sometimes to the new num_possible_cpus() based one instead. > For example each of its sdp->mynode remain backward and refer to the > early node leaves that may not exist anymore. On the other hand the > srcu_for_each_node_breadth_first() refers to the new node hierarchy. > > There are at least two bad possible outcomes to this: > > 1) a) A callback enqueued early on an sdp is recorded pending on > sdp->mynode->srcu_data_have_cbs in srcu_funnel_gp_start() with > sdp->mynode pointing to a deep leaf (say 3 levels). > >b) The grace period ends after rcu_init_geometry() which shrinks the > nodes level to a single one. srcu_gp_end() walks through the new > snp hierarchy without ever reaching the old leaves so the callback > is never executed. > >This is easily reproduced on an 8 CPUs machine with >CONFIG_NR_CPUS >= 32 and "rcupdate.rcu_self_test=1". The >srcu_barrier() after early tests verification never completes and >the boot hangs: > > [ 5413.141029] INFO: task swapper/0:1 blocked for more than 4915 > seconds. > [ 5413.147564] Not tainted 5.12.0-rc4+ #28 > [ 5413.151927] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" > disables this message. > [ 5413.159753] task:swapper/0 state:D stack:0 pid:1 ppid: > 0 flags:0x4000 > [ 5413.168099] Call Trace: > [ 5413.170555] __schedule+0x36c/0x930 > [ 5413.174057] ? wait_for_completion+0x88/0x110 > [ 5413.178423] schedule+0x46/0xf0 > [ 5413.181575] schedule_timeout+0x284/0x380 > [ 5413.185591] ? wait_for_completion+0x88/0x110 > [ 5413.189957] ? mark_held_locks+0x61/0x80 > [ 5413.193882] ? mark_held_locks+0x61/0x80 > [ 5413.197809] ? _raw_spin_unlock_irq+0x24/0x50 > [ 5413.202173] ? wait_for_completion+0x88/0x110 > [ 5413.206535] wait_for_completion+0xb4/0x110 > [ 5413.210724] ? srcu_torture_stats_print+0x110/0x110 > [ 5413.215610] srcu_barrier+0x187/0x200 > [ 5413.219277] ? rcu_tasks_verify_self_tests+0x50/0x50 > [ 5413.224244] ? rdinit_setup+0x2b/0x2b > [ 5413.227907] rcu_verify_early_boot_tests+0x2d/0x40 > [ 5413.232700] do_one_initcall+0x63/0x310 > [ 5413.236541] ? rdinit_setup+0x2b/0x2b > [ 5413.240207] ? rcu_read_lock_sched_held+0x52/0x80 > [ 5413.244912] kernel_init_freeable+0x253/0x28f > [ 5413.249273] ? rest_init+0x250/0x250 > [ 5413.252846] kernel_init+0xa/0x110 > [ 5413.256257] ret_from_fork+0x22/0x30 > > 2) An ssp that gets initialized before rcu_init_geometry() and used >afterward will always have stale rdp->mynode references, resulting in >callbacks to be missed in srcu_gp_end(), just like in the previous >scenario. > > Solve this with initializing nodes geometry whenever an struct srcu_state > happens to be initialized before rcu_init(). This way we make sure the > RCU nodes hierarchy is properly built and distributed before the nodes > of an struct srcu_state are allocated. > > Suggested-by: Paul E. McKenney > Signed-off-by: Frederic Weisbecker > Cc: Boqun Feng > Cc: Lai J
[Patch] blk-wbt: fix a divide-by-zero error in rwb_arm_timer()
From: Cong Wang We hit a divide error in rwb_arm_timer() and crash dump shows rqd->scale_step is 16777215 (0xff in hex), so the expression "(rqd->scale_step + 1) << 8)" is 0x1, which is just beyond 32-bit integer range, hence it is truncated to 0 and int_sqrt(0) returns 0 too, so we end up passing 0 as a divisor to div_u64(). Looking at the assembly code generated: add$0x1,%edi shl$0x8,%edi movslq %edi,%rdi mov0x10(%rbx),%rdi xor%edx,%edx mov%eax,%ecx shl$0x4,%rdi mov%rdi,%rax div%rcx we notice that the left shift is still using 32 bit register %edi, because the type of rqd->scale_step is 'int'. But actually int_sqrt() takes 'long' as a parameter, so the temporary result should fit well at least on x86_64. Fix this by explicitly casting the expression to u64 and call int_sqrt64() to avoid any ambiguity on 32 bit. After this patch, the assembly code looks correct: add$0x1,%edi movslq %edi,%rdi shl$0x8,%rdi mov0x10(%rbx),%rdi xor%edx,%edx mov%eax,%ecx shl$0x4,%rdi mov%rdi,%rax div%rcx Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism") Cc: Jens Axboe Cc: Fam Zheng Cc: Xiongchun Duan Signed-off-by: Cong Wang --- block/blk-wbt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index 42aed0160f86..5157ca86574f 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -337,7 +337,7 @@ static void rwb_arm_timer(struct rq_wb *rwb) * though. */ rwb->cur_win_nsec = div_u64(rwb->win_nsec << 4, - int_sqrt((rqd->scale_step + 1) << 8)); + int_sqrt64((u64)(rqd->scale_step + 1) << 8)); } else { /* * For step < 0, we don't want to increase/decrease the -- 2.25.1
Re: PROBLEM: DoS Attack on Fragment Cache
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote: > Sure, there are better ways to handle the reassembly cache overflowing, but > that is pretty unrelated to the fact that waiting 30 full seconds for a > fragment to come in doesn't really make sense in today's networks (the 30 > second delay that is used today appears to even be higher than RFC 791 > suggested in 1981!). Not exactly actually, because you forget the TTL here. With most hosts sending an initial TTL around 64, after crossing 10-15 hops it's still around 50 so that would result in ~50 seconds by default, even according to the 40 years old RFC791. The 15s there was the absolute minimum. While I do agree that we shouldn't keep them that long nowadays, we can't go too low without risking to break some slow transmission stacks (SLIP/PPP over modems for example). In addition even cutting that in 3 will remain trivially DoSable. > You get a lot more bang for your buck if you don't wait > around so long (or we could restructure things to kick out the oldest > fragments, but that is a lot more work, and probably extra indexes that just > aren't worth it). Kicking out oldest ones is a bad approach in a system made only of independent elements, because it tends to result in a lot of damage once all of them behave similarly. I.e. if you need to kick out an old entry in valid traffic, it's because you do need to wait that long, and if all datagrams need to wait that long, then new datagrams systematically prevent the oldest one from being reassembled, and none gest reassembled. With a random approach at least your success ratio converges towards 1/e (i.e. 36%) which is better. Willy
Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board
On Sat, Apr 17, 2021 at 8:36 PM Atish Patra wrote: > > On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool wrote: > > > > On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote: > > > > > > Hi Atish, > > > > > > Le 3/3/21 à 3:02 PM, Atish Patra a écrit : > > > > Add initial DTS for Microchip ICICLE board having only > > > > essential devices (clocks, sdhci, ethernet, serial, etc). > > > > The device tree is based on the U-Boot patch. > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/ > > > > > > > > Signed-off-by: Atish Patra > > > > --- > > > > arch/riscv/boot/dts/Makefile | 1 + > > > > arch/riscv/boot/dts/microchip/Makefile| 2 + > > > > .../microchip/microchip-mpfs-icicle-kit.dts | 72 > > > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++ > > > > 4 files changed, 404 insertions(+) > > > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile > > > > create mode 100644 > > > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > > > > > > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > > > > index 7ffd502e3e7b..fe996b88319e 100644 > > > > --- a/arch/riscv/boot/dts/Makefile > > > > +++ b/arch/riscv/boot/dts/Makefile > > > > @@ -1,5 +1,6 @@ > > > > # SPDX-License-Identifier: GPL-2.0 > > > > subdir-y += sifive > > > > subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan > > > > +subdir-y += microchip > > > > > > > > obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y)) > > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile > > > > b/arch/riscv/boot/dts/microchip/Makefile > > > > new file mode 100644 > > > > index ..622b12771fd3 > > > > --- /dev/null > > > > +++ b/arch/riscv/boot/dts/microchip/Makefile > > > > @@ -0,0 +1,2 @@ > > > > +# SPDX-License-Identifier: GPL-2.0 > > > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb > > > > > > I'm playing (or trying to...) with XIP_KERNEL and I had to add the > > > following to have the device tree actually builtin the kernel: > > > > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile > > > b/arch/riscv/boot/dts/microchip/Makefile > > > index 622b12771fd3..855c1502d912 100644 > > > --- a/arch/riscv/boot/dts/microchip/Makefile > > > +++ b/arch/riscv/boot/dts/microchip/Makefile > > > @@ -1,2 +1,3 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb > > > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y)) > > > > > > Alex > > > > Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire, > > regardless of whether the kernel is XIP or not. > > > > But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel. > The bootloaders for polarfire is capable of providing a DTB to kernel. > > If XIP kernel is enabled, the following line in > arch/riscv/boot/dts/Makefile should take care of things > (Sorry. The mail was sent by mistake earlier with incomplete response) Otherwise, we need a similar change for unleashed as well. No ? > > > Best regards, > >Vitaly > > > > > > diff --git > > > > a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > > new file mode 100644 > > > > index ..ec79944065c9 > > > > --- /dev/null > > > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > > @@ -0,0 +1,72 @@ > > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > > > > +/* Copyright (c) 2020 Microchip Technology Inc */ > > > > + > > > > +/dts-v1/; > > > > + > > > > +#include "microchip-mpfs.dtsi" > > > > + > > > > +/* Clock frequency (in Hz) of the rtcclk */ > > > > +#define RTCCLK_FREQ 100 > > > > + > > > > +/ { > > > > + #address-cells = <2>; > > > > + #size-cells = <2>; > > > > + model = "Microchip PolarFire-SoC Icicle Kit"; > > > > + compatible = "microchip,mpfs-icicle-kit"; > > > > + > > > > + chosen { > > > > + stdout-path = &serial0; > > > > + }; > > > > + > > > > + cpus { > > > > + timebase-frequency = ; > > > > + }; > > > > + > > > > + memory@8000 { > > > > + device_type = "memory"; > > > > + reg = <0x0 0x8000 0x0 0x4000>; > > > > + clocks = <&clkcfg 26>; > > > > + }; > > > > + > > > > + soc { > > > > + }; > > > > +}; > > > > + > > > > +&serial0 { > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&serial1 { > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&serial2 { > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&serial3 { > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&sdcard { > > > > + status = "okay"; > > > > +}; > > > > + > > > > +&emac0 { > > > > + phy-mode
Re: [PATCH 5/9] sched: prctl() core-scheduling interface
On Wed, Apr 07, 2021 at 07:00:33PM +0200, Peter Zijlstra wrote: > On Thu, Apr 01, 2021 at 03:10:17PM +0200, Peter Zijlstra wrote: > > > Current hard-coded policies are: > > > > - a user can clear the cookie of any process they can set a cookie for. > >Lack of a cookie *might* be a security issue if cookies are being used > >for that. > > ChromeOS people, what are you doing about this? syscall/prctl filtering? Yes, in ChromeOS, we allow the prctl(2) syscall only before entering the seccomp sandbox. Once we enter the sandbox, we do not allow the prctl(2). This has the nice design that the security is enforced on entering the sandbox, and prior to entering the sandbox, no permissions need be given. Let me know if that makes sense and if you had any other questions. thanks, -Joel
Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board
On Mon, Mar 29, 2021 at 10:04 AM Vitaly Wool wrote: > > On Sat, Mar 27, 2021 at 6:24 PM Alex Ghiti wrote: > > > > Hi Atish, > > > > Le 3/3/21 à 3:02 PM, Atish Patra a écrit : > > > Add initial DTS for Microchip ICICLE board having only > > > essential devices (clocks, sdhci, ethernet, serial, etc). > > > The device tree is based on the U-Boot patch. > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20201110103414.10142-6-padmarao.beg...@microchip.com/ > > > > > > Signed-off-by: Atish Patra > > > --- > > > arch/riscv/boot/dts/Makefile | 1 + > > > arch/riscv/boot/dts/microchip/Makefile| 2 + > > > .../microchip/microchip-mpfs-icicle-kit.dts | 72 > > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++ > > > 4 files changed, 404 insertions(+) > > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile > > > create mode 100644 > > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > > > > > diff --git a/arch/riscv/boot/dts/Makefile b/arch/riscv/boot/dts/Makefile > > > index 7ffd502e3e7b..fe996b88319e 100644 > > > --- a/arch/riscv/boot/dts/Makefile > > > +++ b/arch/riscv/boot/dts/Makefile > > > @@ -1,5 +1,6 @@ > > > # SPDX-License-Identifier: GPL-2.0 > > > subdir-y += sifive > > > subdir-$(CONFIG_SOC_CANAAN_K210_DTB_BUILTIN) += canaan > > > +subdir-y += microchip > > > > > > obj-$(CONFIG_BUILTIN_DTB) := $(addsuffix /, $(subdir-y)) > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile > > > b/arch/riscv/boot/dts/microchip/Makefile > > > new file mode 100644 > > > index ..622b12771fd3 > > > --- /dev/null > > > +++ b/arch/riscv/boot/dts/microchip/Makefile > > > @@ -0,0 +1,2 @@ > > > +# SPDX-License-Identifier: GPL-2.0 > > > +dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb > > > > I'm playing (or trying to...) with XIP_KERNEL and I had to add the > > following to have the device tree actually builtin the kernel: > > > > diff --git a/arch/riscv/boot/dts/microchip/Makefile > > b/arch/riscv/boot/dts/microchip/Makefile > > index 622b12771fd3..855c1502d912 100644 > > --- a/arch/riscv/boot/dts/microchip/Makefile > > +++ b/arch/riscv/boot/dts/microchip/Makefile > > @@ -1,2 +1,3 @@ > > # SPDX-License-Identifier: GPL-2.0 > > dtb-$(CONFIG_SOC_MICROCHIP_POLARFIRE) += microchip-mpfs-icicle-kit.dtb > > +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y)) > > > > Alex > > Yes, I believe this is necessary for BUILTIN_DTB to work on Polarfire, > regardless of whether the kernel is XIP or not. > But there is no usecase for BUILTIN_DTB for polarfire except XIP kernel. The bootloaders for polarfire is capable of providing a DTB to kernel. If XIP kernel is enabled, the following line in arch/riscv/boot/dts/Makefile should take care of things > Best regards, >Vitaly > > > > diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > new file mode 100644 > > > index ..ec79944065c9 > > > --- /dev/null > > > +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > > @@ -0,0 +1,72 @@ > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > > > +/* Copyright (c) 2020 Microchip Technology Inc */ > > > + > > > +/dts-v1/; > > > + > > > +#include "microchip-mpfs.dtsi" > > > + > > > +/* Clock frequency (in Hz) of the rtcclk */ > > > +#define RTCCLK_FREQ 100 > > > + > > > +/ { > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + model = "Microchip PolarFire-SoC Icicle Kit"; > > > + compatible = "microchip,mpfs-icicle-kit"; > > > + > > > + chosen { > > > + stdout-path = &serial0; > > > + }; > > > + > > > + cpus { > > > + timebase-frequency = ; > > > + }; > > > + > > > + memory@8000 { > > > + device_type = "memory"; > > > + reg = <0x0 0x8000 0x0 0x4000>; > > > + clocks = <&clkcfg 26>; > > > + }; > > > + > > > + soc { > > > + }; > > > +}; > > > + > > > +&serial0 { > > > + status = "okay"; > > > +}; > > > + > > > +&serial1 { > > > + status = "okay"; > > > +}; > > > + > > > +&serial2 { > > > + status = "okay"; > > > +}; > > > + > > > +&serial3 { > > > + status = "okay"; > > > +}; > > > + > > > +&sdcard { > > > + status = "okay"; > > > +}; > > > + > > > +&emac0 { > > > + phy-mode = "sgmii"; > > > + phy-handle = <&phy0>; > > > + phy0: ethernet-phy@8 { > > > + reg = <8>; > > > + ti,fifo-depth = <0x01>; > > > + }; > > > +}; > > > + > > > +&emac1 { > > > + status = "okay"; > > > + phy-mode = "sgmii"; > > > + phy-handle = <&phy1>; > > > + phy1: ethernet-phy@9 { > > > + reg = <9>; > > > + ti,fifo-depth = <0x01>; > > > + }; > > > +}; > > > diff --git a/arch/riscv/boot/d
[PATCH v3 2/2] cpupower: Fix amd cpu (family >= 0x17) active state issue
From: xufuhai If the read_msr function is executed by a non-root user, the function returns -1, which means that there is no permission to access /dev/cpu/%d/msr, but cpufreq_has_boost_support should also return -1 immediately, and should not follow the original logic to return 0, which will cause amd The cpupower tool returns the boost active state as 0. Reproduce procedure: cpupower frequency-info Reported-by: yangrui Signed-off-by: xufuhai Signed-off-by: chenguanqiao Signed-off-by: lishujin Reviewed-by: Thomas Renninger --- tools/power/cpupower/utils/helpers/misc.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tools/power/cpupower/utils/helpers/misc.c b/tools/power/cpupower/utils/helpers/misc.c index fc6e34511721..565f8c414396 100644 --- a/tools/power/cpupower/utils/helpers/misc.c +++ b/tools/power/cpupower/utils/helpers/misc.c @@ -16,7 +16,7 @@ int cpufreq_has_boost_support(unsigned int cpu, int *support, int *active, int *states) { - int ret; + int ret = 0; unsigned long long val; *support = *active = *states = 0; @@ -30,18 +30,21 @@ int cpufreq_has_boost_support(unsigned int cpu, int *support, int *active, */ if (cpupower_cpu_info.caps & CPUPOWER_CAP_AMD_CPB_MSR) { - if (!read_msr(cpu, MSR_AMD_HWCR, &val)) { + /* +* no permission to access /dev/cpu/%d/msr, return -1 immediately, +* and should not follow the original logic to return 0 +*/ + ret = read_msr(cpu, MSR_AMD_HWCR, &val); + if (!ret) { if (!(val & CPUPOWER_AMD_CPBDIS)) *active = 1; } } else { ret = amd_pci_get_num_boost_states(active, states); - if (ret) - return ret; } } else if (cpupower_cpu_info.caps & CPUPOWER_CAP_INTEL_IDA) *support = *active = 1; - return 0; + return ret; } int cpupower_intel_get_perf_bias(unsigned int cpu) -- 2.24.3 (Apple Git-128)
Re: [git pull] drm/vmwgfx fixes for 5.12-rc8
The pull request you sent on Sun, 18 Apr 2021 09:48:56 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-18 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/aba5970c4da0059ed8052188a341a85ac8845d6f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SCSI fixes for 5.12-rc6
The pull request you sent on Sat, 17 Apr 2021 18:46:43 -0700: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c98ff1d013d2d53911c4b3e8ba14c7cd141cf1ed Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v4 0/5] Add Microchip PolarFire Soc Support
On Mon, Mar 29, 2021 at 9:17 PM Palmer Dabbelt wrote: > > On Wed, 03 Mar 2021 12:02:48 PST (-0800), Atish Patra wrote: > > This series adds minimal support for Microchip Polar Fire Soc Icicle kit. > > It is rebased on v5.12-rc1 and depends on clock support. > > Only MMC and ethernet drivers are enabled via this series. > > The idea here is to add the foundational patches so that other drivers > > can be added to on top of this. The device tree may change based on > > feedback on bindings of individual driver support patches. > > > > This series has been tested on Qemu and Polar Fire Soc Icicle kit. > > It depends on the updated clock-series[2] and macb fix[3]. > > The series is also tested by Lewis from Microchip. > > > > The series can also be found at. > > https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4 > > > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html > > [2] https://www.spinics.net/lists/linux-clk/msg54579.html > > > > Changes from v3->v4: > > 1. Fixed few DT specific issues. > > 2. Rebased on top of new clock driver. > > 3. SD card functionality is verified. > > > > Changes from v2->v3: > > 1. Fixed a typo in dt binding. > > 2. Included MAINTAINERS entry for PolarFire SoC. > > 3. Improved the dts file by using lowercase clock names and keeping phy > >details in board specific dts file. > > > > Changes from v1->v2: > > 1. Modified the DT to match the device tree in U-Boot. > > 2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled > >as it allows larger storage option for linux distros. > > > > Atish Patra (4): > > RISC-V: Add Microchip PolarFire SoC kconfig option > > dt-bindings: riscv: microchip: Add YAML documentation for the > > PolarFire SoC > > RISC-V: Initial DTS for Microchip ICICLE board > > RISC-V: Enable Microchip PolarFire ICICLE SoC > > > > Conor Dooley (1): > > MAINTAINERS: add microchip polarfire soc support > > > > .../devicetree/bindings/riscv/microchip.yaml | 27 ++ > > MAINTAINERS | 8 + > > arch/riscv/Kconfig.socs | 7 + > > arch/riscv/boot/dts/Makefile | 1 + > > arch/riscv/boot/dts/microchip/Makefile| 2 + > > .../microchip/microchip-mpfs-icicle-kit.dts | 72 > > .../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++ > > arch/riscv/configs/defconfig | 4 + > > 8 files changed, 450 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml > > create mode 100644 arch/riscv/boot/dts/microchip/Makefile > > create mode 100644 > > arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts > > create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi > > I had this left in my inbox waiting for either some reviews to come in or a > v2, > but I don't see any. Did I miss something? > Sorry for the late reply. I am on vacation until May. I think I saw all the patches have already been reviewed. Let me know if it is not the case. > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish
Re: [PATCH v4 1/2] binfmt_flat: allow not offsetting data start
On 17/4/21 2:54 pm, Damien Le Moal wrote: On 2021/04/17 13:52, Greg Ungerer wrote: On 17/4/21 11:10 am, Damien Le Moal wrote: Commit 2217b9826246 ("binfmt_flat: revert "binfmt_flat: don't offset the data start"") restored offsetting the start of the data section by a number of words defined by MAX_SHARED_LIBS. As a result, since MAX_SHARED_LIBS is never 0, a gap between the text and data sections always exists. For architectures which cannot support a such gap between the text and data sections (e.g. riscv nommu), flat binary programs cannot be executed. To allow an architecture to request no data start offset to allow for contiguous text and data sections for binaries flagged with FLAT_FLAG_RAM, introduce the new config option CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET. Using this new option, the macro DATA_START_OFFSET_WORDS is conditionally defined in binfmt_flat.c to MAX_SHARED_LIBS for architectures tolerating or needing the data start offset (CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET disabled case) and to 0 when CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET is enabled. DATA_START_OFFSET_WORDS is used in load_flat_file() to calculate the data section length and start position. Signed-off-by: Damien Le Moal --- fs/Kconfig.binfmt | 3 +++ fs/binfmt_flat.c | 19 ++- 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt index c6f1c8c1934e..06fb7a93a1bd 100644 --- a/fs/Kconfig.binfmt +++ b/fs/Kconfig.binfmt @@ -112,6 +112,9 @@ config BINFMT_FLAT_ARGVP_ENVP_ON_STACK config BINFMT_FLAT_OLD_ALWAYS_RAM bool +config BINFMT_FLAT_NO_DATA_START_OFFSET + bool + config BINFMT_FLAT_OLD bool "Enable support for very old legacy flat binaries" depends on BINFMT_FLAT diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c index b9c658e0548e..1dc68dfba3e0 100644 --- a/fs/binfmt_flat.c +++ b/fs/binfmt_flat.c @@ -74,6 +74,12 @@ #define MAX_SHARED_LIBS (1) #endif +#ifdef CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET +#define DATA_START_OFFSET_WORDS(0) +#else +#define DATA_START_OFFSET_WORDS(MAX_SHARED_LIBS) +#endif + struct lib_info { struct { unsigned long start_code; /* Start of text segment */ @@ -560,6 +566,7 @@ static int load_flat_file(struct linux_binprm *bprm, * it all together. */ if (!IS_ENABLED(CONFIG_MMU) && !(flags & (FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) { + Random white space change... Don't worry about re-spinning though, I will just edit this chunk out. Oops. Sorry about that. I should have better checked :) /* * this should give us a ROM ptr, but if it doesn't we don't * really care @@ -576,7 +583,8 @@ static int load_flat_file(struct linux_binprm *bprm, goto err; } - len = data_len + extra + MAX_SHARED_LIBS * sizeof(unsigned long); + len = data_len + extra + + DATA_START_OFFSET_WORDS * sizeof(unsigned long); len = PAGE_ALIGN(len); realdatastart = vm_mmap(NULL, 0, len, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0); @@ -591,7 +599,7 @@ static int load_flat_file(struct linux_binprm *bprm, goto err; } datapos = ALIGN(realdatastart + - MAX_SHARED_LIBS * sizeof(unsigned long), + DATA_START_OFFSET_WORDS * sizeof(unsigned long), FLAT_DATA_ALIGN); pr_debug("Allocated data+bss+stack (%u bytes): %lx\n", @@ -622,7 +630,8 @@ static int load_flat_file(struct linux_binprm *bprm, memp_size = len; } else { - len = text_len + data_len + extra + MAX_SHARED_LIBS * sizeof(u32); + len = text_len + data_len + extra + + DATA_START_OFFSET_WORDS * sizeof(u32); len = PAGE_ALIGN(len); textpos = vm_mmap(NULL, 0, len, PROT_READ | PROT_EXEC | PROT_WRITE, MAP_PRIVATE, 0); @@ -638,7 +647,7 @@ static int load_flat_file(struct linux_binprm *bprm, realdatastart = textpos + ntohl(hdr->data_start); datapos = ALIGN(realdatastart + - MAX_SHARED_LIBS * sizeof(u32), + DATA_START_OFFSET_WORDS * sizeof(u32), FLAT_DATA_ALIGN); reloc = (__be32 __user *) @@ -714,7 +723,7 @@ static int load_flat_file(struct linux_binprm *bprm, ret = result; pr_err("Unable to read code+data+bss, errno %d\n", ret); vm_munmap(textpos, text_len + data_len + extra + - MAX_SHARED_LIBS * sizeof(u32)); + DATA_START_OFFSET_WORD
Re: PROBLEM: DoS Attack on Fragment Cache
Sure, there are better ways to handle the reassembly cache overflowing, but that is pretty unrelated to the fact that waiting 30 full seconds for a fragment to come in doesn't really make sense in today's networks (the 30 second delay that is used today appears to even be higher than RFC 791 suggested in 1981!). You get a lot more bang for your buck if you don't wait around so long (or we could restructure things to kick out the oldest fragments, but that is a lot more work, and probably extra indexes that just aren't worth it). Matt On 4/17/21 21:38, Keyu Man wrote: Willy's words make sense to me and I agree that the existing fragments should be evicted when the new one comes in and the cache is full. Though the attacker can still leverage this to flush the victim's cache, as mentioned previously, since fragments are likely to be assembled in a very short time, it would be hard to launch the attack(evicting the legit fragment before it's assembled requires a large packet sending rate). And this seems better than the existing solution (drop all incoming fragments when full). Keyu On Sat, Apr 17, 2021 at 6:30 PM Matt Corallo wrote: See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do) hit this issue in normal non-adversarial conditions. Matt On 4/17/21 03:50, Willy Tarreau wrote: On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: How about at least allow the existing queue to finish? Currently a tiny new fragment would potentially invalid all previous fragments by letting them timeout without allowing the fragments to come in to finish the assembly. Because this is exactly the principle of how attacks are built: reserve resources claiming that you'll send everything so that others can't make use of the resources that are reserved to you. The best solution precisely is *not* to wait for anyone to finish, hence *not* to reserve valuable resources that are unusuable by others. Willy
Re: [PATCH 12/12] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions
Quoting Sibi Sankar (2021-04-16 05:03:58) > Delete unused power-domain definitions exposed by AOSS QMP. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 10/12] arm64: dts: qcom: sm8250: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:56) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8250 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 11/12] arm64: dts: qcom: sm8350: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:57) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8350 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 09/12] arm64: dts: qcom: sm8150: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:55) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SM8150 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 08/12] arm64: dts: qcom: sdm845: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:54) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SDM845 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 07/12] arm64: dts: qcom: sc7280: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:53) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7280 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 06/12] arm64: dts: qcom: sc7180: Use QMP binding to control load state
Quoting Sibi Sankar (2021-04-16 05:03:52) > Use the Qualcomm Mailbox Protocol (QMP) binding to control the load > state resources on SC7180 SoCs and drop deprecated power-domains exposed > by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 02/12] soc: qcom: aoss: Drop power domain support
Quoting Sibi Sankar (2021-04-16 05:03:48) > The load state resources are expected to follow the life cycle of the > remote processor it tracks. However, modeling load state resources as > power-domains result in them getting turned off during system suspend > and thereby falling out of sync with the remote processors that are still > on. Fix this by replacing load state resource control through the generic > qmp message send interface instead. > > Signed-off-by: Sibi Sankar > --- Is it possible to keep this code around for a cycle so that there isn't the chance that someone is using the deprecated DT bindings with a new kernel? I worry that ripping the code out will cause them angst. Certainly we have to keep the code in place until DT is updated, so this patch should come last?
Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
On Sat, 2021-04-17 at 10:52 +0200, Hans de Goede wrote: > Hi David, > > On 4/17/21 5:12 AM, David E. Box wrote: > > From: Gayatri Kammela > > > > Platforms that support low power modes (LPM) such as Tiger Lake > > maintain > > requirements for each sub-state that a readable in the PMC. > > However, unlike > > LPM status registers, requirement registers are not memory mapped > > but are > > available from an ACPI _DSM. Collect the requirements for Tiger > > Lake using > > the _DSM method and store in a buffer. > > > > Signed-off-by: Gayatri Kammela > > Co-developed-by: David E. Box > > Signed-off-by: David E. Box > > Reviewed-by: Hans de Goede > > Erm, I did not give my "Reviewed-by: Hans de Goede < > hdego...@redhat.com>" > for this patch, because it still needed some work. > > Next time please only add my Reviewed-by to patches where I > explicitly replied with a Reviewed-by. Sure thing. Sorry about that. David > The same goes for patch 7/9 > > Regards, > > Hans > > > > > --- > > > > V2: - Move buffer allocation so that it does not need to be > > freed > > (which was missing anyway) when an error is encountered. > > - Use label to free out_obj after errors > > - Use memcpy instead of memcpy_fromio for ACPI memory > > > > drivers/platform/x86/intel_pmc_core.c | 56 > > +++ > > drivers/platform/x86/intel_pmc_core.h | 2 + > > 2 files changed, 58 insertions(+) > > > > diff --git a/drivers/platform/x86/intel_pmc_core.c > > b/drivers/platform/x86/intel_pmc_core.c > > index 0e59a84b51bf..97efe9a6bd01 100644 > > --- a/drivers/platform/x86/intel_pmc_core.c > > +++ b/drivers/platform/x86/intel_pmc_core.c > > @@ -23,7 +23,9 @@ > > #include > > #include > > #include > > +#include > > > > +#include > > #include > > #include > > #include > > @@ -31,6 +33,9 @@ > > > > #include "intel_pmc_core.h" > > > > +#define ACPI_S0IX_DSM_UUID "57a6512e-3979-4e9d-9708- > > ff13b2508972" > > +#define ACPI_GET_LOW_MODE_REGISTERS1 > > + > > /* PKGC MSRs are common across Intel Core SoCs */ > > static const struct pmc_bit_map msr_map[] = { > > {"Package C2", MSR_PKG_C2_RESIDENCY}, > > @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map = > > { > > .etr3_offset = ETR3_OFFSET, > > }; > > > > +static void pmc_core_get_tgl_lpm_reqs(struct platform_device > > *pdev) > > +{ > > + struct pmc_dev *pmcdev = platform_get_drvdata(pdev); > > + const int num_maps = pmcdev->map->lpm_num_maps; > > + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4; > > + union acpi_object *out_obj; > > + struct acpi_device *adev; > > + guid_t s0ix_dsm_guid; > > + u32 *lpm_req_regs, *addr; > > + > > + adev = ACPI_COMPANION(&pdev->dev); > > + if (!adev) > > + return; > > + > > + guid_parse(ACPI_S0IX_DSM_UUID, &s0ix_dsm_guid); > > + > > + out_obj = acpi_evaluate_dsm(adev->handle, &s0ix_dsm_guid, > > 0, > > + ACPI_GET_LOW_MODE_REGISTERS, > > NULL); > > + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) { > > + int size = out_obj->buffer.length; > > + > > + if (size != lpm_size) { > > + acpi_handle_debug(adev->handle, > > + "_DSM returned unexpected buffer > > size," > > + " have %d, expect %ld\n", size, > > lpm_size); > > + goto free_acpi_obj; > > + } > > + } else { > > + acpi_handle_debug(adev->handle, > > + "_DSM function 0 evaluation > > failed\n"); > > + goto free_acpi_obj; > > + } > > + > > + addr = (u32 *)out_obj->buffer.pointer; > > + > > + lpm_req_regs = devm_kzalloc(&pdev->dev, lpm_size * > > sizeof(u32), > > + GFP_KERNEL); > > + if (!lpm_req_regs) > > + goto free_acpi_obj; > > + > > + memcpy(lpm_req_regs, addr, lpm_size); > > + pmcdev->lpm_req_regs = lpm_req_regs; > > + > > +free_acpi_obj: > > + ACPI_FREE(out_obj); > > +} > > + > > static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int > > reg_offset) > > { > > return readl(pmcdev->regbase + reg_offset); > > @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct > > platform_device *pdev) > > return -ENOMEM; > > > > mutex_init(&pmcdev->lock); > > + > > pmcdev->pmc_xram_read_bit = > > pmc_core_check_read_lock_bit(pmcdev); > > pmc_core_get_low_power_modes(pmcdev); > > pmc_core_do_dmi_quirks(pmcdev); > > > > + if (pmcdev->map == &tgl_reg_map) > > + pmc_core_get_tgl_lpm_reqs(pdev); > > + > > /* > > * On TGL, due to a hardware limitation, the GBE LTR blocks > > PC10 when > > * a cable is attached. Tell the PMC to ignor
Re: [PATCH 03/12] dt-bindings: remoteproc: qcom: pas: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:49) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 04/12] dt-bindings: remoteproc: qcom: Add QMP bindings
Quoting Sibi Sankar (2021-04-16 05:03:50) > Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains > exposed by the AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH 01/12] dt-bindings: soc: qcom: aoss: Drop power-domain bindings
Quoting Sibi Sankar (2021-04-16 05:03:47) > Drop power-domain bindings exposed by AOSS QMP node. > > Signed-off-by: Sibi Sankar > --- Reviewed-by: Stephen Boyd
Re: [PATCH v4 05/13] module: Add printk formats to add module build ID to stacktraces
Quoting Jessica Yu (2021-04-15 06:04:35) > +++ Stephen Boyd [09/04/21 18:52 -0700]: > >diff --git a/include/linux/module.h b/include/linux/module.h > >index 59f094fa6f74..4bf869f6c944 100644 > >--- a/include/linux/module.h > >+++ b/include/linux/module.h > >@@ -11,6 +11,7 @@ > > > > #include > > #include > >+#include > > #include > > #include > > #include > >@@ -367,6 +368,9 @@ struct module { > > /* Unique handle for this module */ > > char name[MODULE_NAME_LEN]; > > > >+ /* Module build ID */ > >+ unsigned char build_id[BUILD_ID_SIZE_MAX]; > > Hi Stephen, > > Since this field is not used when !CONFIG_STACKTRACE_BUILD_ID, I > would prefer to wrap this in an ifdef, similar to the other > CONFIG-dependent fields in struct module. This makes it explicit under > what conditions (i.e. config) the field is meant to be used. Ok will do. > >diff --git a/kernel/module.c b/kernel/module.c > >index 30479355ab85..6f5bc1b046a5 100644 > >--- a/kernel/module.c > >+++ b/kernel/module.c > >@@ -2770,6 +2771,20 @@ static void add_kallsyms(struct module *mod, const > >struct load_info *info) > > } > > mod->core_kallsyms.num_symtab = ndst; > > } > >+ > >+static void init_build_id(struct module *mod, const struct load_info *info) > >+{ > >+ const Elf_Shdr *sechdr; > >+ unsigned int i; > >+ > >+ for (i = 0; i < info->hdr->e_shnum; i++) { > >+ sechdr = &info->sechdrs[i]; > >+ if (!sect_empty(sechdr) && sechdr->sh_type == SHT_NOTE && > >+ !build_id_parse_buf((void *)sechdr->sh_addr, > >mod->build_id, > >+ sechdr->sh_size)) > >+ break; > >+ } > > If mod->build_id is not used when !CONFIG_STACKTRACE_BUILD_ID, then we > don't need to look for it. I would be fine with wrapping the function > body in an ifdef (similar to what we currently do in > del_usage_links() and do_mod_ctors()). Ok, done. > > >+} > > #else > > static inline void layout_symtab(struct module *mod, struct load_info *info) > > { > >@@ -2778,6 +2793,10 @@ static inline void layout_symtab(struct module *mod, > >struct load_info *info) > > static void add_kallsyms(struct module *mod, const struct load_info *info) > > { > > } > >+ > >+static void init_build_id(struct module *mod, const struct load_info *info) > >+{ > >+} > > #endif /* CONFIG_KALLSYMS */ > > > > static void dynamic_debug_setup(struct module *mod, struct _ddebug *debug, > > unsigned int num) > >@@ -4004,6 +4023,7 @@ static int load_module(struct load_info *info, const > >char __user *uargs, > > goto free_arch_cleanup; > > } > > > >+ init_build_id(mod, info); > > dynamic_debug_setup(mod, info->debug, info->num_debug); > > > > /* Ftrace init must be called in the MODULE_STATE_UNFORMED state */ > >@@ -4235,7 +4255,7 @@ void * __weak > >dereference_module_function_descriptor(struct module *mod, > > const char *module_address_lookup(unsigned long addr, > > unsigned long *size, > > unsigned long *offset, > >- char **modname, > >+ char **modname, const unsigned char **modbuildid, > > char *namebuf) > > { > > const char *ret = NULL; > >@@ -4246,6 +4266,8 @@ const char *module_address_lookup(unsigned long addr, > > if (mod) { > > if (modname) > > *modname = mod->name; > >+ if (modbuildid) > >+ *modbuildid = mod->build_id; > > Then maybe we can set *modbuildid = NULL in the case of > !CONFIG_STACKTRACE_BUILD_ID, similar to the kernel case in > kallsyms_lookup_buildid(). > Sounds good. It means that some more ifdefs are probably required vs. making the array size be 0 when the config is disabled but that isn't a big problem for me. I'm reworking the code now and will test and then send v5 shortly. Thanks!
[GIT PULL] SCSI fixes for 5.12-rc6
This libsas fix is for a problem that occurs when trying to change the cache type of an ATA device and the libiscsi one is a regression fix from this merge window. git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Jolly Shah (1): scsi: libsas: Reset num_scatter if libata marks qc as NODATA Mike Christie (1): scsi: iscsi: Fix iSCSI cls conn state And the diffstat: drivers/scsi/libiscsi.c | 26 +++--- drivers/scsi/libsas/sas_ata.c | 9 - drivers/scsi/scsi_transport_iscsi.c | 18 +++--- 3 files changed, 22 insertions(+), 31 deletions(-) With full diff below. James --- diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index 7ad11e42306d..bfd2aaa9b66b 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -3179,9 +3179,10 @@ fail_mgmt_tasks(struct iscsi_session *session, struct iscsi_conn *conn) } } -static void iscsi_start_session_recovery(struct iscsi_session *session, -struct iscsi_conn *conn, int flag) +void iscsi_conn_stop(struct iscsi_cls_conn *cls_conn, int flag) { + struct iscsi_conn *conn = cls_conn->dd_data; + struct iscsi_session *session = conn->session; int old_stop_stage; mutex_lock(&session->eh_mutex); @@ -3239,27 +3240,6 @@ static void iscsi_start_session_recovery(struct iscsi_session *session, spin_unlock_bh(&session->frwd_lock); mutex_unlock(&session->eh_mutex); } - -void iscsi_conn_stop(struct iscsi_cls_conn *cls_conn, int flag) -{ - struct iscsi_conn *conn = cls_conn->dd_data; - struct iscsi_session *session = conn->session; - - switch (flag) { - case STOP_CONN_RECOVER: - cls_conn->state = ISCSI_CONN_FAILED; - break; - case STOP_CONN_TERM: - cls_conn->state = ISCSI_CONN_DOWN; - break; - default: - iscsi_conn_printk(KERN_ERR, conn, - "invalid stop flag %d\n", flag); - return; - } - - iscsi_start_session_recovery(session, conn, flag); -} EXPORT_SYMBOL_GPL(iscsi_conn_stop); int iscsi_conn_bind(struct iscsi_cls_session *cls_session, diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c index 024e5a550759..8b9a39077dba 100644 --- a/drivers/scsi/libsas/sas_ata.c +++ b/drivers/scsi/libsas/sas_ata.c @@ -201,18 +201,17 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc) memcpy(task->ata_task.atapi_packet, qc->cdb, qc->dev->cdb_len); task->total_xfer_len = qc->nbytes; task->num_scatter = qc->n_elem; + task->data_dir = qc->dma_dir; + } else if (qc->tf.protocol == ATA_PROT_NODATA) { + task->data_dir = DMA_NONE; } else { for_each_sg(qc->sg, sg, qc->n_elem, si) xfer += sg_dma_len(sg); task->total_xfer_len = xfer; task->num_scatter = si; - } - - if (qc->tf.protocol == ATA_PROT_NODATA) - task->data_dir = DMA_NONE; - else task->data_dir = qc->dma_dir; + } task->scatter = qc->sg; task->ata_task.retry_count = 1; task->task_state_flags = SAS_TASK_STATE_PENDING; diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c index bebfb355abdf..21a2d997a72e 100644 --- a/drivers/scsi/scsi_transport_iscsi.c +++ b/drivers/scsi/scsi_transport_iscsi.c @@ -2470,10 +2470,22 @@ static void iscsi_if_stop_conn(struct iscsi_cls_conn *conn, int flag) * it works. */ mutex_lock(&conn_mutex); + switch (flag) { + case STOP_CONN_RECOVER: + conn->state = ISCSI_CONN_FAILED; + break; + case STOP_CONN_TERM: + conn->state = ISCSI_CONN_DOWN; + break; + default: + iscsi_cls_conn_printk(KERN_ERR, conn, + "invalid stop flag %d\n", flag); + goto unlock; + } + conn->transport->stop_conn(conn, flag); - conn->state = ISCSI_CONN_DOWN; +unlock: mutex_unlock(&conn_mutex); - } static void stop_conn_work_fn(struct work_struct *work) @@ -2961,7 +2973,7 @@ static int iscsi_if_ep_disconnect(struct iscsi_transport *transport, mutex_lock(&conn->ep_mutex); conn->ep = NULL; mutex_unlock(&conn->ep_mutex); - conn->state = ISCSI_CONN_DOWN; + conn->state = ISCSI_CONN_FAILED; } transport->ep_disconnect(ep);
Re: [PATCH V2 5/9] platform/x86: intel_pmc_core: Get LPM requirements for Tiger Lake
On Sat, 2021-04-17 at 11:00 +0200, Hans de Goede wrote: > Hi, > > On 4/17/21 5:12 AM, David E. Box wrote: > > From: Gayatri Kammela > > > > Platforms that support low power modes (LPM) such as Tiger Lake > > maintain > > requirements for each sub-state that a readable in the PMC. > > However, unlike > > LPM status registers, requirement registers are not memory mapped > > but are > > available from an ACPI _DSM. Collect the requirements for Tiger > > Lake using > > the _DSM method and store in a buffer. > > > > Signed-off-by: Gayatri Kammela > > Co-developed-by: David E. Box > > Signed-off-by: David E. Box > > Reviewed-by: Hans de Goede > > --- > > > > V2: - Move buffer allocation so that it does not need to be > > freed > > (which was missing anyway) when an error is encountered. > > - Use label to free out_obj after errors > > - Use memcpy instead of memcpy_fromio for ACPI memory > > > > drivers/platform/x86/intel_pmc_core.c | 56 > > +++ > > drivers/platform/x86/intel_pmc_core.h | 2 + > > 2 files changed, 58 insertions(+) > > > > diff --git a/drivers/platform/x86/intel_pmc_core.c > > b/drivers/platform/x86/intel_pmc_core.c > > index 0e59a84b51bf..97efe9a6bd01 100644 > > --- a/drivers/platform/x86/intel_pmc_core.c > > +++ b/drivers/platform/x86/intel_pmc_core.c > > @@ -23,7 +23,9 @@ > > #include > > #include > > #include > > +#include > > > > +#include > > #include > > #include > > #include > > @@ -31,6 +33,9 @@ > > > > #include "intel_pmc_core.h" > > > > +#define ACPI_S0IX_DSM_UUID "57a6512e-3979-4e9d-9708- > > ff13b2508972" > > +#define ACPI_GET_LOW_MODE_REGISTERS1 > > + > > /* PKGC MSRs are common across Intel Core SoCs */ > > static const struct pmc_bit_map msr_map[] = { > > {"Package C2", MSR_PKG_C2_RESIDENCY}, > > @@ -590,6 +595,53 @@ static const struct pmc_reg_map tgl_reg_map = > > { > > .etr3_offset = ETR3_OFFSET, > > }; > > > > +static void pmc_core_get_tgl_lpm_reqs(struct platform_device > > *pdev) > > +{ > > + struct pmc_dev *pmcdev = platform_get_drvdata(pdev); > > + const int num_maps = pmcdev->map->lpm_num_maps; > > + size_t lpm_size = LPM_MAX_NUM_MODES * num_maps * 4; > > The type of lpm_size should be an u32, so that it matches > the type of out_obj->buffer.length. > > > + union acpi_object *out_obj; > > + struct acpi_device *adev; > > + guid_t s0ix_dsm_guid; > > + u32 *lpm_req_regs, *addr; > > + > > + adev = ACPI_COMPANION(&pdev->dev); > > + if (!adev) > > + return; > > + > > + guid_parse(ACPI_S0IX_DSM_UUID, &s0ix_dsm_guid); > > + > > + out_obj = acpi_evaluate_dsm(adev->handle, &s0ix_dsm_guid, > > 0, > > + ACPI_GET_LOW_MODE_REGISTERS, > > NULL); > > + if (out_obj && out_obj->type == ACPI_TYPE_BUFFER) { > > + int size = out_obj->buffer.length; > > out_obj->buffer.length is an u32, please make this an u32 too. > > > + > > + if (size != lpm_size) { > > + acpi_handle_debug(adev->handle, > > + "_DSM returned unexpected buffer > > size," > > + " have %d, expect %ld\n", size, > > lpm_size); > > And use %u here (twice), this should also fix the warnings reported > by the kernel test robot. > > If there are no objections against the suggested changes, then I can > fix this up while merging this. > > Please let me know if the suggested changes are ok with you. Changes are good with me. Thanks for the fixup. David > > Regards, > > Hans > > > > + goto free_acpi_obj; > > + } > > + } else { > > + acpi_handle_debug(adev->handle, > > + "_DSM function 0 evaluation > > failed\n"); > > + goto free_acpi_obj; > > + } > > + > > + addr = (u32 *)out_obj->buffer.pointer; > > + > > + lpm_req_regs = devm_kzalloc(&pdev->dev, lpm_size * > > sizeof(u32), > > + GFP_KERNEL); > > + if (!lpm_req_regs) > > + goto free_acpi_obj; > > + > > + memcpy(lpm_req_regs, addr, lpm_size); > > + pmcdev->lpm_req_regs = lpm_req_regs; > > + > > +free_acpi_obj: > > + ACPI_FREE(out_obj); > > +} > > + > > static inline u32 pmc_core_reg_read(struct pmc_dev *pmcdev, int > > reg_offset) > > { > > return readl(pmcdev->regbase + reg_offset); > > @@ -1424,10 +1476,14 @@ static int pmc_core_probe(struct > > platform_device *pdev) > > return -ENOMEM; > > > > mutex_init(&pmcdev->lock); > > + > > pmcdev->pmc_xram_read_bit = > > pmc_core_check_read_lock_bit(pmcdev); > > pmc_core_get_low_power_modes(pmcdev); > > pmc_core_do_dmi_quirks(pmcdev); > > > > + if (pmcdev->map == &tgl_reg_map) > > + pmc_core_g
Re: PROBLEM: DoS Attack on Fragment Cache
Willy's words make sense to me and I agree that the existing fragments should be evicted when the new one comes in and the cache is full. Though the attacker can still leverage this to flush the victim's cache, as mentioned previously, since fragments are likely to be assembled in a very short time, it would be hard to launch the attack(evicting the legit fragment before it's assembled requires a large packet sending rate). And this seems better than the existing solution (drop all incoming fragments when full). Keyu On Sat, Apr 17, 2021 at 6:30 PM Matt Corallo wrote: > > See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from > 30s" (and the two resends of it) - given > the size of the default cache (4MB) and the time that it takes before we > flush the cache (30 seconds) you only need > about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, > its also incredibly practical (and I do) > hit this issue in normal non-adversarial conditions. > > Matt > > On 4/17/21 03:50, Willy Tarreau wrote: > > On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: > >> How about at least allow the existing queue to finish? Currently a tiny new > >> fragment would potentially invalid all previous fragments by letting them > >> timeout without allowing the fragments to come in to finish the assembly. > > > > Because this is exactly the principle of how attacks are built: reserve > > resources claiming that you'll send everything so that others can't make > > use of the resources that are reserved to you. The best solution precisely > > is *not* to wait for anyone to finish, hence *not* to reserve valuable > > resources that are unusuable by others. > > > > Willy > >
Re: [PATCH 0/9] sched: Core scheduling interfaces
On Tue, Apr 06, 2021 at 10:16:12AM -0400, Tejun Heo wrote: > Hello, > > On Mon, Apr 05, 2021 at 02:46:09PM -0400, Joel Fernandes wrote: > > Yeah, its at http://lore.kernel.org/r/20200822030155.ga414...@google.com > > as mentioned above, let me know if you need any more details about > > usecase. > > Except for the unspecified reason in usecase 4, I don't see why cgroup is in > the picture at all. This doesn't really have much to do with hierarchical > resource distribution. Besides, yes, you can use cgroup for logical > structuring and identificaiton purposes but in those cases the interactions > and interface should be with the original subsystem while using cgroup IDs > or paths as parameters - see tracing and bpf for examples. Personally for ChromeOS, we need only the per-task interface. Considering that the second argument of this prctl is a command, I don't see why we cannot add a new command PR_SCHED_CORE_CGROUP_SHARE to do what Tejun is saying (in the future). In order to not block ChromeOS and other "per-task interface" usecases, I suggest we keep the CGroup interface for a later time (whether that's through prctl or the CGroups FS way which Tejun dislikes) and move forward with per-task interface only initially. Peter, any thoughts on this? thanks, - Joel
Re: PROBLEM: DoS Attack on Fragment Cache
See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need about 1Mbps of fragments to hit this issue. While DoS attacks are concerning, its also incredibly practical (and I do) hit this issue in normal non-adversarial conditions. Matt On 4/17/21 03:50, Willy Tarreau wrote: On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote: How about at least allow the existing queue to finish? Currently a tiny new fragment would potentially invalid all previous fragments by letting them timeout without allowing the fragments to come in to finish the assembly. Because this is exactly the principle of how attacks are built: reserve resources claiming that you'll send everything so that others can't make use of the resources that are reserved to you. The best solution precisely is *not* to wait for anyone to finish, hence *not* to reserve valuable resources that are unusuable by others. Willy
Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
On Sat, Apr 17, 2021 at 08:56:13PM +0200, Mauro Carvalho Chehab wrote: > Em Sat, 17 Apr 2021 21:06:27 +0530 > Ashish Kalra escreveu: > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > for this file. Logical and bitwise OR are basically the same in this > > context so it doesn't cause a runtime bug. But let's change it to > > logical OR to make it cleaner and silence the Sparse warning. > > > > Signed-off-by: Ashish Kalra > > --- > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > --- > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > +++ > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > unsigned int ds_log2 = 0; > > unsigned int out_width; > > > > - if ((!out_info) | (!vf_info)) > > + if ((!out_info) || (!vf_info)) > > > While here, please get rid of the unneeded parenthesis: > > if (!out_info || !vf_info) > > > > return -EINVAL; > > > > out_width = out_info->res.width; > > > > Thanks, > Mauro Updated Patch as per your feedback Thanks Ashish >From 770317157c3a7abf2fda1d71b0bd651c33bf0bfa Mon Sep 17 00:00:00 2001 From: Ashish Kalra Date: Sun, 18 Apr 2021 06:52:03 +0530 Subject: [PATCH] media: atomisp: silence "dubious: !x | !y" warning Upon running sparse, "warning: dubious: !x | !y" is brought to notice for this file. Logical and bitwise OR are basically the same in this context so it doesn't cause a runtime bug. But let's change it to logical OR to make it cleaner and silence the Sparse warning. Signed-off-by: Ashish Kalra --- .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c index 358cb7d2cd4c..71c3e7dac052 100644 --- a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c +++ b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( unsigned int ds_log2 = 0; unsigned int out_width; - if ((!out_info) | (!vf_info)) + if (!out_info || !vf_info) return -EINVAL; out_width = out_info->res.width; -- 2.25.1
Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
On Sat, Apr 17, 2021 at 09:31:32PM +, David Laight wrote: > From: Mauro Carvalho Chehab > > Sent: 17 April 2021 19:56 > > > > Em Sat, 17 Apr 2021 21:06:27 +0530 > > Ashish Kalra escreveu: > > > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > > for this file. Logical and bitwise OR are basically the same in this > > > context so it doesn't cause a runtime bug. But let's change it to > > > logical OR to make it cleaner and silence the Sparse warning. > > The old code is very likely to by slightly more efficient. > > It may not matter here, but it might in a really hot path. > > Since !x | !y and !x || !y always have the same value > why is sparse complaining at all. > > David This warning is coming from sparse as per below explanation As the name suggests, a "bitwise" expression is one that is restricted to only a certain "bitwise" operations that make sense within that class. In particular, you can't mix a "bitwise" class with a normal integer expression Warning: int __bitwise i; int __bitwise j; the two variables "i" and "j" are _not_ compatible, simply because they were declared separately, while in the case of int __bitwise i, j; they _are_ compatible. https://yarchive.net/comp/linux/sparse.html > > > > > > > Signed-off-by: Ashish Kalra > > > --- > > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git > > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > > --- > > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > +++ > > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > > unsigned int ds_log2 = 0; > > > unsigned int out_width; > > > > > > - if ((!out_info) | (!vf_info)) > > > + if ((!out_info) || (!vf_info)) > > > > > > While here, please get rid of the unneeded parenthesis: > > > > if (!out_info || !vf_info) > > > > > > > return -EINVAL; > > > > > > out_width = out_info->res.width; > > > > > > > > Thanks, > > Mauro > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 > 1PT, UK > Registration No: 1397386 (Wales) >
[tip:timers/core] BUILD SUCCESS 2d036dfa5f10df9782f5278fc591d79d283c1fad
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core branch HEAD: 2d036dfa5f10df9782f5278fc591d79d283c1fad posix-timers: Preserve return value in clock_adjtime32() elapsed time: 724m configs tested: 100 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig powerpc pcm030_defconfig powerpc pasemi_defconfig m68k amiga_defconfig ia64 tiger_defconfig mips decstation_64_defconfig powerpcicon_defconfig powerpc arches_defconfig armvexpress_defconfig powerpc eiger_defconfig shhp6xx_defconfig armtrizeps4_defconfig mips gcw0_defconfig arm aspeed_g5_defconfig xtensasmp_lx200_defconfig powerpc sbc8548_defconfig sh rts7751r2dplus_defconfig powerpc ppc44x_defconfig arm bcm2835_defconfig powerpcsocrates_defconfig arm rpc_defconfig arm footbridge_defconfig armneponset_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 riscvnommu_k210_defconfig riscvallyesconfig 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-a014-20210417 x86_64 randconfig-a015-20210417 x86_64 randconfig-a011-20210417 x86_64 randconfig-a013-20210417 x86_64 randconfig-a012-20210417 x86_64 randconfig-a016
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 03:11:49PM -0700, Linus Torvalds wrote: > On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote: > > > > No, wait - we have non-NULL buf->prev_reclen, so we'll hit > > with buf->error completely ignored. Nevermind. > > Yeah, I'm pretty sure I even tested that -EINTR case at one point. > > Of course, it could easily have gotten broken again, so that's not a > strong argument. > > That said, the "buf->err" handling has always been very confusing, and > it would be lovely to get rid of that confusion. > > I don't remember why we did it that way, but I think it's because > low-level filesystems ended up changing the error that the filldir() > function returned or something like that. Propagating errors from e.g. filldir() out through ->iterate() instances turns out to be painful. If anything, considering that there's a lot more ->iterate/->iterate_shared instances that ->actor ones, it would make sense to change the calling conventions for the latter. IOW, stop pretending that they return an error value and just have them return a bool: "should the caller keep going". Here's what I've got sitting in a local branch; not sure if it would be better to invert the rules, though - I went for "should we keep going", but we could do "should we stop" instead. Change calling conventions for filldir_t filldir_t instances (directory iterators callbacks) used to return 0 for "OK, keep going" or -E... for "stop". Note that it's *NOT* how the error values are reported - the rules for those are callback-dependent and ->iterate{,_shared}() instances only care about zero vs. non-zero (look at emit_dir() and friends). So let's just return bool - it's less confusing that way. Signed-off-by: Al Viro --- diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 0302035781be..268c2ac616d1 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -890,3 +890,14 @@ been called or returned with non -EIOCBQUEUED code. mnt_want_write_file() can now only be paired with mnt_drop_write_file(), whereas previously it could be paired with mnt_drop_write() as well. + +--- + +*mandatory* + +filldir_t (readdir callbacks) calling conventions have changed. Instead of +returning 0 or -E... it returns bool now. true means "keep going" (as 0 used +to to) and false - "no more" (as -E... in old calling conventions). Rationale: +callers never looked at specific -E... values anyway. ->iterate() and +->iterate_shared() instance require no changes at all, all filldir_t ones in +the tree converted. diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c index d5367a1c6300..6864794b663a 100644 --- a/arch/alpha/kernel/osf_sys.c +++ b/arch/alpha/kernel/osf_sys.c @@ -107,7 +107,7 @@ struct osf_dirent_callback { int error; }; -static int +static bool osf_filldir(struct dir_context *ctx, const char *name, int namlen, loff_t offset, u64 ino, unsigned int d_type) { @@ -119,11 +119,11 @@ osf_filldir(struct dir_context *ctx, const char *name, int namlen, buf->error = -EINVAL; /* only used if we fail */ if (reclen > buf->count) - return -EINVAL; + return false; d_ino = ino; if (sizeof(d_ino) < sizeof(ino) && d_ino != ino) { buf->error = -EOVERFLOW; - return -EOVERFLOW; + return false; } if (buf->basep) { if (put_user(offset, buf->basep)) @@ -140,10 +140,10 @@ osf_filldir(struct dir_context *ctx, const char *name, int namlen, dirent = (void __user *)dirent + reclen; buf->dirent = dirent; buf->count -= reclen; - return 0; + return true; Efault: buf->error = -EFAULT; - return -EFAULT; + return false; } SYSCALL_DEFINE4(osf_getdirentries, unsigned int, fd, diff --git a/fs/afs/dir.c b/fs/afs/dir.c index 714fcca9af99..aa3bdf389d47 100644 --- a/fs/afs/dir.c +++ b/fs/afs/dir.c @@ -24,9 +24,9 @@ static int afs_readdir(struct file *file, struct dir_context *ctx); static int afs_d_revalidate(struct dentry *dentry, unsigned int flags); static int afs_d_delete(const struct dentry *dentry); static void afs_d_iput(struct dentry *dentry, struct inode *inode); -static int afs_lookup_one_filldir(struct dir_context *ctx, const char *name, int nlen, +static bool afs_lookup_one_filldir(struct dir_context *ctx, const char *name, int nlen, loff_t fpos, u64 ino, unsigned dtype); -static int afs_lookup_filldir(struct dir_context *ctx, const char *name, int nlen, +static bool afs_lookup_filldir(struct dir_context *ctx, const char *name, int nlen, loff_t fpos, u64 ino, unsigned dtype); static int afs_create(struct user_namespace *mnt_userns, struct inode *dir, struct dentry *dentry, umode_t mode, bool excl); @@ -527,7 +527,7 @@ static int afs_rea
[PATCH] crypto: camellia: drop duplicate "depends on CRYPTO"
All 5 CAMELLIA crypto driver Kconfig symbols have a duplicate "depends on CRYPTO" line but they are inside an "if CRYPTO"/"endif # if CRYPTO" block, so drop the duplicate "depends" lines. These 5 symbols still depend on CRYPTO. Fixes: 584fffc8b196 ("[CRYPTO] kconfig: Ordering cleanup") Fixes: 0b95ec56ae19 ("crypto: camellia - add assembler implementation for x86_64") Fixes: d9b1d2e7e10d ("crypto: camellia - add AES-NI/AVX/x86_64 assembler implementation of camellia cipher") Fixes: f3f935a76aa0 ("crypto: camellia - add AVX2/AES-NI/x86_64 assembler implementation of camellia cipher") Fixes: c5aac2df6577 ("sparc64: Add DES driver making use of the new des opcodes.") Signed-off-by: Randy Dunlap Cc: Sebastian Siewior Cc: Jussi Kivilinna Cc: Herbert Xu Cc: "David S. Miller" Cc: linux-cry...@vger.kernel.org --- crypto/Kconfig |5 - 1 file changed, 5 deletions(-) --- linux-next-20210416.orig/crypto/Kconfig +++ linux-next-20210416/crypto/Kconfig @@ -1223,7 +1223,6 @@ config CRYPTO_BLOWFISH_X86_64 config CRYPTO_CAMELLIA tristate "Camellia cipher algorithms" - depends on CRYPTO select CRYPTO_ALGAPI help Camellia cipher algorithms module. @@ -1239,7 +1238,6 @@ config CRYPTO_CAMELLIA config CRYPTO_CAMELLIA_X86_64 tristate "Camellia cipher algorithm (x86_64)" depends on X86 && 64BIT - depends on CRYPTO select CRYPTO_SKCIPHER imply CRYPTO_CTR help @@ -1256,7 +1254,6 @@ config CRYPTO_CAMELLIA_X86_64 config CRYPTO_CAMELLIA_AESNI_AVX_X86_64 tristate "Camellia cipher algorithm (x86_64/AES-NI/AVX)" depends on X86 && 64BIT - depends on CRYPTO select CRYPTO_SKCIPHER select CRYPTO_CAMELLIA_X86_64 select CRYPTO_SIMD @@ -1275,7 +1272,6 @@ config CRYPTO_CAMELLIA_AESNI_AVX_X86_64 config CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 tristate "Camellia cipher algorithm (x86_64/AES-NI/AVX2)" depends on X86 && 64BIT - depends on CRYPTO select CRYPTO_CAMELLIA_AESNI_AVX_X86_64 help Camellia cipher algorithm module (x86_64/AES-NI/AVX2). @@ -1291,7 +1287,6 @@ config CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 config CRYPTO_CAMELLIA_SPARC64 tristate "Camellia cipher algorithm (SPARC64)" depends on SPARC64 - depends on CRYPTO select CRYPTO_ALGAPI select CRYPTO_SKCIPHER help
[PATCH 2/3] rtc: pcf8523: add alarm support
Alarm support requires unconditionally disabling clock out because it is using the int1 pin. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf8523.c | 181 +- 1 file changed, 180 insertions(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c index fe3ab41d8326..feadab8e3bd3 100644 --- a/drivers/rtc/rtc-pcf8523.c +++ b/drivers/rtc/rtc-pcf8523.c @@ -8,10 +8,15 @@ #include #include #include +#include #define REG_CONTROL1 0x00 #define REG_CONTROL1_CAP_SEL BIT(7) #define REG_CONTROL1_STOPBIT(5) +#define REG_CONTROL1_AIEBIT(1) + +#define REG_CONTROL2 0x01 +#define REG_CONTROL2_AF BIT(3) #define REG_CONTROL3 0x02 #define REG_CONTROL3_PM_BLD BIT(7) /* battery low detection disabled */ @@ -30,9 +35,22 @@ #define REG_MONTHS 0x08 #define REG_YEARS0x09 +#define REG_MINUTE_ALARM 0x0a +#define REG_HOUR_ALARM 0x0b +#define REG_DAY_ALARM 0x0c +#define REG_WEEKDAY_ALARM 0x0d +#define ALARM_DIS BIT(7) + #define REG_OFFSET 0x0e #define REG_OFFSET_MODE BIT(7) +#define REG_TMR_CLKOUT_CTRL 0x0f + +struct pcf8523 { + struct rtc_device *rtc; + struct i2c_client *client; +}; + static int pcf8523_read(struct i2c_client *client, u8 reg, u8 *valuep) { struct i2c_msg msgs[2]; @@ -138,6 +156,27 @@ static int pcf8523_set_pm(struct i2c_client *client, u8 pm) return 0; } +static irqreturn_t pcf8523_irq(int irq, void *dev_id) +{ + struct pcf8523 *pcf8523 = i2c_get_clientdata(dev_id); + u8 value; + int err; + + err = pcf8523_read(pcf8523->client, REG_CONTROL2, &value); + if (err < 0) + return IRQ_HANDLED; + + if (value & REG_CONTROL2_AF) { + value &= ~REG_CONTROL2_AF; + pcf8523_write(pcf8523->client, REG_CONTROL2, value); + rtc_update_irq(pcf8523->rtc, 1, RTC_IRQF | RTC_AF); + + return IRQ_HANDLED; + } + + return IRQ_NONE; +} + static int pcf8523_stop_rtc(struct i2c_client *client) { u8 value; @@ -257,6 +296,111 @@ static int pcf8523_rtc_set_time(struct device *dev, struct rtc_time *tm) return pcf8523_start_rtc(client); } +static int pcf8523_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *tm) +{ + struct i2c_client *client = to_i2c_client(dev); + u8 start = REG_MINUTE_ALARM, regs[4]; + struct i2c_msg msgs[2]; + u8 value; + int err; + + msgs[0].addr = client->addr; + msgs[0].flags = 0; + msgs[0].len = 1; + msgs[0].buf = &start; + + msgs[1].addr = client->addr; + msgs[1].flags = I2C_M_RD; + msgs[1].len = sizeof(regs); + msgs[1].buf = regs; + + err = i2c_transfer(client->adapter, msgs, ARRAY_SIZE(msgs)); + if (err < 0) + return err; + + tm->time.tm_sec = 0; + tm->time.tm_min = bcd2bin(regs[0] & 0x7F); + tm->time.tm_hour = bcd2bin(regs[1] & 0x3F); + tm->time.tm_mday = bcd2bin(regs[2] & 0x3F); + tm->time.tm_wday = bcd2bin(regs[3] & 0x7); + + err = pcf8523_read(client, REG_CONTROL1, &value); + if (err < 0) + return err; + tm->enabled = !!(value & REG_CONTROL1_AIE); + + err = pcf8523_read(client, REG_CONTROL2, &value); + if (err < 0) + return err; + tm->pending = !!(value & REG_CONTROL2_AF); + + return 0; +} + +static int pcf8523_irq_enable(struct device *dev, unsigned int enabled) +{ + struct i2c_client *client = to_i2c_client(dev); + u8 value; + int err; + + err = pcf8523_read(client, REG_CONTROL1, &value); + if (err < 0) + return err; + + value &= REG_CONTROL1_AIE; + + if (enabled) + value |= REG_CONTROL1_AIE; + + err = pcf8523_write(client, REG_CONTROL1, value); + if (err < 0) + return err; + + return 0; +} + +static int pcf8523_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *tm) +{ + struct i2c_client *client = to_i2c_client(dev); + struct i2c_msg msg; + u8 regs[5]; + int err; + + err = pcf8523_irq_enable(dev, 0); + if (err) + return err; + + err = pcf8523_write(client, REG_CONTROL2, 0); + if (err < 0) + return err; + + /* The alarm has no seconds, round up to nearest minute */ + if (tm->time.tm_sec) { + time64_t alarm_time = rtc_tm_to_time64(&tm->time); + + alarm_time += 60 - tm->time.tm_sec; + rtc_time64_to_tm(alarm_time, &tm->time); + } + + regs[0] = REG_MINUTE_ALARM; + regs[1] = bin2bcd(tm->time.tm_min); + regs[2] = bin2bcd(tm->time.tm_hour); + regs[3] = bin2bcd(tm->time.tm_mday); + regs[4] = ALARM_DIS; + msg.addr = client->addr; + msg.flags = 0; + msg.len = sizeof(regs); + msg.buf = regs; + err = i2c_transfer(client->ad
[PATCH 3/3] rtc: pcf8523: report oscillator failures
Report oscillator failures and invalid date/time on RTC_VL_READ. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf8523.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c index feadab8e3bd3..bb23379bbfc7 100644 --- a/drivers/rtc/rtc-pcf8523.c +++ b/drivers/rtc/rtc-pcf8523.c @@ -406,6 +406,8 @@ static int pcf8523_rtc_ioctl(struct device *dev, unsigned int cmd, unsigned long arg) { struct i2c_client *client = to_i2c_client(dev); + unsigned int flags = 0; + u8 value; int ret; switch (cmd) { @@ -414,9 +416,16 @@ static int pcf8523_rtc_ioctl(struct device *dev, unsigned int cmd, if (ret < 0) return ret; if (ret) - ret = RTC_VL_BACKUP_LOW; + flags |= RTC_VL_BACKUP_LOW; + + ret = pcf8523_read(client, REG_SECONDS, &value); + if (ret < 0) + return ret; + + if (value & REG_SECONDS_OS) + flags |= RTC_VL_DATA_INVALID; - return put_user(ret, (unsigned int __user *)arg); + return put_user(flags, (unsigned int __user *)arg); default: return -ENOIOCTLCMD; -- 2.30.2
[PATCH 1/3] rtc: pcf8523: remove useless define
Drop DRIVER_NAME as it is only used once Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-pcf8523.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c index 5e1e7b2a8c9a..fe3ab41d8326 100644 --- a/drivers/rtc/rtc-pcf8523.c +++ b/drivers/rtc/rtc-pcf8523.c @@ -9,8 +9,6 @@ #include #include -#define DRIVER_NAME "rtc-pcf8523" - #define REG_CONTROL1 0x00 #define REG_CONTROL1_CAP_SEL BIT(7) #define REG_CONTROL1_STOPBIT(5) @@ -373,7 +371,7 @@ MODULE_DEVICE_TABLE(of, pcf8523_of_match); static struct i2c_driver pcf8523_driver = { .driver = { - .name = DRIVER_NAME, + .name = "rtc-pcf8523", .of_match_table = of_match_ptr(pcf8523_of_match), }, .probe = pcf8523_probe, -- 2.30.2
Re: [PATCH 05/15] x86: Implement function_nocfi
On Sat, Apr 17, 2021 at 4:53 PM Thomas Gleixner wrote: > > On Sat, Apr 17 2021 at 16:19, Andy Lutomirski wrote: > > On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote: > >> Okay, you're saying you want __builtin_gimme_body_p() to be a constant > >> expression for the compiler, not inline asm? > > > > Yes. > > > > I admit that, in the trivial case where the asm code is *not* a > > C-ABI-compliant function, giving a type that doesn't fool the compiler > > into thinking that it might be is probably the best fix. Maybe we > > should standardize something, e.g.: > > > > struct raw_symbol; /* not defined anywhere */ > > #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[] > > > > and then we write this: > > > > DECLARE_RAW_SYMBOL(entry_SYSCALL_64); > > > > wrmsrl(..., (unsigned long)entry_SYSCALL_64); > > > > It would be a bit nifty if we didn't need a forward declaration, but > > I'm not immediately seeing a way to do this without hacks that we'll > > probably regret; > > > > But this doesn't help the case in which the symbol is an actual > > C-callable function and we want to be able to call it, too. > > The right way to solve this is that the compiler provides a builtin > > function_nocfi() +/- the naming bikeshed > > which works for > > foo = function_nocfi(bar); I agree in general. But right now, we have, in asm/proto.h: void entry_SYSCALL_64(void); and that's pure nonsense. Depending on your point of view, entry_SYSCALL_64 is a symbol that resolves to an integer or it's an array of bytes containing instructions, but it is most definitely not a function void (void). So, regardless of any CFI stuff, I propose that we standardize our handling of prototypes of symbols that are opaque to the C compiler. Here are a couple of choices: Easy one: extern u8 entry_SYSCALL_64[]; Slightly more complicated: struct opaque_symbol; extern struct opaque_symbol entry_SYSCALL_64; The opaque_symbol variant avoids any possible confusion over the weird status of arrays in C, and it's hard to misuse, since struct opaque_symbol is an incomplete type. --Andy
Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang
On Sat, 2021-04-17 at 14:30 -0400, Jes Sorensen wrote: > On 4/17/21 1:52 PM, Kalle Valo wrote: > > "Gustavo A. R. Silva" wrote: > > > > > In preparation to enable -Wimplicit-fallthrough for Clang, fix > > > multiple warnings by replacing /* fall through */ comments with > > > the new pseudo-keyword macro fallthrough; instead of letting the > > > code fall through to the next case. > > > > > > Notice that Clang doesn't recognize /* fall through */ comments as > > > implicit fall-through markings. > > > > > > Link: https://github.com/KSPP/linux/issues/115 > > > Signed-off-by: Gustavo A. R. Silva > > > > Patch applied to wireless-drivers-next.git, thanks. > > > > bf3365a856a1 rtl8xxxu: Fix fall-through warnings for Clang > > > > Sorry this junk patch should not have been applied. I don't believe it's a junk patch. I believe your characterization of it as such is flawed. You don't like the style, that's fine, but: Any code in the kernel should not be a unique style of your own choosing when it could cause various compilers to emit unnecessary warnings. Please remember the kernel code base is a formed by a community with a nominally generally accepted style. There is a real desire in that community to both enable compiler warnings that might show defects and simultaneously avoid unnecessary compiler warnings. This particular change just avoids a possible compiler warning.
Re: mmu.c:undefined reference to `patch__hash_page_A0'
HI-- I no longer see this build error. However: On 2/27/21 2:24 AM, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 3fb6d0e00efc958d01c2f109c8453033a2d96796 > commit: 259149cf7c3c6195e6199e045ca988c31d081cab powerpc/32s: Only build hash > code when CONFIG_PPC_BOOK3S_604 is selected > date: 4 weeks ago > config: powerpc64-randconfig-r013-20210227 (attached as .config) ktr/lkp, this is a PPC32 .config file that is attached, not PPC64. Also: > compiler: powerpc-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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=259149cf7c3c6195e6199e045ca988c31d081cab > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 259149cf7c3c6195e6199e045ca988c31d081cab > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=powerpc64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function > `MMU_init_hw_patch': >>> mmu.c:(.init.text+0x75e): undefined reference to `patch__hash_page_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x76a): undefined reference to >>> `patch__hash_page_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x776): undefined reference to >>> `patch__hash_page_A1' >powerpc-linux-ld: mmu.c:(.init.text+0x782): undefined reference to > `patch__hash_page_A1' >>> powerpc-linux-ld: mmu.c:(.init.text+0x78e): undefined reference to >>> `patch__hash_page_A2' >powerpc-linux-ld: mmu.c:(.init.text+0x79a): undefined reference to > `patch__hash_page_A2' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7aa): undefined reference to >>> `patch__hash_page_B' >powerpc-linux-ld: mmu.c:(.init.text+0x7b6): undefined reference to > `patch__hash_page_B' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7c2): undefined reference to >>> `patch__hash_page_C' >powerpc-linux-ld: mmu.c:(.init.text+0x7ce): undefined reference to > `patch__hash_page_C' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7da): undefined reference to >>> `patch__flush_hash_A0' >powerpc-linux-ld: mmu.c:(.init.text+0x7e6): undefined reference to > `patch__flush_hash_A0' >>> powerpc-linux-ld: mmu.c:(.init.text+0x7f2): undefined reference to >>> `patch__flush_hash_A1' >powerpc-linux-ld: mmu.c:(.init.text+0x7fe): undefined reference to > `patch__flush_hash_A1' >>> powerpc-linux-ld: mmu.c:(.init.text+0x80a): undefined reference to >>> `patch__flush_hash_A2' >powerpc-linux-ld: mmu.c:(.init.text+0x816): undefined reference to > `patch__flush_hash_A2' >>> powerpc-linux-ld: mmu.c:(.init.text+0x83e): undefined reference to >>> `patch__flush_hash_B' >powerpc-linux-ld: mmu.c:(.init.text+0x84e): undefined reference to > `patch__flush_hash_B' >powerpc-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function > `update_mmu_cache': >>> mmu.c:(.text.update_mmu_cache+0xa0): undefined reference to `add_hash_page' I do see this build error: powerpc-linux-ld: arch/powerpc/boot/wrapper.a(decompress.o): in function `partial_decompress': decompress.c:(.text+0x1f0): undefined reference to `__decompress' when either CONFIG_KERNEL_LZO=y or CONFIG_KERNEL_LZMA=y but the build succeeds when either CONFIG_KERNEL_GZIP=y or CONFIG_KERNEL_XZ=y I guess that is due to arch/powerpc/boot/decompress.c doing this: #ifdef CONFIG_KERNEL_GZIP # include "decompress_inflate.c" #endif #ifdef CONFIG_KERNEL_XZ # include "xz_config.h" # include "../../../lib/decompress_unxz.c" #endif It would be nice to require one of KERNEL_GZIP or KERNEL_XZ to be set/enabled (maybe unless a uImage is being built?). ta. -- ~Randy
[PATCH v2 3/3] rtc: rtc_update_irq_enable: rework UIE emulation
Now that the core is aware of whether alarms are available, it is possible to decide whether UIE emulation is required before actually trying to set the alarm. This greatly simplifies rtc_update_irq_enable because there is now only one error value to track and is not relying on the return value of __rtc_set_alarm anymore. Tested-by: Łukasz Stelmach Signed-off-by: Alexandre Belloni --- Changes in v2: - Fix possible deadlock when using UIE emulation (no impact on Łukasz' test) - Remove rc drivers/rtc/interface.c | 34 ++ 1 file changed, 10 insertions(+), 24 deletions(-) diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c index dcb34c73319e..9a2bd4947007 100644 --- a/drivers/rtc/interface.c +++ b/drivers/rtc/interface.c @@ -545,7 +545,7 @@ EXPORT_SYMBOL_GPL(rtc_alarm_irq_enable); int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int enabled) { - int rc = 0, err; + int err; err = mutex_lock_interruptible(&rtc->ops_lock); if (err) @@ -561,17 +561,21 @@ int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int enabled) if (rtc->uie_rtctimer.enabled == enabled) goto out; - if (rtc->uie_unsupported) { - err = -EINVAL; - goto out; + if (rtc->uie_unsupported || !test_bit(RTC_FEATURE_ALARM, rtc->features)) { + mutex_unlock(&rtc->ops_lock); +#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL + return rtc_dev_update_irq_enable_emul(rtc, enabled); +#else + return -EINVAL; +#endif } if (enabled) { struct rtc_time tm; ktime_t now, onesec; - rc = __rtc_read_time(rtc, &tm); - if (rc) + err = __rtc_read_time(rtc, &tm); + if (err) goto out; onesec = ktime_set(1, 0); now = rtc_tm_to_ktime(tm); @@ -585,24 +589,6 @@ int rtc_update_irq_enable(struct rtc_device *rtc, unsigned int enabled) out: mutex_unlock(&rtc->ops_lock); - /* -* __rtc_read_time() failed, this probably means that the RTC time has -* never been set or less probably there is a transient error on the -* bus. In any case, avoid enabling emulation has this will fail when -* reading the time too. -*/ - if (rc) - return rc; - -#ifdef CONFIG_RTC_INTF_DEV_UIE_EMUL - /* -* Enable emulation if the driver returned -EINVAL to signal that it has -* been configured without interrupts or they are not available at the -* moment. -*/ - if (err == -EINVAL) - err = rtc_dev_update_irq_enable_emul(rtc, enabled); -#endif return err; } EXPORT_SYMBOL_GPL(rtc_update_irq_enable); -- 2.30.2
[PATCH v2 2/3] rtc: ds1307: remove flags
flags is now unused, drop it. Tested-by: Łukasz Stelmach Reviewed-by: Łukasz Stelmach Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-ds1307.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index 76d67c419f7d..089509d0a3a0 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -169,8 +169,6 @@ enum ds_type { struct ds1307 { enum ds_typetype; - unsigned long flags; -#define HAS_NVRAM 0 /* bit 0 == sysfs file active */ struct device *dev; struct regmap *regmap; const char *name; -- 2.30.2
[PATCH v2 1/3] rtc: ds1307: replace HAS_ALARM by RTC_FEATURE_ALARM
The core now has RTC_FEATURE_ALARM for the driver to indicate whether alarms are available. Use that instead of HAS_ALARM to ensure the alarm callbacks are not even called. Tested-by: Łukasz Stelmach Reviewed-by: Łukasz Stelmach Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-ds1307.c | 42 +++- 1 file changed, 7 insertions(+), 35 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index cd8e438bc9c4..76d67c419f7d 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -171,7 +171,6 @@ struct ds1307 { enum ds_typetype; unsigned long flags; #define HAS_NVRAM 0 /* bit 0 == sysfs file active */ -#define HAS_ALARM 1 /* bit 1 == irq claimed */ struct device *dev; struct regmap *regmap; const char *name; @@ -411,9 +410,6 @@ static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t) int ret; u8 regs[9]; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - /* read all ALARM1, ALARM2, and status registers at once */ ret = regmap_bulk_read(ds1307->regmap, DS1339_REG_ALARM1_SECS, regs, sizeof(regs)); @@ -454,9 +450,6 @@ static int ds1337_set_alarm(struct device *dev, struct rtc_wkalrm *t) u8 control, status; int ret; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - dev_dbg(dev, "%s secs=%d, mins=%d, " "hours=%d, mday=%d, enabled=%d, pending=%d\n", "alarm set", t->time.tm_sec, t->time.tm_min, @@ -512,9 +505,6 @@ static int ds1307_alarm_irq_enable(struct device *dev, unsigned int enabled) { struct ds1307 *ds1307 = dev_get_drvdata(dev); - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -ENOTTY; - return regmap_update_bits(ds1307->regmap, DS1337_REG_CONTROL, DS1337_BIT_A1IE, enabled ? DS1337_BIT_A1IE : 0); @@ -592,9 +582,6 @@ static int rx8130_read_alarm(struct device *dev, struct rtc_wkalrm *t) u8 ald[3], ctl[3]; int ret; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - /* Read alarm registers. */ ret = regmap_bulk_read(ds1307->regmap, RX8130_REG_ALARM_MIN, ald, sizeof(ald)); @@ -634,9 +621,6 @@ static int rx8130_set_alarm(struct device *dev, struct rtc_wkalrm *t) u8 ald[3], ctl[3]; int ret; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - dev_dbg(dev, "%s, sec=%d min=%d hour=%d wday=%d mday=%d mon=%d " "enabled=%d pending=%d\n", __func__, t->time.tm_sec, t->time.tm_min, t->time.tm_hour, @@ -681,9 +665,6 @@ static int rx8130_alarm_irq_enable(struct device *dev, unsigned int enabled) struct ds1307 *ds1307 = dev_get_drvdata(dev); int ret, reg; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - ret = regmap_read(ds1307->regmap, RX8130_REG_CONTROL0, ®); if (ret < 0) return ret; @@ -735,9 +716,6 @@ static int mcp794xx_read_alarm(struct device *dev, struct rtc_wkalrm *t) u8 regs[10]; int ret; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - /* Read control and alarm 0 registers. */ ret = regmap_bulk_read(ds1307->regmap, MCP794XX_REG_CONTROL, regs, sizeof(regs)); @@ -793,9 +771,6 @@ static int mcp794xx_set_alarm(struct device *dev, struct rtc_wkalrm *t) unsigned char regs[10]; int wday, ret; - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - wday = mcp794xx_alm_weekday(dev, &t->time); if (wday < 0) return wday; @@ -842,9 +817,6 @@ static int mcp794xx_alarm_irq_enable(struct device *dev, unsigned int enabled) { struct ds1307 *ds1307 = dev_get_drvdata(dev); - if (!test_bit(HAS_ALARM, &ds1307->flags)) - return -EINVAL; - return regmap_update_bits(ds1307->regmap, MCP794XX_REG_CONTROL, MCP794XX_BIT_ALM0_EN, enabled ? MCP794XX_BIT_ALM0_EN : 0); @@ -1641,7 +1613,7 @@ static int ds3231_clks_register(struct ds1307 *ds1307) * Interrupt signal due to alarm conditions and square-wave * output share same pin, so don't initialize both. */ - if (i == DS3231_CLK_SQW && test_bit(HAS_ALARM, &ds1307->flags)) + if (i == DS3231_CLK_SQW && test_bit(RTC_FEATURE_ALARM, ds1307->rtc->features))
[tip:locking/urgent] BUILD SUCCESS 84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/urgent branch HEAD: 84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896 locking/qrwlock: Fix ordering in queued_write_lock_slowpath() elapsed time: 723m configs tested: 119 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc ebony_defconfig powerpc ksi8560_defconfig powerpc pcm030_defconfig powerpc pasemi_defconfig m68k amiga_defconfig ia64 tiger_defconfig mips decstation_64_defconfig powerpcicon_defconfig powerpc arches_defconfig armvexpress_defconfig powerpc eiger_defconfig shhp6xx_defconfig armtrizeps4_defconfig powerpc motionpro_defconfig powerpc powernv_defconfig sh espt_defconfig m68kmvme147_defconfig sh se7780_defconfig sh lboxre2_defconfig mips gcw0_defconfig arm aspeed_g5_defconfig xtensasmp_lx200_defconfig powerpc sbc8548_defconfig sh rts7751r2dplus_defconfig powerpc ppc44x_defconfig armzeus_defconfig sh se7705_defconfig arm omap2plus_defconfig powerpc mpc83xx_defconfig mips loongson3_defconfig riscv rv32_defconfig i386 alldefconfig armshmobile_defconfig mips pic32mzda_defconfig m68k atari_defconfig openriscdefconfig arm s3c2410_defconfig arm bcm2835_defconfig powerpcsocrates_defconfig arm rpc_defconfig arm footbridge_defconfig armneponset_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 riscv
[tip:sched/core] BUILD SUCCESS 9406415f46f6127fd31bb66f0260f7a61a8d2786
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: 9406415f46f6127fd31bb66f0260f7a61a8d2786 sched/debug: Rename the sched_debug parameter to sched_verbose elapsed time: 723m configs tested: 97 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig powerpc ebony_defconfig powerpc ksi8560_defconfig arm davinci_all_defconfig sh se7750_defconfig powerpc pcm030_defconfig arm aspeed_g5_defconfig powerpc eiger_defconfig powerpc mpc834x_mds_defconfig armzeus_defconfig sh se7705_defconfig arm omap2plus_defconfig powerpc mpc83xx_defconfig mips loongson3_defconfig riscv rv32_defconfig i386 alldefconfig armshmobile_defconfig mips pic32mzda_defconfig m68k atari_defconfig openriscdefconfig arm s3c2410_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a003-20210417 i386 randconfig-a006-20210417 i386 randconfig-a001-20210417 i386 randconfig-a005-20210417 i386 randconfig-a004-20210417 i386 randconfig-a002-20210417 i386 randconfig-a015-20210417 i386 randconfig-a014-20210417 i386 randconfig-a013-20210417 i386 randconfig-a012-20210417 i386 randconfig-a016-20210417 i386 randconfig-a011-20210417 x86_64 randconfig-a003-20210417 x86_64 randconfig-a002-20210417 x86_64 randconfig-a005-20210417 x86_64 randconfig-a001-20210417 x86_64 randconfig-a006-20210417 x86_64 randconfig-a004-20210417 riscvnommu_k210_defconfig riscvnommu_virt_defconfig riscv allnoconfig riscv 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-a014-20210417 x86_64 randconfig-a015-20210417 x86_64 randconfig-a011-20210417 x86_64 randconfig-a013-20210417 x86_64 randconfig-a012-20210417 x86_64 randconfig-a016-20210417 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 05/15] x86: Implement function_nocfi
On Sat, Apr 17 2021 at 16:19, Andy Lutomirski wrote: > On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote: >> Okay, you're saying you want __builtin_gimme_body_p() to be a constant >> expression for the compiler, not inline asm? > > Yes. > > I admit that, in the trivial case where the asm code is *not* a > C-ABI-compliant function, giving a type that doesn't fool the compiler > into thinking that it might be is probably the best fix. Maybe we > should standardize something, e.g.: > > struct raw_symbol; /* not defined anywhere */ > #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[] > > and then we write this: > > DECLARE_RAW_SYMBOL(entry_SYSCALL_64); > > wrmsrl(..., (unsigned long)entry_SYSCALL_64); > > It would be a bit nifty if we didn't need a forward declaration, but > I'm not immediately seeing a way to do this without hacks that we'll > probably regret; > > But this doesn't help the case in which the symbol is an actual > C-callable function and we want to be able to call it, too. The right way to solve this is that the compiler provides a builtin function_nocfi() +/- the naming bikeshed which works for foo = function_nocfi(bar); and static unsigned long foo[] = { function_nocfi(bar1), function_nocfi(bar2), }; which are pretty much the only possible 2 usecases. If the compiler wants to have function_nocfi_in_code() and function_nocfi_const() because it can't figure it out on it's own, then I can live with that, but that's still several orders of magnitudes better than having to work around it by whatever nasty macro/struct magic. I don't care about the slightly more unreadable code, but if that builtin has a descriptive name, then it's even useful for documentary purposes. And it can be easily grepped for which makes it subject to static code analysers which can help to detect abuse. Anything which requires to come up with half baken constructs to work around the shortcomings of the compiler are wrong to begin with. Thanks, tglx
[PATCH] imx-sc: remove .read_alarm
The RTC core properly handles RTC without .read_alarm and doesn't use it to set alarms. .read_alarm can be safely dropped. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-imx-sc.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/rtc/rtc-imx-sc.c b/drivers/rtc/rtc-imx-sc.c index cc9fbab4..814d516645e2 100644 --- a/drivers/rtc/rtc-imx-sc.c +++ b/drivers/rtc/rtc-imx-sc.c @@ -80,16 +80,6 @@ static int imx_sc_rtc_alarm_irq_enable(struct device *dev, unsigned int enable) return imx_scu_irq_group_enable(SC_IRQ_GROUP_RTC, SC_IRQ_RTC, enable); } -static int imx_sc_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm) -{ - /* -* SCU firmware does NOT provide read alarm API, but .read_alarm -* callback is required by RTC framework to support alarm function, -* so just return here. -*/ - return 0; -} - static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm) { struct imx_sc_msg_timer_rtc_set_alarm msg; @@ -127,7 +117,6 @@ static int imx_sc_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm) static const struct rtc_class_ops imx_sc_rtc_ops = { .read_time = imx_sc_rtc_read_time, .set_time = imx_sc_rtc_set_time, - .read_alarm = imx_sc_rtc_read_alarm, .set_alarm = imx_sc_rtc_set_alarm, .alarm_irq_enable = imx_sc_rtc_alarm_irq_enable, }; -- 2.30.2
Re: [PATCH v8 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sat, Apr 17, 2021 at 02:47:18PM +0200, Thomas Gleixner wrote: > On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote: > > Bah, hit send too quick. > > > + cpumask_clear(&cpus_ahead); > > + cpumask_clear(&cpus_behind); > > + preempt_disable(); > > Daft. Would migrate_disable() be better? Yes, I know, in virtual environments, the hypervisor can migrate anyway, but this does limit the potential damage to one out of the two schedulers. > > + testcpu = smp_processor_id(); > > + pr_warn("Checking clocksource %s synchronization from CPU %d.\n", > > cs->name, testcpu); > > + for_each_online_cpu(cpu) { > > + if (cpu == testcpu) > > + continue; > > + csnow_begin = cs->read(cs); > > + smp_call_function_single(cpu, clocksource_verify_one_cpu, cs, > > 1); > > + csnow_end = cs->read(cs); > > As this must run with interrupts enabled, that's a pretty rough > approximation like measuring wind speed with a wet thumb. > > Wouldn't it be smarter to let the remote CPU do the watchdog dance and > take that result? i.e. split out more of the watchdog code so that you > can get the nanoseconds delta on that remote CPU to the watchdog. First, an interrupt, NMI, SMI, vCPU preemption, or whatever could not cause a false positive. A false negative, perhaps, but no false positives. Second, in normal operation, these are rare, so that hitting the (eventual) default of eight CPUs is very likely to result in tight bounds on the delay-based error for most of those CPUs. Third, we really need to compare the TSC on one CPU to the TSC on the other in order to have a very clear indication of a problem, should a real TSC-synchronization issue arise. In contrast, comparisons against the watchdog timer will be more complicated and any errors detected will be quite hard to prove to be due to TSC issues. Or am I once again missing something? > > + delta = (s64)((csnow_mid - csnow_begin) & cs->mask); > > + if (delta < 0) > > + cpumask_set_cpu(cpu, &cpus_behind); > > + delta = (csnow_end - csnow_mid) & cs->mask; > > + if (delta < 0) > > + cpumask_set_cpu(cpu, &cpus_ahead); > > + delta = clocksource_delta(csnow_end, csnow_begin, cs->mask); > > + cs_nsec = clocksource_cyc2ns(delta, cs->mult, cs->shift); > > > + if (firsttime || cs_nsec > cs_nsec_max) > > + cs_nsec_max = cs_nsec; > > + if (firsttime || cs_nsec < cs_nsec_min) > > + cs_nsec_min = cs_nsec; > > + firsttime = 0; > > int64_t cs_nsec_max = 0, cs_nsec_min = LLONG_MAX; > > and then the firsttime muck is not needed at all. Good point, will fix! And again, thank you for looking all of this over. Thanx, Paul
[git pull] drm/vmwgfx fixes for 5.12-rc8
Hi Linus, Back from holidays and this was in the cracks (Zack forgot to cc Daniel/lists), I've just piled it onto drm fixes. It contains two regression fixes for vmwgfx, one due to a refactor which meant locks were being used before initialisation, and the other in fixing up some warnings from the core when destroying pinned buffers. Dave. drm-fixes-2021-04-18: drm/vmwgfx fixes for 5.12-rc7 vmwgfx: - fixed unpinning before destruction - lockdep init reordering The following changes since commit 4d2e1288372ccc5ac60290bc10cace49c9bfa6d0: Merge tag 'drm-intel-fixes-2021-04-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-04-15 15:24:17 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-04-18 for you to fetch changes up to 796b556cbfdbe0d65b9793e63653ad24f9fa033c: Merge tag 'vmwgfx-fixes-2021-04-14' of gitlab.freedesktop.org:zack/vmwgfx into drm-fixes (2021-04-18 09:27:00 +1000) drm/vmwgfx fixes for 5.12-rc7 vmwgfx: - fixed unpinning before destruction - lockdep init reordering Dave Airlie (1): Merge tag 'vmwgfx-fixes-2021-04-14' of gitlab.freedesktop.org:zack/vmwgfx into drm-fixes Zack Rusin (3): drm/vmwgfx: Make sure we unpin no longer needed buffers drm/vmwgfx: Fix the lockdep breakage drm/vmwgfx: Make sure bo's are unpinned before putting them back drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 - drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 + drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 14 ++ 4 files changed, 27 insertions(+), 13 deletions(-)
Re: [PATCH v8 clocksource 3/5] clocksource: Check per-CPU clock synchronization when marked unstable
On Sat, Apr 17, 2021 at 02:28:22PM +0200, Thomas Gleixner wrote: > On Tue, Apr 13 2021 at 21:36, Paul E. McKenney wrote: > > diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c > > index 1fc0962c89c0..97eeaf164296 100644 > > --- a/arch/x86/kernel/kvmclock.c > > +++ b/arch/x86/kernel/kvmclock.c > > @@ -169,7 +169,7 @@ struct clocksource kvm_clock = { > > .read = kvm_clock_get_cycles, > > .rating = 400, > > .mask = CLOCKSOURCE_MASK(64), > > - .flags = CLOCK_SOURCE_IS_CONTINUOUS, > > + .flags = CLOCK_SOURCE_IS_CONTINUOUS | CLOCK_SOURCE_VERIFY_PERCPU, > > kvm_clock is not marked with CLOCK_SOURCE_MUST_VERIFY, so what's the > point of adding this here? It's not subject to be monitored by the > watchdog muck. Good point, removed. > > diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c > > index f70dffc2771f..56289170753c 100644 > > --- a/arch/x86/kernel/tsc.c > > +++ b/arch/x86/kernel/tsc.c > > @@ -1151,7 +1151,8 @@ static struct clocksource clocksource_tsc = { > > .mask = CLOCKSOURCE_MASK(64), > > .flags = CLOCK_SOURCE_IS_CONTINUOUS | > > CLOCK_SOURCE_VALID_FOR_HRES | > > - CLOCK_SOURCE_MUST_VERIFY, > > + CLOCK_SOURCE_MUST_VERIFY | > > + CLOCK_SOURCE_VERIFY_PERCPU, > > While this one is part of the horror show. It probably would be good to decorate other arch's per-CPU clocks with CLOCK_SOURCE_VERIFY_PERCPU, but no takers thus far. Thanx, Paul > > +static u64 csnow_mid; > > +static cpumask_t cpus_ahead; > > +static cpumask_t cpus_behind; > > + > > +static void clocksource_verify_one_cpu(void *csin) > > +{ > > + struct clocksource *cs = (struct clocksource *)csin; > > + > > + csnow_mid = cs->read(cs); > > +} > > + > > +static void clocksource_verify_percpu(struct clocksource *cs) > > +{ > > + int64_t cs_nsec, cs_nsec_max, cs_nsec_min; > > + u64 csnow_begin, csnow_end; > > + bool firsttime = 1; > > + int testcpu; > > + s64 delta; > > + int cpu; > > int testcpu, cpu; :) >
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sun, Apr 18, 2021 at 01:15:26AM +0200, Thomas Gleixner wrote: > On Sat, Apr 17 2021 at 15:54, Paul E. McKenney wrote: > > On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote: > >> I so wish we could just delete all of this horror instead of making it > >> more horrible. > > > > Revisit deleting it in five years if there are no issues, whatever > > "issue" might mean in this context? Five years should give time for > > this to propagate to the enterprise distros. > > That does not help with the fact that the broken hardware will still be > around in 5 years from now. Which is what prevents me from deleting the > whole watchdog muck ... Ouch! Sigh... Thanx, Paul
drivers/md/dm-log-writes.c:452:12: warning: stack frame size of 1184 bytes in function 'log_writes_kthread'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 194cf4825638256e9afe1d360831aa5379b3517a commit: 309dca309fc39a9e3c31b916393b74bd174fd74e block: store a block_device pointer in struct bio date: 3 months ago config: powerpc64-randconfig-r032-20210418 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project f549176ad976caa3e19edd036df9a7e12770af7c) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=309dca309fc39a9e3c31b916393b74bd174fd74e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 309dca309fc39a9e3c31b916393b74bd174fd74e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :116:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :118:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :120:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:559:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~^ In file included from drivers/md/dm-log-writes.c:7: In file included from include/linux/device-mapper.h:11: In file included from include/linux/bio.h:8: In
Re: [PATCH 05/15] x86: Implement function_nocfi
On Fri, Apr 16, 2021 at 4:40 PM Kees Cook wrote: > > > 1. I defined a function in asm. I want to tell clang that this > > function is defined in asm, and for clang to behave accordingly: > > > > .globl func > > func: > > ; do stuff > > > > later: > > > > extern void func(void) [something here]; > > > > There really should be a way to write this correctly such that it > > works regardless of the setting of > > -fsanitize-cfi-canonical-jump-tables. This should not bypass CFI. It > > should *work*, with CFI enforced. If I read all the various things > > you linked correctly, this would be something like __cfi_noncanonical, > > and I reserve the right to think that this is a horrible name. > > Yes, I find the name confusing too. Without noncanonical, we'd need > C call wrappers for every single .S function that had its address > taken. This is very common in crypto, for example. That level of extra > code seemed like a total non-starter. Instead, we just get a few places > we have to mark. The patch you linked doesn't have a noncanonical attribute, though. So I'm not sure how to reliably call into asm from C. (The more I think about it, the less I like "canonical". What is "canonical"? The symbol? The function body? Something else?) > > > 2. I need a raw function pointer, thank you very much. I would like > > to be honest about it, and I don't really want to bypass CFI, but I > > need the actual bits in the actual symbol. > > > > translation unit 1 defines func. Maybe it's C with > > -fsanitize-cfi-canonical-jump-tables, maybe it's C with > > -fno-sanitize-cfi-canonical-jump-tables or however it's spelled, and > > maybe it's plain asm. Now translation unit 2 does: > > > > 2a. Uses a literal symbol, because it's going to modify function text > > or poke an MSR or whatever: > > > > wrmsrl(MSR_WHATEVER, func); > > > > clang needs to give us *some* way to have a correct declaration of > > func such that we can, without resorting to inline asm kludges, get > > the actual bit pattern of the actual symbol. > > We don't want version of a global symbol alias of func that points to > the function body, though; it's only very specific cases where this > should be stripped (MSR, ftrace, etc). > > So, if there were some Clang-specific syntax for this, it would still be > used on a case-by-case basis. It would still be something like: > > wrmsrl(MSR_WAT, __builtin_gimme_body_p(func)); > > Okay, you're saying you want __builtin_gimme_body_p() to be a constant > expression for the compiler, not inline asm? Yes. I admit that, in the trivial case where the asm code is *not* a C-ABI-compliant function, giving a type that doesn't fool the compiler into thinking that it might be is probably the best fix. Maybe we should standardize something, e.g.: struct raw_symbol; /* not defined anywhere */ #define DECLARE_RAW_SYMBOL(x) struct raw_symbol x[] and then we write this: DECLARE_RAW_SYMBOL(entry_SYSCALL_64); wrmsrl(..., (unsigned long)entry_SYSCALL_64); It would be a bit nifty if we didn't need a forward declaration, but I'm not immediately seeing a way to do this without hacks that we'll probably regret; But this doesn't help the case in which the symbol is an actual C-callable function and we want to be able to call it, too.
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sat, Apr 17 2021 at 15:54, Paul E. McKenney wrote: > On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote: >> I so wish we could just delete all of this horror instead of making it >> more horrible. > > Revisit deleting it in five years if there are no issues, whatever > "issue" might mean in this context? Five years should give time for > this to propagate to the enterprise distros. That does not help with the fact that the broken hardware will still be around in 5 years from now. Which is what prevents me from deleting the whole watchdog muck ... Thanks, tglx
Re: [PATCH] Fix set apic mode from x2apic enabled bit patch
Mike! On Sun, Apr 18 2021 at 00:39, Thomas Gleixner wrote: > If you can't come up with something sensible anytime soon before the > merge window opens then I'm simply going to revert 41e2da9b5e67 and you > can try again for the next cycle. so I just figured out that Boris wasted his time once more to fix that up and redo the commit in question. Won't happen again. Thanks, tglx
Re: build failure of malta_qemu_32r6_defconfig
Hi Thomas, On Fri, Apr 9, 2021 at 1:17 PM Thomas Bogendoerfer wrote: > > On Thu, Apr 08, 2021 at 09:42:11AM +0800, YunQiang Su wrote: > > Sudip Mukherjee 于2021年4月8日周四 上午2:26写道: > > > > > > Hi Thomas, > > > > > > I was building v5.10.28 with malta_qemu_32r6_defconfig and noticed that > > > it fails to build, so tried next-20210407 to see if it has been fixed. > > > But linux-next also has the issue with gcc-10. > > > > > > The error is: > > > > > > ./arch/mips/include/asm/vdso/gettimeofday.h: In function > > > '__vdso_clock_gettime': > > > ./arch/mips/include/asm/vdso/gettimeofday.h:103:2: error: the register > > > 'lo' cannot be clobbered in 'asm' for the current target > > > 103 | asm volatile( > > > | ^~~ > > > > this operation try to save lo and hi register, while they are not > > exisiting on r6. > > We are working on figure out a patch for it. > > looks like there is already a patch in patchwork, which just needs > a workup: > > https://patchwork.kernel.org/project/linux-mips/patch/20200801154401.4177009-1-romain.na...@gmail.com/ Looks like there has been no response to it since last 8 months. Do you want me to respin it and send a proper patch? -- Regards Sudip
Re: [PATCH v8 clocksource 2/5] clocksource: Retry clock read if long delays detected
On Sat, Apr 17, 2021 at 02:24:23PM +0200, Thomas Gleixner wrote: > On Tue, Apr 13 2021 at 21:35, Paul E. McKenney wrote: > > #define WATCHDOG_INTERVAL (HZ >> 1) > > #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4) > > +#define WATCHDOG_MAX_SKEW (NSEC_PER_SEC >> 6) > > That's ~15ms which is a tad large I'd say... And I have a separate patch queued to crank this down to 125us. I ran 2,664 hours of rcutorture on this patch, and saw only 18 instances of delay detected. So 125us works well, but I am not inclined to decrease it much. I will try 50us this evening though, just for grins. After all, only those who have gone too far can possibly tell you how far you can go. > > static void clocksource_watchdog_work(struct work_struct *work) > > { > > @@ -213,9 +214,10 @@ static void clocksource_watchdog_inject_delay(void) > > static void clocksource_watchdog(struct timer_list *unused) > > { > > struct clocksource *cs; > > - u64 csnow, wdnow, cslast, wdlast, delta; > > - int64_t wd_nsec, cs_nsec; > > + u64 csnow, wdnow, wdagain, cslast, wdlast, delta; > > + int64_t wd_nsec, wdagain_delta, wderr_nsec = 0, cs_nsec; > > int next_cpu, reset_pending; > > + int nretries; > > > > spin_lock(&watchdog_lock); > > if (!watchdog_running) > > @@ -224,6 +226,7 @@ static void clocksource_watchdog(struct timer_list > > *unused) > > reset_pending = atomic_read(&watchdog_reset_pending); > > > > list_for_each_entry(cs, &watchdog_list, wd_list) { > > + nretries = 0; > > > > /* Clocksource already marked unstable? */ > > if (cs->flags & CLOCK_SOURCE_UNSTABLE) { > > @@ -232,11 +235,24 @@ static void clocksource_watchdog(struct timer_list > > *unused) > > continue; > > } > > > > +retry: > > local_irq_disable(); > > - csnow = cs->read(cs); > > - clocksource_watchdog_inject_delay(); > > wdnow = watchdog->read(watchdog); > > + clocksource_watchdog_inject_delay(); > > + csnow = cs->read(cs); > > + wdagain = watchdog->read(watchdog); > > local_irq_enable(); > > + delta = clocksource_delta(wdagain, wdnow, watchdog->mask); > > + wdagain_delta = clocksource_cyc2ns(delta, watchdog->mult, > > watchdog->shift); > > + if (wdagain_delta > WATCHDOG_MAX_SKEW) { > > + wderr_nsec = wdagain_delta; > > + if (nretries++ < max_read_retries) > > + goto retry; > > + } > > + if (nretries) { > > + pr_warn("timekeeping watchdog on CPU%d: %s read-back > > delay of %lldns, attempt %d\n", > > + smp_processor_id(), watchdog->name, wderr_nsec, > > nretries); > > + } > > > > /* Clocksource initialized ? */ > > if (!(cs->flags & CLOCK_SOURCE_WATCHDOG) || > > This can nicely be split out into a read function which avoids brain > overload when reading. Something like the uncompiled below. Good point, done, with minor adjustments. > I so wish we could just delete all of this horror instead of making it > more horrible. Revisit deleting it in five years if there are no issues, whatever "issue" might mean in this context? Five years should give time for this to propagate to the enterprise distros. Thanx, Paul > Thanks, > > tglx > --- > --- a/kernel/time/clocksource.c > +++ b/kernel/time/clocksource.c > @@ -124,6 +124,12 @@ static void __clocksource_change_rating( > #define WATCHDOG_INTERVAL (HZ >> 1) > #define WATCHDOG_THRESHOLD (NSEC_PER_SEC >> 4) > > +/* > + * The maximum delay between two consecutive readouts of the watchdog > + * clocksource to detect SMI,NMI,vCPU preemption. > + */ > +#define WATCHDOG_MAX_DELAY (100 * NSEC_PER_USEC) > + > static void clocksource_watchdog_work(struct work_struct *work) > { > /* > @@ -184,12 +190,37 @@ void clocksource_mark_unstable(struct cl > spin_unlock_irqrestore(&watchdog_lock, flags); > } > > +static bool cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow) > +{ > + unsigned int nretries; > + u64 wd_end, wd_delta; > + int64_t wd_delay; > + > + for (nretries = 0; nretries < max_read_retries; nretries++) { > + local_irq_disable(); > + *wdnow = watchdog->read(watchdog); > + clocksource_watchdog_inject_delay(); > + *csnow = cs->read(cs); > + wd_end = watchdog->read(watchdog); > + local_irq_enable(); > + > + wd_delta = clocksource_delta(wd_end, *wdnow, watchdog->mask); > + wd_delay = clocksource_cyc2ns(wd_delta, watchdog->mult, > watchdog->shift); > + if (wd_delay < WATCHDOG_MAX_DELAY) > + return true; > + } > + > + pr_warn("timekeeping watchdog on CPU%d: %s read-back delay of %lldns, > %d a
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Sat, Apr 17, 2021 at 09:18:57PM +, David Laight wrote: > Ugly as well. Thank you for expressing your opinion. Again.
Re: [PATCH] Fix set apic mode from x2apic enabled bit patch
Mike! On Thu, Apr 15 2021 at 17:06, Mike Travis wrote: I'm slowly getting tired of the fact that every patch coming from you fails to comply with the minimal requirements of the documented procedures. $subject: [PATCH] Fix set apic mode from x2apic enabled bit patch Documentation clearly states, that there has to be a subsystem prefix. It's not rocket science to figure it out: # git log arch/x86/kernel/apic/x2apic_uv_x.c gives you a pretty good hint that the prefix should be: x86/platform/uv: It's not that hard and it's not optional. Also what the heck means: Fix set apic mode from x2apic enabled bit patch Again documentation is very clear about what the subject line, aka git shortlog of a patch should look like. This sentence is just word salad and does not give any clue of what this is about. Even you wont be able to decode this 3 month from now. Simply because it's word salad. I don't care what kind of standards you have @hpe, but I very much care about the standards of the kernel. > Do not set uv_system_type for hubless UV systems as it tricks the > is_uv_system function into thinking it's a UV hubbed system and includes > a UV HUB RTC. This causes UV RTC init to panic on UV hubless systems. And yet more word salad. Can you please describe the precise technical problem and not use metaphors of functions which are thinking? Aside of that this does not describe the change at all. The change is: > - early_set_apic_mode(); but your changelog blurbs about "thinking it's an UV hubbed system". How the heck can this make sense for someone who is not part of the @hpe universe mindset? > Fixes: 41e2da9b5e67 ("x86/platform/uv: Use x2apic enabled bit as set by BIOS > to indicate APIC mode") > > [41e2da9b5e67 was accepted into tip x86/platform branch but not yet > pulled into the linus tree.] Truly useful. The only value of that information is that the maintainer has to manualy remove it because it's irrelevant for the final commit message of the change which ends up on top of that commit in that branch. You can stick this into the section below '---' if you think it's helpful, but then maintainers and tools can just ignore it. TBH, it's not helpful at all because tooling already tells us that 41e2da9b5e67 is not in Linus tree and only queued in tip x86/platform. Commit SHAs are supposed to be unique for a reason... > Signed-off-by: Mike Travis > Reviewed-by: Steve Wahl > Reviewed-by: Dimitri Sivanich The value of these reviewed-by tags is close to zero because they are just documenting that the change is ok at the @hpe universe level... > --- > arch/x86/kernel/apic/x2apic_uv_x.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c > b/arch/x86/kernel/apic/x2apic_uv_x.c > index 2e99605f9a05..68ef9abc91f7 100644 > --- a/arch/x86/kernel/apic/x2apic_uv_x.c > +++ b/arch/x86/kernel/apic/x2apic_uv_x.c > @@ -413,9 +413,8 @@ static int __init uv_set_system_type(char *_oem_id, char > *_oem_table_id) > else > uv_hubless_system |= 0x8; > > - /* Copy OEM Table ID and set APIC Mode */ > + /* Copy OEM Table ID */ > uv_stringify(sizeof(oem_table_id), oem_table_id, _oem_table_id); > - early_set_apic_mode(); So the patch itself tells me more about what's going on than the changelog: Setting up the APIC mode at this place is wrong. But it does not tell me WHY. Neither does the changelog because of useless word salad... If you can't come up with something sensible anytime soon before the merge window opens then I'm simply going to revert 41e2da9b5e67 and you can try again for the next cycle. Thanks, tglx
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 1:35 PM Al Viro wrote: > > No, wait - we have non-NULL buf->prev_reclen, so we'll hit > with buf->error completely ignored. Nevermind. Yeah, I'm pretty sure I even tested that -EINTR case at one point. Of course, it could easily have gotten broken again, so that's not a strong argument. That said, the "buf->err" handling has always been very confusing, and it would be lovely to get rid of that confusion. I don't remember why we did it that way, but I think it's because low-level filesystems ended up changing the error that the filldir() function returned or something like that. Linus
Re: [PATCH] block: fix io hung by block throttle
On 4/17/21 3:10 AM, Hillf Danton wrote: --- a/block/blk-rq-qos.c +++ b/block/blk-rq-qos.c @@ -260,19 +260,17 @@ void rq_qos_wait(struct rq_wait *rqw, void *private_data, .cb = acquire_inflight_cb, .private_data = private_data, }; - bool has_sleeper; - has_sleeper = wq_has_sleeper(&rqw->wait); - if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) + if (!wq_has_sleeper(&rqw->wait) + && acquire_inflight_cb(rqw, private_data)) return; prepare_to_wait_exclusive(&rqw->wait, &data.wq, TASK_UNINTERRUPTIBLE); - has_sleeper = !wq_has_single_sleeper(&rqw->wait); do { /* The memory barrier in set_task_state saves us here. */ if (data.got_token) break; - if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) { + if (acquire_inflight_cb(rqw, private_data)) { finish_wait(&rqw->wait, &data.wq); Simply removing !has_sleeper is not enough if it is mandatory before acquire_inflight_cb() without adding something like a mutex to sieve the concurrent sleepers out, see below. --- a/block/blk-rq-qos.c +++ b/block/blk-rq-qos.c @@ -260,19 +260,18 @@ void rq_qos_wait(struct rq_wait *rqw, vo .cb = acquire_inflight_cb, .private_data = private_data, }; - bool has_sleeper; - has_sleeper = wq_has_sleeper(&rqw->wait); - if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) - return; + mutex_lock(&rqw->mutex); + + if (acquire_inflight_cb(rqw, private_data)) This function is to increase atomic variable rq_wait->inflight. What's the mutex for? Thanks, Junxiao. + goto out; prepare_to_wait_exclusive(&rqw->wait, &data.wq, TASK_UNINTERRUPTIBLE); - has_sleeper = !wq_has_single_sleeper(&rqw->wait); do { /* The memory barrier in set_task_state saves us here. */ if (data.got_token) break; - if (!has_sleeper && acquire_inflight_cb(rqw, private_data)) { + if (acquire_inflight_cb(rqw, private_data)) { finish_wait(&rqw->wait, &data.wq); /* @@ -286,10 +285,11 @@ void rq_qos_wait(struct rq_wait *rqw, vo break; } io_schedule(); - has_sleeper = true; set_current_state(TASK_UNINTERRUPTIBLE); } while (1); finish_wait(&rqw->wait, &data.wq); +out: + mutex_unlock(&rqw->mutex); }
RE: [PATCH] media: atomisp: silence "dubious: !x | !y" warning
From: Mauro Carvalho Chehab > Sent: 17 April 2021 19:56 > > Em Sat, 17 Apr 2021 21:06:27 +0530 > Ashish Kalra escreveu: > > > Upon running sparse, "warning: dubious: !x | !y" is brought to notice > > for this file. Logical and bitwise OR are basically the same in this > > context so it doesn't cause a runtime bug. But let's change it to > > logical OR to make it cleaner and silence the Sparse warning. The old code is very likely to by slightly more efficient. It may not matter here, but it might in a really hot path. Since !x | !y and !x || !y always have the same value why is sparse complaining at all. David > > > > Signed-off-by: Ashish Kalra > > --- > > .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > index 358cb7d2cd4c..3b850bb2d39d 100644 > > --- > > a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > +++ > > b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c > > @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2( > > unsigned int ds_log2 = 0; > > unsigned int out_width; > > > > - if ((!out_info) | (!vf_info)) > > + if ((!out_info) || (!vf_info)) > > > While here, please get rid of the unneeded parenthesis: > > if (!out_info || !vf_info) > > > > return -EINVAL; > > > > out_width = out_info->res.width; > > > > Thanks, > Mauro - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
On Sat, Apr 17, 2021 at 09:13:45PM +, David Laight wrote: > > struct {/* page_pool used by netstack */ > > - /** > > -* @dma_addr: might require a 64-bit value on > > -* 32-bit architectures. > > -*/ > > + unsigned long pp_magic; > > + unsigned long xmi; > > + unsigned long _pp_mapping_pad; > > unsigned long dma_addr[2]; > > }; > > You've deleted the comment. Yes. It no longer added any value. You can see dma_addr now occupies two words. > I also think there should be a comment that dma_addr[0] > must be aliased to ->index. That's not a requirement. Moving the pfmemalloc indicator is a requirement so that we _can_ use index, but there's no requirement about how index is used.
RE: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
From: Matthew Wilcox > Sent: 17 April 2021 03:45 > > Replacement patch to fix compiler warning. ... > static inline dma_addr_t page_pool_get_dma_addr(struct page *page) > { > - return page->dma_addr; > + dma_addr_t ret = page->dma_addr[0]; > + if (sizeof(dma_addr_t) > sizeof(unsigned long)) > + ret |= (dma_addr_t)page->dma_addr[1] << 16 << 16; Ugly as well. Why not just replace the (dma_addr_t) cast with a (u64) one? Looks better than the double shift. Same could be done for the '>> 32'. Is there an upper_32_bits() that could be used?? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
RE: [PATCH 2/2] mm: Indicate pfmemalloc pages in compound_head
From: Matthew Wilcox (Oracle) > Sent: 17 April 2021 00:07 > > The net page_pool wants to use a magic value to identify page pool pages. > The best place to put it is in the first word where it can be clearly a > non-pointer value. That means shifting dma_addr up to alias with ->index, > which means we need to find another way to indicate page_is_pfmemalloc(). > Since page_pool doesn't want to set its magic value on pages which are > pfmemalloc, we can use bit 1 of compound_head to indicate that the page > came from the memory reserves. > ... > struct {/* page_pool used by netstack */ > - /** > - * @dma_addr: might require a 64-bit value on > - * 32-bit architectures. > - */ > + unsigned long pp_magic; > + unsigned long xmi; > + unsigned long _pp_mapping_pad; > unsigned long dma_addr[2]; > }; You've deleted the comment. I also think there should be a comment that dma_addr[0] must be aliased to ->index. (Or whatever all the exact requirements are.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 00/13] [RFC] Rust support
On Thu, Apr 15, 2021 at 2:41 AM wrote: > Regarding compilers, we support Clang-built kernels as well as > `LLVM=1` builds where possible (i.e. as long as supported by > the ClangBuiltLinux project). We also maintain some configurations > of GCC-built kernels working, but they are not intended to be used > at the present time. Having a `bindgen` backend for GCC would be > ideal to improve support for those builds. Sp this effectively means gcc is a second class citizen and even if gcc is supported at some point one needs a super recent gcc *and* rust toolchain to build a rust-enabeled kernel? I understand that this is right now not a big deal, but as soon a non-trival subsystem is rust-only people are forced to upgrade. Don't get me wrong, I'm all for having rust support in Linux. But I'm a bit worried about new dependencies on compiler toolchains. As someone who works a lot with long supported embedded systems I learned that as soon an application gains a hard dependency on clang or rust I'm in trouble. -- Thanks, //richard
Re: [PATCH -next] PCI: remove unused variable rdev
On 4/17/21 04:44, Bixuan Cui wrote: > Fix the build warning: > > drivers/pci/quirks.c: In function ‘quirk_amd_nvme_fixup’: > drivers/pci/quirks.c:312:18: warning: unused variable ‘rdev’ > [-Wunused-variable] > struct pci_dev *rdev; > ^~~~ > > Fixes: 9597624ef606 ('nvme: put some AMD PCIE downstream NVME device to > simple suspend/resume path') > Signed-off-by: Bixuan Cui Looks good. Reviewed-by: Chaitanya Kulkarni
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
On Sat, Apr 17, 2021 at 08:30:42PM +, Al Viro wrote: > and that thing is still there. However, it does *NOT* do what it might > appear to be doing; it ends up with getdents() returning -EINVAL instead. > What we need is > buf->error = -EINTR; > in addition to that return (in all 3 such places). Do you have any problems > with > the following delta? No, wait - we have non-NULL buf->prev_reclen, so we'll hit if (buf.prev_reclen) { struct compat_linux_dirent __user * lastdirent; lastdirent = (void __user *)buf.current_dir - buf.prev_reclen; if (put_user(buf.ctx.pos, &lastdirent->d_off)) error = -EFAULT; else error = count - buf.count; } with buf->error completely ignored. Nevermind.
Re: [PATCH] x86/uaccess: small optimization in unsafe_copy_to_user()
[tytso Cc'd] On Sat, Apr 17, 2021 at 06:09:44PM +, Al Viro wrote: > > Al - fairly trivial patch applied, comments? > > Should be fine... FWIW, I've a patch in the same area, making those suckers > return bool. Seeing that they are only ever called via dir_emit(), > dir_emit_dot() > and dir_emit_dotdot() and all of those return ->actor(...) == 0... > > Anyway, that'd be trivial to rebase on top of yours. Actually... looking through that patch now I've noticed something fishy: in 1f60fbe72749 ("ext4: allow readdir()'s of large empty directories to be interrupted" we had @@ -169,6 +169,8 @@ static int filldir(struct dir_context *ctx, const char *name, int namlen, } dirent = buf->previous; if (dirent) { + if (signal_pending(current)) + return -EINTR; and that thing is still there. However, it does *NOT* do what it might appear to be doing; it ends up with getdents() returning -EINVAL instead. What we need is buf->error = -EINTR; in addition to that return (in all 3 such places). Do you have any problems with the following delta? diff --git a/fs/readdir.c b/fs/readdir.c index 19434b3c982c..c742db935847 100644 --- a/fs/readdir.c +++ b/fs/readdir.c @@ -239,8 +239,10 @@ static int filldir(struct dir_context *ctx, const char *name, int namlen, return -EOVERFLOW; } prev_reclen = buf->prev_reclen; - if (prev_reclen && signal_pending(current)) + if (prev_reclen && signal_pending(current)) { + buf->error = -EINTR; return -EINTR; + } dirent = buf->current_dir; prev = (void __user *) dirent - prev_reclen; if (!user_write_access_begin(prev, reclen + prev_reclen)) @@ -321,8 +323,10 @@ static int filldir64(struct dir_context *ctx, const char *name, int namlen, if (reclen > buf->count) return -EINVAL; prev_reclen = buf->prev_reclen; - if (prev_reclen && signal_pending(current)) + if (prev_reclen && signal_pending(current)) { + buf->error = -EINTR; return -EINTR; + } dirent = buf->current_dir; prev = (void __user *)dirent - prev_reclen; if (!user_write_access_begin(prev, reclen + prev_reclen)) @@ -488,8 +492,10 @@ static int compat_filldir(struct dir_context *ctx, const char *name, int namlen, return -EOVERFLOW; } prev_reclen = buf->prev_reclen; - if (prev_reclen && signal_pending(current)) + if (prev_reclen && signal_pending(current)) { + buf->error = -EINTR; return -EINTR; + } dirent = buf->current_dir; prev = (void __user *) dirent - prev_reclen; if (!user_write_access_begin(prev, reclen + prev_reclen))
Re: [PATCH 1/2] mm: Fix struct page layout on 32-bit systems
On Sat, Apr 17, 2021 at 09:32:06PM +0300, Ilias Apalodimas wrote: > > +static inline void page_pool_set_dma_addr(struct page *page, dma_addr_t > > addr) > > +{ > > + page->dma_addr[0] = addr; > > + if (sizeof(dma_addr_t) > sizeof(unsigned long)) > > + page->dma_addr[1] = addr >> 16 >> 16; > > The 'error' that was reported will never trigger right? > I assume this was compiled with dma_addr_t as 32bits (so it triggered the > compilation error), but the if check will never allow this codepath to run. > If so can we add a comment explaining this, since none of us will remember why > in 6 months from now? That's right. I compiled it all three ways -- 32-bit, 64-bit dma, 32-bit long and 64-bit. The 32/64 bit case turn into: if (0) page->dma_addr[1] = addr >> 16 >> 16; which gets elided. So the only case that has to work is 64-bit dma and 32-bit long. I can replace this with upper_32_bits().
PPC_FPU, ALTIVEC: enable_kernel_fp, put_vr, get_vr
Hi, kernel test robot reports: >> drivers/cpufreq/pmac32-cpufreq.c:262:2: error: implicit declaration of >> function 'enable_kernel_fp' [-Werror,-Wimplicit-function-declaration] enable_kernel_fp(); ^ when # CONFIG_PPC_FPU is not set CONFIG_ALTIVEC=y I see at least one other place that does not handle that combination well, here: ../arch/powerpc/lib/sstep.c: In function 'do_vec_load': ../arch/powerpc/lib/sstep.c:637:3: error: implicit declaration of function 'put_vr' [-Werror=implicit-function-declaration] 637 | put_vr(rn, &u.v); | ^~ ../arch/powerpc/lib/sstep.c: In function 'do_vec_store': ../arch/powerpc/lib/sstep.c:660:3: error: implicit declaration of function 'get_vr'; did you mean 'get_oc'? [-Werror=implicit-function-declaration] 660 | get_vr(rn, &u.v); | ^~ Should the code + Kconfigs/Makefiles handle that kind of kernel config or should ALTIVEC always mean PPC_FPU as well? I have patches to fix the build errors with the config as reported but I don't know if that's the right thing to do... thanks. -- ~Randy
Re: [PATCH 3/3] i2c: mediatek: Use scl_int_delay_ns to compensate clock-stretching
On Sat, Apr 17, 2021 at 02:46:52PM +0800, Qii Wang wrote: > The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due > to device clock-stretch or circuit loss, we could get a suitable > scl_int_delay_ns from i2c_timings to compensate these parameters > to meet the spec via EXT_CONF register. > > Signed-off-by: Qii Wang Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH 2/3] i2c: mediatek: Fix wrong dma sync flag
On Sat, Apr 17, 2021 at 02:46:51PM +0800, Qii Wang wrote: > The right flag is apdma_sync when apdma remove hand-shake signel. > > Signed-off-by: Qii Wang Added: Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout") and applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH 1/3] i2c: mediatek: Fix send master code at more than 1MHz
On Sat, Apr 17, 2021 at 02:46:50PM +0800, Qii Wang wrote: > There are some omissions in the previous patch about replacing > I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and > need to fix it. > > Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz") > Signed-off-by: Qii Wang Applied to for-next, thanks! signature.asc Description: PGP signature
[PATCH] capabilities: require CAP_SETFCAP to map uid 0 (v3.2)
A process running as uid 0 but without cap_setfcap currently can simply unshare a new user namespace with uid 0 mapped to 0. While this task will not have new capabilities against the parent namespace, there is a loophole due to the way namespaced file capabilities work. File capabilities valid in userns 1 are distinguised from file capabilities valid in userns 2 by the kuid which underlies uid 0. Therefore the restricted root process can unshare a new self-mapping namespace, add a namespaced file capability onto a file, then use that file capability in the parent namespace. To prevent that, do not allow mapping uid 0 if the process which opened the uid_map file does not have CAP_SETFCAP, which is the capability for setting file capabilities. A further wrinkle: a task can unshare its user namespace, then open its uid_map file itself, and map (only) its own uid. In this case we do not have the credential from before unshare, which was potentially more restricted. So, when creating a user namespace, we record whether the creator had CAP_SETFCAP. Then we can use that during map_write(). With this patch: 1. unprivileged user can still unshare -Ur ubuntu@caps:~$ unshare -Ur root@caps:~# logout 2. root user can still unshare -Ur ubuntu@caps:~$ sudo bash root@caps:/home/ubuntu# unshare -Ur root@caps:/home/ubuntu# logout 3. root user without CAP_SETFCAP cannot unshare -Ur: root@caps:/home/ubuntu# /sbin/capsh --drop=cap_setfcap -- root@caps:/home/ubuntu# /sbin/setcap cap_setfcap=p /sbin/setcap unable to set CAP_SETFCAP effective capability: Operation not permitted root@caps:/home/ubuntu# unshare -Ur unshare: write failed /proc/self/uid_map: Operation not permitted Signed-off-by: Serge Hallyn Changelog: * fix logic in the case of writing to another task's uid_map * rename 'ns' to 'map_ns', and make a file_ns local variable * use /* comments */ * update the CAP_SETFCAP comment in capability.h * rename parent_unpriv to parent_can_setfcap (and reverse the logic) * remove printks * clarify (i hope) the code comments * update capability.h comment * renamed parent_can_setfcap to parent_could_setfcap * made the check its own disallowed_0_mapping() fn * moved the check into new_idmap_permitted * rename disallowed_0_mapping to verify_root_mapping * change verify_root_mapping to Christian's suggested flow --- include/linux/user_namespace.h | 3 ++ include/uapi/linux/capability.h | 3 +- kernel/user_namespace.c | 66 +++-- 3 files changed, 68 insertions(+), 4 deletions(-) diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h index 64cf8ebdc4ec..f6c5f784be5a 100644 --- a/include/linux/user_namespace.h +++ b/include/linux/user_namespace.h @@ -63,6 +63,9 @@ struct user_namespace { kgid_t group; struct ns_commonns; unsigned long flags; + /* parent_could_setfcap: true if the creator if this ns had CAP_SETFCAP +* in its effective capability set at the child ns creation time. */ + boolparent_could_setfcap; #ifdef CONFIG_KEYS /* List of joinable keyrings in this namespace. Modification access of diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h index c6ca33034147..2ddb4226cd23 100644 --- a/include/uapi/linux/capability.h +++ b/include/uapi/linux/capability.h @@ -335,7 +335,8 @@ struct vfs_ns_cap_data { #define CAP_AUDIT_CONTROL30 -/* Set or remove capabilities on files */ +/* Set or remove capabilities on files. + Map uid=0 into a child user namespace. */ #define CAP_SETFCAP 31 diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c index af612945a4d0..2ead291177b0 100644 --- a/kernel/user_namespace.c +++ b/kernel/user_namespace.c @@ -106,6 +106,7 @@ int create_user_ns(struct cred *new) if (!ns) goto fail_dec; + ns->parent_could_setfcap = cap_raised(new->cap_effective, CAP_SETFCAP); ret = ns_alloc_inum(&ns->ns); if (ret) goto fail_free; @@ -841,6 +842,61 @@ static int sort_idmaps(struct uid_gid_map *map) return 0; } +/** + * verify_root_map() - check the uid 0 mapping + * @file: idmapping file + * @map_ns: user namespace of the target process + * @new_map: requested idmap + * + * If a process requested a mapping for uid 0 onto uid 0, verify that the + * process writing the map had the CAP_SETFCAP capability as the target process + * will be able to write fscaps that are valid in ancestor user namespaces. + * + * Return: true if the mapping is allowed, false if not. + */ +static bool verify_root_map(const struct file *file, + struct user_namespace *map_ns, + struct uid_gid_map *new_map) +{ + int idx; + const struct user_namespace *file_ns = file->f_cred->user_ns; + struct uid_gid_extent *extent0 = NU