1. 21 5月, 2014 5 次提交
  2. 14 5月, 2014 1 次提交
  3. 08 5月, 2014 2 次提交
  4. 07 5月, 2014 3 次提交
    • C
      slub: use sysfs'es release mechanism for kmem_cache · 41a21285
      Christoph Lameter 提交于
      debugobjects warning during netfilter exit:
      
          ------------[ cut here ]------------
          WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
          ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x20
          Modules linked in:
          CPU: 6 PID: 4178 Comm: kworker/u16:2 Tainted: G        W 3.11.0-next-20130906-sasha #3984
          Workqueue: netns cleanup_net
          Call Trace:
            dump_stack+0x52/0x87
            warn_slowpath_common+0x8c/0xc0
            warn_slowpath_fmt+0x46/0x50
            debug_print_object+0x8d/0xb0
            __debug_check_no_obj_freed+0xa5/0x220
            debug_check_no_obj_freed+0x15/0x20
            kmem_cache_free+0x197/0x340
            kmem_cache_destroy+0x86/0xe0
            nf_conntrack_cleanup_net_list+0x131/0x170
            nf_conntrack_pernet_exit+0x5d/0x70
            ops_exit_list+0x5e/0x70
            cleanup_net+0xfb/0x1c0
            process_one_work+0x338/0x550
            worker_thread+0x215/0x350
            kthread+0xe7/0xf0
            ret_from_fork+0x7c/0xb0
      
      Also during dcookie cleanup:
      
          WARNING: CPU: 12 PID: 9725 at lib/debugobjects.c:260 debug_print_object+0x8c/0xb0()
          ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x20
          Modules linked in:
          CPU: 12 PID: 9725 Comm: trinity-c141 Not tainted 3.15.0-rc2-next-20140423-sasha-00018-gc4ff6c4 #408
          Call Trace:
            dump_stack (lib/dump_stack.c:52)
            warn_slowpath_common (kernel/panic.c:430)
            warn_slowpath_fmt (kernel/panic.c:445)
            debug_print_object (lib/debugobjects.c:262)
            __debug_check_no_obj_freed (lib/debugobjects.c:697)
            debug_check_no_obj_freed (lib/debugobjects.c:726)
            kmem_cache_free (mm/slub.c:2689 mm/slub.c:2717)
            kmem_cache_destroy (mm/slab_common.c:363)
            dcookie_unregister (fs/dcookies.c:302 fs/dcookies.c:343)
            event_buffer_release (arch/x86/oprofile/../../../drivers/oprofile/event_buffer.c:153)
            __fput (fs/file_table.c:217)
            ____fput (fs/file_table.c:253)
            task_work_run (kernel/task_work.c:125 (discriminator 1))
            do_notify_resume (include/linux/tracehook.h:196 arch/x86/kernel/signal.c:751)
            int_signal (arch/x86/kernel/entry_64.S:807)
      
      Sysfs has a release mechanism.  Use that to release the kmem_cache
      structure if CONFIG_SYSFS is enabled.
      
      Only slub is changed - slab currently only supports /proc/slabinfo and
      not /sys/kernel/slab/*.  We talked about adding that and someone was
      working on it.
      
      [akpm@linux-foundation.org: fix CONFIG_SYSFS=n build]
      [akpm@linux-foundation.org: fix CONFIG_SYSFS=n build even more]
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Tested-by: NSasha Levin <sasha.levin@oracle.com>
      Acked-by: NGreg KH <greg@kroah.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Bart Van Assche <bvanassche@acm.org>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      41a21285
    • N
      hugetlb: ensure hugepage access is denied if hugepages are not supported · 457c1b27
      Nishanth Aravamudan 提交于
      Currently, I am seeing the following when I `mount -t hugetlbfs /none
      /dev/hugetlbfs`, and then simply do a `ls /dev/hugetlbfs`.  I think it's
      related to the fact that hugetlbfs is properly not correctly setting
      itself up in this state?:
      
        Unable to handle kernel paging request for data at address 0x00000031
        Faulting instruction address: 0xc000000000245710
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2048 NUMA pSeries
        ....
      
      In KVM guests on Power, in a guest not backed by hugepages, we see the
      following:
      
        AnonHugePages:         0 kB
        HugePages_Total:       0
        HugePages_Free:        0
        HugePages_Rsvd:        0
        HugePages_Surp:        0
        Hugepagesize:         64 kB
      
      HPAGE_SHIFT == 0 in this configuration, which indicates that hugepages
      are not supported at boot-time, but this is only checked in
      hugetlb_init().  Extract the check to a helper function, and use it in a
      few relevant places.
      
      This does make hugetlbfs not supported (not registered at all) in this
      environment.  I believe this is fine, as there are no valid hugepages
      and that won't change at runtime.
      
      [akpm@linux-foundation.org: use pr_info(), per Mel]
      [akpm@linux-foundation.org: fix build when HPAGE_SHIFT is undefined]
      Signed-off-by: NNishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      457c1b27
    • A
      nick kvfree() from apparmor · 39f1f78d
      Al Viro 提交于
      too many places open-code it
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      39f1f78d
  5. 06 5月, 2014 3 次提交
  6. 04 5月, 2014 2 次提交
  7. 01 5月, 2014 2 次提交
    • H
      word-at-a-time: simplify big-endian zero_bytemask macro · 789ce9dc
      H. Peter Anvin 提交于
      This is simpler and cleaner.  Depending on architecture, a smart
      compiler may or may not generate the same code.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      789ce9dc
    • A
      dentry_kill(): don't try to remove from shrink list · 41edf278
      Al Viro 提交于
      If the victim in on the shrink list, don't remove it from there.
      If shrink_dentry_list() manages to remove it from the list before
      we are done - fine, we'll just free it as usual.  If not - mark
      it with new flag (DCACHE_MAY_FREE) and leave it there.
      
      Eventually, shrink_dentry_list() will get to it, remove the sucker
      from shrink list and call dentry_kill(dentry, 0).  Which is where
      we'll deal with freeing.
      
      Since now dentry_kill(dentry, 0) may happen after or during
      dentry_kill(dentry, 1), we need to recognize that (by seeing
      DCACHE_DENTRY_KILLED already set), unlock everything
      and either free the sucker (in case DCACHE_MAY_FREE has been
      set) or leave it for ongoing dentry_kill(dentry, 1) to deal with.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      41edf278
  8. 30 4月, 2014 9 次提交
  9. 28 4月, 2014 7 次提交
    • M
      fuse: add renameat2 support · 1560c974
      Miklos Szeredi 提交于
      Support RENAME_EXCHANGE and RENAME_NOREPLACE flags on the userspace ABI.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      1560c974
    • S
      ftrace/module: Hardcode ftrace_module_init() call into load_module() · a949ae56
      Steven Rostedt (Red Hat) 提交于
      A race exists between module loading and enabling of function tracer.
      
      	CPU 1				CPU 2
      	-----				-----
        load_module()
         module->state = MODULE_STATE_COMING
      
      				register_ftrace_function()
      				 mutex_lock(&ftrace_lock);
      				 ftrace_startup()
      				  update_ftrace_function();
      				   ftrace_arch_code_modify_prepare()
      				    set_all_module_text_rw();
      				   <enables-ftrace>
      				    ftrace_arch_code_modify_post_process()
      				     set_all_module_text_ro();
      
      				[ here all module text is set to RO,
      				  including the module that is
      				  loading!! ]
      
         blocking_notifier_call_chain(MODULE_STATE_COMING);
          ftrace_init_module()
      
           [ tries to modify code, but it's RO, and fails!
             ftrace_bug() is called]
      
      When this race happens, ftrace_bug() will produces a nasty warning and
      all of the function tracing features will be disabled until reboot.
      
      The simple solution is to treate module load the same way the core
      kernel is treated at boot. To hardcode the ftrace function modification
      of converting calls to mcount into nops. This is done in init/main.c
      there's no reason it could not be done in load_module(). This gives
      a better control of the changes and doesn't tie the state of the
      module to its notifiers as much. Ftrace is special, it needs to be
      treated as such.
      
      The reason this would work, is that the ftrace_module_init() would be
      called while the module is in MODULE_STATE_UNFORMED, which is ignored
      by the set_all_module_text_ro() call.
      
      Link: http://lkml.kernel.org/r/1395637826-3312-1-git-send-email-indou.takao@jp.fujitsu.comReported-by: NTakao Indoh <indou.takao@jp.fujitsu.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: stable@vger.kernel.org # 2.6.38+
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      a949ae56
    • M
      fuse: allow ctime flushing to userspace · ab9e13f7
      Maxim Patlasov 提交于
      The patch extends fuse_setattr_in, and extends the flush procedure
      (fuse_flush_times()) called on ->write_inode() to send the ctime as well as
      mtime.
      Signed-off-by: NMaxim Patlasov <MPatlasov@parallels.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      ab9e13f7
    • M
      fuse: fuse: add time_gran to INIT_OUT · e27c9d38
      Miklos Szeredi 提交于
      Allow userspace fs to specify time granularity.
      
      This is needed because with writeback_cache mode the kernel is responsible
      for generating mtime and ctime, but if the underlying filesystem doesn't
      support nanosecond granularity then the cache will contain a different
      value from the one stored on the filesystem resulting in a change of times
      after a cache flush.
      
      Make the default granularity 1s.
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      e27c9d38
    • T
      genirq: x86: Ensure that dynamic irq allocation does not conflict · 62a08ae2
      Thomas Gleixner 提交于
      On x86 the allocation of irq descriptors may allocate interrupts which
      are in the range of the GSI interrupts. That's wrong as those
      interrupts are hardwired and we don't have the irq domain translation
      like PPC. So one of these interrupts can be hooked up later to one of
      the devices which are hard wired to it and the io_apic init code for
      that particular interrupt line happily reuses that descriptor with a
      completely different configuration so hell breaks lose.
      
      Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
      except for a few usage sites which have not yet blown up in our face
      for whatever reason. But for drivers which need an irq range, like the
      GPIO drivers, we have no limit in place and we don't want to expose
      such a detail to a driver.
      
      To cure this introduce a function which an architecture can implement
      to impose a lower bound on the dynamic interrupt allocations.
      
      Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
      the end of the hardwired interrupt space, so all dynamic allocations
      happen above.
      
      That not only allows the GPIO driver to work sanely, it also protects
      the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
      htirq code. They need to be cleaned up as well, but that's a separate
      issue.
      Reported-by: NJin Yao <yao.jin@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Krogerus Heikki <heikki.krogerus@intel.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1404241617360.28206@ionos.tec.linutronix.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      62a08ae2
    • R
      linux/interrupt.h: fix new kernel-doc warnings · def5f127
      Randy Dunlap 提交于
      Fix new kernel-doc warnings in <linux/interrupt.h>:
      
      Warning(include/linux/interrupt.h:219): No description found for parameter 'cpumask'
      Warning(include/linux/interrupt.h:219): Excess function parameter 'mask' description in 'irq_set_affinity'
      Warning(include/linux/interrupt.h:236): No description found for parameter 'cpumask'
      Warning(include/linux/interrupt.h:236): Excess function parameter 'mask' description in 'irq_force_affinity'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Link: http://lkml.kernel.org/r/535DD2FD.7030804@infradead.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      def5f127
    • W
      word-at-a-time: avoid undefined behaviour in zero_bytemask macro · ec6931b2
      Will Deacon 提交于
      The asm-generic, big-endian version of zero_bytemask creates a mask of
      bytes preceding the first zero-byte by left shifting ~0ul based on the
      position of the first zero byte.
      
      Unfortunately, if the first (top) byte is zero, the output of
      prep_zero_mask has only the top bit set, resulting in undefined C
      behaviour as we shift left by an amount equal to the width of the type.
      As it happens, GCC doesn't manage to spot this through the call to fls(),
      but the issue remains if architectures choose to implement their shift
      instructions differently.
      
      An example would be arch/arm/ (AArch32), where LSL Rd, Rn, #32 results
      in Rd == 0x0, whilst on arch/arm64 (AArch64) LSL Xd, Xn, #64 results in
      Xd == Xn.
      
      Rather than check explicitly for the problematic shift, this patch adds
      an extra shift by 1, replacing fls with __fls. Since zero_bytemask is
      never called with a zero argument (has_zero() is used to check the data
      first), we don't need to worry about calling __fls(0), which is
      undefined.
      
      Cc: <stable@vger.kernel.org>
      Cc: Victor Kamensky <victor.kamensky@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ec6931b2
  10. 26 4月, 2014 1 次提交
    • J
      serial: sc16is7xx · dfeae619
      Jon Ringle 提交于
      The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel
      high performance UART. The SC16IS7xx's internal register set is
      backward-compatible with the widely used and widely popular 16C450.
      
      The SC16IS7xx also provides additional advanced features such as
      auto hardware and software flow control, automatic RS-485 support, and
      software reset.
      Signed-off-by: NJon Ringle <jringle@gridpoint.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfeae619
  11. 25 4月, 2014 5 次提交
    • R
      tty/serial: add generic serial earlycon · 9aac5887
      Rob Herring 提交于
      This introduces generic earlycon infrastructure for serial devices
      based on the 8250 earlycon. This allows for supporting earlycon option
      with other serial devices. The earlycon output is enabled at the time
      early_params are processed.
      
      Only architectures that have fixmap support or have functional ioremap
      when early_params are processed are supported. This is the same
      restriction that the 8250 driver had.
      Signed-off-by: NRob Herring <robh@kernel.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9aac5887
    • J
      tty: serial: Add driver for MEN's 16z135 High Speed UART. · e264ebf4
      Johannes Thumshirn 提交于
      Add driver for MEN's 16z135 High Speed UART.
      
      The 16z135 is a memory mapped UART Core on an MCB FPGA and has 1024 byte
      deep FIFO buffers for the RX and TX path. It also has configurable FIFO
      fill level IRQs and data copied to and from the hardware has to be
      acknowledged.
      Signed-off-by: NJohannes Thumshirn <johannes.thumshirn@men.de>
      Reviewed-by: NAlan Cox <gnomes@lxorguk.ukuu.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e264ebf4
    • S
      tty: xuartps: Rebrand driver as Cadence UART · d9bb3fb1
      Soren Brinkmann 提交于
      Zynq's UART is Cadence IP. Make this visible in the prompt in kconfig
      and additional comments in the driver.
      This also renames functions and symbols, as far as possible without
      breaking user space API, to reflect the Cadence origin. This is achieved
      through simple search and replace:
       - s/XUARTPS/CDNS_UART/g
       - s/xuartps/cdns_uart/g
      The only exceptions are PORT_XUARTPS and the driver name, which stay as is,
      due to their exposure to user space. As well as the - no legacy -
      compatibility string 'xlnx,xuartps'
      Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com>
      Tested-by: NMichal Simek <michal.simek@xilinx.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9bb3fb1
    • F
      serial: fix UART_IIR_ID · bd5dc09f
      Felipe Balbi 提交于
      UART IRQ Identification bitfield is 3
      bits long (bits 3:1) but current mask only
      masks 2 bits. Fix it.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bd5dc09f
    • H
      tty_ldisc: add more limits to the @write_wakeup · 879eb9c3
      Huang Shijie 提交于
      In the uart_handle_cts_change(), uart_write_wakeup() is called after
      we call @uart_port->ops->start_tx().
      
      The Documentation/serial/driver tells us:
      -----------------------------------------------
        start_tx(port)
      	Start transmitting characters.
      
      	Locking: port->lock taken.
      	Interrupts: locally disabled.
      -----------------------------------------------
      
      So when the uart_write_wakeup() is called, the port->lock is taken by
      the upper. See the following callstack:
      
      	|_ uart_write_wakeup
      	   |_ tty_wakeup
      	      |_ ld->ops->write_wakeup
      
      With the port->lock held, we call the @write_wakeup. Some implemetation of
      the @write_wakeup does not notice that the port->lock is held, and it still
      tries to send data with uart_write() which will try to grab the prot->lock.
      A dead lock occurs, see the following log caught in the Bluetooth by uart:
      
      --------------------------------------------------------------------
      BUG: spinlock lockup suspected on CPU#0, swapper/0/0
       lock: 0xdc3f4410, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W    3.10.17-16839-ge4a1bef #1320
      [<80014cbc>] (unwind_backtrace+0x0/0x138) from [<8001251c>] (show_stack+0x10/0x14)
      [<8001251c>] (show_stack+0x10/0x14) from [<802816ac>] (do_raw_spin_lock+0x108/0x184)
      [<802816ac>] (do_raw_spin_lock+0x108/0x184) from [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60)
      [<806a22b0>] (_raw_spin_lock_irqsave+0x54/0x60) from [<802f5754>] (uart_write+0x38/0xe0)
      [<802f5754>] (uart_write+0x38/0xe0) from [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168)
      [<80455270>] (hci_uart_tx_wakeup+0xa4/0x168) from [<802dab18>] (tty_wakeup+0x50/0x5c)
      [<802dab18>] (tty_wakeup+0x50/0x5c) from [<802f81a4>] (imx_rtsint+0x50/0x80)
      [<802f81a4>] (imx_rtsint+0x50/0x80) from [<802f88f4>] (imx_int+0x158/0x17c)
      [<802f88f4>] (imx_int+0x158/0x17c) from [<8007abe0>] (handle_irq_event_percpu+0x50/0x194)
      [<8007abe0>] (handle_irq_event_percpu+0x50/0x194) from [<8007ad60>] (handle_irq_event+0x3c/0x5c)
      --------------------------------------------------------------------
      
      This patch adds more limits to the @write_wakeup, the one who wants to
      implemet the @write_wakeup should follow the limits which avoid the deadlock.
      Signed-off-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      879eb9c3