noarg: $(MAKE) -C ../../ # The EBB handler is 64-bit code and everything links against it CFLAGS += -m64 TEST_PROGS := reg_access_test event_attributes_test cycles_test \ cycles_with_freeze_test pmc56_overflow_test \ ebb_vs_cpu_event_test cpu_event_vs_ebb_test \ cpu_event_pinned_vs_ebb_test task_event_vs_ebb_test \ task_event_pinned_vs_ebb_test multi_ebb_procs_test \ multi_counter_test pmae_handling_test \ close_clears_pmcc_test instruction_count_test \ fork_cleanup_test ebb_on_child_test \ ebb_on_willing_child_test back_to_back_ebbs_test \ lost_exception_test no_handler_test \ cycles_with_mmcr2_test all: $(TEST_PROGS) $(TEST_PROGS): ../../harness.c ../../utils.c ../event.c ../lib.c \ ebb.c ebb_handler.S trace.c busy_loop.S instruction_count_test: ../loop.S lost_exception_test: ../lib.c include ../../../lib.mk clean: rm -f $(TEST_PROGS) ='form'>
net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/net/caif/cfcnfg.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2017-01-30 14:28:22 -0800
committerDavid S. Miller <davem@davemloft.net>2017-01-30 14:28:22 -0800
commit54791b276b4000b307339f269d3bf7db877d536f (patch)
tree1c2616bd373ce5ea28aac2a53e32f5b5834901ce /net/caif/cfcnfg.c
parent5d0e7705774dd412a465896d08d59a81a345c1e4 (diff)
parent047487241ff59374fded8c477f21453681f5995c (diff)
Merge branch 'sparc64-non-resumable-user-error-recovery'
Liam R. Howlett says: ==================== sparc64: Recover from userspace non-resumable PIO & MEM errors A non-resumable error from userspace is able to cause a kernel panic or trap loop due to the setup and handling of the queued traps once in the kernel. This patch series addresses both of these issues. The queues are fixed by simply zeroing the memory before use. PIO errors from userspace will result in a SIGBUS being sent to the user process. The MEM errors form userspace will result in a SIGKILL and also cause the offending pages to be claimed so they are no longer used in future tasks. SIGKILL is used to ensure that the process does not try to coredump and result in an attempt to read the memory again from within kernel space. Although there is a HV call to scrub the memory (mem_scrub), there is no easy way to guarantee that the real memory address(es) are not used by other tasks. Clearing the error with mem_scrub would zero the memory and cause the other processes to proceed with bad data. The handling of other non-resumable errors remain unchanged and will cause a panic. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/caif/cfcnfg.c')