1. 02 5月, 2013 23 次提交
  2. 21 4月, 2013 1 次提交
  3. 20 4月, 2013 1 次提交
    • D
      irda: small read past the end of array in debug code · e15465e1
      Dan Carpenter 提交于
      The "reason" can come from skb->data[] and it hasn't been capped so it
      can be from 0-255 instead of just 0-6.  For example in irlmp_state_dtr()
      the code does:
      
      	reason = skb->data[3];
      	...
      	irlmp_disconnect_indication(self, reason, skb);
      
      Also LMREASON has a couple other values which don't have entries in the
      irlmp_reasons[] array.  And 0xff is a valid reason as well which means
      "unknown".
      
      So far as I can see we don't actually care about "reason" except for in
      the debug code.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e15465e1
  4. 19 4月, 2013 1 次提交
  5. 18 4月, 2013 2 次提交
  6. 17 4月, 2013 2 次提交
    • M
      fuse: fix type definitions in uapi header · 4c82456e
      Miklos Szeredi 提交于
      Commit 7e98d530 (Synchronize fuse header with
      one used in library) added #ifdef __linux__ around defines if it is not set.
      The kernel build is self-contained and can be built on non-Linux toolchains.
      After the mentioned commit builds on non-Linux toolchains will try to include
      stdint.h and fail due to -nostdinc, and then fail with a bunch of undefined type
      errors.
      
      Fix by checking for __KERNEL__ instead of __linux__ and using the standard int
      types instead of the linux specific ones.
      Reported-by: NArve Hjønnevåg <arve@android.com>
      Reported-by: NColin Cross <ccross@android.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      4c82456e
    • L
      vm: add vm_iomap_memory() helper function · b4cbb197
      Linus Torvalds 提交于
      Various drivers end up replicating the code to mmap() their memory
      buffers into user space, and our core memory remapping function may be
      very flexible but it is unnecessarily complicated for the common cases
      to use.
      
      Our internal VM uses pfn's ("page frame numbers") which simplifies
      things for the VM, and allows us to pass physical addresses around in a
      denser and more efficient format than passing a "phys_addr_t" around,
      and having to shift it up and down by the page size.  But it just means
      that drivers end up doing that shifting instead at the interface level.
      
      It also means that drivers end up mucking around with internal VM things
      like the vma details (vm_pgoff, vm_start/end) way more than they really
      need to.
      
      So this just exports a function to map a certain physical memory range
      into user space (using a phys_addr_t based interface that is much more
      natural for a driver) and hides all the complexity from the driver.
      Some drivers will still end up tweaking the vm_page_prot details for
      things like prefetching or cacheability etc, but that's actually
      relevant to the driver, rather than caring about what the page offset of
      the mapping is into the particular IO memory region.
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b4cbb197
  7. 16 4月, 2013 1 次提交
  8. 15 4月, 2013 2 次提交
  9. 13 4月, 2013 3 次提交
    • D
      x86-32: Fix possible incomplete TLB invalidate with PAE pagetables · 1de14c3c
      Dave Hansen 提交于
      This patch attempts to fix:
      
      	https://bugzilla.kernel.org/show_bug.cgi?id=56461
      
      The symptom is a crash and messages like this:
      
      	chrome: Corrupted page table at address 34a03000
      	*pdpt = 0000000000000000 *pde = 0000000000000000
      	Bad pagetable: 000f [#1] PREEMPT SMP
      
      Ingo guesses this got introduced by commit 611ae8e3 ("x86/tlb:
      enable tlb flush range support for x86") since that code started to free
      unused pagetables.
      
      On x86-32 PAE kernels, that new code has the potential to free an entire
      PMD page and will clear one of the four page-directory-pointer-table
      (aka pgd_t entries).
      
      The hardware aggressively "caches" these top-level entries and invlpg
      does not actually affect the CPU's copy.  If we clear one we *HAVE* to
      do a full TLB flush, otherwise we might continue using a freed pmd page.
      (note, we do this properly on the population side in pud_populate()).
      
      This patch tracks whenever we clear one of these entries in the 'struct
      mmu_gather', and ensures that we follow up with a full tlb flush.
      
      BTW, I disassembled and checked that:
      
      	if (tlb->fullmm == 0)
      and
      	if (!tlb->fullmm && !tlb->need_flush_all)
      
      generate essentially the same code, so there should be zero impact there
      to the !PAE case.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Artem S Tashkinov <t.artem@mailcity.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1de14c3c
    • S
      ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section · 7f49ef69
      Steven Rostedt (Red Hat) 提交于
      As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
      be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
      ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.
      
      Cc: stable@vger.kernel.org
      Cc: Namhyung Kim <namhyung@kernel.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      7f49ef69
    • N
      tracing: Fix possible NULL pointer dereferences · 6a76f8c0
      Namhyung Kim 提交于
      Currently set_ftrace_pid and set_graph_function files use seq_lseek
      for their fops.  However seq_open() is called only for FMODE_READ in
      the fops->open() so that if an user tries to seek one of those file
      when she open it for writing, it sees NULL seq_file and then panic.
      
      It can be easily reproduced with following command:
      
        $ cd /sys/kernel/debug/tracing
        $ echo 1234 | sudo tee -a set_ftrace_pid
      
      In this example, GNU coreutils' tee opens the file with fopen(, "a")
      and then the fopen() internally calls lseek().
      
      Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      6a76f8c0
  10. 12 4月, 2013 1 次提交
    • T
      kthread: Prevent unpark race which puts threads on the wrong cpu · f2530dc7
      Thomas Gleixner 提交于
      The smpboot threads rely on the park/unpark mechanism which binds per
      cpu threads on a particular core. Though the functionality is racy:
      
      CPU0	       	 	CPU1  	     	    CPU2
      unpark(T)				    wake_up_process(T)
        clear(SHOULD_PARK)	T runs
      			leave parkme() due to !SHOULD_PARK  
        bind_to(CPU2)		BUG_ON(wrong CPU)						    
      
      We cannot let the tasks move themself to the target CPU as one of
      those tasks is actually the migration thread itself, which requires
      that it starts running on the target cpu right away.
      
      The solution to this problem is to prevent wakeups in park mode which
      are not from unpark(). That way we can guarantee that the association
      of the task to the target cpu is working correctly.
      
      Add a new task state (TASK_PARKED) which prevents other wakeups and
      use this state explicitly for the unpark wakeup.
      
      Peter noticed: Also, since the task state is visible to userspace and
      all the parked tasks are still in the PID space, its a good hint in ps
      and friends that these tasks aren't really there for the moment.
      
      The migration thread has another related issue.
      
      CPU0	      	     	 CPU1
      Bring up CPU2
      create_thread(T)
      park(T)
       wait_for_completion()
      			 parkme()
      			 complete()
      sched_set_stop_task()
      			 schedule(TASK_PARKED)
      
      The sched_set_stop_task() call is issued while the task is on the
      runqueue of CPU1 and that confuses the hell out of the stop_task class
      on that cpu. So we need the same synchronizaion before
      sched_set_stop_task().
      Reported-by: NDave Jones <davej@redhat.com>
      Reported-and-tested-by: NDave Hansen <dave@sr71.net>
      Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
      Acked-by: NPeter Ziljstra <peterz@infradead.org>
      Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Cc: dhillf@gmail.com
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304091635430.21884@ionosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      f2530dc7
  11. 11 4月, 2013 1 次提交
  12. 10 4月, 2013 2 次提交