Re: [PATCH 0/5] Prepare devicetrees for the new FSL QSPI driver
On Sat, Dec 15, 2018 at 10:04:55AM +, Schrempf Frieder wrote: > I can confirm, that the series does only remove or add properties to the > devicetree, that are currently not used by the driver. Therefore it won't > break > anything. Okay, applied the series. Shawn
Re: [PATCH 3/3] arm64: dts: ls1046a: add qdma device tree nodes
On Fri, Dec 14, 2018 at 10:30:15AM +, Peng Ma wrote: > Hi shawnguo, > > I send this series patch to > http://patchwork.ozlabs.org/project/devicetree-bindings/list/ > But I did not find patchs on devicetree patchwork, could I send patchs again. You do not need to. I have sent the series for 4.21 inclusion. I forgot to reply and let you know. Sorry. Shawn
Re: [PATCH] l2tp: Add protocol field decompression
From: Sam Protsenko Date: Fri, 14 Dec 2018 19:59:21 +0200 > When Protocol Field Compression (PFC) is enabled, the "Protocol" field > in PPP packet will be received without leading 0x00. See section 6.5 in > RFC 1661 for details. So let's decompress protocol field if needed, the > same way it's done in drivers/net/ppp/pptp.c. > > In case when "nopcomp" pppd option is not enabled, PFC (pcomp) can be > negotiated during LCP handshake, and L2TP driver in kernel will receive > PPP packets with compressed Protocol field, which in turn leads to next > error: > > Protocol Rejected (unsupported protocol 0x2145) > > because instead of Protocol=0x0021 in PPP packet there will be > Protocol=0x21. This patch unwraps it back to 0x0021, which fixes the > issue. > > Sending the compressed Protocol field will be implemented in subsequent > patch, this one is self-sufficient. > > Signed-off-by: Sam Protsenko Applied, thanks.
Re: [PATCH] clk: vc5: Initialize src in vc5_mux_set_parent()
Hi Stephen, On Friday, 14 December 2018 23:49:59 EET Stephen Boyd wrote: > It seems that it may be possible to get to the regmap update call > without ever initializing this variable, so just set it to 0 to be safe. This can't happen as the probe() function would have failed first. I'd thus add a comment to explain that the goal is only to silence a compiler warning. > Cc: Marek Vasut > Cc: Alexey Firago > Cc: Laurent Pinchart > Cc: linux-renesas-...@vger.kernel.org > Signed-off-by: Stephen Boyd > --- > drivers/clk/clk-versaclock5.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c > index 5b393e711e94..026f76276933 100644 > --- a/drivers/clk/clk-versaclock5.c > +++ b/drivers/clk/clk-versaclock5.c > @@ -246,7 +246,7 @@ static int vc5_mux_set_parent(struct clk_hw *hw, u8 > index) struct vc5_driver_data *vc5 = > container_of(hw, struct vc5_driver_data, clk_mux); > const u8 mask = VC5_PRIM_SRC_SHDN_EN_XTAL | VC5_PRIM_SRC_SHDN_EN_CLKIN; > - u8 src; > + u8 src = 0; > > if ((index > 1) || !vc5->clk_mux_ins) > return -EINVAL; -- Regards, Laurent Pinchart
Re: [PATCH v6] gpu: ipu-csi: Swap fields according to input/output field types
Hi Steve,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Steve-Longerbeam/gpu-ipu-csi-Swap-fields-according-to-input-output-field-types/20181215-135741
config: nds32-allmodconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.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=6.4.0 make.cross ARCH=nds32
All errors (new ones prefixed by >>):
drivers/gpu/ipu-v3/ipu-csi.c: In function 'ipu_csi_set_bt_interlaced_codes':
>> drivers/gpu/ipu-v3/ipu-csi.c:407:17: error: implicit declaration of function
>> 'V4L2_FIELD_IS_SEQUENTIAL' [-Werror=implicit-function-declaration]
swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
^~~~
cc1: some warnings being treated as errors
vim +/V4L2_FIELD_IS_SEQUENTIAL +407 drivers/gpu/ipu-v3/ipu-csi.c
385
386 static int
387 ipu_csi_set_bt_interlaced_codes(struct ipu_csi *csi,
388 const struct v4l2_mbus_framefmt *infmt,
389 const struct v4l2_mbus_framefmt *outfmt,
390 v4l2_std_id std)
391 {
392 enum v4l2_field infield, outfield;
393 bool swap_fields;
394
395 /* get translated field type of input and output */
396 infield = ipu_csi_translate_field(infmt->field, std);
397 outfield = ipu_csi_translate_field(outfmt->field, std);
398
399 /*
400 * Write the H-V-F codes the CSI will match against the
401 * incoming data for start/end of active and blanking
402 * field intervals. If input and output field types are
403 * sequential but not the same (one is SEQ_BT and the other
404 * is SEQ_TB), swap the F-bit so that the CSI will capture
405 * field 1 lines before field 0 lines.
406 */
> 407 swap_fields = (V4L2_FIELD_IS_SEQUENTIAL(infield) &&
408 V4L2_FIELD_IS_SEQUENTIAL(outfield) &&
409 infield != outfield);
410
411 if (!swap_fields) {
412 /*
413 * Field0BlankEnd = 110, Field0BlankStart = 010
414 * Field0ActiveEnd = 100, Field0ActiveStart = 000
415 * Field1BlankEnd = 111, Field1BlankStart = 011
416 * Field1ActiveEnd = 101, Field1ActiveStart = 001
417 */
418 ipu_csi_write(csi, 0x40596 | CSI_CCIR_ERR_DET_EN,
419CSI_CCIR_CODE_1);
420 ipu_csi_write(csi, 0xD07DF, CSI_CCIR_CODE_2);
421 } else {
422 dev_dbg(csi->ipu->dev, "capture field swap\n");
423
424 /* same as above but with F-bit inverted */
425 ipu_csi_write(csi, 0xD07DF | CSI_CCIR_ERR_DET_EN,
426CSI_CCIR_CODE_1);
427 ipu_csi_write(csi, 0x40596, CSI_CCIR_CODE_2);
428 }
429
430 ipu_csi_write(csi, 0xFF, CSI_CCIR_CODE_3);
431
432 return 0;
433 }
434
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3] staging: android: ion: Add implementation of dma_buf_vmap and dma_buf_vunmap
On 12/16/18 7:20 AM, Liam Mark wrote: > On Tue, 6 Feb 2018, Alexey Skidanov wrote: > >> >> >> On 02/07/2018 01:56 AM, Laura Abbott wrote: >>> On 01/31/2018 10:10 PM, Alexey Skidanov wrote: On 01/31/2018 03:00 PM, Greg KH wrote: > On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote: >> Any driver may access shared buffers, created by ion, using >> dma_buf_vmap and >> dma_buf_vunmap dma-buf API that maps/unmaps previosuly allocated >> buffers into >> the kernel virtual address space. The implementation of these API is >> missing in >> the current ion implementation. >> >> Signed-off-by: Alexey Skidanov >> --- > > No review from any other Intel developers? :( Will add. > > Anyway, what in-tree driver needs access to these functions? I'm not sure that there are the in-tree drivers using these functions and ion as> buffer exporter because they are not implemented in ion :) But there are some in-tre> drivers using these APIs (gpu drivers) with other buffer exporters. >>> >>> It's still not clear why you need to implement these APIs. >> How the importing kernel module may access the content of the buffer? :) >> With the current ion implementation it's only possible by dma_buf_kmap, >> mapping one page at a time. For pretty large buffers, it might have some >> performance impact. >> (Probably, the page by page mapping is the only way to access large >> buffers on 32 bit systems, where the vmalloc range is very small. By the >> way, the current ion dma_map_kmap doesn't really map only 1 page at a >> time - it uses the result of vmap() that might fail on 32 bit systems.) >> >>> Are you planning to use Ion with GPU drivers? I'm especially >>> interested in this if you have a non-Android use case. >> Yes, my use case is the non-Android one. But not with GPU drivers. >>> >>> Thanks, >>> Laura >> >> Thanks, >> Alexey > > I was wondering if we could re-open the discussion on adding support to > ION for dma_buf_vmap. > It seems like the patch was not taken as the reviewers wanted more > evidence of an upstream use case. > > Here would be my upstream usage argument for including dma_buf_vmap > support in ION. > > Currently all calls to ion_dma_buf_begin_cpu_access result in the creation > of a kernel mapping for the buffer, unfortunately the resulting call to > alloc_vmap_area can be quite expensive and this has caused a performance > regression for certain clients when they have moved to the new version of > ION. > > The kernel mapping is not actually needed in ion_dma_buf_begin_cpu_access, > and generally isn't needed by clients. So if we remove the creation of the > kernel mapping in ion_dma_buf_begin_cpu_access and only create it when > needed we can speed up the calls to ion_dma_buf_begin_cpu_access. > > An additional benefit of removing the creation of kernel mappings from > ion_dma_buf_begin_cpu_access is that it makes the ION code more secure. > Currently a malicious client could call the DMA_BUF_IOCTL_SYNC IOCTL with > flags DMA_BUF_SYNC_END multiple times to cause the ION buffer kmap_cnt to > go negative which could lead to undesired behavior. > > One disadvantage of the above change is that a kernel mapping is not > already created when a client calls dma_buf_kmap. So the following > dma_buf_kmap contract can't be satisfied. > > /** > * dma_buf_kmap - Map a page of the buffer object into kernel address > space. The > * same restrictions as for kmap and friends apply. > * @dmabuf:[in]buffer to map page from. > * @page_num: [in]page in PAGE_SIZE units to map. > * > * This call must always succeed, any necessary preparations that might > fail > * need to be done in begin_cpu_access. > */ > > But hopefully we can work around this by moving clients to dma_buf_vmap. I think the problem is with the contract. We can't ensure that the call is always succeeds regardless the implementation - any mapping might fail. Probably this is why *all* clients of dma_buf_kmap() check the return value (so it's safe to return NULL in case of failure). I would suggest to fix the contract and to keep the dma_buf_kmap() support in ION. > > Based on discussions at LPC here is what was proposed: > - #1 Add support to ION for dma_buf_vmap and dma_buf_vunmap > - #2 Move any existing ION clients over from using dma_buf_kmap to > dma_buf_vmap > - #3 Deprecate support in ION for dma_buf_kmap? > - #4 Make the above performance optimization to > ion_dma_buf_begin_cpu_access to remove the creation of a kernel mapping. > > Thoughts? > > Liam > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project > Thanks, Alexey
linux-next: Signed-off-by missing for commit in the block tree
Hi Jens,
Commit
6f7ceaa0559b ("block: remove the bioset_integrity_free export")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpdmXVC5B_nh.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commit in the v4l-dvb-next tree
Hi Mauro,
Commit
7ab9b77a9410 ("media: staging/intel-ipu3: Add dual pipe support")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpfv6BZpmFw_.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commit in the nfs-anna tree
Hi all,
Commit
748d6fd8d297 ("NFS: nfs_compare_mount_options always compare auth flavors.")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpe1D6STw0Ny.pgp
Description: OpenPGP digital signature
Re: [linux-next] Request to add auxdisplay tree
Hi Miguel, On Fri, 14 Dec 2018 17:11:09 +0100 Miguel Ojeda wrote: > > Can you please add the auxdisplay tree into linux-next? > > https://github.com/ojeda/linux.git auxdisplay > > It is extremely low volume, but from time to time there is a patch. Added from Monday. Out of interest, will this tree be sent directly to Linus or merged vi some other tree? Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgphwaUgCPJ8C.pgp Description: OpenPGP digital signature
Re: [PATCH v3] staging: android: ion: Add implementation of dma_buf_vmap and dma_buf_vunmap
On Tue, 6 Feb 2018, Alexey Skidanov wrote: > > > On 02/07/2018 01:56 AM, Laura Abbott wrote: > > On 01/31/2018 10:10 PM, Alexey Skidanov wrote: > >> > >> On 01/31/2018 03:00 PM, Greg KH wrote: > >>> On Wed, Jan 31, 2018 at 02:03:42PM +0200, Alexey Skidanov wrote: > Any driver may access shared buffers, created by ion, using > dma_buf_vmap and > dma_buf_vunmap dma-buf API that maps/unmaps previosuly allocated > buffers into > the kernel virtual address space. The implementation of these API is > missing in > the current ion implementation. > > Signed-off-by: Alexey Skidanov > --- > >>> > >>> No review from any other Intel developers? :( > >> Will add. > >>> > >>> Anyway, what in-tree driver needs access to these functions? > >> I'm not sure that there are the in-tree drivers using these functions > >> and ion as> buffer exporter because they are not implemented in ion :) > >> But there are some in-tre> drivers using these APIs (gpu drivers) with > >> other buffer exporters. > > > > It's still not clear why you need to implement these APIs. > How the importing kernel module may access the content of the buffer? :) > With the current ion implementation it's only possible by dma_buf_kmap, > mapping one page at a time. For pretty large buffers, it might have some > performance impact. > (Probably, the page by page mapping is the only way to access large > buffers on 32 bit systems, where the vmalloc range is very small. By the > way, the current ion dma_map_kmap doesn't really map only 1 page at a > time - it uses the result of vmap() that might fail on 32 bit systems.) > > > Are you planning to use Ion with GPU drivers? I'm especially > > interested in this if you have a non-Android use case. > Yes, my use case is the non-Android one. But not with GPU drivers. > > > > Thanks, > > Laura > > Thanks, > Alexey I was wondering if we could re-open the discussion on adding support to ION for dma_buf_vmap. It seems like the patch was not taken as the reviewers wanted more evidence of an upstream use case. Here would be my upstream usage argument for including dma_buf_vmap support in ION. Currently all calls to ion_dma_buf_begin_cpu_access result in the creation of a kernel mapping for the buffer, unfortunately the resulting call to alloc_vmap_area can be quite expensive and this has caused a performance regression for certain clients when they have moved to the new version of ION. The kernel mapping is not actually needed in ion_dma_buf_begin_cpu_access, and generally isn't needed by clients. So if we remove the creation of the kernel mapping in ion_dma_buf_begin_cpu_access and only create it when needed we can speed up the calls to ion_dma_buf_begin_cpu_access. An additional benefit of removing the creation of kernel mappings from ion_dma_buf_begin_cpu_access is that it makes the ION code more secure. Currently a malicious client could call the DMA_BUF_IOCTL_SYNC IOCTL with flags DMA_BUF_SYNC_END multiple times to cause the ION buffer kmap_cnt to go negative which could lead to undesired behavior. One disadvantage of the above change is that a kernel mapping is not already created when a client calls dma_buf_kmap. So the following dma_buf_kmap contract can't be satisfied. /** * dma_buf_kmap - Map a page of the buffer object into kernel address space. The * same restrictions as for kmap and friends apply. * @dmabuf: [in]buffer to map page from. * @page_num:[in]page in PAGE_SIZE units to map. * * This call must always succeed, any necessary preparations that might fail * need to be done in begin_cpu_access. */ But hopefully we can work around this by moving clients to dma_buf_vmap. Based on discussions at LPC here is what was proposed: - #1 Add support to ION for dma_buf_vmap and dma_buf_vunmap - #2 Move any existing ION clients over from using dma_buf_kmap to dma_buf_vmap - #3 Deprecate support in ION for dma_buf_kmap? - #4 Make the above performance optimization to ion_dma_buf_begin_cpu_access to remove the creation of a kernel mapping. Thoughts? Liam Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] x86, kbuild: revert macrofying inline assembly code
> On Dec 15, 2018, at 6:50 PM, Masahiro Yamada
> wrote:
>
> Revert the following 9 commits:
>
> [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
>work around GCC inlining bugs")
>
>This was partially reverted because it made good cleanups
>irrespective of the inlining issue; the error message is still
>unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should
>be kept.
>
> [2] d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to
>work around GCC inlining bugs")
>
> [3] 0474d5d9d2f7 ("x86/extable: Macrofy inline assembly code to work
>around GCC inlining bugs")
>
> [4] 494b5168f2de ("x86/paravirt: Work around GCC inlining bugs when
>compiling paravirt ops")
>
> [5] f81f8ad56fd1 ("x86/bug: Macrofy the BUG table section handling,
>to work around GCC inlining bugs")
>
> [6] 77f48ec28e4c ("x86/alternatives: Macrofy lock prefixes to work
> around GCC inlining bugs")
>
> [7] 9e1725b41059 ("x86/refcount: Work around GCC inlining bug")
>
>Resolved conflicts in arch/x86/include/asm/refcount.h caused by
>288e4521f0f6 ("x86/asm: 'Simplify' GEN_*_RMWcc() macros").
>
> [8] c06c4d809051 ("x86/objtool: Use asm macros to work around GCC
>inlining bugs")
>
> [9] 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in inline
>assembly code to work around asm() related GCC inlining bugs")
>
> A few days after those commits applied, discussion started to solve
> the issue more elegantly with the help of compiler:
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F10%2F7%2F92data=02%7C01%7Cnamit%40vmware.com%7Ce893ce88065e4c59236308d663019424%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636805255787607178sdata=miiUndmPfGNKvrzD5mttC1%2Bn6rNaoIFebjZOAkBr24Y%3Dreserved=0
>
> The new syntax "asm inline" was implemented by Segher Boessenkool, and
> now queued up for GCC 9. (People were positive even for back-porting it
> to older compilers).
>
> Since the in-kernel workarounds merged, some issues have been reported:
> breakage of building with distcc/icecc, breakage of distro packages for
> module building. (More fundamentally, we cannot build external modules
> after 'make clean'.)
>
> I do not want to mess up the build system any more.
>
> Given that this issue will be solved in a cleaner way sooner or later,
> let's revert the in-kernel workarounds, and wait for GCC 9.
>
> Reported-by: Logan Gunthorpe # distcc
> Reported-by: Sedat Dilek # deb/rpm package
It is customary to cc those who report an issue.
The distcc issue has already been resolved both in distcc and in the patches
I’ve sent: https://lkml.org/lkml/2018/11/15/467 . So I cannot understand why
it is mentioned as a motivation.
It sounds that the external modules can easily be resolved. Can you please
provide a link for the bug report?
Please regard my comments regarding v1. I must admit that I’m very surprised
that you don’t like the patches since you ack’d the original patch-set (and
actually assisted me in changing the Makefile).
Re: [PATCH] fork,memcg: fix crash in free_thread_stack on memcg charge fail
On Fri, Dec 14, 2018 at 11:17:26PM -0500, Rik van Riel wrote:
> Changeset 9b6f7e163cd0 ("mm: rework memcg kernel stack accounting")
> will result in fork failing if allocating a kernel stack for a task
> in dup_task_struct exceeds the kernel memory allowance for that cgroup.
>
> Unfortunately, it also results in a crash.
>
> This is due to the code jumping to free_stack and calling free_thread_stack
> when the memcg kernel stack charge fails, but without tsk->stack pointing
> at the freshly allocated stack.
>
> This in turn results in the vfree_atomic in free_thread_stack oopsing
> with a backtrace like this:
>
> #5 [c900244efc88] die at 8101f0ab
> #6 [c900244efcb8] do_general_protection at 8101cb86
> #7 [c900244efce0] general_protection at 818ff082
> [exception RIP: llist_add_batch+7]
> RIP: 8150d487 RSP: c900244efd98 RFLAGS: 00010282
> RAX: RBX: 88085ef55980 RCX:
> RDX: 88085ef55980 RSI: 343834343531203a RDI: 343834343531203a
> RBP: c900244efd98 R8: 0001 R9: 8808578c3600
> R10: R11: 0001 R12: 88029f6c21c0
> R13: 0286 R14: 880147759b00 R15:
> ORIG_RAX: CS: 0010 SS: 0018
> #8 [c900244efda0] vfree_atomic at 811df2c7
> #9 [c900244efdb8] copy_process at 81086e37
> #10 [c900244efe98] _do_fork at 810884e0
> #11 [c900244eff10] sys_vfork at 810887ff
> #12 [c900244eff20] do_syscall_64 at 81002a43
> RIP: 0049b948 RSP: 7ffcdb307830 RFLAGS: 0246
> RAX: ffda RBX: 00896030 RCX: 0049b948
> RDX: RSI: 7ffcdb307790 RDI: 005d7421
> RBP: 0067370f R8: 7ffcdb3077b0 R9: 0001ed00
> R10: 0008 R11: 0246 R12: 0040
> R13: 000f R14: R15: 0088d018
> ORIG_RAX: 003a CS: 0033 SS: 002b
>
> The simplest fix is to assign tsk->stack right where it is allocated.
Good catch!
Acked-by: Roman Gushchin
Thanks!
Re: [PATCH 5/7] riscv: dts: add initial support for the SiFive FU540-C000 SoC
Hi Paul, I love your patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.20-rc6 next-20181214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Paul-Walmsley/arch-riscv-add-DT-file-support-starting-with-the-SiFive-HiFive-U/20181216-103926 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next config: riscv-tinyconfig (attached as .config) compiler: riscv64-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=riscv Note: the linux-review/Paul-Walmsley/arch-riscv-add-DT-file-support-starting-with-the-SiFive-HiFive-U/20181216-103926 HEAD bd72c6c6fec694776fceb1c4f4cf7c6415a6e8e3 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): >> scripts/Makefile.build:42: arch/riscv/boot/dts/Makefile: No such file or >> directory >> make[2]: *** No rule to make target 'arch/riscv/boot/dts/Makefile'. make[2]: Failed to remake makefile 'arch/riscv/boot/dts/Makefile'. vim +42 scripts/Makefile.build 20a468b51 Sam Ravnborg 2006-01-22 38 2a6914703 Sam Ravnborg 2005-07-25 39 # The filename Kbuild has precedence over Makefile db8c1a7b2 Sam Ravnborg 2005-07-27 40 kbuild-dir := $(if $(filter /%,$(src)),$(src),$(srctree)/$(src)) 0c53c8e6e Sam Ravnborg 2007-10-14 41 kbuild-file := $(if $(wildcard $(kbuild-dir)/Kbuild),$(kbuild-dir)/Kbuild,$(kbuild-dir)/Makefile) 0c53c8e6e Sam Ravnborg 2007-10-14 @42 include $(kbuild-file) ^1da177e4 Linus Torvalds 2005-04-16 43 :: The code at line 42 was first introduced by commit :: 0c53c8e6eb456cde30f2305421c605713856abc8 kbuild: check for wrong use of CFLAGS :: TO: Sam Ravnborg :: CC: Sam Ravnborg --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH v2] x86, kbuild: revert macrofying inline assembly code
Revert the following 9 commits:
[1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to
work around GCC inlining bugs")
This was partially reverted because it made good cleanups
irrespective of the inlining issue; the error message is still
unneeded, and the conversion to STATIC_BRANCH_{NOP,JUMP} should
be kept.
[2] d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to
work around GCC inlining bugs")
[3] 0474d5d9d2f7 ("x86/extable: Macrofy inline assembly code to work
around GCC inlining bugs")
[4] 494b5168f2de ("x86/paravirt: Work around GCC inlining bugs when
compiling paravirt ops")
[5] f81f8ad56fd1 ("x86/bug: Macrofy the BUG table section handling,
to work around GCC inlining bugs")
[6] 77f48ec28e4c ("x86/alternatives: Macrofy lock prefixes to work
around GCC inlining bugs")
[7] 9e1725b41059 ("x86/refcount: Work around GCC inlining bug")
Resolved conflicts in arch/x86/include/asm/refcount.h caused by
288e4521f0f6 ("x86/asm: 'Simplify' GEN_*_RMWcc() macros").
[8] c06c4d809051 ("x86/objtool: Use asm macros to work around GCC
inlining bugs")
[9] 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in inline
assembly code to work around asm() related GCC inlining bugs")
A few days after those commits applied, discussion started to solve
the issue more elegantly with the help of compiler:
https://lkml.org/lkml/2018/10/7/92
The new syntax "asm inline" was implemented by Segher Boessenkool, and
now queued up for GCC 9. (People were positive even for back-porting it
to older compilers).
Since the in-kernel workarounds merged, some issues have been reported:
breakage of building with distcc/icecc, breakage of distro packages for
module building. (More fundamentally, we cannot build external modules
after 'make clean'.)
I do not want to mess up the build system any more.
Given that this issue will be solved in a cleaner way sooner or later,
let's revert the in-kernel workarounds, and wait for GCC 9.
Reported-by: Logan Gunthorpe # distcc
Reported-by: Sedat Dilek # deb/rpm package
Signed-off-by: Masahiro Yamada
Cc: Nadav Amit
Cc: Segher Boessenkool
---
Please consider this for v4.20 release.
Currently, distro package build is broken.
Changes in v2:
- Revive clean-ups made by 5bdcd510c2ac (per Peter Zijlstra)
- Fix commit quoting style (per Peter Zijlstra)
Makefile | 9 +---
arch/x86/Makefile | 7 ---
arch/x86/include/asm/alternative-asm.h | 20 +++
arch/x86/include/asm/alternative.h | 11 +++-
arch/x86/include/asm/asm.h | 53 +++---
arch/x86/include/asm/bug.h | 98 +++---
arch/x86/include/asm/cpufeature.h | 82
arch/x86/include/asm/jump_label.h | 22 ++--
arch/x86/include/asm/paravirt_types.h | 56 +--
arch/x86/include/asm/refcount.h| 81
arch/x86/kernel/macros.S | 16 --
include/asm-generic/bug.h | 8 +--
include/linux/compiler.h | 56 +--
scripts/Kbuild.include | 4 +-
scripts/mod/Makefile | 2 -
15 files changed, 224 insertions(+), 301 deletions(-)
delete mode 100644 arch/x86/kernel/macros.S
diff --git a/Makefile b/Makefile
index f2c3423..4cf4c5b 100644
--- a/Makefile
+++ b/Makefile
@@ -1081,7 +1081,7 @@ scripts: scripts_basic scripts_dtc asm-generic
gcc-plugins $(autoksyms_h)
# version.h and scripts_basic is processed / created.
# Listed in dependency order
-PHONY += prepare archprepare macroprepare prepare0 prepare1 prepare2 prepare3
+PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3
# prepare3 is used to check if we are building in a separate output directory,
# and if so do:
@@ -1104,9 +1104,7 @@ prepare2: prepare3 outputmakefile asm-generic
prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h
$(cmd_crmodverdir)
-macroprepare: prepare1 archmacros
-
-archprepare: archheaders archscripts macroprepare scripts_basic
+archprepare: archheaders archscripts prepare1 scripts_basic
prepare0: archprepare gcc-plugins
$(Q)$(MAKE) $(build)=.
@@ -1174,9 +1172,6 @@ archheaders:
PHONY += archscripts
archscripts:
-PHONY += archmacros
-archmacros:
-
PHONY += __headers
__headers: $(version_h) scripts_basic uapi-asm-generic archheaders archscripts
$(Q)$(MAKE) $(build)=scripts build_unifdef
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 75ef499..85a66c4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -232,13 +232,6 @@ archscripts: scripts_basic
archheaders:
$(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all
-archmacros:
- $(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s
-
-ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s
-export ASM_MACRO_FLAGS
-KBUILD_CFLAGS +=
Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds
> On Dec 14, 2018, at 4:51 PM, Masahiro Yamada
> wrote:
>
> Hi Peter,
>
> On Thu, Dec 13, 2018 at 7:53 PM Peter Zijlstra wrote:
>> On Thu, Dec 13, 2018 at 06:17:41PM +0900, Masahiro Yamada wrote:
>>> Revert the following commits:
>>>
>>> - 5bdcd510c2ac9efaf55c4cbd8d46421d8e2320cd
>>> ("x86/jump-labels: Macrofy inline assembly code to work around GCC
>>> inlining bugs")
>>>
>>> - d5a581d84ae6b8a4a740464b80d8d9cf1e7947b2
>>> ("x86/cpufeature: Macrofy inline assembly code to work around GCC inlining
>>> bugs")
>>>
>>> - 0474d5d9d2f7f3b11262f7bf87d0e7314ead9200.
>>> ("x86/extable: Macrofy inline assembly code to work around GCC inlining
>>> bugs")
>>>
>>> - 494b5168f2de009eb80f198f668da374295098dd.
>>> ("x86/paravirt: Work around GCC inlining bugs when compiling paravirt ops")
>>>
>>> - f81f8ad56fd1c7b99b2ed1c314527f7d9ac447c6.
>>> ("x86/bug: Macrofy the BUG table section handling, to work around GCC
>>> inlining bugs")
>>>
>>> - 77f48ec28e4ccff94d2e5f4260a83ac27a7f3099.
>>> ("x86/alternatives: Macrofy lock prefixes to work around GCC inlining
>>> bugs")
>>>
>>> - 9e1725b410594911cc5981b6c7b4cea4ec054ca8.
>>> ("x86/refcount: Work around GCC inlining bug")
>>> (Conflicts: arch/x86/include/asm/refcount.h)
>>>
>>> - c06c4d8090513f2974dfdbed2ac98634357ac475.
>>> ("x86/objtool: Use asm macros to work around GCC inlining bugs")
>>>
>>> - 77b0bf55bc675233d22cd5df97605d516d64525e.
>>> ("kbuild/Makefile: Prepare for using macros in inline assembly code to
>>> work around asm() related GCC inlining bugs")
>>
>> I don't think we want to blindly revert all that. Some of them actually
>> made sense and did clean up things irrespective of the asm-inline issue.
>>
>> In particular I like the jump-label one.
>
> [1] The #error message is unnecessary.
>
> [2] keep STATC_BRANCH_NOP/JMP instead of STATIC_JUMP_IF_TRUE/FALSE
>
>
>
> In v2, I will make sure to not re-add [1].
> I am not sure about [2].
>
>
> Do you mean only [1],
> or both of them?
>
>
>
>> The cpufeature one OTOh, yeah,
>> I'd love to get that reverted.
>>
>> And as a note; the normal commit quoting style is:
>>
>> d5a581d84ae6 ("x86/cpufeature: Macrofy inline assembly code to work around
>> GCC inlining bugs")
>
>
> OK. I will do so in v2.
I recommend to do the following for v2:
1. Run some static measurements (e.g., function sizes, number of function
symbols) to ensure that GCC works as it should. If possible, run small
performance evaluations. IIRC, I saw small but consistent performance
difference when I ran a loop with mprotect() that kept changing permissions.
This was due to PV MMU functions that caused inlining mess.
2. Break the patch into separate patches, based on the original patch-set
order (reversed). This is the common practice, which allows people to review
patches, perform bisections, and revert when needed.
3. Cc the relevant people who ack'd the original patches, e.g., Kees Cook,
who’s on top of the reference-counters and Linus, who proposed this
approach.
In general, I think that from the start it was clear that the motivation for
the patch-set is not just performance and also better code. For example, I
see no reason to revert the PV-changes or the lock-prefix changes that
improved the code readability.
Regards,
Nadav
Re: Fixing MIPS delay slot emulation weakness?
On Sun, Dec 16, 2018 at 02:15:38AM +, Maciej W. Rozycki wrote: > On Sat, 15 Dec 2018, Rich Felker wrote: > > > > A possibly nicer way to accomplish more or less the same thing would > > > be to allocate the area with _install_special_mapping() and arrange to > > > keep a reference to the struct page around. > > > > > > The really nice but less compatible fix would be to let processes or > > > even the whole system opt out by promising not to put anything in FPU > > > branch delay slots, of course. > > > > As I noted on Twitter when Mudge brought this topic back up, there's a > > much more compatible, elegant, and safe fix possible that does not > > involve any W+X memory. Emulate the delay slot in kernel-space. This > > is trivial to do safely for pretty much everything but loads/stores. > > I think "trivial" is an understatement, you at least need to decode the > delay-slot instruction enough to tell privileged and user instructions > apart and send SIGILL where appropriate. Some user instructions send > exceptions too and you need to handle them accordingly. I meant simply that making them safe is trivial if they're not accessing memory, only modifying the regisster file in the signal context. Not that emulating them is trivial. On the other hand it might be cleaner, safer, and easier to simply write a full mips ISA emulator, put it in the vdso, and have the kernel immediately return-to-userspace on hitting floating point instructions and let the emulator code there take care of it all and then return to the normal flow of execution. > OTOH, for things like ADDIUPC you need to interpret the instruction > anyway, as the value of the PC used for calculation will be wrong except > in the original location. Indeed. Assuming arbitrary ISA extensions including stuff that does PC-relative arithmetic, there's no way to execute it out-of-place without knowing how to interpret it. > > For loads/stores, where you want them to execute with user privilege > > level, what you do is compute the effective address in kernel-space, > > then return to a fixed instruction in the vdso page that performs a > > generic load/store using the register the kernel put the effective > > address result in, then restores registers off the stack and jumps to > > the branch destination. > > What about all the odd and especially vendor-specific load/store > instructions like ASET, SAA or SWAPW? Would we need to have all the > possible encodings provided in the VDSO? Can all kinds of weird stuff like this go in delay slots? I'm more familiar with SH delay slots where lots of instructions are slot-illegal. If so perhaps the full-emulator-in-userspace approach is better. Rich
[PATCH] uapi: linux/fs.h: update comment about reserved ioctl numbers
As commit 72cd87576d1d8 ("block: Introduce BLKGETZONESZ ioctl") and
commit 65e4e3eee83d7 ("block: Introduce BLKGETNRZONES ioctl") added
two more ioctls of type 0x12, update the comment about ioctl numbers
reserved for zoned block devices.
Signed-off-by: Dmitry V. Levin
---
include/uapi/linux/fs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index a441ea1bfe6d..2af9da218c33 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -228,7 +228,7 @@ struct fsxattr {
#define BLKROTATIONAL _IO(0x12,126)
#define BLKZEROOUT _IO(0x12,127)
/*
- * A jump here: 130-131 are reserved for zoned block devices
+ * A jump here: 130-133 are reserved for zoned block devices
* (see uapi/linux/blkzoned.h)
*/
--
ldv
Re: Fixing MIPS delay slot emulation weakness?
On Sat, 15 Dec 2018, Rich Felker wrote: > > A possibly nicer way to accomplish more or less the same thing would > > be to allocate the area with _install_special_mapping() and arrange to > > keep a reference to the struct page around. > > > > The really nice but less compatible fix would be to let processes or > > even the whole system opt out by promising not to put anything in FPU > > branch delay slots, of course. > > As I noted on Twitter when Mudge brought this topic back up, there's a > much more compatible, elegant, and safe fix possible that does not > involve any W+X memory. Emulate the delay slot in kernel-space. This > is trivial to do safely for pretty much everything but loads/stores. I think "trivial" is an understatement, you at least need to decode the delay-slot instruction enough to tell privileged and user instructions apart and send SIGILL where appropriate. Some user instructions send exceptions too and you need to handle them accordingly. OTOH, for things like ADDIUPC you need to interpret the instruction anyway, as the value of the PC used for calculation will be wrong except in the original location. > For loads/stores, where you want them to execute with user privilege > level, what you do is compute the effective address in kernel-space, > then return to a fixed instruction in the vdso page that performs a > generic load/store using the register the kernel put the effective > address result in, then restores registers off the stack and jumps to > the branch destination. What about all the odd and especially vendor-specific load/store instructions like ASET, SAA or SWAPW? Would we need to have all the possible encodings provided in the VDSO? Maciej
Re: general protection fault in kvm_arch_vcpu_ioctl_run
syzbot has found a reproducer for the following crash on: HEAD commit:6531e115b7ab Merge branch 'akpm' (patches from Andrew) git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15d99b2b40 kernel config: https://syzkaller.appspot.com/x/.config?x=c8970c89a0efbb23 dashboard link: https://syzkaller.appspot.com/bug?extid=39810e6c400efadfef71 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16005a1540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1056e54340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+39810e6c400efadfe...@syzkaller.appspotmail.com L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 1 PID: 5962 Comm: syz-executor118 Not tainted 4.20.0-rc6+ #374 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:kvm_apic_hw_enabled arch/x86/kvm/lapic.h:169 [inline] RIP: 0010:vcpu_scan_ioapic arch/x86/kvm/x86.c:7449 [inline] RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:7602 [inline] RIP: 0010:vcpu_run arch/x86/kvm/x86.c:7874 [inline] RIP: 0010:kvm_arch_vcpu_ioctl_run+0x5296/0x7320 arch/x86/kvm/x86.c:8074 Code: 03 00 00 48 89 f8 48 c1 e8 03 42 80 3c 20 00 0f 85 b4 1e 00 00 49 8b 9f e0 03 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 8a 1e 00 00 48 8b 9b 88 00 00 00 48 8d bb d8 RSP: 0018:8881be6bf530 EFLAGS: 00010206 RAX: 0011 RBX: RCX: 8110198b RDX: RSI: 81103a68 RDI: 0088 RBP: 8881be6bf8d0 R08: 8881c2362640 R09: 0008 R10: 0028 R11: 810feb0f R12: dc00 R13: R14: c90005e03db8 R15: 8881c2b70080 FS: 00e17880() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2040 CR3: 0001d2bc9000 CR4: 001426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: kvm_vcpu_ioctl+0x5c8/0x1150 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2596 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440859 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff16fec8f8 EFLAGS: 0207 ORIG_RAX: 0010 RAX: ffda RBX: 004002c8 RCX: 00440859 RDX: RSI: ae80 RDI: 0008 RBP: 006ca018 R08: 004002c8 R09: 004002c8 R10: 004002c8 R11: 0207 R12: 004020e0 R13: 00402170 R14: R15: Modules linked in: ---[ end trace 893a1b8ec645980a ]--- RIP: 0010:kvm_apic_hw_enabled arch/x86/kvm/lapic.h:169 [inline] RIP: 0010:vcpu_scan_ioapic arch/x86/kvm/x86.c:7449 [inline] RIP: 0010:vcpu_enter_guest arch/x86/kvm/x86.c:7602 [inline] RIP: 0010:vcpu_run arch/x86/kvm/x86.c:7874 [inline] RIP: 0010:kvm_arch_vcpu_ioctl_run+0x5296/0x7320 arch/x86/kvm/x86.c:8074 Code: 03 00 00 48 89 f8 48 c1 e8 03 42 80 3c 20 00 0f 85 b4 1e 00 00 49 8b 9f e0 03 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 0f 85 8a 1e 00 00 48 8b 9b 88 00 00 00 48 8d bb d8 RSP: 0018:8881be6bf530 EFLAGS: 00010206 RAX: 0011 RBX: RCX: 8110198b RDX: RSI: 81103a68 RDI: 0088 RBP: 8881be6bf8d0 R08: 8881c2362640 R09: 0008 R10: 0028 R11: 810feb0f R12: dc00 R13: R14: c90005e03db8 R15: 8881c2b70080 FS: 00e17880() GS:8881daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2040 CR3: 0001d2bc9000 CR4: 001426e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
[PATCH] uapi: linux/blkzoned.h: fix BLKGETZONESZ and BLKGETNRZONES definitions
According to the documentation in include/uapi/asm-generic/ioctl.h,
_IOW means userspace is writing and kernel is reading, and
_IOR means userspace is reading and kernel is writing.
In case of these two ioctls, kernel is writing and userspace is reading,
so they have to be _IOR instead of _IOW.
Fixes: 72cd87576d1d8 ("block: Introduce BLKGETZONESZ ioctl")
Fixes: 65e4e3eee83d7 ("block: Introduce BLKGETNRZONES ioctl")
Signed-off-by: Dmitry V. Levin
---
Since both ioctls were introduced after 4.19,
please make sure they are fixed in 4.20.
Thanks.
include/uapi/linux/blkzoned.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/blkzoned.h b/include/uapi/linux/blkzoned.h
index 8f08ff9bdea0..6fa38d001d84 100644
--- a/include/uapi/linux/blkzoned.h
+++ b/include/uapi/linux/blkzoned.h
@@ -141,7 +141,7 @@ struct blk_zone_range {
*/
#define BLKREPORTZONE _IOWR(0x12, 130, struct blk_zone_report)
#define BLKRESETZONE _IOW(0x12, 131, struct blk_zone_range)
-#define BLKGETZONESZ _IOW(0x12, 132, __u32)
-#define BLKGETNRZONES _IOW(0x12, 133, __u32)
+#define BLKGETZONESZ _IOR(0x12, 132, __u32)
+#define BLKGETNRZONES _IOR(0x12, 133, __u32)
#endif /* _UAPI_BLKZONED_H */
--
ldv
[PATCH v2 2/2] trace nvme submit queue status
export nvme disk name, queue id, sq_head, sq_tail to trace event
usage example:
go to the event directory:
cd /sys/kernel/debug/tracing/events/nvme/nvme_sq
filter by disk name:
echo 'disk=="nvme1n1"' > filter
enable the event:
echo 1 > enable
check results from trace_pipe:
cat /sys/kernel/debug/tracing/trace_pipe
In practice, this patch help me debug hardware related
performant issue.
Signed-off-by: yupeng
---
drivers/nvme/host/pci.c | 7 +
drivers/nvme/host/trace_pci.h | 49 +++
2 files changed, 56 insertions(+)
create mode 100644 drivers/nvme/host/trace_pci.h
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c33bb201b884..974cb05b3592 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -32,6 +32,9 @@
#include
#include
+#define CREATE_TRACE_POINTS
+#include "trace_pci.h"
+
#include "nvme.h"
#define SQ_SIZE(depth) (depth * sizeof(struct nvme_command))
@@ -899,6 +902,10 @@ static inline void nvme_handle_cqe(struct nvme_queue
*nvmeq, u16 idx)
}
req = blk_mq_tag_to_rq(*nvmeq->tags, cqe->command_id);
+ trace_nvme_sq(req->rq_disk,
+ nvmeq->qid,
+ le16_to_cpu(cqe->sq_head),
+ nvmeq->sq_tail);
nvme_end_request(req, cqe->status, cqe->result);
}
diff --git a/drivers/nvme/host/trace_pci.h b/drivers/nvme/host/trace_pci.h
new file mode 100644
index ..a48bdd4412e4
--- /dev/null
+++ b/drivers/nvme/host/trace_pci.h
@@ -0,0 +1,49 @@
+/*
+ * NVM Express device driver tracepoints
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM nvme
+
+#if !defined(_TRACE_NVME_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_NVME_H
+
+#include "trace_common.h"
+
+TRACE_EVENT(nvme_sq,
+ TP_PROTO(void *rq_disk, int qid, int sq_head, int sq_tail),
+ TP_ARGS(rq_disk, qid, sq_head, sq_tail),
+ TP_STRUCT__entry(
+__array(char, disk, DISK_NAME_LEN)
+__field(int, qid)
+__field(int, sq_head)
+__field(int, sq_tail)),
+ TP_fast_assign(
+ __entry->qid = qid;
+ __entry->sq_head = sq_head;
+ __entry->sq_tail = sq_tail;
+ __assign_disk_name(__entry->disk, rq_disk);
+ ),
+ TP_printk("nvme: %s qid=%d head=%d tail=%d",
+ __print_disk_name(__entry->disk),
+ __entry->qid, __entry->sq_head, __entry->sq_tail)
+);
+
+#endif /* _TRACE_NVME_H */
+
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE trace_pci
+
+/* This part must be outside protection */
+#include
--
2.17.1
[PATCH v2 1/2] share nvme trace event helper functions with multiple nvme modules
The trace.c could only be used by core.c, move it to a header file and
then other nvme modules could also use it. This commit creates a new
header file trace_common.h, which has all the functions of trace.c. It
changes all functions to static functions, so any other modules could
include it without conflict. This commit also moves some common
functions from trace.h to trace_common.h. Because the trace events in
trace.h are used by nvme-core only, this commit renames the trace.h to
trace_core.h.
Signed-off-by: yupeng
---
drivers/nvme/host/Makefile| 1 -
drivers/nvme/host/core.c | 2 +-
drivers/nvme/host/{trace.c => trace_common.h} | 82 +--
drivers/nvme/host/{trace.h => trace_core.h} | 76 +
4 files changed, 80 insertions(+), 81 deletions(-)
rename drivers/nvme/host/{trace.c => trace_common.h} (55%)
rename drivers/nvme/host/{trace.h => trace_core.h} (56%)
diff --git a/drivers/nvme/host/Makefile b/drivers/nvme/host/Makefile
index aea459c65ae1..165c265f57f1 100644
--- a/drivers/nvme/host/Makefile
+++ b/drivers/nvme/host/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_NVME_RDMA) += nvme-rdma.o
obj-$(CONFIG_NVME_FC) += nvme-fc.o
nvme-core-y:= core.o
-nvme-core-$(CONFIG_TRACING)+= trace.o
nvme-core-$(CONFIG_NVME_MULTIPATH) += multipath.o
nvme-core-$(CONFIG_NVM)+= lightnvm.o
nvme-core-$(CONFIG_FAULT_INJECTION_DEBUG_FS) += fault_inject.o
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 962012135b62..a1cf8df4c507 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -30,7 +30,7 @@
#include
#define CREATE_TRACE_POINTS
-#include "trace.h"
+#include "trace_core.h"
#include "nvme.h"
#include "fabrics.h"
diff --git a/drivers/nvme/host/trace.c b/drivers/nvme/host/trace_common.h
similarity index 55%
rename from drivers/nvme/host/trace.c
rename to drivers/nvme/host/trace_common.h
index 25b0e310f4a8..b9b88da74f58 100644
--- a/drivers/nvme/host/trace.c
+++ b/drivers/nvme/host/trace_common.h
@@ -12,9 +12,16 @@
* more details.
*/
-#include
-#include "trace.h"
+#ifndef TRACE_HEADER_MULTI_READ
+
+#include
+#include
+#include
+
+#include "nvme.h"
+#ifdef CONFIG_TRACING
+#include
static const char *nvme_trace_create_sq(struct trace_seq *p, u8 *cdw10)
{
const char *ret = trace_seq_buffer_ptr(p);
@@ -99,7 +106,7 @@ static const char *nvme_trace_common(struct trace_seq *p, u8
*cdw10)
return ret;
}
-const char *nvme_trace_parse_admin_cmd(struct trace_seq *p,
+static const char *nvme_trace_parse_admin_cmd(struct trace_seq *p,
u8 opcode, u8 *cdw10)
{
switch (opcode) {
@@ -114,7 +121,7 @@ const char *nvme_trace_parse_admin_cmd(struct trace_seq *p,
}
}
-const char *nvme_trace_parse_nvm_cmd(struct trace_seq *p,
+static const char *nvme_trace_parse_nvm_cmd(struct trace_seq *p,
u8 opcode, u8 *cdw10)
{
switch (opcode) {
@@ -129,7 +136,7 @@ const char *nvme_trace_parse_nvm_cmd(struct trace_seq *p,
}
}
-const char *nvme_trace_disk_name(struct trace_seq *p, char *name)
+static const char *nvme_trace_disk_name(struct trace_seq *p, char *name)
{
const char *ret = trace_seq_buffer_ptr(p);
@@ -139,3 +146,68 @@ const char *nvme_trace_disk_name(struct trace_seq *p, char
*name)
return ret;
}
+
+#endif /* CONFIG_TRACING */
+
+static inline void __assign_disk_name(char *name, struct gendisk *disk)
+{
+ if (disk)
+ memcpy(name, disk->disk_name, DISK_NAME_LEN);
+ else
+ memset(name, 0, DISK_NAME_LEN);
+}
+
+#define nvme_admin_opcode_name(opcode) { opcode, #opcode }
+#define show_admin_opcode_name(val)\
+ __print_symbolic(val, \
+ nvme_admin_opcode_name(nvme_admin_delete_sq), \
+ nvme_admin_opcode_name(nvme_admin_create_sq), \
+ nvme_admin_opcode_name(nvme_admin_get_log_page),\
+ nvme_admin_opcode_name(nvme_admin_delete_cq), \
+ nvme_admin_opcode_name(nvme_admin_create_cq), \
+ nvme_admin_opcode_name(nvme_admin_identify),\
+ nvme_admin_opcode_name(nvme_admin_abort_cmd), \
+ nvme_admin_opcode_name(nvme_admin_set_features),\
+ nvme_admin_opcode_name(nvme_admin_get_features),\
+ nvme_admin_opcode_name(nvme_admin_async_event), \
+ nvme_admin_opcode_name(nvme_admin_ns_mgmt), \
+ nvme_admin_opcode_name(nvme_admin_activate_fw), \
+ nvme_admin_opcode_name(nvme_admin_download_fw), \
+ nvme_admin_opcode_name(nvme_admin_ns_attach),
Re: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
Hi,
On 12/16/18 6:38 AM, Liu, Yi L wrote:
From: Lu Baolu [mailto:baolu...@linux.intel.com]
Sent: Sunday, November 11, 2018 10:45 PM
Subject: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
This adds APIs for IOMMU drivers and device drivers to manage the PASIDs used
for
DMA transfer and translation. It bases on I/O ASID allocator for PASID namespace
management and relies on vendor specific IOMMU drivers for paravirtual PASIDs.
Below APIs are added:
* iommu_pasid_init(pasid)
- Initialize a PASID consumer. The vendor specific IOMMU
drivers are able to set the PASID range imposed by IOMMU
hardware through a callback in iommu_ops.
* iommu_pasid_exit(pasid)
- The PASID consumer stops consuming any PASID.
* iommu_pasid_alloc(pasid, min, max, private, *ioasid)
- Allocate a PASID and associate a @private data with this
PASID. The PASID value is stored in @ioaisd if returning
success.
* iommu_pasid_free(pasid, ioasid)
- Free a PASID to the pool so that it could be consumed by
others.
This also adds below helpers to lookup or iterate PASID items associated with a
consumer.
* iommu_pasid_for_each(pasid, func, data)
- Iterate PASID items of the consumer identified by @pasid,
and call @func() against each item. An error returned from
@func() will break the iteration.
* iommu_pasid_find(pasid, ioasid)
- Retrieve the private data associated with @ioasid.
Cc: Ashok Raj
Cc: Jacob Pan
Cc: Kevin Tian
Cc: Jean-Philippe Brucker
Signed-off-by: Lu Baolu
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/iommu.c | 89 +++
include/linux/iommu.h | 73 +++
3 files changed, 163 insertions(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index
d9a25715650e..39f2bb76c7b8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -1,6 +1,7 @@
# IOMMU_API always gets selected by whoever wants it.
config IOMMU_API
bool
+ select IOASID
menuconfig IOMMU_SUPPORT
bool "IOMMU Hardware Support"
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
0b7c96d1425e..570b244897bb 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2082,3 +2082,92 @@ void iommu_detach_device_aux(struct iommu_domain
*domain, struct device *dev)
}
}
EXPORT_SYMBOL_GPL(iommu_detach_device_aux);
+
+/*
+ * APIs for PASID used by IOMMU and the device drivers which depend
+ * on IOMMU.
+ */
+struct iommu_pasid *iommu_pasid_init(struct bus_type *bus) {
I'm thinking about if using struct iommu_domain here is better
than struct bus_type. The major purpose is to pass iommu_ops
in it and route into iommu-sublayer. iommu_domain may be
better since some modules like vfio_iommu_type1 would use
iommu_domain more than bus type.
But drivers might call this during initialization when it doesn't has
any domain yet.
Best regards,
Lu Baolu
Re: [PATCH] pinctrl: aspeed: Wrap -Woverride-init with cc-option
On Tue, Dec 11, 2018 at 1:05 AM Nathan Chancellor wrote: > Clang does not support this option: > > warning: unknown warning option '-Woverride-init'; did you mean > '-Woverride-module'? [-Wunknown-warning-option] > 1 warning generated. > > Signed-off-by: Nathan Chancellor Patch applied with the ACKs! Yours, Linus Walleij
Re: [PATCH] gpio: raspberrypi-exp: decrease refcount on firmware dt node
On Mon, Dec 10, 2018 at 5:50 PM Nicolas Saenz Julienne
wrote:
> We're getting a reference RPi's firmware node in order to be able to
> communicate with it's driver. We should decrease the reference count on
> the dt node after being done with it.
>
> Fixes: a98d90e7d588 ("gpio: raspberrypi-exp: Driver for RPi3 GPIO expander
> via mailbox service")
> Signed-off-by: Nicolas Saenz Julienne
Patch applied.
Yours,
Linus Walleij
Re: [PATCH v5 4/8] pinctrl: lochnagar: Add initial binding documentation
On Tue, Nov 20, 2018 at 3:16 PM Charles Keepax wrote: > Lochnagar is an evaluation and development board for Cirrus > Logic Smart CODEC and Amp devices. It allows the connection of > most Cirrus Logic devices on mini-cards, as well as allowing > connection of various application processor systems to provide a > full evaluation platform. This driver supports the board > controller chip on the Lochnagar board. > > Signed-off-by: Charles Keepax Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] gpio: max7301: fix driver for use with CONFIG_VMAP_STACK
On Fri, Dec 7, 2018 at 2:07 PM Christophe Leroy wrote:
> spi_read() and spi_write() require DMA-safe memory. When
> CONFIG_VMAP_STACK is selected, those functions cannot be used
> with buffers on stack.
>
> This patch replaces calls to spi_read() and spi_write() by
> spi_write_then_read() which doesn't require DMA-safe buffers.
>
> Fixes: 0c36ec314735 ("gpio: gpio driver for max7301 SPI GPIO expander")
> Cc:
> Signed-off-by: Christophe Leroy
Patch applied for fixes.
Yours,
Linus Walleij
Re: Problem with late AMD microcode reload/feedback
On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote: > I'm trying to reload AMD Ryzen Mobile (fam17h) microcode doing: > echo 1 > /sys/devices/system/cpu/microcode/reload Also, I'd advise against using the late loading method but put the microcode in the initrd (which your distro should be probably doing, already): Documentation/x86/microcode.txt -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: Problem with late AMD microcode reload/feedback
On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote: > [19.736770] microcode: [find_equiv_id] sig:8458000 That's your CPU's family/model/stepping: 0x0810f10 > [19.736772] microcode: [find_equiv_id] equiv_table->installed_cpu:8392466 > [19.736775] microcode: [find_equiv_id] equiv_table->installed_cpu:8392578 and those are present on the system. Best to look at them in hex, btw: 0x0800f12 0x0800f82 Which means, there's no microcode for your CPU so nothing gets updated. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Problem with late AMD microcode reload/feedback
Hi, I'm trying to reload AMD Ryzen Mobile (fam17h) microcode doing: echo 1 > /sys/devices/system/cpu/microcode/reload The problem is I don't get any feedback. No error for the "echo" command, no a single new line in the "dmesg". I have no idea if microcode has been reloaded or not. I did a quick pr_info based debugging and I noticed that: 1) load_microcode_amd() calls __load_microcode_amd() and gets UCODE_OK 2) load_microcode_amd() calls find_patch(0) and gets a NULL because of that NULL load_microcode_amd() doesn't return UCODE_NEW. Seeing above I've decided to debug find_patch(). It seems to be calling __find_equiv_id(0) which returns 0. The last step was debugging __find_equiv_id() and find_equiv_id(). It seems that find_equiv_id() gets sig 8458000 that doesn't exists in the equiv_cpu_table: [19.736770] microcode: [find_equiv_id] sig:8458000 [19.736772] microcode: [find_equiv_id] equiv_table->installed_cpu:8392466 [19.736775] microcode: [find_equiv_id] equiv_table->installed_cpu:8392578 Has my microcode been updated? Is there a way to improve that microcode loading code? Is find_patch(0) returning a NULL expected or maybe a bug? -- Rafał
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Fri, Dec 14, 2018 at 04:06:27PM -0800, Sean Christopherson wrote: Good afternoon, I hope the weekend is going well for everyone. > On Fri, Dec 14, 2018 at 05:59:17PM -0600, Dr. Greg wrote: > > On Wed, Dec 12, 2018 at 08:00:36PM +0200, Jarkko Sakkinen wrote: > > > > Good evening, I hope the week has gone well for everyone. > > > > > On Mon, Dec 10, 2018 at 04:49:08AM -0600, Dr. Greg wrote: > > > > In the meantime, I wanted to confirm that your jarkko-sgx/master > > > > branch contains the proposed driver that is headed upstream. > > > > Before adding the SFLC patches we thought it best to run the > > > > driver through some testing in order to verify that any problems > > > > we generated where attributable to our work and not the base > > > > driver. > > > > > > The master branch is by definition unstable at the moment i.e. it > > > can sometimes (not often) contain unfinished changes. Use next for > > > testing. I update next when I consider the master contents "stable > > > enough". > > > > I noticed in the last day or so that you appeared to sync > > jarkko-sgx/master with jarkko-sgx/next, so I checked out a local > > branch against jarkko-sgx/next and ran it against our unit tests. > > Based on what we are seeing the driver is still experiencing issues > > with initialization of a non-trivial enclave. > master branch is broken, looks like the VMA code Jarkko is reworking is > buggy. I should be able to help debug this next week. > > [ 504.149548] [ cut here ] > [ 504.149550] kernel BUG at /home/sean/go/src/kernel.org/linux/mm/mmap.c:669! Rodger, dodger. Let us know when you think you have something working pushed up into one of the branches and we will put it on the bench here in the lab and see what our runtime is able to do with it. BTW, your new vDSO work appears to be shaping up well. Just out of curiosity though, how are you testing and validating the new vDSO based exception handler if it isn't possible to initialize and run an enclave with the new driver? We will look forward to hearing from you. Have a good remainder of the weekend. Dr. Greg As always, Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. 4206 N. 19th Ave. Specializing in information infra-structure Fargo, ND 58102development. PH: 701-281-1686 FAX: 701-281-3949 EMAIL: g...@enjellic.com -- "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken
[PATCH] mailbox: imx: Fix clk handling in imx_mu_probe()
Handling of devm_clk_get() suggests that the driver should support
lack of priv->clk. But imx_mu_probe() fails on clk_prepare_enable(NULL)
in that case.
The patch removes the try to enable absent clk and adds error handling
for mbox_controller_register().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/mailbox/imx-mailbox.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 363d35d5e49d..ddde398f576e 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -292,10 +292,12 @@ static int imx_mu_probe(struct platform_device *pdev)
priv->clk = NULL;
}
- ret = clk_prepare_enable(priv->clk);
- if (ret) {
- dev_err(dev, "Failed to enable clock\n");
- return ret;
+ if (priv->clk) {
+ ret = clk_prepare_enable(priv->clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable clock\n");
+ return ret;
+ }
}
for (i = 0; i < IMX_MU_CHANS; i++) {
@@ -324,7 +326,13 @@ static int imx_mu_probe(struct platform_device *pdev)
imx_mu_init_generic(priv);
- return mbox_controller_register(>mbox);
+ ret = mbox_controller_register(>mbox);
+ if (ret) {
+ clk_disable_unprepare(priv->clk);
+ return ret;
+ }
+
+ return 0;
}
static int imx_mu_remove(struct platform_device *pdev)
--
2.7.4
Re: Fixing MIPS delay slot emulation weakness?
On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote: > Hi all- > > Some security researchers pointed out that writing to the delay slot > emulation page is a great exploit technique on MIPS. It was > introduced in: > > commit 432c6bacbd0c16ec210c43da411ccc3855c4c010 > Author: Paul Burton > Date: Fri Jul 8 11:06:19 2016 +0100 > > MIPS: Use per-mm page to execute branch delay slot instructions > > With my vDSO hat on, I hereby offer a couple of straightforward > suggestions for fixing it. The offending code is: > > base = mmap_region(NULL, STACK_TOP, PAGE_SIZE, >VM_READ|VM_WRITE|VM_EXEC| >VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, >0, NULL); > > VM_WRITE | VM_EXEC is a big no-no, especially at a fixed address. > > The really simple but possibly suboptimal fix is to get rid of > VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it. > > A possibly nicer way to accomplish more or less the same thing would > be to allocate the area with _install_special_mapping() and arrange to > keep a reference to the struct page around. > > The really nice but less compatible fix would be to let processes or > even the whole system opt out by promising not to put anything in FPU > branch delay slots, of course. As I noted on Twitter when Mudge brought this topic back up, there's a much more compatible, elegant, and safe fix possible that does not involve any W+X memory. Emulate the delay slot in kernel-space. This is trivial to do safely for pretty much everything but loads/stores. For loads/stores, where you want them to execute with user privilege level, what you do is compute the effective address in kernel-space, then return to a fixed instruction in the vdso page that performs a generic load/store using the register the kernel put the effective address result in, then restores registers off the stack and jumps to the branch destination. Rich
RE: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Sunday, November 11, 2018 10:45 PM
> Subject: [RFC PATCH 1/5] iommu: Add APIs for IOMMU PASID management
>
> This adds APIs for IOMMU drivers and device drivers to manage the PASIDs used
> for
> DMA transfer and translation. It bases on I/O ASID allocator for PASID
> namespace
> management and relies on vendor specific IOMMU drivers for paravirtual PASIDs.
>
> Below APIs are added:
>
> * iommu_pasid_init(pasid)
> - Initialize a PASID consumer. The vendor specific IOMMU
> drivers are able to set the PASID range imposed by IOMMU
> hardware through a callback in iommu_ops.
>
> * iommu_pasid_exit(pasid)
> - The PASID consumer stops consuming any PASID.
>
> * iommu_pasid_alloc(pasid, min, max, private, *ioasid)
> - Allocate a PASID and associate a @private data with this
> PASID. The PASID value is stored in @ioaisd if returning
> success.
>
> * iommu_pasid_free(pasid, ioasid)
> - Free a PASID to the pool so that it could be consumed by
> others.
>
> This also adds below helpers to lookup or iterate PASID items associated with
> a
> consumer.
>
> * iommu_pasid_for_each(pasid, func, data)
> - Iterate PASID items of the consumer identified by @pasid,
> and call @func() against each item. An error returned from
> @func() will break the iteration.
>
> * iommu_pasid_find(pasid, ioasid)
> - Retrieve the private data associated with @ioasid.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Kevin Tian
> Cc: Jean-Philippe Brucker
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/Kconfig | 1 +
> drivers/iommu/iommu.c | 89 +++
> include/linux/iommu.h | 73 +++
> 3 files changed, 163 insertions(+)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index
> d9a25715650e..39f2bb76c7b8 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -1,6 +1,7 @@
> # IOMMU_API always gets selected by whoever wants it.
> config IOMMU_API
> bool
> + select IOASID
>
> menuconfig IOMMU_SUPPORT
> bool "IOMMU Hardware Support"
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index
> 0b7c96d1425e..570b244897bb 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2082,3 +2082,92 @@ void iommu_detach_device_aux(struct iommu_domain
> *domain, struct device *dev)
> }
> }
> EXPORT_SYMBOL_GPL(iommu_detach_device_aux);
> +
> +/*
> + * APIs for PASID used by IOMMU and the device drivers which depend
> + * on IOMMU.
> + */
> +struct iommu_pasid *iommu_pasid_init(struct bus_type *bus) {
I'm thinking about if using struct iommu_domain here is better
than struct bus_type. The major purpose is to pass iommu_ops
in it and route into iommu-sublayer. iommu_domain may be
better since some modules like vfio_iommu_type1 would use
iommu_domain more than bus type.
Thanks,
Yi Liu
Re: [PATCH] sched/debug: Add tracepoint for RT throttling
Hi Benjamin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Benjamin-Bouvier/sched-debug-Add-tracepoint-for-RT-throttling/20181216-050740
config: x86_64-randconfig-x001-201850 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:14:0,
from arch/x86/include/asm/percpu.h:45,
from arch/x86/include/asm/current.h:6,
from include/linux/sched.h:12,
from kernel//sched/sched.h:5,
from kernel//sched/rt.c:6:
kernel//sched/rt.c: In function 'sched_rt_runtime_exceeded':
>> kernel//sched/rt.c:934:59: error: 'struct rq' has no member named 'cpu'
rt_rq->rq->curr->pid, rt_rq->rq->curr->comm, rt_rq->rq->cpu);
^
include/linux/printk.h:372:26: note: in definition of macro
'printk_deferred_once'
printk_deferred(fmt, ##__VA_ARGS__); \
^~~
kernel//sched/rt.c:935:56: error: 'struct rq' has no member named 'cpu'
trace_sched_rt_throttling(rt_rq->rq->curr, rt_rq->rq->cpu);
^~
vim +934 kernel//sched/rt.c
907
908 static int sched_rt_runtime_exceeded(struct rt_rq *rt_rq)
909 {
910 u64 runtime = sched_rt_runtime(rt_rq);
911
912 if (rt_rq->rt_throttled)
913 return rt_rq_throttled(rt_rq);
914
915 if (runtime >= sched_rt_period(rt_rq))
916 return 0;
917
918 balance_runtime(rt_rq);
919 runtime = sched_rt_runtime(rt_rq);
920 if (runtime == RUNTIME_INF)
921 return 0;
922
923 if (rt_rq->rt_time > runtime) {
924 struct rt_bandwidth *rt_b = sched_rt_bandwidth(rt_rq);
925
926 /*
927 * Don't actually throttle groups that have no runtime
assigned
928 * but accrue some time due to boosting.
929 */
930 if (likely(rt_b->rt_runtime)) {
931 rt_rq->rt_throttled = 1;
932 printk_deferred_once(
933 "sched: RT throttling activated for
task pid %d (%s) on cpu:%d\n",
> 934 rt_rq->rq->curr->pid,
> rt_rq->rq->curr->comm, rt_rq->rq->cpu);
935 trace_sched_rt_throttling(rt_rq->rq->curr,
rt_rq->rq->cpu);
936 } else {
937 /*
938 * In case we did anyway, make it go away,
939 * replenishment is a joke, since it will
replenish us
940 * with exactly 0 ns.
941 */
942 rt_rq->rt_time = 0;
943 }
944
945 if (rt_rq_throttled(rt_rq)) {
946 sched_rt_rq_dequeue(rt_rq);
947 return 1;
948 }
949 }
950
951 return 0;
952 }
953
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 7/9] arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO
Hi,
> Olof Johansson hat am 13. Dezember 2018 um 07:48 geschrieben:
>
>
> On Fri, Nov 09, 2018 at 06:05:24AM +, Horia Geanta wrote:
> > On 11/9/2018 3:11 AM, Marc Gonzalez wrote:
> > > Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
> > > enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
> > > which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
> > > CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
> > >
> > > Signed-off-by: Marc Gonzalez
> > Reviewed-by: Horia Geantă
>
> I had to redo this one, and when I did I noticed that there's also an ethernet
> driver. Should that be enabled as well?
>
this patch in next-20181214 breaks "make modules_install" for arm64/defconfig
on my Ubuntu machine:
DEPMOD 4.20.0-rc6-next-20181214
depmod: ERROR: Found 6 modules in dependency cycles!
depmod: ERROR: Cycle detected: caamalg_desc -> dpaa2_caam -> authenc
depmod: ERROR: Cycle detected: caamalg_desc -> dpaa2_caam -> fsl_mc_dpio
depmod: ERROR: Cycle detected: dpaa2_caam -> caamhash_desc -> dpaa2_caam
depmod: ERROR: Cycle detected: caamalg_desc -> dpaa2_caam -> caamhash_desc ->
error
depmod: ERROR: Cycle detected: caamalg_desc -> dpaa2_caam -> caamhash_desc ->
caamalg_desc
After reverting of this patch the issue disappeared.
Stefan
Re: Fixing MIPS delay slot emulation weakness?
Hi Andy, On Sat, Dec 15, 2018 at 11:19:37AM -0800, Andy Lutomirski wrote: > Some security researchers pointed out that writing to the delay slot > emulation page is a great exploit technique on MIPS. It was > introduced in: > > commit 432c6bacbd0c16ec210c43da411ccc3855c4c010 > Author: Paul Burton > Date: Fri Jul 8 11:06:19 2016 +0100 > > MIPS: Use per-mm page to execute branch delay slot instructions Are there any further details you can share? You'd still need to persuade a program to both write to & jump to the page, right? We're talking purely about this providing writable+executable memory? For the record prior to this patch we had to keep the user's stack executable & write instructions there, so this didn't make things any worse. > With my vDSO hat on, I hereby offer a couple of straightforward > suggestions for fixing it. The offending code is: > > base = mmap_region(NULL, STACK_TOP, PAGE_SIZE, >VM_READ|VM_WRITE|VM_EXEC| >VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, >0, NULL); > > VM_WRITE | VM_EXEC is a big no-no, especially at a fixed address. > > The really simple but possibly suboptimal fix is to get rid of > VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it. > > A possibly nicer way to accomplish more or less the same thing would > be to allocate the area with _install_special_mapping() and arrange to > keep a reference to the struct page around. Right, I can look into that. > The really nice but less compatible fix would be to let processes or > even the whole system opt out by promising not to put anything in FPU > branch delay slots, of course. The ultimate fix comes with a switch to the nanoMIPS ISA which has no delay slots :) Thanks, Paul
[PATCH] ARM: Ensure that NEON code always compiles with Clang
While building arm32 allyesconfig, I ran into the following errors:
arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with
'-mfloat-abi=softfp -mfpu=neon'
In file included from lib/raid6/neon1.c:27:
/home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2:
error: "NEON support not enabled"
Building V=1 showed NEON_FLAGS getting passed along to Clang but
__ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang
only defining __ARM_NEON__ when targeting armv7, rather than armv6k,
which is the '-march' value for allyesconfig.
>From lib/Basic/Targets/ARM.cpp in the Clang source:
// This only gets set when Neon instructions are actually available, unlike
// the VFP define, hence the soft float and arch check. This is subtly
// different from gcc, we follow the intent which was that it should be set
// when Neon instructions are actually available.
if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) {
Builder.defineMacro("__ARM_NEON", "1");
Builder.defineMacro("__ARM_NEON__");
// current AArch32 NEON implementations do not support double-precision
// floating-point even when it is present in VFP.
Builder.defineMacro("__ARM_NEON_FP",
"0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP));
}
Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the
beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets
definined by Clang. This doesn't functionally change anything because
that code will only run where NEON is supported, which is implicitly
armv7.
Link: https://github.com/ClangBuiltLinux/linux/issues/287
Suggested-by: Ard Biesheuvel
Signed-off-by: Nathan Chancellor
---
Documentation/arm/kernel_mode_neon.txt | 4 ++--
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/xor-neon.c| 2 +-
lib/raid6/Makefile | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/arm/kernel_mode_neon.txt
b/Documentation/arm/kernel_mode_neon.txt
index 525452726d31..b9e060c5b61e 100644
--- a/Documentation/arm/kernel_mode_neon.txt
+++ b/Documentation/arm/kernel_mode_neon.txt
@@ -6,7 +6,7 @@ TL;DR summary
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
- '-mfpu=neon -mfloat-abi=softfp'
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into
your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
@@ -87,7 +87,7 @@ instructions appearing in unexpected places if no special
care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
- '-mfpu=neon -mfloat-abi=softfp';
+ '-march=armv7-a -mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the
calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index ad25fd1872c7..0bff0176db2c 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -39,7 +39,7 @@ $(obj)/csumpartialcopy.o: $(obj)/csumpartialcopygeneric.S
$(obj)/csumpartialcopyuser.o: $(obj)/csumpartialcopygeneric.S
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
- NEON_FLAGS := -mfloat-abi=softfp -mfpu=neon
+ NEON_FLAGS := -march=armv7-a -mfloat-abi=softfp -mfpu=neon
CFLAGS_xor-neon.o+= $(NEON_FLAGS)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
endif
diff --git a/arch/arm/lib/xor-neon.c b/arch/arm/lib/xor-neon.c
index a6741a895189..4600b62d845f 100644
--- a/arch/arm/lib/xor-neon.c
+++ b/arch/arm/lib/xor-neon.c
@@ -14,7 +14,7 @@
MODULE_LICENSE("GPL");
#ifndef __ARM_NEON__
-#error You should compile this file with '-mfloat-abi=softfp -mfpu=neon'
+#error You should compile this file with '-march=armv7-a -mfloat-abi=softfp
-mfpu=neon'
#endif
/*
diff --git a/lib/raid6/Makefile b/lib/raid6/Makefile
index 2f8b61dfd9b0..bfec7c87c61e 100644
--- a/lib/raid6/Makefile
+++ b/lib/raid6/Makefile
@@ -25,7 +25,7 @@ endif
ifeq ($(CONFIG_KERNEL_MODE_NEON),y)
NEON_FLAGS := -ffreestanding
ifeq ($(ARCH),arm)
-NEON_FLAGS += -mfloat-abi=softfp -mfpu=neon
+NEON_FLAGS += -march=armv7-a -mfloat-abi=softfp -mfpu=neon
endif
CFLAGS_recov_neon_inner.o += $(NEON_FLAGS)
ifeq ($(ARCH),arm64)
--
2.20.1
Re: [PATCH net-next v3 0/4] net: mitigate retpoline overhead
From: Paolo Abeni Date: Fri, 14 Dec 2018 11:51:56 +0100 > The spectre v2 counter-measures, aka retpolines, are a source of measurable > overhead[1]. We can partially address that when the function pointer refers to > a builtin symbol resorting to a list of tests vs well-known builtin function > and > direct calls. > > Experimental results show that replacing a single indirect call via > retpoline with several branches and a direct call gives performance gains > even when multiple branches are added - 5 or more, as reported in [2]. > > This may lead to some uglification around the indirect calls. In netconf 2018 > Eric Dumazet described a technique to hide the most relevant part of the > needed > boilerplate with some macro help. > > This series is a [re-]implementation of such idea, exposing the introduced > helpers in a new header file. They are later leveraged to avoid the indirect > call overhead in the GRO path, when possible. > > Overall this gives > 10% performance improvement for UDP GRO benchmark and > smaller but measurable for TCP syn flood. > > The added infra can be used in follow-up patches to cope with retpoline > overhead > in other points of the networking stack (e.g. at the qdisc layer) and possibly > even in other subsystems. ... Series applied, I'll push this out after a build check completes. Thanks.
Re: [PATCH v2] net: macb: restart tx after tx used bit read
From: Date: Fri, 14 Dec 2018 10:40:47 + > From: Claudiu Beznea > > On some platforms (currently detected only on SAMA5D4) TX might stuck > even the pachets are still present in DMA memories and TX start was > issued for them. This happens due to race condition between MACB driver > updating next TX buffer descriptor to be used and IP reading the same > descriptor. In such a case, the "TX USED BIT READ" interrupt is asserted. > GEM/MACB user guide specifies that if a "TX USED BIT READ" interrupt > is asserted TX must be restarted. Restart TX if used bit is read and > packets are present in software TX queue. Packets are removed from software > TX queue if TX was successful for them (see macb_tx_interrupt()). > > Signed-off-by: Claudiu Beznea > --- > > changes in v2: > - use "static inline" instead of "inline static" for macb_tx_restart() Yes that is the correct order for a static inline function declaration, but in foo.c files we do not use the inline keyword and instead let the compiler decide the best thing to do. Please remove this inline keyword and resubmit. Thank you.
[PATCH 1/1] efi: efi_guid_t must be 64-bit aligned
The UEFI Specification Version 2.7 Errata A defines: "EFI_GUID 128-bit buffer containing a unique identifier value. Unless otherwise specified, aligned on a 64-bit boundary." Before this patch efi_guid_t was 8-bit aligned. Signed-off-by: Heinrich Schuchardt --- include/linux/efi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/efi.h b/include/linux/efi.h index 845174e113ce..c1a1931238c5 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -48,7 +48,7 @@ typedef u16 efi_char16_t; /* UNICODE character */ typedef u64 efi_physical_addr_t; typedef void *efi_handle_t; -typedef guid_t efi_guid_t; +typedef guid_t efi_guid_t __aligned(8); #define EFI_GUID(a,b,c,d0,d1,d2,d3,d4,d5,d6,d7) \ GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) -- 2.19.2
Re: [PATCH net-next 3/3] vhost: access vq metadata through kernel virtual address
From: Jason Wang Date: Fri, 14 Dec 2018 11:57:35 +0800 > This is the price of all GUP users not only vhost itself. What's more > important, the goal is not to be left too much behind for other > backends like DPDK or AF_XDP (all of which are using GUP). +1
Re: [PATCH] dt-bindings: net: ravb: Add support for r8a774c0 SoC
From: Fabrizio Castro Date: Thu, 13 Dec 2018 20:18:34 + > Document RZ/G2E (R8A774C0) SoC bindings. > > Signed-off-by: Fabrizio Castro Applied to net-next.
Time zones
Is it possible to tell the kernel what time zone the RTC is in? Right now it appears to assume that it's always in UTC, and this causes a few headaches during the boot process. As it is I tried to file a bug to have openrc activate hwclock earlier, but it was rejected.
Re: [PATCH v8 20/22] tracing: Use hist trigger's var_ref array to destroy var_refs
Hi Namhyung, On Sat, 2018-12-15 at 15:50 +0900, Namhyung Kim wrote: > Hi Tom and Masami, > > On Sat, Dec 15, 2018 at 2:29 AM Tom Zanussi > wrote: > > > > Hi Masami, > > > > On Sat, 2018-12-15 at 01:31 +0900, Masami Hiramatsu wrote: > > > On Mon, 10 Dec 2018 18:01:34 -0600 > > > Tom Zanussi wrote: > > > > > > > From: Tom Zanussi > > > > > > > > Since every var ref for a trigger has an entry in the var_ref[] > > > > array, > > > > use that to destroy the var_refs, instead of piecemeal via the > > > > field > > > > expressions. > > > > > > > > This allows us to avoid having to keep and treat differently > > > > separate > > > > lists for the action-related references, which future patches > > > > will > > > > remove. > > > > > > I'm not so sure, but this seems a bugfix... if so, please move > > > this > > > at > > > the top of this series. > > > > > > > No, none of these are bugfixes - patches 17-22 are just some > > additional > > cleanup that try to make the code easier to follow after Namhyung's > > comments that things were confusing here. > > > > Actually, what I should probably do is make these a separate > > series.. > > Agreed, I also think it's getting bigger and having these cleanups > before the actual change would make things little bit easier IMHO. > Yep, that's what I'll do then. Thanks, Tom
Re: [PATCH v2 6/8] socket: Add SO_TIMESTAMP[NS]_NEW
> > Also for the other comment. The reason the conditionals were not
> > consistent is because they were not consistent to begin with.
>
> The only difference I see is an inversion of the test. Nesting order
> is the same:
>
> int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
> ...
> if (need_software_tstamp) {
> if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
> }
>
> vs
>
> if (sock_flag(sk, SOCK_RCVTSTAMP)) {
> if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
> }
>
> I suggest just adding something like
>
> if (need_software_tstamp) {
> + if (sock_uses_new_tstamp(sk) {
> + __sock_recv_timestamp_new(msg, sk,
> ktime_to_timespec64(skb->tstamp));
> + } else if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> - if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
>
> and
>
> if (sock_flag(sk, SOCK_RCVTSTAMP)) {
> + if (sock_uses_new_tstamp(sk) {
> + __sock_recv_timestamp_new(msg, sk, ts);
> + else if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> - if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
> } else {
> }
>
> I think we can use the same helper for both the sock and tcp variant.
> The only intended difference between the two functions, as described
> in the tcp_recv_timestamp function comment, is the absence of an skb
> in the tcp case. That is immaterial at this level.
I will just not refactor things into a function: __sock_rescv_timestamp_new().
I will just add new conditionals for the new timestamps.
When you guys refactor the other timestamp stuff like you mentioned
below maybe you can move the new timestamps to a new funtcion as you
see fit.
The helper functions in skbuff.h might first need to be refactored
first. But I again leave this to you guys.
> Note also (2) tentative helper function sock_uses_new_tstamp(const
> struct sock *sk) instead of testing sock_flag(sk, SOCK_TSTAMP_NEW)
> directly. Since the .._NEW variants are equivalent to .._OLD on 64-bit,
> I wonder if we can just compile out the branch. Something like
>
> static inline bool sock_uses_new_tstamp(const struct sock *sk) {
> return (sizeof(time_t) != sizeof(__kernel_long_t)) &&
>sock_flag(sk, SOCK_TSTAMP_NEW);
> }
>
You could just ifdef CONFIG_64BIT if you are worried about branching.
Note that SO_TIMESTAMP is by default SO_TIMESTAMP_OLD on 64 bit machines.
But, I will again leave the optimization to you. I will implement in a
straight forward way and you guys can deicde how you want to optimize
the fast path or what should it even be.
-Deepa
<<>>
Greetings!! Apologies should my message be a disturbance to you.My Name is Peter Owen a fund/Investment Manager with a high profile investment company.A huge Sum of funds has been diverted, representing 1.2% of Excess Magellan Capital Funds from the Investor Capital Project Funds. I am contacting you strictly for us to work this deal out so that we can claim the funds as mentioned above. Be assured that this is highly confidential and your integrity will be protected. You must consider this a professionally arranged business deal and should respond ONLY if you can exhibit 100% commitment. Sincerely, Peter Owen
[PATCH] crypto: x86/chacha - avoid sleeping under kernel_fpu_begin()
From: Eric Biggers
Passing atomic=true to skcipher_walk_virt() only makes the later
skcipher_walk_done() calls use atomic memory allocations, not
skcipher_walk_virt() itself. Thus, we have to move it outside of the
preemption-disabled region (kernel_fpu_begin()/kernel_fpu_end()).
(skcipher_walk_virt() only allocates memory for certain layouts of the
input scatterlist, hence why I didn't notice this earlier...)
Reported-by: syzbot+9bf843c33f782d73a...@syzkaller.appspotmail.com
Fixes: 4af78261870a ("crypto: x86/chacha20 - add XChaCha20 support")
Signed-off-by: Eric Biggers
---
arch/x86/crypto/chacha_glue.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/crypto/chacha_glue.c b/arch/x86/crypto/chacha_glue.c
index 9b1d3fac49433..45c1c41431766 100644
--- a/arch/x86/crypto/chacha_glue.c
+++ b/arch/x86/crypto/chacha_glue.c
@@ -127,30 +127,27 @@ static void chacha_dosimd(u32 *state, u8 *dst, const u8
*src,
}
}
-static int chacha_simd_stream_xor(struct skcipher_request *req,
+static int chacha_simd_stream_xor(struct skcipher_walk *walk,
struct chacha_ctx *ctx, u8 *iv)
{
u32 *state, state_buf[16 + 2] __aligned(8);
- struct skcipher_walk walk;
int next_yield = 4096; /* bytes until next FPU yield */
- int err;
+ int err = 0;
BUILD_BUG_ON(CHACHA_STATE_ALIGN != 16);
state = PTR_ALIGN(state_buf + 0, CHACHA_STATE_ALIGN);
- err = skcipher_walk_virt(, req, true);
-
crypto_chacha_init(state, ctx, iv);
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
+ while (walk->nbytes > 0) {
+ unsigned int nbytes = walk->nbytes;
- if (nbytes < walk.total) {
- nbytes = round_down(nbytes, walk.stride);
+ if (nbytes < walk->total) {
+ nbytes = round_down(nbytes, walk->stride);
next_yield -= nbytes;
}
- chacha_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr,
+ chacha_dosimd(state, walk->dst.virt.addr, walk->src.virt.addr,
nbytes, ctx->nrounds);
if (next_yield <= 0) {
@@ -160,7 +157,7 @@ static int chacha_simd_stream_xor(struct skcipher_request
*req,
next_yield = 4096;
}
- err = skcipher_walk_done(, walk.nbytes - nbytes);
+ err = skcipher_walk_done(walk, walk->nbytes - nbytes);
}
return err;
@@ -170,13 +167,18 @@ static int chacha_simd(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
+ struct skcipher_walk walk;
int err;
if (req->cryptlen <= CHACHA_BLOCK_SIZE || !irq_fpu_usable())
return crypto_chacha_crypt(req);
+ err = skcipher_walk_virt(, req, true);
+ if (err)
+ return err;
+
kernel_fpu_begin();
- err = chacha_simd_stream_xor(req, ctx, req->iv);
+ err = chacha_simd_stream_xor(, ctx, req->iv);
kernel_fpu_end();
return err;
}
@@ -185,6 +187,7 @@ static int xchacha_simd(struct skcipher_request *req)
{
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
+ struct skcipher_walk walk;
struct chacha_ctx subctx;
u32 *state, state_buf[16 + 2] __aligned(8);
u8 real_iv[16];
@@ -193,6 +196,10 @@ static int xchacha_simd(struct skcipher_request *req)
if (req->cryptlen <= CHACHA_BLOCK_SIZE || !irq_fpu_usable())
return crypto_xchacha_crypt(req);
+ err = skcipher_walk_virt(, req, true);
+ if (err)
+ return err;
+
BUILD_BUG_ON(CHACHA_STATE_ALIGN != 16);
state = PTR_ALIGN(state_buf + 0, CHACHA_STATE_ALIGN);
crypto_chacha_init(state, ctx, req->iv);
@@ -204,7 +211,7 @@ static int xchacha_simd(struct skcipher_request *req)
memcpy(_iv[0], req->iv + 24, 8);
memcpy(_iv[8], req->iv + 16, 8);
- err = chacha_simd_stream_xor(req, , real_iv);
+ err = chacha_simd_stream_xor(, , real_iv);
kernel_fpu_end();
--
2.19.2
Re: [PATCH] ubifs: Get/put page when changing PG_private
On 2018/12/15 下午11:01, Richard Weinberger wrote:
The page migration code assumes that a page with PG_private
set has its page count elevated by 1.
UBIFS never did this and therefore the migration code was unable
to migrate some pages owned by UBIFS.
The lead to situations where the CMA memory allocator failed to
allocate memory.
Fix this by using get/put_page when changing PG_private.
Cc:
Cc: zhangjun
Fixes: 4ac1c17b2044 ("UBIFS: Implement ->migratepage()")
Reported-by: zhangjun
Signed-off-by: Richard Weinberger
---
zhangjun,
Please give this patch a try!
Thanks,
//richard
---
fs/ubifs/file.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index 1b78f2e09218..abe940d0767c 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -582,6 +582,7 @@ static int ubifs_write_end(struct file *file, struct
address_space *mapping,
}
if (!PagePrivate(page)) {
+ get_page(page);
SetPagePrivate(page);
atomic_long_inc(>dirty_pg_cnt);
__set_page_dirty_nobuffers(page);
@@ -959,6 +960,7 @@ static int do_writepage(struct page *page, int len)
atomic_long_dec(>dirty_pg_cnt);
ClearPagePrivate(page);
ClearPageChecked(page);
+ put_page(page);
kunmap(page);
unlock_page(page);
@@ -1318,6 +1320,7 @@ static void ubifs_invalidatepage(struct page *page,
unsigned int offset,
atomic_long_dec(>dirty_pg_cnt);
ClearPagePrivate(page);
ClearPageChecked(page);
+ put_page(page);
}
int ubifs_fsync(struct file *file, loff_t start, loff_t end, int datasync)
@@ -1487,6 +1490,8 @@ static int ubifs_migrate_page(struct address_space
*mapping,
if (PagePrivate(page)) {
ClearPagePrivate(page);
+ put_page(page);
+ get_page(newpage);
SetPagePrivate(newpage);
}
@@ -1513,6 +1518,7 @@ static int ubifs_releasepage(struct page *page, gfp_t unused_gfp_flags)
ubifs_assert(c, 0);
ClearPagePrivate(page);
ClearPageChecked(page);
+ put_page(page);
return 1;
}
@@ -1582,6 +1588,7 @@ static vm_fault_t ubifs_vm_page_mkwrite(struct vm_fault *vmf)
else {
if (!PageChecked(page))
ubifs_convert_page_budget(c);
+ get_page(page);
SetPagePrivate(page);
atomic_long_inc(>dirty_pg_cnt);
__set_page_dirty_nobuffers(page);
Hello Richard
After adding your patch,my test did not go wrong.
I think it is ok now.
thanks
//zhangjun
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Hi Lucas,
Thank you for your patch, just some small comments below.
On 12/15/18 2:46 PM, Lucas A. M. Magalhães wrote:
> The previous code pipeline used the stack to walk on the graph and
> process a frame. Basically the vimc-sensor entity starts a thread that
> generates the frames and calls the propagate_process function to send
> this frame to each entity linked with a sink pad. The propagate_process
> will call the process_frame of the entities which will call the
> propagate_frame for each one of it's sink pad. This cycle will continue
> until it reaches a vimc-capture entity that will finally return and
> unstack.
>
> This solution had many problems:
> * It was a little bit slow
> * It was susceptible to a stack overflow as it made indiscriminate
> use of the stack.
> * It doesn't allow frame rate control
> * It was complex to understand
> * It doesn't allow pipeline control
>
> This commit proposes an alternative way to control vimc streams by
> having a streamer object. This object will create a linear pipeline
> walking backwards on the graph. When the stream starts it will simply
> loop through the pipeline calling the respective process_frame function
> for each entity on the pipeline.
>
> This solution has some premises which are true for now:
> * Two paths can never be enabled and streaming at the same time.
> * There is no entity streaming frames to two source pads at the same
> time.
> * There is no entity receiving frames from two sink pads at the same
> time.
>
> Signed-off-by: Lucas A. M. Magalhães
I won't comment on the commit message, as Mauro already sent a good review.
> ---
> Hi,
>
> This patch introduces a streamer controller library for the vimc
> driver. It's a step towards a optimized mode I've been discussing with
> Helen.
> I plan to pass a tpg struct through the pipeline. This tpg struct
> will be configured in each entity and the capture will generate the
> frames with the correct format at the end of the pipeline.
>
> Thanks,
> Lucas
>
> drivers/media/platform/vimc/Makefile| 3 +-
> drivers/media/platform/vimc/vimc-capture.c | 18 +-
> drivers/media/platform/vimc/vimc-common.c | 50 ++
> drivers/media/platform/vimc/vimc-common.h | 15 +-
> drivers/media/platform/vimc/vimc-debayer.c | 26 +--
> drivers/media/platform/vimc/vimc-scaler.c | 28 +---
> drivers/media/platform/vimc/vimc-sensor.c | 56 ++-
> drivers/media/platform/vimc/vimc-streamer.c | 176
> drivers/media/platform/vimc/vimc-streamer.h | 38 +
> 9 files changed, 268 insertions(+), 142 deletions(-)
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.c
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.h
>
> diff --git a/drivers/media/platform/vimc/Makefile
> b/drivers/media/platform/vimc/Makefile
> index 4b2e3de7856e..c4fc8e7d365a 100644
> --- a/drivers/media/platform/vimc/Makefile
> +++ b/drivers/media/platform/vimc/Makefile
> @@ -5,6 +5,7 @@ vimc_common-objs := vimc-common.o
> vimc_debayer-objs := vimc-debayer.o
> vimc_scaler-objs := vimc-scaler.o
> vimc_sensor-objs := vimc-sensor.o
> +vimc_streamer-objs := vimc-streamer.o
>
> obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o
> vimc-debayer.o \
> - vimc_scaler.o vimc_sensor.o
> + vimc_scaler.o vimc_sensor.o vimc_streamer.o
> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c
> index 3f7e9ed56633..80d7515ec420 100644
> --- a/drivers/media/platform/vimc/vimc-capture.c
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -24,6 +24,7 @@
> #include
>
> #include "vimc-common.h"
> +#include "vimc-streamer.h"
>
> #define VIMC_CAP_DRV_NAME "vimc-capture"
>
> @@ -44,7 +45,7 @@ struct vimc_cap_device {
> spinlock_t qlock;
> struct mutex lock;
> u32 sequence;
> - struct media_pipeline pipe;
> + struct vimc_stream stream;
> };
>
> static const struct v4l2_pix_format fmt_default = {
> @@ -248,14 +249,13 @@ static int vimc_cap_start_streaming(struct vb2_queue
> *vq, unsigned int count)
> vcap->sequence = 0;
>
> /* Start the media pipeline */
> - ret = media_pipeline_start(entity, >pipe);
> + ret = media_pipeline_start(entity, >stream.pipe);
> if (ret) {
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> return ret;
> }
>
> - /* Enable streaming from the pipe */
> - ret = vimc_pipeline_s_stream(>vdev.entity, 1);
> + ret = vimc_streamer_s_stream(>stream, >ved, 1);
> if (ret) {
> media_pipeline_stop(entity);
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> @@ -273,8 +273,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
> {
> struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
>
> - /* Disable streaming from the pipe */
> -
Re: [PATCH net v2] net: ipv4: do not handle duplicate fragments as overlapping
From: Michal Kubecek
Date: Thu, 13 Dec 2018 17:23:32 +0100 (CET)
> Since commit 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping
> segments.") IPv4 reassembly code drops the whole queue whenever an
> overlapping fragment is received. However, the test is written in a way
> which detects duplicate fragments as overlapping so that in environments
> with many duplicate packets, fragmented packets may be undeliverable.
>
> Add an extra test and for (potentially) duplicate fragment, only drop the
> new fragment rather than the whole queue. Only starting offset and length
> are checked, not the contents of the fragments as that would be too
> expensive. For similar reason, linear list ("run") of a rbtree node is not
> iterated, we only check if the new fragment is a subset of the interval
> covered by existing consecutive fragments.
>
> Fixes: 7969e5c40dfd ("ip: discard IPv4 datagrams with overlapping segments.")
> Signed-off-by: Michal Kubecek
>
> v2: instead of an exact check iterating through linear list of an rbtree
> node, only check if the new fragment is subset of the "run" (suggested
> by Eric Dumazet)
Applied and queued up for -stable, thank you.
Re: [PATCH 4.19 001/142] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes
On 2018-12-14 12:58, Greg Kroah-Hartman wrote: 4.19-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Wiesner [ Upstream commit ebaf39e6032faf77218220707fc3fa22487784e0 ] The patch under review should to be applied to 4.19-stable.
Re: [PATCH 4.14 01/89] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes
On 2018-12-14 12:59, Greg Kroah-Hartman wrote: 4.14-stable review patch. If anyone has any objections, please let me know. -- From: Jiri Wiesner [ Upstream commit ebaf39e6032faf77218220707fc3fa22487784e0 ] I am sorry for forgetting to mention (and to include a tag) that the patch actually fixed v4.10-rc4-868-g158f323b9868, which introduced changing the truesize member in pskb_expand_head(). The patch under review needs to be applied to 4.14-stable and 4.19-stable only.
Re: [PATCH] vhost: return EINVAL if iovecs size does not match the message size
From: Pavel Tikhomirov Date: Thu, 13 Dec 2018 17:53:50 +0300 > We've failed to copy and process vhost_iotlb_msg so let userspace at > least know about it. For instance before these patch the code below runs > without any error: ... > Signed-off-by: Pavel Tikhomirov Michael, will you be taking this in via your tree? Thanks.
Re: [PATCH net-next 0/3] vhost: accelerate metadata access through vmap()
From: Jason Wang Date: Fri, 14 Dec 2018 12:29:54 +0800 > > On 2018/12/14 上午4:12, Michael S. Tsirkin wrote: >> On Thu, Dec 13, 2018 at 06:10:19PM +0800, Jason Wang wrote: >>> Hi: >>> >>> This series tries to access virtqueue metadata through kernel virtual >>> address instead of copy_user() friends since they had too much >>> overheads like checks, spec barriers or even hardware feature >>> toggling. >>> >>> Test shows about 24% improvement on TX PPS. It should benefit other >>> cases as well. >>> >>> Please review >> I think the idea of speeding up userspace access is a good one. >> However I think that moving all checks to start is way too aggressive. > > > So did packet and AF_XDP. Anyway, sharing address space and access > them directly is the fastest way. Performance is the major > consideration for people to choose backend. Compare to userspace > implementation, vhost does not have security advantages at any > level. If vhost is still slow, people will start to develop backends > based on e.g AF_XDP. Exactly, this is precisely how this kind of problem should be solved. Michael, I strongly support the approach Jason is taking here, and I would like to ask you to seriously reconsider your objections. Thank you.
Re: [PATCH] power: supply: isp1704: switch to gpiod API
On Thu 2018-12-13 02:38:58, Sebastian Reichel wrote: > This migrates isp1704 driver from old GPIO API to new descriptor > based GPIO API and drops useless platform data as a side-effect. > > Migration is simple, since all mainline users are DT based and > DT API does not change. Out of tree users of the platform data > need to migrate to gpiod_lookup_table as described here: > > Documentation/driver-api/gpio/board.rst > > Signed-off-by: Sebastian Reichel Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: WARNING in ovl_instantiate
syzbot has found a reproducer for the following crash on: HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=143f9a1540 kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140 dashboard link: https://syzkaller.appspot.com/bug?extid=9c69c282adc4edd2b540 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a6e54340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+9c69c282adc4edd2b...@syzkaller.appspotmail.com overlayfs: filesystem on './file0' not supported as upperdir overlayfs: filesystem on './file0' not supported as upperdir overlayfs: filesystem on './file0' not supported as upperdir overlayfs: filesystem on './file0' not supported as upperdir overlayfs: filesystem on './file0' not supported as upperdir WARNING: CPU: 1 PID: 28918 at fs/overlayfs/dir.c:263 ovl_instantiate+0x369/0x400 fs/overlayfs/dir.c:263 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 28918 Comm: syz-executor1 Not tainted 4.20.0-rc6-next-20181214+ #171 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+0x244/0x39d lib/dump_stack.c:113 panic+0x2ad/0x632 kernel/panic.c:214 __warn.cold.8+0x20/0x4f kernel/panic.c:571 report_bug+0x254/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973 RIP: 0010:ovl_instantiate+0x369/0x400 fs/overlayfs/dir.c:263 Code: c3 89 c6 e8 89 35 ed fe 85 db 0f 85 9e 00 00 00 e8 6c 34 ed fe 4c 89 e7 45 31 f6 e8 a1 b1 44 ff e9 ec fe ff ff e8 57 34 ed fe <0f> 0b e9 e0 fe ff ff e8 4b 34 ed fe 0f 0b e9 63 ff ff ff e8 ef 88 RSP: 0018:8881ca6679a8 EFLAGS: 00010293 RAX: 8881d39c44c0 RBX: 8881ca667a40 RCX: 8292cd44 RDX: RSI: 8292cec9 RDI: 0007 RBP: 8881ca667a68 R08: 8881d39c44c0 R09: ed10394ccee8 R10: ed10394ccee8 R11: 0003 R12: 8881a357c8c0 R13: 8881ca6679e0 R14: ff8c R15: ovl_create_over_whiteout fs/overlayfs/dir.c:518 [inline] ovl_create_or_link+0xad6/0x1560 fs/overlayfs/dir.c:582 ovl_create_object+0x2e9/0x3a0 fs/overlayfs/dir.c:616 ovl_symlink+0x24/0x30 fs/overlayfs/dir.c:651 vfs_symlink+0x37a/0x5d0 fs/namei.c:4127 do_symlinkat+0x242/0x2d0 fs/namei.c:4154 __do_sys_symlink fs/namei.c:4173 [inline] __se_sys_symlink fs/namei.c:4171 [inline] __x64_sys_symlink+0x59/0x80 fs/namei.c:4171 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457659 Code: fd b3 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 b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fbde1680c78 EFLAGS: 0246 ORIG_RAX: 0058 RAX: ffda RBX: 0002 RCX: 00457659 RDX: RSI: 2140 RDI: 2040 RBP: 0072bf00 R08: R09: R10: R11: 0246 R12: 7fbde16816d4 R13: 004c532d R14: 004d97a0 R15: Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH 1/1] net-next/hinic:optmize rx refill buffer mechanism
From: Xue Chaojing Date: Sun, 9 Dec 2018 19:14:19 + > There is no need to schedule a different tasklet for refill, > This patch remove it. > > Suggested-by: Neil Horman > Signed-off-by: Xue Chaojing I completely agree with Neil's analysis. You should never receive a packet if refilling the ring entry resources fails. It is so dangerous to allow the RX ring to reach an empty state, not only does it mean that the device will stop receiving frames but also this is probably one of the least tested conditions in ring based networking designs and it proabably has bugs that hang the chip and require a HW reset to recover from.
Re: [PATCH net-next] tcp: minor optimization for calculating packets_out in tcp connect
From: Eric Dumazet Date: Sat, 15 Dec 2018 04:59:00 -0800 > > > On 12/15/2018 01:33 AM, Yafang Shao wrote: >> When we building a syn packet, the tcp_skb_pcount(skb) is always 1, >> which is set in tcp_init_nondata_skb(). >> Regarding the syn_data, it is set through >> memcpy(syn_data->cb, syn->cb, sizeof(syn->cb)), >> which is always 1 as well. >> >> So we don't need to use tcp_skb_pcount(skb), that could give us a >> little improvement. >> > > I dunno, I find current code more self-documented. > > This is not fast path, so I would suggest we keep it. I agree, I won't be applying this.
Re: [PATCH 22/52] Create a list of free memory ranges
Hi Vivek, I love your patch! Yet something to improve: [auto build test ERROR on fuse/for-next] [also build test ERROR on v4.20-rc6] [cannot apply to next-20181214] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Vivek-Goyal/virtio-fs-shared-file-system-for-virtual-machines/20181211-103034 base: https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-next config: nds32-defconfig (attached as .config) compiler: nds32le-linux-gcc (GCC) 6.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=6.4.0 make.cross ARCH=nds32 All errors (new ones prefixed by >>): fs/fuse/inode.o: In function `fuse_fill_super_common': >> inode.c:(.text+0x1c00): undefined reference to `dax_read_lock' inode.c:(.text+0x1c04): undefined reference to `dax_read_lock' >> inode.c:(.text+0x1c22): undefined reference to `dax_direct_access' inode.c:(.text+0x1c26): undefined reference to `dax_direct_access' >> inode.c:(.text+0x1c32): undefined reference to `dax_read_unlock' inode.c:(.text+0x1c36): undefined reference to `dax_read_unlock' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] ipconfig: convert to DEFINE_SHOW_ATTRIBUTE
From: Yangtao Li Date: Sat, 15 Dec 2018 02:19:53 -0500 > Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. > > Signed-off-by: Yangtao Li Applied.
Re: [PATCH] cxgb4: remove DEFINE_SIMPLE_DEBUGFS_FILE()
From: Yangtao Li Date: Sat, 15 Dec 2018 02:59:30 -0500 > We already have the DEFINE_SHOW_ATTRIBUTE. There is no need to define > such a macro, so remove DEFINE_SIMPLE_DEBUGFS_FILE. Also use the > DEFINE_SHOW_ATTRIBUTE macro to simplify some code. > > Signed-off-by: Yangtao Li Applied.
Fixing MIPS delay slot emulation weakness?
Hi all- Some security researchers pointed out that writing to the delay slot emulation page is a great exploit technique on MIPS. It was introduced in: commit 432c6bacbd0c16ec210c43da411ccc3855c4c010 Author: Paul Burton Date: Fri Jul 8 11:06:19 2016 +0100 MIPS: Use per-mm page to execute branch delay slot instructions With my vDSO hat on, I hereby offer a couple of straightforward suggestions for fixing it. The offending code is: base = mmap_region(NULL, STACK_TOP, PAGE_SIZE, VM_READ|VM_WRITE|VM_EXEC| VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, 0, NULL); VM_WRITE | VM_EXEC is a big no-no, especially at a fixed address. The really simple but possibly suboptimal fix is to get rid of VM_WRITE and to use get_user_pages(..., FOLL_FORCE) to write to it. A possibly nicer way to accomplish more or less the same thing would be to allocate the area with _install_special_mapping() and arrange to keep a reference to the struct page around. The really nice but less compatible fix would be to let processes or even the whole system opt out by promising not to put anything in FPU branch delay slots, of course. --Andy
Re: [PATCH v2 3/3] fat: New inline functions to determine the FAT variant (32, 16 or 12)
Carmeli Tamir writes:
> This patch introduces 3 new inline functions - IS_FAT12, IS_FAT16 and
> IS_FAT32, and replaces every occurrence in the code in which the FS
> variant (whether this is FAT12, FAT16 or FAT32) was previously checked
> using msdos_sb_info->fat_bits.
Could you use lower case chars for inline functions?
> Signed-off-by: Carmeli Tamir
> ---
> fs/fat/cache.c | 2 +-
> fs/fat/dir.c| 4 ++--
> fs/fat/fat.h| 25 ++---
> fs/fat/fatent.c | 16 +++-
> fs/fat/inode.c | 12 ++--
> fs/fat/misc.c | 2 +-
> 6 files changed, 39 insertions(+), 22 deletions(-)
>
> diff --git a/fs/fat/cache.c b/fs/fat/cache.c
> index 78d501c..30c51b9 100644
> --- a/fs/fat/cache.c
> +++ b/fs/fat/cache.c
> @@ -363,7 +363,7 @@ int fat_bmap(struct inode *inode, sector_t sector,
> sector_t *phys,
>
> *phys = 0;
> *mapped_blocks = 0;
> - if ((sbi->fat_bits != 32) && (inode->i_ino == MSDOS_ROOT_INO)) {
> + if (!IS_FAT32(sbi) && (inode->i_ino == MSDOS_ROOT_INO)) {
> if (sector < (sbi->dir_entries >> sbi->dir_per_block_bits)) {
> *phys = sector + sbi->dir_start;
> *mapped_blocks = 1;
> diff --git a/fs/fat/dir.c b/fs/fat/dir.c
> index c8366cb..b0b8f44 100644
> --- a/fs/fat/dir.c
> +++ b/fs/fat/dir.c
> @@ -57,7 +57,7 @@ static inline void fat_dir_readahead(struct inode *dir,
> sector_t iblock,
> if ((iblock & (sbi->sec_per_clus - 1)) || sbi->sec_per_clus == 1)
> return;
> /* root dir of FAT12/FAT16 */
> - if ((sbi->fat_bits != 32) && (dir->i_ino == MSDOS_ROOT_INO))
> + if (!IS_FAT32(sbi) && (dir->i_ino == MSDOS_ROOT_INO))
> return;
>
> bh = sb_find_get_block(sb, phys);
> @@ -1313,7 +1313,7 @@ int fat_add_entries(struct inode *dir, void *slots, int
> nr_slots,
> }
> }
> if (dir->i_ino == MSDOS_ROOT_INO) {
> - if (sbi->fat_bits != 32)
> + if (!IS_FAT32(sbi))
> goto error;
> } else if (MSDOS_I(dir)->i_start == 0) {
> fat_msg(sb, KERN_ERR, "Corrupted directory (i_pos %lld)",
> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
> index 11bc4a2..5b6f1c8 100644
> --- a/fs/fat/fat.h
> +++ b/fs/fat/fat.h
> @@ -142,13 +142,32 @@ static inline struct msdos_sb_info *MSDOS_SB(struct
> super_block *sb)
> return sb->s_fs_info;
> }
>
> +/*
> + * Functions that determine the variant of the FAT file system (i.e.,
> + * whether this is FAT12, FAT16 or FAT32.
> + */
> +static inline bool IS_FAT12(const struct msdos_sb_info *sbi)
> +{
> + return sbi->fat_bits == 12;
> +}
> +
> +static inline bool IS_FAT16(const struct msdos_sb_info *sbi)
> +{
> + return sbi->fat_bits == 16;
> +}
> +
> +static inline bool IS_FAT32(const struct msdos_sb_info *sbi)
> +{
> + return sbi->fat_bits == 32;
> +}
> +
> /* Maximum number of clusters */
> static inline u32 MAX_FAT(struct super_block *sb)
> {
> struct msdos_sb_info *sbi = MSDOS_SB(sb);
>
> - return sbi->fat_bits == 32 ? MAX_FAT32 :
> - sbi->fat_bits == 16 ? MAX_FAT16 : MAX_FAT12;
> + return IS_FAT32(sbi) ? MAX_FAT32 :
> + IS_FAT16(sbi) ? MAX_FAT16 : MAX_FAT12;
> }
>
> static inline struct msdos_inode_info *MSDOS_I(struct inode *inode)
> @@ -266,7 +285,7 @@ static inline int fat_get_start(const struct
> msdos_sb_info *sbi,
> const struct msdos_dir_entry *de)
> {
> int cluster = le16_to_cpu(de->start);
> - if (sbi->fat_bits == 32)
> + if (IS_FAT32(sbi))
> cluster |= (le16_to_cpu(de->starthi) << 16);
> return cluster;
> }
> diff --git a/fs/fat/fatent.c b/fs/fat/fatent.c
> index f58c0ca..9166d96 100644
> --- a/fs/fat/fatent.c
> +++ b/fs/fat/fatent.c
> @@ -290,19 +290,17 @@ void fat_ent_access_init(struct super_block *sb)
>
> mutex_init(>fat_lock);
>
> - switch (sbi->fat_bits) {
> - case 32:
> + if (IS_FAT32(sbi)) {
> sbi->fatent_shift = 2;
> sbi->fatent_ops = _ops;
> - break;
> - case 16:
> + } else if (IS_FAT16(sbi)) {
> sbi->fatent_shift = 1;
> sbi->fatent_ops = _ops;
> - break;
> - case 12:
> + } else if (IS_FAT12(sbi)) {
> sbi->fatent_shift = -1;
> sbi->fatent_ops = _ops;
> - break;
> + } else {
> + fat_fs_error(sb, "invalid FAT variant, %u bits", sbi->fat_bits);
> }
> }
>
> @@ -310,7 +308,7 @@ static void mark_fsinfo_dirty(struct super_block *sb)
> {
> struct msdos_sb_info *sbi = MSDOS_SB(sb);
>
> - if (sb_rdonly(sb) || sbi->fat_bits != 32)
> + if (sb_rdonly(sb) || !IS_FAT32(sbi))
> return;
>
> __mark_inode_dirty(sbi->fsinfo_inode, I_DIRTY_SYNC);
> @@ -327,7 +325,7 @@ static inline int fat_ent_update_ptr(struct super_block
> *sb,
> /* Is this fatent's blocks including this
Re: [PATCH v2 2/3] fat: Moved MAX_FAT to fat.h and changed it to inline function
Carmeli Tamir writes:
> MAX_FAT is useless in msdos_fs.h, since it uses the MSDOS_SB function
> that is defined in fat.h. So really, this macro can be only called
> from code that already includes fat.h.
>
> Hence, this patch moves it to fat.h, right after MSDOS_SB is defined.
> I also changed it to an inline function in order to save the double call
> to MSDOS_SB. This was suggested by j...@perches.com in the previous
> version.
>
> This patch is required for the next in the series, in which the variant
> (whether this is FAT12, FAT16 or FAT32) checks are replaced with new
> macros.
Could you use lower case chars for inline functions? Yeah, MSDOS_SB() is
upper case though, it is historical reason.
Thanks.
> Signed-off-by: Carmeli Tamir
> ---
> fs/fat/fat.h | 9 +
> include/uapi/linux/msdos_fs.h | 2 --
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/fs/fat/fat.h b/fs/fat/fat.h
> index 4e1b2f6..11bc4a2 100644
> --- a/fs/fat/fat.h
> +++ b/fs/fat/fat.h
> @@ -142,6 +142,15 @@ static inline struct msdos_sb_info *MSDOS_SB(struct
> super_block *sb)
> return sb->s_fs_info;
> }
>
> +/* Maximum number of clusters */
> +static inline u32 MAX_FAT(struct super_block *sb)
> +{
> + struct msdos_sb_info *sbi = MSDOS_SB(sb);
> +
> + return sbi->fat_bits == 32 ? MAX_FAT32 :
> + sbi->fat_bits == 16 ? MAX_FAT16 : MAX_FAT12;
> +}
> +
> static inline struct msdos_inode_info *MSDOS_I(struct inode *inode)
> {
> return container_of(inode, struct msdos_inode_info, vfs_inode);
> diff --git a/include/uapi/linux/msdos_fs.h b/include/uapi/linux/msdos_fs.h
> index 833c707..a577389 100644
> --- a/include/uapi/linux/msdos_fs.h
> +++ b/include/uapi/linux/msdos_fs.h
> @@ -65,8 +65,6 @@
> #define MAX_FAT120xFF4
> #define MAX_FAT160xFFF4
> #define MAX_FAT320x0FF6
> -#define MAX_FAT(s) (MSDOS_SB(s)->fat_bits == 32 ? MAX_FAT32 : \
> - MSDOS_SB(s)->fat_bits == 16 ? MAX_FAT16 : MAX_FAT12)
>
> /* bad cluster mark */
> #define BAD_FAT120xFF7
--
OGAWA Hirofumi
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Em Sat, 15 Dec 2018 16:38:41 -0200 Helen Koike escreveu: > Hi Mauro, > > On 12/15/18 4:01 PM, Mauro Carvalho Chehab wrote: > > Hi Lucas, > > > > > > Em Sat, 15 Dec 2018 14:46:31 -0200 > > Lucas A. M. Magalhães escreveu: > > > >> The previous code pipeline used the stack to walk on the graph and > >> process a frame. Basically the vimc-sensor entity starts a thread that > >> generates the frames and calls the propagate_process function to send > >> this frame to each entity linked with a sink pad. The propagate_process > >> will call the process_frame of the entities which will call the > >> propagate_frame for each one of it's sink pad. This cycle will continue > >> until it reaches a vimc-capture entity that will finally return and > >> unstack. > > > > I didn't review the code yet, but I have a few comments about the > > way you're describing this patch. > > > > When you mention about a "previous code pipeline". Well, by adding it > > at the main body of the patch description, reviewers should expect > > that you're mentioning an implementation that already reached upstream. > > > > I suspect that this is not the case here, as I don't think we merged > > any recursive algorithm using the stack, as this is something that > > we shouldn't do at Kernelspace, as a 4K stack is usually not OK > > with recursive algorithms. > > > > So, it seems that this entire patch description (as-is) is bogus[1]. > > > > [1] if this is not the case and a recursive approach was indeed > > sneaked into the Kernel, this is a bug. So, you should really > > use the "Fixes:" meta-tag indicating what changeset this patch is > > fixing, and a "Cc: sta...@vger.kernel.org", in order to hint > > stable maintainers that this require backports. > > Just fyi, this is not the case, the current implementation in mainline > is bogus indeed (implemented by me when I was starting kernel > development, sorry about that and thanks Lucas for sending a fix). Not > only when propagating the frame [1] but also when activating the > pipeline [2]. > > But in any case this should be better written in the commit message. > > > [1] > Every entity calls vimc_propagate_frame() > https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n506 > That calls the process_frame() of each entity directly connected, that > calls vimc_propagate_frame() again: > https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-common.c#n237 > > [2] > .s_stream is calling the .s_stream of the subdevices directly connected > https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n355 > > > I was actually wondering if this is worthy in sending this to stable, as > this implementation is not a real problem, because the topology in vimc > is hardcoded and limited, and according to: > https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst > "It must fix a real bug that bothers people" > > So as the topology is fixed (in the current implementation), the max > number of nested calls is 4 (in the sensor->debayer->scaler->capture > path), this doesn't triggers any bug to users. But this will be a > problem once we have the configfs API in vimc. > > You could say that if your memory is low, this can be a problem in the > current implementation, but then your system won't have memory for any 4 > nested function calls anyway (which I think the kernel wouldn't work at > all). That basically depends on how much memory each call eats at stack. It is not always trivial about the amount of memory a stack call uses, and enabling KASAN can affect it a lot, as it changes some gcc optimization parameters, and there are some of those that use stack to either speedup the code or to allow checking for memory overrun. I'd say that it would be safe if, at the worse case scenario, it would be allocating no more than ~500 bytes at stack. Above that, it could be problematic. On a quick glance, I would be expecting, that, for 4 nested calls, it would use up to 256 bytes on 64 bits archs. For each call, it would use: 1 64-bits pointer for function return pointer; 2 64-bits pointers for the two function arguments; 5 64-bits pointers for the temporary values. All assuming that gcc won't be using registers for the above nor do any other optimization. But you have to check the asm code to be sure. Also, as I said, different Kconfig options could change the amount of memory spent (optimization for size is enabled? KASAN is enabled? what type of KASAN?). > > Mauro, with that said, do you still think we should send this to stable? Yes, let's properly document it (please check the abount of stack it is using with and without KASAN, for the worse case scenario) and send it to stable. Better safe than sorry. > > Thanks > Helen > > > > > Please notice that the patch description will be stored forever > > at the git tree. Mentioning something that were
Re: [RFC PATCH 4/4] x86/TSC: Use RDTSCP
On Fri, Dec 14, 2018 at 5:39 AM David Laight wrote: > > From: Borislav Petkov > > Sent: 12 December 2018 18:45 > ... > > > The property I want for RDTSC ordering is much weaker: I want it to be > > > ordered like a load. Imagine that, instead of an on-chip TSC, the TSC > > > is literally a location in main memory that gets incremented by an > > > extra dedicated CPU every nanosecond or so. I want users of RDTSC to > > > work as if they were reading such a location in memory using an > > > ordinary load. I believe this gives the real desired property that it > > > should be impossible to observe the TSC going backwards. This is a > > > much weaker form of serialization. > > > > Well, in that case you need something new. > > > > Because, the moment you have a RDTSC in flight and a second RDTSC comes > > in and that second RDTSC must *not* bypass the first one and execute > > earlier due to OoO, you need to impose some ordering. And that's pretty > > much uarch-dependent, I'd say. > > > > And I guess on AMD the way to do that is to stop dispatch until the > > first RDTSC retires. > > > > Can it be done faster? Sure. And I'm pretty sure there's a lot of pesky > > little hw details we're not even hearing of, which get in the way. > > ISTR one of the problems with RDTSC serialising is that it is used > for micro-benchmarks. If you're benchmarking with that level of detail, you're probably doing RDTSC directly instead of using the vDSO. Or, even better, RDPMC.
Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms
On Wed, Dec 12, 2018 at 2:01 PM Edgecombe, Rick P
wrote:
>
> On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> > On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> > wrote:
> > >
> > > On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
> > > > On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> > > > wrote:
> > > > >
> > > > > This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS,
> > > > > for
> > > > > enabling vfree operations to immediately clear executable TLB entries
> > > > > to
> > > > > freed
> > > > > pages, and handle freeing memory with special permissions.
> > > > >
> > > > > In order to support vfree being called on memory that might be RO, the
> > > > > vfree
> > > > > deferred list node is moved to a kmalloc allocated struct, from where
> > > > > it
> > > > > is
> > > > > today, reusing the allocation being freed.
> > > > >
> > > > > arch_vunmap is a new __weak function that implements the actual
> > > > > unmapping
> > > > > and
> > > > > resetting of the direct map permissions. It can be overridden by more
> > > > > efficient
> > > > > architecture specific implementations.
> > > > >
> > > > > For the default implementation, it uses architecture agnostic methods
> > > > > which
> > > > > are
> > > > > equivalent to what most usages do before calling vfree. So now it is
> > > > > just
> > > > > centralized here.
> > > > >
> > > > > This implementation derives from two sketches from Dave Hansen and
> > > > > Andy
> > > > > Lutomirski.
> > > > >
> > > > > Suggested-by: Dave Hansen
> > > > > Suggested-by: Andy Lutomirski
> > > > > Suggested-by: Will Deacon
> > > > > Signed-off-by: Rick Edgecombe
> > > > > ---
> > > > > include/linux/vmalloc.h | 2 ++
> > > > > mm/vmalloc.c| 73
> > > > > +
> > > > > 2 files changed, 69 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> > > > > index 398e9c95cd61..872bcde17aca 100644
> > > > > --- a/include/linux/vmalloc.h
> > > > > +++ b/include/linux/vmalloc.h
> > > > > @@ -21,6 +21,8 @@ struct notifier_block;/* in
> > > > > notifier.h
> > > > > */
> > > > > #define VM_UNINITIALIZED 0x0020 /* vm_struct is not
> > > > > fully
> > > > > initialized */
> > > > > #define VM_NO_GUARD0x0040 /* don't add guard
> > > > > page
> > > > > */
> > > > > #define VM_KASAN 0x0080 /* has allocated kasan
> > > > > shadow memory */
> > > > > +#define VM_IMMEDIATE_UNMAP 0x0200 /* flush before
> > > > > releasing
> > > > > pages */
> > > > > +#define VM_HAS_SPECIAL_PERMS 0x0400 /* may be freed with
> > > > > special
> > > > > perms */
> > > > > /* bits [20..32] reserved for arch specific ioremap internals */
> > > > >
> > > > > /*
> > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > > > > index 97d4b25d0373..02b284d2245a 100644
> > > > > --- a/mm/vmalloc.c
> > > > > +++ b/mm/vmalloc.c
> > > > > @@ -18,6 +18,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -38,6 +39,11 @@
> > > > >
> > > > > #include "internal.h"
> > > > >
> > > > > +struct vfree_work {
> > > > > + struct llist_node node;
> > > > > + void *addr;
> > > > > +};
> > > > > +
> > > > > struct vfree_deferred {
> > > > > struct llist_head list;
> > > > > struct work_struct wq;
> > > > > @@ -50,9 +56,13 @@ static void free_work(struct work_struct *w)
> > > > > {
> > > > > struct vfree_deferred *p = container_of(w, struct
> > > > > vfree_deferred,
> > > > > wq);
> > > > > struct llist_node *t, *llnode;
> > > > > + struct vfree_work *cur;
> > > > >
> > > > > - llist_for_each_safe(llnode, t, llist_del_all(>list))
> > > > > - __vunmap((void *)llnode, 1);
> > > > > + llist_for_each_safe(llnode, t, llist_del_all(>list)) {
> > > > > + cur = container_of(llnode, struct vfree_work, node);
> > > > > + __vunmap(cur->addr, 1);
> > > > > + kfree(cur);
> > > > > + }
> > > > > }
> > > > >
> > > > > /*** Page table manipulation functions ***/
> > > > > @@ -1494,6 +1504,48 @@ struct vm_struct *remove_vm_area(const void
> > > > > *addr)
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > +/*
> > > > > + * This function handles unmapping and resetting the direct map as
> > > > > efficiently
> > > > > + * as it can with cross arch functions. The three categories of
> > > > > architectures
> > > > > + * are:
> > > > > + * 1. Architectures with no set_memory implementations and no
> > > > > direct
> > > > > map
> > > > > + * permissions.
> > > > > + * 2. Architectures with set_memory implementations but no direct
> > > > > map
> > > > > + * permissions
> > > > > + * 3. Architectures with set_memory
Re: [PATCH v2 6/8] socket: Add SO_TIMESTAMP[NS]_NEW
> 3 reasons for not doing this:
>
> 1. We do not want to break userspace. If we move this to
> linux/socket.h all the userspace programs now have to include
> linux/socket.h or get this definition through a new libc.
> 2. All the socket options are together in the file asm/socket.h. It
> doesn't seem good for maintainability to move just a few bits
> elsewhere.
> 3. There are only 4 arches (after the series is applied) that have
> their own asm/socket.h. And, this is because there seems to be
> significant differences to asm-generic/socket.h that don't seem
> logically obvious to group and eliminate some of the defines.
Agreed. All good reasons to leave as is.
> Also for the other comment. The reason the conditionals were not
> consistent is because they were not consistent to begin with.
The only difference I see is an inversion of the test. Nesting order
is the same:
int need_software_tstamp = sock_flag(sk, SOCK_RCVTSTAMP);
...
if (need_software_tstamp) {
if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
} else {
}
}
vs
if (sock_flag(sk, SOCK_RCVTSTAMP)) {
if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
} else {
}
}
I suggest just adding something like
if (need_software_tstamp) {
+ if (sock_uses_new_tstamp(sk) {
+ __sock_recv_timestamp_new(msg, sk,
ktime_to_timespec64(skb->tstamp));
+ } else if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
- if (!sock_flag(sk, SOCK_RCVTSTAMPNS)) {
} else {
}
and
if (sock_flag(sk, SOCK_RCVTSTAMP)) {
+ if (sock_uses_new_tstamp(sk) {
+ __sock_recv_timestamp_new(msg, sk, ts);
+ else if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
- if (sock_flag(sk, SOCK_RCVTSTAMPNS)) {
} else {
}
I think we can use the same helper for both the sock and tcp variant.
The only intended difference between the two functions, as described
in the tcp_recv_timestamp function comment, is the absence of an skb
in the tcp case. That is immaterial at this level.
Note also (2) tentative helper function sock_uses_new_tstamp(const
struct sock *sk) instead of testing sock_flag(sk, SOCK_TSTAMP_NEW)
directly. Since the .._NEW variants are equivalent to .._OLD on 64-bit,
I wonder if we can just compile out the branch. Something like
static inline bool sock_uses_new_tstamp(const struct sock *sk) {
return (sizeof(time_t) != sizeof(__kernel_long_t)) &&
sock_flag(sk, SOCK_TSTAMP_NEW);
}
> I'm trying to follow your request to keep code churn to minimal.
> It's just that I moved to a different function as that seemed logical
> to me. Do you prefer me to remove that refactoring?
Yes, please avoid rearranging existing code as much as possible.
If there is any refactoring to be done, I think it would be to
deduplicate the shared logic between __sock_recv_timestamp and
tcp_recv_timestamp. I think the first can be rewritten to reuse the
second, if the only difference really is that the first takes an skb with
embedded timestamps, while the second directly takes a pointer to
struct scm_timestamping.
Either way, that's out of scope for this patchset.
Re: BUG: sleeping function called from invalid context at mm/slab.h:LINE (4)
syzbot has found a reproducer for the following crash on:
HEAD commit:d14b746c6c1c Add linux-next specific files for 20181214
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=129bc94340
kernel config: https://syzkaller.appspot.com/x/.config?x=1da6d2d18f803140
dashboard link: https://syzkaller.appspot.com/bug?extid=9bf843c33f782d73ae7d
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=136154cd40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1687bfa340
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9bf843c33f782d73a...@syzkaller.appspotmail.com
sshd (6035) used greatest stack depth: 15600 bytes left
BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 0, pid: 6051, name: syz-executor515
1 lock held by syz-executor515/6051:
#0: 2f6552ef (sk_lock-AF_ALG){+.+.}, at: lock_sock
include/net/sock.h:1502 [inline]
#0: 2f6552ef (sk_lock-AF_ALG){+.+.}, at:
skcipher_recvmsg+0xbb/0x1420 crypto/algif_skcipher.c:163
Preemption disabled at:
[] kernel_fpu_begin+0x16/0x260
arch/x86/kernel/fpu/core.c:127
CPU: 0 PID: 6051 Comm: syz-executor515 Not tainted
4.20.0-rc6-next-20181214+ #171
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+0x244/0x39d lib/dump_stack.c:113
___might_sleep.cold.86+0x221/0x254 kernel/sched/core.c:6148
__might_sleep+0x95/0x190 kernel/sched/core.c:6101
slab_pre_alloc_hook mm/slab.h:421 [inline]
slab_alloc mm/slab.c:3365 [inline]
__do_kmalloc mm/slab.c:3707 [inline]
__kmalloc+0x2da/0x760 mm/slab.c:3718
kmalloc include/linux/slab.h:550 [inline]
kzalloc include/linux/slab.h:740 [inline]
skcipher_next_slow crypto/skcipher.c:254 [inline]
skcipher_walk_next+0x7f9/0x17f0 crypto/skcipher.c:358
skcipher_walk_first+0xff/0x3a0 crypto/skcipher.c:441
skcipher_walk_skcipher+0x541/0x700 crypto/skcipher.c:469
skcipher_walk_virt+0x58/0xd0 crypto/skcipher.c:479
chacha_simd_stream_xor+0xb3/0xa40 arch/x86/crypto/chacha_glue.c:141
chacha_simd+0xd8/0x110 arch/x86/crypto/chacha_glue.c:179
crypto_skcipher_decrypt include/crypto/skcipher.h:538 [inline]
_skcipher_recvmsg crypto/algif_skcipher.c:146 [inline]
skcipher_recvmsg+0xcc9/0x1420 crypto/algif_skcipher.c:165
sock_recvmsg_nosec net/socket.c:795 [inline]
sock_recvmsg+0xd0/0x110 net/socket.c:802
___sys_recvmsg+0x2b6/0x680 net/socket.c:2279
do_recvmmsg+0x303/0xb90 net/socket.c:2392
__sys_recvmmsg+0x265/0x2a0 net/socket.c:2471
__do_sys_recvmmsg net/socket.c:2494 [inline]
__se_sys_recvmmsg net/socket.c:2487 [inline]
__x64_sys_recvmmsg+0xe6/0x140 net/socket.c:2487
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440349
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff9312c608 EFLAGS: 0203 ORIG_RAX: 012b
RAX: ffda RBX: 004002c8 RCX: 00440349
RDX: 0001 RSI: 2000a280 RDI: 0004
RBP: 006ca018 R08: R09: 004002c8
R10: R11: 0203 R12:
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Hi Mauro, On 12/15/18 4:01 PM, Mauro Carvalho Chehab wrote: > Hi Lucas, > > > Em Sat, 15 Dec 2018 14:46:31 -0200 > Lucas A. M. Magalhães escreveu: > >> The previous code pipeline used the stack to walk on the graph and >> process a frame. Basically the vimc-sensor entity starts a thread that >> generates the frames and calls the propagate_process function to send >> this frame to each entity linked with a sink pad. The propagate_process >> will call the process_frame of the entities which will call the >> propagate_frame for each one of it's sink pad. This cycle will continue >> until it reaches a vimc-capture entity that will finally return and >> unstack. > > I didn't review the code yet, but I have a few comments about the > way you're describing this patch. > > When you mention about a "previous code pipeline". Well, by adding it > at the main body of the patch description, reviewers should expect > that you're mentioning an implementation that already reached upstream. > > I suspect that this is not the case here, as I don't think we merged > any recursive algorithm using the stack, as this is something that > we shouldn't do at Kernelspace, as a 4K stack is usually not OK > with recursive algorithms. > > So, it seems that this entire patch description (as-is) is bogus[1]. > > [1] if this is not the case and a recursive approach was indeed > sneaked into the Kernel, this is a bug. So, you should really > use the "Fixes:" meta-tag indicating what changeset this patch is > fixing, and a "Cc: sta...@vger.kernel.org", in order to hint > stable maintainers that this require backports. Just fyi, this is not the case, the current implementation in mainline is bogus indeed (implemented by me when I was starting kernel development, sorry about that and thanks Lucas for sending a fix). Not only when propagating the frame [1] but also when activating the pipeline [2]. But in any case this should be better written in the commit message. [1] Every entity calls vimc_propagate_frame() https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n506 That calls the process_frame() of each entity directly connected, that calls vimc_propagate_frame() again: https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-common.c#n237 [2] .s_stream is calling the .s_stream of the subdevices directly connected https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n355 I was actually wondering if this is worthy in sending this to stable, as this implementation is not a real problem, because the topology in vimc is hardcoded and limited, and according to: https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst "It must fix a real bug that bothers people" So as the topology is fixed (in the current implementation), the max number of nested calls is 4 (in the sensor->debayer->scaler->capture path), this doesn't triggers any bug to users. But this will be a problem once we have the configfs API in vimc. You could say that if your memory is low, this can be a problem in the current implementation, but then your system won't have memory for any 4 nested function calls anyway (which I think the kernel wouldn't work at all). Mauro, with that said, do you still think we should send this to stable? Thanks Helen > > Please notice that the patch description will be stored forever > at the git tree. Mentioning something that were never merged > (and that, years from now people will hardly remember, and will > have lots of trouble to seek as you didn't even mentioned any > ML archive with the past solution) shouldn't be done. > > So, you should rewrite the entire patch description explaining > what the current approach took by this patch does. Then, in order > to make easier for reviewers to compare with a previous implementation, > you can add a "---" line and then a description about why this approach > is better than the first version, e. g. something like: > > [PATCH v2] media: vimc: Add vimc-streamer for stream control > > Add a logic that will create a linear pipeline walking > backwards on the graph. When the stream starts it will simply > loop through the pipeline calling the respective process_frame > function for each entity on the pipeline. > > Signed-off-by: Your Name > > --- > > v2: The previous approach were to use a recursive function that > it was using the stack to walk on the graph and > process a frame. Basically the vimc-sensor entity starts a thread that > generates the frames and calls the propagate_process function to send > this frame to each entity linked with a sink pad. The propagate_process > will call the process_frame of the entities which will call the > propagate_frame for each one of it's sink pad. This cycle will continue > until it reaches a vimc-capture entity that will finally return and >
Re: [PATCH v2 3/3] spi: meson-axg: add a linear clock divider support
Hi Sunny,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on spi/for-next]
[also build test WARNING on v4.20-rc6 next-20181214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sunny-Luo/spi-meson-axg-support-MAX-80M-clock/20181214-175627
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-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=xtensa
All warnings (new ones prefixed by >>):
drivers/spi/spi-meson-spicc.c: In function 'meson_spicc_clk_init':
>> drivers/spi/spi-meson-spicc.c:583:28: warning: cast from pointer to integer
>> of different size [-Wpointer-to-int-cast]
div1->reg = spicc->base + (u64)div1->reg;
^
drivers/spi/spi-meson-spicc.c:621:28: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
div1->reg = spicc->base + (u64)div1->reg;
^
drivers/spi/spi-meson-spicc.c:638:27: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
mux->reg = spicc->base + (u64)mux->reg;
^
vim +583 drivers/spi/spi-meson-spicc.c
546
547 static int meson_spicc_clk_init(struct meson_spicc_device *spicc)
548 {
549 struct device *dev = >pdev->dev;
550 struct clk_fixed_factor *div0;
551 struct clk_divider *div1;
552 struct clk_mux *mux;
553 struct clk_init_data init;
554 struct clk *clk;
555 const char *parent_names[1];
556 const char *mux_parent_names[2];
557 char name[32];
558
559 div0 = _spicc_div0;
560 snprintf(name, sizeof(name), "%s#_div0", dev_name(dev));
561 init.name = name;
562 init.ops = _fixed_factor_ops;
563 init.flags = 0;
564 parent_names[0] = __clk_get_name(spicc->core);
565 init.parent_names = parent_names;
566 init.num_parents = 1;
567
568 div0->hw.init =
569
570 clk = devm_clk_register(dev, >hw);
571 if (WARN_ON(IS_ERR(clk)))
572 return PTR_ERR(clk);
573
574 div1 = _spicc_div1;
575 snprintf(name, sizeof(name), "%s#_div1", dev_name(dev));
576 init.name = name;
577 init.ops = _divider_ops;
578 init.flags = CLK_SET_RATE_PARENT;
579 parent_names[0] = __clk_get_name(clk);
580 init.parent_names = parent_names;
581 init.num_parents = 1;
582
> 583 div1->reg = spicc->base + (u64)div1->reg;
584 div1->hw.init =
585
586 clk = devm_clk_register(dev, >hw);
587 if (WARN_ON(IS_ERR(clk)))
588 return PTR_ERR(clk);
589
590 if (!spicc->data->has_enhance_clk_div) {
591 spicc->clk = clk;
592 return 0;
593 }
594
595 mux_parent_names[0] = __clk_get_name(clk);
596
597 div0 = _spicc_div2;
598 snprintf(name, sizeof(name), "%s#_div2", dev_name(dev));
599 init.name = name;
600 init.ops = _fixed_factor_ops;
601 init.flags = 0;
602 parent_names[0] = __clk_get_name(spicc->core);
603 init.parent_names = parent_names;
604 init.num_parents = 1;
605
606 div0->hw.init =
607
608 clk = devm_clk_register(dev, >hw);
609 if (WARN_ON(IS_ERR(clk)))
610 return PTR_ERR(clk);
611
612 div1 = _spicc_div3;
613 snprintf(name, sizeof(name), "%s#_div3", dev_name(dev));
614 init.name = name;
615 init.ops = _divider_ops;
616 init.flags = CLK_SET_RATE_PARENT;
617 parent_names[0] = __clk_get_name(clk);
618 init.parent_names = parent_names;
619 init.num_parents = 1;
620
621 div1->reg = spicc->base + (u64)div1->reg;
622 div1->hw.init =
623
624 clk = devm_clk_register(dev, >hw);
625 if (WARN_ON(IS_ERR(clk)))
626 return PTR_ERR(clk);
627
628 mux_parent_names[1] = __clk_get_name(clk);
629
630 mux = _spicc_sel;
631 snprintf(name, sizeof(name), "%s#_sel", dev_name(dev));
632 init.name = name;
633 init.ops = _mux_ops;
634 init.parent_names = mux_parent_names;
635
Re: [PATCH] Allow hwrng to initialize crng.
On Sat, 2018-12-15 at 18:11 +0100, Michael Niewöhner wrote:
> On Thu, 2018-12-13 at 12:50 +0800, Louis Collard wrote:
> > On Sun, Nov 18, 2018 at 4:15 AM Michael Niewöhner
> > wrote:
> > >
> > > Hi Louis,
> > >
> > > On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> > > > Some systems, for example embedded systems, do not generate
> > > > enough entropy on boot through interrupts, and boot may be blocked for
> > > > several minutes waiting for a call to getrandom to complete.
> > > >
> > > > Currently, random data is read from a hwrng when it is registered,
> > > > and is loaded into primary_crng. This data is treated in the same
> > > > way as data that is device-specific but otherwise unchanging, and
> > > > so primary_crng cannot become initialized with the data from the
> > > > hwrng.
> > > >
> > > > This change causes the data initially read from the hwrng to be
> > > > treated the same as subsequent data that is read from the hwrng if
> > > > it's quality score is non-zero.
> > > >
> > > > The implications of this are:
> > > >
> > > > The data read from hwrng can cause primary_crng to become
> > > > initialized, therefore avoiding problems of getrandom blocking
> > > > on boot.
> > > >
> > > > Calls to getrandom (with GRND_RANDOM) may be using entropy
> > > > exclusively (or in practise, almost exclusively) from the hwrng.
> > > >
> > > > Regarding the latter point; this behavior is the same as if a
> > > > user specified a quality score of 1 (bit of entropy per 1024 bits)
> > > > so hopefully this is not too scary a change to make.
> > > >
> > > > This change is the result of the discussion here:
> > > > https://patchwork.kernel.org/patch/10453893/
> > > >
> > > > Signed-off-by: Louis Collard
> > > > Acked-by: Jarkko Sakkinen
> > > > ---
> > > > drivers/char/hw_random/core.c | 9 +++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/char/hw_random/core.c
> > > > b/drivers/char/hw_random/core.c
> > > > index aaf9e5afaad4..47f358aa0c3d 100644
> > > > --- a/drivers/char/hw_random/core.c
> > > > +++ b/drivers/char/hw_random/core.c
> > > > @@ -24,6 +24,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #define RNG_MODULE_NAME "hw_random"
> > > >
> > > > @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> > > > static void add_early_randomness(struct hwrng *rng)
> > > > {
> > > > int bytes_read;
> > > > - size_t size = min_t(size_t, 16, rng_buffer_size());
> > > > + /* Read enough to initialize crng. */
> > > > + size_t size = 2*CHACHA20_KEY_SIZE;
> > > >
> > > > mutex_lock(_mutex);
> > > > bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> > > > mutex_unlock(_mutex);
> > > > if (bytes_read > 0)
> > > > - add_device_randomness(rng_buffer, bytes_read);
> > > > + /* Allow crng to become initialized, but do not add
> > > > + * entropy to the pool.
> > > > + */
> > > > + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> > > > }
> > > >
> > > > static inline void cleanup_rng(struct kref *kref)
> > >
> > > I found your patch by chance, searching for a solution for crng init delay
> > > on my
> > > headless machine. Unfortunately it hardly makes any difference for me.
> > > With
> > > the
> > > patch the system hangs for about 80s instead of 120s until the "crng init
> > > done"
> > > message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
> > > initializes the crng instantly.
> > >
> > > Isn't that delay the problem this patch tries to fix? Any idea what is
> > > wrong
> > > here?
> > >
> > > Thanks!
> > >
> > > Best regards
> > > Michael
> > >
> > >
> >
> > Yes that is the problem this is trying to address. My guess would be
> > rng_get_data() is not returning as much data as requested, so the
> > delay is reduced but not eliminated. Looking at implementation of
> > rng_get_data() it appears this could be caused by device support for
> > read() vs data_read(). I don't have a good feel for whether looping to
> > retrieve more data here would be acceptable, it is certainly a bigger
> > change than currently proposed.
> >
> > Thanks,
> > Louis
>
> Hi Louis,
>
> that is what I thought first, too, but I was able to verify that 64 bytes are
> read as expected.
>
> It seems this is exactly what David noticed in your discussion about the
> quality
> module parameter (https://patchwork.kernel.org/patch/10453893/#22130681):
>
> > Interesting.
> >
> > add_hwgenereator_randomness() will call crng_fast_load(), regardless
> > of entropy estimate/quality, if crng_init is 0. So initializing
> > crng_init from the hwrng, regardless of quality, is already the
> > intent.
> >
> > But hw_random only calls add_hwgenerator_randomness() if
> > current_quality > 0, via the hwrng_fillfn() kthread.
> >
> > All that to say, I agree.
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Hi Lucas, Em Sat, 15 Dec 2018 14:46:31 -0200 Lucas A. M. Magalhães escreveu: > The previous code pipeline used the stack to walk on the graph and > process a frame. Basically the vimc-sensor entity starts a thread that > generates the frames and calls the propagate_process function to send > this frame to each entity linked with a sink pad. The propagate_process > will call the process_frame of the entities which will call the > propagate_frame for each one of it's sink pad. This cycle will continue > until it reaches a vimc-capture entity that will finally return and > unstack. I didn't review the code yet, but I have a few comments about the way you're describing this patch. When you mention about a "previous code pipeline". Well, by adding it at the main body of the patch description, reviewers should expect that you're mentioning an implementation that already reached upstream. I suspect that this is not the case here, as I don't think we merged any recursive algorithm using the stack, as this is something that we shouldn't do at Kernelspace, as a 4K stack is usually not OK with recursive algorithms. So, it seems that this entire patch description (as-is) is bogus[1]. [1] if this is not the case and a recursive approach was indeed sneaked into the Kernel, this is a bug. So, you should really use the "Fixes:" meta-tag indicating what changeset this patch is fixing, and a "Cc: sta...@vger.kernel.org", in order to hint stable maintainers that this require backports. Please notice that the patch description will be stored forever at the git tree. Mentioning something that were never merged (and that, years from now people will hardly remember, and will have lots of trouble to seek as you didn't even mentioned any ML archive with the past solution) shouldn't be done. So, you should rewrite the entire patch description explaining what the current approach took by this patch does. Then, in order to make easier for reviewers to compare with a previous implementation, you can add a "---" line and then a description about why this approach is better than the first version, e. g. something like: [PATCH v2] media: vimc: Add vimc-streamer for stream control Add a logic that will create a linear pipeline walking backwards on the graph. When the stream starts it will simply loop through the pipeline calling the respective process_frame function for each entity on the pipeline. Signed-off-by: Your Name --- v2: The previous approach were to use a recursive function that it was using the stack to walk on the graph and process a frame. Basically the vimc-sensor entity starts a thread that generates the frames and calls the propagate_process function to send this frame to each entity linked with a sink pad. The propagate_process will call the process_frame of the entities which will call the propagate_frame for each one of it's sink pad. This cycle will continue until it reaches a vimc-capture entity that will finally return and unstack. ... If the past approach was written by somebody else (or if you sent it a long time ago), please add an URL (if possible using https://lore.kernel.org/linux-media/ archive) pointing to the previous approach, in order to help us to check what you're referring to. Regards, Mauro Thanks, Mauro
Re: MAINTAINERS: Update my email address
On Mon, 2018-12-03 at 10:23:15 UTC, Boris Brezillon wrote: > Use my korg address instead of the bootlin one. > > Signed-off-by: Boris Brezillon Applied to http://git.infradead.org/linux-mtd.git mtd/next. Boris
Re: [15/15] dma-mapping: bypass indirect calls for dma-direct
Hi, On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote: > Avoid expensive indirect calls in the fast path DMA mapping > operations by directly calling the dma_direct_* ops if we are using > the directly mapped DMA operations. > This patch results in arm64 boot failures. Reverting the patch fixes the problem. Bisect results are attached. Per logs, the system fails to instantiate the root device. Examples from two logs: [ 22.843080] nvme nvme0: pci function :00:02.0 [ 22.853820] nvme :00:02.0: enabling device ( -> 0002) [ 22.884178] nvme nvme0: Removing after probe failure status: -12 [ 15.451963] xhci_hcd :00:02.0: xHCI Host Controller [ 15.453294] xhci_hcd :00:02.0: new USB bus registered, assigned bus number 1 [ 15.456042] xhci_hcd :00:02.0: can't setup: -12 [ 15.457003] xhci_hcd :00:02.0: USB bus 1 deregistered [ 15.458340] xhci_hcd :00:02.0: init :00:02.0 fail, -12 [ 15.458825] xhci_hcd: probe of :00:02.0 failed with error -12 Guenter --- # bad: [d14b746c6c1ca310f679ef13f661587454e2c588] Add linux-next specific files for 20181214 # good: [40e020c129cfc991e8ab4736d2665351ffd1468d] Linux 4.20-rc6 git bisect start 'HEAD' 'v4.20-rc6' # bad: [ddfdda7f7d1ebdca0851f30a814e76749f08be99] Merge remote-tracking branch 'spi-nor/spi-nor/next' git bisect bad ddfdda7f7d1ebdca0851f30a814e76749f08be99 # bad: [466d2f8b964745cc8db7f126607e19526385f2d5] Merge remote-tracking branch 'file-locks/locks-next' git bisect bad 466d2f8b964745cc8db7f126607e19526385f2d5 # bad: [c43abf670f074a3eba2eebf9568ba95b2fe57f00] Merge remote-tracking branch 'arm-soc/for-next' git bisect bad c43abf670f074a3eba2eebf9568ba95b2fe57f00 # good: [e4337d9d50eb940a25d3808ef76bb0eaa61a0146] Merge branch 'next/dt' into for-next git bisect good e4337d9d50eb940a25d3808ef76bb0eaa61a0146 # bad: [32d851d8e81b1152d3e663b6c0b318474d649098] Merge remote-tracking branch 'dma-mapping/for-next' git bisect bad 32d851d8e81b1152d3e663b6c0b318474d649098 # good: [32550839013d8e72d35c1cc0a756c818d7f9ae32] Merge remote-tracking branch 'scsi-fixes/fixes' git bisect good 32550839013d8e72d35c1cc0a756c818d7f9ae32 # good: [8ea3ac17b6557f30697c624d1cd4ff2b30af82e1] Merge remote-tracking branch 'kbuild/for-next' git bisect good 8ea3ac17b6557f30697c624d1cd4ff2b30af82e1 # good: [ad78dee0b630527bdfed809d1f5ed95c601886ae] dma-debug: Batch dma_debug_entry allocation git bisect good ad78dee0b630527bdfed809d1f5ed95c601886ae # good: [55897af63091ebc2c3f239c6af748113ac50] dma-direct: merge swiotlb_dma_ops into the dma_direct code git bisect good 55897af63091ebc2c3f239c6af748113ac50 # good: [7d32be2e5abb2d88cf321357178d05c461b1cc83] leaking_addresses: do not parse binary files git bisect good 7d32be2e5abb2d88cf321357178d05c461b1cc83 # good: [9db33987ee2e5abb32a40dca44a2953391786833] leaking_addresses: remove version number git bisect good 9db33987ee2e5abb32a40dca44a2953391786833 # good: [7fd0d1346c1f96371a9a4996a590b86d570098f9] Merge remote-tracking branch 'leaks/leaks-next' git bisect good 7fd0d1346c1f96371a9a4996a590b86d570098f9 # bad: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct git bisect bad 356da6d0cde3323236977fce54c1f9612a742036 # good: [190d4e5916a2d70a11009022b968fca948fb5dc7] vmd: use the proper dma_* APIs instead of direct methods calls git bisect good 190d4e5916a2d70a11009022b968fca948fb5dc7 # first bad commit: [356da6d0cde3323236977fce54c1f9612a742036] dma-mapping: bypass indirect calls for dma-direct
Re: [PATCH 2/2] checkpatch: add Co-developed-by to signature tags
On Fri, 2018-12-14 at 12:16 -0800, Andrew Morton wrote:
> On Fri, 14 Dec 2018 18:35:28 +0100 Jorge Ramirez-Ortiz
> wrote:
>
> > As per Documentation/process/submitting-patches, Co-developed-by is a
> > valid signature.
> >
>
> I'm with Joe - I find this tag kinda useless and duplicative. But whatever.
>
> But as the documentation says, Co-developed-by must be accompanied by a
> Signed-off-by:. It would be helpful if checkpatch were to detect a
> failure to do this.
perhaps
---
scripts/checkpatch.pl | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 93e84c9504a1..056d4b47ffaf 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2673,7 +2673,20 @@ sub process {
WARN("BAD_SIGN_OFF",
"Duplicate signature\n" . $herecurr);
} else {
- $signatures{$sig_nospace} = 1;
+ $signatures{$sig_nospace} = $herecurr;
+ }
+ }
+
+# Check for "Co-developed-by:" uses without equivalent "Signed-off-by:"
+# $signatures keys are all lower case without spaces
+ if ($rawline =~ /^---$/) {
+ foreach my $sig (keys %signatures) {
+ next if ($sig !~ /^co-developed-by:(.*)/);
+ my $signer = $1;
+ if (!defined
$signatures{"signed-off-by:$signer"}) {
+ WARN("CODEVELOPED_WITHOUT_SIGNOFF",
+"Co-developed-by: used without
Signed-off-by: by same person\n" . $signatures{$sig});
+ }
}
}
Attention Please !!!
-- Greetings Please forgive me for stressing you with my predicaments as I know that this letter may come to you as big surprise. Actually, I came across your E-mail from my personal search afterward I decided to email you directly believing that you will be honest to fulfill my final wish before I die. Meanwhile, I am Madam Evelyn Mary Edward, 73 years, from USA, childless and I am suffering from a long-time cancer and from all indication my condition is really eriorating as my doctors have confirmed and courageously advised me that I may not live beyond two months from now for the reason that my tumor has reached a critical stage which has defiled all forms of medical treatment. Since my days are numbered, I’ve decided willingly to fulfill my long- time promise to donate the sum of Ten million six hundred and twenty- five thousand dollars $10.625000 remaining in my foreign bank account over 9 years due to my health problem. This fund was obtained by me when I was dealing on Gold. My promise is to help the widows, handicapped, orphans, underprivileged, to build technical school and hospital for their well-being. If you will be obedient to assist me fulfill my promise as I said here kindly show me your first obedience by providing me your personal details to enable me introduce you to my bank management as the sole eneficiary and to enable them check whether it will be possible to transfer or deliver my fund to you. I have been trying to handle this project for the past 4 years by myself when I will get better, but I have seen that it won’t be possible anymore. Please get back to me if you can handle the project for more details. All details shall be sent to you once I hear from you God bless you Madam Evelyn Mary Edward.
Re: [PATCH 3/3] arm64: tegra: p2972: Enable the CPU, GPU and AUX thermal zones
On Fri, Nov 23, 2018 at 01:18:39PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Enable these thermal zones to be able to monitor their temperatures and
> control the fan to cool down the system if necessary.
>
> Signed-off-by: Thierry Reding
Acked-by: Eduardo Valentin
As mentioned, I already added patch 1.
> ---
> .../boot/dts/nvidia/tegra194-p2972-.dts | 91 ++-
> 1 file changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> index cbae8e8b1281..e29f8f6117c8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> @@ -43,8 +43,97 @@
> };
> };
>
> - fan {
> + fan: fan {
> compatible = "pwm-fan";
> pwms = < 0 45334>;
> +
> + cooling-levels = <0 64 128 255>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + };
> +
> + thermal-zones {
> + cpu {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + cpu_trip_critical: critical {
> + temperature = <96500>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> +
> + cpu_trip_hot: hot {
> + temperature = <7>;
> + hysteresis = <2000>;
> + type = "hot";
> + };
> +
> + cpu_trip_active: active {
> + temperature = <5>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_trip_passive: passive {
> + temperature = <3>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + };
> +
> + cooling-maps {
> + cpu-critical {
> + cooling-device = < 3 3>;
> + trip = <_trip_critical>;
> + };
> +
> + cpu-hot {
> + cooling-device = < 2 2>;
> + trip = <_trip_hot>;
> + };
> +
> + cpu-active {
> + cooling-device = < 1 1>;
> + trip = <_trip_active>;
> + };
> +
> + cpu-passive {
> + cooling-device = < 0 0>;
> + trip = <_trip_passive>;
> + };
> + };
> + };
> +
> + gpu {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + gpu_alert0: critical {
> + temperature = <99000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> +
> + aux {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + aux_alert0: critical {
> + temperature = <9>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> };
> };
Re: [PATCH 2/3] arm64: tegra: Add thermal zones on Tegra194
On Fri, Nov 23, 2018 at 01:18:38PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The NVIDIA Tegra194 SoC defines six thermal zones. Define all of them in
> device tree.
>
> Signed-off-by: Thierry Reding
Acked-by: Eduardo Valentin
The patch 1 I added in my -linus branch.
> ---
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 39
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index cbba7395a286..39169f6b6166 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "nvidia,tegra194";
> @@ -938,6 +939,44 @@
> mbox-names = "rx", "tx";
> };
>
> + thermal-zones {
> + cpu {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_CPU>;
> + status = "disabled";
> + };
> +
> + gpu {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_GPU>;
> + status = "disabled";
> + };
> +
> + aux {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_AUX>;
> + status = "disabled";
> + };
> +
> + pllx {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_PLLX>;
> + status = "disabled";
> + };
> +
> + ao {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_AO>;
> + status = "disabled";
> + };
> +
> + tj {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_TJ_MAX>;
> + status = "disabled";
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts =
Re: [PATCH 4.19 000/142] 4.19.10-stable review
On Sat, Dec 15, 2018 at 11:01:02AM -0600, Dan Rue wrote: > On Fri, Dec 14, 2018 at 12:58:05PM +0100, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.10 release. > > There are 142 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 Sun Dec 16 11:57:12 UTC 2018. > > Anything received after that time might be too late. > > Results from Linaro’s test farm. > Regressions detected. They were? > > Summary > > > kernel: 4.19.10-rc1 > git repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > git branch: linux-4.19.y > git commit: 4875bf1f86d7bdc8dbf3222ab4028239446fab3f > git describe: v4.19.9-143-g4875bf1f86d7 > Test details: > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.9-143-g4875bf1f86d7 > > No regressions (compared to build v4.19.9) > > No fixes (compared to build v4.19.9) > > Ran 18346 total tests in the following environments and test suites. This said there were no regressions. confused, greg k-h
Re: [PATCH] Allow hwrng to initialize crng.
On Thu, 2018-12-13 at 12:50 +0800, Louis Collard wrote:
> On Sun, Nov 18, 2018 at 4:15 AM Michael Niewöhner
> wrote:
> >
> > Hi Louis,
> >
> > On Wed, 2018-09-26 at 11:24 +0800, Louis Collard wrote:
> > > Some systems, for example embedded systems, do not generate
> > > enough entropy on boot through interrupts, and boot may be blocked for
> > > several minutes waiting for a call to getrandom to complete.
> > >
> > > Currently, random data is read from a hwrng when it is registered,
> > > and is loaded into primary_crng. This data is treated in the same
> > > way as data that is device-specific but otherwise unchanging, and
> > > so primary_crng cannot become initialized with the data from the
> > > hwrng.
> > >
> > > This change causes the data initially read from the hwrng to be
> > > treated the same as subsequent data that is read from the hwrng if
> > > it's quality score is non-zero.
> > >
> > > The implications of this are:
> > >
> > > The data read from hwrng can cause primary_crng to become
> > > initialized, therefore avoiding problems of getrandom blocking
> > > on boot.
> > >
> > > Calls to getrandom (with GRND_RANDOM) may be using entropy
> > > exclusively (or in practise, almost exclusively) from the hwrng.
> > >
> > > Regarding the latter point; this behavior is the same as if a
> > > user specified a quality score of 1 (bit of entropy per 1024 bits)
> > > so hopefully this is not too scary a change to make.
> > >
> > > This change is the result of the discussion here:
> > > https://patchwork.kernel.org/patch/10453893/
> > >
> > > Signed-off-by: Louis Collard
> > > Acked-by: Jarkko Sakkinen
> > > ---
> > > drivers/char/hw_random/core.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > > index aaf9e5afaad4..47f358aa0c3d 100644
> > > --- a/drivers/char/hw_random/core.c
> > > +++ b/drivers/char/hw_random/core.c
> > > @@ -24,6 +24,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #define RNG_MODULE_NAME "hw_random"
> > >
> > > @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void)
> > > static void add_early_randomness(struct hwrng *rng)
> > > {
> > > int bytes_read;
> > > - size_t size = min_t(size_t, 16, rng_buffer_size());
> > > + /* Read enough to initialize crng. */
> > > + size_t size = 2*CHACHA20_KEY_SIZE;
> > >
> > > mutex_lock(_mutex);
> > > bytes_read = rng_get_data(rng, rng_buffer, size, 1);
> > > mutex_unlock(_mutex);
> > > if (bytes_read > 0)
> > > - add_device_randomness(rng_buffer, bytes_read);
> > > + /* Allow crng to become initialized, but do not add
> > > + * entropy to the pool.
> > > + */
> > > + add_hwgenerator_randomness(rng_buffer, bytes_read, 0);
> > > }
> > >
> > > static inline void cleanup_rng(struct kref *kref)
> >
> > I found your patch by chance, searching for a solution for crng init delay
> > on my
> > headless machine. Unfortunately it hardly makes any difference for me. With
> > the
> > patch the system hangs for about 80s instead of 120s until the "crng init
> > done"
> > message.In contrast, doing a `cat /dev/hwrng >/dev/random` or running rngd
> > initializes the crng instantly.
> >
> > Isn't that delay the problem this patch tries to fix? Any idea what is wrong
> > here?
> >
> > Thanks!
> >
> > Best regards
> > Michael
> >
> >
>
> Yes that is the problem this is trying to address. My guess would be
> rng_get_data() is not returning as much data as requested, so the
> delay is reduced but not eliminated. Looking at implementation of
> rng_get_data() it appears this could be caused by device support for
> read() vs data_read(). I don't have a good feel for whether looping to
> retrieve more data here would be acceptable, it is certainly a bigger
> change than currently proposed.
>
> Thanks,
> Louis
Hi Louis,
that is what I thought first, too, but I was able to verify that 64 bytes are
read as expected.
It seems this is exactly what David noticed in your discussion about the quality
module parameter (https://patchwork.kernel.org/patch/10453893/#22130681):
> Interesting.
>
> add_hwgenereator_randomness() will call crng_fast_load(), regardless
> of entropy estimate/quality, if crng_init is 0. So initializing
> crng_init from the hwrng, regardless of quality, is already the
> intent.
>
> But hw_random only calls add_hwgenerator_randomness() if
> current_quality > 0, via the hwrng_fillfn() kthread.
>
> All that to say, I agree. add_early_randomness() should (indirectly)
> call crng_fast_load(), like add_hwgenerator_randomness() does.
When I set rng_quality=1024, the crng does get initialized more or less
instantly.
dmesg with default rng_quality=0:
[0.003831] ACPI: TPM2 0x9E0B7F70 34 (v03 LENOVO TC-
S06 1260 AMI )
[0.161803]
Re: [PATCH 4.19 000/142] 4.19.10-stable review
On Fri, Dec 14, 2018 at 12:58:05PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.10 release. > There are 142 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 Sun Dec 16 11:57:12 UTC 2018. > Anything received after that time might be too late. Results from Linaro’s test farm. Regressions detected. Summary kernel: 4.19.10-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 4875bf1f86d7bdc8dbf3222ab4028239446fab3f git describe: v4.19.9-143-g4875bf1f86d7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.9-143-g4875bf1f86d7 No regressions (compared to build v4.19.9) No fixes (compared to build v4.19.9) Ran 18346 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-containers-tests * ltp-cve-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * spectre-meltdown-checker-test * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-timers-tests * ltp-open-posix-tests * ltp-syscalls-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.14 00/89] 4.14.89-stable review
On Fri, Dec 14, 2018 at 12:59:13PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.89 release. > There are 89 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 Sun Dec 16 11:57:01 UTC 2018. > Anything received after that time might be too late. Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.14.89-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 159976987c2f89308c6293a31e8fa9543549b94b git describe: v4.14.88-90-g159976987c2f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.88-90-g159976987c2f No regressions (compared to build v4.14.88) No fixes (compared to build v4.14.88) Ran 21597 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 1/9] staging: rtl8188eu: cleanup declarations in rtw_mlme_ext.c
On Sat, 2018-12-15 at 17:46 +0100, Michael Straube wrote:
> Replace tabs with spaces and/or remove spaces in declarations.
> Remove unused/commented declarations, remove unnecessary comment,
> remove blank lines between declarations and add missing lines after
> declarations. Also clears some line over 80 characters checkpatch
> warnings.
[]
> diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
> b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
[]
> @@ -22,14 +22,14 @@ static u8 null_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
> /**
> OUI definitions for the vendor specific IE
> ***/
> -unsigned charRTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
> +unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
> unsigned char WMM_OUI[] = {0x00, 0x50, 0xf2, 0x02};
> -unsigned charWPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
> -unsigned charP2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
> -unsigned charWFD_OUI[] = {0x50, 0x6F, 0x9A, 0x0A};
> +unsigned char WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
> +unsigned char P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
> +unsigned char WFD_OUI[] = {0x50, 0x6F, 0x9A, 0x0A};
>
> -unsigned charWMM_INFO_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
> -unsigned charWMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
> +unsigned char WMM_INFO_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
> +unsigned char WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
>
> unsigned char WPA_TKIP_CIPHER[4] = {0x00, 0x50, 0xf2, 0x02};
> unsigned char RSN_TKIP_CIPHER[4] = {0x00, 0x0f, 0xac, 0x02};
unrelated trivia:
Might be nice to make some or all of these const or
even static const where appropriate.
Re: [PATCH v2 6/8] socket: Add SO_TIMESTAMP[NS]_NEW
On Sat, Dec 15, 2018 at 7:12 AM Willem de Bruijn wrote: > > On Fri, Dec 14, 2018 at 8:07 PM Deepa Dinamani wrote: > > > > > > diff --git a/arch/alpha/include/uapi/asm/socket.h > > > > b/arch/alpha/include/uapi/asm/socket.h > > > > index 00e45c80e574..352e3dc0b3d9 100644 > > > > --- a/arch/alpha/include/uapi/asm/socket.h > > > > +++ b/arch/alpha/include/uapi/asm/socket.h > > > > @@ -3,6 +3,7 @@ > > > > #define _UAPI_ASM_SOCKET_H > > > > > > > > #include > > > > +#include > > > > > > > > /* For setsockopt(2) */ > > > > /* > > > > @@ -110,12 +111,22 @@ > > > > > > > > #define SO_TIMESTAMP_OLD 29 > > > > #define SO_TIMESTAMPNS_OLD 35 > > > > + > > > > #define SO_TIMESTAMPING_OLD 37 > > > > > > > > +#define SO_TIMESTAMP_NEW 62 > > > > +#define SO_TIMESTAMPNS_NEW 63 > > > > + > > > > #if !defined(__KERNEL__) > > > > > > > > -#define SO_TIMESTAMP SO_TIMESTAMP_OLD > > > > -#define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > > > +#if __BITS_PER_LONG == 64 > > > > +#define SO_TIMESTAMP SO_TIMESTAMP_OLD > > > > +#define SO_TIMESTAMPNS SO_TIMESTAMPNS_OLD > > > > +#else > > > > +#define SO_TIMESTAMP (sizeof(time_t) == sizeof(__kernel_long_t) ? > > > > SO_TIMESTAMP_OLD : SO_TIMESTAMP_NEW) > > > > +#define SO_TIMESTAMPNS (sizeof(time_t) == sizeof(__kernel_long_t) ? > > > > SO_TIMESTAMPNS_OLD : SO_TIMESTAMPNS_NEW) > > > > +#endif > > > > + > > > > > > This is not platform specific. Perhaps it can be deduplicated. The > > > interface expects callers to include , not > > > directly. So perhaps it can go there? > > > > I'm not following what you are saying here. > > > > Are you talking about in kernel users or userspace interface? > > > > Userspace should always include sys/socket.h according to the man page. > > I'm not sure if userspace can even include linux/socket.h directly. > > On my distribution this includes bits/socket.h which in turn includes > > asm/socket.h. > > I meant include/uapi/linux/socket.h. > > But you're right that that is not referenced from sys/socket.h. > > I do see a reference to it in my bits/socket.h > > /* Socket level message types. This must match the definitions in >. */ > > so perhaps the logic could be both there and in libc bits/socket.h. bits/socket.h cannot be included directly, and it's just how one of the libc implementations decided to do it. It doesn't even have to exist. > > Which file gets installed as asm/socket.h is defined per architecture > > in the kbuild file such as > > arch/ia64/include/uapi/asm/Kbuild (without series applied): > > > > generic-y += poll.h > > generic-y += sembuf.h > > generic-y += shmbuf.h > > generic-y += socket.h > > > > Also the new timestamp numbers being added are not the same for all > > architectures. > > > > So I'm not sure how this can be moved to linux/socket.h. > > Does that matter, as long as they are defined? This basic block is the > same between all archs: 3 reasons for not doing this: 1. We do not want to break userspace. If we move this to linux/socket.h all the userspace programs now have to include linux/socket.h or get this definition through a new libc. 2. All the socket options are together in the file asm/socket.h. It doesn't seem good for maintainability to move just a few bits elsewhere. 3. There are only 4 arches (after the series is applied) that have their own asm/socket.h. And, this is because there seems to be significant differences to asm-generic/socket.h that don't seem logically obvious to group and eliminate some of the defines. Also for the other comment. The reason the conditionals were not consistent is because they were not consistent to begin with. I'm trying to follow your request to keep code churn to minimal. It's just that I moved to a different function as that seemed logical to me. Do you prefer me to remove that refactoring? -Deepa
Re: [PATCH 4.9 00/51] 4.9.146-stable review
On Fri, Dec 14, 2018 at 01:00:02PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.146 release. > There are 51 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 Sun Dec 16 11:56:52 UTC 2018. > Anything received after that time might be too late. Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.146-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 88d902c956b8078676b83e964db1f896bb548134 git describe: v4.9.145-52-g88d902c956b8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.145-52-g88d902c956b8 No regressions (compared to build v4.9.145) No fixes (compared to build v4.9.145) Ran 21461 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH 2/9] staging: rtl8188eu: remove unnecessary parentheses in rtw_mlme_ext.c
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 324 +-
1 file changed, 162 insertions(+), 162 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 4996227b6a2e..16c449d2e6c2 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -184,7 +184,7 @@ Following are some TX functions for WiFi MLME
void update_mgnt_tx_rate(struct adapter *padapter, u8 rate)
{
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
pmlmeext->tx_rate = rate;
DBG_88E("%s(): rate = %x\n", __func__, rate);
@@ -192,7 +192,7 @@ void update_mgnt_tx_rate(struct adapter *padapter, u8 rate)
void update_mgntframe_attrib(struct adapter *padapter, struct pkt_attrib
*pattrib)
{
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
memset((u8 *)(pattrib), 0, sizeof(struct pkt_attrib));
@@ -319,11 +319,11 @@ static void issue_beacon(struct adapter *padapter, int
timeout_ms)
struct ieee80211_hdr *pwlanhdr;
__le16 *fctrl;
unsigned int rate_len;
- struct xmit_priv *pxmitpriv = &(padapter->xmitpriv);
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
- struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
- struct wlan_bssid_ex *cur_network = &(pmlmeinfo->network);
+ struct xmit_priv *pxmitpriv = >xmitpriv;
+ struct mlme_priv *pmlmepriv = >mlmepriv;
+ struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = >mlmext_info;
+ struct wlan_bssid_ex *cur_network = >network;
u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
pmgntframe = alloc_mgtxmitframe(pxmitpriv);
@@ -349,7 +349,7 @@ static void issue_beacon(struct adapter *padapter, int
timeout_ms)
*(fctrl) = 0;
ether_addr_copy(pwlanhdr->addr1, bc_addr);
- ether_addr_copy(pwlanhdr->addr2, myid(&(padapter->eeprompriv)));
+ ether_addr_copy(pwlanhdr->addr2, myid(>eeprompriv));
ether_addr_copy(pwlanhdr->addr3, cur_network->MacAddress);
SetSeqNum(pwlanhdr, 0/*pmlmeext->mgnt_seq*/);
@@ -413,7 +413,7 @@ static void issue_beacon(struct adapter *padapter, int
timeout_ms)
pframe = rtw_set_ie(pframe, _SUPPORTEDRATES_IE_, min_t(unsigned int,
rate_len, 8), cur_network->SupportedRates, >pktlen);
/* DS parameter set */
- pframe = rtw_set_ie(pframe, _DSSET_IE_, 1, (unsigned char
*)&(cur_network->Configuration.DSConfig), >pktlen);
+ pframe = rtw_set_ie(pframe, _DSSET_IE_, 1, (unsigned char
*)_network->Configuration.DSConfig, >pktlen);
{
u8 erpinfo = 0;
@@ -460,15 +460,15 @@ static void issue_probersp(struct adapter *padapter,
unsigned char *da)
struct ieee80211_hdr *pwlanhdr;
__le16 *fctrl;
unsigned char *mac, *bssid;
- struct xmit_priv *pxmitpriv = &(padapter->xmitpriv);
+ struct xmit_priv *pxmitpriv = >xmitpriv;
#if defined(CONFIG_88EU_AP_MODE)
u8 *pwps_ie;
uint wps_ielen;
struct mlme_priv *pmlmepriv = >mlmepriv;
#endif
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
- struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
- struct wlan_bssid_ex *cur_network = &(pmlmeinfo->network);
+ struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = >mlmext_info;
+ struct wlan_bssid_ex *cur_network = >network;
unsigned int rate_len;
pmgntframe = alloc_mgtxmitframe(pxmitpriv);
@@ -486,7 +486,7 @@ static void issue_probersp(struct adapter *padapter,
unsigned char *da)
pframe = (u8 *)(pmgntframe->buf_addr) + TXDESC_OFFSET;
pwlanhdr = (struct ieee80211_hdr *)pframe;
- mac = myid(&(padapter->eeprompriv));
+ mac = myid(>eeprompriv);
bssid = cur_network->MacAddress;
fctrl = >frame_control;
@@ -573,7 +573,7 @@ static void issue_probersp(struct adapter *padapter,
unsigned char *da)
pframe = rtw_set_ie(pframe, _SUPPORTEDRATES_IE_, min_t(unsigned
int, rate_len, 8), cur_network->SupportedRates, >pktlen);
/* DS parameter set */
- pframe = rtw_set_ie(pframe, _DSSET_IE_, 1, (unsigned char
*)&(cur_network->Configuration.DSConfig), >pktlen);
+ pframe = rtw_set_ie(pframe, _DSSET_IE_, 1, (unsigned char
*)_network->Configuration.DSConfig, >pktlen);
if ((pmlmeinfo->state&0x03) == WIFI_FW_ADHOC_STATE) {
u8 erpinfo = 0;
@@ -610,9 +610,9 @@ static int issue_probereq(struct adapter *padapter,
__le16 *fctrl;
[PATCH 4/9] staging: rtl8188eu: convert unsigned char arrays to u8
Covert unsigned char arrays to u8 and make them static and/or const
where possible.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 18 ++---
.../staging/rtl8188eu/core/rtw_wlan_util.c| 26 +--
drivers/staging/rtl8188eu/include/rtw_mlme.h | 6 ++---
.../staging/rtl8188eu/include/rtw_mlme_ext.h | 9 ++-
4 files changed, 25 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index eda11eff5051..b5cd9f6c4e30 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -22,17 +22,15 @@ static u8 null_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
/**
OUI definitions for the vendor specific IE
***/
-unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
-unsigned char WMM_OUI[] = {0x00, 0x50, 0xf2, 0x02};
-unsigned char WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
-unsigned char P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
+const u8 RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
+const u8 WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
+static const u8 WMM_OUI[] = {0x00, 0x50, 0xf2, 0x02};
+static const u8 P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
-unsigned char WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
+static const u8 WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
-unsigned char WPA_TKIP_CIPHER[4] = {0x00, 0x50, 0xf2, 0x02};
-unsigned char RSN_TKIP_CIPHER[4] = {0x00, 0x0f, 0xac, 0x02};
-
-extern unsigned char REALTEK_96B_IE[];
+const u8 WPA_TKIP_CIPHER[4] = {0x00, 0x50, 0xf2, 0x02};
+const u8 RSN_TKIP_CIPHER[4] = {0x00, 0x0f, 0xac, 0x02};
/
MCS rate definitions
@@ -5210,7 +5208,7 @@ u8 setkey_hdl(struct adapter *padapter, u8 *pbuf)
struct setkey_parm *pparm = (struct setkey_parm *)pbuf;
struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
struct mlme_ext_info *pmlmeinfo = >mlmext_info;
- unsigned char null_sta[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ u8 null_sta[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
/* main tx key for wep. */
if (pparm->set_tx)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 9a20faad96c9..f01a50e8ba51 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -12,20 +12,18 @@
#include
#include
-static unsigned char ARTHEROS_OUI1[] = {0x00, 0x03, 0x7f};
-static unsigned char ARTHEROS_OUI2[] = {0x00, 0x13, 0x74};
-
-static unsigned char BROADCOM_OUI1[] = {0x00, 0x10, 0x18};
-static unsigned char BROADCOM_OUI2[] = {0x00, 0x0a, 0xf7};
-
-static unsigned char CISCO_OUI[] = {0x00, 0x40, 0x96};
-static unsigned char MARVELL_OUI[] = {0x00, 0x50, 0x43};
-static unsigned char RALINK_OUI[] = {0x00, 0x0c, 0x43};
-static unsigned char REALTEK_OUI[] = {0x00, 0xe0, 0x4c};
-static unsigned char AIRGOCAP_OUI[] = {0x00, 0x0a, 0xf5};
-static unsigned char EPIGRAM_OUI[] = {0x00, 0x90, 0x4c};
-
-unsigned char REALTEK_96B_IE[] = {0x00, 0xe0, 0x4c, 0x02, 0x01, 0x20};
+static const u8 ARTHEROS_OUI1[] = {0x00, 0x03, 0x7f};
+static const u8 ARTHEROS_OUI2[] = {0x00, 0x13, 0x74};
+static const u8 BROADCOM_OUI1[] = {0x00, 0x10, 0x18};
+static const u8 BROADCOM_OUI2[] = {0x00, 0x0a, 0xf7};
+static const u8 CISCO_OUI[] = {0x00, 0x40, 0x96};
+static const u8 MARVELL_OUI[] = {0x00, 0x50, 0x43};
+static const u8 RALINK_OUI[] = {0x00, 0x0c, 0x43};
+static const u8 REALTEK_OUI[] = {0x00, 0xe0, 0x4c};
+static const u8 AIRGOCAP_OUI[] = {0x00, 0x0a, 0xf5};
+static const u8 EPIGRAM_OUI[] = {0x00, 0x90, 0x4c};
+
+u8 REALTEK_96B_IE[] = {0x00, 0xe0, 0x4c, 0x02, 0x01, 0x20};
#define R2T_PHY_DELAY (0)
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme.h
b/drivers/staging/rtl8188eu/include/rtw_mlme.h
index 126b96906171..bfef66525944 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme.h
@@ -211,9 +211,9 @@ int hostapd_mode_init(struct adapter *padapter);
void hostapd_mode_unload(struct adapter *padapter);
#endif
-extern unsigned char WPA_TKIP_CIPHER[4];
-extern unsigned char RSN_TKIP_CIPHER[4];
-extern unsigned char REALTEK_96B_IE[];
+extern const u8 WPA_TKIP_CIPHER[4];
+extern const u8 RSN_TKIP_CIPHER[4];
+extern u8 REALTEK_96B_IE[];
extern const u8 MCS_rate_1R[16];
void rtw_joinbss_event_prehandle(struct adapter *adapter, u8 *pbuf);
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 62999bc06de5..1fb2349bd0a0 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -80,13 +80,8 @@
#define_48M_RATE_ 10
#define_54M_RATE_ 11
-
-extern unsigned char
[PATCH 6/9] staging: rtl8188eu: simplify null array initializations
Simplfy initialization of null arrays to improve readability
and save some lines.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 4 ++--
drivers/staging/rtl8188eu/core/rtw_xmit.c | 6 ++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index b5cd9f6c4e30..a7d85070281a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -17,7 +17,7 @@
#include
#include
-static u8 null_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
+static u8 null_addr[ETH_ALEN] = {};
/**
OUI definitions for the vendor specific IE
@@ -5208,7 +5208,7 @@ u8 setkey_hdl(struct adapter *padapter, u8 *pbuf)
struct setkey_parm *pparm = (struct setkey_parm *)pbuf;
struct mlme_ext_priv *pmlmeext = >mlmeextpriv;
struct mlme_ext_info *pmlmeinfo = >mlmext_info;
- u8 null_sta[] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+ u8 null_sta[ETH_ALEN] = {};
/* main tx key for wep. */
if (pparm->set_tx)
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 14e3f59b9009..3b1ccd138c3f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -592,7 +592,7 @@ static s32 xmitframe_addmic(struct adapter *padapter,
struct xmit_frame *pxmitfr
struct pkt_attrib *pattrib = >attrib;
struct security_priv *psecuritypriv = >securitypriv;
struct xmit_priv *pxmitpriv = >xmitpriv;
- u8 priority[4] = {0x0, 0x0, 0x0, 0x0};
+ u8 priority[4] = {};
u8 hw_hdr_offset = 0;
if (pattrib->psta)
@@ -605,9 +605,7 @@ static s32 xmitframe_addmic(struct adapter *padapter,
struct xmit_frame *pxmitfr
if (pattrib->encrypt == _TKIP_) {
/* encode mic code */
if (stainfo) {
- u8 null_key[16] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
- 0x0, 0x0};
+ u8 null_key[16] = {};
pframe = pxmitframe->buf_addr + hw_hdr_offset;
--
2.20.0
[PATCH 5/9] staging: rtl8188eu: constify arrays in rtw_wlan_util.c
The values of these arrays are never changed, so make them const.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index f01a50e8ba51..cbdb0fae8df8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -31,20 +31,20 @@ u8 REALTEK_96B_IE[] = {0x00, 0xe0, 0x4c, 0x02, 0x01, 0x20};
#define WAIT_FOR_BCN_TO_MIN(6000)
#define WAIT_FOR_BCN_TO_MAX(2)
-static u8 rtw_basic_rate_cck[4] = {
+static const u8 rtw_basic_rate_cck[4] = {
IEEE80211_CCK_RATE_1MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_CCK_RATE_2MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_CCK_RATE_5MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_CCK_RATE_11MB | IEEE80211_BASIC_RATE_MASK
};
-static u8 rtw_basic_rate_ofdm[3] = {
+static const u8 rtw_basic_rate_ofdm[3] = {
IEEE80211_OFDM_RATE_6MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_OFDM_RATE_12MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_OFDM_RATE_24MB | IEEE80211_BASIC_RATE_MASK
};
-static u8 rtw_basic_rate_mix[7] = {
+static const u8 rtw_basic_rate_mix[7] = {
IEEE80211_CCK_RATE_1MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_CCK_RATE_2MB | IEEE80211_BASIC_RATE_MASK,
IEEE80211_CCK_RATE_5MB | IEEE80211_BASIC_RATE_MASK,
--
2.20.0
[Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
The previous code pipeline used the stack to walk on the graph and
process a frame. Basically the vimc-sensor entity starts a thread that
generates the frames and calls the propagate_process function to send
this frame to each entity linked with a sink pad. The propagate_process
will call the process_frame of the entities which will call the
propagate_frame for each one of it's sink pad. This cycle will continue
until it reaches a vimc-capture entity that will finally return and
unstack.
This solution had many problems:
* It was a little bit slow
* It was susceptible to a stack overflow as it made indiscriminate
use of the stack.
* It doesn't allow frame rate control
* It was complex to understand
* It doesn't allow pipeline control
This commit proposes an alternative way to control vimc streams by
having a streamer object. This object will create a linear pipeline
walking backwards on the graph. When the stream starts it will simply
loop through the pipeline calling the respective process_frame function
for each entity on the pipeline.
This solution has some premises which are true for now:
* Two paths can never be enabled and streaming at the same time.
* There is no entity streaming frames to two source pads at the same
time.
* There is no entity receiving frames from two sink pads at the same
time.
Signed-off-by: Lucas A. M. Magalhães
---
Hi,
This patch introduces a streamer controller library for the vimc
driver. It's a step towards a optimized mode I've been discussing with
Helen.
I plan to pass a tpg struct through the pipeline. This tpg struct
will be configured in each entity and the capture will generate the
frames with the correct format at the end of the pipeline.
Thanks,
Lucas
drivers/media/platform/vimc/Makefile| 3 +-
drivers/media/platform/vimc/vimc-capture.c | 18 +-
drivers/media/platform/vimc/vimc-common.c | 50 ++
drivers/media/platform/vimc/vimc-common.h | 15 +-
drivers/media/platform/vimc/vimc-debayer.c | 26 +--
drivers/media/platform/vimc/vimc-scaler.c | 28 +---
drivers/media/platform/vimc/vimc-sensor.c | 56 ++-
drivers/media/platform/vimc/vimc-streamer.c | 176
drivers/media/platform/vimc/vimc-streamer.h | 38 +
9 files changed, 268 insertions(+), 142 deletions(-)
create mode 100644 drivers/media/platform/vimc/vimc-streamer.c
create mode 100644 drivers/media/platform/vimc/vimc-streamer.h
diff --git a/drivers/media/platform/vimc/Makefile
b/drivers/media/platform/vimc/Makefile
index 4b2e3de7856e..c4fc8e7d365a 100644
--- a/drivers/media/platform/vimc/Makefile
+++ b/drivers/media/platform/vimc/Makefile
@@ -5,6 +5,7 @@ vimc_common-objs := vimc-common.o
vimc_debayer-objs := vimc-debayer.o
vimc_scaler-objs := vimc-scaler.o
vimc_sensor-objs := vimc-sensor.o
+vimc_streamer-objs := vimc-streamer.o
obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o vimc-debayer.o
\
- vimc_scaler.o vimc_sensor.o
+ vimc_scaler.o vimc_sensor.o vimc_streamer.o
diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c
index 3f7e9ed56633..80d7515ec420 100644
--- a/drivers/media/platform/vimc/vimc-capture.c
+++ b/drivers/media/platform/vimc/vimc-capture.c
@@ -24,6 +24,7 @@
#include
#include "vimc-common.h"
+#include "vimc-streamer.h"
#define VIMC_CAP_DRV_NAME "vimc-capture"
@@ -44,7 +45,7 @@ struct vimc_cap_device {
spinlock_t qlock;
struct mutex lock;
u32 sequence;
- struct media_pipeline pipe;
+ struct vimc_stream stream;
};
static const struct v4l2_pix_format fmt_default = {
@@ -248,14 +249,13 @@ static int vimc_cap_start_streaming(struct vb2_queue *vq,
unsigned int count)
vcap->sequence = 0;
/* Start the media pipeline */
- ret = media_pipeline_start(entity, >pipe);
+ ret = media_pipeline_start(entity, >stream.pipe);
if (ret) {
vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
return ret;
}
- /* Enable streaming from the pipe */
- ret = vimc_pipeline_s_stream(>vdev.entity, 1);
+ ret = vimc_streamer_s_stream(>stream, >ved, 1);
if (ret) {
media_pipeline_stop(entity);
vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
@@ -273,8 +273,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
{
struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
- /* Disable streaming from the pipe */
- vimc_pipeline_s_stream(>vdev.entity, 0);
+ vimc_streamer_s_stream(>stream, >ved, 0);
/* Stop the media pipeline */
media_pipeline_stop(>vdev.entity);
@@ -355,8 +354,8 @@ static void vimc_cap_comp_unbind(struct device *comp,
struct device *master,
kfree(vcap);
}
-static void vimc_cap_process_frame(struct vimc_ent_device *ved,
-
[PATCH 1/9] staging: rtl8188eu: cleanup declarations in rtw_mlme_ext.c
Replace tabs with spaces and/or remove spaces in declarations.
Remove unused/commented declarations, remove unnecessary comment,
remove blank lines between declarations and add missing lines after
declarations. Also clears some line over 80 characters checkpatch
warnings.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 484 +-
1 file changed, 241 insertions(+), 243 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 6790b840aef8..4996227b6a2e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -22,14 +22,14 @@ static u8 null_addr[ETH_ALEN] = {0, 0, 0, 0, 0, 0};
/**
OUI definitions for the vendor specific IE
***/
-unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
+unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
unsigned char WMM_OUI[] = {0x00, 0x50, 0xf2, 0x02};
-unsigned char WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
-unsigned char P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
-unsigned char WFD_OUI[] = {0x50, 0x6F, 0x9A, 0x0A};
+unsigned char WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
+unsigned char P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
+unsigned char WFD_OUI[] = {0x50, 0x6F, 0x9A, 0x0A};
-unsigned char WMM_INFO_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
-unsigned char WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
+unsigned char WMM_INFO_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
+unsigned char WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
unsigned char WPA_TKIP_CIPHER[4] = {0x00, 0x50, 0xf2, 0x02};
unsigned char RSN_TKIP_CIPHER[4] = {0x00, 0x0f, 0xac, 0x02};
@@ -56,7 +56,7 @@ static struct rt_channel_plan_2g
RTW_ChannelPlan2G[RT_CHANNEL_DOMAIN_2G_MAX] = {
{{}, 0},
/* 0x05, RT_CHANNEL_DOMAIN_2G_NULL */
};
-static struct rt_channel_plan_map
RTW_ChannelPlanMap[RT_CHANNEL_DOMAIN_MAX] = {
+static struct rt_channel_plan_map RTW_ChannelPlanMap[RT_CHANNEL_DOMAIN_MAX] = {
/* 0x00 ~ 0x1F , Old Define = */
{0x02}, /* 0x00, RT_CHANNEL_DOMAIN_FCC */
{0x02}, /* 0x01, RT_CHANNEL_DOMAIN_IC */
@@ -154,8 +154,8 @@ int rtw_ch_set_search_ch(struct rt_channel_info *ch_set,
const u32 ch)
struct xmit_frame *alloc_mgtxmitframe(struct xmit_priv *pxmitpriv)
{
- struct xmit_frame *pmgntframe;
- struct xmit_buf *pxmitbuf;
+ struct xmit_frame *pmgntframe;
+ struct xmit_buf *pxmitbuf;
pmgntframe = rtw_alloc_xmitframe(pxmitpriv);
if (!pmgntframe) {
@@ -184,7 +184,7 @@ Following are some TX functions for WiFi MLME
void update_mgnt_tx_rate(struct adapter *padapter, u8 rate)
{
- struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
pmlmeext->tx_rate = rate;
DBG_88E("%s(): rate = %x\n", __func__, rate);
@@ -192,7 +192,7 @@ void update_mgnt_tx_rate(struct adapter *padapter, u8 rate)
void update_mgntframe_attrib(struct adapter *padapter, struct pkt_attrib
*pattrib)
{
- struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
memset((u8 *)(pattrib), 0, sizeof(struct pkt_attrib));
@@ -313,18 +313,18 @@ static int update_hidden_ssid(u8 *ies, u32 ies_len, u8
hidden_ssid_mode)
static void issue_beacon(struct adapter *padapter, int timeout_ms)
{
- struct xmit_frame *pmgntframe;
- struct pkt_attrib *pattrib;
- unsigned char *pframe;
+ struct xmit_frame *pmgntframe;
+ struct pkt_attrib *pattrib;
+ unsigned char *pframe;
struct ieee80211_hdr *pwlanhdr;
__le16 *fctrl;
- unsigned intrate_len;
- struct xmit_priv*pxmitpriv = &(padapter->xmitpriv);
+ unsigned int rate_len;
+ struct xmit_priv *pxmitpriv = &(padapter->xmitpriv);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
- struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
- struct wlan_bssid_ex*cur_network = &(pmlmeinfo->network);
- u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+ struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct wlan_bssid_ex *cur_network = &(pmlmeinfo->network);
+ u8 bc_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
pmgntframe = alloc_mgtxmitframe(pxmitpriv);
if (!pmgntframe) {
@@ -454,22 +454,22 @@ static void issue_beacon(struct adapter *padapter, int
timeout_ms)
static void
[PATCH 3/9] staging: rtl8188eu: remove unused arrays WFD_OUI and WMM_INFO_OUI
The arrays WFD_OUI and WMM_INFO_OUI are not used anywhere,
so remove them.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c| 2 --
drivers/staging/rtl8188eu/include/rtw_mlme_ext.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index 16c449d2e6c2..eda11eff5051 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -26,9 +26,7 @@ unsigned char RTW_WPA_OUI[] = {0x00, 0x50, 0xf2, 0x01};
unsigned char WMM_OUI[] = {0x00, 0x50, 0xf2, 0x02};
unsigned char WPS_OUI[] = {0x00, 0x50, 0xf2, 0x04};
unsigned char P2P_OUI[] = {0x50, 0x6F, 0x9A, 0x09};
-unsigned char WFD_OUI[] = {0x50, 0x6F, 0x9A, 0x0A};
-unsigned char WMM_INFO_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01};
unsigned char WMM_PARA_OUI[] = {0x00, 0x50, 0xf2, 0x02, 0x01, 0x01};
unsigned char WPA_TKIP_CIPHER[4] = {0x00, 0x50, 0xf2, 0x02};
diff --git a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
index 0ade33df16d2..62999bc06de5 100644
--- a/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8188eu/include/rtw_mlme_ext.h
@@ -84,10 +84,8 @@
extern unsigned char RTW_WPA_OUI[];
extern unsigned char WMM_OUI[];
extern unsigned char WPS_OUI[];
-extern unsigned char WFD_OUI[];
extern unsigned char P2P_OUI[];
-extern unsigned char WMM_INFO_OUI[];
extern unsigned char WMM_PARA_OUI[];
/* Channel Plan Type. */
--
2.20.0
[PATCH 7/9] staging: rtl8188eu: change return type of is_basicrate() to bool
The function is_basicrate() returns true or false, so change the
return type from int to bool.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index cbdb0fae8df8..d7553cc8b418 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -154,7 +154,7 @@ static unsigned char ratetbl_val_2wifirate(unsigned char
rate)
}
}
-static int is_basicrate(struct adapter *padapter, unsigned char rate)
+static bool is_basicrate(struct adapter *padapter, unsigned char rate)
{
int i;
unsigned char val;
--
2.20.0
[PATCH 8/9] staging: rtl8188eu: add spaces aroubd '&' in rtw_mlme_ext.c
Add spaces around '&' to follow kernel coding style.
Reported by ceckpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 92 ++-
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index a7d85070281a..1b6d9e770de1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -355,7 +355,7 @@ static void issue_beacon(struct adapter *padapter, int
timeout_ms)
pframe += sizeof(struct ieee80211_hdr_3addr);
pattrib->pktlen = sizeof(struct ieee80211_hdr_3addr);
- if ((pmlmeinfo->state&0x03) == WIFI_FW_AP_STATE) {
+ if ((pmlmeinfo->state & 0x03) == WIFI_FW_AP_STATE) {
int len_diff;
u8 *wps_ie;
uint wps_ielen;
@@ -503,7 +503,7 @@ static void issue_probersp(struct adapter *padapter,
unsigned char *da)
return;
#if defined(CONFIG_88EU_AP_MODE)
- if ((pmlmeinfo->state&0x03) == WIFI_FW_AP_STATE) {
+ if ((pmlmeinfo->state & 0x03) == WIFI_FW_AP_STATE) {
pwps_ie = rtw_get_wps_ie(cur_network->ies+_FIXED_IE_LENGTH_,
cur_network->ie_length-_FIXED_IE_LENGTH_, NULL, _ielen);
/* inerset & update wps_probe_resp_ie */
@@ -571,7 +571,7 @@ static void issue_probersp(struct adapter *padapter,
unsigned char *da)
/* DS parameter set */
pframe = rtw_set_ie(pframe, _DSSET_IE_, 1, (unsigned char
*)_network->Configuration.DSConfig, >pktlen);
- if ((pmlmeinfo->state&0x03) == WIFI_FW_ADHOC_STATE) {
+ if ((pmlmeinfo->state & 0x03) == WIFI_FW_ADHOC_STATE) {
u8 erpinfo = 0;
u32 ATIMWindow;
/* IBSS Parameter Set... */
@@ -1218,9 +1218,9 @@ static int _issue_nulldata(struct adapter *padapter,
unsigned char *da,
fctrl = >frame_control;
*(fctrl) = 0;
- if ((pmlmeinfo->state&0x03) == WIFI_FW_AP_STATE)
+ if ((pmlmeinfo->state & 0x03) == WIFI_FW_AP_STATE)
SetFrDs(fctrl);
- else if ((pmlmeinfo->state&0x03) == WIFI_FW_STATION_STATE)
+ else if ((pmlmeinfo->state & 0x03) == WIFI_FW_STATION_STATE)
SetToDs(fctrl);
if (power_mode)
@@ -1339,9 +1339,9 @@ static int _issue_qos_nulldata(struct adapter *padapter,
unsigned char *da,
fctrl = >frame_control;
*(fctrl) = 0;
- if ((pmlmeinfo->state&0x03) == WIFI_FW_AP_STATE)
+ if ((pmlmeinfo->state & 0x03) == WIFI_FW_AP_STATE)
SetFrDs(fctrl);
- else if ((pmlmeinfo->state&0x03) == WIFI_FW_STATION_STATE)
+ else if ((pmlmeinfo->state & 0x03) == WIFI_FW_STATION_STATE)
SetToDs(fctrl);
if (pattrib->mdata)
@@ -1612,7 +1612,7 @@ static void issue_action_BA(struct adapter *padapter,
unsigned char *raddr,
psta = rtw_get_stainfo(pstapriv, raddr);
if (psta) {
- start_seq =
(psta->sta_xmitpriv.txseq_tid[status & 0x07]&0xfff) + 1;
+ start_seq =
(psta->sta_xmitpriv.txseq_tid[status & 0x07] & 0xfff) + 1;
DBG_88E("BA_starting_seqctrl=%d for TID=%d\n",
start_seq, status & 0x07);
@@ -1828,7 +1828,7 @@ unsigned int send_delba(struct adapter *padapter, u8
initiator, u8 *addr)
struct mlme_ext_info *pmlmeinfo = >mlmext_info;
u16 tid;
- if ((pmlmeinfo->state&0x03) != WIFI_FW_AP_STATE)
+ if ((pmlmeinfo->state & 0x03) != WIFI_FW_AP_STATE)
if (!(pmlmeinfo->state & WIFI_FW_ASSOC_SUCCESS))
return _SUCCESS;
@@ -1840,7 +1840,7 @@ unsigned int send_delba(struct adapter *padapter, u8
initiator, u8 *addr)
for (tid = 0; tid < MAXTID; tid++) {
if (psta->recvreorder_ctrl[tid].enable) {
DBG_88E("rx agg disable tid(%d)\n", tid);
- issue_action_BA(padapter, addr,
RTW_WLAN_ACTION_DELBA, (((tid << 1) | initiator)&0x1F));
+ issue_action_BA(padapter, addr,
RTW_WLAN_ACTION_DELBA, (((tid << 1) | initiator) & 0x1F));
psta->recvreorder_ctrl[tid].enable = false;
psta->recvreorder_ctrl[tid].indicate_seq =
0x;
}
@@ -1849,7 +1849,7 @@ unsigned int send_delba(struct adapter *padapter, u8
initiator, u8 *addr)
for (tid = 0; tid < MAXTID; tid++) {
if (psta->htpriv.agg_enable_bitmap & BIT(tid)) {
DBG_88E("tx agg disable tid(%d)\n", tid);
- issue_action_BA(padapter, addr,
RTW_WLAN_ACTION_DELBA, (((tid << 1) | initiator)&0x1F));
+
[PATCH 9/9] staging: rtl8188eu: cleanup brace coding style issues
Cleanup brace coding style issues reported by checkpatch.
ERROR: space required before the open brace '{'
WARNING: braces {} are not necessary for single statement blocks
CHECK: Unbalanced braces around else statement
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 3 +--
drivers/staging/rtl8188eu/core/rtw_security.c | 4 ++--
drivers/staging/rtl8188eu/hal/phy.c | 4 ++--
drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 7 +++
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 3 +--
5 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index f9cdd1da8add..407f65cf7150 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -214,9 +214,8 @@ int rtw_cmd_thread(void *context)
pcmdpriv->cmdthd_running = false;
/* free all cmd_obj resources */
- while ((pcmd = rtw_dequeue_cmd(>cmd_queue))) {
+ while ((pcmd = rtw_dequeue_cmd(>cmd_queue)))
rtw_free_cmd_obj(pcmd);
- }
complete(>terminate_cmdthread_comp);
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index f7407632e80b..364d6ea14bf8 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1259,7 +1259,7 @@ u32 rtw_aes_encrypt(struct adapter *padapter, u8
*pxmitframe)
length =
pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
aes_cipher(prwskey, pattrib->hdrlen,
pframe, length);
- } else{
+ } else {
length =
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
aes_cipher(prwskey, pattrib->hdrlen,
pframe, length);
@@ -1267,7 +1267,7 @@ u32 rtw_aes_encrypt(struct adapter *padapter, u8
*pxmitframe)
pframe = (u8
*)round_up((size_t)(pframe), 8);
}
}
- } else{
+ } else {
RT_TRACE(_module_rtl871x_security_c_, _drv_err_, ("%s:
stainfo==NULL!!!\n", __func__));
res = _FAIL;
}
diff --git a/drivers/staging/rtl8188eu/hal/phy.c
b/drivers/staging/rtl8188eu/hal/phy.c
index 051cfbab78b1..51c40abfafaa 100644
--- a/drivers/staging/rtl8188eu/hal/phy.c
+++ b/drivers/staging/rtl8188eu/hal/phy.c
@@ -437,9 +437,9 @@ void
rtl88eu_dm_txpower_tracking_callback_thermalmeter(struct adapter *adapt)
thermal_val = (u8)(thermal_avg / thermal_avg_count);
if (dm_odm->RFCalibrateInfo.bDoneTxpower &&
- !dm_odm->RFCalibrateInfo.bReloadtxpowerindex)
+ !dm_odm->RFCalibrateInfo.bReloadtxpowerindex) {
delta = abs(thermal_val -
dm_odm->RFCalibrateInfo.ThermalValue);
- else {
+ } else {
delta = abs(thermal_val - hal_data->EEPROMThermalMeter);
if (dm_odm->RFCalibrateInfo.bReloadtxpowerindex) {
dm_odm->RFCalibrateInfo.bReloadtxpowerindex =
false;
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
index b832bbf202a5..701136f6 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c
@@ -90,15 +90,14 @@ static s32 FillH2CCmd_88E(struct adapter *adapt, u8
ElementID, u32 CmdLen, u8 *p
/* Write Ext command */
msgbox_ex_addr = REG_HMEBOX_EXT_0 + (h2c_box_num *
RTL88E_EX_MESSAGE_BOX_SIZE);
- for (cmd_idx = 0; cmd_idx < ext_cmd_len; cmd_idx++) {
+ for (cmd_idx = 0; cmd_idx < ext_cmd_len; cmd_idx++)
usb_write8(adapt, msgbox_ex_addr+cmd_idx, *((u8
*)(_cmd_ex)+cmd_idx));
- }
}
/* Write command */
msgbox_addr = REG_HMEBOX_0 + (h2c_box_num *
RTL88E_MESSAGE_BOX_SIZE);
- for (cmd_idx = 0; cmd_idx < RTL88E_MESSAGE_BOX_SIZE; cmd_idx++)
{
+ for (cmd_idx = 0; cmd_idx < RTL88E_MESSAGE_BOX_SIZE; cmd_idx++)
usb_write8(adapt, msgbox_addr+cmd_idx, *((u8
*)(_cmd)+cmd_idx));
- }
+
bcmd_down = true;
adapt->HalData->LastHMEBoxNum =
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index d5a1cf92ca6f..086f98d38cba 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++
Re: [PATCH 4.4 00/88] 4.4.168-stable review
On Fri, Dec 14, 2018 at 12:59:34PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.168 release. > There are 88 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 Sun Dec 16 11:56:41 UTC 2018. > Anything received after that time might be too late. Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.168-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 9c558d7fe359a962e214e426ffeb338e012bba39 git describe: v4.4.167-89-g9c558d7fe359 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.167-89-g9c558d7fe359 No regressions (compared to build v4.4.167-40-g840a97100a76) No fixes (compared to build v4.4.167-40-g840a97100a76) Ran 17023 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * install-android-platform-tools-r2600 * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.168-rc1 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.168-rc1-hikey-20181214-340 git commit: adb4d07253946d647c9afde07d2002b28b3c0ec0 git describe: 4.4.168-rc1-hikey-20181214-340 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.168-rc1-hikey-20181214-340 No regressions (compared to build 4.4.167-rc1-hikey-20181211-336) No fixes (compared to build 4.4.167-rc1-hikey-20181211-336) Ran 2756 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test -- Linaro LKFT https://lkft.linaro.org
Re: dt-bindings: watchdog: update bindings for MT7629 SoC
On Wed, Nov 07, 2018 at 03:10:36PM +0800, Ryder Lee wrote: > This updates dt-binding documentation for MT7629 SoC > > Signed-off-by: Ryder Lee Reviewed-by: Guenter Roeck > --- > Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > index 859dee1..8682d6a 100644 > --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt > @@ -8,6 +8,7 @@ Required properties: > "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 > "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 > "mediatek,mt7623-wdt", "mediatek,mt6589-wdt": for MT7623 > + "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 > > - reg : Specifies base physical address and size of the registers. >
