Re: [PATCH] ARC: Improve handling of fatal signals in do_page_fault()
Hi Vineet, On Fri, 2018-06-29 at 11:20 -0700, Alexey Brodkin wrote: > This was triggered by investigation of a deadlock after OOM killer invocation, > see [1] for more details. > > Looks like our handling of fatal signal in do_page_fault() has some issues: > > 1. We only want to do special (read "early") handling of fatal signal >if handle_mm_fault() returned VM_FAULT_RETRY so that we don't loop >in retry loop endlessly, otherwise we'll handle that signal normally >on exit from exception handler. > > 2. up_read() is not needed as indeed it will be done in __lock_page_or_retry() >in mm/filemap.c. > > With above comments in mind simplified version should be like that: > --->8--- > if (fatal_signal_pending(current) > if (fault & VM_FAULT_RETRY) > if (user_mode(regs)) > return; > --->8--- > > But looks like there's a room for improvement, see [2]. > Instead of proceeding forward and then inevitably hitting retry path we > short-cut right to kernel fix-up code in no_context. > > [1] > http://lists.infradead.org/pipermail/linux-snps-arc/2018-February/003403.html > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=746a272e44141af24a02f6c9b0f65f4c4598ed42 > > Signed-off-by: Alexey Brodkin I should have put that in commit message right away:) This patch fixes OOM lock-up we were seeing previously, see STAR 9001304674 "OOM killer hangs system". -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: [plat-axs10x] Get rid of auto-selected CONFIG_AX10x options
On 07/11/2018 10:13 AM, Alexey Brodkin wrote:
> Commit 4fbaf649ebbc ("ARC: [plat-axs10x] auto-select AXS101 or AXS103 given
> the ISA config")
> made selection of CONFIG_AXS10x option automatic so there's no point
> in keeping them in defconfigs.
>
> Signed-off-by: Alexey Brodkin
Can you regenerate the defconfigs - there seem to be more changes now than just
those.
Also for the other patch for FUSE, is this something we will need day in day
out -
I'm afraid we will start bloating stuff .
If you insist I can add it - but i's still prefer you build them using modules
and
start testing that infra as well.
-Vineet
> ---
> arch/arc/configs/axs101_defconfig | 1 -
> arch/arc/configs/axs103_defconfig | 1 -
> arch/arc/configs/axs103_smp_defconfig | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/arch/arc/configs/axs101_defconfig
> b/arch/arc/configs/axs101_defconfig
> index 13500399ea86..55686cc4bb19 100644
> --- a/arch/arc/configs/axs101_defconfig
> +++ b/arch/arc/configs/axs101_defconfig
> @@ -23,7 +23,6 @@ CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_ARC_PLAT_AXS10X=y
> -CONFIG_AXS101=y
> CONFIG_ARC_CACHE_LINE_SHIFT=5
> CONFIG_ARC_BUILTIN_DTB_NAME="axs101"
> CONFIG_PREEMPT=y
> diff --git a/arch/arc/configs/axs103_defconfig
> b/arch/arc/configs/axs103_defconfig
> index a0576308cccd..20fb8e4e7337 100644
> --- a/arch/arc/configs/axs103_defconfig
> +++ b/arch/arc/configs/axs103_defconfig
> @@ -23,7 +23,6 @@ CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_ARC_PLAT_AXS10X=y
> -CONFIG_AXS103=y
> CONFIG_ISA_ARCV2=y
> CONFIG_ARC_BUILTIN_DTB_NAME="axs103"
> CONFIG_PREEMPT=y
> diff --git a/arch/arc/configs/axs103_smp_defconfig
> b/arch/arc/configs/axs103_smp_defconfig
> index 9bd590c22620..51d1e866ce94 100644
> --- a/arch/arc/configs/axs103_smp_defconfig
> +++ b/arch/arc/configs/axs103_smp_defconfig
> @@ -23,7 +23,6 @@ CONFIG_MODULE_UNLOAD=y
> CONFIG_MODULE_FORCE_UNLOAD=y
> CONFIG_PARTITION_ADVANCED=y
> CONFIG_ARC_PLAT_AXS10X=y
> -CONFIG_AXS103=y
> CONFIG_ISA_ARCV2=y
> CONFIG_SMP=y
> CONFIG_ARC_BUILTIN_DTB_NAME="axs103_idu"
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: [plat-axs10x] Get rid of auto-selected CONFIG_AX10x options
Hi Vineet,
On Thu, 2018-07-12 at 10:36 -0700, Vineet Gupta wrote:
> On 07/11/2018 10:13 AM, Alexey Brodkin wrote:
> > Commit 4fbaf649ebbc ("ARC: [plat-axs10x] auto-select AXS101 or AXS103 given
> > the ISA config")
> > made selection of CONFIG_AXS10x option automatic so there's no point
> > in keeping them in defconfigs.
> >
> > Signed-off-by: Alexey Brodkin
>
> Can you regenerate the defconfigs - there seem to be more changes now than
> just those.
The only thing left is this one:
->8--
@@ -63,7 +63,6 @@ CONFIG_MOUSE_PS2_TOUCHKIT=y
CONFIG_MOUSE_SERIAL=y
CONFIG_MOUSE_SYNAPTICS_USB=y
# CONFIG_LEGACY_PTYS is not set
-# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DW=y
->8--
But I was going to investigate a bit more on why this one became
not needed. Shouldn't be rocket science but I'd like to understand what
am I doing :)
> Also for the other patch for FUSE, is this something we will need day in day
> out -
> I'm afraid we will start bloating stuff .
For me the main usage of FUSE is SSHFS which allows to mount file-system of
whatever SSH-enabled server to the board. The point is it's quite a rare
occasion
when one may start and use NFS server on machine he/she doesn't own.
As an example I may build stuff on powerful server and still use results
on target.
> If you insist I can add it - but i's still prefer you build them using
> modules and
> start testing that infra as well.
Modules are all fine with one important note - on every kernel source change we
need to copy every module in rootfs otherwise older ones won't be even loaded.
So for development modules are not super convenient.
Another reason to add more pretty common options to at least HSDK (and I guess
AX10x stuff is on not much interest for you as compared to HSDK) is more and
more
people start to play with the board and to make their (and thus ours) life
easier
we'd better have basics in place from day one rather than explaining people how
to overcome "unexpected" difficulties.
We may indeed one again agree on having an additional defconfig for demos,
distros
and so on together with bare-minimal config we'll be using for our development
but
this will mean that fuller defconfig won't be daily tested which is not what we
want.
Also keeping in sync multiple configs is not the best idea ever especially if
there're
subtle differences here and there.
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: mm: allow mprotect to make stack mappings executable
mprotect(EXEC) was failing for stack mappings as default vm flags was missing MAYEXEC. This was triggered by glibc test suite nptl/tst-execstack testcase What is surprising is that despite running LTP for years on, we didn't catch this issue as it lacks a directed test case. gcc dejagnu tests with nested functions also requiring exec stack work fine though because they rely on the GNU_STACK segment spit out by compiler and handled in kernel elf loader. This glibc case is different as the stack is non exec to begin with and a dlopen of shared lib with GNU_STACK segment triggers the exec stack proceedings using a mprotect(PROT_EXEC) which was broken. CC: sta...@vger.kernel.org Signed-off-by: Vineet Gupta --- arch/arc/include/asm/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h index 109baa06831c..09f71cc5 100644 --- a/arch/arc/include/asm/page.h +++ b/arch/arc/include/asm/page.h @@ -105,7 +105,7 @@ typedef pte_t * pgtable_t; #define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr)) /* Default Permissions for stack/heaps pages (Non Executable) */ -#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE) +#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC) #define WANT_PAGE_VIRTUAL 1 -- 2.7.4 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
