Re: [PATCH] hugetlb: remove unused hstate in hugetlb_fault_mutex_hash()
Hi Wei,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Wei-Yang/hugetlb-remove-unused-hstate-in-hugetlb_fault_mutex_hash/20191005-090034
config: x86_64-lkp (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:16:0,
from include/asm-generic/bug.h:19,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from mm/userfaultfd.c:8:
mm/userfaultfd.c: In function '__mcopy_atomic_hugetlb':
>> mm/userfaultfd.c:262:40: error: 'h' undeclared (first use in this function)
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
include/linux/build_bug.h:30:63: note: in definition of macro
'BUILD_BUG_ON_INVALID'
#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e
^
>> mm/userfaultfd.c:262:3: note: in expansion of macro 'VM_BUG_ON'
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
mm/userfaultfd.c:262:40: note: each undeclared identifier is reported only
once for each function it appears in
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
include/linux/build_bug.h:30:63: note: in definition of macro
'BUILD_BUG_ON_INVALID'
#define BUILD_BUG_ON_INVALID(e) ((void)(sizeof((__force long)(e
^
>> mm/userfaultfd.c:262:3: note: in expansion of macro 'VM_BUG_ON'
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
vim +/h +262 mm/userfaultfd.c
c1a4de99fada21 Andrea Arcangeli 2015-09-04 167
60d4d2d2b40e44 Mike Kravetz 2017-02-22 168 #ifdef CONFIG_HUGETLB_PAGE
60d4d2d2b40e44 Mike Kravetz 2017-02-22 169 /*
60d4d2d2b40e44 Mike Kravetz 2017-02-22 170 * __mcopy_atomic processing
for HUGETLB vmas. Note that this routine is
60d4d2d2b40e44 Mike Kravetz 2017-02-22 171 * called with mmap_sem held,
it will release mmap_sem before returning.
60d4d2d2b40e44 Mike Kravetz 2017-02-22 172 */
60d4d2d2b40e44 Mike Kravetz 2017-02-22 173 static __always_inline ssize_t
__mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 174
struct vm_area_struct *dst_vma,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 175
unsigned long dst_start,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 176
unsigned long src_start,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 177
unsigned long len,
60d4d2d2b40e44 Mike Kravetz 2017-02-22 178
bool zeropage)
60d4d2d2b40e44 Mike Kravetz 2017-02-22 179 {
1c9e8def43a345 Mike Kravetz 2017-02-22 180 int vm_alloc_shared =
dst_vma->vm_flags & VM_SHARED;
1c9e8def43a345 Mike Kravetz 2017-02-22 181 int vm_shared =
dst_vma->vm_flags & VM_SHARED;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 182 ssize_t err;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 183 pte_t *dst_pte;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 184 unsigned long src_addr,
dst_addr;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 185 long copied;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 186 struct page *page;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 187 unsigned long
vma_hpagesize;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 188 pgoff_t idx;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 189 u32 hash;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 190 struct address_space
*mapping;
60d4d2d2b40e44 Mike Kravetz 2017-02-22 191
60d4d2d2b40e44 Mike Kravetz 2017-02-22 192 /*
60d4d2d2b40e44 Mike Kravetz 2017-02-22 193 * There is no default
zero huge page for all huge page sizes as
60d4d2d2b40e44 Mike Kravetz 2017-02-22 194 * supported by
hugetlb. A PMD_SIZE huge pages may exist as used
60d4d2d2b40e44 Mike Kravetz 2017-02-22 195 *
Re: [PATCH] hugetlb: remove unused hstate in hugetlb_fault_mutex_hash()
Hi Wei,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Wei-Yang/hugetlb-remove-unused-hstate-in-hugetlb_fault_mutex_hash/20191005-090034
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/asm-generic/bug.h:5:0,
from arch/x86/include/asm/bug.h:83,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/mm.h:9,
from mm/userfaultfd.c:8:
mm/userfaultfd.c: In function '__mcopy_atomic_hugetlb':
mm/userfaultfd.c:262:40: error: 'h' undeclared (first use in this function)
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
>> include/linux/mmdebug.h:18:25: note: in expansion of macro 'BUG_ON'
#define VM_BUG_ON(cond) BUG_ON(cond)
^~
mm/userfaultfd.c:262:3: note: in expansion of macro 'VM_BUG_ON'
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
mm/userfaultfd.c:262:40: note: each undeclared identifier is reported only
once for each function it appears in
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
>> include/linux/mmdebug.h:18:25: note: in expansion of macro 'BUG_ON'
#define VM_BUG_ON(cond) BUG_ON(cond)
^~
mm/userfaultfd.c:262:3: note: in expansion of macro 'VM_BUG_ON'
VM_BUG_ON(dst_addr & ~huge_page_mask(h));
^
vim +/BUG_ON +18 include/linux/mmdebug.h
309381feaee564 Sasha Levin 2014-01-23 16
59ea746337c69f Jiri Slaby2008-06-12 17 #ifdef CONFIG_DEBUG_VM
59ea746337c69f Jiri Slaby2008-06-12 @18 #define VM_BUG_ON(cond)
BUG_ON(cond)
309381feaee564 Sasha Levin 2014-01-23 19 #define
VM_BUG_ON_PAGE(cond, page) \
e4f674229ce63d Dave Hansen 2014-06-04 20 do {
\
e4f674229ce63d Dave Hansen 2014-06-04 21 if
(unlikely(cond)) { \
e4f674229ce63d Dave Hansen 2014-06-04 22
dump_page(page, "VM_BUG_ON_PAGE(" __stringify(cond)")");\
e4f674229ce63d Dave Hansen 2014-06-04 23 BUG();
\
e4f674229ce63d Dave Hansen 2014-06-04 24 }
\
e4f674229ce63d Dave Hansen 2014-06-04 25 } while (0)
fa3759ccd5651c Sasha Levin 2014-10-09 26 #define
VM_BUG_ON_VMA(cond, vma) \
fa3759ccd5651c Sasha Levin 2014-10-09 27 do {
\
fa3759ccd5651c Sasha Levin 2014-10-09 28 if
(unlikely(cond)) { \
fa3759ccd5651c Sasha Levin 2014-10-09 29
dump_vma(vma); \
fa3759ccd5651c Sasha Levin 2014-10-09 30 BUG();
\
fa3759ccd5651c Sasha Levin 2014-10-09 31 }
\
fa3759ccd5651c Sasha Levin 2014-10-09 32 } while (0)
31c9afa6db122a Sasha Levin 2014-10-09 33 #define VM_BUG_ON_MM(cond,
mm) \
31c9afa6db122a Sasha Levin 2014-10-09 34 do {
\
31c9afa6db122a Sasha Levin 2014-10-09 35 if
(unlikely(cond)) { \
31c9afa6db122a Sasha Levin 2014-10-09 36
dump_mm(mm);\
31c9afa6db122a Sasha Levin 2014-10-09 37 BUG();
Re: [PATCH 3/3] net: phy: fixed_phy: switch to using fwnode_gpiod_get_index
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/net-phy-switch-to-using-fwnode_gpiod_get_index/20191005-083613
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=nds32
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers/net/phy/fixed_phy.c: In function 'fixed_phy_get_gpiod':
drivers/net/phy/fixed_phy.c:213:10: error: implicit declaration of function
'fwnode_gpiod_get_index'; did you mean 'devm_gpiod_get_index'?
[-Werror=implicit-function-declaration]
gpiod = fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
^~
devm_gpiod_get_index
>> drivers/net/phy/fixed_phy.c:213:8: warning: assignment to 'struct gpio_desc
>> *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
gpiod = fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
^
cc1: some warnings being treated as errors
vim +213 drivers/net/phy/fixed_phy.c
194
195 #ifdef CONFIG_OF_GPIO
196 static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
197 {
198 struct device_node *fixed_link_node;
199 struct gpio_desc *gpiod;
200
201 if (!np)
202 return NULL;
203
204 fixed_link_node = of_get_child_by_name(np, "fixed-link");
205 if (!fixed_link_node)
206 return NULL;
207
208 /*
209 * As the fixed link is just a device tree node without any
210 * Linux device associated with it, we simply have obtain
211 * the GPIO descriptor from the device tree like this.
212 */
> 213 gpiod =
> fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
214 "link-gpios", 0, GPIOD_IN,
"mdio");
215 if (IS_ERR(gpiod) && PTR_ERR(gpiod) != -EPROBE_DEFER) {
216 if (PTR_ERR(gpiod) != -ENOENT)
217 pr_err("error getting GPIO for fixed link %pOF,
proceed without\n",
218 fixed_link_node);
219 gpiod = NULL;
220 }
221 of_node_put(fixed_link_node);
222
223 return gpiod;
224 }
225 #else
226 static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
227 {
228 return NULL;
229 }
230 #endif
231
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 2/7] regulator: slg51000: switch to using fwnode_gpiod_get_index
Hi Dmitry,
I love your patch! Yet something to improve:
[auto build test ERROR on regulator/for-next]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/regulator-switch-to-using-devm_-fwnode_gpiod_get_index/20191005-085020
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
drivers/regulator/slg51000-regulator.c: In function 'slg51000_of_parse_cb':
>> drivers/regulator/slg51000-regulator.c:203:14: error: implicit declaration
>> of function 'fwnode_gpiod_get_index'; did you mean 'devm_gpiod_get_index'?
>> [-Werror=implicit-function-declaration]
ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), "enable", 0,
^~
devm_gpiod_get_index
>> drivers/regulator/slg51000-regulator.c:203:12: warning: assignment makes
>> pointer from integer without a cast [-Wint-conversion]
ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), "enable", 0,
^
cc1: some warnings being treated as errors
vim +203 drivers/regulator/slg51000-regulator.c
196
197 static int slg51000_of_parse_cb(struct device_node *np,
198 const struct regulator_desc *desc,
199 struct regulator_config *config)
200 {
201 struct gpio_desc *ena_gpiod;
202
> 203 ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np),
> "enable", 0,
204 GPIOD_OUT_LOW |
205
GPIOD_FLAGS_BIT_NONEXCLUSIVE,
206 "gpio-en-ldo");
207 if (!IS_ERR(ena_gpiod))
208 config->ena_gpiod = ena_gpiod;
209
210 return 0;
211 }
212
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/3] net: phylink: switch to using fwnode_gpiod_get_index()
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/net-phy-switch-to-using-fwnode_gpiod_get_index/20191005-083613
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=nds32
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers/net/phy/phylink.c: In function 'phylink_parse_fixedlink':
drivers/net/phy/phylink.c:171:11: error: implicit declaration of function
'fwnode_gpiod_get_index'; did you mean 'devm_gpiod_get_index'?
[-Werror=implicit-function-declaration]
desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
^~
devm_gpiod_get_index
>> drivers/net/phy/phylink.c:171:9: warning: assignment to 'struct gpio_desc *'
>> from 'int' makes pointer from integer without a cast [-Wint-conversion]
desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
^
cc1: some warnings being treated as errors
vim +171 drivers/net/phy/phylink.c
143
144 static int phylink_parse_fixedlink(struct phylink *pl,
145 struct fwnode_handle *fwnode)
146 {
147 struct fwnode_handle *fixed_node;
148 const struct phy_setting *s;
149 struct gpio_desc *desc;
150 u32 speed;
151 int ret;
152
153 fixed_node = fwnode_get_named_child_node(fwnode, "fixed-link");
154 if (fixed_node) {
155 ret = fwnode_property_read_u32(fixed_node, "speed",
);
156
157 pl->link_config.speed = speed;
158 pl->link_config.duplex = DUPLEX_HALF;
159
160 if (fwnode_property_read_bool(fixed_node,
"full-duplex"))
161 pl->link_config.duplex = DUPLEX_FULL;
162
163 /* We treat the "pause" and "asym-pause" terminology as
164 * defining the link partner's ability. */
165 if (fwnode_property_read_bool(fixed_node, "pause"))
166 pl->link_config.pause |= MLO_PAUSE_SYM;
167 if (fwnode_property_read_bool(fixed_node, "asym-pause"))
168 pl->link_config.pause |= MLO_PAUSE_ASYM;
169
170 if (ret == 0) {
> 171 desc = fwnode_gpiod_get_index(fixed_node,
> "link", 0,
172GPIOD_IN, "?");
173
174 if (!IS_ERR(desc))
175 pl->link_gpio = desc;
176 else if (desc == ERR_PTR(-EPROBE_DEFER))
177 ret = -EPROBE_DEFER;
178 }
179 fwnode_handle_put(fixed_node);
180
181 if (ret)
182 return ret;
183 } else {
184 u32 prop[5];
185
186 ret = fwnode_property_read_u32_array(fwnode,
"fixed-link",
187 NULL, 0);
188 if (ret != ARRAY_SIZE(prop)) {
189 phylink_err(pl, "broken fixed-link?\n");
190 return -EINVAL;
191 }
192
193 ret = fwnode_property_read_u32_array(fwnode,
"fixed-link",
194 prop,
ARRAY_SIZE(prop));
195 if (!ret) {
196 pl->link_config.duplex = prop[1] ?
197 DUPLEX_FULL :
DUPLEX_HALF;
198 pl->link_config.speed = prop[2];
199 if (prop[3])
200 pl->link_config.pause |= MLO_PAUSE_SYM;
201 if (prop[4])
202 pl->link_config.pause |= MLO_PAUSE_ASYM;
203 }
204 }
205
206 if (pl->
[PATCH] dma-mapping: fix false positivse warnings in dma_common_free_remap()
Commit 5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages
helper") changed invalid input check in dma_common_free_remap() from:
if (!area || !area->flags != VM_DMA_COHERENT)
to
if (!area || !area->flags != VM_DMA_COHERENT || !area->pages)
which seem to produce false positives for memory obtained via
dma_common_contiguous_remap()
This triggers the following warning message when doing "reboot" on ZII
VF610 Dev Board Rev B:
WARNING: CPU: 0 PID: 1 at kernel/dma/remap.c:112 dma_common_free_remap+0x88/0x8c
trying to free invalid coherent area: 9ef82980
Modules linked in:
CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.3.0-rc6-next-20190820 #119
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Backtrace:
[<8010d1ec>] (dump_backtrace) from [<8010d588>] (show_stack+0x20/0x24)
r7:8015ed78 r6:0009 r5: r4:9f4d9b14
[<8010d568>] (show_stack) from [<8077e3f0>] (dump_stack+0x24/0x28)
[<8077e3cc>] (dump_stack) from [<801197a0>] (__warn.part.3+0xcc/0xe4)
[<801196d4>] (__warn.part.3) from [<80119830>] (warn_slowpath_fmt+0x78/0x94)
r6:0070 r5:808e540c r4:81c03048
[<801197bc>] (warn_slowpath_fmt) from [<8015ed78>]
(dma_common_free_remap+0x88/0x8c)
r3:9ef82980 r2:808e53e0
r7:1000 r6:a0b1e000 r5:a0b1e000 r4:1000
[<8015ecf0>] (dma_common_free_remap) from [<8010fa9c>]
(remap_allocator_free+0x60/0x68)
r5:81c03048 r4:9f4d9b78
[<8010fa3c>] (remap_allocator_free) from [<801100d0>]
(__arm_dma_free.constprop.3+0xf8/0x148)
r5:81c03048 r4:9ef82900
[<8010ffd8>] (__arm_dma_free.constprop.3) from [<80110144>]
(arm_dma_free+0x24/0x2c)
r5:9f563410 r4:80110120
[<80110120>] (arm_dma_free) from [<8015d80c>] (dma_free_attrs+0xa0/0xdc)
[<8015d76c>] (dma_free_attrs) from [<8020f3e4>] (dma_pool_destroy+0xc0/0x154)
r8:9efa8860 r7:808f02f0 r6:808f02d0 r5:9ef82880 r4:9ef82780
[<8020f324>] (dma_pool_destroy) from [<805525d0>] (ehci_mem_cleanup+0x6c/0x150)
r7:9f563410 r6:9efa8810 r5: r4:9efd0148
[<80552564>] (ehci_mem_cleanup) from [<80558e0c>] (ehci_stop+0xac/0xc0)
r5:9efd0148 r4:9efd
[<80558d60>] (ehci_stop) from [<8053c4bc>] (usb_remove_hcd+0xf4/0x1b0)
r7:9f563410 r6:9efd0074 r5:81c03048 r4:9efd
[<8053c3c8>] (usb_remove_hcd) from [<8056361c>] (host_stop+0x48/0xb8)
r7:9f563410 r6:9efd r5:9f5f4040 r4:9f5f5040
[<805635d4>] (host_stop) from [<80563d0c>] (ci_hdrc_host_destroy+0x34/0x38)
r7:9f563410 r6:9f5f5040 r5:9efa8800 r4:9f5f4040
[<80563cd8>] (ci_hdrc_host_destroy) from [<8055ef18>]
(ci_hdrc_remove+0x50/0x10c)
[<8055eec8>] (ci_hdrc_remove) from [<804a2ed8>] (platform_drv_remove+0x34/0x4c)
r7:9f563410 r6:81c4f99c r5:9efa8810 r4:9efa8810
[<804a2ea4>] (platform_drv_remove) from [<804a18a8>]
(device_release_driver_internal+0xec/0x19c)
r5: r4:9efa8810
[<804a17bc>] (device_release_driver_internal) from [<804a1978>]
(device_release_driver+0x20/0x24)
r7:9f563410 r6:81c41ed0 r5:9efa8810 r4:9f4a1dac
[<804a1958>] (device_release_driver) from [<804a01b8>]
(bus_remove_device+0xdc/0x108)
[<804a00dc>] (bus_remove_device) from [<8049c204>] (device_del+0x150/0x36c)
r7:9f563410 r6:81c03048 r5:9efa8854 r4:9efa8810
[<8049c0b4>] (device_del) from [<804a3368>]
(platform_device_del.part.2+0x20/0x84)
r10:9f563414 r9:809177e0 r8:81cb07dc r7:81c78320 r6:9f563454 r5:9efa8800
r4:9efa8800
[<804a3348>] (platform_device_del.part.2) from [<804a3420>]
(platform_device_unregister+0x28/0x34)
r5:9f563400 r4:9efa8800
[<804a33f8>] (platform_device_unregister) from [<8055dce0>]
(ci_hdrc_remove_device+0x1c/0x30)
r5:9f563400 r4:0001
[<8055dcc4>] (ci_hdrc_remove_device) from [<805652ac>]
(ci_hdrc_imx_remove+0x38/0x118)
r7:81c78320 r6:9f563454 r5:9f563410 r4:9f541010
[<8056538c>] (ci_hdrc_imx_shutdown) from [<804a2970>]
(platform_drv_shutdown+0x2c/0x30)
[<804a2944>] (platform_drv_shutdown) from [<8049e4fc>]
(device_shutdown+0x158/0x1f0)
[<8049e3a4>] (device_shutdown) from [<8013ac80>]
(kernel_restart_prepare+0x44/0x48)
r10:0058 r9:9f4d8000 r8:fee1dead r7:379ce700 r6:81c0b280 r5:81c03048
r4:
[<8013ac3c>] (kernel_restart_prepare) from [<8013ad14>]
(kernel_restart+0x1c/0x60)
[<8013acf8>] (kernel_restart) from [<8013af84>] (__do_sys_reboot+0xe0/0x1d8)
r5:81c03048 r4:
[<8013aea4>] (__do_sys_reboot) from [<8013b0ec>] (sys_reboot+0x18/0x1c)
r8:80101204 r7:0058 r6: r5: r4:
[<8013b0d4>] (sys_reboot) from [<80101000>] (ret_fast_syscall+0x0/0x54)
Exception stack(0x9f4d9fa8 to 0x9f4d9ff0)
9fa0: fee1dead 28121969 01234567 379ce700
9fc0: 0058 00016d04
9fe0: 00028e0c 7ec87c64 000135ec 76c1f410
Restore original invalid input check in dma_common_free_remap() to
avoid this problem.
Fixes: 5cf4537975bb ("dma-mapping: introduce a dma_common_find_pages helper")
Signed-off-by: Andrey Smirnov
Cc: Andrew Lunn
Cc: Vivien Didelot
Cc: Chris Healy
Cc: Geert Uytterhoeven
Cc: Christoph Hellwig
Cc: Robin Murphy
Cc: linux-kernel@vger.kernel.org
[PATCH] uverbs: prevent potential underflow
The issue is in drivers/infiniband/core/uverbs_std_types_cq.c in the
UVERBS_HANDLER(UVERBS_METHOD_CQ_CREATE) function. We check that:
if (attr.comp_vector >= attrs->ufile->device->num_comp_vectors) {
But we don't check that "attr.comp_vector" whether negative. It
could potentially lead to an array underflow. My concern would be where
cq->vector is used in the create_cq() function from the cxgb4 driver.
Fixes: 9ee79fce3642 ("IB/core: Add completion queue (cq) object actions")
Signed-off-by: Dan Carpenter
---
drivers/infiniband/core/uverbs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/core/uverbs.h b/drivers/infiniband/core/uverbs.h
index 1e5aeb39f774..63f7f7db5902 100644
--- a/drivers/infiniband/core/uverbs.h
+++ b/drivers/infiniband/core/uverbs.h
@@ -98,7 +98,7 @@ ib_uverbs_init_udata_buf_or_null(struct ib_udata *udata,
struct ib_uverbs_device {
atomic_trefcount;
- int num_comp_vectors;
+ u32 num_comp_vectors;
struct completion comp;
struct device dev;
/* First group for device attributes, NULL terminated array */
--
2.20.1
Re: [PATCH 3/3] net: phy: fixed_phy: switch to using fwnode_gpiod_get_index
Hi Dmitry,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/net-phy-switch-to-using-fwnode_gpiod_get_index/20191005-083613
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
drivers/net/phy/fixed_phy.c: In function 'fixed_phy_get_gpiod':
>> drivers/net/phy/fixed_phy.c:213:10: error: implicit declaration of function
>> 'fwnode_gpiod_get_index'; did you mean 'devm_gpiod_get_index'?
>> [-Werror=implicit-function-declaration]
gpiod = fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
^~
devm_gpiod_get_index
>> drivers/net/phy/fixed_phy.c:213:8: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
gpiod = fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
^
cc1: some warnings being treated as errors
vim +213 drivers/net/phy/fixed_phy.c
194
195 #ifdef CONFIG_OF_GPIO
196 static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
197 {
198 struct device_node *fixed_link_node;
199 struct gpio_desc *gpiod;
200
201 if (!np)
202 return NULL;
203
204 fixed_link_node = of_get_child_by_name(np, "fixed-link");
205 if (!fixed_link_node)
206 return NULL;
207
208 /*
209 * As the fixed link is just a device tree node without any
210 * Linux device associated with it, we simply have obtain
211 * the GPIO descriptor from the device tree like this.
212 */
> 213 gpiod =
> fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
214 "link-gpios", 0, GPIOD_IN,
"mdio");
215 if (IS_ERR(gpiod) && PTR_ERR(gpiod) != -EPROBE_DEFER) {
216 if (PTR_ERR(gpiod) != -ENOENT)
217 pr_err("error getting GPIO for fixed link %pOF,
proceed without\n",
218 fixed_link_node);
219 gpiod = NULL;
220 }
221 of_node_put(fixed_link_node);
222
223 return gpiod;
224 }
225 #else
226 static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
227 {
228 return NULL;
229 }
230 #endif
231
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/3] net: phylink: switch to using fwnode_gpiod_get_index()
Hi Dmitry,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/net-phy-switch-to-using-fwnode_gpiod_get_index/20191005-083613
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
drivers/net/phy/phylink.c: In function 'phylink_parse_fixedlink':
>> drivers/net/phy/phylink.c:171:11: error: implicit declaration of function
>> 'fwnode_gpiod_get_index'; did you mean 'devm_gpiod_get_index'?
>> [-Werror=implicit-function-declaration]
desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
^~
devm_gpiod_get_index
>> drivers/net/phy/phylink.c:171:9: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
^
cc1: some warnings being treated as errors
vim +171 drivers/net/phy/phylink.c
143
144 static int phylink_parse_fixedlink(struct phylink *pl,
145 struct fwnode_handle *fwnode)
146 {
147 struct fwnode_handle *fixed_node;
148 const struct phy_setting *s;
149 struct gpio_desc *desc;
150 u32 speed;
151 int ret;
152
153 fixed_node = fwnode_get_named_child_node(fwnode, "fixed-link");
154 if (fixed_node) {
155 ret = fwnode_property_read_u32(fixed_node, "speed",
);
156
157 pl->link_config.speed = speed;
158 pl->link_config.duplex = DUPLEX_HALF;
159
160 if (fwnode_property_read_bool(fixed_node,
"full-duplex"))
161 pl->link_config.duplex = DUPLEX_FULL;
162
163 /* We treat the "pause" and "asym-pause" terminology as
164 * defining the link partner's ability. */
165 if (fwnode_property_read_bool(fixed_node, "pause"))
166 pl->link_config.pause |= MLO_PAUSE_SYM;
167 if (fwnode_property_read_bool(fixed_node, "asym-pause"))
168 pl->link_config.pause |= MLO_PAUSE_ASYM;
169
170 if (ret == 0) {
> 171 desc = fwnode_gpiod_get_index(fixed_node,
> "link", 0,
172GPIOD_IN, "?");
173
174 if (!IS_ERR(desc))
175 pl->link_gpio = desc;
176 else if (desc == ERR_PTR(-EPROBE_DEFER))
177 ret = -EPROBE_DEFER;
178 }
179 fwnode_handle_put(fixed_node);
180
181 if (ret)
182 return ret;
183 } else {
184 u32 prop[5];
185
186 ret = fwnode_property_read_u32_array(fwnode,
"fixed-link",
187 NULL, 0);
188 if (ret != ARRAY_SIZE(prop)) {
189 phylink_err(pl, "broken fixed-link?\n");
190 return -EINVAL;
191 }
192
193 ret = fwnode_property_read_u32_array(fwnode,
"fixed-link",
194 prop,
ARRAY_SIZE(prop));
195 if (!ret) {
196 pl->link_config.duplex = prop[1] ?
197 DUPLEX_FULL :
DUPLEX_HALF;
198 pl->link_config.speed = prop[2];
199 if (prop[3])
200 pl->link_config.pause |= MLO_PAUSE_SYM;
201 if (prop[4])
202 pl->link_config.pause |= MLO_PAUSE_ASYM;
203 }
204 }
205
206 if (pl->link_config.sp
[GIT PULL] SCSI fixes for 5.4-rc1
Twelve patches mostly small but obvious fixes or cosmetic but small
updates, all in drivers.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Austin Kim (1):
scsi: qedf: Remove always false 'tmp_prio < 0' statement
Himanshu Madhani (1):
scsi: qla2xxx: Silence fwdump template message
Laurence Oberman (1):
scsi: bnx2fc: Handle scope bits when array returns BUSY or TSF
Long Li (1):
scsi: storvsc: setup 1:1 mapping between hardware queue and CPU queue
Quinn Tran (6):
scsi: qla2xxx: Fix Nport ID display value
scsi: qla2xxx: Fix N2N link up fail
scsi: qla2xxx: Fix N2N link reset
scsi: qla2xxx: Optimize NPIV tear down process
scsi: qla2xxx: Fix stale mem access on driver unload
scsi: qla2xxx: Fix unbound sleep in fcport delete path.
Stanley Chu (1):
scsi: ufs: skip shutdown if hba is not powered
Xiang Chen (1):
scsi: megaraid: disable device when probe failed after enabled device
YueHaibing (1):
scsi: hisi_sas: Make three functions static
And the diffstat:
drivers/scsi/bnx2fc/bnx2fc_io.c | 29 +++--
drivers/scsi/hisi_sas/hisi_sas_main.c | 6 +-
drivers/scsi/megaraid.c | 4 +-
drivers/scsi/qedf/qedf_main.c | 2 +-
drivers/scsi/qla2xxx/qla_attr.c | 2 +
drivers/scsi/qla2xxx/qla_def.h| 4 +-
drivers/scsi/qla2xxx/qla_gs.c | 3 +-
drivers/scsi/qla2xxx/qla_init.c | 109 --
drivers/scsi/qla2xxx/qla_iocb.c | 7 ++-
drivers/scsi/qla2xxx/qla_mbx.c| 25 +++-
drivers/scsi/qla2xxx/qla_mid.c| 32 ++
drivers/scsi/qla2xxx/qla_os.c | 18 --
drivers/scsi/qla2xxx/qla_target.c | 26
drivers/scsi/storvsc_drv.c| 3 +-
drivers/scsi/ufs/ufshcd.c | 3 +
15 files changed, 193 insertions(+), 80 deletions(-)
With full diff below.
James
---
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index da00ca5fa5dc..401743e2b429 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -1923,6 +1923,7 @@ void bnx2fc_process_scsi_cmd_compl(struct bnx2fc_cmd
*io_req,
struct fcoe_fcp_rsp_payload *fcp_rsp;
struct bnx2fc_rport *tgt = io_req->tgt;
struct scsi_cmnd *sc_cmd;
+ u16 scope = 0, qualifier = 0;
/* scsi_cmd_cmpl is called with tgt lock held */
@@ -1990,12 +1991,30 @@ void bnx2fc_process_scsi_cmd_compl(struct bnx2fc_cmd
*io_req,
if (io_req->cdb_status == SAM_STAT_TASK_SET_FULL ||
io_req->cdb_status == SAM_STAT_BUSY) {
- /* Set the jiffies + retry_delay_timer * 100ms
- for the rport/tgt */
- tgt->retry_delay_timestamp = jiffies +
- fcp_rsp->retry_delay_timer * HZ / 10;
+ /* Newer array firmware with BUSY or
+* TASK_SET_FULL may return a status that needs
+* the scope bits masked.
+* Or a huge delay timestamp up to 27 minutes
+* can result.
+*/
+ if (fcp_rsp->retry_delay_timer) {
+ /* Upper 2 bits */
+ scope = fcp_rsp->retry_delay_timer
+ & 0xC000;
+ /* Lower 14 bits */
+ qualifier = fcp_rsp->retry_delay_timer
+ & 0x3FFF;
+ }
+ if (scope > 0 && qualifier > 0 &&
+ qualifier <= 0x3FEF) {
+ /* Set the jiffies +
+* retry_delay_timer * 100ms
+* for the rport/tgt
+*/
+ tgt->retry_delay_timestamp = jiffies +
+ (qualifier * HZ / 10);
+ }
}
-
}
if (io_req->fcp_resid)
scsi_set_resid(sc_cmd, io_req->fcp_resid);
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index d1513fdf1e00..0847e682797b 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -3683,7 +3683,7 @@ void hisi_sas_debugfs_work_handler(struct work_struct
*work)
}
EXPORT_SYMBOL_GPL(hisi_sas_debugfs_work_handler);
-void hisi_sas_debugfs_release(struct hisi_hba
Re: [PATCH V1] dt-bindings: pinctrl: qcom-pmic-gpio: Add support for pm6150/pm6150l
On Fri 04 Oct 04:20 PDT 2019, Kiran Gunda wrote:
> Add support for the PM6150 and PM6150L GPIO support to the
> Qualcomm PMIC GPIO binding.
>
> Signed-off-by: Kiran Gunda
Acked-by: Bjorn Andersson
> ---
> Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 4
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
> b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
> index c32bf32..2f48cca 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt
> @@ -23,6 +23,8 @@ PMIC's from Qualcomm.
> "qcom,pms405-gpio"
> "qcom,pm8150-gpio"
> "qcom,pm8150b-gpio"
> + "qcom,pm6150-gpio"
> + "qcom,pm6150l-gpio"
>
> And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio"
> if the device is on an spmi bus or an ssbi bus respectively
> @@ -100,6 +102,8 @@ to specify in a pin configuration subnode:
>and gpio8)
> gpio1-gpio12 for pm8150b (holes on gpio3, gpio4, gpio7)
> gpio1-gpio12 for pm8150l (hole on gpio7)
> + gpio1-gpio10 for pm6150
> + gpio1-gpio12 for pm6150l
>
> - function:
> Usage: required
> diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> index f1fece5..387917c 100644
> --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
> @@ -1121,6 +1121,8 @@ static int pmic_gpio_remove(struct platform_device
> *pdev)
> { .compatible = "qcom,pm8150b-gpio", .data = (void *) 12 },
> /* pm8150l has 12 GPIOs with holes on 7 */
> { .compatible = "qcom,pm8150l-gpio", .data = (void *) 12 },
> + { .compatible = "qcom,pm6150-gpio", .data = (void *) 10 },
> + { .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
> { },
> };
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: KCSAN: data-race in taskstats_exit / taskstats_exit
On Sat, Oct 5, 2019 at 6:26 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:b4bd9343 x86, kcsan: Enable KCSAN for x86 > git tree: https://github.com/google/ktsan.git kcsan > console output: https://syzkaller.appspot.com/x/log.txt?x=125329db60 > kernel config: https://syzkaller.appspot.com/x/.config?x=c0906aa620713d80 > dashboard link: https://syzkaller.appspot.com/bug?extid=c5d03165a1bd1dead0c1 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+c5d03165a1bd1dead...@syzkaller.appspotmail.com +Christian, you wanted races in process mgmt ;) > == > BUG: KCSAN: data-race in taskstats_exit / taskstats_exit > > write to 0x8881157bbe10 of 8 bytes by task 7951 on cpu 0: > taskstats_tgid_alloc kernel/taskstats.c:567 [inline] > taskstats_exit+0x6b7/0x717 kernel/taskstats.c:596 > do_exit+0x2c2/0x18e0 kernel/exit.c:864 > do_group_exit+0xb4/0x1c0 kernel/exit.c:983 > get_signal+0x2a2/0x1320 kernel/signal.c:2734 > do_signal+0x3b/0xc00 arch/x86/kernel/signal.c:815 > exit_to_usermode_loop+0x250/0x2c0 arch/x86/entry/common.c:159 > prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] > syscall_return_slowpath arch/x86/entry/common.c:274 [inline] > do_syscall_64+0x2d7/0x2f0 arch/x86/entry/common.c:299 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > read to 0x8881157bbe10 of 8 bytes by task 7949 on cpu 1: > taskstats_tgid_alloc kernel/taskstats.c:559 [inline] > taskstats_exit+0xb2/0x717 kernel/taskstats.c:596 > do_exit+0x2c2/0x18e0 kernel/exit.c:864 > do_group_exit+0xb4/0x1c0 kernel/exit.c:983 > __do_sys_exit_group kernel/exit.c:994 [inline] > __se_sys_exit_group kernel/exit.c:992 [inline] > __x64_sys_exit_group+0x2e/0x30 kernel/exit.c:992 > do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 1 PID: 7949 Comm: syz-executor.3 Not tainted 5.3.0+ #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > == > Kernel panic - not syncing: panic_on_warn set ... > CPU: 1 PID: 7949 Comm: syz-executor.3 Not tainted 5.3.0+ #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0xf5/0x159 lib/dump_stack.c:113 > panic+0x209/0x639 kernel/panic.c:219 > end_report kernel/kcsan/report.c:135 [inline] > kcsan_report.cold+0x57/0xeb kernel/kcsan/report.c:283 > __kcsan_setup_watchpoint+0x342/0x500 kernel/kcsan/core.c:456 > __tsan_read8 kernel/kcsan/kcsan.c:31 [inline] > __tsan_read8+0x2c/0x30 kernel/kcsan/kcsan.c:31 > taskstats_tgid_alloc kernel/taskstats.c:559 [inline] > taskstats_exit+0xb2/0x717 kernel/taskstats.c:596 > do_exit+0x2c2/0x18e0 kernel/exit.c:864 > do_group_exit+0xb4/0x1c0 kernel/exit.c:983 > __do_sys_exit_group kernel/exit.c:994 [inline] > __se_sys_exit_group kernel/exit.c:992 [inline] > __x64_sys_exit_group+0x2e/0x30 kernel/exit.c:992 > do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x459a59 > Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7ffc4ccf3408 EFLAGS: 0246 ORIG_RAX: 00e7 > RAX: ffda RBX: 001e RCX: 00459a59 > RDX: 00413741 RSI: fff7 RDI: > RBP: R08: 7f8e4506 R09: 7ffc4ccf3460 > R10: 81007108 R11: 0246 R12: > R13: 7ffc4ccf3460 R14: R15: 7ffc4ccf3470 > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/9b403005942237bf%40google.com.
KCSAN: data-race in taskstats_exit / taskstats_exit
Hello, syzbot found the following crash on: HEAD commit:b4bd9343 x86, kcsan: Enable KCSAN for x86 git tree: https://github.com/google/ktsan.git kcsan console output: https://syzkaller.appspot.com/x/log.txt?x=125329db60 kernel config: https://syzkaller.appspot.com/x/.config?x=c0906aa620713d80 dashboard link: https://syzkaller.appspot.com/bug?extid=c5d03165a1bd1dead0c1 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c5d03165a1bd1dead...@syzkaller.appspotmail.com == BUG: KCSAN: data-race in taskstats_exit / taskstats_exit write to 0x8881157bbe10 of 8 bytes by task 7951 on cpu 0: taskstats_tgid_alloc kernel/taskstats.c:567 [inline] taskstats_exit+0x6b7/0x717 kernel/taskstats.c:596 do_exit+0x2c2/0x18e0 kernel/exit.c:864 do_group_exit+0xb4/0x1c0 kernel/exit.c:983 get_signal+0x2a2/0x1320 kernel/signal.c:2734 do_signal+0x3b/0xc00 arch/x86/kernel/signal.c:815 exit_to_usermode_loop+0x250/0x2c0 arch/x86/entry/common.c:159 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x2d7/0x2f0 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0x8881157bbe10 of 8 bytes by task 7949 on cpu 1: taskstats_tgid_alloc kernel/taskstats.c:559 [inline] taskstats_exit+0xb2/0x717 kernel/taskstats.c:596 do_exit+0x2c2/0x18e0 kernel/exit.c:864 do_group_exit+0xb4/0x1c0 kernel/exit.c:983 __do_sys_exit_group kernel/exit.c:994 [inline] __se_sys_exit_group kernel/exit.c:992 [inline] __x64_sys_exit_group+0x2e/0x30 kernel/exit.c:992 do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7949 Comm: syz-executor.3 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 == Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 7949 Comm: syz-executor.3 Not tainted 5.3.0+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xf5/0x159 lib/dump_stack.c:113 panic+0x209/0x639 kernel/panic.c:219 end_report kernel/kcsan/report.c:135 [inline] kcsan_report.cold+0x57/0xeb kernel/kcsan/report.c:283 __kcsan_setup_watchpoint+0x342/0x500 kernel/kcsan/core.c:456 __tsan_read8 kernel/kcsan/kcsan.c:31 [inline] __tsan_read8+0x2c/0x30 kernel/kcsan/kcsan.c:31 taskstats_tgid_alloc kernel/taskstats.c:559 [inline] taskstats_exit+0xb2/0x717 kernel/taskstats.c:596 do_exit+0x2c2/0x18e0 kernel/exit.c:864 do_group_exit+0xb4/0x1c0 kernel/exit.c:983 __do_sys_exit_group kernel/exit.c:994 [inline] __se_sys_exit_group kernel/exit.c:992 [inline] __x64_sys_exit_group+0x2e/0x30 kernel/exit.c:992 do_syscall_64+0xcf/0x2f0 arch/x86/entry/common.c:296 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x459a59 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffc4ccf3408 EFLAGS: 0246 ORIG_RAX: 00e7 RAX: ffda RBX: 001e RCX: 00459a59 RDX: 00413741 RSI: fff7 RDI: RBP: R08: 7f8e4506 R09: 7ffc4ccf3460 R10: 81007108 R11: 0246 R12: R13: 7ffc4ccf3460 R14: R15: 7ffc4ccf3470 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
Re: Kernel Concurrency Sanitizer (KCSAN)
On Sat, Oct 5, 2019 at 2:58 AM Eric Dumazet wrote:
> > This one is tricky. What I think we need to avoid is an onslaught of
> > patches adding READ_ONCE/WRITE_ONCE without a concrete analysis of the
> > code being modified. My worry is that Joe Developer is eager to get their
> > first patch into the kernel, so runs this tool and starts spamming
> > maintainers with these things to the point that they start ignoring KCSAN
> > reports altogether because of the time they take up.
> >
> > I suppose one thing we could do is to require each new READ_ONCE/WRITE_ONCE
> > to have a comment describing the racy access, a bit like we do for memory
> > barriers. Another possibility would be to use atomic_t more widely if
> > there is genuine concurrency involved.
> >
>
> About READ_ONCE() and WRITE_ONCE(), we will probably need
>
> ADD_ONCE(var, value) for arches that can implement the RMW in a single
> instruction.
>
> WRITE_ONCE(var, var + value) does not look pretty, and increases register
> pressure.
FWIW modern compilers can handle this if we tell them what we are trying to do:
void foo(int *p, int x)
{
x += __atomic_load_n(p, __ATOMIC_RELAXED);
__atomic_store_n(p, x, __ATOMIC_RELAXED);
}
$ clang test.c -c -O2 && objdump -d test.o
:
0: 01 37add%esi,(%rdi)
2: c3retq
We can have syntactic sugar on top of this of course.
Re: [PATCH] remoteproc: debug: Remove unneeded NULL check
On Mon 23 Sep 19:58 PDT 2019, Ding Xiang wrote:
> debugfs_remove_recursive will do NULL check, so remove
> the redundant null check
>
Nice, applied.
Regards,
Bjorn
> Signed-off-by: Ding Xiang
> ---
> drivers/remoteproc/remoteproc_debugfs.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
> b/drivers/remoteproc/remoteproc_debugfs.c
> index 8cd4a0a..dd93cf0 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -333,9 +333,6 @@ struct dentry *rproc_create_trace_file(const char *name,
> struct rproc *rproc,
>
> void rproc_delete_debug_dir(struct rproc *rproc)
> {
> - if (!rproc->dbg_dir)
> - return;
> -
> debugfs_remove_recursive(rproc->dbg_dir);
> }
>
> --
> 1.9.1
>
>
>
Re: [PATCH 4/4] hwspinlock: sprd: Use devm_hwspin_lock_register() to register hwlock controller
On Fri 27 Sep 00:10 PDT 2019, Baolin Wang wrote:
> Use devm_hwspin_lock_register() to register the hwlock controller instead of
> unregistering the hwlock controller explicitly when removing the device.
>
> Signed-off-by: Baolin Wang
Thanks Baolin, series applied.
Regards,
Bjorn
> ---
> drivers/hwspinlock/sprd_hwspinlock.c |8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hwspinlock/sprd_hwspinlock.c
> b/drivers/hwspinlock/sprd_hwspinlock.c
> index e76c702..44d69db 100644
> --- a/drivers/hwspinlock/sprd_hwspinlock.c
> +++ b/drivers/hwspinlock/sprd_hwspinlock.c
> @@ -135,8 +135,9 @@ static int sprd_hwspinlock_probe(struct platform_device
> *pdev)
> platform_set_drvdata(pdev, sprd_hwlock);
> pm_runtime_enable(>dev);
>
> - ret = hwspin_lock_register(_hwlock->bank, >dev,
> -_hwspinlock_ops, 0, SPRD_HWLOCKS_NUM);
> + ret = devm_hwspin_lock_register(>dev, _hwlock->bank,
> + _hwspinlock_ops, 0,
> + SPRD_HWLOCKS_NUM);
> if (ret) {
> pm_runtime_disable(>dev);
> return ret;
> @@ -147,9 +148,6 @@ static int sprd_hwspinlock_probe(struct platform_device
> *pdev)
>
> static int sprd_hwspinlock_remove(struct platform_device *pdev)
> {
> - struct sprd_hwspinlock_dev *sprd_hwlock = platform_get_drvdata(pdev);
> -
> - hwspin_lock_unregister(_hwlock->bank);
> pm_runtime_disable(>dev);
> return 0;
> }
> --
> 1.7.9.5
>
Re: [PATCH] remoteproc: remove useless typedef
On Fri 04 Oct 10:44 PDT 2019, Clement Leger wrote: > rproc_handle_resources_t is not used anymore, remove it. > > Signed-off-by: Clement Leger Applied Thanks, Bjorn > --- > drivers/remoteproc/remoteproc_core.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > index 48feebd6d0a2..78e00194e72f 100644 > --- a/drivers/remoteproc/remoteproc_core.c > +++ b/drivers/remoteproc/remoteproc_core.c > @@ -52,8 +52,6 @@ > static DEFINE_MUTEX(rproc_list_mutex); > static LIST_HEAD(rproc_list); > > -typedef int (*rproc_handle_resources_t)(struct rproc *rproc, > - struct resource_table *table, int len); > typedef int (*rproc_handle_resource_t)(struct rproc *rproc, >void *, int offset, int avail); > > -- > 2.15.0.276.g89ea799 >
Re: [PATCH] remoteproc: stm32: fix probe error case
On Fri 04 Oct 05:02 PDT 2019, Fabien Dessenne wrote:
> If the rproc driver is probed before the mailbox driver and if the rproc
> Device Tree node has some mailbox properties, the rproc driver probe
> shall be deferred instead of being probed without mailbox support.
>
> Signed-off-by: Fabien Dessenne
> ---
> drivers/remoteproc/stm32_rproc.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/stm32_rproc.c
> b/drivers/remoteproc/stm32_rproc.c
> index 2cf4b29..410b794 100644
> --- a/drivers/remoteproc/stm32_rproc.c
> +++ b/drivers/remoteproc/stm32_rproc.c
> @@ -310,7 +310,7 @@ static const struct stm32_mbox
> stm32_rproc_mbox[MBOX_NB_MBX] = {
> }
> };
>
> -static void stm32_rproc_request_mbox(struct rproc *rproc)
> +static int stm32_rproc_request_mbox(struct rproc *rproc)
> {
> struct stm32_rproc *ddata = rproc->priv;
> struct device *dev = >dev;
> @@ -328,11 +328,15 @@ static void stm32_rproc_request_mbox(struct rproc
> *rproc)
> cl->dev = dev->parent;
>
> ddata->mb[i].chan = mbox_request_channel_byname(cl, name);
> - if (IS_ERR(ddata->mb[i].chan)) {
> + if (PTR_ERR(ddata->mb[i].chan) == -EPROBE_DEFER) {
You may not use PTR_ERR() without first checking IS_ERR(), apart from
that your patch looks good.
Regards,
Bjorn
> + return -EPROBE_DEFER;
> + } else if (IS_ERR(ddata->mb[i].chan)) {
> dev_warn(dev, "cannot get %s mbox\n", name);
> ddata->mb[i].chan = NULL;
> }
> }
> +
> + return 0;
> }
>
> static int stm32_rproc_set_hold_boot(struct rproc *rproc, bool hold)
> @@ -596,7 +600,9 @@ static int stm32_rproc_probe(struct platform_device *pdev)
> if (ret)
> goto free_rproc;
>
> - stm32_rproc_request_mbox(rproc);
> + ret = stm32_rproc_request_mbox(rproc);
> + if (ret)
> + goto free_rproc;
>
> ret = rproc_add(rproc);
> if (ret)
> --
> 2.7.4
>
Re: [PATCH 0/3] Optimize the u8500_hsem hwlock driver
On Fri 27 Sep 01:27 PDT 2019, Baolin Wang wrote: > This patch set did some Optimization with changing to use devm_xxx() > APIs to simplify the code and make code more readable. > Applied, with Linus' r-b Thanks, Bjorn > Baolin Wang (3): > hwspinlock: u8500_hsem: Change to use > devm_platform_ioremap_resource() > hwspinlock: u8500_hsem: Use devm_kzalloc() to allocate memory > hwspinlock: u8500_hsem: Use devm_hwspin_lock_register() to register > hwlock controller > > drivers/hwspinlock/u8500_hsem.c | 46 > +++ > 1 file changed, 13 insertions(+), 33 deletions(-) > > -- > 1.7.9.5 >
Re: DM3730 Bluetooth Performance differences between SERIAL_8250_OMAP vs SERIAL_OMAP
On Fri, Oct 4, 2019 at 11:51 AM Adam Ford wrote:
>
> On Fri, Oct 4, 2019 at 9:08 AM Adam Ford wrote:
> >
> > On Fri, Oct 4, 2019 at 7:27 AM Yegor Yefremov
> > wrote:
> > >
> > > Hi Adam,
> > >
> > > On Fri, Oct 4, 2019 at 12:39 PM Adam Ford wrote:
> > > >
> > > > On Fri, Oct 4, 2019 at 5:02 AM Adam Ford wrote:
> > > > >
> > > > > I am running Kernel 5.3.2 trying to troubleshoot some intermittent
> > > > > Bluetooth issues, and I think I have narrowed it down to the serial
> > > > > driver in use.
> > > >
> > > > I should have also noted that it's using UART2 with CTS and RTS on the
> > > > DM3730 (omap3630) and its configured with a baud rate of 3M.
> > > > I tried slowing it to 115200, but that didn't help. I tried disabling
> > > > the DMA hooks from the device tree, and that didn't help.
> > > >
> > > > > By default, omap2plus_defconfig enables both SERIAL_8250_OMAP and
> > > > > SERIAL_OMAP. I have my console device configured as ttyS0, and all
> > > > > appears fine. When I enable Bluetooth, however, I get intermittent
> > > > > errors on an DM3730 / OMAP3630.
> > > > >
> > > > > Using the 8250 driver for Blueotooth I get intermittent frame errors
> > > > > and data loss.
> > > > >
> > > > > Scanning ...
> > > > > [ 28.482452] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > [ 36.162170] Bluetooth: hci0: Frame reassembly failed (-84)
> > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 8.27ms
> > > > > no response from F4:4E:FC:C9:2F:57: id 1
> > > > > ^C2 sent, 1 received, 50% loss
> > > > >
> > > > > (after a fairly long hang, I hit control-c)
> > > > >
> > > > > However, disabling the 8250 driver and using the only SERIAL_OMAP and
> > > > > the console routed to ttyO0, the Bluetooth works well, so I believe it
> > > > > to be a serial driver issue and not a Bluetooth error.
> > > > >
> > > > > # hcitool scan
> > > > > Scanning ...
> > > > > F4:4E:FC:C9:2F:57 BluJax
> > > > > ^C
> > > > > # l2ping F4:4E:FC:C9:2F:57
> > > > > Ping: F4:4E:FC:C9:2F:57 from 00:18:30:49:7D:63 (data size 44) ...
> > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 0 time 6.90ms
> > > > > ...
> > > > > 44 bytes from F4:4E:FC:C9:2F:57 id 14 time 28.29ms
> > > > > ^C15 sent, 15 received, 0% loss
> > > > > #
> > > > >
> > > > > 0% loss and regular, repeatable communication without any Frame
> > > > > reassembly errors.
> > > > >
> > > >
> > > > I tried disabling SERIAL_OMAP and using only SERIAL_8250_OMAP, but
> > > > that didn't help. Because the issue goes away when I disable
> > > > SERIAL_8250_OMAP, I am wondering if something is either being
> > > > misconfigured or some IRQ or DMA integration is missing that may be
> > > > present with the older SERIAL_OMAP driver.
> > > >
> > > > > Any suggestions on how to troubleshoot or what might cause the
> > > > > difference between the two drivers?
> > >
> > > Can it be related to this issue [1]? Can you confirm that 5.2 is
> > > working as expected with the 8250 driver?
> > >
> > > [1] https://marc.info/?l=linux-serial=156965039008649=2
> >
> > I reverted the whole 8250 directory to d99482673f95 ("serial:
> > mctrl_gpio: Check if GPIO property exisits before requesting it") and
> > it is somewhat better, but it's not as good as the stock OMAP serial
> > driver. I get some frame errors and eventually, I get some timeouts,
> > but it's not as bad. I'll try to implement the RTS and CTS as gpio
> > pins and change the device tree accordingly. It might shed some light
> > on the situation.
>
> I tried to manually setup RTS and CTS pins as GPIO, but that didn't
> work, so I changed it back.
>
> It looks like the clocking is correct. I don't know enough about the
> DMA or the IRQ to know if it's working correctly.
>
> I was wondering if the problem is in the handshaking or not.
> I added " uart-has-rtscts;" to by uart node thinking it might help,
> but it did not.
>
> >
> 8250_omap.c has some checks to see if we can enable autoRTS:
>
> if (termios->c_cflag & CRTSCTS && up->port.flags & UPF_HARD_FLOW &&
> !up->gpios) {
> /* Enable AUTOCTS (autoRTS is enabled when RTS is raised) */
> ...
> }
>
> Based on this, I would expect up->gpios to always be zero if we want
> auto RTS CTS.
>
> I threw some debug code into the serial driver to look at the status
> of the various flags that go into setting up auto RTS/CTS.
>
> [ 13.837005] termios->c_cflag & CRTSCTS = 8000
> [ 13.841888] up->port.flags & UPF_HARD_FLOW = 30
> [ 13.846801] up->gpios = ce3f3cc0
> [ 17.166595] termios->c_cflag & CRTSCTS = 0
> [ 17.170745] up->port.flags & UPF_HARD_FLOW = 30
> [ 17.175781] up->gpios = ce3f3d40
>
> I don't know which port is which, but I only have two active uarts
> (console and Bluetooth)
> The Bluetooth port should use handshaking and the console should not.
>
> From the look
Re: [PATCH v2] kheaders: making headers archive reproducible
On Fri, Oct 4, 2019 at 7:40 PM Dmitry Goldin wrote:
>
> From: Dmitry Goldin
>
> In commit 43d8ce9d65a5 ("Provide in-kernel headers to make
> extending kernel easier") a new mechanism was introduced, for kernels
> >=5.2, which embeds the kernel headers in the kernel image or a module
> and exposes them in procfs for use by userland tools.
>
> The archive containing the header files has nondeterminism caused by
> header files metadata. This patch normalizes the metadata and utilizes
> KBUILD_BUILD_TIMESTAMP if provided and otherwise falls back to the
> default behaviour.
>
> In commit f7b101d33046 ("kheaders: Move from proc to sysfs") it was
> modified to use sysfs and the script for generation of the archive was
> renamed to what is being patched.
>
> Signed-off-by: Dmitry Goldin
>
> ---
Applied to linux-kbuild. Thanks.
>
> v1: Initial fix
>
> v2: Added a bit of info about kheaders to the reproducible builds
> documentation and used the opportunity to fix a few typos in the
> original patch.
>
> ---
> Documentation/kbuild/reproducible-builds.rst | 13 +
> kernel/gen_kheaders.sh | 5 -
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/kbuild/reproducible-builds.rst
> b/Documentation/kbuild/reproducible-builds.rst
> index ab92e98c89c8..ce6a408b3303 100644
> --- a/Documentation/kbuild/reproducible-builds.rst
> +++ b/Documentation/kbuild/reproducible-builds.rst
> @@ -16,16 +16,21 @@ the kernel may be unreproducible, and how to avoid them.
> Timestamps
> --
>
> -The kernel embeds a timestamp in two places:
> +The kernel embeds timestamps in three places:
>
> * The version string exposed by ``uname()`` and included in
>``/proc/version``
>
> * File timestamps in the embedded initramfs
>
> -By default the timestamp is the current time. This must be overridden
> -using the `KBUILD_BUILD_TIMESTAMP`_ variable. If you are building
> -from a git commit, you could use its commit date.
> +* If enabled via ``CONFIG_IKHEADERS``, file timestamps of kernel
> + headers embedded in the kernel or respective module,
> + exposed via ``/sys/kernel/kheaders.tar.xz``
> +
> +By default the timestamp is the current time and in the case of
> +``kheaders`` the various files' modification times. This must
> +be overridden using the `KBUILD_BUILD_TIMESTAMP`_ variable.
> +If you are building from a git commit, you could use its commit date.
>
> The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,
> and enables warnings if they are used. If you incorporate external
> diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh
> index 9ff449888d9c..aff79e461fc9 100755
> --- a/kernel/gen_kheaders.sh
> +++ b/kernel/gen_kheaders.sh
> @@ -71,7 +71,10 @@ done | cpio --quiet -pd $cpio_dir >/dev/null 2>&1
> find $cpio_dir -type f -print0 |
> xargs -0 -P8 -n1 perl -pi -e 'BEGIN {undef $/;};
> s/\/\*((?!SPDX).)*?\*\///smg;'
>
> -tar -Jcf $tarfile -C $cpio_dir/ . > /dev/null
> +# Create archive and try to normalize metadata for reproducibility
> +tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \
> +--owner=0 --group=0 --sort=name --numeric-owner \
> +-Jcf $tarfile -C $cpio_dir/ . > /dev/null
>
> echo "$src_files_md5" > kernel/kheaders.md5
> echo "$obj_files_md5" >> kernel/kheaders.md5
> --
> 2.23.0
--
Best Regards
Masahiro Yamada
Re: BISECTED: Compile error on 5.4-rc1
On Fri, Oct 4, 2019 at 5:26 PM Harald Arnesen wrote: > > I just tried to compile kernel 5.4-rc1 on my ThinkPad, which runs Devuan > Beowulf. Got the following: > > $ make bindeb-pkg > UPD include/config/kernel.release > sh ./scripts/package/mkdebian > dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -b -nc -uc > dpkg-buildpackage: info: source package linux-5.4.0-rc1-00014-gcc3a7bfe62b9 > dpkg-buildpackage: info: source version 5.4.0-rc1-00014-gcc3a7bfe62b9-1 > dpkg-buildpackage: info: source distribution beowulf > dpkg-buildpackage: info: source changed by Harald Arnesen > > dpkg-architecture: warning: specified GNU system type x86_64-linux-gnu > does not match CC system type x86_64-pc-linux-gnu, try setting a correct > CC environment variable > dpkg-buildpackage: info: host architecture amd64 > dpkg-source --before-build . > dpkg-source: warning: can't parse dependency -n libelf-dev > dpkg-source: error: error occurred while parsing Build-Depends > dpkg-buildpackage: error: dpkg-source --before-build . subprocess > returned exit status 255 > make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 255 > make: *** [Makefile:1448: bindeb-pkg] Error 2 > > > Bisecting gives me > > 858805b336be1cabb3d9033adaa3676574d12e37 is the first bad commit > commit 858805b336be1cabb3d9033adaa3676574d12e37 > Author: Masahiro Yamada > Date: Sun Aug 25 22:28:37 2019 +0900 > ... > > By reverting commit 858805b336be1cabb3d9033adaa3676574d12e37 I could > compile the kernel. > -- > Hilsen Harald > I cannot reproduce it. I tested bindeb-pkg for the latest Linus tree successfully. masahiro@grover:~/ref/linux$ git log --oneline -1 4ea655343ce4 (HEAD -> master, origin/master, origin/HEAD) Merge tag 'mips_fixes_5.4_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux masahiro@grover:~/ref/linux$ make bindeb-pkg sh ./scripts/package/mkdebian dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch) -b -nc -uc dpkg-buildpackage: info: source package linux-5.4.0-rc1+ dpkg-buildpackage: info: source version 5.4.0-rc1+-4 dpkg-buildpackage: info: source distribution bionic dpkg-buildpackage: info: source changed by Masahiro Yamada dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build linux debian/rules build make KERNELRELEASE=5.4.0-rc1+ ARCH=x86 KBUILD_BUILD_VERSION=4 -f ./Makefile CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a GEN .version CHK include/generated/compile.h LD vmlinux.o MODPOST vmlinux.o MODINFO modules.builtin.modinfo LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.o LD vmlinux SORTEX vmlinux SYSMAP System.map VOFFSET arch/x86/boot/compressed/../voffset.h CC arch/x86/boot/compressed/misc.o OBJCOPY arch/x86/boot/compressed/vmlinux.bin RELOCS arch/x86/boot/compressed/vmlinux.relocs GZIParch/x86/boot/compressed/vmlinux.bin.gz MKPIGGY arch/x86/boot/compressed/piggy.S AS arch/x86/boot/compressed/piggy.o CC arch/x86/boot/compressed/kaslr.o LD arch/x86/boot/compressed/vmlinux ZOFFSET arch/x86/boot/zoffset.h AS arch/x86/boot/header.o CC arch/x86/boot/version.o LD arch/x86/boot/setup.elf OBJCOPY arch/x86/boot/setup.bin OBJCOPY arch/x86/boot/vmlinux.bin BUILD arch/x86/boot/bzImage Setup is 16124 bytes (padded to 16384 bytes). System is 8661 kB CRC fab8ebd9 Kernel: arch/x86/boot/bzImage is ready (#5) Building modules, stage 2. MODPOST 12 modules fakeroot -u debian/rules binary make KERNELRELEASE=5.4.0-rc1+ ARCH=x86 KBUILD_BUILD_VERSION=4 -f ./Makefile intdeb-pkg sh ./scripts/package/builddeb INSTALL drivers/thermal/intel/x86_pkg_temp_thermal.ko INSTALL fs/efivarfs/efivarfs.ko INSTALL net/ipv4/netfilter/iptable_nat.ko INSTALL net/ipv4/netfilter/nf_log_arp.ko INSTALL net/ipv4/netfilter/nf_log_ipv4.ko INSTALL net/ipv6/netfilter/nf_log_ipv6.ko INSTALL net/netfilter/nf_log_common.ko INSTALL net/netfilter/xt_LOG.ko INSTALL net/netfilter/xt_MASQUERADE.ko INSTALL net/netfilter/xt_addrtype.ko INSTALL net/netfilter/xt_mark.ko INSTALL net/netfilter/xt_nat.ko DEPMOD 5.4.0-rc1+ INSTALL ./debian/headertmp/usr/include dpkg-deb: building package 'linux-headers-5.4.0-rc1+' in '../linux-headers-5.4.0-rc1+_5.4.0-rc1+-4_amd64.deb'. dpkg-deb: building package 'linux-libc-dev' in '../linux-libc-dev_5.4.0-rc1+-4_amd64.deb'. dpkg-deb: building package 'linux-image-5.4.0-rc1+' in '../linux-image-5.4.0-rc1+_5.4.0-rc1+-4_amd64.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../linux-5.4.0-rc1+_5.4.0-rc1+-4_amd64.changes dpkg-genchanges: warning: package linux-image-5.4.0-rc1+-dbg in control file but not in files list dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source
Re: kbuild change breaks HiFive-U boot here
Hi Paul,
On Sat, Oct 5, 2019 at 2:48 AM Paul Walmsley wrote:
>
>
> Commit 858805b336be1cabb3d9033adaa3676574d12e37 ("kbuild: add $(BASH) to
> run scripts with bash-extension") breaks my kernel test flow that targets
> the HiFive Unleashed board. The boot traps during BBL early boot and
> stops. QEMU is unaffected. Reverting 858805b336be fixes the issue.
The reason is because
a shell script using bash-extension is run by 'sh' instead of 'bash'.
Run 'git grep CONFIG_SHELL', then can you find a suspicious script?
Is there a warning/error message in the build log?
> I haven't yet had the opportunity to root-cause the issue. The issue may
> be related to idiosyncracies in my local boot testing process, rather
> than this commit.
>
>
> - Paul
--
Best Regards
Masahiro Yamada
Re: [PATCH] kmemleak: Do not corrupt the object_list during clean-up
On 04/10/2019 23:46, Catalin Marinas wrote:
> In case of an error (e.g. memory pool too small), kmemleak disables
> itself and cleans up the already allocated metadata objects. However, if
> this happens early before the RCU callback mechanism is available,
> put_object() skips call_rcu() and frees the object directly. This is not
> safe with the RCU list traversal in __kmemleak_do_cleanup().
>
> Change the list traversal in __kmemleak_do_cleanup() to
> list_for_each_entry_safe() and remove the rcu_read_{lock,unlock} since
> the kmemleak is already disabled at this point. In addition, avoid an
> unnecessary metadata object rb-tree look-up since it already has the
> struct kmemleak_object pointer.
>
> Fixes: c5665868183f ("mm: kmemleak: use the memory pool for early
> allocations")
> Reported-by: Alexey Kardashevskiy
> Reported-by: Marc Dionne
> Cc: Andrew Morton
> Signed-off-by: Catalin Marinas
Tested-by: Alexey Kardashevskiy
It not just fixed lockups but brought network speed back to normal but I guess
it is because kmemleak disables itself
when CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=400.
dmesg:
[0.00] kmemleak: Memory pool empty, consider increasing
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE
[0.00] kmemleak: Cannot allocate a kmemleak_object structure
[0.00] kmemleak: Kernel memory leak detector disabled
> ---
> mm/kmemleak.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 03a8d84badad..244607663363 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -526,6 +526,16 @@ static struct kmemleak_object
> *find_and_get_object(unsigned long ptr, int alias)
> return object;
> }
>
> +/*
> + * Remove an object from the object_tree_root and object_list. Must be called
> + * with the kmemleak_lock held _if_ kmemleak is still enabled.
> + */
> +static void __remove_object(struct kmemleak_object *object)
> +{
> + rb_erase(>rb_node, _tree_root);
> + list_del_rcu(>object_list);
> +}
> +
> /*
> * Look up an object in the object search tree and remove it from both
> * object_tree_root and object_list. The returned object's use_count should
> be
> @@ -538,10 +548,8 @@ static struct kmemleak_object
> *find_and_remove_object(unsigned long ptr, int ali
>
> write_lock_irqsave(_lock, flags);
> object = lookup_object(ptr, alias);
> - if (object) {
> - rb_erase(>rb_node, _tree_root);
> - list_del_rcu(>object_list);
> - }
> + if (object)
> + __remove_object(object);
> write_unlock_irqrestore(_lock, flags);
>
> return object;
> @@ -1834,12 +1842,16 @@ static const struct file_operations kmemleak_fops = {
>
> static void __kmemleak_do_cleanup(void)
> {
> - struct kmemleak_object *object;
> + struct kmemleak_object *object, *tmp;
>
> - rcu_read_lock();
> - list_for_each_entry_rcu(object, _list, object_list)
> - delete_object_full(object->pointer);
> - rcu_read_unlock();
> + /*
> + * Kmemleak has already been disabled, no need for RCU list traversal
> + * or kmemleak_lock held.
> + */
> + list_for_each_entry_safe(object, tmp, _list, object_list) {
> + __remove_object(object);
> + __delete_object(object);
> + }
> }
>
> /*
>
--
Alexey
Re: [PATCH v3 1/3] mm: kmemleak: Make the tool tolerant to struct scan_area allocation failures
On 03/10/2019 18:41, Catalin Marinas wrote: > On Thu, Oct 03, 2019 at 04:13:07PM +1000, Alexey Kardashevskiy wrote: >> On 13/08/2019 02:06, Catalin Marinas wrote: >>> Object scan areas are an optimisation aimed to decrease the false >>> positives and slightly improve the scanning time of large objects known >>> to only have a few specific pointers. If a struct scan_area fails to >>> allocate, kmemleak can still function normally by scanning the full >>> object. >>> >>> Introduce an OBJECT_FULL_SCAN flag and mark objects as such when >>> scan_area allocation fails. >> >> I came across this one while bisecting sudden drop in throughput of a >> 100Gbit Mellanox CX4 ethernet card in a PPC POWER9 system, the speed >> dropped from 100Gbit to about 40Gbit. Bisect pointed at dba82d943177, >> this are the relevant config options: >> >> [fstn1-p1 kernel]$ grep KMEMLEAK ~/pbuild/kernel-le-4g/.config >> CONFIG_HAVE_DEBUG_KMEMLEAK=y >> CONFIG_DEBUG_KMEMLEAK=y >> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=16000 >> # CONFIG_DEBUG_KMEMLEAK_TEST is not set >> # CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF is not set >> CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y > > The throughput drop is probably caused caused by kmemleak slowing down > all memory allocations (including skb). So that's expected. You may get > similar drop with other debug options like lock proving, kasan. I was not precise. I meant that before dba82d943177 kmemleak would work but would not slow network down (at least 100Gbit) and now it does which is downgrade so I was wondering if kmemleak just got so much better to justify this change or there is a bug somewhere, so which one is it? Or "LOG_SIZE=400" never really worked? See my findings below though. If it was always slow, it is expected indeed. > >> Setting CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=400 or even 4000 (this is >> what KMEMLEAK_EARLY_LOG_SIZE is now in the master) produces soft >> lockups on the recent upstream (sha1 a3c0e7b1fe1f): >> >> [c01fde64fb60] [c0c24ed4] _raw_write_unlock_irqrestore+0x54/0x70 >> [c01fde64fb90] [c04117e4] find_and_remove_object+0xa4/0xd0 >> [c01fde64fbe0] [c0411c74] delete_object_full+0x24/0x50 >> [c01fde64fc00] [c0411d28] __kmemleak_do_cleanup+0x88/0xd0 >> [c01fde64fc40] [c012a1a4] process_one_work+0x374/0x6a0 >> [c01fde64fd20] [c012a548] worker_thread+0x78/0x5a0 >> [c01fde64fdb0] [c0135508] kthread+0x198/0x1a0 >> [c01fde64fe20] [c000b980] ret_from_kernel_thread+0x5c/0x7c > > That's the kmemleak disabling path. I don't have the full log but I > suspect by setting a small pool size, kmemleak failed to allocate memory > and went into disabling itself. The clean-up above tries to remove the > allocated metadata. It seems that it takes significant time on your > platform. Not sure how to avoid the soft lock-up but I wouldn't bother > too much about it, it's only triggered by a previous error condition > disabling kmemleak. > >> KMEMLEAK_EARLY_LOG_SIZE=8000 works but slow. >> >> Interestingly KMEMLEAK_EARLY_LOG_SIZE=400 on dba82d943177 still worked >> and I saw my 100Gbit. Disabling KMEMLEAK also fixes the speed >> (apparently). > > A small memory pool for kmemleak just disables it shortly after boot, so > it's no longer in the way and you get your throughput back. > >> Is that something expected? Thanks, > > Yes for the throughput. Not sure about the soft lock-up. Do you have the > full log around the lock-up? I was going to post one but then I received "kmemleak: Do not corrupt the object_list during clean-up" which fixed lockups and took throughput back to normal, I'll reply there too. Thanks, -- Alexey
Re: [Patch v2 19/21] media: v4l2-common: add pixel encoding support
Hi Benoit,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Benoit-Parrot/media-vpe-maintenance/20191005-061051
base: git://linuxtv.org/media_tree.git master
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/media//usb/zr364xx/zr364xx.c:25:0:
>> include/media/v4l2-common.h:468:2: error: stray '@' in program
@V4L2_ENC_UNKNOWN = 0,
^
vim +468 include/media/v4l2-common.h
458
459 /**
460 * enum v4l2_pixel_encoding - specifies the pixel encoding value
461 *
462 * @V4L2_ENC_UNKNOWN: Pixel encoding is unknown/un-initialized
463 * @V4L2_ENC_YUV: Pixel encoding is YUV
464 * @V4L2_ENC_RGB: Pixel encoding is RGB
465 * @V4L2_ENC_BAYER: Pixel encoding is Bayer
466 */
467 enum v4l2_pixel_encoding {
> 468 @V4L2_ENC_UNKNOWN = 0,
469 V4L2_ENC_YUV = 1,
470 V4L2_ENC_RGB = 2,
471 V4L2_ENC_BAYER = 3,
472 };
473
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v3] media: vimc: Enable set resolution at the scaler src pad
Modify the scaler subdevice to accept setting the resolution of the source
pad (previously the source resolution would always be 3 times the sink for
both dimensions). Now any resolution can be set at src (even smaller ones)
and the sink video will be scaled to match it.
Test example: With the vimc module up (using the default vimc topology)
media-ctl -d /dev/media0 -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d /dev/media0 -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
media-ctl -d /dev/media0 -V '"Scaler":0[fmt:RGB888_1X24/640x480]'
media-ctl -d /dev/media0 -V '"Scaler":1[fmt:RGB888_1X24/300x700]'
v4l2-ctl -d /dev/video2 -v width=300,height=700
v4l2-ctl -d /dev/video0 -v pixelformat=BA81
v4l2-ctl --stream-mmap --stream-count=10 -d /dev/video2 \
--stream-to=test.raw
ffplay -loglevel warning -v info -f rawvideo -pixel_format rgb24 \
-video_size "300x700" test.raw
Co-developed-by: Gabriela Bittencourt
Signed-off-by: Gabriela Bittencourt
Co-developed-by: Gabriel Francisco Mandaji
Signed-off-by: Gabriel Francisco Mandaji
Signed-off-by: Pedro "pirate" Terra
---
Changes in V3:
* Corrections suggested by Hans:
- Default scaling factor is now 1 (we removed the define and
set the source format equals the sink).
- Removed SCA_COUNT (enum that represents the number of pads)
as there always 2
- Swapped the per byte pixel copy to memcpy.
* Corrections suggested by Dafna:
- Removed from the documentation the old scaler parameter which
isn't necessary anymore.
* Added a thank you note at the end of the email
Changes in V2:
* Patch was not sent to media list mail for some reason (even though it
was on the Cc list), trying again.
* Updating documentation.
Hello! This patch depends on the series:
"Collapse vimc into single monolithic driver" V3
This code is the result of friends getting together with too much
coffee, sugar and beer trying to get started with some kernel coding.
Please, don't go easy on us! s2
Thanks Hans and Dafna for taking your time to review our patch!
Running
/usr/local/bin/v4l2-compliance -m /dev/media0
Gave the following result:
v4l2-compliance SHA: b393a5408383b7341883857dfda78537f2f85ef6, 64 bits
Grand Total for vimc device /dev/media0: 451, Succeeded: 451, Failed: 0,
Warnings: 0
---
Documentation/media/v4l-drivers/vimc.rst | 19 +-
drivers/media/platform/vimc/vimc-scaler.c | 212 +++---
2 files changed, 72 insertions(+), 159 deletions(-)
diff --git a/Documentation/media/v4l-drivers/vimc.rst
b/Documentation/media/v4l-drivers/vimc.rst
index a582af0509ee..22689bb6a63b 100644
--- a/Documentation/media/v4l-drivers/vimc.rst
+++ b/Documentation/media/v4l-drivers/vimc.rst
@@ -61,9 +61,11 @@ vimc-debayer:
* 1 Pad source
vimc-scaler:
- Scale up the image by a factor of 3. E.g.: a 640x480 image becomes a
-1920x1440 image. (this value can be configured, see at
-`Module options`_).
+ Re-size the image to meet the source pad resolution. E.g.: if the sync
pad
+is configured to 360x480 and the source to 1280x720, the image will be
stretched
+to fit the source resolution. Works for any resolution within the vimc
+limitations (even shrinking the image if necessary).
+
Exposes:
* 1 Pad sink
@@ -80,16 +82,7 @@ vimc-capture:
Module options
---
-Vimc has a few module parameters to configure the driver.
-
-param=value
-
-* ``sca_mult=``
-
-Image size multiplier factor to be used to multiply both width and
-height, so the image size will be ``sca_mult^2`` bigger than the
-original one. Currently, only supports scaling up (the default value
-is 3).
+Vimc has one module parameters to configure the driver.
* ``deb_mean_win_size=``
diff --git a/drivers/media/platform/vimc/vimc-scaler.c
b/drivers/media/platform/vimc/vimc-scaler.c
index 05db5070e268..3a319ee3e8bb 100644
--- a/drivers/media/platform/vimc/vimc-scaler.c
+++ b/drivers/media/platform/vimc/vimc-scaler.c
@@ -8,29 +8,25 @@
#include
#include
#include
+#include
#include
#include "vimc-common.h"
-static unsigned int sca_mult = 3;
-module_param(sca_mult, uint, );
-MODULE_PARM_DESC(sca_mult, " the image size multiplier");
-
-#define IS_SINK(pad) (!pad)
-#define IS_SRC(pad)(pad)
-#define MAX_ZOOM 8
+/* Pad identifier */
+enum sca_pad {
+ SCA_SINK = 0,
+ SCA_SRC = 1,
+};
struct vimc_sca_device {
struct vimc_ent_device ved;
struct v4l2_subdev sd;
struct device *dev;
- /* NOTE: the source fmt is the same as the sink
-* with the width and hight multiplied by mult
-*/
- struct v4l2_mbus_framefmt sink_fmt;
+ /* Frame format for both sink and src pad */
+ struct v4l2_mbus_framefmt fmt[2];
/* Values calculated when the stream starts */
u8 *src_frame;
- unsigned int src_line_size;
unsigned int bpp;
};
Re: [PATCH v6 2/2] leds: Add control of the voltage/current regulator to the LED core
Hi Jean-Jacques,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on j.anaszewski-leds/for-next]
[cannot apply to v5.4-rc1 next-20191004]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jean-Jacques-Hiblot/leds-Add-control-of-the-voltage-current-regulator-to-the-LED-core/20191005-062631
base:
https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
for-next
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sparc
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers/leds/led-core.c: In function 'try_turn_on_regulator_if_needed':
>> drivers/leds/led-core.c:65:15: warning: overflow in implicit constant
>> conversion [-Woverflow]
atomic_and(~REG_R_ON, _cdev->regulator_state);
^
drivers/leds/led-core.c: In function 'led_set_brightness_nopm':
drivers/leds/led-core.c:353:27: warning: overflow in implicit constant
conversion [-Woverflow]
old = atomic_fetch_and(~REG_U_ON,
^
vim +65 drivers/leds/led-core.c
54
55 static void try_turn_on_regulator_if_needed(struct led_classdev
*led_cdev)
56 {
57 int old = atomic_cmpxchg(_cdev->regulator_state,
REG_R_OFF_U_ON,
58REG_R_ON_U_ON);
59 if (old == REG_R_OFF_U_ON) {
60 int rc = regulator_enable(led_cdev->regulator);
61
62 if (rc) {
63 dev_err(led_cdev->dev,
64 "Failed to enable the regulator
(%d)\n", rc);
> 65 atomic_and(~REG_R_ON,
_cdev->regulator_state);
66 }
67 }
68 }
69
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
On Fri, 2019-10-04 at 16:36 -0700, Alexander Duyck wrote:
> From: Alexander Duyck
>
> This patch is meant to address possible race conditions that can exist
> between network configuration and power management. A similar issue was
> fixed for igb in commit 9474933caf21 ("igb: close/suspend race in
> netif_device_detach").
>
> In addition it consolidates the code so that the PCI error handling code
> will essentially perform the power management freeze on the device prior to
> attempting a reset, and will thaw the device afterwards if that is what it
> is planning to do. Otherwise when we call close on the interface it should
> see it is detached and not attempt to call the logic to down the interface
> and free the IRQs again.
>
> >From what I can tell the check that was adding the check for __E1000_DOWN
> in e1000e_close was added when runtime power management was added. However
> it should not be relevant for us as we perform a call to
> pm_runtime_get_sync before we call e1000_down/free_irq so it should always
> be back up before we call into this anyway.
>
> Signed-off-by: Alexander Duyck
> ---
>
> I'm putting this out as an RFC for now. I haven't had a chance to do much
> testing yet, but I have verified no build issues, and the driver appears
> to load, link, and pass traffic without problems.
>
> This should address issues seen with either double freeing or never freeing
> IRQs that have been seen on this and similar drivers in the past.
>
> I'll submit this formally after testing it over the weekend assuming there
> are no issues.
>
> drivers/net/ethernet/intel/e1000e/netdev.c | 33
> ++--
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index d7d56e42a6aa..182a2c8f12d8 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -4715,12 +4715,12 @@ int e1000e_close(struct net_device *netdev)
>
> pm_runtime_get_sync(>dev);
>
> - if (!test_bit(__E1000_DOWN, >state)) {
> + if (netif_device_present(netdev)) {
> e1000e_down(adapter, true);
> e1000_free_irq(adapter);
>
> /* Link status message must follow this format */
> - pr_info("%s NIC Link is Down\n", adapter->netdev->name);
> + pr_info("%s NIC Link is Down\n", netdev->name);
> }
>
> napi_disable(>napi);
> @@ -6299,6 +6299,7 @@ static int e1000e_pm_freeze(struct device *dev)
> struct net_device *netdev = dev_get_drvdata(dev);
> struct e1000_adapter *adapter = netdev_priv(netdev);
>
> + rtnl_lock();
> netif_device_detach(netdev);
>
> if (netif_running(netdev)) {
> @@ -6313,6 +6314,8 @@ static int e1000e_pm_freeze(struct device *dev)
> e1000e_down(adapter, false);
> e1000_free_irq(adapter);
> }
> + rtnl_unlock();
> +
> e1000e_reset_interrupt_capability(adapter);
>
> /* Allow time for pending master requests to run */
> @@ -6626,27 +6629,30 @@ static int __e1000_resume(struct pci_dev *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> static int e1000e_pm_thaw(struct device *dev)
> {
> struct net_device *netdev = dev_get_drvdata(dev);
> struct e1000_adapter *adapter = netdev_priv(netdev);
> + int rc = 0;
>
> e1000e_set_interrupt_capability(adapter);
> - if (netif_running(netdev)) {
> - u32 err = e1000_request_irq(adapter);
>
> - if (err)
> - return err;
> + rtnl_lock();
> + if (netif_running(netdev)) {
> + rc = e1000_request_irq(adapter);
> + if (rc)
> + goto err_irq;
>
> e1000e_up(adapter);
> }
>
> netif_device_attach(netdev);
> -
> - return 0;
> + rtnl_unlock();
> +err_irq:
> + return rc;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> static int e1000e_pm_suspend(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> @@ -6821,13 +6827,11 @@ static pci_ers_result_t
> e1000_io_error_detected(struct pci_dev *pdev,
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct e1000_adapter *adapter = netdev_priv(netdev);
>
> - netif_device_detach(netdev);
> + e1000e_pm_freeze(>dev);
>
> if (state == pci_channel_io_perm_failure)
> return PCI_ERS_RESULT_DISCONNECT;
>
> - if (netif_running(netdev))
> - e1000e_down(adapter, true);
> pci_disable_device(pdev);
>
> /* Request a slot slot reset. */
> @@ -6893,10 +6897,7 @@ static void e1000_io_resume(struct pci_dev *pdev)
>
> e1000_init_manageability_pt(adapter);
>
> - if (netif_running(netdev))
> - e1000e_up(adapter);
> -
> - netif_device_attach(netdev);
> + e1000e_pm_thaw(>dev);
>
> /* If the controller has AMT, do not set DRV_LOAD until the
INQUIRY
Hello I am Mrs Lubov Aleksandrov from DAVSAR LLC Russia.I am in charge of sales . We are interested in your product .We would greatly appreciate receiving any information, brochures and price lists of your products. Thanks. Mrs Lubov Aleksandrov Sales General Manager of DAVSAR LLC) 14 Marksistskaya St. 109147 Moscow RUSSIA Phone:+7(494)213-66-26
Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default
On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: > In order to avoid wasting user address space by using bottom-up mmap > allocation scheme, prefer top-down scheme when possible. > > Before: > root@qemuriscv64:~# cat /proc/self/maps > 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils > 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils > 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils > 00018000-00039000 rw-p 00:00 0 [heap] > 156000-16d000 r-xp fe:00 7193 /lib/ld-2.28.so > 16d000-16e000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so > 16e000-16f000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so > 16f000-17 rw-p 00:00 0 > 17-172000 r-xp 00:00 0 [vdso] > 174000-176000 rw-p 00:00 0 > 176000-1555674000 r-xp fe:00 7187 /lib/libc-2.28.so > 1555674000-1555678000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so > 1555678000-155567a000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so > 155567a000-15556a rw-p 00:00 0 > 3fffb9-3fffbb1000 rw-p 00:00 0 [stack] > > After: > root@qemuriscv64:~# cat /proc/self/maps > 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils > 00016000-00017000 r--p 5000 fe:00 6389 /bin/cat.coreutils > 00017000-00018000 rw-p 6000 fe:00 6389 /bin/cat.coreutils > 2de81000-2dea2000 rw-p 00:00 0 [heap] > 3ff7eb6000-3ff7ed8000 rw-p 00:00 0 > 3ff7ed8000-3ff7fd6000 r-xp fe:00 7187 /lib/libc-2.28.so > 3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187 /lib/libc-2.28.so > 3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187 /lib/libc-2.28.so > 3ff7fdc000-3ff7fe2000 rw-p 00:00 0 > 3ff7fe4000-3ff7fe6000 r-xp 00:00 0 [vdso] > 3ff7fe6000-3ff7ffd000 r-xp fe:00 7193 /lib/ld-2.28.so > 3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193 /lib/ld-2.28.so > 3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193 /lib/ld-2.28.so > 3ff7fff000-3ff800 rw-p 00:00 0 > 3fff888000-3fff8a9000 rw-p 00:00 0 [stack] > > Signed-off-by: Alexandre Ghiti > Acked-by: Paul Walmsley > Reviewed-by: Christoph Hellwig > Reviewed-by: Kees Cook > Reviewed-by: Luis Chamberlain > --- > arch/riscv/Kconfig | 12 > 1 file changed, 12 insertions(+) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 59a4727ecd6c..87dc5370becb 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -54,6 +54,18 @@ config RISCV > select EDAC_SUPPORT > select ARCH_HAS_GIGANTIC_PAGE > select ARCH_WANT_HUGE_PMD_SHARE if 64BIT > + select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU > + select HAVE_ARCH_MMAP_RND_BITS > + > +config ARCH_MMAP_RND_BITS_MIN > + default 18 if 64BIT > + default 8 > + > +# max bits determined by the following formula: > +# VA_BITS - PAGE_SHIFT - 3 > +config ARCH_MMAP_RND_BITS_MAX > + default 24 if 64BIT # SV39 based > + default 17 > > config MMU > def_bool y With this patch, I am not able to boot a Fedora Linux(a Gnome desktop image) on RISC-V hardware (Unleashed + Microsemi Expansion board). The booting gets stuck right after systemd starts. https://paste.fedoraproject.org/paste/TOrUMqqKH-pGFX7CnfajDg Reverting just this patch allow to boot Fedora successfully on specific RISC-V hardware. I have not root caused the issue but it looks like it might have messed userpsace mapping. -- Regards, Atish
Re: [PATCH] nvme-pci: Shutdown when removing dead controller
On Fri, 2019-10-04 at 11:36 -0400, Tyler Ramer wrote:
> Here's a failure we had which represents the issue the patch is
> intended to solve:
>
> Aug 26 15:00:56 testhost kernel: nvme nvme4: async event result 00010300
> Aug 26 15:01:27 testhost kernel: nvme nvme4: controller is down; will
> reset: CSTS=0x3, PCI_STATUS=0x10
> Aug 26 15:02:10 testhost kernel: nvme nvme4: Device not ready; aborting
> reset
> Aug 26 15:02:10 testhost kernel: nvme nvme4: Removing after probe
> failure status: -19
>
> The CSTS warnings comes from nvme_timeout, and is printed by
> nvme_warn_reset. A reset then occurs
> Controller state should be NVME_CTRL_RESETTING
>
> Now, in nvme_reset_work, controller is never marked "CONNECTING" at:
>
> if (!nvme_change_ctrl_state(>ctrl, NVME_CTRL_CONNECTING))
>
> because several lines above, we can determine that
> nvme_pci_configure_admin_queues returns
> a bad result, which triggers a goto out_unlock and prints "removing
> after probe failure status: -19"
>
> Because state is never changed to NVME_CTRL_CONNECTING or
> NVME_CTRL_DELETING, the
> logic added in
> https://github.com/torvalds/linux/commit/2036f7263d70e67d70a67899a468588cb7356bc9
> should not apply. We can further validate that dev->ctrl.state ==
> NVME_CTRL_RESETTING thanks to
> the WARN_ON in nvme_reset_work.
>
>
>
>
>
>
> On Thu, Oct 3, 2019 at 3:13 PM Tyler Ramer wrote:
> >
> > Always shutdown the controller when nvme_remove_dead_controller is
> > reached.
> >
> > It's possible for nvme_remove_dead_controller to be called as part of a
> > failed reset, when there is a bad NVME_CSTS. The controller won't
> > be comming back online, so we should shut it down rather than just
> > disabling.
> >
What is the bad CSTS bit? CSTS.RDY? The entire reset/disable race is quite
tricky in general, it was made better with the shutdown_lock, but if the
timeout value is small, several of them can occur in the middle of a reset.
For this patch
Acked-by: Balbir Singh
> > Signed-off-by: Tyler Ramer
> > ---
> > drivers/nvme/host/pci.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
> > index c0808f9eb8ab..c3f5ba22c625 100644
> > --- a/drivers/nvme/host/pci.c
> > +++ b/drivers/nvme/host/pci.c
> > @@ -2509,7 +2509,7 @@ static void nvme_pci_free_ctrl(struct nvme_ctrl
> > *ctrl)
> > static void nvme_remove_dead_ctrl(struct nvme_dev *dev)
> > {
> > nvme_get_ctrl(>ctrl);
> > - nvme_dev_disable(dev, false);
> > + nvme_dev_disable(dev, true);
> > nvme_kill_queues(>ctrl);
> > if (!queue_work(nvme_wq, >remove_work))
> > nvme_put_ctrl(>ctrl);
> > --
> > 2.23.0
> >
>
> ___
> Linux-nvme mailing list
> linux-n...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
Re: [cifs] semantics of IPC$ shares (was Re: [PATCH] devpts: Fix NULL pointer dereference in dcache_readdir())
Your questions are interesting and rarely asked.
On Fri, Oct 4, 2019 at 11:57 AM Al Viro wrote:
>
> On Fri, Oct 04, 2019 at 05:02:20PM +0100, Al Viro wrote:
>
> > * (possibly) cifs hitting the same on eviction by memory pressure
> > alone
> > (no locked inodes anywhere in sight). Possibly == if cifs IPC$ share
> > happens to
> > show up non-empty (e.g. due to server playing silly buggers).
> > * (possibly) cifs hitting *another* lovely issue - lookup in one
> > subdirectory
> > of IPC$ root finding an alias for another subdirectory of said root,
> > triggering
> > d_move() of dentry of the latter. IF the name happens to be long enough to
> > be
> > externally allocated and if dcache_readdir() on root is currently copying
> > it to
> > userland, Bad Things(tm) will happen. That one almost certainly depends
> > upon the
> > server playing silly buggers and might or might not be possible. I'm not
> > familiar
> > enough with CIFS to tell.
>
> BTW, I would really appreciate somebody familiar with CIFS giving a braindump
> on
> that. Questions:
>
> 1) What's normally (== without malicious/broken server) seen when you mount
> an IPC$ share?
IPC$ is for "inter process communication" so is basically an
abstraction for named pipes (used
for remote procedure call queries using the old DCE/RPC standard).
To Windows it is possible to mount IPC$, to Samba you can connect to
the share but
due to a Samba server bug you can't do a query info on "." (the 'root'
of the IPC$ share).
> 2) Does it ever have subdirectories (i.e. can we fail a lookup in its root if
> it
> looks like returning a subdirectory)?
In Samba you can't query subdirectories on IPC$ because even open of "."
fails, but to Windows the query directory would get "STATUS_INVALID_INFO_CLASS"
An interesting question, and one that I will bring up with the spec
writers is whether
there are info level which would be allowed for query directory (probably not).
Another interesting question this brings up is ... "should we allow
enumerating the 'services' under IPC$
via readdir"? You could imagine a case where mounting IPC$ would
allow you to see the 'services'
exported by the server over remote procedure call ("server service"
and "workstation server" and "netlogon service"
and the global name space (DFS) service and perhaps "witness protocol
services" and "branch cache service" etc.)
And then thinking about Dave Howell's changes to the mount API -
should this be a mechanism that is allowed to be
used to either browse the valid shares or better access the root of
the (DFS) global name space.
But the short answer is "no you can't query the directory contents
under IPC$" (at least not without changing the
abstraction that we export on the client) but I am open to ideas if
this would fit with Dave Howell's changes to the
mount API or other ideas.
> 3) If it can be non-empty, is there way to ask the server about its contents?
> Short of "look every possible name up", that is...
>
> As it is, the thing is abusing either cifs_lookup() (if it really shouldn't
> have any files in it) or dcache_readdir(). Sure, dcache_readdir() can (and
> should) pin a dentry while copying the name to userland, but WTF kind of
> semantics it is? "ls will return the things you'd guessed to look up, until
> there's enough memory pressure to have them forgotten, which can happen at
> any point with no activity on server"?
Server's realistically must expose a share "IPC$" so in theory it can be mounted
(despite Samba server's current bug there) and there were some experiments
that Shirish did a few years ago opening well known services under mounts
to IPC$ (to allow doing remote procedure calls over SMB3 mounts which has
some value) but AFAIK you would never do a readdir over IPC$ and no
current users would ever mount IPC$
--
Thanks,
Steve
RE: [EXT] [PATCH] mwifiex: pcie: Fix memory leak in mwifiex_pcie_alloc_cmdrsp_buf
Hi Navid,
> Fixes: fc3314609047 ("mwifiex: use pci_alloc/free_consistent APIs for PCIe")
Thanks for the change;
Acked-by: Ganapathi Bhat
Regards,
Ganapathi
RE: [EXT] [PATCH] mwifiex: pcie: Fix memory leak in mwifiex_pcie_init_evt_ring
Hi Navid,
> Fixes: 0732484b47b5 ("mwifiex: separate ring initialization and ring creation
> routines")
Thanks for the this change as well;
Acked-by: Ganapathi Bhat
Regards,
Ganapathi
[PATCH] PCI: endpoint: cast the page number to phys_addr_t
From: Alan Mikhak Modify pci_epc_mem_alloc_addr() to cast the variable 'pageno' from type 'int' to 'phys_addr_t' before shifting left. This cast is needed to avoid treating bit 31 of 'pageno' as the sign bit which would otherwise get sign-extended to produce a negative value. When added to the base address of PCI memory space, the negative value would produce an invalid physical address which falls before the start of the PCI memory space. Signed-off-by: Alan Mikhak --- drivers/pci/endpoint/pci-epc-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/endpoint/pci-epc-mem.c b/drivers/pci/endpoint/pci-epc-mem.c index 2bf8bd1f0563..d2b174ce15de 100644 --- a/drivers/pci/endpoint/pci-epc-mem.c +++ b/drivers/pci/endpoint/pci-epc-mem.c @@ -134,7 +134,7 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc, if (pageno < 0) return NULL; - *phys_addr = mem->phys_base + (pageno << page_shift); + *phys_addr = mem->phys_base + ((phys_addr_t)pageno << page_shift); virt_addr = ioremap(*phys_addr, size); if (!virt_addr) bitmap_release_region(mem->bitmap, pageno, order); -- 2.7.4
[GIT] Networking
1) ieeeu02154 atusb driver use and free, from Johan Hovold. 2) Need to validate TCA_CBQ_WRROPT netlink attributes, from Eric Dumazet. 3) txq null deref in mac80211, from Miaoqing Pan. 4) ionic driver needs to select NET_DEVLINK, from Arnd Bergmann. 5) Need to disable bh during nft_connlimit GC, from Pablo Neira Ayuso. 6) Avoid division by zero in taprio scheduler, from Vladimir Oltean. 7) Various xgmac fixes in stmmac driver from Jose Abreu. 8) Avoid 64-bit division in mlx5 leading to link errors on 32-bit from Michal Kubecek. 9) Fix bad VLAN check in rtl8366 DSA driver, from Linus Walleij. 10) Fix sleep while atomic in sja1105, from Vladimir Oltean. 11) Suspend/resume deadlock in stmmac, from Thierry Reding. 12) Various UDP GSO fixes from Josh Hunt. 13) Fix slab out of bounds access in tcp_zerocopy_receive(), from Eric Dumazet. 14) Fix OOPS in __ipv6_ifa_notify(), from David Ahern. 15) Memory leak in NFC's llcp_sock_bind, from Eric Dumazet. Please pull, thanks a lot! The following changes since commit 02dc96ef6c25f990452c114c59d75c368a1f4c8f: Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2019-09-28 17:47:33 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net for you to fetch changes up to ef129d34149ea23d0d442844fc25ae26a85589fc: selftests/net: add nettest to .gitignore (2019-10-04 18:36:34 -0700) Adam Zerella (1): docs: networking: Add title caret and missing doc Alexey Dobriyan (1): net: make sock_prot_memory_pressure() return "const char *" Andrea Merello (1): net: phy: allow for reset line to be tied to a sleepy GPIO controller Arnd Bergmann (1): ionic: select CONFIG_NET_DEVLINK Christophe JAILLET (1): ieee802154: mcr20a: simplify a bit 'mcr20a_handle_rx_read_buf_complete()' David Ahern (3): ipv6: Handle race in addrconf_dad_work Revert "ipv6: Handle race in addrconf_dad_work" ipv6: Handle missing host route in __ipv6_ifa_notify David Howells (1): rxrpc: Fix rxrpc_recvmsg tracepoint David S. Miller (6): Merge tag 'ieee802154-for-davem-2019-09-28' of git://git.kernel.org/.../sschmidt/wpan Merge tag 'mac80211-for-davem-2019-10-01' of git://git.kernel.org/.../jberg/mac80211 Merge branch 'stmmac-fixes' Merge branch 'SJA1105-DSA-locking-fixes-for-PTP' Merge git://git.kernel.org/.../pablo/nf Merge branch 'Fix-regression-with-AR8035-speed-downgrade' Dexuan Cui (1): vsock: Fix a lockdep warning in __vsock_release() Dongli Zhang (1): xen-netfront: do not use ~0U as error return value for xennet_fill_frags() Dotan Barak (1): net/rds: Fix error handling in rds_ib_add_one() Eric Dumazet (6): sch_cbq: validate TCA_CBQ_WRROPT to avoid crash tcp: adjust rto_base in retransmits_timed_out() ipv6: drop incoming packets having a v4mapped source address tcp: fix slab-out-of-bounds in tcp_zerocopy_receive() sch_dsmark: fix potential NULL deref in dsmark_init() nfc: fix memory leak in llcp_sock_bind() Florian Westphal (1): netfilter: drop bridge nf reset from nf_reset Haishuang Yan (1): erspan: remove the incorrect mtu limit for erspan Jakub Kicinski (1): selftests/net: add nettest to .gitignore Johan Hovold (2): ieee802154: atusb: fix use-after-free at disconnect hso: fix NULL-deref on tty open Johannes Berg (4): nl80211: validate beacon head cfg80211: validate SSID/MBSSID element ordering assumption cfg80211: initialize on-stack chandefs mac80211: keep BHs disabled while calling drv_tx_wake_queue() Jose Abreu (9): net: stmmac: xgmac: Not all Unicast addresses may be available net: stmmac: xgmac: Detect Hash Table size dinamically net: stmmac: selftests: Always use max DMA size in Jumbo Test net: stmmac: dwmac4: Always update the MAC Hash Filter net: stmmac: Correctly take timestamp for PTPv2 net: stmmac: Do not stop PHY if WoL is enabled net: stmmac: xgmac: Disable the Timestamp interrupt by default net: stmmac: xgmac: Fix RSS not writing all Keys to HW net: stmmac: xgmac: Fix RSS writing wrong keys Josh Hunt (2): udp: fix gso_segs calculations udp: only do GSO if # of segs > 1 Kai-Heng Feng (1): r8152: Set macpassthru in reset_resume callback Linus Walleij (1): net: dsa: rtl8366: Check VLAN ID and not ports Lorenzo Bianconi (1): net: socionext: netsec: always grab descriptor lock Martin KaFai Lau (1): net: Unpublish sk from sk_reuseport_cb before call_rcu Miaoqing Pan (2): nl80211: fix null pointer dereference mac80211: fix txq null pointer dereference Michal Kubecek (1): mlx5: avoid 64-bit division in dr_icm_pool_mr_create() Michal Vokáč (1): net: dsa: qca8k: Use up to 7 ports for all operations Navid Emamdoost
Re: [PATCH] net: qlogic: Fix memory leak in ql_alloc_large_buffers
From: Navid Emamdoost
Date: Fri, 4 Oct 2019 15:24:39 -0500
> In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
> This skb should be released if pci_dma_mapping_error fails.
>
> Fixes: 0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in
> ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(),
> ql_alloc_large_buffers(), and ql3xxx_send()")
> Signed-off-by: Navid Emamdoost
Applied and queued up for -stable.
Re: [RFC PATCH 00/13] XOM for KVM guest userspace
On Fri, Oct 4, 2019 at 1:10 PM Edgecombe, Rick P wrote: > > On Fri, 2019-10-04 at 07:56 -0700, Andy Lutomirski wrote: > > On Thu, Oct 3, 2019 at 2:38 PM Rick Edgecombe > > wrote: > > > > > > This patchset enables the ability for KVM guests to create execute-only > > > (XO) > > > memory by utilizing EPT based XO permissions. XO memory is currently > > > supported > > > on Intel hardware natively for CPU's with PKU, but this enables it on > > > older > > > platforms, and can support XO for kernel memory as well. > > > > The patchset seems to sometimes call this feature "XO" and sometimes > > call it "NR". To me, XO implies no-read and no-write, whereas NR > > implies just no-read. Can you please clarify *exactly* what the new > > bit does and be consistent? > > > > I suggest that you make it NR, which allows for PROT_EXEC and > > PROT_EXEC|PROT_WRITE and plain PROT_WRITE. WX is of dubious value, > > but I can imagine plain W being genuinely useful for logging and for > > JITs that could maintain a W and a separate X mapping of some code. > > In other words, with an NR bit, all 8 logical access modes are > > possible. Also, keeping the paging bits more orthogonal seems nice -- > > we already have a bit that controls write access. > > Sorry, yes the behavior of this bit needs to be documented a lot better. I > will > definitely do this for the next version. > > To clarify, since the EPT permissions in the XO/NR range are executable, and > not > readable or writeable the new bit really means XO, but only when NX is 0 since > the guest page tables are being checked as well. When NR=1, W=1, and NX=0, the > memory is still XO. > > NR was picked over XO because as you say. The idea is that it can be defined > that in the case of KVM XO, NR and writable is not a valid combination, like > writeable but not readable is defined as not valid for the EPT. > Ugh, I see, this is an "EPT Misconfiguration". Oh, well. I guess just keep things as they are and document things better, please. Don't try to emulate. I don't suppose Intel could be convinced to get rid of that in a future CPU and allow write-only memory? BTW, is your patch checking for support in IA32_VMX_EPT_VPID_CAP? I didn't notice it, but I didn't look that hard.
Re: [PATCH v2] riscv: add support for SECCOMP and SECCOMP_FILTER
On Fri, 27 Sep 2019, Kees Cook wrote: > On Wed, Aug 28, 2019 at 6:30 PM Paul Walmsley > wrote: > > On Mon, 26 Aug 2019, Kees Cook wrote: > > > > > On Mon, Aug 26, 2019 at 09:39:50AM -0700, David Abdurachmanov wrote: > > > > I don't have the a build with SECCOMP for the board right now, so it > > > > will have to wait. I just finished a new kernel (almost rc6) for Fedora, > > > > > > FWIW, I don't think this should block landing the code: all the tests > > > fail without seccomp support. ;) So this patch is an improvement! > > > > Am sympathetic to this -- we did it with the hugetlb patches for RISC-V -- > > but it would be good to understand a little bit more about why the test > > fails before we merge it. > > The test is almost certainly failing due to the environmental > requirements (i.e. namespaces, user ids, etc). There are some corner > cases in there that we've had to fix in the past. If the other tests > are passing, then I would expect all the seccomp internals are fine -- > it's just the case being weird. It's just a matter of figuring out > what state the test environment is in so we can cover that corner case > too. > > > Once we merge the patch, it will probably reduce the motivation for others > > to either understand and fix the underlying problem with the RISC-V code > > -- or, if it truly is a flaky test, to drop (or fix) the test in the > > seccomp_bpf kselftests. > > Sure, I get that point -- but I don't want to block seccomp landing > for riscv for that. I suggested to David offlist that the test could > just be marked with a FIXME XFAIL on riscv and once someone's in a > better position to reproduce it we can fix it. (I think the test bug > is almost certainly not riscv specific, but just some missing > requirement that we aren't handling correctly.) OK. It might be nice to mark the seccomp_bpf.c test as flaky in the comments for the test. > How does that sound? Let's follow your plan. Thanks for your review and feedback. - Paul
Re: [PATCH v2] riscv: add support for SECCOMP and SECCOMP_FILTER
Hello Shuah,
On Thu, 22 Aug 2019, David Abdurachmanov wrote:
> This patch was extensively tested on Fedora/RISCV (applied by default on
> top of 5.2-rc7 kernel for <2 months). The patch was also tested with 5.3-rc
> on QEMU and SiFive Unleashed board.
>
> libseccomp (userspace) was rebased:
> https://github.com/seccomp/libseccomp/pull/134
>
> Fully passes libseccomp regression testing (simulation and live).
>
> There is one failing kernel selftest: global.user_notification_signal
>
> v1 -> v2:
> - return immediatly if secure_computing(NULL) returns -1
> - fixed whitespace issues
> - add missing seccomp.h
> - remove patch #2 (solved now)
> - add riscv to seccomp kernel selftest
>
> Cc: keesc...@chromium.org
> Cc: m...@carlosedp.com
>
> Signed-off-by: David Abdurachmanov
We'd like to merge this patch through the RISC-V tree.
Care to ack the change to tools/testing/selftests/seccomp/seccomp_bpf.c ?
Kees has already reviewed it:
https://lore.kernel.org/linux-riscv/CAJr-aD=UnCN9E_mdVJ2H5nt=6jurswikzna5hxdlqxxlbsr...@mail.gmail.com/
- Paul
> ---
> arch/riscv/Kconfig| 14 ++
> arch/riscv/include/asm/seccomp.h | 10 +++
> arch/riscv/include/asm/thread_info.h | 5 +++-
> arch/riscv/kernel/entry.S | 27 +--
> arch/riscv/kernel/ptrace.c| 10 +++
> tools/testing/selftests/seccomp/seccomp_bpf.c | 8 +-
> 6 files changed, 70 insertions(+), 4 deletions(-)
> create mode 100644 arch/riscv/include/asm/seccomp.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 59a4727ecd6c..441e63ff5adc 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -31,6 +31,7 @@ config RISCV
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_ATOMIC64 if !64BIT
> select HAVE_ARCH_AUDITSYSCALL
> + select HAVE_ARCH_SECCOMP_FILTER
> select HAVE_MEMBLOCK_NODE_MAP
> select HAVE_DMA_CONTIGUOUS
> select HAVE_FUTEX_CMPXCHG if FUTEX
> @@ -235,6 +236,19 @@ menu "Kernel features"
>
> source "kernel/Kconfig.hz"
>
> +config SECCOMP
> + bool "Enable seccomp to safely compute untrusted bytecode"
> + help
> + This kernel feature is useful for number crunching applications
> + that may need to compute untrusted bytecode during their
> + execution. By using pipes or other transports made available to
> + the process as file descriptors supporting the read/write
> + syscalls, it's possible to isolate those applications in
> + their own address space using seccomp. Once seccomp is
> + enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> + and the task is only allowed to execute a few safe syscalls
> + defined by each seccomp mode.
> +
> endmenu
>
> menu "Boot options"
> diff --git a/arch/riscv/include/asm/seccomp.h
> b/arch/riscv/include/asm/seccomp.h
> new file mode 100644
> index ..bf7744ee3b3d
> --- /dev/null
> +++ b/arch/riscv/include/asm/seccomp.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_SECCOMP_H
> +#define _ASM_SECCOMP_H
> +
> +#include
> +
> +#include
> +
> +#endif /* _ASM_SECCOMP_H */
> diff --git a/arch/riscv/include/asm/thread_info.h
> b/arch/riscv/include/asm/thread_info.h
> index 905372d7eeb8..a0b2a29a0da1 100644
> --- a/arch/riscv/include/asm/thread_info.h
> +++ b/arch/riscv/include/asm/thread_info.h
> @@ -75,6 +75,7 @@ struct thread_info {
> #define TIF_MEMDIE 5 /* is terminating due to OOM killer */
> #define TIF_SYSCALL_TRACEPOINT 6 /* syscall tracepoint
> instrumentation */
> #define TIF_SYSCALL_AUDIT7 /* syscall auditing */
> +#define TIF_SECCOMP 8 /* syscall secure computing */
>
> #define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
> #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
> @@ -82,11 +83,13 @@ struct thread_info {
> #define _TIF_NEED_RESCHED(1 << TIF_NEED_RESCHED)
> #define _TIF_SYSCALL_TRACEPOINT (1 << TIF_SYSCALL_TRACEPOINT)
> #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
> +#define _TIF_SECCOMP (1 << TIF_SECCOMP)
>
> #define _TIF_WORK_MASK \
> (_TIF_NOTIFY_RESUME | _TIF_SIGPENDING | _TIF_NEED_RESCHED)
>
> #define _TIF_SYSCALL_WORK \
> - (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_TRACEPOINT | _TIF_SYSCALL_AUDIT)
> + (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_TRACEPOINT | _TIF_SYSCALL_AUDIT | \
> + _TIF_SECCOMP )
>
> #endif /* _ASM_RISCV_THREAD_INFO_H */
> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
> index bc7a56e1ca6f..0bbedfa3e47d 100644
> --- a/arch/riscv/kernel/entry.S
> +++ b/arch/riscv/kernel/entry.S
> @@ -203,8 +203,25 @@ check_syscall_nr:
> /* Check to make sure we don't jump to a bogus syscall number. */
> li t0, __NR_syscalls
> la s0, sys_ni_syscall
> - /* Syscall number held in a7 */
> - bgeu a7, t0, 1f
> + /*
> + *
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Sat, Oct 05, 2019 at 07:48:45AM +0800, Wei Yang wrote: > On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: > >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: > >> After this change, kernel build test reduces 20% anon_vma allocation. > > > >But does it have any effect on elapsed time or peak memory consumption? > > Do the same kernel build test and record time: > > > Origin > > real 2m50.467s > user 17m52.002s > sys 1m51.953s > > real 2m48.662s > user 17m55.464s > sys 1m50.553s > > real 2m51.143s > user 17m59.687s > sys 1m53.600s > > > Patched > > real 2m43.733s > user 17m25.705s > sys 1m41.791s > > real 2m47.146s > user 17m47.451s > sys 1m43.474s > > real 2m45.763s > user 17m38.230s > sys 1m42.102s > > > For time in sys, it reduced 8.5%. That's compelling!
Re: [PATCH v3 0/3] selftests: netfilter: introduce test cases for ipvs
> On 2019年10月4日, at 下午7:47, Duncan Roe wrote:
>
> On Thu, Oct 03, 2019 at 10:41:06PM +0800, Haishuang Yan wrote:
>>
>>
>>> On 2019??10??2??, at 9:27, Duncan Roe
>>> wrote:
>>>
>>> On Tue, Oct 01, 2019 at 09:34:13PM +0300, Julian Anastasov wrote:
Hello,
On Tue, 1 Oct 2019, Haishuang Yan wrote:
> This series patch include test cases for ipvs.
>
> The test topology is who as below:
> +--+
> | | |
> | ns0 | ns1 |
> | --- | ------|
> | | veth01 | - | veth10 || veth12 ||
> | ---peer ------|
> | | || |
> | --- || |
> | | br0| |- peer |--|
> | --- || |
> | | || |
> | -- peer -- --- |
> | | veth02 | - | veth20 | | veth12 | |
> | -- | -- --- |
> | | ns2 |
> | | |
> +--+
>
> Test results:
> # selftests: netfilter: ipvs.sh
> # Testing DR mode...
> # Testing NAT mode...
> # Testing Tunnel mode...
> # ipvs.sh: PASS
> ok 6 selftests: netfilter: ipvs.sh
>
> Haishuang Yan (3):
> selftests: netfilter: add ipvs test script
> selftests: netfilter: add ipvs nat test case
> selftests: netfilter: add ipvs tunnel test case
Acked-by: Julian Anastasov
> tools/testing/selftests/netfilter/Makefile | 2 +-
> tools/testing/selftests/netfilter/ipvs.sh | 234
> +
> 2 files changed, 235 insertions(+), 1 deletion(-)
> create mode 100755 tools/testing/selftests/netfilter/ipvs.sh
Regards
--
Julian Anastasov
>>>
>>> I still prefer #!/bin/sh in 1/3. You never know what's in someone's
>>> environment
>>>
>>> Cheers ... Duncan.
>>>
>>
>> It??s also my preference too. "_"
>>
>> I have tested both #!/bin/bash and #!/bin/sh script, they all works properly.
>
> Enter these 2 lines:
>> ip(){ return 0; }
>> export -f ip
>
> Now try the #!/bin/bash script. If that now fails, try again with #!/bin/bash
> changed to #!/bin/bash -p
>
> Any better now?
>
> Cheers ... Duncan.
>
It’s better now, thanks for your explanation.
In v3 commit I will use #!/bin/bash -p to prevent exporting function from
environment variables.
Re: Kernel Concurrency Sanitizer (KCSAN)
On 9/20/19 8:54 AM, Will Deacon wrote: > > This one is tricky. What I think we need to avoid is an onslaught of > patches adding READ_ONCE/WRITE_ONCE without a concrete analysis of the > code being modified. My worry is that Joe Developer is eager to get their > first patch into the kernel, so runs this tool and starts spamming > maintainers with these things to the point that they start ignoring KCSAN > reports altogether because of the time they take up. > > I suppose one thing we could do is to require each new READ_ONCE/WRITE_ONCE > to have a comment describing the racy access, a bit like we do for memory > barriers. Another possibility would be to use atomic_t more widely if > there is genuine concurrency involved. > About READ_ONCE() and WRITE_ONCE(), we will probably need ADD_ONCE(var, value) for arches that can implement the RMW in a single instruction. WRITE_ONCE(var, var + value) does not look pretty, and increases register pressure. I had a look at first KCSAN reports, and I can tell that tcp_poll() being lockless means we need to add hundreds of READ_ONCE(), WRITE_ONCE() and ADD_ONCE() all over the places. -> Absolute nightmare for future backports to stable branches.
Re: [PATCH] arm64: dts: rockchip: Fix usb-c on Hugsun X99 TV Box
On Fri, Oct 04, 2019 at 11:45:08PM +0200, Heiko Stuebner wrote:
> Hi Vivek,
>
> Am Montag, 30. September 2019, 01:46:15 CEST schrieb Vivek Unune:
> > On Sun, Sep 29, 2019 at 01:22:17PM +0200, Vicente Bergas wrote:
> > > On Sunday, September 29, 2019 5:22:30 AM CEST, Vivek Unune wrote:
> > > > Fix usb-c on X99 TV Box. Tested with armbian w/ kernel 5.3
> > > >
> > > > Signed-off-by: Vivek Unune
> > > > ---
> > > > arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > > > b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > > > index 0d1f5f9a0de9..c133e8d64b2a 100644
> > > > --- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > > > +++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > > > @@ -644,7 +644,7 @@
> > > > status = "okay";
> > > > u2phy0_host: host-port {
> > > > - phy-supply = <_host>;
> > > > + phy-supply = <_typec>;
> > > > status = "okay";
> > > > };
> > > > @@ -712,7 +712,7 @@
> > > > _dwc3_0 {
> > > > status = "okay";
> > > > - dr_mode = "otg";
> > > > + dr_mode = "host";
> > > > };
> > > > _1 {
> > >
> > > Hi Vivek,
> > >
> > > which is the relationship of your patch and this commit:
> > >
> > > e1d9149e8389f1690cdd4e4056766dd26488a0fe
> > > arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire
> > >
> > > with respect to this other commit:
> > >
> > > c09b73cfac2a9317f1104169045c519c6021aa1d
> > > usb: dwc3: don't set gadget->is_otg flag
> > >
> > > ?
> > >
> > > I did not test reverting e1d9149e since c09b73cf was applied.
> > >
> > > Regards,
> > > Vicenç.
> > >
> >
> > Hi Vicenç,
> >
> > Indeed, I was motivated by e1d9149e ("arm64: dts: rockchip: Fix USB3
> > Type-C on rk3399-sapphire"). X99 TV box showed exact same symptoms
> > with usb-c port. After applying the fix, it worked.
> >
> > I was not aware of c09b73cf ("usb: dwc3: don't set gadget->is_otg
> > flag") and it will be interesting to test it. This might render
> > my fix unecessary.
>
> So I'll let this patch sit here for now.
> Once you've done the testing, can you please respond with the
> result (both positive and negative results please).
>
> Thanks
> Heiko
>
>
Hi Heiko,
I tested the c09b73cf patch without modifying exsisting dts. I can confirm
that that patch doesn't work for me. No usb-c devices were recognized.
Vicenç - were you able to test it?
As soon as I apply dts patch, usb-c devices are recognized.
Thanks,
Vivek
Re: [Patch v2 19/21] media: v4l2-common: add pixel encoding support
Hi Benoit, I love your patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [cannot apply to v5.4-rc1 next-20191004] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Benoit-Parrot/media-vpe-maintenance/20191005-061051 base: git://linuxtv.org/media_tree.git master reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' Error: Cannot open file drivers/dma-buf/reservation.c Error: Cannot open file drivers/dma-buf/reservation.c Error: Cannot open file drivers/dma-buf/reservation.c Error: Cannot open file include/linux/reservation.h Error: Cannot open file include/linux/reservation.h include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:335: warning: Excess function parameter 'dev' description in 'amdgpu_gem_prime_export' drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c:336: warning: Excess function parameter 'dev' description in 'amdgpu_gem_prime_export' drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c:142: warning: Function parameter or member 'blockable' not described in 'amdgpu_mn_read_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:347: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:348: warning: cannot understand function prototype: 'struct amdgpu_vm_pt_cursor ' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:494: warning: Function parameter or member 'start' not described in 'amdgpu_vm_pt_first_dfs' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'adev' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'vm' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'start' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'cursor' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:546: warning: Function parameter or member 'entry' not described in 'for_each_amdgpu_vm_pt_dfs_safe' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:823: warning: Function parameter or member 'level' not described in 'amdgpu_vm_bo_param' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'params' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'bo' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'level' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'pe' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'addr' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'count' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'incr' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1285: warning: Function parameter or member 'flags' not described in 'amdgpu_vm_update_flags' drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:2823: warning: Function parameter or member 'pasid' not described in 'amdgpu_vm_make_compute' drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:378: warning: Excess function parameter 'entry' description in 'amdgpu_irq_dispatch' drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:379: warning: Function parameter or member 'ih' not described in 'amdgpu_irq_dispatch' drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:379: warning: Excess function parameter 'entry' description in 'amdgpu_irq_di
[PATCH] hugetlb: remove unused hstate in hugetlb_fault_mutex_hash()
The first parameter hstate in function hugetlb_fault_mutex_hash() is not
used anymore.
This patch removes it.
Signed-off-by: Wei Yang
Suggested-by: Andrew Morton
---
fs/hugetlbfs/inode.c| 4 ++--
include/linux/hugetlb.h | 4 ++--
mm/hugetlb.c| 12 ++--
mm/userfaultfd.c| 5 +
4 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index a478df035651..715db1e34174 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -440,7 +440,7 @@ static void remove_inode_hugepages(struct inode *inode,
loff_t lstart,
u32 hash;
index = page->index;
- hash = hugetlb_fault_mutex_hash(h, mapping, index, 0);
+ hash = hugetlb_fault_mutex_hash(mapping, index, 0);
mutex_lock(_fault_mutex_table[hash]);
/*
@@ -644,7 +644,7 @@ static long hugetlbfs_fallocate(struct file *file, int
mode, loff_t offset,
addr = index * hpage_size;
/* mutex taken here, fault path and hole punch */
- hash = hugetlb_fault_mutex_hash(h, mapping, index, addr);
+ hash = hugetlb_fault_mutex_hash(mapping, index, addr);
mutex_lock(_fault_mutex_table[hash]);
/* See if already present in mapping to avoid alloc/free */
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 53fc34f930d0..40e9e3fad1cf 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -105,8 +105,8 @@ void move_hugetlb_state(struct page *oldpage, struct page
*newpage, int reason);
void free_huge_page(struct page *page);
void hugetlb_fix_reserve_counts(struct inode *inode);
extern struct mutex *hugetlb_fault_mutex_table;
-u32 hugetlb_fault_mutex_hash(struct hstate *h, struct address_space *mapping,
- pgoff_t idx, unsigned long address);
+u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx,
+ unsigned long address);
pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index ef37c85423a5..e0f033baac9d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3916,7 +3916,7 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
* handling userfault. Reacquire after handling
* fault to make calling code simpler.
*/
- hash = hugetlb_fault_mutex_hash(h, mapping, idx, haddr);
+ hash = hugetlb_fault_mutex_hash(mapping, idx, haddr);
mutex_unlock(_fault_mutex_table[hash]);
ret = handle_userfault(, VM_UFFD_MISSING);
mutex_lock(_fault_mutex_table[hash]);
@@ -4043,8 +4043,8 @@ static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
}
#ifdef CONFIG_SMP
-u32 hugetlb_fault_mutex_hash(struct hstate *h, struct address_space *mapping,
- pgoff_t idx, unsigned long address)
+u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx,
+ unsigned long address)
{
unsigned long key[2];
u32 hash;
@@ -4061,8 +4061,8 @@ u32 hugetlb_fault_mutex_hash(struct hstate *h, struct
address_space *mapping,
* For uniprocesor systems we always use a single mutex, so just
* return 0 and avoid the hashing overhead.
*/
-u32 hugetlb_fault_mutex_hash(struct hstate *h, struct address_space *mapping,
- pgoff_t idx, unsigned long address)
+u32 hugetlb_fault_mutex_hash(struct address_space *mapping, pgoff_t idx,
+ unsigned long address)
{
return 0;
}
@@ -4106,7 +4106,7 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
* get spurious allocation failures if two CPUs race to instantiate
* the same page in the page cache.
*/
- hash = hugetlb_fault_mutex_hash(h, mapping, idx, haddr);
+ hash = hugetlb_fault_mutex_hash(mapping, idx, haddr);
mutex_lock(_fault_mutex_table[hash]);
entry = huge_ptep_get(ptep);
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 0a40746a5b1e..5c0a80626cf0 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -214,7 +214,6 @@ static __always_inline ssize_t
__mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
unsigned long src_addr, dst_addr;
long copied;
struct page *page;
- struct hstate *h;
unsigned long vma_hpagesize;
pgoff_t idx;
u32 hash;
@@ -271,8 +270,6 @@ static __always_inline ssize_t
__mcopy_atomic_hugetlb(struct mm_struct *dst_mm,
goto out_unlock;
}
- h = hstate_vma(dst_vma);
-
while (src_addr < src_start + len) {
pte_t dst_pteval;
@@ -283,7
Re: [PATCH] sched/fair: scale quota and period without losing quota/period ratio precision
On Fri, Oct 4, 2019 at 6:14 AM Phil Auld wrote:
>
> On Thu, Oct 03, 2019 at 07:05:56PM -0700 Xuewei Zhang wrote:
> > +cc neeln...@google.com and hao...@google.com, they helped a lot
> > for this issue. Sorry I forgot to include them when sending out the patch.
> >
> > On Thu, Oct 3, 2019 at 5:55 PM Phil Auld wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Oct 03, 2019 at 05:12:43PM -0700 Xuewei Zhang wrote:
> > > > quota/period ratio is used to ensure a child task group won't get more
> > > > bandwidth than the parent task group, and is calculated as:
> > > > normalized_cfs_quota() = [(quota_us << 20) / period_us]
> > > >
> > > > If the quota/period ratio was changed during this scaling due to
> > > > precision loss, it will cause inconsistency between parent and child
> > > > task groups. See below example:
> > > > A userspace container manager (kubelet) does three operations:
> > > > 1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
> > > > 2) Create a few children cgroups.
> > > > 3) Set quota to 1,000us and period to 10,000us on a child cgroup.
> > > >
> > > > These operations are expected to succeed. However, if the scaling of
> > > > 147/128 happens before step 3), quota and period of the parent cgroup
> > > > will be changed:
> > > > new_quota: 1148437ns, 1148us
> > > > new_period: 11484375ns, 11484us
> > > >
> > > > And when step 3) comes in, the ratio of the child cgroup will be 104857,
> > > > which will be larger than the parent cgroup ratio (104821), and will
> > > > fail.
> > > >
> > > > Scaling them by a factor of 2 will fix the problem.
> > >
> > > I have no issues with the concept. We went around a bit about the actual
> > > numbers and made it an approximation.
> > >
> > > >
> > > > Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop
> > > > to avoid hard lockup")
> > > > Signed-off-by: Xuewei Zhang
> > > > ---
> > > > kernel/sched/fair.c | 36 ++--
> > > > 1 file changed, 22 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > > > index 83ab35e2374f..b3d3d0a231cd 100644
> > > > --- a/kernel/sched/fair.c
> > > > +++ b/kernel/sched/fair.c
> > > > @@ -4926,20 +4926,28 @@ static enum hrtimer_restart
> > > > sched_cfs_period_timer(struct hrtimer *timer)
> > > > if (++count > 3) {
> > > > u64 new, old = ktime_to_ns(cfs_b->period);
> > > >
> > > > - new = (old * 147) / 128; /* ~115% */
> > > > - new = min(new, max_cfs_quota_period);
> > > > -
> > > > - cfs_b->period = ns_to_ktime(new);
> > > > -
> > > > - /* since max is 1s, this is limited to 1e9^2,
> > > > which fits in u64 */
> > > > - cfs_b->quota *= new;
> > > > - cfs_b->quota = div64_u64(cfs_b->quota, old);
> > > > -
> > > > - pr_warn_ratelimited(
> > > > - "cfs_period_timer[cpu%d]: period too short, scaling up (new
> > > > cfs_period_us %lld, cfs_quota_us = %lld)\n",
> > > > - smp_processor_id(),
> > > > - div_u64(new, NSEC_PER_USEC),
> > > > - div_u64(cfs_b->quota, NSEC_PER_USEC));
> > > > + /*
> > > > + * Grow period by a factor of 2 to avoid lossing
> > > > precision.
> > > > + * Precision loss in the quota/period ratio can
> > > > cause __cfs_schedulable
> > > > + * to fail.
> > > > + */
> > > > + new = old * 2;
> > > > + if (new < max_cfs_quota_period) {
> > >
> > > I don't like this part as much. There may be a value between
> > > max_cfs_quota_period/2 and max_cfs_quota_period that would get us out of
> > > the loop. Possibly in practice it won't matter but here you trigger the
> > > warning and take no action to keep it from continuing.
> > >
> > > Also, if you are actually hitting this then you might want to just start
> > > at
> > > a higher but proportional quota and period.
> >
> > I'd like to do what you suggested. A quick idea would be to scale period to
> > max_cfs_quota_period, and scale quota proportionally. However the naive
> > implementation won't work under this edge case:
> > original:
> > quota: 500,000us period: 570,000us
> > after scaling:
> > quota: 877,192us period: 1,000,000us
> > original ratio: 919803
> > new ratio: 919802
> >
> > To do this right, the code would have to keep an eye out on the precision
> > loss,
> > and increase quota by 1us sometimes to cancel out the precision loss.
> >
> > Also, I think this case is not that important. Because if we are
> > hitting this case, that
> > suggests the period is already >0.5s. And if we are still hitting
> > timeouts with a 0.5s
> > period, scaling it to 1s probably won't help much.
> > When this happens, I'd imagine the parent
Re: [PATCH] r8152: Set macpassthru in reset_resume callback
From: Kai-Heng Feng Date: Fri, 4 Oct 2019 20:51:04 +0800 > r8152 may fail to establish network connection after resume from system > suspend. > > If the USB port connects to r8152 lost its power during system suspend, > the MAC address was written before is lost. The reason is that The MAC > address doesn't get written again in its reset_resume callback. > > So let's set MAC address again in reset_resume callback. Also remove > unnecessary lock as no other locking attempt will happen during > reset_resume. > > Signed-off-by: Kai-Heng Feng Applied.
Re: [PATCH] tty: serial: fsl_lpuart: Fix lpuart_flush_buffer()
Hi Andrey,
On Fri, 4 Oct 2019 14:55:37 -0700, Andrey Smirnov
wrote:
> Fix incorrect read-modify-write sequence in lpuart_flush_buffer() that
> was reading from UARTPFIFO and writing to UARTCFIFO instead of
> operating solely on the latter.
>
> Fixes: 9bc19af9dacb ("tty: serial: fsl_lpuart: Flush HW FIFOs in
> .flush_buffer")
> Signed-off-by: Andrey Smirnov
This fixes the TTY on my ZII Devel Boards Rev B and C:
Reported-by: Vivien Didelot
Tested-by: Vivien Didelot
Thank you!
Vivien
Re: [PATCH 4.14 000/185] 4.14.147-stable review
On 10/4/19 11:51 AM, Dan Rue wrote: On Thu, Oct 03, 2019 at 05:51:18PM +0200, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.147 release. There are 185 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. Anything received after that time might be too late. There's a regression listed below that happened while running 'modprobe vivid' on db410c. We've investigated it and are unable to reliably reproduce it. It happens less than 1% of the time, so it is very unlikely to be a regression. The detailed log can be found at https://lkft.validation.linaro.org/scheduler/job/950199#L1545 and we will continue to investigate and try to narrow down the problem so that we can report it coherently. Adding Hans and linux-media to the thread. Hans! I thought you might be interested in looking at this vivid panic. thanks, -- Shuah
Re: [PATCH] nvme: fix uninitialized return of ret when sysfs_create_link fails
This was already fixed and merged (by Dan)
On 10/2/19 5:43 AM, Colin King wrote:
From: Colin Ian King
Currently when the call to sysfs_create_link fails the error exit
path returns an uninitialized value in variable ret. Fix this by
returning the error code returned from the failed call to
sysfs_create_link.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 32fd90c40768 ("nvme: change locking for the per-subsystem controller
list")
Signed-off-by: Colin Ian King
---
drivers/nvme/host/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 63b37d08ac98..f6acbff3e3bc 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2540,8 +2540,9 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl,
struct nvme_id_ctrl *id)
list_add_tail(>entry, _subsystems);
}
- if (sysfs_create_link(>dev.kobj, >device->kobj,
- dev_name(ctrl->device))) {
+ ret = sysfs_create_link(>dev.kobj, >device->kobj,
+ dev_name(ctrl->device));
+ if (ret) {
dev_err(ctrl->device,
"failed to create sysfs link from subsystem.\n");
goto out_put_subsystem;
Re: [PATCH] ARM: dts: am3874-iceboard: Fix 'i2c-mux-idle-disconnect' usage
Hi Andrey,
On 2019-10-03 6:45 p.m., Andrey Smirnov wrote:
> According to
> Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt,
> i2c-mux-idle-disconnect is a property of a parent node since it
> pertains to the mux/switch as a whole, so move it there and drop all
> of the concurrences in child nodes.
>
> Fixes: d031773169df ("ARM: dts: Adds device tree file for McGill's IceBoard,
> based on TI AM3874")
> Signed-off-by: Andrey Smirnov
> Cc: Benoît Cousson
> Cc: Tony Lindgren
> Cc: Graeme Smecher
> Cc: linux-o...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
>
> This is purely a drive-by fix, since it concerns the HW I've never
> heard of before. However I was working with PCA9548
> (vf610-zii-scu4-aib is my HW) and looking at various users in the
> kernel, when this code caught my eye. Apologies for the noise if this
> fix is somehow bogus.
>
> In case that it matters this patch is based on top of 5.4-rc1.
Thanks! We do have I2C address collisions on downstream bus segments, so
keeping these segments isolated is important. I'm surprised this patch
was necessary and happy to see it.
Lightly tested on 5.3.
Tested-by: Graeme Smecher
cheers,
Graeme
pEpkey.asc
Description: application/pgp-keys
Re: [PATCH] .gitattributes: Use 'dts' diff driver for dts files
Quoting Randy Dunlap (2019-10-04 15:08:08) > On 10/4/19 2:23 PM, Stephen Boyd wrote: > > > > diff --git a/.gitattributes b/.gitattributes > > index 89c411b5ce6b..4b32eaa9571e 100644 > > --- a/.gitattributes > > +++ b/.gitattributes > > @@ -1,2 +1,4 @@ > > *.c diff=cpp > > *.h diff=cpp > > +*.dtsi diff=dts > > +*.dts diff=dts > > > > Hm, I have a "cpp" installed but not a "dts". > Where would I find this "dts" so that I can install it? > It's not released yet but it is staged to be in the next release[1]. You can probably build git from source and try it out if you're interested. [1] https://git.kernel.org/pub/scm/git/git.git/commit/?id=d49c2c3466d2c8cb0b3d0a43e6b406b07078fdb1
Re: [PATCH 01/11] iomap: add tracing for the readpage / readpages
On Tue, Oct 01, 2019 at 09:11:42AM +0200, Christoph Hellwig wrote:
> Lift the xfs code for tracing address space operations to the iomap
> layer.
>
> Signed-off-by: Christoph Hellwig
> ---
> fs/iomap/buffered-io.c | 7 +++
> include/trace/events/iomap.h | 27 +++
> 2 files changed, 34 insertions(+)
> create mode 100644 include/trace/events/iomap.h
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e25901ae3ff4..099daf0c09b8 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -19,6 +19,9 @@
>
> #include "../internal.h"
>
> +#define CREATE_TRACE_POINTS
> +#include
> +
> static struct iomap_page *
> iomap_page_create(struct inode *inode, struct page *page)
> {
> @@ -293,6 +296,8 @@ iomap_readpage(struct page *page, const struct iomap_ops
> *ops)
> unsigned poff;
> loff_t ret;
>
> + trace_iomap_readpage(page->mapping->host, 1);
> +
> for (poff = 0; poff < PAGE_SIZE; poff += ret) {
> ret = iomap_apply(inode, page_offset(page) + poff,
> PAGE_SIZE - poff, 0, ops, ,
> @@ -389,6 +394,8 @@ iomap_readpages(struct address_space *mapping, struct
> list_head *pages,
> loff_t last = page_offset(list_entry(pages->next, struct page, lru));
> loff_t length = last - pos + PAGE_SIZE, ret = 0;
>
> + trace_iomap_readpages(mapping->host, nr_pages);
> +
> while (length > 0) {
> ret = iomap_apply(mapping->host, pos, length, 0, ops,
> , iomap_readpages_actor);
> diff --git a/include/trace/events/iomap.h b/include/trace/events/iomap.h
> new file mode 100644
> index ..7d2fe2c773f3
> --- /dev/null
> +++ b/include/trace/events/iomap.h
...and I guess while we're bikeshedding over tracepoints, why not put
this in fs/iomap/trace.h ? Do you anticipate anyone outside of iomap
needing to access the tracepoint declarations?
--D
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2009-2019, Christoph Hellwig
> + * All Rights Reserved.
> + *
> + * NOTE: none of these tracepoints shall be consider a stable kernel ABI
> + * as they can change at any time.
> + */
> +#undef TRACE_SYSTEM
> +#define TRACE_SYSTEM iomap
> +
> +#if !defined(_TRACE_IOMAP_H) || defined(TRACE_HEADER_MULTI_READ)
> +#define _TRACE_IOMAP_H
> +
> +#include
> +
> +#define DEFINE_READPAGE_EVENT(name) \
> +DEFINE_EVENT(iomap_readpage_class, name, \
> + TP_PROTO(struct inode *inode, int nr_pages), \
> + TP_ARGS(inode, nr_pages))
> +DEFINE_READPAGE_EVENT(iomap_readpage);
> +DEFINE_READPAGE_EVENT(iomap_readpages);
> +
> +#endif /* _TRACE_IOMAP_H */
> +
> +/* This part must be outside protection */
> +#include
> --
> 2.20.1
>
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Fri, Oct 04, 2019 at 07:45:26PM -0400, Rik van Riel wrote:
>On Sat, 2019-10-05 at 00:06 +0800, Wei Yang wrote:
>> In function __anon_vma_prepare(), we will try to find anon_vma if it
>> is
>> possible to reuse it. While on fork, the logic is different.
>>
>> Since commit 5beb49305251 ("mm: change anon_vma linking to fix
>> multi-process server scalability issue"), function anon_vma_clone()
>> tries to allocate new anon_vma for child process. But the logic here
>> will allocate a new anon_vma for each vma, even in parent this vma
>> is mergeable and share the same anon_vma with its sibling. This may
>> do
>> better for scalability issue, while it is not necessary to do so
>> especially after interval tree is used.
>>
>> Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma
>> hierarchy")
>> tries to reuse some anon_vma by counting child anon_vma and attached
>> vmas. While for those mergeable anon_vmas, we can just reuse it and
>> not
>> necessary to go through the logic.
>>
>> After this change, kernel build test reduces 20% anon_vma allocation.
>>
>> Signed-off-by: Wei Yang
>
>Acked-by: Rik van Riel
>
Thanks
>--
>All Rights Reversed.
--
Wei Yang
Help you, Help me
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: >> After this change, kernel build test reduces 20% anon_vma allocation. > >But does it have any effect on elapsed time or peak memory consumption? Do the same kernel build test and record time: Origin real2m50.467s user17m52.002s sys 1m51.953s real2m48.662s user17m55.464s sys 1m50.553s real2m51.143s user17m59.687s sys 1m53.600s Patched real2m43.733s user17m25.705s sys 1m41.791s real2m47.146s user17m47.451s sys 1m43.474s real2m45.763s user17m38.230s sys 1m42.102s For time in sys, it reduced 8.5%. -- Wei Yang Help you, Help me
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Sat, 2019-10-05 at 00:06 +0800, Wei Yang wrote:
> In function __anon_vma_prepare(), we will try to find anon_vma if it
> is
> possible to reuse it. While on fork, the logic is different.
>
> Since commit 5beb49305251 ("mm: change anon_vma linking to fix
> multi-process server scalability issue"), function anon_vma_clone()
> tries to allocate new anon_vma for child process. But the logic here
> will allocate a new anon_vma for each vma, even in parent this vma
> is mergeable and share the same anon_vma with its sibling. This may
> do
> better for scalability issue, while it is not necessary to do so
> especially after interval tree is used.
>
> Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma
> hierarchy")
> tries to reuse some anon_vma by counting child anon_vma and attached
> vmas. While for those mergeable anon_vmas, we can just reuse it and
> not
> necessary to go through the logic.
>
> After this change, kernel build test reduces 20% anon_vma allocation.
>
> Signed-off-by: Wei Yang
Acked-by: Rik van Riel
--
All Rights Reversed.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] fs/userfaultfd.c: simplify the calculation of new_flags
On Fri, Oct 04, 2019 at 07:28:34PM -0400, Andrea Arcangeli wrote: >On Sat, Oct 05, 2019 at 06:46:40AM +0800, Wei Yang wrote: >> On Wed, Oct 02, 2019 at 08:45:05PM -0400, Andrea Arcangeli wrote: >> >Hello, >> > >> >On Tue, Aug 06, 2019 at 01:38:59PM +0800, Wei Yang wrote: >> >> Finally new_flags equals old vm_flags *OR* vm_flags. >> >> >> >> It is not necessary to mask them first. >> >> >> >> Signed-off-by: Wei Yang >> >> --- >> >> fs/userfaultfd.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c >> >> index ccbdbd62f0d8..653d8f7c453c 100644 >> >> --- a/fs/userfaultfd.c >> >> +++ b/fs/userfaultfd.c >> >> @@ -1457,7 +1457,7 @@ static int userfaultfd_register(struct >> >> userfaultfd_ctx *ctx, >> >> start = vma->vm_start; >> >> vma_end = min(end, vma->vm_end); >> >> >> >> - new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; >> >> + new_flags = vma->vm_flags | vm_flags; >> >> prev = vma_merge(mm, prev, start, vma_end, new_flags, >> >>vma->anon_vma, vma->vm_file, vma->vm_pgoff, >> >>vma_policy(vma), >> > >> >And then how do you clear the flags after the above? >> > >> >It must be possible to clear the flags (from >> >UFFDIO_REGISTER_MODE_MISSING|UFFDIO_REGISTER_MODE_WP to only one set >> >or invert). >> > >> >We have no WP support upstream yet, so maybe that's why it looks >> >superfluous in practice, but in theory it isn't because it would then >> >need to be reversed by Peter's (CC'ed) -wp patchset. >> > >> >The register code has already the right placeholder to support -wp and >> >so it's better not to break them. >> > >> >I would recommend reviewing the uffd-wp support and working on testing >> >the uffd-wp code instead of changing the above. >> > >> >> Sorry, I don't get your point. This change is valid to me even from >> arithmetic >> point of view. >> >> vm_flags == VM_UFFD_MISSING | VM_UFFD_WP >> >> The effect of current code is clear these two bits then add them. This equals >> to just add these two bits. >> >> I am not sure which part I lost. > >The cleaned removed the "& ~" and that was enough to quickly tell the >cleaned up version was wrong. > >What I should have noticed right away as well is that the code was >already wrong, sorry. That code doesn't require a noop code cleanup, >it requires a fix and the "& ~" needs to stay. > >This isn't going to make any difference upstream until the uffd-wp >support is merged so it is enough to queue it in Peter's queue, or you >can merge it independently. > ok, I get your point. >Thanks, >Andrea > >>From a0f17bef184c6bb9b99294f202eefb50b6eb43cd Mon Sep 17 00:00:00 2001 >From: Andrea Arcangeli >Date: Fri, 4 Oct 2019 19:09:59 -0400 >Subject: [PATCH 1/1] uffd: wp: clear VM_UFFD_MISSING or VM_UFFD_WP during > userfaultfd_register() > >If the registration is repeated without VM_UFFD_MISSING or VM_UFFD_WP >they need to be cleared. Currently setting UFFDIO_REGISTER_MODE_WP >returns -EINVAL, so this patch is a noop until the >UFFDIO_REGISTER_MODE_WP support is applied. > >Reported-by: Wei Yang >Signed-off-by: Andrea Arcangeli Reviewed-by: Wei Yang >--- > fs/userfaultfd.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c >index fe6d804a38dc..97596bb65dd5 100644 >--- a/fs/userfaultfd.c >+++ b/fs/userfaultfd.c >@@ -1458,7 +1458,8 @@ static int userfaultfd_register(struct userfaultfd_ctx >*ctx, > start = vma->vm_start; > vma_end = min(end, vma->vm_end); > >- new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; >+ new_flags = (vma->vm_flags & >+ ~(VM_UFFD_MISSING|VM_UFFD_WP)) | vm_flags; > prev = vma_merge(mm, prev, start, vma_end, new_flags, >vma->anon_vma, vma->vm_file, vma->vm_pgoff, >vma_policy(vma), -- Wei Yang Help you, Help me
[RFC PATCH] e1000e: Use rtnl_lock to prevent race conditions between net and pci/pm
From: Alexander Duyck
This patch is meant to address possible race conditions that can exist
between network configuration and power management. A similar issue was
fixed for igb in commit 9474933caf21 ("igb: close/suspend race in
netif_device_detach").
In addition it consolidates the code so that the PCI error handling code
will essentially perform the power management freeze on the device prior to
attempting a reset, and will thaw the device afterwards if that is what it
is planning to do. Otherwise when we call close on the interface it should
see it is detached and not attempt to call the logic to down the interface
and free the IRQs again.
>From what I can tell the check that was adding the check for __E1000_DOWN
in e1000e_close was added when runtime power management was added. However
it should not be relevant for us as we perform a call to
pm_runtime_get_sync before we call e1000_down/free_irq so it should always
be back up before we call into this anyway.
Signed-off-by: Alexander Duyck
---
I'm putting this out as an RFC for now. I haven't had a chance to do much
testing yet, but I have verified no build issues, and the driver appears
to load, link, and pass traffic without problems.
This should address issues seen with either double freeing or never freeing
IRQs that have been seen on this and similar drivers in the past.
I'll submit this formally after testing it over the weekend assuming there
are no issues.
drivers/net/ethernet/intel/e1000e/netdev.c | 33 ++--
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index d7d56e42a6aa..182a2c8f12d8 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -4715,12 +4715,12 @@ int e1000e_close(struct net_device *netdev)
pm_runtime_get_sync(>dev);
- if (!test_bit(__E1000_DOWN, >state)) {
+ if (netif_device_present(netdev)) {
e1000e_down(adapter, true);
e1000_free_irq(adapter);
/* Link status message must follow this format */
- pr_info("%s NIC Link is Down\n", adapter->netdev->name);
+ pr_info("%s NIC Link is Down\n", netdev->name);
}
napi_disable(>napi);
@@ -6299,6 +6299,7 @@ static int e1000e_pm_freeze(struct device *dev)
struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ rtnl_lock();
netif_device_detach(netdev);
if (netif_running(netdev)) {
@@ -6313,6 +6314,8 @@ static int e1000e_pm_freeze(struct device *dev)
e1000e_down(adapter, false);
e1000_free_irq(adapter);
}
+ rtnl_unlock();
+
e1000e_reset_interrupt_capability(adapter);
/* Allow time for pending master requests to run */
@@ -6626,27 +6629,30 @@ static int __e1000_resume(struct pci_dev *pdev)
return 0;
}
-#ifdef CONFIG_PM_SLEEP
static int e1000e_pm_thaw(struct device *dev)
{
struct net_device *netdev = dev_get_drvdata(dev);
struct e1000_adapter *adapter = netdev_priv(netdev);
+ int rc = 0;
e1000e_set_interrupt_capability(adapter);
- if (netif_running(netdev)) {
- u32 err = e1000_request_irq(adapter);
- if (err)
- return err;
+ rtnl_lock();
+ if (netif_running(netdev)) {
+ rc = e1000_request_irq(adapter);
+ if (rc)
+ goto err_irq;
e1000e_up(adapter);
}
netif_device_attach(netdev);
-
- return 0;
+ rtnl_unlock();
+err_irq:
+ return rc;
}
+#ifdef CONFIG_PM_SLEEP
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
@@ -6821,13 +6827,11 @@ static pci_ers_result_t e1000_io_error_detected(struct
pci_dev *pdev,
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
- netif_device_detach(netdev);
+ e1000e_pm_freeze(>dev);
if (state == pci_channel_io_perm_failure)
return PCI_ERS_RESULT_DISCONNECT;
- if (netif_running(netdev))
- e1000e_down(adapter, true);
pci_disable_device(pdev);
/* Request a slot slot reset. */
@@ -6893,10 +6897,7 @@ static void e1000_io_resume(struct pci_dev *pdev)
e1000_init_manageability_pt(adapter);
- if (netif_running(netdev))
- e1000e_up(adapter);
-
- netif_device_attach(netdev);
+ e1000e_pm_thaw(>dev);
/* If the controller has AMT, do not set DRV_LOAD until the interface
* is up. For all other cases, let the f/w know that the h/w is now
Re: [PATCH 08/16] KVM: VMX: Check for full VMX support when verifying CPU compatibility
On Fri, Oct 4, 2019 at 2:56 PM Sean Christopherson wrote: > > Explicitly check the current CPU's VMX feature flag when verifying > compatibility across physical CPUs. This effectively adds a check on > IA32_FEATURE_CONTROL to ensure that VMX is fully enabled on all CPUs. > > Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson
[PATCH] soc: qcom: llcc: Name regmaps to avoid collisions
We'll end up with debugfs collisions if we don't give names to the
regmaps created inside this driver. Copy the template config over into
this function and give the regmap the same name as the resource name.
Fixes: 7f9c136216c7 ("soc: qcom: Add broadcast base for Last Level Cache
Controller (LLCC)")
Cc: Venkata Narendra Kumar Gutta
Cc: Evan Green
Signed-off-by: Stephen Boyd
---
drivers/soc/qcom/llcc-slice.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/qcom/llcc-slice.c b/drivers/soc/qcom/llcc-slice.c
index 9090ea12eaf3..aa342938c403 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -48,13 +48,6 @@
static struct llcc_drv_data *drv_data = (void *) -EPROBE_DEFER;
-static const struct regmap_config llcc_regmap_config = {
- .reg_bits = 32,
- .reg_stride = 4,
- .val_bits = 32,
- .fast_io = true,
-};
-
/**
* llcc_slice_getd - get llcc slice descriptor
* @uid: usecase_id for the client
@@ -314,6 +307,12 @@ static struct regmap *qcom_llcc_init_mmio(struct
platform_device *pdev,
{
struct resource *res;
void __iomem *base;
+ static struct regmap_config llcc_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .fast_io = true,
+ };
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
if (!res)
@@ -323,6 +322,7 @@ static struct regmap *qcom_llcc_init_mmio(struct
platform_device *pdev,
if (IS_ERR(base))
return ERR_CAST(base);
+ llcc_regmap_config.name = name;
return devm_regmap_init_mmio(>dev, base, _regmap_config);
}
--
Sent by a computer through tubes
Re: [PATCH] fs/userfaultfd.c: simplify the calculation of new_flags
On Sat, Oct 05, 2019 at 06:46:40AM +0800, Wei Yang wrote: > On Wed, Oct 02, 2019 at 08:45:05PM -0400, Andrea Arcangeli wrote: > >Hello, > > > >On Tue, Aug 06, 2019 at 01:38:59PM +0800, Wei Yang wrote: > >> Finally new_flags equals old vm_flags *OR* vm_flags. > >> > >> It is not necessary to mask them first. > >> > >> Signed-off-by: Wei Yang > >> --- > >> fs/userfaultfd.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > >> index ccbdbd62f0d8..653d8f7c453c 100644 > >> --- a/fs/userfaultfd.c > >> +++ b/fs/userfaultfd.c > >> @@ -1457,7 +1457,7 @@ static int userfaultfd_register(struct > >> userfaultfd_ctx *ctx, > >>start = vma->vm_start; > >>vma_end = min(end, vma->vm_end); > >> > >> - new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; > >> + new_flags = vma->vm_flags | vm_flags; > >>prev = vma_merge(mm, prev, start, vma_end, new_flags, > >> vma->anon_vma, vma->vm_file, vma->vm_pgoff, > >> vma_policy(vma), > > > >And then how do you clear the flags after the above? > > > >It must be possible to clear the flags (from > >UFFDIO_REGISTER_MODE_MISSING|UFFDIO_REGISTER_MODE_WP to only one set > >or invert). > > > >We have no WP support upstream yet, so maybe that's why it looks > >superfluous in practice, but in theory it isn't because it would then > >need to be reversed by Peter's (CC'ed) -wp patchset. > > > >The register code has already the right placeholder to support -wp and > >so it's better not to break them. > > > >I would recommend reviewing the uffd-wp support and working on testing > >the uffd-wp code instead of changing the above. > > > > Sorry, I don't get your point. This change is valid to me even from arithmetic > point of view. > > vm_flags == VM_UFFD_MISSING | VM_UFFD_WP > > The effect of current code is clear these two bits then add them. This equals > to just add these two bits. > > I am not sure which part I lost. The cleaned removed the "& ~" and that was enough to quickly tell the cleaned up version was wrong. What I should have noticed right away as well is that the code was already wrong, sorry. That code doesn't require a noop code cleanup, it requires a fix and the "& ~" needs to stay. This isn't going to make any difference upstream until the uffd-wp support is merged so it is enough to queue it in Peter's queue, or you can merge it independently. Thanks, Andrea >From a0f17bef184c6bb9b99294f202eefb50b6eb43cd Mon Sep 17 00:00:00 2001 From: Andrea Arcangeli Date: Fri, 4 Oct 2019 19:09:59 -0400 Subject: [PATCH 1/1] uffd: wp: clear VM_UFFD_MISSING or VM_UFFD_WP during userfaultfd_register() If the registration is repeated without VM_UFFD_MISSING or VM_UFFD_WP they need to be cleared. Currently setting UFFDIO_REGISTER_MODE_WP returns -EINVAL, so this patch is a noop until the UFFDIO_REGISTER_MODE_WP support is applied. Reported-by: Wei Yang Signed-off-by: Andrea Arcangeli --- fs/userfaultfd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index fe6d804a38dc..97596bb65dd5 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1458,7 +1458,8 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, start = vma->vm_start; vma_end = min(end, vma->vm_end); - new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; + new_flags = (vma->vm_flags & +~(VM_UFFD_MISSING|VM_UFFD_WP)) | vm_flags; prev = vma_merge(mm, prev, start, vma_end, new_flags, vma->anon_vma, vma->vm_file, vma->vm_pgoff, vma_policy(vma),
Re: [PATCH 07/16] KVM: VMX: Use VMX feature flag to query BIOS enabling
On Fri, Oct 4, 2019 at 2:56 PM Sean Christopherson wrote: > > Replace KVM's manual checks on IA32_FEATURE_CONTROL with a query on the > boot CPU's VMX feature flag. The VMX flag is now cleared during boot if > VMX isn't fully enabled via IA32_FEATURE_CONTROL, including the case > where IA32_FEATURE_CONTROL isn't supported. > > Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson
Re: [PATCH 05/16] KVM: VMX: Drop initialization of IA32_FEATURE_CONTROL MSR
On Fri, Oct 4, 2019 at 2:56 PM Sean Christopherson wrote: > > Remove the code to initialize IA32_FEATURE_CONTROL MSR when KVM is > loaded now that the MSR is initialized during boot on all CPUs that > support VMX, i.e. can possibly load kvm_intel. > > Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson
Re: [PATCH] rculist: Describe variadic macro argument in a Sphinx-compatible way
On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote: > On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote: > > Without this patch, Sphinx shows "variable arguments" as the description > > of the cond argument, rather than the intended description, and prints > > the following warnings: > > > > ./include/linux/rculist.h:374: warning: Excess function parameter 'cond' > > description in 'list_for_each_entry_rcu' > > ./include/linux/rculist.h:651: warning: Excess function parameter 'cond' > > description in 'hlist_for_each_entry_rcu' Hmm, small detail that I didn't realize before: It's actually the kernel-doc script, not Sphinx, that can't deal with variadic macro arguments and thus requires this patch. So it may also be possible to fix the script instead. (I have not looked into how much work that would be.) Thanks, Jonathan Neuschäfer signature.asc Description: PGP signature
Re: [PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
Quoting Taniya Das (2019-10-04 10:39:31) > Hi Stephen, > > On 10/3/2019 9:31 PM, Stephen Boyd wrote: > > Quoting Taniya Das (2019-10-03 03:31:15) > >> Hi Stephen, > >> > >> On 10/1/2019 8:08 PM, Stephen Boyd wrote: > >>> > >>> Why do you want to keep them critical and registered? I'm suggesting > >>> that any clk that is marked critical and doesn't have a parent should > >>> instead become a register write in probe to turn the clk on. > >>> > >> Sure, let me do a one-time enable from probe for the clocks which > >> doesn't have a parent. > >> But I would now have to educate the clients of these clocks to remove > >> using them. > >> > > > > If anyone is using these clks we can return NULL from the provider for > > the specifier so that we indicate there isn't support for them in the > > kernel. At least I hope that code path still works given all the recent > > changes to clk_get(). > > > > Could you please confirm if you are referring to update the below? I wasn't suggesting that explicitly but sure. Something like this would be necessary to make clk_get() pass back a NULL pointer to the caller. Does everything keep working with this change?
[PATCH 2/3] net: phy: fixed_phy: fix use-after-free when checking link GPIO
If we fail to locate GPIO for any reason other than deferral or
not-found-GPIO, we try to print device tree node info, however if might
be freed already as we called of_node_put() on it.
Signed-off-by: Dmitry Torokhov
---
drivers/net/phy/fixed_phy.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 7c5265fd2b94..4190f9ed5313 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -212,16 +212,13 @@ static struct gpio_desc *fixed_phy_get_gpiod(struct
device_node *np)
*/
gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
GPIOD_IN, "mdio");
- of_node_put(fixed_link_node);
- if (IS_ERR(gpiod)) {
- if (PTR_ERR(gpiod) == -EPROBE_DEFER)
- return gpiod;
-
+ if (IS_ERR(gpiod) && PTR_ERR(gpiod) != -EPROBE_DEFER) {
if (PTR_ERR(gpiod) != -ENOENT)
pr_err("error getting GPIO for fixed link %pOF, proceed
without\n",
fixed_link_node);
gpiod = NULL;
}
+ of_node_put(fixed_link_node);
return gpiod;
}
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 3/3] net: phy: fixed_phy: switch to using fwnode_gpiod_get_index
gpiod_get_from_of_node() is being retired in favor of
[devm_]fwnode_gpiod_get_index(), that behaves similar to
[devm_]gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov
---
drivers/net/phy/fixed_phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 4190f9ed5313..73a72ff0fb16 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -210,8 +210,8 @@ static struct gpio_desc *fixed_phy_get_gpiod(struct
device_node *np)
* Linux device associated with it, we simply have obtain
* the GPIO descriptor from the device tree like this.
*/
- gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
- GPIOD_IN, "mdio");
+ gpiod = fwnode_gpiod_get_index(of_fwnode_handle(fixed_link_node),
+ "link-gpios", 0, GPIOD_IN, "mdio");
if (IS_ERR(gpiod) && PTR_ERR(gpiod) != -EPROBE_DEFER) {
if (PTR_ERR(gpiod) != -ENOENT)
pr_err("error getting GPIO for fixed link %pOF, proceed
without\n",
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 0/3] net: phy: switch to using fwnode_gpiod_get_index
This series switches phy drivers form using fwnode_get_named_gpiod() and gpiod_get_from_of_node() that are scheduled to be removed in favor of fwnode_gpiod_get_index() that behaves more like standard gpiod_get_index() and will potentially handle secondary software nodes in cases we need to augment platform firmware. This depends on the new code that can be bound in ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree: git pull git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git ib-fwnode-gpiod-get-index I hope that it would be possible to pull in this immutable branch and not wait until after 5.5 merge window. Dmitry Torokhov (3): net: phylink: switch to using fwnode_gpiod_get_index() net: phy: fixed_phy: fix use-after-free when checking link GPIO net: phy: fixed_phy: switch to using fwnode_gpiod_get_index drivers/net/phy/fixed_phy.c | 11 --- drivers/net/phy/phylink.c | 4 ++-- 2 files changed, 6 insertions(+), 9 deletions(-) -- 2.23.0.581.g78d2f28ef7-goog
[PATCH 1/3] net: phylink: switch to using fwnode_gpiod_get_index()
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but
works with arbitrary firmware node.
Reviewed-by: Andy Shevchenko
Signed-off-by: Dmitry Torokhov
---
drivers/net/phy/phylink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index a5a57ca94c1a..c34ca644d47e 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -168,8 +168,8 @@ static int phylink_parse_fixedlink(struct phylink *pl,
pl->link_config.pause |= MLO_PAUSE_ASYM;
if (ret == 0) {
- desc = fwnode_get_named_gpiod(fixed_node, "link-gpios",
- 0, GPIOD_IN, "?");
+ desc = fwnode_gpiod_get_index(fixed_node, "link", 0,
+ GPIOD_IN, "?");
if (!IS_ERR(desc))
pl->link_gpio = desc;
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 5/7] regulator: da9211: switch to using devm_fwnode_gpiod_get
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov --- drivers/regulator/da9211-regulator.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/regulator/da9211-regulator.c b/drivers/regulator/da9211-regulator.c index bf80748f1ccc..523dc1b95826 100644 --- a/drivers/regulator/da9211-regulator.c +++ b/drivers/regulator/da9211-regulator.c @@ -283,12 +283,12 @@ static struct da9211_pdata *da9211_parse_regulators_dt( pdata->init_data[n] = da9211_matches[i].init_data; pdata->reg_node[n] = da9211_matches[i].of_node; - pdata->gpiod_ren[n] = devm_gpiod_get_from_of_node(dev, - da9211_matches[i].of_node, - "enable-gpios", - 0, - GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE, - "da9211-enable"); + pdata->gpiod_ren[n] = devm_fwnode_gpiod_get(dev, + of_fwnode_handle(pdata->reg_node[n]), + "enable", + GPIOD_OUT_HIGH | + GPIOD_FLAGS_BIT_NONEXCLUSIVE, + "da9211-enable"); if (IS_ERR(pdata->gpiod_ren[n])) pdata->gpiod_ren[n] = NULL; n++; -- 2.23.0.581.g78d2f28ef7-goog
[PATCH 6/7] regulator: tps65132: switch to using devm_fwnode_gpiod_get()
devm_fwnode_get_index_gpiod_from_child() is going away as the name is
too unwieldy, let's switch to using the new devm_fwnode_gpiod_get().
Note that we no longer need to check for NULL as devm_fwnode_gpiod_get()
will return -ENOENT if GPIO is missing.
Signed-off-by: Dmitry Torokhov
---
drivers/regulator/tps65132-regulator.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/tps65132-regulator.c
b/drivers/regulator/tps65132-regulator.c
index e302bd01a084..7b0e38f8d627 100644
--- a/drivers/regulator/tps65132-regulator.c
+++ b/drivers/regulator/tps65132-regulator.c
@@ -136,9 +136,10 @@ static int tps65132_of_parse_cb(struct device_node *np,
struct tps65132_reg_pdata *rpdata = >reg_pdata[desc->id];
int ret;
- rpdata->en_gpiod = devm_fwnode_get_index_gpiod_from_child(tps->dev,
- "enable", 0, >fwnode, 0, "enable");
- if (IS_ERR_OR_NULL(rpdata->en_gpiod)) {
+ rpdata->en_gpiod = devm_fwnode_gpiod_get(tps->dev, of_fwnode_handle(np),
+"enable", GPIOD_ASIS,
+"enable");
+ if (IS_ERR(rpdata->en_gpiod)) {
ret = PTR_ERR(rpdata->en_gpiod);
/* Ignore the error other than probe defer */
@@ -147,10 +148,12 @@ static int tps65132_of_parse_cb(struct device_node *np,
return 0;
}
- rpdata->act_dis_gpiod = devm_fwnode_get_index_gpiod_from_child(
- tps->dev, "active-discharge", 0,
- >fwnode, 0, "active-discharge");
- if (IS_ERR_OR_NULL(rpdata->act_dis_gpiod)) {
+ rpdata->act_dis_gpiod = devm_fwnode_gpiod_get(tps->dev,
+ of_fwnode_handle(np),
+ "active-discharge",
+ GPIOD_ASIS,
+ "active-discharge");
+ if (IS_ERR(rpdata->act_dis_gpiod)) {
ret = PTR_ERR(rpdata->act_dis_gpiod);
/* Ignore the error other than probe defer */
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 4/7] regulator: s2mps11: switch to using devm_fwnode_gpiod_get
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov --- drivers/regulator/s2mps11.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c index 5bc00884cf51..4f2dc5ebffdc 100644 --- a/drivers/regulator/s2mps11.c +++ b/drivers/regulator/s2mps11.c @@ -844,10 +844,9 @@ static void s2mps14_pmic_dt_parse_ext_control_gpio(struct platform_device *pdev, if (!rdata[reg].init_data || !rdata[reg].of_node) continue; - gpio[reg] = devm_gpiod_get_from_of_node(>dev, - rdata[reg].of_node, - "samsung,ext-control-gpios", - 0, + gpio[reg] = devm_fwnode_gpiod_get(>dev, + of_fwnode_handle(rdata[reg].of_node), + "samsung,ext-control", GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE, "s2mps11-regulator"); if (PTR_ERR(gpio[reg]) == -ENOENT) -- 2.23.0.581.g78d2f28ef7-goog
[PATCH 3/7] regulator: tps65090: switch to using devm_fwnode_gpiod_get
devm_gpiod_get_from_of_node() is being retired in favor of
devm_fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Signed-off-by: Dmitry Torokhov
---
drivers/regulator/tps65090-regulator.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/tps65090-regulator.c
b/drivers/regulator/tps65090-regulator.c
index 10ea4b5a0f55..f0b660e9f15f 100644
--- a/drivers/regulator/tps65090-regulator.c
+++ b/drivers/regulator/tps65090-regulator.c
@@ -346,16 +346,20 @@ static struct tps65090_platform_data
*tps65090_parse_dt_reg_data(
for (idx = 0; idx < ARRAY_SIZE(tps65090_matches); idx++) {
struct regulator_init_data *ri_data;
struct tps65090_regulator_plat_data *rpdata;
+ struct device_node *np;
rpdata = _pdata[idx];
ri_data = tps65090_matches[idx].init_data;
- if (!ri_data || !tps65090_matches[idx].of_node)
+ if (!ri_data)
+ continue;
+
+ np = tps65090_matches[idx].of_node;
+ if (!np)
continue;
rpdata->reg_init_data = ri_data;
- rpdata->enable_ext_control = of_property_read_bool(
- tps65090_matches[idx].of_node,
- "ti,enable-ext-control");
+ rpdata->enable_ext_control = of_property_read_bool(np,
+ "ti,enable-ext-control");
if (rpdata->enable_ext_control) {
enum gpiod_flags gflags;
@@ -366,11 +370,12 @@ static struct tps65090_platform_data
*tps65090_parse_dt_reg_data(
gflags = GPIOD_OUT_LOW;
gflags |= GPIOD_FLAGS_BIT_NONEXCLUSIVE;
- rpdata->gpiod = devm_gpiod_get_from_of_node(>dev,
-
tps65090_matches[idx].of_node,
-
"dcdc-ext-control-gpios", 0,
- gflags,
- "tps65090");
+ rpdata->gpiod = devm_fwnode_gpiod_get(
+ >dev,
+ of_fwnode_handle(np),
+ "dcdc-ext-control",
+ gflags,
+ "tps65090");
if (PTR_ERR(rpdata->gpiod) == -ENOENT) {
dev_err(>dev,
"could not find DCDC external control
GPIO\n");
@@ -379,8 +384,7 @@ static struct tps65090_platform_data
*tps65090_parse_dt_reg_data(
return ERR_CAST(rpdata->gpiod);
}
- if (of_property_read_u32(tps65090_matches[idx].of_node,
-"ti,overcurrent-wait",
+ if (of_property_read_u32(np, "ti,overcurrent-wait",
>overcurrent_wait) == 0)
rpdata->overcurrent_wait_valid = true;
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 0/7] regulator: switch to using [devm_]fwnode_gpiod_get_index
This series swiches regulator drivers form using [devm_]gpiod_get_from_of_node() that is scheduled to be removed in favor of [devm_]fwnode_gpiod_get_index() that behaves more like standard [devm_]gpiod_get_index() and will potentially handle secondary software nodes in cases we need to augment platform firmware. This depends on the new code that can be found in ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree: git pull git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git ib-fwnode-gpiod-get-index I hope that it would be possible to pull in this immutable branch and not wait until after 5.5 merge window. Thanks! Dmitry Torokhov (7): regulator: s5m8767: switch to using devm_fwnode_gpiod_get regulator: slg51000: switch to using fwnode_gpiod_get_index regulator: tps65090: switch to using devm_fwnode_gpiod_get regulator: s2mps11: switch to using devm_fwnode_gpiod_get regulator: da9211: switch to using devm_fwnode_gpiod_get regulator: tps65132: switch to using devm_fwnode_gpiod_get() regulator: max77686: switch to using fwnode_gpiod_get_index drivers/regulator/da9211-regulator.c | 12 ++-- drivers/regulator/max77686-regulator.c | 5 +++-- drivers/regulator/s2mps11.c| 7 +++ drivers/regulator/s5m8767.c| 7 +++ drivers/regulator/slg51000-regulator.c | 13 + drivers/regulator/tps65090-regulator.c | 26 +++--- drivers/regulator/tps65132-regulator.c | 17 ++--- 7 files changed, 45 insertions(+), 42 deletions(-) -- 2.23.0.581.g78d2f28ef7-goog
[PATCH 2/7] regulator: slg51000: switch to using fwnode_gpiod_get_index
devm_gpiod_get_from_of_node() is being retired in favor of
[devm_]fwnode_gpiod_get_index(), that behaves similar to
devm_gpiod_get_index(), but can work with arbitrary firmware node. It
will also be able to support secondary software nodes.
Let's switch this driver over.
Note that now that we have a good non-devm API for getting GPIO from
arbitrary firmware node, there is no reason to use devm API here as
regulator core takes care of managing lifetime of "enable" GPIO and we
were immediately detaching requested GPIO from devm anyway.
Signed-off-by: Dmitry Torokhov
---
drivers/regulator/slg51000-regulator.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/slg51000-regulator.c
b/drivers/regulator/slg51000-regulator.c
index a0565daecace..bf1a3508ebc4 100644
--- a/drivers/regulator/slg51000-regulator.c
+++ b/drivers/regulator/slg51000-regulator.c
@@ -198,17 +198,14 @@ static int slg51000_of_parse_cb(struct device_node *np,
const struct regulator_desc *desc,
struct regulator_config *config)
{
- struct slg51000 *chip = config->driver_data;
struct gpio_desc *ena_gpiod;
- enum gpiod_flags gflags = GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE;
- ena_gpiod = devm_gpiod_get_from_of_node(chip->dev, np,
- "enable-gpios", 0,
- gflags, "gpio-en-ldo");
- if (!IS_ERR(ena_gpiod)) {
+ ena_gpiod = fwnode_gpiod_get_index(of_fwnode_handle(np), "enable", 0,
+ GPIOD_OUT_LOW |
+ GPIOD_FLAGS_BIT_NONEXCLUSIVE,
+ "gpio-en-ldo");
+ if (!IS_ERR(ena_gpiod))
config->ena_gpiod = ena_gpiod;
- devm_gpiod_unhinge(chip->dev, config->ena_gpiod);
- }
return 0;
}
--
2.23.0.581.g78d2f28ef7-goog
[PATCH 7/7] regulator: max77686: switch to using fwnode_gpiod_get_index
gpiod_get_from_of_node() is being retired in favor of fwnode_gpiod_get_index(), that behaves similar to gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov --- drivers/regulator/max77686-regulator.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/max77686-regulator.c b/drivers/regulator/max77686-regulator.c index c8e579e99316..9089ec608fcc 100644 --- a/drivers/regulator/max77686-regulator.c +++ b/drivers/regulator/max77686-regulator.c @@ -256,8 +256,9 @@ static int max77686_of_parse_cb(struct device_node *np, case MAX77686_BUCK8: case MAX77686_BUCK9: case MAX77686_LDO20 ... MAX77686_LDO22: - config->ena_gpiod = gpiod_get_from_of_node(np, - "maxim,ena-gpios", + config->ena_gpiod = fwnode_gpiod_get_index( + of_fwnode_handle(np), + "maxim,ena", 0, GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE, "max77686-regulator"); -- 2.23.0.581.g78d2f28ef7-goog
[PATCH 1/7] regulator: s5m8767: switch to using devm_fwnode_gpiod_get
devm_gpiod_get_from_of_node() is being retired in favor of devm_fwnode_gpiod_get_index(), that behaves similar to devm_gpiod_get_index(), but can work with arbitrary firmware node. It will also be able to support secondary software nodes. Let's switch this driver over. Signed-off-by: Dmitry Torokhov --- drivers/regulator/s5m8767.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c index 6ca27e9d5ef7..bdc07739e9a2 100644 --- a/drivers/regulator/s5m8767.c +++ b/drivers/regulator/s5m8767.c @@ -567,11 +567,10 @@ static int s5m8767_pmic_dt_parse_pdata(struct platform_device *pdev, continue; } - rdata->ext_control_gpiod = devm_gpiod_get_from_of_node( + rdata->ext_control_gpiod = devm_fwnode_gpiod_get( >dev, - reg_np, - "s5m8767,pmic-ext-control-gpios", - 0, + of_fwnode_handle(reg_np), + "s5m8767,pmic-ext-control", GPIOD_OUT_HIGH | GPIOD_FLAGS_BIT_NONEXCLUSIVE, "s5m8767"); if (PTR_ERR(rdata->ext_control_gpiod) == -ENOENT) -- 2.23.0.581.g78d2f28ef7-goog
Re: [PATCH 3.16 00/87] 3.16.75-rc1 review
On Wed, Oct 02, 2019 at 08:06:50PM +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.16.75 release. > There are 87 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri Oct 04 19:06:50 UTC 2019. > Anything received after that time might be too late. > For v3.16.74-85-g811e39a80ea5: Build results: total: 136 pass: 136 fail: 0 Qemu test results: total: 229 pass: 229 fail: 0 Guenter
Re: [PATCH 5.3 000/344] 5.3.4-stable review
On Thu, Oct 03, 2019 at 05:49:25PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.3.4 release. > There are 344 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 158 pass: 158 fail: 0 Qemu test results: total: 391 pass: 391 fail: 0 Guenter
Re: [PATCH 5.2 000/313] 5.2.19-stable review
On Thu, Oct 03, 2019 at 05:49:38PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.2.19 release. > There are 313 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 159 pass: 159 fail: 0 Qemu test results: total: 390 pass: 390 fail: 0 Guenter
Re: [PATCH 4.19 000/211] 4.19.77-stable review
On Thu, Oct 03, 2019 at 05:51:06PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.77 release. > There are 211 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 156 pass: 156 fail: 0 Qemu test results: total: 390 pass: 390 fail: 0 Guenter
Re: [PATCH 4.14 000/185] 4.14.147-stable review
On Thu, Oct 03, 2019 at 05:51:18PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.147 release. > There are 185 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 172 pass: 172 fail: 0 Qemu test results: total: 372 pass: 372 fail: 0 Guenter
Re: [PATCH 4.9 000/129] 4.9.195-stable review
On Thu, Oct 03, 2019 at 05:52:03PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.195 release. > There are 129 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 172 pass: 172 fail: 0 Qemu test results: total: 356 pass: 356 fail: 0 Guenter
Re: [PATCH 4.4 00/99] 4.4.195-stable review
On Thu, Oct 03, 2019 at 05:52:23PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.195 release. > There are 99 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat 05 Oct 2019 03:37:47 PM UTC. > Anything received after that time might be too late. > Build results: total: 170 pass: 170 fail: 0 Qemu test results: total: 324 pass: 324 fail: 0 Guenter
Re: [PATCH v9 17/17] Documentation/x86/64: Add documentation for GS/FS addressing mode
On 10/4/19 11:16 AM, Chang S. Bae wrote: > From: Thomas Gleixner > > --- Reviewed-by: Randy Dunlap Thanks. > > Changes from v8: > * Fixed typos (Randy Dunlap) > * Massaged a few sentences that were previously edited by Thomas. > > Changes from v7: > * Rewritten the documentation and changelog by Thomas > * Included compiler version info additionally > --- > Documentation/x86/x86_64/fsgs.rst | 199 > + > Documentation/x86/x86_64/index.rst | 1 + > 2 files changed, 200 insertions(+) > create mode 100644 Documentation/x86/x86_64/fsgs.rst -- ~Randy
Re: [PATCH] tty: serial: fsl_lpuart: Fix lpuart_flush_buffer()
On Fri, Oct 04, 2019 at 02:55:37PM -0700, Andrey Smirnov wrote:
> Fix incorrect read-modify-write sequence in lpuart_flush_buffer() that
> was reading from UARTPFIFO and writing to UARTCFIFO instead of
> operating solely on the latter.
>
> Fixes: 9bc19af9dacb ("tty: serial: fsl_lpuart: Flush HW FIFOs in
> .flush_buffer")
> Signed-off-by: Andrey Smirnov
Tested-by: Andrew Lunn
Andrew
Re: [PATCH] fs/userfaultfd.c: simplify the calculation of new_flags
On Wed, Oct 02, 2019 at 08:45:05PM -0400, Andrea Arcangeli wrote: >Hello, > >On Tue, Aug 06, 2019 at 01:38:59PM +0800, Wei Yang wrote: >> Finally new_flags equals old vm_flags *OR* vm_flags. >> >> It is not necessary to mask them first. >> >> Signed-off-by: Wei Yang >> --- >> fs/userfaultfd.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c >> index ccbdbd62f0d8..653d8f7c453c 100644 >> --- a/fs/userfaultfd.c >> +++ b/fs/userfaultfd.c >> @@ -1457,7 +1457,7 @@ static int userfaultfd_register(struct userfaultfd_ctx >> *ctx, >> start = vma->vm_start; >> vma_end = min(end, vma->vm_end); >> >> -new_flags = (vma->vm_flags & ~vm_flags) | vm_flags; >> +new_flags = vma->vm_flags | vm_flags; >> prev = vma_merge(mm, prev, start, vma_end, new_flags, >> vma->anon_vma, vma->vm_file, vma->vm_pgoff, >> vma_policy(vma), > >And then how do you clear the flags after the above? > >It must be possible to clear the flags (from >UFFDIO_REGISTER_MODE_MISSING|UFFDIO_REGISTER_MODE_WP to only one set >or invert). > >We have no WP support upstream yet, so maybe that's why it looks >superfluous in practice, but in theory it isn't because it would then >need to be reversed by Peter's (CC'ed) -wp patchset. > >The register code has already the right placeholder to support -wp and >so it's better not to break them. > >I would recommend reviewing the uffd-wp support and working on testing >the uffd-wp code instead of changing the above. > Sorry, I don't get your point. This change is valid to me even from arithmetic point of view. vm_flags == VM_UFFD_MISSING | VM_UFFD_WP The effect of current code is clear these two bits then add them. This equals to just add these two bits. I am not sure which part I lost. >Thanks, >Andrea -- Wei Yang Help you, Help me
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Fri, Oct 04, 2019 at 07:33:53PM +0300, Konstantin Khlebnikov wrote:
>On 04/10/2019 19.06, Wei Yang wrote:
>> In function __anon_vma_prepare(), we will try to find anon_vma if it is
>> possible to reuse it. While on fork, the logic is different.
>>
>> Since commit 5beb49305251 ("mm: change anon_vma linking to fix
>> multi-process server scalability issue"), function anon_vma_clone()
>> tries to allocate new anon_vma for child process. But the logic here
>> will allocate a new anon_vma for each vma, even in parent this vma
>> is mergeable and share the same anon_vma with its sibling. This may do
>> better for scalability issue, while it is not necessary to do so
>> especially after interval tree is used.
>>
>> Commit 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy")
>> tries to reuse some anon_vma by counting child anon_vma and attached
>> vmas. While for those mergeable anon_vmas, we can just reuse it and not
>> necessary to go through the logic.
>>
>> After this change, kernel build test reduces 20% anon_vma allocation.
>>
>
>Makes sense. This might have much bigger effect for scenarios when task
>unmaps holes in huge vma as red-zones between allocations and then forks.
>
>Acked-by: Konstantin Khlebnikov
>
Thanks
--
Wei Yang
Help you, Help me
Re: [PATCH] mm/rmap.c: reuse mergeable anon_vma as parent when fork
On Fri, Oct 04, 2019 at 09:11:20AM -0700, Matthew Wilcox wrote: >On Sat, Oct 05, 2019 at 12:06:32AM +0800, Wei Yang wrote: >> After this change, kernel build test reduces 20% anon_vma allocation. > >But does it have any effect on elapsed time or peak memory consumption? I didn't evaluate these aspects. BTW, how to evaluate peak memory consumption? This looks a transient value. -- Wei Yang Help you, Help me
RE: [PATCH v2] x86/hyperv: make vapic support x2apic mode
From: Roman Kagan Sent: Friday, October 4, 2019 2:19 AM > > On Fri, Oct 04, 2019 at 03:01:51AM +, Michael Kelley wrote: > > From: Roman Kagan Sent: Thursday, October 3, 2019 > > 5:53 AM > > > > > > > > AFAIU you're trying to mirror native_x2apic_icr_write() here but this is > > > > different from what hv_apic_icr_write() does > > > > (SET_APIC_DEST_FIELD(id)). > > > > > > Right. In xapic mode the ICR2 aka the high 4 bytes of ICR is programmed > > > with the destination id in the highest byte; in x2apic mode the whole > > > ICR2 is set to the 32bit destination id. > > > > > > > Is it actually correct? (I think you've tested this and it is but) > > > > > > As I wrote in the commit log, I haven't tested it in the sense that I > > > ran a Linux guest in a Hyper-V VM exposing x2apic to the guest, because > > > I didn't manage to configure it to do so. OTOH I did run a Windows > > > guest in QEMU/KVM with hv_apic and x2apic enabled and saw it write > > > destination ids unshifted to the ICR2 part of ICR, so I assume it's > > > correct. > > > > > > > Michael, could you please shed some light here? > > > > > > Would be appreciated, indeed. > > > > > > > The newest version of Hyper-V provides an x2apic in a guest VM when the > > number of vCPUs in the VM is > 240. This version of Hyper-V is beginning > > to be deployed in Azure to enable the M416v2 VM size, but the functionality > > is not yet available for the on-premises version of Hyper-V. However, I can > > test this configuration internally with the above patch -- give me a few > > days. > > > > An additional complication is that when running on Intel processors that > > offer > > vAPIC functionality, the Hyper-V "hints" value does *not* recommend using > > the > > MSR-based APIC accesses. In this case, memory-mapped access to the x2apic > > registers is faster than the synthetic MSRs. > > I guess you mean "using regular x2apic MSRs compared to the synthetic > MSRs". Yes, of course you are correct. > Indeed they do essentially the same thing, and there's no reason > for one set of MSRs to be significantly faster than the other. However, > hv_apic_eoi_write makes use of "apic assists" aka lazy EOI which is > certainly a win, and I'm not sure if it works without hv_apic. > I've checked with the Hyper-V people and the presence of vAPIC makes a difference. If vAPIC is present in the hardware: 1) Hyper-V does not set the HV_X64_APIC_ACCESS_RECOMMENDED flag 2) The architectural MSRs should be used instead of the Hyper-V synthetic MSRs, as they are significantly faster. The architectural MSRs do not cause a VMEXIT because they are handled entirely by the vAPIC microcode in the CPU. The synthetic MSRs do cause a VMEXIT. 3) The lazy EOI functionality should not be used If vAPIC is not present in the hardware: 1) Hyper-V will set HV_X64_APIC_ACCESS_RECOMMENDED 2) Either set of MSRs has about the same performance, but we should use the synthetic MSRs. 3) The lazy EOI functionality has some value and should be used The same will apply to the AMD AVIC in some Hyper-V updates that are coming soon. So I think your code makes sense given the above information. By Monday I'll try to test it on a Hyper-V guest VM with x2APIC. Michael
[PATCH v2 5/6] rpmsg: glink: Don't send pending rx_done during remove
Attempting to transmit rx_done messages after the GLINK instance is
being torn down will cause use after free and memory leaks. So cancel
the intent_work and free up the pending intents.
With this there are no concurrent accessors of the channel left during
qcom_glink_native_remove() and there is therefor no need to hold the
spinlock during this operation - which would prohibit the use of
cancel_work_sync() in the release function. So remove this.
Fixes: 1d2ea36eead9 ("rpmsg: glink: Add rx done command")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- Drop the locking of idr_lock in qcom_glink_native_remove()
drivers/rpmsg/qcom_glink_native.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 89e02baea2d0..4117818db6a1 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -241,11 +241,23 @@ static void qcom_glink_channel_release(struct kref *ref)
{
struct glink_channel *channel = container_of(ref, struct glink_channel,
refcount);
+ struct glink_core_rx_intent *intent;
struct glink_core_rx_intent *tmp;
unsigned long flags;
int iid;
+ /* cancel pending rx_done work */
+ cancel_work_sync(>intent_work);
+
spin_lock_irqsave(>intent_lock, flags);
+ /* Free all non-reuse intents pending rx_done work */
+ list_for_each_entry_safe(intent, tmp, >done_intents, node) {
+ if (!intent->reuse) {
+ kfree(intent->data);
+ kfree(intent);
+ }
+ }
+
idr_for_each_entry(>liids, tmp, iid) {
kfree(tmp->data);
kfree(tmp);
@@ -1634,7 +1646,6 @@ void qcom_glink_native_remove(struct qcom_glink *glink)
if (ret)
dev_warn(glink->dev, "Can't remove GLINK devices: %d\n", ret);
- spin_lock_irqsave(>idr_lock, flags);
/* Release any defunct local channels, waiting for close-ack */
idr_for_each_entry(>lcids, channel, cid)
kref_put(>refcount, qcom_glink_channel_release);
@@ -1645,7 +1656,6 @@ void qcom_glink_native_remove(struct qcom_glink *glink)
idr_destroy(>lcids);
idr_destroy(>rcids);
- spin_unlock_irqrestore(>idr_lock, flags);
mbox_free_channel(glink->mbox_chan);
}
EXPORT_SYMBOL_GPL(qcom_glink_native_remove);
--
2.18.0
[PATCH v2 6/6] rpmsg: glink: Free pending deferred work on remove
By just cancelling the deferred rx worker during GLINK instance teardown
any pending deferred commands are leaked, so free them.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
drivers/rpmsg/qcom_glink_native.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 4117818db6a1..862f89c128a0 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1562,6 +1562,18 @@ static void qcom_glink_work(struct work_struct *work)
}
}
+static void qcom_glink_cancel_rx_work(struct qcom_glink *glink)
+{
+ struct glink_defer_cmd *dcmd;
+ struct glink_defer_cmd *tmp;
+
+ /* cancel any pending deferred rx_work */
+ cancel_work_sync(>rx_work);
+
+ list_for_each_entry_safe(dcmd, tmp, >rx_queue, node)
+ kfree(dcmd);
+}
+
struct qcom_glink *qcom_glink_native_probe(struct device *dev,
unsigned long features,
struct qcom_glink_pipe *rx,
@@ -1640,7 +1652,7 @@ void qcom_glink_native_remove(struct qcom_glink *glink)
unsigned long flags;
disable_irq(glink->irq);
- cancel_work_sync(>rx_work);
+ qcom_glink_cancel_rx_work(glink);
ret = device_for_each_child(glink->dev, NULL, qcom_glink_remove_device);
if (ret)
--
2.18.0
[PATCH v2] mm/page_isolation: fix a deadlock with printk()
It is unsafe to call printk() while zone->lock was held, i.e.,
zone->lock --> console_lock
because the console could always allocate some memory in different code
paths and form locking chains in an opposite order,
console_lock --> * --> zone->lock
As the result, it triggers lockdep splats like below and in different
code paths in this thread [1]. Since has_unmovable_pages() was only used
in set_migratetype_isolate() and is_pageblock_removable_nolock(). Only
the former will set the REPORT_FAILURE flag which will call printk().
Hence, unlock the zone->lock just before the dump_page() there where
when has_unmovable_pages() returns true, there is no need to hold the
lock anyway in the rest of set_migratetype_isolate().
While at it, remove a problematic printk() in __offline_isolated_pages()
only for debugging as well which will always disable lockdep on debug
kernels.
The problem is probably there forever, but neither many developers will
run memory offline with the lockdep enabled nor admins in the field are
lucky enough yet to hit a perfect timing which required to trigger a
real deadlock. In addition, there aren't many places that call printk()
while zone->lock was held.
WARNING: possible circular locking dependency detected
--
test.sh/1724 is trying to acquire lock:
52059ec0 (console_owner){-...}, at: console_unlock+0x
01: 328/0xa30
but task is already holding lock:
6ffd89c8 (&(>lock)->rlock){-.-.}, at: start_iso
01: late_page_range+0x216/0x538
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&(>lock)->rlock){-.-.}:
lock_acquire+0x21a/0x468
_raw_spin_lock+0x54/0x68
get_page_from_freelist+0x8b6/0x2d28
__alloc_pages_nodemask+0x246/0x658
__get_free_pages+0x34/0x78
sclp_init+0x106/0x690
sclp_register+0x2e/0x248
sclp_rw_init+0x4a/0x70
sclp_console_init+0x4a/0x1b8
console_init+0x2c8/0x410
start_kernel+0x530/0x6a0
startup_continue+0x70/0xd0
-> #1 (sclp_lock){-.-.}:
lock_acquire+0x21a/0x468
_raw_spin_lock_irqsave+0xcc/0xe8
sclp_add_request+0x34/0x308
sclp_conbuf_emit+0x100/0x138
sclp_console_write+0x96/0x3b8
console_unlock+0x6dc/0xa30
vprintk_emit+0x184/0x3c8
vprintk_default+0x44/0x50
printk+0xa8/0xc0
iommu_debugfs_setup+0xf2/0x108
iommu_init+0x6c/0x78
do_one_initcall+0x162/0x680
kernel_init_freeable+0x4e8/0x5a8
kernel_init+0x2a/0x188
ret_from_fork+0x30/0x34
kernel_thread_starter+0x0/0xc
-> #0 (console_owner){-...}:
check_noncircular+0x338/0x3e0
__lock_acquire+0x1e66/0x2d88
lock_acquire+0x21a/0x468
console_unlock+0x3a6/0xa30
vprintk_emit+0x184/0x3c8
vprintk_default+0x44/0x50
printk+0xa8/0xc0
__dump_page+0x1dc/0x710
dump_page+0x2e/0x58
has_unmovable_pages+0x2e8/0x470
start_isolate_page_range+0x404/0x538
__offline_pages+0x22c/0x1338
memory_subsys_offline+0xa6/0xe8
device_offline+0xe6/0x118
state_store+0xf0/0x110
kernfs_fop_write+0x1bc/0x270
vfs_write+0xce/0x220
ksys_write+0xea/0x190
system_call+0xd8/0x2b4
other info that might help us debug this:
Chain exists of:
console_owner --> sclp_lock --> &(>lock)->rlock
Possible unsafe locking scenario:
CPU0CPU1
lock(&(>lock)->rlock);
lock(sclp_lock);
lock(&(>lock)->rlock);
lock(console_owner);
*** DEADLOCK ***
9 locks held by test.sh/1724:
#0: 0e925408 (sb_writers#4){.+.+}, at: vfs_write+0x201:
#1: 50aa4280 (>mutex){+.+.}, at: kernfs_fop_write:
#2: 62e5c628 (kn->count#198){.+.+}, at: kernfs_fop_write
#3: 523236a0 (device_hotplug_lock){+.+.}, at:
lock_device_hotplug_sysfs+0x30/0x80
#4: 62e70990 (>mutex){}, at: device_offline
#5: 51fd36b0 (cpu_hotplug_lock.rw_sem){}, at:
__offline_pages+0xec/0x1338
#6: 521ca470 (mem_hotplug_lock.rw_sem){}, at:
percpu_down_write+0x38/0x210
#7: 6ffd89c8 (&(>lock)->rlock){-.-.}, at:
start_isolate_page_range+0x216/0x538
#8: 5205a100 (console_lock){+.+.}, at: vprintk_emit
stack backtrace:
Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
Call Trace:
([<512ae218>] show_stack+0x110/0x1b0)
[<51b6d506>] dump_stack+0x126/0x178
[<513a4b08>] check_noncircular+0x338/0x3e0
[<513aaaf6>] __lock_acquire+0x1e66/0x2d88
[<513a7e12>] lock_acquire+0x21a/0x468
[<513bb2fe>] console_unlock+0x3a6/0xa30
[<513bde2c>] vprintk_emit+0x184/0x3c8
[<513be0b4>] vprintk_default+0x44/0x50
[<513beb60>] printk+0xa8/0xc0
[<5158c364>] __dump_page+0x1dc/0x710
[<5158c8c6>] dump_page+0x2e/0x58
[PATCH v2 4/6] rpmsg: glink: Fix rpmsg_register_device err handling
From: Chris Lew
The device release function is set before registering with rpmsg. If
rpmsg registration fails, the framework will call device_put(), which
invokes the release function. The channel create logic does not need to
free rpdev if rpmsg_register_device() fails and release is called.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Chris Lew
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
drivers/rpmsg/qcom_glink_native.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 21fd2ae5f7f1..89e02baea2d0 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1423,15 +1423,13 @@ static int qcom_glink_rx_open(struct qcom_glink *glink,
unsigned int rcid,
ret = rpmsg_register_device(rpdev);
if (ret)
- goto free_rpdev;
+ goto rcid_remove;
channel->rpdev = rpdev;
}
return 0;
-free_rpdev:
- kfree(rpdev);
rcid_remove:
spin_lock_irqsave(>idr_lock, flags);
idr_remove(>rcids, channel->rcid);
--
2.18.0
[PATCH v2 1/6] rpmsg: glink: Fix reuse intents memory leak issue
From: Arun Kumar Neelakantam
Memory allocated for re-usable intents are not freed during channel
cleanup which causes memory leak in system.
Check and free all re-usable memory to avoid memory leak.
Fixes: 933b45da5d1d ("rpmsg: glink: Add support for TX intents")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Arun Kumar Neelakantam
Reported-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
drivers/rpmsg/qcom_glink_native.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 621f1afd4d6b..9355ce26fd98 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -241,10 +241,19 @@ static void qcom_glink_channel_release(struct kref *ref)
{
struct glink_channel *channel = container_of(ref, struct glink_channel,
refcount);
+ struct glink_core_rx_intent *tmp;
unsigned long flags;
+ int iid;
spin_lock_irqsave(>intent_lock, flags);
+ idr_for_each_entry(>liids, tmp, iid) {
+ kfree(tmp->data);
+ kfree(tmp);
+ }
idr_destroy(>liids);
+
+ idr_for_each_entry(>riids, tmp, iid)
+ kfree(tmp);
idr_destroy(>riids);
spin_unlock_irqrestore(>intent_lock, flags);
--
2.18.0
[PATCH v2 3/6] rpmsg: glink: Put an extra reference during cleanup
From: Chris Lew
In a remote processor crash scenario, there is no guarantee the remote
processor sent close requests before it went into a bad state. Remove
the reference that is normally handled by the close command in the
so channel resources can be released.
Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Cc: sta...@vger.kernel.org
Tested-by: Srinivas Kandagatla
Signed-off-by: Chris Lew
Reported-by: Srinivas Kandagatla
Signed-off-by: Bjorn Andersson
---
Changes since v1:
- None
drivers/rpmsg/qcom_glink_native.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index 72ed671f5dcd..21fd2ae5f7f1 100644
--- a/drivers/rpmsg/qcom_glink_native.c
+++ b/drivers/rpmsg/qcom_glink_native.c
@@ -1641,6 +1641,10 @@ void qcom_glink_native_remove(struct qcom_glink *glink)
idr_for_each_entry(>lcids, channel, cid)
kref_put(>refcount, qcom_glink_channel_release);
+ /* Release any defunct local channels, waiting for close-req */
+ idr_for_each_entry(>rcids, channel, cid)
+ kref_put(>refcount, qcom_glink_channel_release);
+
idr_destroy(>lcids);
idr_destroy(>rcids);
spin_unlock_irqrestore(>idr_lock, flags);
--
2.18.0
Re: [PATCH v18 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework
On Fri, Oct 04, 2019 at 03:59:10PM -0600, shuah wrote: > On 10/4/19 3:42 PM, Linus Torvalds wrote: > > On Fri, Oct 4, 2019 at 2:39 PM Theodore Y. Ts'o wrote: > > > > > > This question is primarily directed at Shuah and Linus > > > > > > What's the current status of the kunit series now that Brendan has > > > moved it out of the top-level kunit directory as Linus has requested? > > > > The move happened smack in the middle of merge window and landed in > linux-next towards the end of the merge window. > > > We seemed to decide to just wait for 5.5, but there is nothing that > > looks to block that. And I encouraged Shuah to find more kunit cases > > for when it _does_ get merged. > > > > Right. I communicated that to Brendan that we could work on adding more > kunit based tests which would help get more mileage on the kunit. > > > So if the kunit branch is stable, and people want to start using it > > for their unit tests, then I think that would be a good idea, and then > > during the 5.5 merge window we'll not just get the infrastructure, > > we'll get a few more users too and not just examples. I was planning on holding off on accepting more tests/changes until KUnit is in torvalds/master. As much as I would like to go around promoting it, I don't really want to promote too much complexity in a non-upstream branch before getting it upstream because I don't want to risk adding something that might cause it to get rejected again. To be clear, I can understand from your perspective why getting more tests/usage before accepting it is a good thing. The more people that play around with it, the more likely that someone will find an issue with it, and more likely that what is accepted into torvalds/master is of high quality. However, if I encourage arbitrary tests/improvements into my KUnit branch, it further diverges away from torvalds/master, and is more likely that there will be a merge conflict or issue that is not related to the core KUnit changes that will cause the whole thing to be rejected again in v5.5. I don't know. I guess we could maybe address that situation by splitting up the pull request into features and tests when we go to send it in, but that seems to invite a lot of unnecessary complexity. I actually already had some other tests/changes ready to send for review, but was holding off until the initial set of patches mad it in. Looking forward to hearing other people's thoughts.
[PATCH v2 0/6] rpmsg: glink stability fixes
Fixes for issues found in GLINK during reboot testing of a remoteproc. Arun Kumar Neelakantam (2): rpmsg: glink: Fix reuse intents memory leak issue rpmsg: glink: Fix use after free in open_ack TIMEOUT case Bjorn Andersson (2): rpmsg: glink: Don't send pending rx_done during remove rpmsg: glink: Free pending deferred work on remove Chris Lew (2): rpmsg: glink: Put an extra reference during cleanup rpmsg: glink: Fix rpmsg_register_device err handling drivers/rpmsg/qcom_glink_native.c | 52 +-- 1 file changed, 42 insertions(+), 10 deletions(-) -- 2.18.0
