Re: [PATCH v2] video: fbdev: add Marvell PXA framebuffer binding
On Sun, Oct 4, 2015 at 12:31 PM, Robert Jarzmik wrote:
> Add documentation for the PXA frambuffer devicetree binding.
>
> Signed-off-by: Robert Jarzmik
> ---
> Since v1: Philipp's review on the whole binding
> ---
> .../devicetree/bindings/video/marvell,pxafb.txt| 80
> ++
> 1 file changed, 80 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> new file mode 100644
> index ..4d6bd490680d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> @@ -0,0 +1,80 @@
> +PXA LCDC Framebuffer
> +
> +
> +Required properties:
> + - compatible :
> + "marvell,pxa2xx-lcdc",
> + - reg : Should contain 1 register ranges(address and length).
> +Can contain an additional register range(address and length)
> +for fixed framebuffer memory. Useful for dedicated memories.
> + - interrupts : framebuffer controller interrupt
> +
> +Required nodes:
> + - clocks: phandle to input clocks.
> + - port: connection to the LCD panel (see video-interfaces.txt)
> +This nodes must have its properties bus-width and remote-endpoint
> set.
> +This should be in the board dts.
> +
> +Example:
> +
> + lcd-controller@4050 {
> + compatible = "marvell,pxa2xx-lcdc";
> + reg = <0x4400 0x1>;
> + interrupts = <17>;
> + clocks = <&clks CLK_LCD>;
> + interrupts = <23>;
The interrupt line is duplicated in the example.
> + status = "okay";
> +
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + bus-width = <16>;
> + };
> + };
> + };
> +
> +PXA LCDC Display
> +
> +Required properties (as per of_videomode_helper):
> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
> + "color-tft", "smart-panel"
Would it make sense to make this property optional and have the
default be "color-tft"? That is probably the most common one by far.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[v6] *** 8250_dw ***
From: Noam Camus v6 change: Adapt patch to latest version (nothing functional) v5 change: Two patches is now squashed into single one v4 change Remove patch for skipping looptest through DT option. This is now handled in our simulator model. Thanks to Vineet Gupta from Synopsys for his help. We are left with 2 patches which adds BIG endian support. V3 change: Use second level accessors for big/little endian port. The new accessors are now pointed from uart_port->private_data These accessors are initialized during driver probe(). Driver shouldn't access directly to readl/writel but to these new second level accessors (first level is at uart_port). e.g. at dw8250_check_LCR() and dw8250_setup_port() I replaced such direct calls. V2 changes: 1) better description for each commit. 2) adding to CC list the device tree maintainer. 3) rename dw8250_check_control() --> dw8250_check_LCR(). 4) remove bad patch of "add UPF_FIXED_TYPE to flags". Noam Camus (1): serial: 8250_dw: Add support for big-endian MMIO accesses drivers/tty/serial/8250/8250_dw.c | 72 1 files changed, 64 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0 chips
> > OK, I guess we got stuck in the follow-up discussions and missed the points. > > Yup, don't get me wrong here. I like this discussion and am willing to > listen to reasonable arguments. We could not agree more. I'm always up for a good discussion... ;-) > > My 1st point is: > > > > TPM1.2's 0x4000 SRK handle was a well-known, singleton, always-present > > key, that could be relied upon. > > > > TPM2.0's 0x8000 is a temporary, TPM-assigned, context-specific handle, > > that cannot be relied upon. > > > > Therefore, I think your patch should not use it. > > > > Instead, I'd recommend using the closest equivalent to an SRK that TPM2.0 > > has to offer, which is within the range 0x8100 to 0x8100. > > (see > > http://www.trustedcomputinggroup.org/resources/registry_of_reserved_tpm_20_handles_and_localities) > > You might want to use TPM2_GetCapability() to find the correct one. > > > > Also User-Space could reference any of these handles in the > > 0x8100-0x81FF range. This would be fine. > > Alright. How about requiring keyhandle as explicit option for TPM 2.0? > Would that be a more reasonable solution in your opinion? That would > acceptable for me. You mean getting rid of the default behaviour ? That sound reasonable to me as well. A later patch could add the possibility to use the TPM2_GetCapability() thing at a later stage then... > > My 2nd point is: > > > > It is IMHO a bad idea to allow user-space to provide transient handles as > > parameter to the TPM, because TSS2.0 will virtualize handles and /dev/tpm0 > > is single-access only. > > Instead I'd recommend passing context-saved-blobs to the kernel. > > > > Then you brought up the valid point that this requires kernel-space resource > > broker and I provided some sketch-idea in pseudo-code for discussion of > > general approach. I did not know that the access broker was solved already. > > Yeah. I'm not against implementing the broker and how I've been thinking > implementing it is not too far away what you just suggested. > > I'm not just seeing why that couldn't be done as a separate patch set > later on. I should have been more clear then. I agree that it can be added later on. Or rather I think it should be added at some later point... I was just trying to point out that the concept is not too difficult, since kernel-space (minimal) resource-manager makes a lot of people go "oh god, never ever, way too big, way too complicated", which IMHO it is not. Until then, I think that the call should just return -EBUSY when you cannot load the sealed data if no slots are available ? I looked at Patch 3/4 and it seems you default to -EPERM on TPM2_Create()- and TPM2_Load()-failures ? You might want to test against rc == TPM_RC_OBJECT_MEMORY and return -EBUSY in those cases. Would you agree ? (P.S. I can cross-post there if that's prefered ?) Cheers, Andreas-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one
Hi On 09/24/2015 01:01 PM, Peter Ujfalusi wrote: > Hi, > > Changes since v3: > - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got > squashed > by accident for v3 > - Added Tony's Acked-by to patch 11 (for mach-oamp2 part) Gentle ping on this series ;) -- Péter > Changes since v2: > - devm_kasprintf format string fixed > - Additional patch to enable dynamic paRAM slot usage when the channel mapping > is supported by the eDMA module. > On am335x we have 256 paRAM slots and 64 DMA channels, this means that we > had > 64 slots 'locked away' all the time. The dynamic paRAM slot logic will allow > us to use all 256 slots freely for any purpose. > > Changes since v1: > - Convert edma platform device registration to use > platform_device_register_full > - Moved the PM callback also to the dmaengine driver - missed in v1 > - Commit message added to: > ARM/dmaengine: edma: Remove limitation on the number of eDMA controllers > - New patch which reads the flag for the channel mapping support in one place > > Cover letter: > > with this series the edma two driver setup will be changed to have only one > driver to support eDMA3. The legacy edma interface will be removed and eDMA > can > only be used via dmaengine API from this point on. > In order to do the merge the following improvements has been done: > - One driver instance per eDMA: > - Any number of eDMA instances are supported (both legacy and DT boot) > - Not relying on global variables, arrays, etc > - Code simplification and optimizations in several places > > This change will also help us to do bigger changes in the eDMA driver since, > since now we have only one driver to work with. > > The series has been tested on: > da850-evm (OMAP-L138) > - with legacy and DT boot (both eDMA0 and eDMA1 is enabled) > - In code swapping the eDMA instances in legacy mode to make sure the second > instance is handled correctly. > > am335x-evmsk > - DT boot > > I think this series could go via the dmaengine tree. Changes are trivial under > arch/arm/ > > Regards, > Peter > --- > Peter Ujfalusi (25): > ARM: common: edma: Fix channel parameter for irq callbacks > ARM: common: edma: Remove unused functions > dmaengine: edma: Simplify and optimize the edma_execute path > ARM: davinci/common: Convert edma driver to handle one eDMA instance > per driver > ARM/dmaengine: edma: Move of_dma_controller_register to the dmaengine > driver > ARM: common: edma: Internal API to use pointer to 'struct edma' > ARM/dmaengine: edma: Public API to use private struct pointer > ARM/dmaengine: edma: Remove limitation on the number of eDMA > controllers > ARM: davinci: Use platform_device_register_full() to create pdev for > eDMA > ARM: davinci: Add dma_mask to eDMA devices > ARM/dmaengine: edma: Merge the two drivers under drivers/dma/ > dmaengine: edma: Allocate memory dynamically for bitmaps and > structures > dmaengine: edma: Parameter alignment and long line fixes > dmaengine: edma: Use devm_kcalloc when possible > dmaengine: edma: Cleanup regarding the use of dev around the code > dmaengine: edma: Use dev_dbg instead pr_debug > dmaengine: edma: Use the edma_write_slot instead open coded > memcpy_toio > dmaengine: edma: Print warning when linking slots from different eDMA > dmaengine: edma: Consolidate the comments for functions > dmaengine: edma: Simplify the interrupt handling > dmaengine: edma: Move the pending error check into helper function > dmaengine: edma: Simplify and optimize ccerr interrupt handler > dmaengine: edma: Read channel mapping support only once from HW > dmaengine: edma: Rename bitfields for slot and channel usage tracking > dmaengine: edma: Dynamic paRAM slot handling if HW supports it > > arch/arm/Kconfig |1 - > arch/arm/common/Kconfig |3 - > arch/arm/common/Makefile |1 - > arch/arm/common/edma.c| 1876 > - > arch/arm/mach-davinci/devices-da8xx.c | 122 +-- > arch/arm/mach-davinci/dm355.c | 40 +- > arch/arm/mach-davinci/dm365.c | 25 +- > arch/arm/mach-davinci/dm644x.c| 40 +- > arch/arm/mach-davinci/dm646x.c| 44 +- > arch/arm/mach-omap2/Kconfig |1 - > drivers/dma/Kconfig |1 - > drivers/dma/edma.c| 1569 --- > include/linux/platform_data/edma.h| 101 -- > 13 files changed, 1523 insertions(+), 2301 deletions(-) > delete mode 100644 arch/arm/common/edma.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile
From: Mark Brown Date: Mon, 5 Oct 2015 15:57:22 +0100 > On Mon, Oct 05, 2015 at 09:29:31AM -0400, j...@ringle.org wrote: >> From: Jon Ringle >> >> The only time that it makes sense to call a custom provided reg_update_bits >> function, is the register being updated is one that has volatile bits. >> Otherwise, the normal read/modify/write cycle (where the read is likely to >> be free from the cache) will do just fine. This should keep the reg cache >> intact, since volatile registers won't get cached anyway. > > Dave, to be clear please do *not* apply this patch at least for the time > being - I've not reviewed it or the one from Thursday that you applied > this morning. It's applied, it's pushed out to my tree, and therefore this will need to be fixed up with a relative patch of some sort. What you don't seem to understand is that my GIT tree is never rebased or mangled because many people depend upon it. So once a patch is applied, that commit lives on forever. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function
From: Mark Brown Date: Mon, 5 Oct 2015 15:25:31 +0100 > On Mon, Oct 05, 2015 at 06:16:09AM -0700, David Miller wrote: > >> >> Applied. > >> > Thanks David. However, I've sent a v3 patch, and also expecting feedback >> > from Mark Brown on the regmap portion of it. > >> Please send me relative changes from v2 to v3, thanks. > >> Sorry about that. > > Ugh, this is a mess :( Can you please drop this patch instead? I can't just "drop" changes. Once a commit hits my tree it is part of the permanent record. The easiest thing to do is to send a relative fix, and that's why I have asked for exactly that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the audit tree
Hi Paul,
After merging the audit tree, today's linux-next build (i386 defconfig
and others) produced this warning:
security/lsm_audit.c: In function 'dump_common_audit_data':
security/lsm_audit.c:340:9: warning: passing argument 1 of 'unix_sk' discards
'const' qualifier from pointer target type
u = unix_sk(sk);
^
In file included from security/lsm_audit.c:22:0:
include/net/af_unix.h:67:33: note: expected 'struct sock *' but argument is of
type 'const struct sock *'
static inline struct unix_sock *unix_sk(struct sock *sk)
^
Introduced by commit
43cfd5e38587 ("audit: constify parts of common_audit_data and
lsm_network_audit")
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
arch/mips/include/uapi/asm/unistd.h
arch/mips/kernel/scall32-o32.S
arch/mips/kernel/scall64-n32.S
arch/mips/kernel/scall64-64.S
arch/mips/kernel/scall64-o32.S
between commit:
96fc7a9cee67 ("MIPS: Wire up userfaultfd and membarrier syscalls.")
from Linus' tree and commit:
4f9b011b10e7 ("mips: add entry for new mlock2 syscall")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/include/uapi/asm/unistd.h
index cfabadb135d9,d0bdfaa13ee9..
--- a/arch/mips/include/uapi/asm/unistd.h
+++ b/arch/mips/include/uapi/asm/unistd.h
@@@ -377,18 -377,17 +377,19 @@@
#define __NR_memfd_create (__NR_Linux + 354)
#define __NR_bpf (__NR_Linux + 355)
#define __NR_execveat (__NR_Linux + 356)
-#define __NR_mlock2 (__NR_Linux + 357)
+#define __NR_userfaultfd (__NR_Linux + 357)
+#define __NR_membarrier (__NR_Linux + 358)
++#define __NR_mlock2 (__NR_Linux + 359)
/*
* Offset of the last Linux o32 flavoured syscall
*/
- #define __NR_Linux_syscalls 358
-#define __NR_Linux_syscalls 357
++#define __NR_Linux_syscalls 359
#endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
#define __NR_O32_Linux4000
- #define __NR_O32_Linux_syscalls 358
-#define __NR_O32_Linux_syscalls 357
++#define __NR_O32_Linux_syscalls 359
#if _MIPS_SIM == _MIPS_SIM_ABI64
@@@ -713,18 -712,17 +714,19 @@@
#define __NR_memfd_create (__NR_Linux + 314)
#define __NR_bpf (__NR_Linux + 315)
#define __NR_execveat (__NR_Linux + 316)
-#define __NR_mlock2 (__NR_Linux + 317)
+#define __NR_userfaultfd (__NR_Linux + 317)
+#define __NR_membarrier (__NR_Linux + 318)
++#define __NR_mlock2 (__NR_Linux + 319)
/*
* Offset of the last Linux 64-bit flavoured syscall
*/
- #define __NR_Linux_syscalls 318
-#define __NR_Linux_syscalls 317
++#define __NR_Linux_syscalls 319
#endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */
#define __NR_64_Linux 5000
- #define __NR_64_Linux_syscalls318
-#define __NR_64_Linux_syscalls317
++#define __NR_64_Linux_syscalls319
#if _MIPS_SIM == _MIPS_SIM_NABI32
@@@ -1053,17 -1051,16 +1055,18 @@@
#define __NR_memfd_create (__NR_Linux + 318)
#define __NR_bpf (__NR_Linux + 319)
#define __NR_execveat (__NR_Linux + 320)
-#define __NR_mlock2 (__NR_Linux + 321)
+#define __NR_userfaultfd (__NR_Linux + 321)
+#define __NR_membarrier (__NR_Linux + 322)
++#define __NR_mlock2 (__NR_Linux + 323)
/*
* Offset of the last N32 flavoured syscall
*/
- #define __NR_Linux_syscalls 322
-#define __NR_Linux_syscalls 321
++#define __NR_Linux_syscalls 323
#endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */
#define __NR_N32_Linux6000
- #define __NR_N32_Linux_syscalls 322
-#define __NR_N32_Linux_syscalls 321
++#define __NR_N32_Linux_syscalls 323
#endif /* _UAPI_ASM_UNISTD_H */
diff --cc arch/mips/kernel/scall32-o32.S
index 65a74e4f0f45,b0b377aa1d5d..
--- a/arch/mips/kernel/scall32-o32.S
+++ b/arch/mips/kernel/scall32-o32.S
@@@ -592,5 -599,4 +592,6 @@@ EXPORT(sys_call_table
PTR sys_memfd_create
PTR sys_bpf /* 4355 */
PTR sys_execveat
+ PTR sys_userfaultfd
+ PTR sys_membarrier
+ PTR sys_mlock2
diff --cc arch/mips/kernel/scall64-64.S
index e732981cf99f,f12eb03c0961..
--- a/arch/mips/kernel/scall64-64.S
+++ b/arch/mips/kernel/scall64-64.S
@@@ -430,6 -436,5 +430,7 @@@ EXPORT(sys_call_table
PTR sys_memfd_create
PTR sys_bpf /* 5315 */
PTR sys_execveat
+ PTR sys_userfaultfd
+ PTR sys_membarrier
+ PTR sys_mlock2
.size sys_call_table,.-sys_call_table
diff --cc arch/mips/kernel/scall64-n32.S
index c79484397584,ecdd65a2b02c..
--- a/arch/mips/kernel/scall64-n32.S
+++ b/arch/mips/kernel/scall64-n32.S
@@@ -420,6 -429,5 +420,7 @@@ EXPORT(sysn32_call_table
PTR sys_memfd_create
PTR sys_bpf
PTR compat_sys_execveat /* 6320 */
+ PTR sys_userfaultfd
+ PTR sys_membarrier
+ PTR sys_mlock2
.size sysn32_call_table,.-sysn32_call_table
Re: Build regressions/improvements in v4.3-rc4
On Mon, Oct 05, 2015 at 12:38:55PM +0200, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v4.3-rc4[1] compared to v4.2[2]. > > 8 improvements: > - /home/kisskb/slave/src/drivers/net/ethernet/via/via-rhine.c: error: > implicit declaration of function 'pci_iomap' > [-Werror=implicit-function-declaration]: 1098:2 => > - /home/kisskb/slave/src/drivers/net/ethernet/via/via-rhine.c: error: > implicit declaration of function 'pci_iounmap' > [-Werror=implicit-function-declaration]: 1119:2 => I saw this message with avr32 allmodconfig. Fix already in linux-next. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] Input: db9 - store object at correct index
On Mon, Oct 05, 2015 at 05:32:05PM -0700, Dmitry Torokhov wrote:
> On Sat, Oct 03, 2015 at 02:54:56PM +0530, Sudip Mukherjee wrote:
> > The variable i is used to check the port to attach to and we are
> > supposed to save the reference of struct db9 in the location given by
> > db9_base[i]. But after finding out the index, i is getting modified again
> > so we saved in a wrong index.
> > While at it mark db9_base[i] as NULL after it is freed.
> >
> > Fixes: 2260c419b52b ("Input: db9 - use parallel port device model")
> > Signed-off-by: Sudip Mukherjee
>
> Applied the lot, thank you.
Thanks. And the change for serio/parkbd was pending. You said it was
clashing with other changs. Do i need to rebase and send you?
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] ARM64:Fix MINSIGSTKSZ and SIGSTKSZ
MINSIGSTKSZ and SIGSTKSZ for ARM64 are not correctly set in latest kernel. This patch fixes this issue. This issue is reported in LTP (testcase: sigaltstack02.c). Testcase failed when sigaltstack() called with stack size "MINSIGSTKSZ - 1" Since in Glibc-2.22, MINSIGSTKSZ is set to 5120 but in kernel it is set to 2048 so testcase gets failed. Testcase Output: sigaltstack02 1 TPASS : stgaltstack() fails, Invalid Flag value,errno:22 sigaltstack02 2 TFAIL : sigaltstack() returned 0, expected -1,errno:12 Reported Issue in Glibc Bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=16850 Bugfix in Glibc-2.22: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=sysdeps/unix/ sysv/linux/aarch64/bits/sigstack.h;h=8f2fb76e3e81734ef8a9cf9ae40daf4705 f31c35;hb=b763f6ae859ecea70a5dacb8ad45c71d5f667e2e Signed-off-by: Akhilesh Kumar Signed-off-by: Manjeet Pawar Signed-off-by: Rohit Thapliyal --- v1 -> Changes in uapi overall header v2 -> Changes done in arm64 headers arch/arm64/include/uapi/asm/signal.h |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/include/uapi/asm/signal.h b/arch/arm64/include/uapi/asm/signal.h index 8d1e723..5ac56cf 100644 --- a/arch/arm64/include/uapi/asm/signal.h +++ b/arch/arm64/include/uapi/asm/signal.h @@ -21,4 +21,9 @@ #include +#undef MINSIGSTKSZ +#undef SIGSTKSZ +#define MINSIGSTKSZ 5120 +#define SIGSTKSZ16384 + #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New helper to free highmem pages in larger chunks
On Tuesday 06 October 2015 03:40 AM, Andrew Morton wrote:
> On Sat, 3 Oct 2015 18:25:13 +0530 Vineet Gupta
> wrote:
>
>> Hi,
>>
>> I noticed increased boot time when enabling highmem for ARC. Turns out that
>> freeing highmem pages into buddy allocator is done page at a time, while it
>> is
>> batched for low mem pages. Below is call flow.
>>
>> I'm thinking of writing free_highmem_pages() which takes start and end pfn
>> and
>> want to solicit some ideas whether to write it from scratch or preferably
>> call
>> existing __free_pages_memory() to reuse the logic to convert a pfn range into
>> {pfn, order} tuples.
>>
>> For latter however there are semantical differences as you can see below
>> which I'm
>> not sure of:
>> -highmem page->count is set to 1, while 0 for low mem
> That would be weird.
>
> Look more closely at __free_pages_boot_core() - it uses
> set_page_refcounted() to set the page's refcount to 1. Those
> set_page_count() calls look superfluous to me.
If you closer still, set_page_refcounted() is called outside the loop for the
first page only. For all pages, loop iterator sets them to 1. Turns out there's
more fun here
I ran this under a debugger and much earlier in boot process, there's existing
setting of page count to 1 for *all* pages of *all* zones (include highmem
pages).
See call flow below.
free_area_init_node
free_area_init_core
loops thru all zones
memmap_init_zone
loops thru all pages of zones
__init_single_page
This means the subsequent setting of page count to 0 (or 1 for the special first
page) is superfluous - actually buggy at best. I will send a patch to fix that.
I
hope I don't break some obscure init path which doesn't hit the above init.
>
>> -atomic clearing of page reserved flag vs. non atomic
> I doubt if the atomic is needed - who else can be looking at this page
> at this time?
I'll send another one to separately fix that as well. Seems like boot mem setup
is
a relatively neglect part of kernel.
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (i386 defconfig)
failed like this:
net/built-in.o: In function `fib_rebalance':
fib_semantics.c:(.text+0x9d6d4): undefined reference to `__divdi3'
Caused by commit
0e884c78ee19 ("ipv4: L3 hash-based multipath")
I have reverted that commit (and the following commit since it may depend
on the former) for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] h8300: Fix build error due to missing word-at-a-time.h
h8300 builds fail with
lib/string.c:31:32: fatal error: asm/word-at-a-time.h: No such file or directory
Fixes: 30035e45753b ("string: provide strscpy()")
Cc: Chris Metcalf
Signed-off-by: Guenter Roeck
---
arch/h8300/include/asm/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild
index 70e6ae1e7006..373cb23301e3 100644
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@ -73,4 +73,5 @@ generic-y += uaccess.h
generic-y += ucontext.h
generic-y += unaligned.h
generic-y += vga.h
+generic-y += word-at-a-time.h
generic-y += xor.h
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT
On Tue, 2015-10-06 at 06:20 +0100, gre...@linuxfoundation.org wrote: > On Tue, Oct 06, 2015 at 06:12:40AM +0100, gre...@linuxfoundation.org wrote: > > On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote: > > > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote: > > > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote: > > > > > From: Sudeep Dutt > > > > > > > > > > iova is a library which can be built without IOMMU_SUPPORT > > > > > > > > > > Signed-off-by: Sudeep Dutt > > > > > > > > The first three of these patches are in 4.3-rc4 already. Apologies for > > > > the delay in pushing them out. > > > > > > > > This one looks sane enough too, but perhaps in that case we should move > > > > the code *out* of drivers/iommu/ and into lib/iova/ ? > > > > > > > > > > Yes, moving the code into lib/iova is the correct long term solution. I > > > have sent Greg a patch which reverts this commit since it is no longer > > > required and will create a merge conflict for him unnecessarily as well > > > with 4.3-rc4. > > > > I can handle merge issues, that's trivial. Reverting the patch > > shoulnd't really be needed, right? Let me see what happens when I merge > > to see if your patch is necessary... > > Ok, I don't think it is needed, the merge was pretty trivial. > > Can you test out my char-misc-testing branch right now to see if it's > all ok with the merge? If so, I'll move it all over to the "real" place > for it to start showing up in linux-next, i.e. my char-misc-next branch. > Hi Greg, I think it is best to revert this patch as it is incorrect. The iommu folder gets compiled only if IOMMU_SUPPORT is enabled so IOMMU_IOVA should indeed be included only when IOMMU_SUPPORT is enabled. Sincere apologies for the mess here but I believe it will all get fixed up if you accept the revert of 353649e5da I sent across earlier today. Thanks, Sudeep Dutt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT
On Tue, Oct 06, 2015 at 06:12:40AM +0100, gre...@linuxfoundation.org wrote: > On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote: > > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote: > > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote: > > > > From: Sudeep Dutt > > > > > > > > iova is a library which can be built without IOMMU_SUPPORT > > > > > > > > Signed-off-by: Sudeep Dutt > > > > > > The first three of these patches are in 4.3-rc4 already. Apologies for > > > the delay in pushing them out. > > > > > > This one looks sane enough too, but perhaps in that case we should move > > > the code *out* of drivers/iommu/ and into lib/iova/ ? > > > > > > > Yes, moving the code into lib/iova is the correct long term solution. I > > have sent Greg a patch which reverts this commit since it is no longer > > required and will create a merge conflict for him unnecessarily as well > > with 4.3-rc4. > > I can handle merge issues, that's trivial. Reverting the patch > shoulnd't really be needed, right? Let me see what happens when I merge > to see if your patch is necessary... Ok, I don't think it is needed, the merge was pretty trivial. Can you test out my char-misc-testing branch right now to see if it's all ok with the merge? If so, I'll move it all over to the "real" place for it to start showing up in linux-next, i.e. my char-misc-next branch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: kernel BUG at mm/slub.c:1447!
On Mon, Oct 05, 2015 at 07:12:17PM -0700, Andrew Morton wrote: > On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton > wrote: > > > Maybe it would be better to add the gfp_t argument to the > > address_space_operations. At a minimum, writepage(), readpage(), > > writepages(), readpages(). What a pickle. > > I'm being dumb. All we need to do is to add a new > > address_space_operations.readpage_gfp(..., gfp_t gfp) > > etc. That should be trivial. Each fs type only has 2-4 instances of > address_space_operations so the overhead is miniscule. > > As a background janitorial thing we can migrate filesystems over to the > new interface then remove address_space_operations.readpage() etc. But > this *would* add overhead: more stack and more text for no gain. So > perhaps we just leave things as they are. > > That's so simple that I expect we can short-term fix this bug with that > approach. umm, something like > > --- a/fs/mpage.c~a > +++ a/fs/mpage.c > @@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, st > static struct bio * > do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages, > sector_t *last_block_in_bio, struct buffer_head *map_bh, > - unsigned long *first_logical_block, get_block_t get_block) > + unsigned long *first_logical_block, get_block_t get_block, > + gfp_t gfp) Simple enough, but not sufficient to avoid deadlocks because this doesn't address the common vector for deadlock that was reported. i.e. deadlocks due to the layering dependency the loop device creates between two otherwise independent filesystems. If read IO through the loop device does GFP_KERNEL allocations, then it is susceptible to deadlock as that can force writeback and transactions from the filesystem on top of the loop device, which does more IO to the loop device, which then backs up on the backing file inode mutex. Forwards progress cannot be made until the GFP_KERNEL allocation succeeds, but that depends on the loop device making forwards progress... The loop device indicates this is a known problems tries to avoid these deadlocks by doing this on it's backing file: mapping_set_gfp_mask(mapping, lo->old_gfp_mask & ~(__GFP_IO|__GFP_FS)) to try to ensure that mapping related allocations do not cause inappropriate reclaim contexts to be triggered. This is a problem independent of any specific filesystem - let's not hack a workaround into a specific filesystem just because the problem was reported on that filesystem Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v2 04/22] iommu: Allow iova to be used without requiring IOMMU_SUPPORT
On Mon, Oct 05, 2015 at 10:38:43AM -0700, Sudeep Dutt wrote: > On Mon, 2015-10-05 at 03:50 -0700, Woodhouse, David wrote: > > On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote: > > > From: Sudeep Dutt > > > > > > iova is a library which can be built without IOMMU_SUPPORT > > > > > > Signed-off-by: Sudeep Dutt > > > > The first three of these patches are in 4.3-rc4 already. Apologies for > > the delay in pushing them out. > > > > This one looks sane enough too, but perhaps in that case we should move > > the code *out* of drivers/iommu/ and into lib/iova/ ? > > > > Yes, moving the code into lib/iova is the correct long term solution. I > have sent Greg a patch which reverts this commit since it is no longer > required and will create a merge conflict for him unnecessarily as well > with 4.3-rc4. I can handle merge issues, that's trivial. Reverting the patch shoulnd't really be needed, right? Let me see what happens when I merge to see if your patch is necessary... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 12/22] arm64: Delay cpu feature checks
Hi Suzuki,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: arm64-alldefconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Suzuki-K-Poulose/arm64-Consolidate-CPU-feature-handling
HEAD bfdef3a10032e84cc7ae186a058443219f110679 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/arm64/kernel/cpufeature.c: In function 'cpu_enable_features':
>> arch/arm64/kernel/cpufeature.c:733:52: error: 'const struct
>> arm64_cpu_capabilities' has no member named 'sys_reg'
if(!cpus_have_cap(caps[i].capability) || !caps[i].sys_reg)
^
arch/arm64/kernel/cpufeature.c:739:47: error: 'const struct
arm64_cpu_capabilities' has no member named 'sys_reg'
if (!feature_matches(read_cpu_sysreg(caps[i].sys_reg), &caps[i]))
^
vim +733 arch/arm64/kernel/cpufeature.c
727 const struct arm64_cpu_capabilities *caps = arm64_features;
728
729 for(i = 0; caps[i].desc; i++)
730 if (caps[i].enable && cpus_have_cap(caps[i].capability))
731 caps[i].enable(NULL);
732 for(i = 0; caps[i].desc; i++) {
> 733 if(!cpus_have_cap(caps[i].capability) ||
> !caps[i].sys_reg)
734 continue;
735 /*
736 * If the new CPU misses an advertised feature, we
cannot proceed
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v2] staging: rtl8723au: Fix sparse errors in rtl8723a_cmd.c
From: Jacob Kiefer
This patch fixes the following sparse errors:
CHECK drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
...
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
expected unsigned int [unsigned] [usertype]
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:118:25: \
got restricted __le32 [usertype]
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
warning: incorrect type in assignment (different base types)
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
expected unsigned int [unsigned] [usertype] mask
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c:130:14: \
got restricted __le32 [usertype]
...
Signed-off-by: Jacob Kiefer
---
Took a fresh look at the code. In v2, verified that the converted
buffer logic is the same as previous: i.e. an 8-bit pointer to
what really is a 32-bit little endian buffer is passed to
FillH2CCmd and used in a memcpy within. Likewise, a 32-bit little endian
mask is used in memcpy. This patch makes the code cleaner with
no confusing reuse of buffers for both little- and (possibly)
big-endian data and clears the sparse errors.
As for __le32 typing, le32 is not available in this scope,
since it is defined under fs/ntfs/types.h.
---
drivers/staging/rtl8723au/hal/rtl8723a_cmd.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
index 9733aa6..cceda59 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723a_cmd.c
@@ -115,9 +115,11 @@ exit:
int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter, u8 *param)
{
- *((u32 *)param) = cpu_to_le32(*((u32 *)param));
+ __le32 leparam;
- FillH2CCmd(padapter, RSSI_SETTING_EID, 3, param);
+ leparam = cpu_to_le32(*((u32 *)param));
+
+ FillH2CCmd(padapter, RSSI_SETTING_EID, 3, (u8 *)&leparam);
return _SUCCESS;
}
@@ -125,10 +127,11 @@ int rtl8723a_set_rssi_cmd(struct rtw_adapter *padapter,
u8 *param)
int rtl8723a_set_raid_cmd(struct rtw_adapter *padapter, u32 mask, u8 arg)
{
u8 buf[5];
+ __le32 lemask;
memset(buf, 0, 5);
- mask = cpu_to_le32(mask);
- memcpy(buf, &mask, 4);
+ lemask = cpu_to_le32(mask);
+ memcpy(buf, &lemask, 4);
buf[4] = arg;
FillH2CCmd(padapter, MACID_CONFIG_EID, 5, buf);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/12] KVM: x86: Replace call-back set_tsc_khz() with a common function
On Mon, Oct 05, 2015 at 09:53:26PM +0200, Radim Krčmář wrote:
> 2015-09-28 13:38+0800, Haozhong Zhang:
> > Both VMX and SVM propagate virtual_tsc_khz in the same way, so this
> > patch removes the call-back set_tsc_khz() and replaces it with a common
> > function.
> >
> > Signed-off-by: Haozhong Zhang
> > ---
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > +static void set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz, bool
> > scale)
> > +{
> > + u64 ratio, khz;
> | [...]
> > + khz = user_tsc_khz;
>
> I'd use "user_tsc_khz" directly.
>
I'll do so.
> > + /* TSC scaling required - calculate ratio */
> > + shift = (kvm_tsc_scaling_ratio_frac_bits <= 32) ?
> > + kvm_tsc_scaling_ratio_frac_bits : 32;
> > + ratio = khz << shift;
> > + do_div(ratio, tsc_khz);
> > + ratio <<= (kvm_tsc_scaling_ratio_frac_bits - shift);
>
> VMX is losing 16 bits by this operation; normal fixed point division
> could get us a smaller drift (and an one-liner here) ...
> at 4.3 GHz, 32 instead of 48 bits after decimal point translate to one
> "lost" TSC tick per second, in the worst case.
>
> Please mention that we are truncating on purpose :)
It's intentional to avoid the potential overflow in
khz << kvm_tsc_scaling_ratio_frac_bits.
For VMX where kvm_tsc_scaling_ratio_frac_bits == 48, the above
expression is only safe to left shift a pretty small khz (< 2^16 KHz
or 65.5 MHz). Thus, I decided to sacrifice the precision for safety.
I chose to truncate at the boundary of 32 bits which can handle
khz as large as 4294 GHz.
Though this truncation results in losing TSC ticks when khz is larger
than 4.3 GHz, the lost is however pretty small compared with the large
khz.
Alternatively, it's also possible to follow David's comment to use
divq on x86_64 to keep both precision and safety. On i386, it just
falls back to above truncating approach.
- Haozhong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/15] pcnet32: use pci_set_dma_mask insted of pci_dma_supported
On Sat, 2015-10-03 at 17:19 +0200, Christoph Hellwig wrote:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/amd/pcnet32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Don Fry
> diff --git a/drivers/net/ethernet/amd/pcnet32.c
> b/drivers/net/ethernet/amd/pcnet32.c
> index bc8b04f..e2afabf 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1500,7 +1500,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return -ENODEV;
> }
>
> - if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) {
> + if (!pci_set_dma_mask(pdev, PCNET32_DMA_MASK)) {
> if (pcnet32_debug & NETIF_MSG_PROBE)
> pr_err("architecture does not support 32bit PCI
> busmaster DMA\n");
> return -ENODEV;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()
On 2015/09/22 15:23, Ingo Molnar wrote:
> So when memory hotplug removes a piece of physical memory from pagetable
> mappings, it also frees the underlying PGD entry.
>
> This complicates PGD management, so don't do this. We can keep the
> PGD mapped and the PUD table all clear - it's only a single 4K page
> per 512 GB of memory hotplugged.
>
> Cc: Andrew Morton
> Cc: Andy Lutomirski
> Cc: Borislav Petkov
> Cc: Brian Gerst
> Cc: Denys Vlasenko
> Cc: H. Peter Anvin
> Cc: Linus Torvalds
> Cc: Oleg Nesterov
> Cc: Peter Zijlstra
> Cc: Rik van Riel
> Cc: Thomas Gleixner
> Cc: Waiman Long
> Cc: linux...@kvack.org
> Signed-off-by: Ingo Molnar
Ishimatsu-san, Tang-san, please check.
Doesn't this patch affects the issues of
5255e0a79fcc0ff47b387af92bd9ef5729b1b859
9661d5bcd058fe15b4138a00d96bd36516134543
?
-Kame
> ---
> arch/x86/mm/init_64.c | 27 ---
> 1 file changed, 27 deletions(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 7129e7647a76..60b0cc3f2819 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -780,27 +780,6 @@ static void __meminit free_pmd_table(pmd_t *pmd_start,
> pud_t *pud)
> spin_unlock(&init_mm.page_table_lock);
> }
>
> -/* Return true if pgd is changed, otherwise return false. */
> -static bool __meminit free_pud_table(pud_t *pud_start, pgd_t *pgd)
> -{
> - pud_t *pud;
> - int i;
> -
> - for (i = 0; i < PTRS_PER_PUD; i++) {
> - pud = pud_start + i;
> - if (pud_val(*pud))
> - return false;
> - }
> -
> - /* free a pud table */
> - free_pagetable(pgd_page(*pgd), 0);
> - spin_lock(&init_mm.page_table_lock);
> - pgd_clear(pgd);
> - spin_unlock(&init_mm.page_table_lock);
> -
> - return true;
> -}
> -
> static void __meminit
> remove_pte_table(pte_t *pte_start, unsigned long addr, unsigned long end,
>bool direct)
> @@ -992,7 +971,6 @@ remove_pagetable(unsigned long start, unsigned long end,
> bool direct)
> unsigned long addr;
> pgd_t *pgd;
> pud_t *pud;
> - bool pgd_changed = false;
>
> for (addr = start; addr < end; addr = next) {
> next = pgd_addr_end(addr, end);
> @@ -1003,13 +981,8 @@ remove_pagetable(unsigned long start, unsigned long
> end, bool direct)
>
> pud = (pud_t *)pgd_page_vaddr(*pgd);
> remove_pud_table(pud, addr, next, direct);
> - if (free_pud_table(pud, pgd))
> - pgd_changed = true;
> }
>
> - if (pgd_changed)
> - sync_global_pgds(start, end - 1, 1);
> -
> flush_tlb_all();
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API
On Fri, 2015-10-02 at 13:11 -0700, Nishanth Aravamudan wrote:
> Drivers like NVMe need to be able to determine the page size used for
> DMA transfers. Add a new API that defaults to return PAGE_SHIFT on all
> architectures.
>
> Signed-off-by: Nishanth Aravamudan
>
> diff --git a/include/asm-generic/dma-mapping-common.h
> b/include/asm-generic/dma-mapping-common.h
> index b1bc954..86e4e97 100644
> --- a/include/asm-generic/dma-mapping-common.h
> +++ b/include/asm-generic/dma-mapping-common.h
> @@ -355,4 +355,11 @@ static inline int dma_set_mask(struct device *dev, u64
> mask)
> }
> #endif
>
> +#ifndef HAVE_ARCH_DMA_GET_PAGE_SHIFT
> +static inline unsigned long dma_get_page_shift(struct device *dev)
> +{
> + return PAGE_SHIFT;
> +}
> +#endif
> +
> #endif
>
Adding Arnd who is asm-generic maintainer.
Arnd/Christoph can one of you give us an ack for this patch?
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift
On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote: > Hi Nishanth, > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > ignore] > > config: powerpc-defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=powerpc > > All error/warnings (new ones prefixed by >>): > >arch/powerpc/platforms/pseries/iommu.c: In function > 'iommu_init_early_pSeries': > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct > >> machdep_calls' has no member named 'dma_get_page_shift' > ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP; It was added in patch 3/5, so I think this error is bogus. Unless there's a typo I'm missing? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing operand for tlbie instruction on Power7
On Fri, 2015-10-02 at 08:43 -0700, Laura Abbott wrote: > Hi, > > We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) of > bad assembly > when compiling on powerpc with little endian ... > After some discussion with the binutils folks, it turns out that the tlbie > instruction actually requires another operand and binutils was updated to > check for this https://sourceware.org/ml/binutils/2015-05/msg00133.html . > > The code sequence in arch/powerpc/include/asm/ppc_asm.h now needs to be > updated: > > #if !defined(CONFIG_4xx) && !defined(CONFIG_8xx) > #define tlbia \ > li r4,1024;\ > mtctr r4; \ > lis r4,KERNELBASE@h;\ > 0: tlbie r4; \ > addir4,r4,0x1000; \ > bdnz0b > #endif > > I don't know enough ppc assembly to properly fix this but I can test. How are you testing? This code is fairly old and I'm dubious if it still works. These days we have a ppc_md hook for flushing the TLB, ppc_md.flush_tlb(). Ideally the swsusp code would use that. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] ARM: mvebu: enable SDHCI card detection using DAT3 pin on A388-GP
On Tue, Oct 06, 2015 at 03:22:40AM +0200, Marcin Wojtas wrote: > The newest revisions of A388-GP (v1.5 and higher) support only > DAT3-based card detection, which is enabled by this commit. Hitherto > revisions, without such modification, will be impacted with a broken > card detection - in order to operate the cards have to be present > during kernel boot. Humm. Is this acceptable, breaking old boards? I would say at minimum, there should be a big fat comment at the top of armada-388-gp.dts explaining that this DTS file is broken on v0.0-v1.4. Or we have two .dts files for the 388-gp file, and a dtsi file. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] powerpc/iommu: expose IOMMU page shift
On Fri, Oct 02, 2015 at 10:18:00AM -0700, Nishanth Aravamudan wrote: > We will leverage this macro in the NVMe driver, which needs to know the > configured IOMMU page shift to properly configure its device's page > size. > > Signed-off-by: Nishanth Aravamudan > > --- > Given this is available, it seems reasonable to expose -- and it doesn't > really make sense to make the driver do a log2 call on the existing > IOMMU_PAGE_SIZE() value. > > diff --git a/arch/powerpc/include/asm/iommu.h > b/arch/powerpc/include/asm/iommu.h > index ca18cff..6fdf857 100644 > --- a/arch/powerpc/include/asm/iommu.h > +++ b/arch/powerpc/include/asm/iommu.h > @@ -36,6 +36,7 @@ > #define IOMMU_PAGE_MASK_4K (~((1 << IOMMU_PAGE_SHIFT_4K) - 1)) > #define IOMMU_PAGE_ALIGN_4K(addr) _ALIGN_UP(addr, IOMMU_PAGE_SIZE_4K) > > +#define IOMMU_PAGE_SHIFT(tblptr) (tblptr)->it_page_shift > #define IOMMU_PAGE_SIZE(tblptr) (ASM_CONST(1) << (tblptr)->it_page_shift) Seems like it would be a touch safer to alter IOMMU_PAGE_SIZE so it uses the new IOMMU_PAGE_SHIFT macro. > #define IOMMU_PAGE_MASK(tblptr) (~((1 << (tblptr)->it_page_shift) - 1)) > #define IOMMU_PAGE_ALIGN(addr, tblptr) _ALIGN_UP(addr, > IOMMU_PAGE_SIZE(tblptr)) > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
[PATCH] Staging: fbtft: Use BIT macro
Replace (1 << x) by BIT(x)
Signed-off-by: Ronit halder
---
drivers/staging/fbtft/fb_ssd1351.c | 4 +--
drivers/staging/fbtft/fbtft.h | 56 +++---
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ssd1351.c
b/drivers/staging/fbtft/fb_ssd1351.c
index eb45b27..28cc5d9 100644
--- a/drivers/staging/fbtft/fb_ssd1351.c
+++ b/drivers/staging/fbtft/fb_ssd1351.c
@@ -80,10 +80,10 @@ static int set_var(struct fbtft_par *par)
switch (par->info->var.rotate) {
case 0:
- write_reg(par, 0xA0, remap | 0x00 | 1<<4);
+ write_reg(par, 0xA0, remap | 0x00 | BIT(4));
break;
case 270:
- write_reg(par, 0xA0, remap | 0x03 | 1<<4);
+ write_reg(par, 0xA0, remap | 0x03 | BIT(4));
break;
case 180:
write_reg(par, 0xA0, remap | 0x02);
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h
index 6dd42b2..375af6b 100644
--- a/drivers/staging/fbtft/fbtft.h
+++ b/drivers/staging/fbtft/fbtft.h
@@ -374,39 +374,39 @@ module_exit(fbtft_driver_module_exit);
#define DEBUG_LEVEL_6 (DEBUG_LEVEL_4 | DEBUG_LEVEL_5)
#define DEBUG_LEVEL_7 0x
-#define DEBUG_DRIVER_INIT_FUNCTIONS (1<<3)
-#define DEBUG_TIME_FIRST_UPDATE (1<<4)
-#define DEBUG_TIME_EACH_UPDATE (1<<5)
-#define DEBUG_DEFERRED_IO (1<<6)
-#define DEBUG_FBTFT_INIT_FUNCTIONS (1<<7)
+#define DEBUG_DRIVER_INIT_FUNCTIONSBIT(3)
+#define DEBUG_TIME_FIRST_UPDATEBIT(4)
+#define DEBUG_TIME_EACH_UPDATE BIT(5)
+#define DEBUG_DEFERRED_IO BIT(6)
+#define DEBUG_FBTFT_INIT_FUNCTIONS BIT(7)
/* fbops */
-#define DEBUG_FB_READ (1<<8)
-#define DEBUG_FB_WRITE (1<<9)
-#define DEBUG_FB_FILLRECT (1<<10)
-#define DEBUG_FB_COPYAREA (1<<11)
-#define DEBUG_FB_IMAGEBLIT (1<<12)
-#define DEBUG_FB_SETCOLREG (1<<13)
-#define DEBUG_FB_BLANK (1<<14)
+#define DEBUG_FB_READ BIT(8)
+#define DEBUG_FB_WRITE BIT(9)
+#define DEBUG_FB_FILLRECT BIT(10)
+#define DEBUG_FB_COPYAREA BIT(11)
+#define DEBUG_FB_IMAGEBLIT BIT(12)
+#define DEBUG_FB_SETCOLREG BIT(13)
+#define DEBUG_FB_BLANK BIT(14)
-#define DEBUG_SYSFS (1<<16)
+#define DEBUG_SYSFS BIT(16)
/* fbtftops */
-#define DEBUG_BACKLIGHT (1<<17)
-#define DEBUG_READ (1<<18)
-#define DEBUG_WRITE (1<<19)
-#define DEBUG_WRITE_VMEM(1<<20)
-#define DEBUG_WRITE_REGISTER(1<<21)
-#define DEBUG_SET_ADDR_WIN (1<<22)
-#define DEBUG_RESET (1<<23)
-#define DEBUG_MKDIRTY (1<<24)
-#define DEBUG_UPDATE_DISPLAY(1<<25)
-#define DEBUG_INIT_DISPLAY (1<<26)
-#define DEBUG_BLANK (1<<27)
-#define DEBUG_REQUEST_GPIOS (1<<28)
-#define DEBUG_FREE_GPIOS(1<<29)
-#define DEBUG_REQUEST_GPIOS_MATCH (1<<30)
-#define DEBUG_VERIFY_GPIOS (1<<31)
+#define DEBUG_BACKLIGHT BIT(17)
+#define DEBUG_READ BIT(18)
+#define DEBUG_WRITE BIT(19)
+#define DEBUG_WRITE_VMEMBIT(20)
+#define DEBUG_WRITE_REGISTERBIT(21)
+#define DEBUG_SET_ADDR_WIN BIT(22)
+#define DEBUG_RESET BIT(23)
+#define DEBUG_MKDIRTY BIT(24)
+#define DEBUG_UPDATE_DISPLAYBIT(25)
+#define DEBUG_INIT_DISPLAY BIT(26)
+#define DEBUG_BLANK BIT(27)
+#define DEBUG_REQUEST_GPIOS BIT(28)
+#define DEBUG_FREE_GPIOSBIT(29)
+#define DEBUG_REQUEST_GPIOS_MATCH BIT(30)
+#define DEBUG_VERIFY_GPIOS BIT(31)
#define fbtft_init_dbg(dev, format, arg...) \
do { \
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon: Modify the id and name of external connector
Roger,
On 2015년 10월 05일 19:49, Roger Quadros wrote:
> Chanwoo,
>
> On 05/10/15 12:04, Chanwoo Choi wrote:
>> Hi Roger,
>>
>> On 2015년 10월 05일 18:01, Chanwoo Choi wrote:
>>> Hi Roger,
>>>
>>> On 2015년 10월 05일 17:26, Roger Quadros wrote:
Chanwoo,
On 04/10/15 06:45, Chanwoo Choi wrote:
> This patch modifies the id and name of external connector with the
> additional
> prefix to clarify both attribute and meaning of external connector as
> following:
> - EXTCON_CHG_* mean the charger connector.
> - EXTCON_JACK_* mean the jack connector.
> - EXTCON_DISP_* mean the display port connector.
>
> Following table show the new name of external connector with old name:
> -
> Old extcon name | New extcon name |
> -
> EXTCON_TA | EXTCON_CHG_USB_DCP|
> EXTCON_FAST_CHARGER | EXTCON_CHG_USB_FAST |
> EXTCON_SLOW_CHARGER | EXTCON_CHG_USB_SLOW |
> EXTCON_CHARGE_DOWNSTREAM| EXTCON_CHG_USB_CDP|
> -
> EXTCON_MICROPHONE | EXTCON_JACK_MICROPHONE|
> EXTCON_HEADPHONE| EXTCON_JACK_HEADPHONE |
> EXTCON_LINE_IN | EXTCON_JACK_LINE_IN |
> EXTCON_LINE_OUT | EXTCON_JACK_LINE_OUT |
> EXTCON_VIDEO_IN | EXTCON_JACK_VIDEO_IN |
> EXTCON_VIDEO_OUT| EXTCON_JACK_VIDEO_OUT |
> EXTCON_SPDIF_IN | EXTCON_JACK_SPDIF_IN |
> EXTCON_SPDIF_OUT| EXTCON_JACK_SPDIF_OUT |
> -
> EXTCON_HMDI | EXTCON_DISP_HDMI |
> EXTCON_MHL | EXTCON_DISP_MHL |
> EXTCON_DVI | EXTCON_DISP_DVI |
> EXTCON_VGA | EXTCON_DISP_VGA |
> -
>
> And, when altering the name of USB charger connector, EXTCON refers to the
> "USB battery charging specification"[1] to use the standard name of USB
> charging port as following. Following name of USB charging port are
> already used
> in power_supply subsystem. We chan check it on patch[2].
> - EXTCON_CHG_USB /* Standard Downstream Port */
> - EXTCON_CHG_USB_DCP /* Dedicated Charging Port */
> - EXTCON_CHG_USB_CDP /* Charging Downstream Port */
> - EXTCON_CHG_USB_ACA /* Accessory Charging Adapter */
>
> [1]
> http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf
> [2] commit 85efc8a18ce ("[PATCH] power_supply: Add types for USB
> chargers")
>
> Signed-off-by: Chanwoo Choi
> ---
> drivers/extcon/extcon-arizona.c | 18 ++--
> drivers/extcon/extcon-axp288.c | 12
> drivers/extcon/extcon-max14577.c | 18 ++--
> drivers/extcon/extcon-max77693.c | 32 +++--
> drivers/extcon/extcon-max77843.c | 27 ++
> drivers/extcon/extcon-max8997.c | 21 +++---
> drivers/extcon/extcon-rt8973a.c | 4 +--
> drivers/extcon/extcon-sm5502.c | 4 +--
> drivers/extcon/extcon.c | 60
> ---
> include/linux/extcon.h | 61
> +++-
> 10 files changed, 138 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 8dd0af1..505a028 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -39,37 +39,39 @@
> #define CABLE_NAME_MAX 30
>
> static const char *extcon_name[] = {
> - [EXTCON_NONE] = "NONE",
> + [EXTCON_NONE] = "EXTCON_NONE",
>
> /* USB external connector */
> - [EXTCON_USB]= "USB",
> - [EXTCON_USB_HOST] = "USB-HOST",
> -
> - /* Charger external connector */
> - [EXTCON_TA] = "TA",
> - [EXTCON_FAST_CHARGER] = "FAST-CHARGER",
> - [EXTCON_SLOW_CHARGER] = "SLOW-CHARGER",
> - [EXTCON_CHARGE_DOWNSTREAM] = "CHARGE-DOWNSTREAM",
> -
> - /* Audio/Video external connector */
> - [EXTCON_LINE_IN]= "LINE-IN",
> - [EXTCON_LINE_OUT] = "LINE-OUT",
> - [EXTCON_MICROPHONE] = "MICROPHONE",
> - [EXTCON_HEADPHONE] = "HEADPHONE",
> -
> - [EXTCON_HDMI] = "HDMI",
> - [EXTCON_MHL]= "MHL",
> - [EXTCON_DVI]= "DVI",
> - [EXTCON_VGA]= "VGA",
> - [EXTCON_SPDIF_IN] = "SPDIF-IN",
> - [EXTCON_SPDIF_OUT] = "SPDIF-OUT",
> - [EXTCON_VIDEO_IN] = "VIDEO-IN",
> - [EXTCON_VIDEO_OUT] = "VIDEO-OUT",
> -
> - /* Etc external connector */
> - [EXTCON_DOCK] = "DOCK",
> - [EXTCON_JIG]= "JIG",
> - [EXTCON_M
Re: Re: Re: [PATCH v2] arm: Adding support for atomic half word exchange
Hello Will,
Thank you so much for the review. I have thought it over and it makes
sense not to have that comment in cmpxchg.h, I will also change !defined to
#ifndef and quickly post a v3.
Regards,
Sarbojit
--- Original Message ---
Sender : Will Deacon
Date : Oct 05, 2015 21:30 (GMT+05:30)
Title : Re: Re: [PATCH v2] arm: Adding support for atomic half word exchange
On Mon, Oct 05, 2015 at 01:10:53PM +, Sarbojit Ganguly wrote:
> My sincere apologies for the format issue. This was due to the e-mail editor
> which reformats the text.
> I am reposting the patch, please let me know if it is ok this time.
>
>
> v1-->v2 : Extended the guard code to cover the byte exchange case as
> well following opinion of Will Deacon.
> Checkpatch has been run and issues were taken care of.
>
> Since support for half-word atomic exchange was not there and Qspinlock
> on ARM requires it, modified __xchg() to add support for that as well.
> ARMv6 and lower does not support ldrex{b,h} so, added a guard code
> to prevent build breaks.
>
> Signed-off-by: Sarbojit Ganguly
> ---
> arch/arm/include/asm/cmpxchg.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h
> index 916a274..a53cbeb 100644
> --- a/arch/arm/include/asm/cmpxchg.h
> +++ b/arch/arm/include/asm/cmpxchg.h
> @@ -39,6 +39,7 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void *ptr, int size
>
> switch (size) {
> #if __LINUX_ARM_ARCH__ >= 6
> +#if !defined(CONFIG_CPU_V6)
#ifndef ? (to match the __cmpxchg code).
> case 1:
> asm volatile("@ __xchg1\n"
> "1: ldrexb %0, [%3]\n"
> @@ -49,6 +50,22 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void *ptr, int size
> : "r" (x), "r" (ptr)
> : "memory", "cc");
> break;
> +
> + /*
> + * Half-word atomic exchange, required
> + * for Qspinlock support on ARM.
> + */
I think I said it before, but I don't think this comment is of any real
value.
Other than those, this looks ok to me.
Will
?
??? ?? ?? ??
--+
The Tao lies beyond Yin and Yang. It is silent and still as a pool of water.
|
It does not seek fame, therefore nobody knows its presence.
|
It does not seek fortune, for it is complete within itself.
|
It exists beyond space and time.
|
--+
linux-next: manual merge of the tip tree with the pm tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/kernel/acpi.c
between commit:
f26527b1428f ("irqchip / GIC: Convert the GIC driver to ACPI probing")
from the pm tree and commit:
89e44b51cc0d ("arm64, acpi/apei: Implement arch_apei_get_mem_attributes()")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/kernel/acpi.c
index d6463bba2360,137d537ddceb..
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@@ -205,3 -210,52 +210,27 @@@ void __init acpi_boot_table_init(void
disable_acpi();
}
}
+
-void __init acpi_gic_init(void)
-{
- struct acpi_table_header *table;
- acpi_status status;
- acpi_size tbl_size;
- int err;
-
- if (acpi_disabled)
- return;
-
- status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
- if (ACPI_FAILURE(status)) {
- const char *msg = acpi_format_exception(status);
-
- pr_err("Failed to get MADT table, %s\n", msg);
- return;
- }
-
- err = gic_v2_acpi_init(table);
- if (err)
- pr_err("Failed to initialize GIC IRQ controller");
-
- early_acpi_os_unmap_memory((char *)table, tbl_size);
-}
-
+ #ifdef CONFIG_ACPI_APEI
+ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+ {
+ /*
+* According to "Table 8 Map: EFI memory types to AArch64 memory
+* types" of UEFI 2.5 section 2.3.6.1, each EFI memory type is
+* mapped to a corresponding MAIR attribute encoding.
+* The EFI memory attribute advises all possible capabilities
+* of a memory region. We use the most efficient capability.
+*/
+
+ u64 attr;
+
+ attr = efi_mem_attributes(addr);
+ if (attr & EFI_MEMORY_WB)
+ return PAGE_KERNEL;
+ if (attr & EFI_MEMORY_WT)
+ return __pgprot(PROT_NORMAL_WT);
+ if (attr & EFI_MEMORY_WC)
+ return __pgprot(PROT_NORMAL_NC);
+ return __pgprot(PROT_DEVICE_nGnRnE);
+ }
+ #endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware
> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Tuesday, October 06, 2015 3:06 AM
>
> >> And what if cap_hdr isn't written yet?
> >
> > This design mainly targeting a simplest interface that user could
> > upload efi capsule in a single command action: cat capsule.bin >
> > /dev/efi_capsule_loader
> >
> > So, it is expected that efi capsule header is at the starting of the binary
> > file.
> > Already capture this into efi_capsule_write() comment in v7 patchset:
> > https://lkml.org/lkml/2015/10/5/232
> >
> > If you want to enhance this module to support creating efi capsule
> > header for your binary, strongly believe this design can cater the
> > implementation such as adding ioctl to pass in efi guid, flags and so on
> parameters to create the header.
> >
>
> No, that's not what I mean. What I mean is: what if cat writes too little in
> the
> first write call (e.g. 3 bytes).
Yes, I could add a condition checking for this:
if (write_byte < sizeof(efi_capsule_header_t) { ... }
to ensure the 1st block count does not less than the capsule header size.
If not, will return error.
Do you have any idea that in what kind of situation user app will pass in less
than
28 bytes each time?
>
> >
> >>
> >> > + if (ret) {
> >> > + pr_err("%s: efi_capsule_supported() failed\n",
> >> > + __func__);
> >> > + kunmap(kbuff_page);
> >> > + efi_free_all_buff_pages(kbuff_page);
> >> > + return ret;
> >> > + }
> >> > +
> >> > + cap_info.total_size = cap_hdr->imagesize;
> >> > + cap_info.pages = kmalloc_array(pages_needed, sizeof(void
> >> > *),
> >> > + GFP_KERNEL);
> >> > + if (!cap_info.pages) {
> >> > + pr_debug("%s: kmalloc_array() failed\n",
> >> > __func__);
> >> > + kunmap(kbuff_page);
> >> > + efi_free_all_buff_pages(kbuff_page);
> >> > + return -ENOMEM;
> >> > + }
> >> > +
> >> > + cap_info.header_obtained = 1;
> >>
> >> I don't see how you know that the header is obtained.
> >
> > Capsule header is at the starting block of image binary. We can obtain
> > the header through the 1st block of write action.
>
> That's quite an assumption to make.
Answered as above.
>
> >> > + cap_info.pages[cap_info.index++] = kbuff_page;
> >>
> >> Huh? You might now have allocated a whole page.
> >
> > Yes, the efi capsule header does tell the whole image size.
>
> So what? Did you allocate a page in this particular write call? If so, then
> cap_info.index++, etc is okay. If not, it's wrong.
Yes, the allocation is at:
cap_info.pages = kmalloc_array(pages_needed, sizeof(void *),
GFP_KERNEL);
before line:
cap_info.header_obtained = 1;
>
> >> > + }
> >> > + /* indicate capsule binary uploading is done */
> >> > + cap_info.index = -1;
> >>
> >> Should count > cap_info.total_size be an error?
> >>
> >> --Andy
> >
> > Yes, this is why after the write count already reaches the image size
> > stated in efi capsule header, an indicator will be flagged for
> > subsequence write to be returned -EIO as what Matt has commented.
>
> What if *this very same write* writes too much data?
>
I think it is still okay as the data is still within a page and this could
cater the image
binary that padding to page size. Whatever next write that more than the current
page, will return error -EIO.
If you think that should flag an error, I could simply add the condition
checking
to it.
Thanks & Regards,
Wilson
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH RT 4/4] work-simple: Add missing #include
work-simple.c uses EXPORT_SYMBOL_GPL(), defined in . Signed-off-by: Ben Hutchings Cc: stable...@vger.kernel.org --- kernel/work-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/work-simple.c b/kernel/work-simple.c index c996f75..e57a052 100644 --- a/kernel/work-simple.c +++ b/kernel/work-simple.c @@ -10,6 +10,7 @@ #include #include #include +#include #define SWORK_EVENT_PENDING (1 << 0) -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part
[PATCH RT 2/4] rtmutex: Fix rt_mutex_timed_fastlock() slowfn type mismatch up to 3.10
The type of the slowfn parameter is declared incorrectly in some of
the backports, resulting in:
kernel/rtmutex.c: In function 'rt_mutex_timed_futex_lock':
kernel/rtmutex.c:1730:12: warning: passing argument 5 of
'rt_mutex_timed_fastlock' from incompatible pointer type [enabled by default]
kernel/rtmutex.c:1655:1: note: expected 'int (*)(struct rt_mutex *, int,
struct hrtimer_sleeper *, int)' but argument is of type 'int (*)(struct
rt_mutex *, int, struct hrtimer_sleeper *, enum rtmutex_chainwalk)'
kernel/rtmutex.c: In function 'rt_mutex_timed_lock':
kernel/rtmutex.c:1770:12: warning: passing argument 5 of
'rt_mutex_timed_fastlock' from incompatible pointer type [enabled by default]
kernel/rtmutex.c:1655:1: note: expected 'int (*)(struct rt_mutex *, int,
struct hrtimer_sleeper *, int)' but argument is of type 'int (*)(struct
rt_mutex *, int, struct hrtimer_sleeper *, enum rtmutex_chainwalk)'
Signed-off-by: Ben Hutchings
Cc: # 3.2 3.4 3.10
---
kernel/rtmutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 52cab27..26550b6 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -1657,7 +1657,7 @@ rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
enum rtmutex_chainwalk chwalk,
int (*slowfn)(struct rt_mutex *lock, int state,
struct hrtimer_sleeper *timeout,
- int detect_deadlock))
+ enum rtmutex_chainwalk chwalk))
{
if (chwalk == RT_MUTEX_MIN_CHAINWALK &&
likely(rt_mutex_cmpxchg(lock, NULL, current))) {
--
Ben Hutchings
All the simple programs have been written, and all the good names taken.
signature.asc
Description: This is a digitally signed message part
[PATCH RT 3/4] genirq: Fix pointer cast warning for randomness on 32-bit architectures
gcc warns about casting directly from a 32-bit pointer to u64. In the current rt patch series we cast to unsigned long to avoid the warning, but this fix hasn't been backported to all versions. Signed-off-by: Ben Hutchings Cc: # 3.2 3.4 --- kernel/irq/manage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index e4549b2..964cf41 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -897,7 +897,8 @@ static int irq_thread(void *data) #ifdef CONFIG_PREEMPT_RT_FULL migrate_disable(); add_interrupt_randomness(action->irq, 0, -desc->random_ip ^ (u64) action); +desc->random_ip ^ +(unsigned long) action); migrate_enable(); #endif } -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part
[PATCH RT 1/4] KVM: lapic: Fix name of timer handler before 3.7
The timer handler was named kvm_timer_fn, not apic_timer_fn, before
Linux 3.7.
Signed-off-by: Ben Hutchings
Cc: # 3.2 3.4
---
arch/x86/kvm/lapic.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 7198be0..c661909 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -680,15 +680,13 @@ static void update_divide_count(struct kvm_lapic *apic)
}
-static enum hrtimer_restart apic_timer_fn(struct hrtimer *data);
-
static void apic_timer_expired(struct hrtimer *data)
{
int ret, i = 0;
enum hrtimer_restart r;
struct kvm_timer *ktimer = container_of(data, struct kvm_timer, timer);
- r = apic_timer_fn(data);
+ r = kvm_timer_fn(data);
if (r == HRTIMER_RESTART) {
do {
--
Ben Hutchings
All the simple programs have been written, and all the good names taken.
signature.asc
Description: This is a digitally signed message part
linux-next: manual merge of the audit tree with Linus' tree
Hi Paul,
Today's linux-next merge of the audit tree got a conflict in:
include/linux/lsm_audit.h
between commit:
671a2781ff01 ("security: add ioctl specific auditing to lsm_audit")
from Linus' tree and commit:
43cfd5e38587 ("audit: constify parts of common_audit_data and
lsm_network_audit")
from the audit tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/lsm_audit.h
index ffb9c9da4f39,6c4c7acd0e5e..
--- a/include/linux/lsm_audit.h
+++ b/include/linux/lsm_audit.h
@@@ -58,10 -53,9 +58,10 @@@ struct common_audit_data
#define LSM_AUDIT_DATA_KMOD 8
#define LSM_AUDIT_DATA_INODE 9
#define LSM_AUDIT_DATA_DENTRY 10
+#define LSM_AUDIT_DATA_IOCTL_OP 11
union {
struct path path;
- struct dentry *dentry;
+ const struct dentry *dentry;
struct inode *inode;
struct lsm_network_audit *net;
int cap;
@@@ -70,11 -64,10 +70,11 @@@
#ifdef CONFIG_KEYS
struct {
key_serial_t key;
- char *key_desc;
+ const char *key_desc;
} key_struct;
#endif
- char *kmod_name;
+ const char *kmod_name;
+ struct lsm_ioctlop_audit *op;
} u;
/* this union contains LSM specific data */
union {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 21/22] driver core: Start processing deferred probes earlier
On Mon, Oct 5, 2015 at 6:52 PM, Frank Rowand wrote:
> On 9/21/2015 7:03 AM, Tomeu Vizoso wrote:
>> Some initcalls in the late level assume that some devices will have
>> already probed without explicitly checking for that.
>>
>> After the recent move to defer most device probes when they are
>> registered, pressure increased in the late initcall level.
>>
>> By starting the processing of the deferred queue in device_initcall_sync
>> we increase the chances that the initcalls mentioned before will find
>> the devices they depend on to have already probed.
>>
>> Signed-off-by: Tomeu Vizoso
>> ---
>>
>> Changes in v4:
>> - Start processing deferred probes in device_initcall_sync
>>
>> drivers/base/dd.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 269ea76c1a4f..f0ef9233fcd6 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void)
>> *
>> * We don't want to get in the way when the bulk of drivers are getting
>> probed.
>> * Instead, this initcall makes sure that deferred probing is delayed until
>> - * late_initcall time.
>> + * device_initcall_sync time.
>
> This is a misuse of the *_sync initcall level.
>
> If a deferred probe created a thread and expected a wait at the
> following *_sync level then the wait would not occur because
> there is no subsequent *_sync level. This is not a problem today
> because (as far as I know) there are no threads in the probe
> functions. But there has been interest in adding parallel
> probing and that could expose this problem.
>
> The purpose of the *_sync initcall levels is to allow the corresponding
> initcall level to use multiple threads of execution instead of a single
> thread. The *_sync level provides a location for a wait for all of the
> threads at the corresponding init level to complete. This is better
> explained in the git log:
The things I was worried about like clk and regulator disabling are
actually late_initcall_sync, so maybe late_initcall is fine here after
all.
However, looking at other *_initcall_sync users, I'm not so sure they
are doing the same abuse.
Rob
>
> commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e
> Author: Andrew Morton
> Date: Fri Oct 27 11:42:37 2006 -0700
>
> [PATCH] drivers: wait for threaded probes between initcall levels
>
> The multithreaded-probing code has a problem: after one initcall level
> (eg,
> core_initcall) has been processed, we will then start processing the next
> level (postcore_initcall) while the kernel threads which are handling
> core_initcall are still executing. This breaks the guarantees which the
> layered initcalls previously gave us.
>
> IOW, we want to be multithreaded _within_ an initcall level, but not
> between
> different levels.
>
> Fix that up by causing the probing code to wait for all outstanding
> probes at
> one level to complete before we start processing the next level.
>
>> */
>> static int deferred_probe_initcall(void)
>> {
>> @@ -190,7 +190,7 @@ static int deferred_probe_initcall(void)
>> flush_workqueue(deferred_wq);
>> return 0;
>> }
>> -late_initcall(deferred_probe_initcall);
>> +device_initcall_sync(deferred_probe_initcall);
>>
>> static void driver_bound(struct device *dev)
>> {
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: CFS scheduler unfairly prefers pinned tasks
On Tue, 2015-10-06 at 08:48 +1100, paul.sz...@sydney.edu.au wrote:
> The Linux CFS scheduler prefers pinned tasks and unfairly
> gives more CPU time to tasks that have set CPU affinity.
> This effect is observed with or without CGROUP controls.
>
> To demonstrate: on an otherwise idle machine, as some user
> run several processes pinned to each CPU, one for each CPU
> (as many as CPUs present in the system) e.g. for a quad-core
> non-HyperThreaded machine:
>
> taskset -c 0 perl -e 'while(1){1}' &
> taskset -c 1 perl -e 'while(1){1}' &
> taskset -c 2 perl -e 'while(1){1}' &
> taskset -c 3 perl -e 'while(1){1}' &
>
> and (as that same or some other user) run some without
> pinning:
>
> perl -e 'while(1){1}' &
> perl -e 'while(1){1}' &
>
> and use e.g. top to observe that the pinned processes get
> more CPU time than "fair".
>
> Fairness is obtained when either:
> - there are as many un-pinned processes as CPUs; or
> - with CGROUP controls and the two kinds of processes run by
>different users, when there is just one un-pinned process; or
> - if the pinning is turned off for these processes (or they
>are started without).
>
> Any insight is welcome!
If they can all migrate, load balancing can move any of them to try to
fix the permanent imbalance, so they'll all bounce about sharing a CPU
with some other hog, and it all kinda sorta works out.
When most are pinned, to make it work out long term you'd have to be
short term unfair, walking the unpinned minority around the box in a
carefully orchestrated dance... and have omniscient powers that assure
that none of the tasks you're trying to equalize is gonna do something
rude like leave, sleep, fork or whatever, and muck up the grand plan.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RT 0/4] Warning fixes for PREEMPT_RT
These patches fix various warnings I got when building 3.2.71-rt104; some of them are applicable to other RT branches as well. Ben. Ben Hutchings (4): KVM: lapic: Fix name of timer handler before 3.7 rtmutex: Fix rt_mutex_timed_fastlock() slowfn type mismatch up to 3.10 genirq: Fix pointer cast warning for randomness on 32-bit architectures work-simple: Add missing #include arch/x86/kvm/lapic.c | 4 +--- kernel/irq/manage.c | 3 ++- kernel/rtmutex.c | 2 +- kernel/work-simple.c | 1 + 4 files changed, 5 insertions(+), 5 deletions(-) -- Ben Hutchings All the simple programs have been written, and all the good names taken. signature.asc Description: This is a digitally signed message part
Re: [RFC 1/7] arm64: pm/domains: try mutualize CPU domains init between arm/arm64
On Fri, Sep 25 2015 at 07:04 -0600, Marc Titinger wrote:
From: Marc Titinger
fake path to start testing, eventually move this out of /arch/.
incidently enable PM_GENERIC_DOMAINS for VExpress.
In fact, this could be moved out of ARM. My last series moved it to
drivers/base/power/.
-- Lina
Signed-off-by: Marc Titinger
---
arch/arm/common/domains.c | 4 ++--
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/arm-pd.h | 1 +
arch/arm64/kernel/Makefile | 6 ++
arch/arm64/kernel/domains.c | 1 +
5 files changed, 11 insertions(+), 2 deletions(-)
create mode 12 arch/arm64/include/asm/arm-pd.h
create mode 12 arch/arm64/kernel/domains.c
diff --git a/arch/arm/common/domains.c b/arch/arm/common/domains.c
index d3207da..68908d4 100644
--- a/arch/arm/common/domains.c
+++ b/arch/arm/common/domains.c
@@ -20,7 +20,7 @@
#include
-#define NAME_MAX 36
+#define GENPD_NAME_MAX 36
struct arm_pm_domain {
struct generic_pm_domain genpd;
@@ -182,7 +182,7 @@ static int __init arm_domain_init(void)
}
/* Initialize rest of CPU PM domain specifics */
- pd->genpd.name = kstrndup(np->name, NAME_MAX, GFP_KERNEL);
+ pd->genpd.name = kstrndup(np->name, GENPD_NAME_MAX, GFP_KERNEL);
pd->genpd.power_off = arm_pd_power_down;
pd->genpd.power_on = arm_pd_power_up;
pd->genpd.flags |= GENPD_FLAG_IRQ_SAFE;
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7c55a63..d35f213 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -250,6 +250,7 @@ config ARCH_VEXPRESS
select COMMON_CLK_VERSATILE
select POWER_RESET_VEXPRESS
select VEXPRESS_CONFIG
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for the ARMv8 software model (Versatile
Express).
diff --git a/arch/arm64/include/asm/arm-pd.h b/arch/arm64/include/asm/arm-pd.h
new file mode 12
index 000..ecc5437
--- /dev/null
+++ b/arch/arm64/include/asm/arm-pd.h
@@ -0,0 +1 @@
+../../../arm/include/asm/arm-pd.h
\ No newline at end of file
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 426d076..4689565 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -30,6 +30,12 @@ arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
arm64-obj-$(CONFIG_CPU_PM) += sleep.o suspend.o
arm64-obj-$(CONFIG_CPU_IDLE)+= cpuidle.o
+
+# CPU domains: try mutualize for arm/arm64 in a first step.
+# Eventually make this more generic.
+#
+arm64-obj-$(CONFIG_PM_GENERIC_DOMAINS) += domains.o
+
arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
arm64-obj-$(CONFIG_KGDB)+= kgdb.o
arm64-obj-$(CONFIG_EFI) += efi.o efi-stub.o efi-entry.o
diff --git a/arch/arm64/kernel/domains.c b/arch/arm64/kernel/domains.c
new file mode 12
index 000..bf17c69
--- /dev/null
+++ b/arch/arm64/kernel/domains.c
@@ -0,0 +1 @@
+../../arm/common/domains.c
\ No newline at end of file
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] sys_membarrier (x86, generic)
- On Oct 5, 2015, at 7:21 PM, Rusty Russell ru...@ozlabs.org wrote: > Mathieu Desnoyers writes: >> Hi Andrew, >> >> Here is a repost of sys_membarrier, rebased on top of Linus commit >> c4b5fd3fb2058b650447372472ad24e2a989f9f6 without any change since the >> last v19 post other that proceeding to further testing. When merging >> with other system calls, system call number conflicts should be quite >> straightforward to handle, there is nothing special there. > > Hi Mathieu, > >Great to see this go in! One small note: it talks about > threads, but membarrier as currently implemented would cover any shared > memory. If you plan to optimize in future, that might not be the case: > we'd want an address argument for those cases? Hi Rusty, Indeed, the current membarrier implementation only supports the MEMBARRIER_CMD_SHARED flag, which works even with shared memory across processes. If we ever want to optimize that for single-process, multi-threaded cases, we would have to add a new flag (e.g. MEMBARRIER_CMD_PRIVATE). This is quite similar to what already exists in the futex system call. I'm not sure I fully understand where the address argument you are describing would be useful. So far, I see two main use-cases: we either interact with memory that is local to a single process, or with memory shared across processes. We could indeed think about sending a membarrier to all processes using a specific shared memory area (hence the possible need for an address argument). This could eventually be supported by adding a specific flag for this (e.g. MEMBARRIER_CMD_SHM), which would indicate that an extra parameter is provided (an address). Thoughts ? Thanks for the feedback! Mathieu > > Cheers, > Rusty. -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: kernel BUG at mm/slub.c:1447!
On Mon, 5 Oct 2015 12:29:36 -0700 Andrew Morton
wrote:
> Maybe it would be better to add the gfp_t argument to the
> address_space_operations. At a minimum, writepage(), readpage(),
> writepages(), readpages(). What a pickle.
I'm being dumb. All we need to do is to add a new
address_space_operations.readpage_gfp(..., gfp_t gfp)
etc. That should be trivial. Each fs type only has 2-4 instances of
address_space_operations so the overhead is miniscule.
As a background janitorial thing we can migrate filesystems over to the
new interface then remove address_space_operations.readpage() etc. But
this *would* add overhead: more stack and more text for no gain. So
perhaps we just leave things as they are.
That's so simple that I expect we can short-term fix this bug with that
approach. umm, something like
--- a/fs/mpage.c~a
+++ a/fs/mpage.c
@@ -139,7 +139,8 @@ map_buffer_to_page(struct page *page, st
static struct bio *
do_mpage_readpage(struct bio *bio, struct page *page, unsigned nr_pages,
sector_t *last_block_in_bio, struct buffer_head *map_bh,
- unsigned long *first_logical_block, get_block_t get_block)
+ unsigned long *first_logical_block, get_block_t get_block,
+ gfp_t gfp)
{
struct inode *inode = page->mapping->host;
const unsigned blkbits = inode->i_blkbits;
@@ -278,7 +279,7 @@ alloc_new:
}
bio = mpage_alloc(bdev, blocks[0] << (blkbits - 9),
min_t(int, nr_pages, BIO_MAX_PAGES),
- GFP_KERNEL);
+ gfp);
if (bio == NULL)
goto confused;
}
@@ -310,7 +311,7 @@ confused:
}
/**
- * mpage_readpages - populate an address space with some pages & start reads
against them
+ * mpage_readpages_gfp - populate an address space with some pages & start
reads against them
* @mapping: the address_space
* @pages: The address of a list_head which contains the target pages. These
* pages have their ->index populated and are otherwise uninitialised.
@@ -318,6 +319,7 @@ confused:
* issued in @pages->prev to @pages->next order.
* @nr_pages: The number of pages at *@pages
* @get_block: The filesystem's block mapper function.
+ * @gfp: memory allocation constraints
*
* This function walks the pages and the blocks within each page, building and
* emitting large BIOs.
@@ -352,9 +354,8 @@ confused:
*
* This all causes the disk requests to be issued in the correct order.
*/
-int
-mpage_readpages(struct address_space *mapping, struct list_head *pages,
- unsigned nr_pages, get_block_t get_block)
+int mpage_readpages_gfp(struct address_space *mapping, struct list_head *pages,
+ unsigned nr_pages, get_block_t get_block, gfp_t gfp)
{
struct bio *bio = NULL;
unsigned page_idx;
@@ -370,12 +371,12 @@ mpage_readpages(struct address_space *ma
prefetchw(&page->flags);
list_del(&page->lru);
if (!add_to_page_cache_lru(page, mapping,
- page->index, GFP_KERNEL)) {
+ page->index, gfp)) {
bio = do_mpage_readpage(bio, page,
nr_pages - page_idx,
&last_block_in_bio, &map_bh,
&first_logical_block,
- get_block);
+ get_block, gfp);
}
page_cache_release(page);
}
@@ -384,6 +385,14 @@ mpage_readpages(struct address_space *ma
mpage_bio_submit(READ, bio);
return 0;
}
+EXPORT_SYMBOL(mpage_readpages_gfp);
+
+int mpage_readpages(struct address_space *mapping, struct list_head *pages,
+ unsigned nr_pages, get_block_t get_block)
+{
+ return mpage_readpages_gfp(mapping, pages, nr_pages, get_block,
+ GFP_KERNEL);
+}
EXPORT_SYMBOL(mpage_readpages);
/*
@@ -399,7 +408,7 @@ int mpage_readpage(struct page *page, ge
map_bh.b_state = 0;
map_bh.b_size = 0;
bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
- &map_bh, &first_logical_block, get_block);
+ &map_bh, &first_logical_block, get_block, GFP_KERNEL);
if (bio)
mpage_bio_submit(READ, bio);
return 0;
diff -puN include/linux/fs.h~a include/linux/fs.h
diff -puN include/linux/mpage.h~a include/linux/mpage.h
--- a/include/linux/mpage.h~a
+++ a/include/linux/mpage.h
@@ -15,6 +15,8 @@ struct writeback_control;
int mpage_readpages(struct address_space *mapping, struct list_head *pages,
unsigned nr_pages, get_block_t get_block);
+int mpage_readpages_gfp(struct ad
Re: [PATCH v4 0/2] RFC: Secure Memory Allocation Framework
On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
version 4 changes:
- rebased on kernel 4.3-rc3
- fix missing EXPORT_SYMBOL for smaf_create_handle()
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Overall I like the abstraction. Do you have a use case in mind right now for
the best allocation method? Some of the classic examples (mmu vs. no mmu)
are gradually becoming less relevant as the systems have evolved. I was
discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious about
your uses.
Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] modpost: Add flag -E for making section mismatches fatal
Nicolas Boichat writes: > The section mismatch warning can be easy to miss during the kernel build > process. Allow it to be marked as fatal to be easily caught and prevent > bugs from slipping in. > > Setting CONFIG_SECTION_MISMATCH_WARN_ONLY=y causes these warnings to be > non-fatal, since there are a number of section mismatches when using > allmodconfig on some architectures, and we do not want to break these > builds by default. > > Signed-off-by: Nicolas Boichat > > Change-Id: Ic346706e3297c9f0d790e3552aa94e5cff9897a6 Thanks, applied. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] sys_membarrier (x86, generic)
Mathieu Desnoyers writes: > Hi Andrew, > > Here is a repost of sys_membarrier, rebased on top of Linus commit > c4b5fd3fb2058b650447372472ad24e2a989f9f6 without any change since the > last v19 post other that proceeding to further testing. When merging > with other system calls, system call number conflicts should be quite > straightforward to handle, there is nothing special there. Hi Mathieu, Great to see this go in! One small note: it talks about threads, but membarrier as currently implemented would cover any shared memory. If you plan to optimize in future, that might not be the case: we'd want an address argument for those cases? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] create SMAF module
On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 000..37914e7
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,736 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smaf_handle {
+ struct dma_buf *dmabuf;
+ struct smaf_allocator *allocator;
+ struct dma_buf *db_alloc;
+ size_t length;
+ unsigned int flags;
+ int fd;
+ bool is_secure;
+ void *secure_ctx;
+};
+
+/**
+ * struct smaf_device - smaf device node private data
+ * @misc_dev: the misc device
+ * @head: list of allocator
+ * @lock: list and secure pointer mutex
+ * @secure:pointer to secure functions helpers
+ */
+struct smaf_device {
+ struct miscdevice misc_dev;
+ struct list_head head;
+ /* list and secure pointer lock*/
+ struct mutex lock;
+ struct smaf_secure *secure;
+};
+
+static struct smaf_device smaf_dev;
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+ if (!handle->is_secure)
+ return true;
+
+ if (!smaf_dev.secure)
+ return true;
+
+ if (!smaf_dev.secure->allow_cpu_access)
+ return true;
+
+ return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+}
+
+static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+dma_addr_t addr, size_t size,
+enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->grant_access)
+ return -EINVAL;
+
+ return smaf_dev.secure->grant_access(handle->secure_ctx,
+dev, addr, size, dir);
+}
+
+static void smaf_revoke_access(struct smaf_handle *handle, struct device *dev,
+ dma_addr_t addr, size_t size,
+ enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return;
+
+ if (!smaf_dev.secure)
+ return;
+
+ if (!smaf_dev.secure->revoke_access)
+ return;
+
+ smaf_dev.secure->revoke_access(handle->secure_ctx,
+ dev, addr, size, dir);
+}
+
+static int smaf_secure_handle(struct smaf_handle *handle)
+{
+ if (handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->create_context)
+ return -EINVAL;
+
+ handle->secure_ctx = smaf_dev.secure->create_context();
+
+ if (!handle->secure_ctx)
+ return -EINVAL;
+
+ handle->is_secure = true;
+ return 0;
+}
+
+static int smaf_unsecure_handle(struct smaf_handle *handle)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->destroy_context)
+ return -EINVAL;
+
+ if (smaf_dev.secure->destroy_context(handle->secure_ctx))
+ return -EINVAL;
+
+ handle->secure_ctx = NULL;
+ handle->is_secure = false;
+ return 0;
+}
All these functions need to be protected by a lock, otherwise the
secure state could change. For that matter, I think the smaf_handle
needs a lock to protect its state as well for places like map_dma_buf
+static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ switch (cmd) {
+ case SMAF_IOC_CREATE:
+ {
+ struct smaf_create_data data;
+ struct smaf_handle *handle;
+
+ if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
+ return -EFAULT;
+
+ handle = smaf_create_handle(data.length, data.flags);
+ if (!handle)
+ return -EINVAL;
+
+ if (data.name[0]) {
+ /* user force allocator selection */
+ if (smaf_select_allocator_by_name(handle->dmabuf,
+ data.name)) {
+ dma_buf_put(handle->dmabuf);
+ return -EINVAL;
+ }
+ }
+
+ handle->fd = dma_buf_fd(handle->dmabuf, data.flags);
+
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
On Fri, Sep 25, 2015 at 2:31 PM, James Liao wrote: > In kernel late init, it turns off all unused clocks, which > needs to access subsystem registers such as VENC and VENC_LT. > > Accessing MT8173 VENC registers needs two top clocks, mm_sel and > venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel. > So we need to keep these clocks on before accessing their registers. > > This patch keeps venc_sel / venclt_sel clock on when > VENC / VENC_LT's power is on, to prevent system hang up while > accessing its registeres. > > Signed-off-by: James Liao After the discussions with James here on the list, I'm happy with this fix. Compared to any proposed alternative, this patch seems just as effective and is also simpler and more maintainable and extensible (if other clocks/power domains need the same treatment). Reviewed-by: Daniel Kurtz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] block, dax: fix lifetime of in-kernel dax mappings
On Wed, Sep 30, 2015 at 4:35 PM, Dave Chinner wrote: > On Tue, Sep 29, 2015 at 08:41:36PM -0400, Dan Williams wrote: >> The DAX implementation needs to protect new calls to ->direct_access() >> and usage of its return value against unbind of the underlying block >> device. Use blk_queue_enter()/blk_queue_exit() to either prevent >> blk_cleanup_queue() from proceeding, or fail the dax_map_bh() if the >> request_queue is being torn down. >> >> Cc: Jens Axboe >> Cc: Christoph Hellwig >> Cc: Boaz Harrosh >> Cc: Dave Chinner >> Cc: Ross Zwisler >> Signed-off-by: Dan Williams >> --- >> block/blk.h|2 - >> fs/dax.c | 130 >> +++- >> include/linux/blkdev.h |2 + >> 3 files changed, 85 insertions(+), 49 deletions(-) >> >> diff --git a/block/blk.h b/block/blk.h >> index 5b2cd393afbe..0f8de0dda768 100644 >> --- a/block/blk.h >> +++ b/block/blk.h >> @@ -72,8 +72,6 @@ void blk_dequeue_request(struct request *rq); >> void __blk_queue_free_tags(struct request_queue *q); >> bool __blk_end_bidi_request(struct request *rq, int error, >> unsigned int nr_bytes, unsigned int bidi_bytes); >> -int blk_queue_enter(struct request_queue *q, gfp_t gfp); >> -void blk_queue_exit(struct request_queue *q); >> void blk_freeze_queue(struct request_queue *q); >> >> static inline void blk_queue_enter_live(struct request_queue *q) >> diff --git a/fs/dax.c b/fs/dax.c >> index bcfb14bfc1e4..7ce002bb60d0 100644 >> --- a/fs/dax.c >> +++ b/fs/dax.c >> @@ -63,12 +63,42 @@ int dax_clear_blocks(struct inode *inode, sector_t >> block, long size) >> } >> EXPORT_SYMBOL_GPL(dax_clear_blocks); >> >> -static long dax_get_addr(struct buffer_head *bh, void __pmem **addr, >> - unsigned blkbits) >> +static void __pmem *__dax_map_bh(const struct buffer_head *bh, unsigned >> blkbits, >> + unsigned long *pfn, long *len) > > Please don't use bufferheads for this. Please pass an inode, the > block and length to map, similar to dax_clear_blocks(). > > Why? Because dax_clear_blocks() needs to do this "mapping" too, > and it is called from contexts where there are no bufferheads. > There's a good chance we'll need more mapping contexts like this in > future, so lets not propagate bufferheads deeper into this code > than we absilutely need to. > > We should be trying to limit/remove bufferheads in the DAX code, not > propagating them deeper into the code... So I gave this a try but ran into the road block that get_block() is performing the inode to bdev conversion and that is filesystem specific. However, I'll at least not pass the bh into this map routine and will call it dax_map_atomic() which is more accurate. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: dts: Exynos improvements for 4.4-2
Dear Kukjin, This is an updated pull request with DTS related changes for 4.4. Description along with a tag. You can find them also on the lists with my reviewed-by. Best regards, Krzysztof The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-dt-4.4-2 for you to fetch changes up to c21dbcfefc9dc9abc42971dc1f2681b6a8677c3c: ARM: dts: Remove regulator-compatible usage in exynos4412-trats2 (2015-10-06 10:47:13 +0900) Device Tree improvements for Exynos based boards (updated pull request): 1. Enable DMA on Exynos4 serial ports. This old patch uncovered a number of other issues in dmaengine and samsung serial driver. All of known issues are resolved so finally enable the DMA for UART. 2. Fix incorrect location of display-timings node (FIMD->DP node) on Arndale, SMDK5250 and SMDK5240 boards. 3. Minor cleanups. Javier Martinez Canillas (1): ARM: dts: Remove regulator-compatible usage in exynos4412-trats2 Robert Baldyga (1): ARM: dts: Add DMA support for serial ports in exynos4 Sean Paul (1): ARM: dts: Move display-timings node from fimd to dp in exynos5250-arndale, smdk5250 and smdk5420 Tobias Jakobi (2): ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid ARM: dts: Unify voltage regulator style in exynos4412-odroid Vladimir Zapolskiy (1): ARM: dts: Fix cpu compatible value for s3c2416 arch/arm/boot/dts/exynos4.dtsi | 8 ++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 12 +-- arch/arm/boot/dts/exynos4412-trats2.dts | 105 arch/arm/boot/dts/exynos5250-arndale.dts| 8 +- arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 ++-- arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 +- arch/arm/boot/dts/s3c2416.dtsi | 2 +- 7 files changed, 62 insertions(+), 96 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/12] KVM: x86: Add a common TSC scaling ratio field in kvm_vcpu_arch
On Mon, Oct 05, 2015 at 09:26:30PM +0200, Radim Krčmář wrote: > 2015-09-28 13:38+0800, Haozhong Zhang: > > This patch moves the field of TSC scaling ratio from the architecture > > struct vcpu_svm to the common struct kvm_vcpu_arch. > > > > Signed-off-by: Haozhong Zhang > > --- > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > @@ -7080,6 +7080,9 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, > > > > vcpu = kvm_x86_ops->vcpu_create(kvm, id); > > > > + if (!IS_ERR(vcpu)) > > + vcpu->arch.tsc_scaling_ratio = kvm_default_tsc_scaling_ratio; > > This shouldn't be necessary, (and we can definitely do it without error > checking later) > > kvm_arch_vcpu_create >(vmx|svm)_create_vcpu > kvm_vcpu_init >kvm_arch_vcpu_init > kvm_set_tsc_khz > > sets vcpu->arch.tsc_scaling_ratio to something reasonable and SVM didn't > overwrite that value. (kvm_set_tsc_khz() only doesn't set the ration if > this_tsc_khz == 0, which we could extend to be extra safe.) Thanks Radim! I even didn't notice this path. I'll remove the ratio setting in kvm_arch_vcpu_create(). In kvm_set_tsc_khz(), if this_tsc_khz == 0, I'll make it set vcpu->arch.tsc_scaling_ratio to kvm_default_tsc_scaling_ratio. - Haozhong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the block tree
Hi Stephen, [auto build test ERROR on next-20151002 -- if it's inappropriate base, please ignore] config: i386-randconfig-x006-201540 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/block/loop.c: In function 'lo_rw_aio_complete': >> drivers/block/loop.c:473:2: error: too many arguments to function >> 'blk_mq_complete_request' blk_mq_complete_request(rq, ret); ^ In file included from drivers/block/loop.h:14:0, from drivers/block/loop.c:79: include/linux/blk-mq.h:218:6: note: declared here void blk_mq_complete_request(struct request *rq); ^ vim +/blk_mq_complete_request +473 drivers/block/loop.c 467 468 if (ret > 0) 469 ret = 0; 470 else if (ret < 0) 471 ret = -EIO; 472 > 473 blk_mq_complete_request(rq, ret); 474 } 475 476 static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd, --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [GIT PULL] arm64: dts: Exynos ARMv8 improvements for 4.4
On 06.10.2015 10:47, Kukjin Kim wrote: > Krzysztof Kozlowski wrote: >> >> Dear Kukjin, >> >> One ARMv8 DTS change for 4.4. >> >> Best regards, >> Krzysztof >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> are available in the git repository at: >> >> https://github.com/krzk/linux.git tags/samsung-dt64-4.4 >> >> for you to fetch changes up to 235c8e96f54a76bee201a7c86620c351a30b1ac6: >> >> arm64: dts: Add BUS1 instance pinctrl support for exynos7 (2015-09-16 >> 09:03:09 +0900) >> >> >> Device Tree improvements for Exynos ARMv8 based boards: >> 1. Add a BUS1 instance pinctrl for Exynos7 SoC. >> >> >> Alim Akhtar (1): >> arm64: dts: Add BUS1 instance pinctrl support for exynos7 >> >> arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 103 >> >> arch/arm64/boot/dts/exynos/exynos7.dtsi | 7 ++ >> 2 files changed, 110 insertions(+) > > Looks good to me. Since just one patch in this pull-request if you don't mind, > let me take the patch directly with your signed-off. Of course, thanks! Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] arm64: dts: Exynos ARMv8 improvements for 4.4
Krzysztof Kozlowski wrote: > > Dear Kukjin, > > One ARMv8 DTS change for 4.4. > > Best regards, > Krzysztof > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > https://github.com/krzk/linux.git tags/samsung-dt64-4.4 > > for you to fetch changes up to 235c8e96f54a76bee201a7c86620c351a30b1ac6: > > arm64: dts: Add BUS1 instance pinctrl support for exynos7 (2015-09-16 > 09:03:09 +0900) > > > Device Tree improvements for Exynos ARMv8 based boards: > 1. Add a BUS1 instance pinctrl for Exynos7 SoC. > > > Alim Akhtar (1): > arm64: dts: Add BUS1 instance pinctrl support for exynos7 > > arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 103 > > arch/arm64/boot/dts/exynos/exynos7.dtsi | 7 ++ > 2 files changed, 110 insertions(+) Looks good to me. Since just one patch in this pull-request if you don't mind, let me take the patch directly with your signed-off. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ARM: dts: Exynos improvements for 4.4
On 06.10.2015 10:42, Kukjin Kim wrote: > Krzysztof Kozlowski wrote: >> >> Dear Kukjin, >> > Hi, > >> DTS related changes for 4.4. >> >> Description along with a tag. >> You can find them also on the lists with my reviewed-by. >> > I have small comments. Then I could just pull your branch... > >> Best regards, >> Krzysztof >> >> >> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: >> >> Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) >> >> are available in the git repository at: >> >> https://github.com/krzk/linux.git tags/samsung-dt-4.4 >> >> for you to fetch changes up to 01dd011b7a0230a426a79475ae452298421a16e4: >> >> ARM: dts: exynos4412-trats2: remove regulator-compatible usage (2015-09-30 >> 09:03:03 +0900) >> >> >> Device Tree improvements for Exynos based boards: >> 1. Enable DMA on Exynos4 serial ports. This old patch uncovered >>a number of other issues in dmaengine and samsung serial driver. >>All of known issues are resolved so finally enable the DMA for UART. >> 2. Fix incorrect location of display-timings node (FIMD->DP node). >> 3. Minor cleanups. >> >> >> Javier Martinez Canillas (1): >> ARM: dts: exynos4412-trats2: remove regulator-compatible usage > > Can you please move the dt name at the end of subject like others? Ok > >> >> Robert Baldyga (1): >> ARM: dts: Add DMA support for serial ports in exynos4 >> >> Sean Paul (1): >> ARM: dts: Move display-timings node from fimd to dp on Exynos > > For all of exynos? If not, please specify the dt file in subject so that we > could realize what has been updated. Sure, I'll fix it and resend pull request. Best regards, Krzysztof > >> >> Tobias Jakobi (2): >> ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid >> ARM: dts: Unify voltage regulator style in exynos4412-odroid >> >> Vladimir Zapolskiy (1): >> ARM: dts: Fix cpu compatible value for s3c2416 >> >> arch/arm/boot/dts/exynos4.dtsi | 8 ++ >> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 12 +-- >> arch/arm/boot/dts/exynos4412-trats2.dts | 105 >> >> arch/arm/boot/dts/exynos5250-arndale.dts| 8 +- >> arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 ++-- >> arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 +- >> arch/arm/boot/dts/s3c2416.dtsi | 2 +- >> 7 files changed, 62 insertions(+), 96 deletions(-) > > - Kukjin > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the block tree
Hi Jens,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/block/loop.c: In function 'lo_rw_aio_complete':
drivers/block/loop.c:474:2: error: too few arguments to function
'blk_mq_complete_request'
blk_mq_complete_request(rq);
^
In file included from drivers/block/loop.h:14:0,
from drivers/block/loop.c:79:
include/linux/blk-mq.h:217:6: note: declared here
void blk_mq_complete_request(struct request *rq, int error);
^
Caused by commit
f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")
from Linus' tree interacting with commit
bc07c10a3603 ("block: loop: support DIO & AIO")
from the block tree.
I added the this merge fix patch:
From: Stephen Rothwell
Date: Tue, 6 Oct 2015 12:39:41 +1100
Subject: [PATCH] blk-mq: merge fix for "fix racy updates of rq->errors"
Signed-off-by: Stephen Rothwell
---
drivers/block/loop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index c692a3d812e4..9be61ad3163d 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -470,8 +470,7 @@ static void lo_rw_aio_complete(struct kiocb *iocb, long
ret, long ret2)
else if (ret < 0)
ret = -EIO;
- rq->errors = ret;
- blk_mq_complete_request(rq);
+ blk_mq_complete_request(rq, ret);
}
static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd,
--
2.5.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [GIT PULL] ARM: dts: Exynos improvements for 4.4
Krzysztof Kozlowski wrote: > > Dear Kukjin, > Hi, > DTS related changes for 4.4. > > Description along with a tag. > You can find them also on the lists with my reviewed-by. > I have small comments. Then I could just pull your branch... > Best regards, > Krzysztof > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > https://github.com/krzk/linux.git tags/samsung-dt-4.4 > > for you to fetch changes up to 01dd011b7a0230a426a79475ae452298421a16e4: > > ARM: dts: exynos4412-trats2: remove regulator-compatible usage (2015-09-30 > 09:03:03 +0900) > > > Device Tree improvements for Exynos based boards: > 1. Enable DMA on Exynos4 serial ports. This old patch uncovered >a number of other issues in dmaengine and samsung serial driver. >All of known issues are resolved so finally enable the DMA for UART. > 2. Fix incorrect location of display-timings node (FIMD->DP node). > 3. Minor cleanups. > > > Javier Martinez Canillas (1): > ARM: dts: exynos4412-trats2: remove regulator-compatible usage Can you please move the dt name at the end of subject like others? > > Robert Baldyga (1): > ARM: dts: Add DMA support for serial ports in exynos4 > > Sean Paul (1): > ARM: dts: Move display-timings node from fimd to dp on Exynos For all of exynos? If not, please specify the dt file in subject so that we could realize what has been updated. > > Tobias Jakobi (2): > ARM: dts: Remove redundant pinctrl settings in exynos4412-odroid > ARM: dts: Unify voltage regulator style in exynos4412-odroid > > Vladimir Zapolskiy (1): > ARM: dts: Fix cpu compatible value for s3c2416 > > arch/arm/boot/dts/exynos4.dtsi | 8 ++ > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 12 +-- > arch/arm/boot/dts/exynos4412-trats2.dts | 105 > > arch/arm/boot/dts/exynos5250-arndale.dts| 8 +- > arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 ++-- > arch/arm/boot/dts/exynos5420-smdk5420.dts | 7 +- > arch/arm/boot/dts/s3c2416.dtsi | 2 +- > 7 files changed, 62 insertions(+), 96 deletions(-) - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16
On Tue, Oct 6, 2015 at 4:59 AM, Felipe Balbi wrote: > Vaishali Thakkar writes: > >> On Mon, Aug 24, 2015 at 2:29 PM, David Laight >> wrote: >>> From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com] Sent: 22 August 2015 02:57 >>> ... >> - .bcdADC = __constant_cpu_to_le16(0x0100), >> - .wTotalLength = >> __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH), >> + .bcdADC = cpu_to_le16(0x0100), >> + .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH), > > Have you test compiled this on a big-endian system? > My gut feeling is that is fails. No. I have tested it on little-endian system only. But I'll be really surprised if this will fail. Can you please tell me if I am missing something in this particular case or same applies for other cases because most of the cases like __constant_ are already converted to ? As far as I know, if the argument is a constant the conversion happens at compile time. And unfolding both definitions returns to same expression. Still I am trying if someone can test it for me on big endian system. >>> >>> Flip one to cpu_to_be16() and see if it still compiles. >> >> Yes. It still compiles. > > it's unclear to me if this is really safe to apply. Until then I'm > dropping this from queue. Seems like, at a minimum, we need a better > commit log I compared both .s files [before the change and after the change] and I don't see any difference between instructions in them. I am not sure but it looks like if expression contains 'a ? t : f' then either 't' OR 'f' should be constant not both. Also, the code still complies on little endian machines after changing cpu_to_be16(). And on top of that fact is there are many patches applied in the kernel from years for the same and very less are remaining. In case, this fails then I think we need to change those cases as well. But I have never seen people reporting a bug for the same and changing to __constant_ again. Still I think probably it would be good if someone can test this patch on big endian machine [just to be sure about the change]. > -- > balbi -- Vaishali -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: fix platform_no_drv_owner.cocci warnings
drivers/input/touchscreen/ft6236.c:316:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Noralf Trønnes
Signed-off-by: Fengguang Wu
---
ft6236.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/input/touchscreen/ft6236.c
+++ b/drivers/input/touchscreen/ft6236.c
@@ -313,7 +313,6 @@ MODULE_DEVICE_TABLE(i2c, ft6236_id);
static struct i2c_driver ft6236_driver = {
.driver = {
.name = "ft6236",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(ft6236_of_match),
},
.probe = ft6236_probe,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/loop.c
between commit:
f4829a9b7a61 ("blk-mq: fix racy updates of rq->errors")
from Linus' tree and commit:
bc07c10a3603 ("block: loop: support DIO & AIO")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/block/loop.c
index 674f800a3b57,23376084a5cb..
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@@ -1486,47 -1669,25 +1669,26 @@@ static void loop_handle_cmd(struct loop
{
const bool write = cmd->rq->cmd_flags & REQ_WRITE;
struct loop_device *lo = cmd->rq->q->queuedata;
- int ret = -EIO;
+ int ret = 0;
- if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY))
+ if (write && (lo->lo_flags & LO_FLAGS_READ_ONLY)) {
+ ret = -EIO;
goto failed;
+ }
ret = do_req_filebacked(lo, cmd->rq);
-
failed:
- blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
+ if (ret)
+ cmd->rq->errors = -EIO;
+ /* complete non-aio request */
+ if (!cmd->use_aio || ret)
- blk_mq_complete_request(cmd->rq);
++ blk_mq_complete_request(cmd->rq, ret ? -EIO : 0);
}
- static void loop_queue_write_work(struct work_struct *work)
- {
- struct loop_device *lo =
- container_of(work, struct loop_device, write_work);
- LIST_HEAD(cmd_list);
-
- spin_lock_irq(&lo->lo_lock);
- repeat:
- list_splice_init(&lo->write_cmd_head, &cmd_list);
- spin_unlock_irq(&lo->lo_lock);
-
- while (!list_empty(&cmd_list)) {
- struct loop_cmd *cmd = list_first_entry(&cmd_list,
- struct loop_cmd, list);
- list_del_init(&cmd->list);
- loop_handle_cmd(cmd);
- }
-
- spin_lock_irq(&lo->lo_lock);
- if (!list_empty(&lo->write_cmd_head))
- goto repeat;
- lo->write_started = false;
- spin_unlock_irq(&lo->lo_lock);
- }
-
- static void loop_queue_read_work(struct work_struct *work)
+ static void loop_queue_work(struct kthread_work *work)
{
struct loop_cmd *cmd =
- container_of(work, struct loop_cmd, read_work);
+ container_of(work, struct loop_cmd, work);
loop_handle_cmd(cmd);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: reduce CONFIG_SCSI_CONSTANTS impact by 4k
Hi Rasmus,
On Sun, Oct 4, 2015 at 9:09 AM, Rasmus Villemoes
wrote:
> Subject: [PATCH 2/2] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
>
> On 64 bit, struct error_info has 6 bytes of padding, which amounts to
> over 4k of wasted space in the additional[] array. We could easily get
> rid of that by instead using separate arrays for the codes and the
> pointers. However, we can do even better than that and save an
> additional 6 bytes per entry: In the table, just store the sizeof()
> the corresponding string literal. The cumulative sum of these is then
> the appropriate offset into additional_text, which is built from the
> concatenation (with '\0's inbetween) of the strings.
>
> $ scripts/bloat-o-meter /tmp/vmlinux vmlinux
> add/remove: 0/0 grow/shrink: 1/1 up/down: 24/-8488 (-8464)
> function old new delta
> scsi_extd_sense_format 136 160 +24
> additional 113122824 -8488
Quick question:
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/scsi/constants.c | 25 +
> drivers/scsi/sense_codes.h | 2 --
> 2 files changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
> index 47aaccd5e68e..ccd34b0481cd 100644
> --- a/drivers/scsi/constants.c
> +++ b/drivers/scsi/constants.c
> @@ -292,17 +292,31 @@ bool scsi_opcode_sa_name(int opcode, int service_action,
>
> struct error_info {
> unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */
> - const char * text;
> + unsigned short size;
> };
>
>
> +/*
> + * There are 700+ entries in this table. To save space, we don't store
> + * (code, pointer) pairs, which would make sizeof(struct
> + * error_info)==16 on 64 bits. Rather, the second element just stores
> + * the size (including \0) of the corresponding string, and we use the
> + * sum of these to get the appropriate offset into additional_text
> + * defined below. This approach saves 12 bytes per entry.
> + */
> static const struct error_info additional[] =
> {
> -#define SENSE_CODE(c, s) {c, s},
> +#define SENSE_CODE(c, s) {c, sizeof(s)},
> #include "sense_codes.h"
> #undef SENSE_CODE
> };
>
> +static const char *additional_text =
> +#define SENSE_CODE(c, s) s "\0"
> +#include "sense_codes.h"
> +#undef SENSE_CODE
> + ;
> +
> struct error_info2 {
> unsigned char code1, code2_min, code2_max;
> const char * str;
> @@ -364,11 +378,14 @@ scsi_extd_sense_format(unsigned char asc, unsigned char
> ascq, const char **fmt)
> {
> int i;
> unsigned short code = ((asc << 8) | ascq);
> + unsigned offset = 0;
>
> *fmt = NULL;
> - for (i = 0; additional[i].text; i++)
> + for (i = 0; i < ARRAY_SIZE(additional); i++) {
> if (additional[i].code12 == code)
> - return additional[i].text;
> + return additional_text + offset;
> + offset += additional[i].size;
You don't seem to be accounting for the null bytes here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/41] Richacls
On Tue, Oct 06, 2015 at 12:01:19AM +0200, Andreas Gruenbacher wrote: > On Mon, Oct 5, 2015 at 11:17 PM, Dave Chinner wrote: > > On Mon, Oct 05, 2015 at 08:45:40PM +0200, Andreas Gruenbacher wrote: > >> On Sun, Oct 4, 2015 at 8:23 AM, Christoph Hellwig > >> wrote: > >> > After that the wire up should be so trivial that you can wire up btrfs, > >> > xfs and f2fs as well, which is important to make the feature mergeable. > >> > >> Why would the patch queue become more mergeable by having support for > >> more filesystems in it? The filesystem specific code really isn't all > >> that interesting. > > > > The hardest part for the filesystem support is the on-disk feature > > flag that needs to be set. The kernel part of that is easy, but it's > > an on-disk format change and so there's also all the userspace side > > for mkfs, fsck, debug tools, etc, that also need to be able to parse > > and understand it. So while the xattr code can be made much more > > generic, there's a bunch of filesystem specific code that needs to > > go into multiple different repositories and userspace packages for > > this. > > Yes. > > > Andreas, I also can't remember if any xfstests have been written for > > these ACLs? That would certainly help make sure all these > > filesystems have equivalent behaviour... > > There's a reasonable amount of tests in the richacl user-space package > which are shell based, with a few small C helpers. We could move those > into xfstests eventually; now seems a bit early to me. Well, all the fs developers that will do the userspace work are already running xfstests. If you want us to be able to test the richACL code as we add all the fs specific flags to the userspace code, then we need the tests in xfstests at the same time the infrastructure appears in the kernel... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8] mmc: sdhci-pxav3: disable clock inversion for HS MMC cards
From: Nadav Haklai
According to 'FE-2946959' erratum the clock inversion option is
needed to support slow frequencies when the card input hold time
requirement is high. This setting is not required for high speed
MMC and might cause timing violation.
Signed-off-by: Nadav Haklai
Cc: # v4.2
---
drivers/mmc/host/sdhci-pxav3.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 976cddd..89a9e49 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -291,6 +291,9 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
uhs == MMC_TIMING_UHS_DDR50) {
reg_val &= ~SDIO3_CONF_CLK_INV;
reg_val |= SDIO3_CONF_SD_FB_CLK;
+ } else if (uhs == MMC_TIMING_MMC_HS) {
+ reg_val &= ~SDIO3_CONF_CLK_INV;
+ reg_val &= ~SDIO3_CONF_SD_FB_CLK;
} else {
reg_val |= SDIO3_CONF_CLK_INV;
reg_val &= ~SDIO3_CONF_SD_FB_CLK;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/8] mmc: sdhci-pxav3: enable proper resuming on Armada 38x SoC
When resuming from suspend on Armada 38x SoC MBus windows have to be
re-configured and for that purpose mv_conf_mbus_windows function needed
rework. MBus windows register base address obtaining was moved to
armada_38x_quirks function in order to be kept in pxa global structure,
because it is used during a resume.
This commit fixes resuming from suspend by calling MBus windows
configuration routine and therefore enabling proper DMA operation.
Signed-off-by: Marcin Wojtas
---
drivers/mmc/host/sdhci-pxav3.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d..3f71894 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -63,6 +63,7 @@ struct sdhci_pxa {
struct clk *clk_io;
u8 power_mode;
void __iomem *sdio3_conf_reg;
+ void __iomem *mbus_win_regs;
};
/*
@@ -81,30 +82,16 @@ struct sdhci_pxa {
#define SDIO3_CONF_CLK_INV BIT(0)
#define SDIO3_CONF_SD_FB_CLK BIT(2)
-static int mv_conf_mbus_windows(struct platform_device *pdev,
+static int mv_conf_mbus_windows(struct device *dev, void __iomem *regs,
const struct mbus_dram_target_info *dram)
{
int i;
- void __iomem *regs;
- struct resource *res;
if (!dram) {
- dev_err(&pdev->dev, "no mbus dram info\n");
- return -EINVAL;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(&pdev->dev, "cannot get mbus registers\n");
+ dev_err(dev, "no mbus dram info\n");
return -EINVAL;
}
- regs = ioremap(res->start, resource_size(res));
- if (!regs) {
- dev_err(&pdev->dev, "cannot map mbus registers\n");
- return -ENOMEM;
- }
-
for (i = 0; i < SDHCI_MAX_WIN_NUM; i++) {
writel(0, regs + SDHCI_WINDOW_CTRL(i));
writel(0, regs + SDHCI_WINDOW_BASE(i));
@@ -122,8 +109,6 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
writel(cs->base, regs + SDHCI_WINDOW_BASE(i));
}
- iounmap(regs);
-
return 0;
}
@@ -135,6 +120,14 @@ static int armada_38x_quirks(struct platform_device *pdev,
struct sdhci_pxa *pxa = pltfm_host->priv;
struct resource *res;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mbus");
+ pxa->mbus_win_regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pxa->mbus_win_regs)) {
+ dev_err(mmc_dev(host->mmc),
+ "failed to obtain MBus windows register base\n");
+ return PTR_ERR(pxa->mbus_win_regs);
+ }
+
host->quirks &= ~SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN;
host->quirks |= SDHCI_QUIRK_MISSING_CAPS;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
@@ -403,7 +396,8 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
ret = armada_38x_quirks(pdev, host);
if (ret < 0)
goto err_mbus_win;
- ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
+ ret = mv_conf_mbus_windows(&pdev->dev, pxa->mbus_win_regs,
+ mv_mbus_dram_info());
if (ret < 0)
goto err_mbus_win;
}
@@ -520,6 +514,13 @@ static int sdhci_pxav3_resume(struct device *dev)
{
int ret;
struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host->priv;
+ struct device_node *np = dev->of_node;
+
+ if (of_device_is_compatible(np, "marvell,armada-380-sdhci"))
+ ret = mv_conf_mbus_windows(dev, pxa->mbus_win_regs,
+ mv_mbus_dram_info());
pm_runtime_get_sync(dev);
ret = sdhci_resume_host(host);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] mmc: sdhci-pxav3: fix error handling of armada_38x_quirks
In case of armada_38x_quirks error, all clocks should be cleaned-up, same
as after mv_conf_mbus_windows failure.
Signed-off-by: Marcin Wojtas
Cc: # v4.2
---
drivers/mmc/host/sdhci-pxav3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 89a9e49..f5edf9d 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -402,7 +402,7 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, "marvell,armada-380-sdhci")) {
ret = armada_38x_quirks(pdev, host);
if (ret < 0)
- goto err_clk_get;
+ goto err_mbus_win;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret < 0)
goto err_mbus_win;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH v2 5/5] ARM: sun5i: Add C.H.I.P DTS
Hi Maxime,
On Tue, Oct 6, 2015 at 1:23 AM, Maxime Ripard
wrote:
> The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
> RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
> and two connectors to plug additional boards on top of it.
Sorry for the late review, but a couple of minor things stuck out at me.
> Signed-off-by: Maxime Ripard
> Reviewed-by: Hans de Goede
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/sun5i-r8-chip.dts | 224
>
> 2 files changed, 226 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c7adaa85ef3f..2cf7e593270a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
> sun5i-a13-olinuxino.dtb \
> sun5i-a13-olinuxino-micro.dtb \
> sun5i-a13-q8-tablet.dtb \
> - sun5i-a13-utoo-p66.dtb
> + sun5i-a13-utoo-p66.dtb \
> + sun5i-r8-chip.dtb
> dtb-$(CONFIG_MACH_SUN6I) += \
> sun6i-a31-app4-evb1.dtb \
> sun6i-a31-colombus.dtb \
> diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
> b/arch/arm/boot/dts/sun5i-r8-chip.dts
> new file mode 100644
> index ..08ff70601c79
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
> @@ -0,1 +1,224 @@
> +/*
> + * Copyright 2015 Free Electrons
> + * Copyright 2015 NextThing Co
> + *
> + * Maxime Ripard
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun5i-a13.dtsi"
Am I missing something or should this include "sun5i-r8.dtsi" instead?
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "NextThing C.H.I.P.";
> + compatible = "nextthing,chip", "allwinner,sun5i-r8";
> +
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + serial0 = &uart1;
> + serial1 = &uart3;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
Should the composite output be enabled here too?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] ARM: mvebu: enable SDHCI card detection using DAT3 pin on A388-GP
The newest revisions of A388-GP (v1.5 and higher) support only
DAT3-based card detection, which is enabled by this commit. Hitherto
revisions, without such modification, will be impacted with a broken
card detection - in order to operate the cards have to be present
during kernel boot.
Signed-off-by: Marcin Wojtas
---
arch/arm/boot/dts/armada-388-gp.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-388-gp.dts
b/arch/arm/boot/dts/armada-388-gp.dts
index 391dea9..4855963 100644
--- a/arch/arm/boot/dts/armada-388-gp.dts
+++ b/arch/arm/boot/dts/armada-388-gp.dts
@@ -213,8 +213,9 @@
sdhci@d8000 {
pinctrl-names = "default";
pinctrl-0 = <&sdhci_pins>;
- cd-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
no-1-8-v;
+ dat3-cd;
+ cd-inverted;
wp-inverted;
bus-width = <8>;
status = "okay";
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/5] PCI: Add support for PCI Enhanced Allocation "BARs"
On 10/05/2015 04:05 PM, Sean O. Stalley wrote: On Fri, Oct 02, 2015 at 08:16:48PM -0700, Yinghai Lu wrote: On Fri, Oct 2, 2015 at 3:37 PM, David Daney wrote: From: David Daney PCI Enhanced Allocation is a new method of allocating MMIO & IO resources for PCI devices & bridges. It can be used instead of the traditional PCI method of using BARs. EA entries are hardware-initialized to a fixed address. Unlike BARs, regions described by EA are cannot be moved. Because of this, only devices which are permanently connected to the PCI bus can use EA. A removable PCI card must not use EA. The Enhanced Allocation ECN is publicly available here: https://www.pcisig.com/specifications/conventional/ECN_Enhanced_Allocation_23_Oct_2014_Final.pdf Looks like the EA will support more than just fixed address later. "Enhanced Allocation is an optional Conventional PCI Capability that may be implemented by Functions to indicate fixed (non reprogrammable) I/O and memory ranges assigned to the Function, as well as supporting new resource “type” definitions and future extensibility to also support reprogrammable allocations." so I would prefer to think more to make frame configurable to leave space for that. Bjorn, I wonder if we need to revive the add-on resource support patchset that i suggested couple years ago, so we can extend it to support EA features. URL: https://lkml.org/lkml/2012/3/19/86 Thanks Yinghai This might be useful for fixed resources as well. For some BEI values, EA allows for an arbitrary number of EA entries. I think this is true only for BEI = 6 which is for type-1 config space only (i.e. for bridges) I am thinking about splitting out the bridge part of the patch set, as my systems work fine without explicitly assigning bridge resources via EA. That would allow us to more forward with the patches that are less controversial, and spend more time hashing out the proper approach to take with bridges. For PF & VF resource ranges, it allows 2 ranges. I don't really understand what you are saying here. My reading of the spec. is that BEI[0..5] are PF BARs and each may have any of the properties that are allowed for normal BARs (io, memory-nonprefetchable, memory-prefetchable). BEI[9..14] are VF BARs, and likewise may have any of the properties that are alloed for normal VF bars (memory-nonprefetchable, memory-prefetchable) I guess in theory EA allows you to allocate 6 64-bit BARs, where you would be limited to only 3 64-bit normal BARs (one below the 4GB boundry, and one above). I don't think the current pci_dev struct can handle that many resources. -Sean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/8] mmc: sdhci: add init_card callback to sdhci
Some sdhci hosts may require handling quirks during card initialization at
the time when its type is already known. Hence a new callback (init_card)
is added in sdhci_ops.
Signed-off-by: Marcin Wojtas
---
drivers/mmc/host/sdhci.c | 9 +
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index cfed695..a1c308d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2200,6 +2200,14 @@ static void sdhci_card_event(struct mmc_host *mmc)
spin_unlock_irqrestore(&host->lock, flags);
}
+static void sdhci_init_card(struct mmc_host *mmc, struct mmc_card *card)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+
+ if (host->ops->init_card)
+ host->ops->init_card(host, card);
+}
+
static const struct mmc_host_ops sdhci_ops = {
.request= sdhci_request,
.post_req = sdhci_post_req,
@@ -2215,6 +2223,7 @@ static const struct mmc_host_ops sdhci_ops = {
.select_drive_strength = sdhci_select_drive_strength,
.card_event = sdhci_card_event,
.card_busy = sdhci_card_busy,
+ .init_card = sdhci_init_card,
};
/*\
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index c751b78..365c860 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -547,6 +547,7 @@ struct sdhci_ops {
struct mmc_card *card,
unsigned int max_dtr, int host_drv,
int card_drv, int *drv_type);
+ void(*init_card)(struct sdhci_host *host, struct mmc_card *card);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] mmc: sdhci-pxav3: enable modifying MMC_CARD bit during card initialization
On Marvell Armada 38x SoC's the MMC_CARD bit in SD_CE_ATA_1 register must
be set to 0x1 when a MMC card is supposed to work in DDR mode, or when
commands CMD11, CMD14 and CMD20 are used.
This commit enables the above for all MMC cards by modifying the host
registers during card initialization. It is done by using init_card()
callback.
Signed-off-by: Marcin Wojtas
---
drivers/mmc/host/sdhci-pxav3.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index ce96640..315dc4e 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,7 @@
#define SD_SPI_MODE 0x108
#define SD_CE_ATA_1 0x10C
+#define SDCE_MMC_CARD BIT(28)
#define SD_CE_ATA_2 0x10E
#define SDCE_MISC_INT (1<<2)
@@ -221,6 +222,22 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
}
}
+static void pxav3_init_card(struct sdhci_host *host, struct mmc_card *card)
+{
+ struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
+ struct device_node *np = pdev->dev.of_node;
+ u32 reg_val;
+
+ if (of_device_is_compatible(np, "marvell,armada-380-sdhci")) {
+ reg_val = sdhci_readl(host, SD_CE_ATA_1);
+ if (mmc_card_mmc(card))
+ reg_val |= SDCE_MMC_CARD;
+ else
+ reg_val &= ~SDCE_MMC_CARD;
+ sdhci_writel(host, reg_val, SD_CE_ATA_1);
+ }
+}
+
#define MAX_WAIT_COUNT 5
static void pxav3_gen_init_74_clocks(struct sdhci_host *host, u8 power_mode)
{
@@ -338,6 +355,7 @@ static const struct sdhci_ops pxav3_sdhci_ops = {
.set_bus_width = sdhci_set_bus_width,
.reset = pxav3_reset,
.set_uhs_signaling = pxav3_set_uhs_signaling,
+ .init_card = pxav3_init_card,
};
static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4] kselftest: timers: Add adjtick test to validate adjtimex() tick adjustments
Recently an issue was reported that was difficult to detect except
by tweaking the adjtimex tick value, and noticing how quickly the
adjustment took to be made:
https://lkml.org/lkml/2015/9/1/488
Thus this patch introduces a new test which manipulates the adjtimex
tick value and validates the results are what we expect.
Cc: Nuno Gonçalves
Cc: Miroslav Lichvar
Cc: Prarit Bhargava
Cc: Richard Cochran
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Shuah Khan
Signed-off-by: John Stultz
---
v2: - Use sysconf(_SC_CLK_TCK) to properly get USER_HZ value.
v3: - Set STA_PLL to ensure offset is cleared
- Add rational for 100ppm error bound
v4: - Add message informing each iteration takes ~15 secs
- Cleanup error message when ntpd is suspected of running
tools/testing/selftests/timers/Makefile | 3 +-
tools/testing/selftests/timers/adjtick.c | 210 +++
2 files changed, 212 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/timers/adjtick.c
diff --git a/tools/testing/selftests/timers/Makefile
b/tools/testing/selftests/timers/Makefile
index 89a3f44..4a1be1b 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -8,7 +8,7 @@ LDFLAGS += -lrt -lpthread
TEST_PROGS = posix_timers nanosleep nsleep-lat set-timer-lat mqueue-lat \
inconsistency-check raw_skew threadtest rtctest
-TEST_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex change_skew \
+TEST_PROGS_EXTENDED = alarmtimer-suspend valid-adjtimex adjtick change_skew \
skew_consistency clocksource-switch leap-a-day \
leapcrash set-tai set-2038
@@ -24,6 +24,7 @@ include ../lib.mk
run_destructive_tests: run_tests
./alarmtimer-suspend
./valid-adjtimex
+ ./adjtick
./change_skew
./skew_consistency
./clocksource-switch
diff --git a/tools/testing/selftests/timers/adjtick.c
b/tools/testing/selftests/timers/adjtick.c
new file mode 100644
index 000..253f684
--- /dev/null
+++ b/tools/testing/selftests/timers/adjtick.c
@@ -0,0 +1,210 @@
+/* adjtimex() tick adjustment test
+ * by: John Stultz
+ * (C) Copyright Linaro Limited 2015
+ * Licensed under the GPLv2
+ *
+ * To build:
+ * $ gcc adjtick.c -o adjtick -lrt
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef KTEST
+#include "../kselftest.h"
+#else
+static inline int ksft_exit_pass(void)
+{
+ exit(0);
+}
+static inline int ksft_exit_fail(void)
+{
+ exit(1);
+}
+#endif
+
+
+#define CLOCK_MONOTONIC_RAW4
+#define NSEC_PER_SEC 10LL
+#define USEC_PER_SEC 100
+#define MILLION 100
+
+long systick;
+
+long long llabs(long long val)
+{
+ if (val < 0)
+ val = -val;
+ return val;
+}
+
+unsigned long long ts_to_nsec(struct timespec ts)
+{
+ return ts.tv_sec * NSEC_PER_SEC + ts.tv_nsec;
+}
+
+struct timespec nsec_to_ts(long long ns)
+{
+ struct timespec ts;
+
+ ts.tv_sec = ns/NSEC_PER_SEC;
+ ts.tv_nsec = ns%NSEC_PER_SEC;
+ return ts;
+}
+
+long long diff_timespec(struct timespec start, struct timespec end)
+{
+ long long start_ns, end_ns;
+
+ start_ns = ts_to_nsec(start);
+ end_ns = ts_to_nsec(end);
+ return end_ns - start_ns;
+}
+
+void get_monotonic_and_raw(struct timespec *mon, struct timespec *raw)
+{
+ struct timespec start, mid, end;
+ long long diff = 0, tmp;
+ int i;
+
+ clock_gettime(CLOCK_MONOTONIC, mon);
+ clock_gettime(CLOCK_MONOTONIC_RAW, raw);
+
+ /* Try to get a more tightly bound pairing */
+ for (i = 0; i < 3; i++) {
+ long long newdiff;
+
+ clock_gettime(CLOCK_MONOTONIC, &start);
+ clock_gettime(CLOCK_MONOTONIC_RAW, &mid);
+ clock_gettime(CLOCK_MONOTONIC, &end);
+
+ newdiff = diff_timespec(start, end);
+ if (diff == 0 || newdiff < diff) {
+ diff = newdiff;
+ *raw = mid;
+ tmp = (ts_to_nsec(start) + ts_to_nsec(end))/2;
+ *mon = nsec_to_ts(tmp);
+ }
+ }
+}
+
+long long get_ppm_drift(void)
+{
+ struct timespec mon_start, raw_start, mon_end, raw_end;
+ long long delta1, delta2, eppm;
+
+ get_monotonic_and_raw(&mon_start, &raw_start);
+
+
[PATCH 5/8] mmc: sdhci-pxav3: enable usage of DAT3 pin as HW card detect
Marvell Armada 38x SDHCI controller enable using DAT3 pin as a hardware
card detection. According to the SD sdandard this signal can be used for
this purpose combined with a pull-up resistor, implying inverted (active
low) polarization of a card detect. MMC standard does not support this
feature and does not operate with such connectivity of DAT3.
When using DAT3-based detection Armada 38x SDIO IP expects its internal
clock to be always on, which had to be ensured twofold:
- Each time controller is reset by updating appropriate registers. On the
occasion of adding new register @0x104, register @0x100 name is modified
in order to the be aligned with Armada 38x documentation.
- Leaving the clock enabled despite power-down. For this purpose a new
quirk had to be added to SDHCI subsystem - SDHCI_QUIRK2_KEEP_INT_CLK_ON.
In addition to the changes above this commit adds a new property to Armada
38x SDHCI node ('dat3-cd') with an according binding documentation update.
Signed-off-by: Marcin Wojtas
---
.../devicetree/bindings/mmc/sdhci-pxa.txt | 5 +++
drivers/mmc/host/sdhci-pxav3.c | 38 --
drivers/mmc/host/sdhci.c | 5 ++-
drivers/mmc/host/sdhci.h | 3 ++
4 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..ffd6b14 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -23,6 +23,11 @@ Required properties:
Optional properties:
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
+- dat3-cd: use DAT3 pin as hardware card detect - option available for
+ "marvell,armada-380-sdhci" only. The detection is supposed to work with
+ active high polarity, which implies usage of "cd-inverted" property.
+ Note that according to the specifications DAT3-based card detection can be
+ used with SD cards only. MMC standard doesn't support this feature.
Example:
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 3f71894..ce96640 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -46,10 +46,14 @@
#define SDCLK_DELAY_SHIFT 9
#define SDCLK_DELAY_MASK 0x1f
-#define SD_CFG_FIFO_PARAM 0x100
+#define SD_EXTRA_PARAM_REG 0x100
#define SDCFG_GEN_PAD_CLK_ON (1<<6)
#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_FIFO_PARAM_REG 0x104
+#define SD_USE_DAT3BIT(7)
+#define SD_OVRRD_CLK_OEN BIT(11)
+#define SD_FORCE_CLK_ONBIT(12)
#define SD_SPI_MODE 0x108
#define SD_CE_ATA_1 0x10C
@@ -163,6 +167,15 @@ static int armada_38x_quirks(struct platform_device *pdev,
}
host->caps1 &= ~(SDHCI_SUPPORT_SDR104 | SDHCI_USE_SDR50_TUNING);
+ /*
+* The interface clock enable is also used as control
+* for the A38x SDIO IP, so it can't be powered down
+* when using HW-based card detection.
+*/
+ if (of_property_read_bool(np, "dat3-cd") &&
+ !of_property_read_bool(np, "broken-cd"))
+ host->quirks2 |= SDHCI_QUIRK2_KEEP_INT_CLK_ON;
+
return 0;
}
@@ -170,6 +183,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ u32 reg_val;
sdhci_reset(host, mask);
@@ -187,6 +202,22 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
tmp |= SDCLK_SEL;
writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
}
+
+ if (of_device_is_compatible(np, "marvell,armada-380-sdhci") &&
+ host->quirks2 & SDHCI_QUIRK2_KEEP_INT_CLK_ON) {
+ reg_val = sdhci_readl(host, SD_FIFO_PARAM_REG);
+ reg_val |= SD_USE_DAT3 | SD_OVRRD_CLK_OEN |
+ SD_FORCE_CLK_ON;
+ sdhci_writel(host, reg_val, SD_FIFO_PARAM_REG);
+
+ /*
+* For HW detection based on DAT3 pin keep internal
+* clk switched on after controller reset.
+*/
+ reg_val = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
+ reg_val |= SDHCI_CLOCK_INT_EN;
+ sdhci_writel(host, reg_val, SDHCI_CLOCK_CONTROL);
+ }
}
}
@@ -214,9 +245,9 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host
*host, u8 power_mode)
writew(tmp, host->ioaddr + SD_CE_ATA_2);
/* start sending the 74 clocks */
[PATCH 0/8] Armada 38x SDHCI driver improvements
Hi, This series brings a couple of fixes and improvements to Armada 38x SDHCI controller driver. First four patches are fixes, of which three are stable CC'ed. Another two add DAT3-pin based hardware card detection in the driver, what should be used by the newest revisions of A388-GP boards. The last patches enable MMC_CARD bit, using init_card() callback added to SDHCI hosts. Any remarks and comments are welcome. Best regards, Marcin Marcin Wojtas (6): mmc: sdhci-pxav3: fix error handling of armada_38x_quirks mmc: sdhci-pxav3: enable proper resuming on Armada 38x SoC mmc: sdhci-pxav3: enable usage of DAT3 pin as HW card detect ARM: mvebu: enable SDHCI card detection using DAT3 pin on A388-GP mmc: sdhci: add init_card callback to sdhci mmc: sdhci-pxav3: enable modifying MMC_CARD bit during card initialization Nadav Haklai (2): mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driver mmc: sdhci-pxav3: disable clock inversion for HS MMC cards .../devicetree/bindings/mmc/sdhci-pxa.txt | 5 + arch/arm/boot/dts/armada-388-gp.dts| 3 +- drivers/mmc/host/sdhci-pxav3.c | 101 - drivers/mmc/host/sdhci.c | 14 ++- drivers/mmc/host/sdhci.h | 4 + 5 files changed, 102 insertions(+), 25 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] mmc: sdhci-pxav3: remove broken clock base quirk for Armada 38x sdhci driver
From: Nadav Haklai shci-pxav3 driver is enabling by default the SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN quirk. However this quirk is not required for Armada 38x and leads to wrong clock setting in the divider. Signed-off-by: Nadav Haklai Signed-off-by: Marcin Wojtas Cc: # v4.2 --- drivers/mmc/host/sdhci-pxav3.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c index 946d37f..976cddd 100644 --- a/drivers/mmc/host/sdhci-pxav3.c +++ b/drivers/mmc/host/sdhci-pxav3.c @@ -135,6 +135,7 @@ static int armada_38x_quirks(struct platform_device *pdev, struct sdhci_pxa *pxa = pltfm_host->priv; struct resource *res; + host->quirks &= ~SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN; host->quirks |= SDHCI_QUIRK_MISSING_CAPS; res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "conf-sdio3"); -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the drm tree
Hi Dave,
After merging the drm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/drm_fb_helper.c: In function 'restore_fbdev_mode':
drivers/gpu/drm/drm_fb_helper.c:448:5: error: 'error' undeclared (first use in
this function)
error = true;
^
Caused by commit
03f9abb28c3e ("drm: handle cursor_set2 in restore_fbdev_mode")
>From Linus' tree interacting with commit
b7bdf0a87add ("drm/fb-helper: Use -errno return in restore_mode_unlocked")
from the drm tree.
I added the following merge fix patch:
From: Stephen Rothwell
Date: Tue, 6 Oct 2015 12:04:49 +1100
Subject: [PATCH] drm/fb-helper: merge fix for "Use -errno return in
restore_mode_unlocked"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 97d1a4633c5c..bd6d4ab27512 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -445,7 +445,7 @@ static int restore_fbdev_mode(struct drm_fb_helper
*fb_helper)
if (crtc->funcs->cursor_set2) {
ret = crtc->funcs->cursor_set2(crtc, NULL, 0, 0, 0, 0,
0);
if (ret)
- error = true;
+ return ret;
} else if (crtc->funcs->cursor_set) {
ret = crtc->funcs->cursor_set(crtc, NULL, 0, 0, 0);
if (ret)
--
2.5.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 00/36] x86: Rewrite all syscall entries except native 64-bit
The first two patches are optimizations that I'm surprised we didn't already have. I noticed them when I was looking at the generated asm. The next two patches are tests and some old stuff. There's a test that validates the vDSO AT_SYSINFO annotations. There's also a test that exercises some assumptions that signal handling and ptracers make about syscalls that currently do *not* hold on 64-bit AMD using 32-bit AT_SYSINFO. The next three patches are NT cleanups and a lockdep cleanup. It may pay to apply the beginning of the series (at most through "x86/entry/64/compat: After SYSENTER, move STI after the NT fixup") without waiting for everyone to wrap their heads around the rest. The rest is basically a rewrite of syscalls for all cases except 64-bit native. With these patches applied, there is a single 32-bit vDSO and it uses SYSCALL, SYSENTER, and INT80 almost interchangeably via alternatives. The semantics of SYSENTER and SYSCALL are defined as: 1. If SYSCALL, ESP = ECX 2. ECX = *ESP 3. IP = INT80 landing pad 4. Opportunistic SYSRET/SYSEXIT is enabled on return The vDSO is rearranged so that these semantics work. Anything that backs IP up by 2 ends up pointing at a bona fide int $0x80 instruction with the expected regs. In the process, the vDSO CFI annotations (which are actually used) get rewritten using normal CFI directives. Opportunistic SYSRET/SYSEXIT only happens on return when CS and SS are as expected, IP points to the INT80 landing pad, and flags are in good shape. (There is no longer any assumption that full fast-path 32-bit syscalls don't muck with the registers that matter for fast exits -- I played with maintaining an optimization like that with poor results. I may try again if it saves a few cycles.) Other than that, the system call entries are simplified to the bare minimum prologue and a call to a C function. Amusingly, SYSENTER and SYSCALL32 use the same C function. To make that work, I had to remove all the 32-bit syscall stubs except the clone argument hack. This is because, for C code to call through the system call table, the system call table entries need to be real function pointers with C-compatible ABIs. There is nothing at all anymore that requires that x86_32 syscalls be asmlinkage. That could be removed in a subsequent patch. The upshot appears to be a ~16 cycle performance hit on 32-bit fast path syscalls. (On my system, my little prctl test takes 172 cycles before and 188 cycles with these patches applied.) The slow path is probably faster under most circumstances and, if the exit slow path gets hit, it'll be much faster because (as we already do in the 64-bit native case) we can still use SYSEXIT/SYSRET. The patchset is structured as a removal of the old fast syscall code, then the change that makes syscalls into real functions, then a clean re-implementation of fast syscalls. If we want some of the 25 cycles back, we could consider open-coding a new C fast path. Changes from v1: - The unwind_vdso_32 test now warns on broken Debian installations instead of failing. The problem is now fully understood, will be fixed by Debian and possibly also fixed by upstream glibc. - execve was rather broken in v1. - It's quite a bit faster now (the optimizations at the end are mostly new). - int80 on 64-bit no longer clobbers extra regs (thanks Denys!). - The uaccess stuff is new. - Lots of other things that I forgot, I'm sure. Andy Lutomirski (36): x86/uaccess: Tell the compiler that uaccess is unlikely to fault x86/uaccess: __chk_range_not_ok is unlikely to return true selftests/x86: Add a test for vDSO unwinding selftests/x86: Add a test for syscall restart and arg modification x86/entry/64/compat: Fix SYSENTER's NT flag before user memory access x86/entry: Move lockdep_sys_exit to prepare_exit_to_usermode x86/entry/64/compat: After SYSENTER, move STI after the NT fixup x86/vdso: Remove runtime 32-bit vDSO selection x86/asm: Re-add manual CFI infrastructure x86/vdso: Define BUILD_VDSO while building and emit .eh_frame in asm x86/vdso: Replace hex int80 CFI annotations with gas directives x86/elf/64: Clear more registers in elf_common_init x86/vdso/32: Save extra registers in the INT80 vsyscall path x86/entry/64/compat: Disable SYSENTER and SYSCALL32 entries x86/entry/64/compat: Remove audit optimizations x86/entry/64/compat: Remove most of the fast system call machinery x86/entry/64/compat: Set up full pt_regs for all compat syscalls x86/entry/syscalls: Move syscall table declarations into asm/syscalls.h x86/syscalls: Give sys_call_ptr_t a useful type x86/entry: Add do_syscall_32, a C function to do 32-bit syscalls x86/entry/64/compat: Migrate the body of the syscall entry to C x86/entry: Add C code for fast system call entries x86/vdso/compat: Wire up SYSENTER and SYSCSALL for compat userspace x86/entry/compat: Implement opportunistic SYSRETL for compat syscalls x86/entry/32: Open-code
[PATCH v2 02/36] x86/uaccess: __chk_range_not_ok is unlikely to return true
This should improve code quality a bit. It also shrinks the kernel text. Before: textdata bss dec hex filename 218283795194760 1277952 283010911afd723 vmlinux textdata bss dec hex filename 218279975194760 1277952 283007091afd5a5 vmlinux Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/uaccess.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h index 3e911c68876e..09b1b0ab94b7 100644 --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -51,13 +51,13 @@ static inline bool __chk_range_not_ok(unsigned long addr, unsigned long size, un * limit, not add it to the address). */ if (__builtin_constant_p(size)) - return addr > limit - size; + return unlikely(addr > limit - size); /* Arbitrary sizes? Be careful about overflow */ addr += size; - if (addr < size) + if (unlikely(addr < size)) return true; - return addr > limit; + return unlikely(addr > limit); } #define __range_not_ok(addr, size, limit) \ -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/36] x86/entry: Move lockdep_sys_exit to prepare_exit_to_usermode
Rather than worrying about exactly where LOCKDEP_SYS_EXIT should go in the asm code, add it to prepare_exit_from_usermode and remove all of the asm calls that are followed by prepare_exit_to_usermode. LOCKDEP_SYS_EXIT now appears only in the syscall fast paths. Signed-off-by: Andy Lutomirski --- arch/x86/entry/common.c | 2 ++ arch/x86/entry/entry_32.S | 2 -- arch/x86/entry/entry_64.S | 1 - 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c index 80dcc9261ca3..d94a60c16029 100644 --- a/arch/x86/entry/common.c +++ b/arch/x86/entry/common.c @@ -220,6 +220,8 @@ __visible void prepare_exit_to_usermode(struct pt_regs *regs) if (WARN_ON(!irqs_disabled())) local_irq_disable(); + lockdep_sys_exit(); + /* * In order to return to user mode, we need to have IRQs off with * none of _TIF_SIGPENDING, _TIF_NOTIFY_RESUME, _TIF_USER_RETURN_NOTIFY, diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index b2909bf8cf70..a08ded481aba 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -255,7 +255,6 @@ ret_from_intr: jb resume_kernel # not returning to v8086 or userspace ENTRY(resume_userspace) - LOCKDEP_SYS_EXIT DISABLE_INTERRUPTS(CLBR_ANY) TRACE_IRQS_OFF movl%esp, %eax @@ -372,7 +371,6 @@ syscall_call: syscall_after_call: movl%eax, PT_EAX(%esp) # store the return value syscall_exit: - LOCKDEP_SYS_EXIT jmp syscall_exit_work restore_all: diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index d3033183ed70..766254c2068b 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -557,7 +557,6 @@ ret_from_intr: jz retint_kernel /* Interrupt came from user space */ - LOCKDEP_SYS_EXIT_IRQ GLOBAL(retint_user) mov %rsp,%rdi callprepare_exit_to_usermode -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/36] selftests/x86: Add a test for vDSO unwinding
While the kernel itself doesn't use DWARF unwinding, user code
expects to be able to unwind the vDSO. The vsyscall (AT_SYSINFO)
entry is manually CFI-annotated, and this tests that it unwinds
correctly.
I tested the test by incorrectly annotating __kernel_vsyscall, and
the test indeed fails if I do that.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/Makefile | 2 +-
tools/testing/selftests/x86/unwind_vdso.c | 209 ++
2 files changed, 210 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/x86/unwind_vdso.c
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index fd55bc37fa18..75413529f4a2 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,7 +5,7 @@ include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs ldt_gdt syscall_nt
-TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault sigreturn
test_syscall_vdso
+TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault sigreturn
test_syscall_vdso unwind_vdso
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/unwind_vdso.c
b/tools/testing/selftests/x86/unwind_vdso.c
new file mode 100644
index ..5992ff24ab83
--- /dev/null
+++ b/tools/testing/selftests/x86/unwind_vdso.c
@@ -0,0 +1,209 @@
+/*
+ * unwind_vdso.c - tests unwind info for AT_SYSINFO in the vDSO
+ * Copyright (c) 2014-2015 Andrew Lutomirski
+ *
+ * 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.
+ *
+ * This tests __kernel_vsyscall's unwind info.
+ */
+
+#define _GNU_SOURCE
+
+#include
+#include
+
+#if defined(__GLIBC__) && __GLIBC__ == 2 && __GLIBC_MINOR__ < 16
+
+int main()
+{
+ /* We need getauxval(). */
+ printf("[SKIP]\tGLIBC before 2.16 cannot compile this test\n");
+ return 0;
+}
+
+#else
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *),
+ int flags)
+{
+ struct sigaction sa;
+ memset(&sa, 0, sizeof(sa));
+ sa.sa_sigaction = handler;
+ sa.sa_flags = SA_SIGINFO | flags;
+ sigemptyset(&sa.sa_mask);
+ if (sigaction(sig, &sa, 0))
+ err(1, "sigaction");
+}
+
+#ifdef __x86_64__
+# define WIDTH "q"
+#else
+# define WIDTH "l"
+#endif
+
+static unsigned long get_eflags(void)
+{
+ unsigned long eflags;
+ asm volatile ("pushf" WIDTH "\n\tpop" WIDTH " %0" : "=rm" (eflags));
+ return eflags;
+}
+
+static void set_eflags(unsigned long eflags)
+{
+ asm volatile ("push" WIDTH " %0\n\tpopf" WIDTH
+ : : "rm" (eflags) : "flags");
+}
+
+#define X86_EFLAGS_TF (1UL << 8)
+
+static volatile sig_atomic_t nerrs;
+static unsigned long sysinfo;
+static bool got_sysinfo = false;
+static unsigned long return_address;
+
+struct unwind_state {
+ unsigned long ip; /* trap source */
+ int depth; /* -1 until we hit the trap source */
+};
+
+_Unwind_Reason_Code trace_fn(struct _Unwind_Context * ctx, void *opaque)
+{
+ struct unwind_state *state = opaque;
+ unsigned long ip = _Unwind_GetIP(ctx);
+
+ if (state->depth == -1) {
+ if (ip == state->ip)
+ state->depth = 0;
+ else
+ return _URC_NO_REASON; /* Not there yet */
+ }
+ printf("\t 0x%lx\n", ip);
+
+ if (ip == return_address) {
+ /* Here we are. */
+ unsigned long eax = _Unwind_GetGR(ctx, 0);
+ unsigned long ecx = _Unwind_GetGR(ctx, 1);
+ unsigned long edx = _Unwind_GetGR(ctx, 2);
+ unsigned long ebx = _Unwind_GetGR(ctx, 3);
+ unsigned long ebp = _Unwind_GetGR(ctx, 5);
+ unsigned long esi = _Unwind_GetGR(ctx, 6);
+ unsigned long edi = _Unwind_GetGR(ctx, 7);
+ bool ok = (eax == SYS_getpid || eax == getpid()) &&
+ ebx == 1 && ecx == 2 && edx == 3 &&
+ esi == 4 && edi == 5 && ebp == 6;
+
+ if (!ok)
+ nerrs++;
+ printf("[%s]\t NR = %ld, args = %ld, %ld, %ld, %ld, %ld,
%ld\n",
+ (ok ? "O
[PATCH v2 05/36] x86/entry/64/compat: Fix SYSENTER's NT flag before user memory access
Clearing NT is part of the prologue, whereas loading up arg6 makes more sense to think about as part of syscall processing. Reorder them. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index a9360d40fb7f..aa76864a8a6b 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -89,15 +89,6 @@ ENTRY(entry_SYSENTER_compat) sub $(10*8), %rsp /* pt_regs->r8-11, bp, bx, r12-15 not saved */ /* -* no need to do an access_ok check here because rbp has been -* 32-bit zero extended -*/ - ASM_STAC -1: movl(%rbp), %ebp - _ASM_EXTABLE(1b, ia32_badarg) - ASM_CLAC - - /* * Sysenter doesn't filter flags, so we need to clear NT * ourselves. To save a few cycles, we can check whether * NT was set instead of doing an unconditional popfq. @@ -106,6 +97,15 @@ ENTRY(entry_SYSENTER_compat) jnz sysenter_fix_flags sysenter_flags_fixed: + /* +* no need to do an access_ok check here because rbp has been +* 32-bit zero extended +*/ + ASM_STAC +1: movl(%rbp), %ebp + _ASM_EXTABLE(1b, ia32_badarg) + ASM_CLAC + orl $TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) jnz sysenter_tracesys -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/36] x86/elf/64: Clear more registers in elf_common_init
Before we start calling execve in contexts that honor the full
pt_regs, we need to teach it to initialize all registers.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/elf.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index 2ee05c4f5f37..1514753fd435 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -171,11 +171,11 @@ do { \
static inline void elf_common_init(struct thread_struct *t,
struct pt_regs *regs, const u16 ds)
{
- /* Commented-out registers are cleared in stub_execve */
- /*regs->ax = regs->bx =*/ regs->cx = regs->dx = 0;
- regs->si = regs->di /*= regs->bp*/ = 0;
+ /* ax gets execve's return value. */
+ /*regs->ax = */ regs->bx = regs->cx = regs->dx = 0;
+ regs->si = regs->di = regs->bp = 0;
regs->r8 = regs->r9 = regs->r10 = regs->r11 = 0;
- /*regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;*/
+ regs->r12 = regs->r13 = regs->r14 = regs->r15 = 0;
t->fs = t->gs = 0;
t->fsindex = t->gsindex = 0;
t->ds = t->es = ds;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/36] x86/vdso/32: Save extra registers in the INT80 vsyscall path
The goal is to integrate the SYSENTER and SYSCALL32 entry paths with
the INT80 path. SYSENTER clobbers ESP and EIP. SYSCALL32 clobbers
ECX (and, invisibly, R11). SYSRETL (long mode to compat mode)
clobbers ECX and, invisibly, R11. SYSEXIT (which we only need for
native 32-bit) clobbers ECX and EDX.
This means that we'll need to provide ESP to the kernel in a
register (I chose ECX, since it's only needed for SYSENTER) and we
need to provide the args that normally live in ECX and EDX in
memory.
The epilogue needs to restore ECX and EDX, since user code relies on
regs being preserved.
We don't need to do anything special about EIP, since the kernel
already knows where we are. The kernel will eventually need to
know where int $0x80 lands, so add a vdso_image entry for it.
The only user-visible effect of this code is that ptrace-induced
changes to ECX and EDX during fast syscalls will be lost. This is
already the case for the SYSENTER path.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/vdso2c.c | 1 +
arch/x86/entry/vdso/vdso32/system_call.S | 25 -
arch/x86/include/asm/vdso.h | 1 +
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 2637eb1e3949..785d9922b106 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -101,6 +101,7 @@ struct vdso_sym required_syms[] = {
{"__kernel_vsyscall", true},
{"__kernel_sigreturn", true},
{"__kernel_rt_sigreturn", true},
+ {"int80_landing_pad", true},
};
__attribute__((format(printf, 1, 2))) __attribute__((noreturn))
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S
b/arch/x86/entry/vdso/vdso32/system_call.S
index b52cbfbe119e..d591fe93e93a 100644
--- a/arch/x86/entry/vdso/vdso32/system_call.S
+++ b/arch/x86/entry/vdso/vdso32/system_call.S
@@ -16,7 +16,30 @@
ALIGN
__kernel_vsyscall:
CFI_STARTPROC
- int $0x80
+ /*
+* Reshuffle regs so that all of any of the entry instructions
+* will preserve enough state.
+*/
+ pushl %edx
+ CFI_ADJUST_CFA_OFFSET 4
+ CFI_REL_OFFSET edx, 0
+ pushl %ecx
+ CFI_ADJUST_CFA_OFFSET 4
+ CFI_REL_OFFSET ecx, 0
+ movl%esp, %ecx
+
+ /* Enter using int $0x80 */
+ movl(%esp), %ecx
+ int $0x80
+GLOBAL(int80_landing_pad)
+
+ /* Restore ECX and EDX in case they were clobbered. */
+ popl%ecx
+ CFI_RESTORE ecx
+ CFI_ADJUST_CFA_OFFSET -4
+ popl%edx
+ CFI_RESTORE edx
+ CFI_ADJUST_CFA_OFFSET -4
ret
CFI_ENDPROC
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index 5bcb1de8296e..756de9190aec 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -26,6 +26,7 @@ struct vdso_image {
long sym___kernel_sigreturn;
long sym___kernel_rt_sigreturn;
long sym___kernel_vsyscall;
+ long sym_int80_landing_pad;
};
#ifdef CONFIG_X86_64
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/36] x86/vdso: Remove runtime 32-bit vDSO selection
32-bit userspace will now always see the same vDSO, which is exactly
what used to be the int80 vDSO. Subsequent patches will clean it up
and make it support SYSENTER and SYSCALL using alternatives.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vdso/Makefile | 35 +++---
arch/x86/entry/vdso/vdso2c.c | 1 -
arch/x86/entry/vdso/vdso32-setup.c | 28 +---
arch/x86/entry/vdso/vdso32/int80.S | 56 ---
arch/x86/entry/vdso/vdso32/syscall.S | 75
arch/x86/entry/vdso/vdso32/sysenter.S| 116 ---
arch/x86/entry/vdso/vdso32/system_call.S | 56 +++
arch/x86/entry/vdso/vma.c| 13 +---
arch/x86/ia32/ia32_signal.c | 4 +-
arch/x86/include/asm/elf.h | 2 +-
arch/x86/include/asm/vdso.h | 9 +--
arch/x86/kernel/signal.c | 4 +-
arch/x86/xen/setup.c | 13 +---
13 files changed, 77 insertions(+), 335 deletions(-)
delete mode 100644 arch/x86/entry/vdso/vdso32/int80.S
delete mode 100644 arch/x86/entry/vdso/vdso32/syscall.S
delete mode 100644 arch/x86/entry/vdso/vdso32/sysenter.S
create mode 100644 arch/x86/entry/vdso/vdso32/system_call.S
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index a3d0767a6b29..3bfb39e7b8b2 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -19,9 +19,7 @@ obj-y += vma.o
# vDSO images to build
vdso_img-$(VDSO64-y) += 64
vdso_img-$(VDSOX32-y) += x32
-vdso_img-$(VDSO32-y) += 32-int80
-vdso_img-$(CONFIG_IA32_EMULATION) += 32-syscall
-vdso_img-$(VDSO32-y) += 32-sysenter
+vdso_img-$(VDSO32-y) += 32
obj-$(VDSO32-y)+= vdso32-setup.o
@@ -122,15 +120,6 @@ $(obj)/%.so: $(obj)/%.so.dbg
$(obj)/vdsox32.so.dbg: $(src)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso)
-#
-# Build multiple 32-bit vDSO images to choose from at boot time.
-#
-vdso32.so-$(VDSO32-y) += int80
-vdso32.so-$(CONFIG_IA32_EMULATION) += syscall
-vdso32.so-$(VDSO32-y) += sysenter
-
-vdso32-images = $(vdso32.so-y:%=vdso32-%.so)
-
CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386 -Wl,-soname=linux-gate.so.1
@@ -139,14 +128,12 @@ VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-m,elf_i386
-Wl,-soname=linux-gate.so.1
override obj-dirs = $(dir $(obj)) $(obj)/vdso32/
targets += vdso32/vdso32.lds
-targets += vdso32/note.o vdso32/vclock_gettime.o $(vdso32.so-y:%=vdso32/%.o)
+targets += vdso32/note.o vdso32/vclock_gettime.o vdso32/system_call.o
targets += vdso32/vclock_gettime.o
-$(obj)/vdso32.o: $(vdso32-images:%=$(obj)/%)
-
KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS))
-$(vdso32-images:%=$(obj)/%.dbg): KBUILD_AFLAGS = $(KBUILD_AFLAGS_32)
-$(vdso32-images:%=$(obj)/%.dbg): asflags-$(CONFIG_X86_64) += -m32
+$(obj)/vdso32.so.dbg: KBUILD_AFLAGS = $(KBUILD_AFLAGS_32)
+$(obj)/vdso32.so.dbg: asflags-$(CONFIG_X86_64) += -m32
KBUILD_CFLAGS_32 := $(filter-out -m64,$(KBUILD_CFLAGS))
KBUILD_CFLAGS_32 := $(filter-out -mcmodel=kernel,$(KBUILD_CFLAGS_32))
@@ -157,13 +144,13 @@ KBUILD_CFLAGS_32 += $(call cc-option,
-fno-stack-protector)
KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-$(vdso32-images:%=$(obj)/%.dbg): KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
+$(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
-$(vdso32-images:%=$(obj)/%.dbg): $(obj)/vdso32-%.so.dbg: FORCE \
-$(obj)/vdso32/vdso32.lds \
-$(obj)/vdso32/vclock_gettime.o \
-$(obj)/vdso32/note.o \
-$(obj)/vdso32/%.o
+$(obj)/vdso32.so.dbg: FORCE \
+ $(obj)/vdso32/vdso32.lds \
+ $(obj)/vdso32/vclock_gettime.o \
+ $(obj)/vdso32/note.o \
+ $(obj)/vdso32/system_call.o
$(call if_changed,vdso)
#
@@ -206,4 +193,4 @@ $(vdso_img_insttargets): install_%: $(obj)/%.dbg
$(MODLIB)/vdso FORCE
PHONY += vdso_install $(vdso_img_insttargets)
vdso_install: $(vdso_img_insttargets) FORCE
-clean-files := vdso32-syscall* vdso32-sysenter* vdso32-int80* vdso64*
vdso-image-*.c vdsox32.so*
+clean-files := vdso32.so vdso32.so.dbg vdso64* vdso-image-*.c vdsox32.so*
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 8627db24a7f6..2637eb1e3949 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -98,7 +98,6 @@ struct vdso_sym required_syms[] = {
"VDSO_FAKE_SECTION_TABLE_END", false
},
{"VDSO32_NOTE_MASK", true},
- {"VDSO32_SYSENTER_RETURN", true},
{"__kernel_vsyscall", true},
{"__kernel_sigreturn
[PATCH v2 09/36] x86/asm: Re-add manual CFI infrastructure
Commit 131484c8da97 ("x86/debug: Remove perpetually broken,
unmaintainable dwarf annotations") removed all the manual DWARF
annotations outside the vDSO. It also removed the macros we used
for the manual annotations.
Re-add the macros so that we can clean up the vDSO annotations.
Signed-off-by: Andy Lutomirski
---
arch/x86/Makefile | 10 ++-
arch/x86/include/asm/dwarf2.h | 170 ++
2 files changed, 178 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/include/asm/dwarf2.h
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 747860c696e1..2dfaa72260b4 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -159,6 +159,12 @@ endif
sp-$(CONFIG_X86_32) := esp
sp-$(CONFIG_X86_64) := rsp
+# do binutils support CFI?
+cfi := $(call as-instr,.cfi_startproc\n.cfi_rel_offset
$(sp-y)$(comma)0\n.cfi_endproc,-DCONFIG_AS_CFI=1)
+# is .cfi_signal_frame supported too?
+cfi-sigframe := $(call
as-instr,.cfi_startproc\n.cfi_signal_frame\n.cfi_endproc,-DCONFIG_AS_CFI_SIGNAL_FRAME=1)
+cfi-sections := $(call as-instr,.cfi_sections
.debug_frame,-DCONFIG_AS_CFI_SECTIONS=1)
+
# does binutils support specific instructions?
asinstr := $(call as-instr,fxsaveq (%rax),-DCONFIG_AS_FXSAVEQ=1)
asinstr += $(call as-instr,pshufb %xmm0$(comma)%xmm0,-DCONFIG_AS_SSSE3=1)
@@ -166,8 +172,8 @@ asinstr += $(call as-instr,crc32l
%eax$(comma)%eax,-DCONFIG_AS_CRC32=1)
avx_instr := $(call as-instr,vxorps
%ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1)
avx2_instr :=$(call as-instr,vpbroadcastb
%xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
-KBUILD_AFLAGS += $(asinstr) $(avx_instr) $(avx2_instr)
-KBUILD_CFLAGS += $(asinstr) $(avx_instr) $(avx2_instr)
+KBUILD_AFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr)
+KBUILD_CFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr)
LDFLAGS := -m elf_$(UTS_MACHINE)
diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
new file mode 100644
index ..de1cdaf4d743
--- /dev/null
+++ b/arch/x86/include/asm/dwarf2.h
@@ -0,0 +1,170 @@
+#ifndef _ASM_X86_DWARF2_H
+#define _ASM_X86_DWARF2_H
+
+#ifndef __ASSEMBLY__
+#warning "asm/dwarf2.h should be only included in pure assembly files"
+#endif
+
+/*
+ * Macros for dwarf2 CFI unwind table entries.
+ * See "as.info" for details on these pseudo ops. Unfortunately
+ * they are only supported in very new binutils, so define them
+ * away for older version.
+ */
+
+#ifdef CONFIG_AS_CFI
+
+#define CFI_STARTPROC .cfi_startproc
+#define CFI_ENDPROC.cfi_endproc
+#define CFI_DEF_CFA.cfi_def_cfa
+#define CFI_DEF_CFA_REGISTER .cfi_def_cfa_register
+#define CFI_DEF_CFA_OFFSET .cfi_def_cfa_offset
+#define CFI_ADJUST_CFA_OFFSET .cfi_adjust_cfa_offset
+#define CFI_OFFSET .cfi_offset
+#define CFI_REL_OFFSET .cfi_rel_offset
+#define CFI_REGISTER .cfi_register
+#define CFI_RESTORE.cfi_restore
+#define CFI_REMEMBER_STATE .cfi_remember_state
+#define CFI_RESTORE_STATE .cfi_restore_state
+#define CFI_UNDEFINED .cfi_undefined
+#define CFI_ESCAPE .cfi_escape
+
+#ifdef CONFIG_AS_CFI_SIGNAL_FRAME
+#define CFI_SIGNAL_FRAME .cfi_signal_frame
+#else
+#define CFI_SIGNAL_FRAME
+#endif
+
+#if defined(CONFIG_AS_CFI_SECTIONS) && defined(__ASSEMBLY__)
+ /*
+* Emit CFI data in .debug_frame sections, not .eh_frame sections.
+* The latter we currently just discard since we don't do DWARF
+* unwinding at runtime. So only the offline DWARF information is
+* useful to anyone. Note we should not use this directive if this
+* file is used in the vDSO assembly, or if vmlinux.lds.S gets
+* changed so it doesn't discard .eh_frame.
+*/
+ .cfi_sections .debug_frame
+#endif
+
+#else
+
+/*
+ * Due to the structure of pre-exisiting code, don't use assembler line
+ * comment character # to ignore the arguments. Instead, use a dummy macro.
+ */
+.macro cfi_ignore a=0, b=0, c=0, d=0
+.endm
+
+#define CFI_STARTPROC cfi_ignore
+#define CFI_ENDPROCcfi_ignore
+#define CFI_DEF_CFAcfi_ignore
+#define CFI_DEF_CFA_REGISTER cfi_ignore
+#define CFI_DEF_CFA_OFFSET cfi_ignore
+#define CFI_ADJUST_CFA_OFFSET cfi_ignore
+#define CFI_OFFSET cfi_ignore
+#define CFI_REL_OFFSET cfi_ignore
+#define CFI_REGISTER cfi_ignore
+#define CFI_RESTOREcfi_ignore
+#define CFI_REMEMBER_STATE cfi_ignore
+#define CFI_RESTORE_STATE cfi_ignore
+#define CFI_UNDEFINED cfi_ignore
+#define CFI_ESCAPE cfi_ignore
+#define CFI_SIGNAL_FRAME cfi_ignore
+
+#endif
+
+/*
+ * An attempt to make CFI annotations more or less
+ * correct and shorter. It is implied that you know
+ * what you're doing if you use them.
+ */
+#ifdef __ASSEMBLY__
+#ifdef CONFIG_X86_64
+ .macro pushq_cfi reg
+
[PATCH v2 15/36] x86/entry/64/compat: Remove audit optimizations
These audit optimizations are messy and hard to maintain. We'll get a similar effect from opportunistic sysret when fast compat system calls are re-implemented. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 98 +--- 1 file changed, 2 insertions(+), 96 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index e11aa38696fe..8f847722ce72 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -16,16 +16,6 @@ #include #include -/* Avoid __ASSEMBLER__'ifying just for this. */ -#include -#define AUDIT_ARCH_I386(EM_386|__AUDIT_ARCH_LE) -#define __AUDIT_ARCH_LE0x4000 - -#ifndef CONFIG_AUDITSYSCALL -# define sysexit_audit ia32_ret_from_sys_call_irqs_off -# define sysretl_audit ia32_ret_from_sys_call_irqs_off -#endif - .section .entry.text, "ax" #ifdef CONFIG_PARAVIRT @@ -148,7 +138,7 @@ sysenter_dispatch: DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz sysexit_audit + jnz ia32_ret_from_sys_call_irqs_off sysexit_from_sys_call: /* * NB: SYSEXIT is not obviously safe for 64-bit kernels -- an @@ -200,81 +190,12 @@ sysexit_from_sys_call: */ USERGS_SYSRET32 -#ifdef CONFIG_AUDITSYSCALL - .macro auditsys_entry_common - /* -* At this point, registers hold syscall args in the 32-bit syscall ABI: -* EAX is syscall number, the 6 args are in EBX,ECX,EDX,ESI,EDI,EBP. -* -* We want to pass them to __audit_syscall_entry(), which is a 64-bit -* C function with 5 parameters, so shuffle them to match what -* the function expects: RDI,RSI,RDX,RCX,R8. -*/ - movl%esi, %r8d /* arg5 (R8 ) <= 4th syscall arg (ESI) */ - xchg%ecx, %edx /* arg4 (RCX) <= 3rd syscall arg (EDX) */ - /* arg3 (RDX) <= 2nd syscall arg (ECX) */ - movl%ebx, %esi /* arg2 (RSI) <= 1st syscall arg (EBX) */ - movl%eax, %edi /* arg1 (RDI) <= syscall number (EAX) */ - call__audit_syscall_entry - - /* -* We are going to jump back to the syscall dispatch code. -* Prepare syscall args as required by the 64-bit C ABI. -* Registers clobbered by __audit_syscall_entry() are -* loaded from pt_regs on stack: -*/ - movlORIG_RAX(%rsp), %eax/* syscall number */ - movl%ebx, %edi /* arg1 */ - movlRCX(%rsp), %esi /* arg2 */ - movlRDX(%rsp), %edx /* arg3 */ - movlRSI(%rsp), %ecx /* arg4 */ - movlRDI(%rsp), %r8d /* arg5 */ - .endm - - .macro auditsys_exit exit - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) - testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz ia32_ret_from_sys_call - movl%eax, %esi /* second arg, syscall return value */ - cmpl$-MAX_ERRNO, %eax /* is it an error ? */ - jbe 1f - movslq %eax, %rsi /* if error sign extend to 64 bits */ -1: setbe %al /* 1 if error, 0 if not */ - movzbl %al, %edi /* zero-extend that into %edi */ - call__audit_syscall_exit - movl$(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), %edi - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - testl %edi, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jz \exit - xorl%eax, %eax /* Do not leak kernel information */ - movq%rax, R11(%rsp) - movq%rax, R10(%rsp) - movq%rax, R9(%rsp) - movq%rax, R8(%rsp) - jmp int_ret_from_sys_call_irqs_off - .endm - -sysenter_auditsys: - auditsys_entry_common - movl%ebp, %r9d /* reload 6th syscall arg */ - jmp sysenter_dispatch - -sysexit_audit: - auditsys_exit sysexit_from_sys_call -#endif - sysenter_fix_flags: pushq $X86_EFLAGS_FIXED popfq jmp sysenter_flags_fixed sysenter_tracesys: -#ifdef CONFIG_AUDITSYSCALL - testl $(_TIF_WORK_SYSCALL_ENTRY & ~_TIF_SYSCALL_AUDIT), ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jz sysenter_auditsys -#endif SAVE_EXTRA_REGS xorl%eax, %eax /* Do not leak kernel information */ movq%rax, R11(%rsp) @@ -389,7 +310,7 @@ cstar_dispatch: DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz sysretl_audit + jnz ia32_ret_from_sys_call_irqs_o
[PATCH v2 10/36] x86/vdso: Define BUILD_VDSO while building and emit .eh_frame in asm
For the vDSO, user code wants runtime unwind info. Make sure that, if we use .cfi directives, we generate it. Signed-off-by: Andy Lutomirski --- arch/x86/entry/vdso/Makefile | 4 ++-- arch/x86/include/asm/dwarf2.h | 13 ++--- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile index 3bfb39e7b8b2..265c0ed68118 100644 --- a/arch/x86/entry/vdso/Makefile +++ b/arch/x86/entry/vdso/Makefile @@ -67,7 +67,7 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so $(obj)/vdso2c FORCE CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64 \ $(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \ -fno-omit-frame-pointer -foptimize-sibling-calls \ - -DDISABLE_BRANCH_PROFILING + -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(vobjs): KBUILD_CFLAGS += $(CFL) @@ -131,7 +131,7 @@ targets += vdso32/vdso32.lds targets += vdso32/note.o vdso32/vclock_gettime.o vdso32/system_call.o targets += vdso32/vclock_gettime.o -KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS)) +KBUILD_AFLAGS_32 := $(filter-out -m64,$(KBUILD_AFLAGS)) -DBUILD_VDSO $(obj)/vdso32.so.dbg: KBUILD_AFLAGS = $(KBUILD_AFLAGS_32) $(obj)/vdso32.so.dbg: asflags-$(CONFIG_X86_64) += -m32 diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h index de1cdaf4d743..09133ba032b3 100644 --- a/arch/x86/include/asm/dwarf2.h +++ b/arch/x86/include/asm/dwarf2.h @@ -36,15 +36,22 @@ #endif #if defined(CONFIG_AS_CFI_SECTIONS) && defined(__ASSEMBLY__) +#ifndef BUILD_VDSO /* * Emit CFI data in .debug_frame sections, not .eh_frame sections. * The latter we currently just discard since we don't do DWARF * unwinding at runtime. So only the offline DWARF information is -* useful to anyone. Note we should not use this directive if this -* file is used in the vDSO assembly, or if vmlinux.lds.S gets -* changed so it doesn't discard .eh_frame. +* useful to anyone. Note we should not use this directive if +* vmlinux.lds.S gets changed so it doesn't discard .eh_frame. */ .cfi_sections .debug_frame +#else +/* + * For the vDSO, emit both runtime unwind information and debug + * symbols for the .dbg file. + */ + .cfi_sections .eh_frame, .debug_frame +#endif #endif #else -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 14/36] x86/entry/64/compat: Disable SYSENTER and SYSCALL32 entries
We've disabled the vDSO helpers to call them, so turn off the entries entirely (temporarily) in preparation for cleaning them up. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 1432d60a1f4a..e11aa38696fe 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -103,6 +103,14 @@ ENTRY(entry_SYSENTER_compat) jnz sysenter_fix_flags sysenter_flags_fixed: + /* Temporary: SYSENTER is disabled. */ +#ifdef CONFIG_CONTEXT_TRACKING + call enter_from_user_mode +#endif + ENABLE_INTERRUPTS(CLBR_NONE) + movl $11, %edi + call do_exit + /* * Re-enable interrupts. IRQ tracing already thinks that IRQs are * on (since we treat user mode as having IRQs on), and the @@ -324,6 +332,11 @@ ENTRY(entry_SYSCALL_compat) * it is too small to ever cause noticeable irq latency. */ SWAPGS_UNSAFE_STACK + + /* Temporary: SYSCALL32 is disabled. */ + movl$-ENOSYS, %eax + USERGS_SYSRET32 + movl%esp, %r8d movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp ENABLE_INTERRUPTS(CLBR_NONE) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 18/36] x86/entry/syscalls: Move syscall table declarations into asm/syscalls.h
The header was missing some compat declarations.
Also make sys_call_ptr_t have a consistent type.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/syscall_32.c | 5 +
arch/x86/include/asm/syscall.h | 12 +++-
arch/x86/um/sys_call_table_32.c | 3 +--
arch/x86/um/sys_call_table_64.c | 3 +--
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/x86/entry/syscall_32.c b/arch/x86/entry/syscall_32.c
index 8ea34f94e973..429460d7721e 100644
--- a/arch/x86/entry/syscall_32.c
+++ b/arch/x86/entry/syscall_32.c
@@ -4,13 +4,12 @@
#include
#include
#include
+#include
#ifdef CONFIG_IA32_EMULATION
#define SYM(sym, compat) compat
#else
#define SYM(sym, compat) sym
-#define ia32_sys_call_table sys_call_table
-#define __NR_syscall_compat_max __NR_syscall_max
#endif
#define __SYSCALL_I386(nr, sym, compat) extern asmlinkage void SYM(sym,
compat)(void) ;
@@ -19,8 +18,6 @@
#define __SYSCALL_I386(nr, sym, compat) [nr] = SYM(sym, compat),
-typedef asmlinkage void (*sys_call_ptr_t)(void);
-
extern asmlinkage void sys_ni_syscall(void);
__visible const sys_call_ptr_t ia32_sys_call_table[__NR_syscall_compat_max+1]
= {
diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
index d6a756ae04c8..f3ff2ef36e19 100644
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -20,9 +20,19 @@
#include/* for TS_COMPAT */
#include
-typedef void (*sys_call_ptr_t)(void);
+typedef asmlinkage void (*sys_call_ptr_t)(void);
extern const sys_call_ptr_t sys_call_table[];
+#if defined(CONFIG_X86_32)
+#define ia32_sys_call_table sys_call_table
+#define __NR_syscall_compat_max __NR_syscall_max
+#define IA32_NR_syscalls NR_syscalls
+#endif
+
+#if defined(CONFIG_IA32_EMULATION)
+extern const sys_call_ptr_t ia32_sys_call_table[];
+#endif
+
/*
* Only the low 32 bits of orig_ax are meaningful, so we return int.
* This importantly ignores the high bits on 64-bit, so comparisons
diff --git a/arch/x86/um/sys_call_table_32.c b/arch/x86/um/sys_call_table_32.c
index bd16d6c370ec..d738e9c96036 100644
--- a/arch/x86/um/sys_call_table_32.c
+++ b/arch/x86/um/sys_call_table_32.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#define __NO_STUBS
@@ -30,8 +31,6 @@
#undef __SYSCALL_I386
#define __SYSCALL_I386(nr, sym, compat) [ nr ] = sym,
-typedef asmlinkage void (*sys_call_ptr_t)(void);
-
extern asmlinkage void sys_ni_syscall(void);
const sys_call_ptr_t sys_call_table[] cacheline_aligned = {
diff --git a/arch/x86/um/sys_call_table_64.c b/arch/x86/um/sys_call_table_64.c
index a75d8700472a..1ff9a21b2645 100644
--- a/arch/x86/um/sys_call_table_64.c
+++ b/arch/x86/um/sys_call_table_64.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#define __NO_STUBS
@@ -43,8 +44,6 @@
#undef __SYSCALL_64
#define __SYSCALL_64(nr, sym, compat) [ nr ] = sym,
-typedef void (*sys_call_ptr_t)(void);
-
extern void sys_ni_syscall(void);
const sys_call_ptr_t sys_call_table[] cacheline_aligned = {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/36] x86/vdso: Replace hex int80 CFI annotations with gas directives
Maintaining the current CFI annotations written in R'lyehian is difficult for most of us. Translate them to something a little closer to English. This will remove the CFI data for kernels built with extremely old versions of binutils. I think this is a fair tradeoff for the ability for mortals to edit the asm. Signed-off-by: Andy Lutomirski --- arch/x86/entry/vdso/vdso32/system_call.S | 48 ++-- 1 file changed, 8 insertions(+), 40 deletions(-) diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S index b15b7c01aedb..b52cbfbe119e 100644 --- a/arch/x86/entry/vdso/vdso32/system_call.S +++ b/arch/x86/entry/vdso/vdso32/system_call.S @@ -1,6 +1,10 @@ /* * Code for the vDSO. This version uses the old int $0x80 method. - * +*/ + +#include + +/* * First get the common code for the sigreturn entry points. * This must come first. */ @@ -11,46 +15,10 @@ .type __kernel_vsyscall,@function ALIGN __kernel_vsyscall: -.LSTART_vsyscall: + CFI_STARTPROC int $0x80 ret -.LEND_vsyscall: - .size __kernel_vsyscall,.-.LSTART_vsyscall - .previous - - .section .eh_frame,"a",@progbits -.LSTARTFRAMEDLSI: - .long .LENDCIEDLSI-.LSTARTCIEDLSI -.LSTARTCIEDLSI: - .long 0 /* CIE ID */ - .byte 1 /* Version number */ - .string "zR"/* NUL-terminated augmentation string */ - .uleb128 1 /* Code alignment factor */ - .sleb128 -4 /* Data alignment factor */ - .byte 8 /* Return address register column */ - .uleb128 1 /* Augmentation value length */ - .byte 0x1b /* DW_EH_PE_pcrel|DW_EH_PE_sdata4. */ - .byte 0x0c /* DW_CFA_def_cfa */ - .uleb128 4 - .uleb128 4 - .byte 0x88 /* DW_CFA_offset, column 0x8 */ - .uleb128 1 - .align 4 -.LENDCIEDLSI: - .long .LENDFDEDLSI-.LSTARTFDEDLSI /* Length FDE */ -.LSTARTFDEDLSI: - .long .LSTARTFDEDLSI-.LSTARTFRAMEDLSI /* CIE pointer */ - .long .LSTART_vsyscall-./* PC-relative start address */ - .long .LEND_vsyscall-.LSTART_vsyscall - .uleb128 0 - .align 4 -.LENDFDEDLSI: - .previous + CFI_ENDPROC - /* -* Pad out the segment to match the size of the sysenter.S version. -*/ -VDSO32_vsyscall_eh_frame_size = 0x40 - .section .data,"aw",@progbits - .space VDSO32_vsyscall_eh_frame_size-(.LENDFDEDLSI-.LSTARTFRAMEDLSI), 0 + .size __kernel_vsyscall,.-__kernel_vsyscall .previous -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 16/36] x86/entry/64/compat: Remove most of the fast system call machinery
We now have only one code path that calls through the compat syscall table. This will make it much more pleasant to change the pt_regs vs register calling convention, which we need to do to move the call into C. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 246 +-- 1 file changed, 4 insertions(+), 242 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 8f847722ce72..3216e6072312 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -101,119 +101,13 @@ sysenter_flags_fixed: movl $11, %edi call do_exit - /* -* Re-enable interrupts. IRQ tracing already thinks that IRQs are -* on (since we treat user mode as having IRQs on), and the -* prologue above is too short for it to be worth adding a -* tracing round trip. -*/ - ENABLE_INTERRUPTS(CLBR_NONE) - - /* -* no need to do an access_ok check here because rbp has been -* 32-bit zero extended -*/ - ASM_STAC -1: movl(%rbp), %ebp - _ASM_EXTABLE(1b, ia32_badarg) - ASM_CLAC - - orl $TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) - testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz sysenter_tracesys - -sysenter_do_call: - /* 32-bit syscall -> 64-bit C ABI argument conversion */ - movl%edi, %r8d /* arg5 */ - movl%ebp, %r9d /* arg6 */ - xchg%ecx, %esi /* rsi:arg2, rcx:arg4 */ - movl%ebx, %edi /* arg1 */ - movl%edx, %edx /* arg3 (zero extension) */ -sysenter_dispatch: - cmpq$(IA32_NR_syscalls-1), %rax - ja 1f - call*ia32_sys_call_table(, %rax, 8) - movq%rax, RAX(%rsp) -1: - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - testl $_TIF_ALLWORK_MASK, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz ia32_ret_from_sys_call_irqs_off -sysexit_from_sys_call: - /* -* NB: SYSEXIT is not obviously safe for 64-bit kernels -- an -* NMI between STI and SYSEXIT has poorly specified behavior, -* and and NMI followed by an IRQ with usergs is fatal. So -* we just pretend we're using SYSEXIT but we really use -* SYSRETL instead. -* -* This code path is still called 'sysexit' because it pairs -* with 'sysenter' and it uses the SYSENTER calling convention. -*/ - andl$~TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) - movlRIP(%rsp), %ecx /* User %eip */ - movqRAX(%rsp), %rax - movlRSI(%rsp), %esi - movlRDI(%rsp), %edi - xorl%edx, %edx /* Do not leak kernel information */ - xorq%r8, %r8 - xorq%r9, %r9 - xorq%r10, %r10 - movlEFLAGS(%rsp), %r11d /* User eflags */ - TRACE_IRQS_ON - - /* -* SYSRETL works even on Intel CPUs. Use it in preference to SYSEXIT, -* since it avoids a dicey window with interrupts enabled. -*/ - movlRSP(%rsp), %esp - - /* -* USERGS_SYSRET32 does: -* gsbase = user's gs base -* eip = ecx -* rflags = r11 -* cs = __USER32_CS -* ss = __USER_DS -* -* The prologue set RIP(%rsp) to VDSO32_SYSENTER_RETURN, which does: -* -* pop %ebp -* pop %edx -* pop %ecx -* -* Therefore, we invoke SYSRETL with EDX and R8-R10 zeroed to -* avoid info leaks. R11 ends up with VDSO32_SYSENTER_RETURN's -* address (already known to user code), and R12-R15 are -* callee-saved and therefore don't contain any interesting -* kernel data. -*/ - USERGS_SYSRET32 + /* Unreachable. */ + ud2 sysenter_fix_flags: pushq $X86_EFLAGS_FIXED popfq jmp sysenter_flags_fixed - -sysenter_tracesys: - SAVE_EXTRA_REGS - xorl%eax, %eax /* Do not leak kernel information */ - movq%rax, R11(%rsp) - movq%rax, R10(%rsp) - movq%rax, R9(%rsp) - movq%rax, R8(%rsp) - movq%rsp, %rdi /* &pt_regs -> arg1 */ - callsyscall_trace_enter - - /* Reload arg registers from stack. (see sysenter_tracesys) */ - movlRCX(%rsp), %ecx - movlRDX(%rsp), %edx - movlRSI(%rsp), %esi - movlRDI(%rsp), %edi - movl%eax, %eax /* zero extension */ - - RESTORE_EXTRA_REGS - jmp sysenter_do_call ENDPROC(entry_SYSENTER_compat) /* @@ -280,142 +174,10 @@ ENTRY(entry_SYSCALL_compat) pushq $-ENOSYS/* pt_regs->ax */ sub $(10*8), %rsp
Re: [RFC v2 4/7] powerpc: atomic: Implement xchg_* and atomic{,64}_xchg_* variants
On Mon, Oct 05, 2015 at 03:44:07PM +0100, Will Deacon wrote: > On Thu, Oct 01, 2015 at 07:03:01PM +0100, Paul E. McKenney wrote: > > On Thu, Oct 01, 2015 at 07:13:04PM +0200, Peter Zijlstra wrote: > > > On Thu, Oct 01, 2015 at 08:09:09AM -0700, Paul E. McKenney wrote: > > > > On Thu, Oct 01, 2015 at 02:24:40PM +0200, Peter Zijlstra wrote: > > > > > > > > I must say I'm somewhat surprised by this level of relaxation, I had > > > > > expected to only loose SMP barriers, not the program order ones. > > > > > > > > > > Is there a good argument for this? > > > > > > > > Yes, when we say "relaxed", we really mean relaxed. ;-) > > > > > > > > Both the CPU and the compiler are allowed to reorder around relaxed > > > > operations. > > > > > > Is this documented somewhere, because I completely missed this part. > > > > Well, yes, these need to be added to the documentation. I am assuming > > that Will is looking to have the same effect as C11 memory_order_relaxed, > > which is relaxed in this sense. If he has something else in mind, > > he needs to tell us what it is and why. ;-) > > I was treating them purely as being single-copy atomic and not providing > any memory ordering guarantees (much like the non *_return atomic operations > that we already have). I think this lines up with C11, minus the bits > about data races which we don't call out anyway. As long as it is single-copy atomic and not multi-copy atomic, I believe we are on the saem page. We have slowly been outlawing some sorts of data races over the past few years, and I would guess that this will continue, expecially if good tooling emerges (and KTSAN is showing some promise from what I can see). Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 20/36] x86/entry: Add do_syscall_32, a C function to do 32-bit syscalls
System calls are really quite simple. Add a helper to call
a 32-bit system call.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index d94a60c16029..41d17508cf46 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -318,3 +318,46 @@ __visible void syscall_return_slowpath(struct pt_regs
*regs)
local_irq_disable();
prepare_exit_to_usermode(regs);
}
+
+#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
+/*
+ * Does a 32-bit syscall. Called with IRQs off and does all entry and
+ * exit work.
+ */
+__visible void do_int80_syscall_32(struct pt_regs *regs)
+{
+ struct thread_info *ti = pt_regs_to_thread_info(regs);
+ unsigned int nr = (unsigned int)regs->orig_ax;
+
+#ifdef CONFIG_IA32_EMULATION
+ ti->status |= TS_COMPAT;
+#endif
+
+ local_irq_enable();
+
+ if (READ_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY) {
+ /*
+* Subtlety here: if ptrace pokes something larger than
+* 2^32-1 into orig_ax, this truncates it. This may or
+* may not be necessary, but it matches the old asm
+* behavior.
+*/
+ nr = syscall_trace_enter(regs);
+ }
+
+ if (nr < IA32_NR_syscalls) {
+ /*
+* It's possible that a 32-bit syscall implementation
+* takes a 64-bit parameter but nonetheless assumes that
+* the high bits are zero. Make sure we zero-extend all
+* of the args.
+*/
+ regs->ax = ia32_sys_call_table[nr](
+ (unsigned int)regs->bx, (unsigned int)regs->cx,
+ (unsigned int)regs->dx, (unsigned int)regs->si,
+ (unsigned int)regs->di, (unsigned int)regs->bp);
+ }
+
+ syscall_return_slowpath(regs);
+}
+#endif
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 22/36] x86/entry: Add C code for fast system call entries
This handles both SYSENTER and SYSCALL. The asm glue will take care
of the differences.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 41d17508cf46..1b2606edc621 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -24,6 +24,8 @@
#include
#include
+#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -360,4 +362,45 @@ __visible void do_int80_syscall_32(struct pt_regs *regs)
syscall_return_slowpath(regs);
}
+
+__visible void do_fast_syscall_32(struct pt_regs *regs)
+{
+ /*
+* Called using the internal vDSO SYSENTER/SYSCALL32 calling
+* convention. Adjust regs so it looks like we entered using int80.
+*/
+
+ unsigned long landing_pad = (unsigned long)current->mm->context.vdso +
+ vdso_image_32.sym_int80_landing_pad;
+
+ /*
+* SYSENTER loses EIP, and even SYSCALL32 needs us to skip forward
+* so that 'regs->ip -= 2' lands back on an int $0x80 instruction.
+* Fix it up.
+*/
+ regs->ip = landing_pad;
+
+ /*
+* Fetch ECX from where the vDSO stashed it.
+*
+* WARNING: We are in CONTEXT_USER and RCU isn't paying attention!
+*/
+ local_irq_enable();
+ if (get_user(*(u32 *)®s->cx,
+(u32 __user __force *)(unsigned long)(u32)regs->sp)) {
+ /* User code screwed up. */
+ local_irq_disable();
+ regs->ax = -EFAULT;
+#ifdef CONFIG_CONTEXT_TRACKING
+ enter_from_user_mode();
+#endif
+ prepare_exit_to_usermode(regs);
+ return;
+ }
+ local_irq_disable();
+
+ /* Now this is just like a normal syscall. */
+ do_int80_syscall_32(regs);
+ return;
+}
#endif
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 17/36] x86/entry/64/compat: Set up full pt_regs for all compat syscalls
This is conceptually simpler. More importantly, it eliminates the PTREGSCALL and execve stubs, which were not compatible with the C ABI. This means that C code can call through the compat syscall table. The execve stubs are a bit subtle. They did two things: they cleared some registers and they forced slow-path return. Neither is necessary any more: elf_common_init clears the extra registers and start_thread calls force_iret(). Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64.S | 6 + arch/x86/entry/entry_64_compat.S | 42 +++--- arch/x86/entry/syscalls/syscall_32.tbl | 12 +- 3 files changed, 20 insertions(+), 40 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 766254c2068b..4f8c25eb3437 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -391,20 +391,16 @@ GLOBAL(stub_execveat) jmp return_from_execve END(stub_execveat) -#if defined(CONFIG_X86_X32_ABI) || defined(CONFIG_IA32_EMULATION) +#if defined(CONFIG_X86_X32_ABI) .align 8 GLOBAL(stub_x32_execve) -GLOBAL(stub32_execve) callcompat_sys_execve jmp return_from_execve -END(stub32_execve) END(stub_x32_execve) .align 8 GLOBAL(stub_x32_execveat) -GLOBAL(stub32_execveat) callcompat_sys_execveat jmp return_from_execve -END(stub32_execveat) END(stub_x32_execveat) #endif diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 3216e6072312..2c2aac577b3c 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -219,12 +219,18 @@ ENTRY(entry_INT80_compat) pushq %rdx/* pt_regs->dx */ pushq %rcx/* pt_regs->cx */ pushq $-ENOSYS/* pt_regs->ax */ - pushq $0 /* pt_regs->r8 */ - pushq $0 /* pt_regs->r9 */ - pushq $0 /* pt_regs->r10 */ - pushq $0 /* pt_regs->r11 */ + xorq%r8,%r8 + pushq %r8 /* pt_regs->r8 = 0 */ + pushq %r8 /* pt_regs->r9 = 0 */ + pushq %r8 /* pt_regs->r10 = 0 */ + pushq %r8 /* pt_regs->r11 = 0 */ + pushq %rbx/* pt_regs->rbx */ + pushq %rbp/* pt_regs->rbp */ + pushq %r12/* pt_regs->r12 */ + pushq %r13/* pt_regs->r13 */ + pushq %r14/* pt_regs->r14 */ + pushq %r15/* pt_regs->r15 */ cld - sub $(6*8), %rsp /* pt_regs->bp, bx, r12-15 not saved */ orl $TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) @@ -243,10 +249,10 @@ ia32_do_call: call*ia32_sys_call_table(, %rax, 8) movq%rax, RAX(%rsp) 1: + RESTORE_EXTRA_REGS jmp int_ret_from_sys_call ia32_tracesys: - SAVE_EXTRA_REGS movq%rsp, %rdi /* &pt_regs -> arg1 */ callsyscall_trace_enter /* @@ -261,25 +267,11 @@ ia32_tracesys: movlRSI(%rsp), %esi movlRDI(%rsp), %edi movl%eax, %eax /* zero extension */ - RESTORE_EXTRA_REGS jmp ia32_do_call END(entry_INT80_compat) - .macro PTREGSCALL label, func - ALIGN -GLOBAL(\label) - leaq\func(%rip), %rax - jmp ia32_ptregs_common - .endm - - PTREGSCALL stub32_rt_sigreturn, sys32_rt_sigreturn - PTREGSCALL stub32_sigreturn,sys32_sigreturn - PTREGSCALL stub32_fork, sys_fork - PTREGSCALL stub32_vfork,sys_vfork - ALIGN GLOBAL(stub32_clone) - leaqsys_clone(%rip), %rax /* * The 32-bit clone ABI is: clone(..., int tls_val, int *child_tidptr). * The 64-bit clone ABI is: clone(..., int *child_tidptr, int tls_val). @@ -288,12 +280,4 @@ GLOBAL(stub32_clone) * so we need to swap arguments here before calling it: */ xchg%r8, %rcx - jmp ia32_ptregs_common - - ALIGN -ia32_ptregs_common: - SAVE_EXTRA_REGS 8 - call*%rax - RESTORE_EXTRA_REGS 8 - ret -END(ia32_ptregs_common) + jmp sys_clone diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index 7663c455b9f6..caa2c712d1e7 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -8,7 +8,7 @@ # 0 i386restart_syscall sys_restart_syscall 1 i386exitsys_exit -2 i386forksys_fork stub32_fork +2
[PATCH v2 19/36] x86/syscalls: Give sys_call_ptr_t a useful type
Syscalls are asmlinkage functions (on 32-bit kernels), take six args
of type unsigned long, and return long. Note that uml could
probably be slightly cleaned up on top of this patch.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/syscall_32.c | 4 ++--
arch/x86/entry/syscall_64.c | 4 ++--
arch/x86/include/asm/syscall.h | 4 +++-
arch/x86/um/sys_call_table_32.c | 4 ++--
arch/x86/um/sys_call_table_64.c | 4 ++--
5 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/entry/syscall_32.c b/arch/x86/entry/syscall_32.c
index 429460d7721e..9a6649857106 100644
--- a/arch/x86/entry/syscall_32.c
+++ b/arch/x86/entry/syscall_32.c
@@ -12,13 +12,13 @@
#define SYM(sym, compat) sym
#endif
-#define __SYSCALL_I386(nr, sym, compat) extern asmlinkage void SYM(sym,
compat)(void) ;
+#define __SYSCALL_I386(nr, sym, compat) extern asmlinkage long SYM(sym,
compat)(unsigned long, unsigned long, unsigned long, unsigned long, unsigned
long, unsigned long) ;
#include
#undef __SYSCALL_I386
#define __SYSCALL_I386(nr, sym, compat) [nr] = SYM(sym, compat),
-extern asmlinkage void sys_ni_syscall(void);
+extern asmlinkage long sys_ni_syscall(unsigned long, unsigned long, unsigned
long, unsigned long, unsigned long, unsigned long);
__visible const sys_call_ptr_t ia32_sys_call_table[__NR_syscall_compat_max+1]
= {
/*
diff --git a/arch/x86/entry/syscall_64.c b/arch/x86/entry/syscall_64.c
index 4ac730b37f0b..41283d22be7a 100644
--- a/arch/x86/entry/syscall_64.c
+++ b/arch/x86/entry/syscall_64.c
@@ -14,13 +14,13 @@
# define __SYSCALL_X32(nr, sym, compat) /* nothing */
#endif
-#define __SYSCALL_64(nr, sym, compat) extern asmlinkage void sym(void) ;
+#define __SYSCALL_64(nr, sym, compat) extern asmlinkage long sym(unsigned
long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned
long) ;
#include
#undef __SYSCALL_64
#define __SYSCALL_64(nr, sym, compat) [nr] = sym,
-extern void sys_ni_syscall(void);
+extern long sys_ni_syscall(unsigned long, unsigned long, unsigned long,
unsigned long, unsigned long, unsigned long);
asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
/*
diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
index f3ff2ef36e19..999b7cd2e78c 100644
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -20,7 +20,9 @@
#include/* for TS_COMPAT */
#include
-typedef asmlinkage void (*sys_call_ptr_t)(void);
+typedef asmlinkage long (*sys_call_ptr_t)(unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long);
extern const sys_call_ptr_t sys_call_table[];
#if defined(CONFIG_X86_32)
diff --git a/arch/x86/um/sys_call_table_32.c b/arch/x86/um/sys_call_table_32.c
index d738e9c96036..439c0994b696 100644
--- a/arch/x86/um/sys_call_table_32.c
+++ b/arch/x86/um/sys_call_table_32.c
@@ -25,13 +25,13 @@
#define old_mmap sys_old_mmap
-#define __SYSCALL_I386(nr, sym, compat) extern asmlinkage void sym(void) ;
+#define __SYSCALL_I386(nr, sym, compat) extern asmlinkage long sym(unsigned
long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned
long) ;
#include
#undef __SYSCALL_I386
#define __SYSCALL_I386(nr, sym, compat) [ nr ] = sym,
-extern asmlinkage void sys_ni_syscall(void);
+extern asmlinkage long sys_ni_syscall(unsigned long, unsigned long, unsigned
long, unsigned long, unsigned long, unsigned long);
const sys_call_ptr_t sys_call_table[] cacheline_aligned = {
/*
diff --git a/arch/x86/um/sys_call_table_64.c b/arch/x86/um/sys_call_table_64.c
index 1ff9a21b2645..b74ea6c2c0e7 100644
--- a/arch/x86/um/sys_call_table_64.c
+++ b/arch/x86/um/sys_call_table_64.c
@@ -38,13 +38,13 @@
#define __SYSCALL_COMMON(nr, sym, compat) __SYSCALL_64(nr, sym, compat)
#define __SYSCALL_X32(nr, sym, compat) /* Not supported */
-#define __SYSCALL_64(nr, sym, compat) extern asmlinkage void sym(void) ;
+#define __SYSCALL_64(nr, sym, compat) extern asmlinkage long sym(unsigned
long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned
long) ;
#include
#undef __SYSCALL_64
#define __SYSCALL_64(nr, sym, compat) [ nr ] = sym,
-extern void sys_ni_syscall(void);
+extern asmlinkage long sys_ni_syscall(unsigned long, unsigned long, unsigned
long, unsigned long, unsigned long, unsigned long);
const sys_call_ptr_t sys_call_table[] cacheline_aligned = {
/*
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 23/36] x86/vdso/compat: Wire up SYSENTER and SYSCSALL for compat userspace
What, you didn't realize that SYSENTER and SYSCALL were actually the same thing? :) Unlike the old code, this actually passes the ptrace_syscall_32 test on AMD systems. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64_compat.S | 90 +++- arch/x86/entry/vdso/vdso32/system_call.S | 8 +++ 2 files changed, 62 insertions(+), 36 deletions(-) diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 63ef9fa29002..8f109de51d03 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -52,15 +52,18 @@ ENTRY(entry_SYSENTER_compat) SWAPGS_UNSAFE_STACK movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp - /* Zero-extending 32-bit regs, do not remove */ - movl%ebp, %ebp + /* +* User tracing code (ptrace or signal handlers) might assume that +* the saved RAX contains a 32-bit number when we're invoking a 32-bit +* syscall. Just in case the high bits are nonzero, zero-extend +* the syscall number. (This could almost certainly be deleted +* with no ill effects.) +*/ movl%eax, %eax - movlASM_THREAD_INFO(TI_sysenter_return, %rsp, 0), %r10d - /* Construct struct pt_regs on stack */ pushq $__USER32_DS/* pt_regs->ss */ - pushq %rbp/* pt_regs->sp */ + pushq %rcx/* pt_regs->sp */ /* * Push flags. This is nasty. First, interrupts are currently @@ -70,17 +73,28 @@ ENTRY(entry_SYSENTER_compat) */ pushfq /* pt_regs->flags (except IF = 0) */ orl $X86_EFLAGS_IF, (%rsp) /* Fix saved flags */ + ASM_CLAC/* Clear AC after saving FLAGS */ pushq $__USER32_CS/* pt_regs->cs */ - pushq %r10/* pt_regs->ip = thread_info->sysenter_return */ + xorq%r8,%r8 + pushq %r8 /* pt_regs->ip = 0 (placeholder) */ pushq %rax/* pt_regs->orig_ax */ pushq %rdi/* pt_regs->di */ pushq %rsi/* pt_regs->si */ pushq %rdx/* pt_regs->dx */ - pushq %rcx/* pt_regs->cx */ + pushq %rcx/* pt_regs->cx (will be overwritten) */ pushq $-ENOSYS/* pt_regs->ax */ + pushq %r8 /* pt_regs->r8 = 0 */ + pushq %r8 /* pt_regs->r9 = 0 */ + pushq %r8 /* pt_regs->r10 = 0 */ + pushq %r8 /* pt_regs->r11 = 0 */ + pushq %rbx/* pt_regs->rbx */ + pushq %rbp/* pt_regs->rbp */ + pushq %r8 /* pt_regs->r12 = 0 */ + pushq %r8 /* pt_regs->r13 = 0 */ + pushq %r8 /* pt_regs->r14 = 0 */ + pushq %r8 /* pt_regs->r15 = 0 */ cld - sub $(10*8), %rsp /* pt_regs->r8-11, bp, bx, r12-15 not saved */ /* * Sysenter doesn't filter flags, so we need to clear NT @@ -93,16 +107,15 @@ ENTRY(entry_SYSENTER_compat) jnz sysenter_fix_flags sysenter_flags_fixed: - /* Temporary: SYSENTER is disabled. */ -#ifdef CONFIG_CONTEXT_TRACKING - call enter_from_user_mode -#endif - ENABLE_INTERRUPTS(CLBR_NONE) - movl $11, %edi - call do_exit + /* +* User mode is traced as though IRQs are on, and SYSENTER +* turned them off. +*/ + TRACE_IRQS_OFF - /* Unreachable. */ - ud2 + movq%rsp, %rdi + calldo_fast_syscall_32 + jmp .Lsyscall_32_done sysenter_fix_flags: pushq $X86_EFLAGS_FIXED @@ -135,26 +148,14 @@ ENDPROC(entry_SYSENTER_compat) * edi arg5 * esp user stack * 0(%esp) arg6 - * - * This is purely a fast path. For anything complicated we use the int 0x80 - * path below. We set up a complete hardware stack frame to share code - * with the int 0x80 path. */ ENTRY(entry_SYSCALL_compat) - /* -* Interrupts are off on entry. -* We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON, -* it is too small to ever cause noticeable irq latency. -*/ + /* Interrupts are off on entry. */ SWAPGS_UNSAFE_STACK - /* Temporary: SYSCALL32 is disabled. */ - movl$-ENOSYS, %eax - USERGS_SYSRET32 - + /* Stash user ESP and switch to the kernel stack. */ movl%esp, %r8d movqPER_CPU_VAR(cpu_current_top_of_stack), %rsp - ENABLE_INTERRUPTS(CLBR_NONE) /* Zero-extending 32-bit regs, do not remove */ movl%eax, %eax @@ -169,13 +170,29 @@ ENTRY(entry_SYSCALL_compat) pushq
[PATCH v2 25/36] x86/entry/32: Open-code return tracking from fork and kthreads
syscall_exit is going away, and return tracing is just a function call now, so open-code the two non-syscall 32-bit users. While we're at it, update the big register layout comment. Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index a08ded481aba..36b6beb181f6 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -3,7 +3,7 @@ * * entry_32.S contains the system-call and low-level fault and trap handling routines. * - * Stack layout in 'syscall_exit': + * Stack layout while running C code: * ptrace needs to have all registers on the stack. * If the order here is changed, it needs to be * updated in fork.c:copy_process(), signal.c:do_signal(), @@ -211,7 +211,11 @@ ENTRY(ret_from_fork) popl%eax pushl $0x0202 # Reset kernel eflags popfl - jmp syscall_exit + + /* When we fork, we trace the syscall return in the child, too. */ + movl%esp, %eax + callsyscall_return_slowpath + jmp restore_all END(ret_from_fork) ENTRY(ret_from_kernel_thread) @@ -224,7 +228,15 @@ ENTRY(ret_from_kernel_thread) movlPT_EBP(%esp), %eax call*PT_EBX(%esp) movl$0, PT_EAX(%esp) - jmp syscall_exit + + /* +* Kernel threads return to userspace as if returning from a syscall. +* We should check whether anything actually uses this path and, if so, +* consider switching it over to ret_from_fork. +*/ + movl%esp, %eax + callsyscall_return_slowpath + jmp restore_all ENDPROC(ret_from_kernel_thread) /* -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 26/36] x86/entry/32: Switch INT80 to the new C syscall path
Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_32.S | 34 +- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 36b6beb181f6..02881e528945 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -153,13 +153,13 @@ #endif /* CONFIG_X86_32_LAZY_GS */ -.macro SAVE_ALL +.macro SAVE_ALL pt_regs_ax=%eax cld PUSH_GS pushl %fs pushl %es pushl %ds - pushl %eax + pushl \pt_regs_ax pushl %ebp pushl %edi pushl %esi @@ -370,20 +370,17 @@ ENDPROC(entry_SYSENTER_32) # system call handler stub ENTRY(entry_INT80_32) ASM_CLAC - pushl %eax# save orig_eax - SAVE_ALL - GET_THREAD_INFO(%ebp) - # system call tracing in operation / emulation - testl $_TIF_WORK_SYSCALL_ENTRY, TI_flags(%ebp) - jnz syscall_trace_entry - cmpl$(NR_syscalls), %eax - jae syscall_badsys -syscall_call: - call*sys_call_table(, %eax, 4) -syscall_after_call: - movl%eax, PT_EAX(%esp) # store the return value -syscall_exit: - jmp syscall_exit_work + pushl %eax/* pt_regs->orig_ax */ + SAVE_ALL pt_regs_ax=$-ENOSYS/* save rest, load -ENOSYS into ax */ + + /* +* User mode is traced as though IRQs are on, and the interrupt gate +* turned them off. +*/ + TRACE_IRQS_OFF + + movl%esp, %eax + calldo_int80_syscall_32 restore_all: TRACE_IRQS_IRET @@ -491,11 +488,6 @@ syscall_fault: jmp resume_userspace END(syscall_fault) -syscall_badsys: - movl$-ENOSYS, %eax - jmp syscall_after_call -END(syscall_badsys) - sysenter_badsys: movl$-ENOSYS, %eax jmp sysenter_after_call -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 21/36] x86/entry/64/compat: Migrate the body of the syscall entry to C
Signed-off-by: Andy Lutomirski --- arch/x86/entry/entry_64.S| 2 +- arch/x86/entry/entry_64_compat.S | 56 +--- 2 files changed, 19 insertions(+), 39 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 4f8c25eb3437..f9067d610e50 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -582,7 +582,7 @@ retint_kernel: * At this label, code paths which return to kernel and to user, * which come from interrupts/exception and from syscalls, merge. */ -restore_regs_and_iret: +GLOBAL(restore_regs_and_iret) RESTORE_EXTRA_REGS restore_c_regs_and_iret: RESTORE_C_REGS diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 2c2aac577b3c..63ef9fa29002 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -202,14 +202,17 @@ END(entry_SYSCALL_compat) ENTRY(entry_INT80_compat) /* * Interrupts are off on entry. -* We do not frame this tiny irq-off block with TRACE_IRQS_OFF/ON, -* it is too small to ever cause noticeable irq latency. */ PARAVIRT_ADJUST_EXCEPTION_FRAME SWAPGS - ENABLE_INTERRUPTS(CLBR_NONE) - /* Zero-extending 32-bit regs, do not remove */ + /* +* User tracing code (ptrace or signal handlers) might assume that +* the saved RAX contains a 32-bit number when we're invoking a 32-bit +* syscall. Just in case the high bits are nonzero, zero-extend +* the syscall number. (This could almost certainly be deleted +* with no ill effects.) +*/ movl%eax, %eax /* Construct struct pt_regs on stack (iret frame is already on stack) */ @@ -232,42 +235,19 @@ ENTRY(entry_INT80_compat) pushq %r15/* pt_regs->r15 */ cld - orl $TS_COMPAT, ASM_THREAD_INFO(TI_status, %rsp, SIZEOF_PTREGS) - testl $_TIF_WORK_SYSCALL_ENTRY, ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz ia32_tracesys - -ia32_do_call: - /* 32-bit syscall -> 64-bit C ABI argument conversion */ - movl%edi, %r8d /* arg5 */ - movl%ebp, %r9d /* arg6 */ - xchg%ecx, %esi /* rsi:arg2, rcx:arg4 */ - movl%ebx, %edi /* arg1 */ - movl%edx, %edx /* arg3 (zero extension) */ - cmpq$(IA32_NR_syscalls-1), %rax - ja 1f - - call*ia32_sys_call_table(, %rax, 8) - movq%rax, RAX(%rsp) -1: - RESTORE_EXTRA_REGS - jmp int_ret_from_sys_call - -ia32_tracesys: - movq%rsp, %rdi /* &pt_regs -> arg1 */ - callsyscall_trace_enter /* -* Reload arg registers from stack in case ptrace changed them. -* Don't reload %eax because syscall_trace_enter() returned -* the %rax value we should see. But do truncate it to 32 bits. -* If it's -1 to make us punt the syscall, then (u32)-1 is still -* an appropriately invalid value. +* User mode is traced as though IRQs are on, and the interrupt +* gate turned them off. */ - movlRCX(%rsp), %ecx - movlRDX(%rsp), %edx - movlRSI(%rsp), %esi - movlRDI(%rsp), %edi - movl%eax, %eax /* zero extension */ - jmp ia32_do_call + TRACE_IRQS_OFF + + movq%rsp, %rdi + calldo_int80_syscall_32 + + /* Go back to user mode. */ + TRACE_IRQS_ON + SWAPGS + jmp restore_regs_and_iret END(entry_INT80_compat) ALIGN -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
