Commit Graph

533784 Commits

Author SHA1 Message Date
Jan Kara c8962f4be4 ext4: Improve ext4 Kconfig test
Now that ext4 driver must be used to access ext3 filesystems, improve
the Kconfig help text to better explain that using ext4 driver to access
the filesystem is fully compatible with the old ext3 driver.

Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:40 +02:00
Jan Kara a3ad0a9da8 block: Remove forced page bouncing under IO
JBD layer wrote back data buffers without setting PageWriteback bit.
Thus standard mechanism for guaranteeing stable pages under IO did not
work. Since JBD is gone now and there is no other user of the
functionality, just remove it.

Acked-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jan Kara <jack@suse.cz>
2015-07-23 20:59:40 +02:00
Jan Kara c290ea01ab fs: Remove ext3 filesystem driver
The functionality of ext3 is fully supported by ext4 driver. Major
distributions (SUSE, RedHat) already use ext4 driver to handle ext3
filesystems for quite some time. There is some ugliness in mm resulting
from jbd cleaning buffers in a dirty page without cleaning page dirty
bit and also support for buffer bouncing in the block layer when stable
pages are required is there only because of jbd. So let's remove the
ext3 driver. This saves us some 28k lines of duplicated code.

Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
2015-07-23 20:59:40 +02:00
Jan Kara 82ff50b222 doc: Update doc about journalling layer
Documentation of journalling layer in
Documentation/DocBook/filesystems.tmpl speaks about JBD layer. Since
that is going away, update the documentation to speak about JBD2. Also
update the parts that have changed since someone last touched the
document and remove some parts which are just misleading and outdated.

Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:39 +02:00
Dave Kleikamp acc84b05b1 jfs: Handle error from dquot_initialize()
dquot_initialize() can now return error. Handle it where possible

Slightly modified by Dave Kleikamp due to needed jfs_rename() error path
fix.

Signed-off-by: Jan Kara <jack@suse.com>
Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com>
2015-07-23 20:59:39 +02:00
Jan Kara 2e6c97ea4c reiserfs: Handle error from dquot_initialize()
dquot_initialize() can now return error. Handle it where possible.

Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:38 +02:00
Jan Kara 9c89fe0af8 ocfs2: Handle error from dquot_initialize()
dquot_initialize() can now return error. Handle it where possible.

Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:38 +02:00
Jan Kara a7cdadee0e ext4: Handle error from dquot_initialize()
dquot_initialize() can now return error. Handle it where possible.

Acked-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:37 +02:00
Jan Kara c2edb305d6 ext2: Handle error from dquot_initalize()
dquot_initialize() can now return error. Handle it where possible.

Signed-off-by: Jan Kara <jack@suse.com>
2015-07-23 20:59:37 +02:00
Jan Kara 6184fc0b8d quota: Propagate error from ->acquire_dquot()
Currently when some error happened in ->acquire_dquot(), dqget() just
returned NULL. That was indistinguishable from a case when e.g. someone
run quotaoff and so was generally silently ignored. However
->acquire_dquot() can fail because of ENOSPC or EIO in which case user
should better know. So propagate error up from ->acquire_dquot properly.

Signed-off-by: Jan Kara <jack@suse.cz>
2015-07-23 20:59:10 +02:00
Linus Torvalds d725e66c06 Revert "fsnotify: fix oops in fsnotify_clear_marks_by_group_flags()"
This reverts commit a2673b6e04.

Kinglong Mee reports a memory leak with that patch, and Jan Kara confirms:

 "Thanks for report! You are right that my patch introduces a race
  between fsnotify kthread and fsnotify_destroy_group() which can result
  in leaking inotify event on group destruction.

  I haven't yet decided whether the right fix is not to queue events for
  dying notification group (as that is pointless anyway) or whether we
  should just fix the original problem differently...  Whenever I look
  at fsnotify code mark handling I get lost in the maze of locks, lists,
  and subtle differences between how different notification systems
  handle notification marks :( I'll think about it over night"

and after thinking about it, Jan says:

 "OK, I have looked into the code some more and I found another
  relatively simple way of fixing the original oops.  It will be IMHO
  better than trying to fixup this issue which has more potential for
  breakage.  I'll ask Linus to revert the fsnotify fix he already merged
  and send a new fix"

Reported-by: Kinglong Mee <kinglongmee@gmail.com>
Requested-by: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-07-21 16:06:53 -07:00
Linus Torvalds 71ebd1af09 Merge tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
 "Here are some overly ripe pin control fixes for the v4.2 series.

  They got delayed because of various crap commits and having to clean
  and rinse the patch stack a few times.  Now they are however looking
  good.

   - some dead defines dropped from the Samsung driver, was targeted for
     -rc2 but got delayed
   - drop the strict mode from abx500, this was too strict
   - fix the R-Car sparse IRQs code to work as intended
   - fix the IRQ code for the pinctrl-single GPIO backend to not enforce
     threaded IRQs
   - clear the latched events/IRQs for the Broadcom BCM2835 driver
   - fix up debugfs for the Freescale imx1 driver
   - fix a typo bug in the Schmitt Trigger setup in the LPC18xx driver"

* tag 'pinctrl-v4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: lpc18xx: fix schmitt trigger setup
  Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback
  pinctrl: bcm2835: Clear the event latch register when disabling interrupts
  pinctrl: single: ensure pcs irq will not be forced threaded
  sh-pfc: fix sparse GPIOs for R-Car SoCs
  pinctrl: abx500: remove strict mode
  pinctrl: samsung: Remove old unused defines
2015-07-21 15:27:27 -07:00
Linus Torvalds 8426fb302c Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
Pull UDF fix from Jan Kara:
 "A fix for UDF corruption when certain disk-format feature is enabled"

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  udf: Don't corrupt unalloc spacetable when writing it
2015-07-21 15:18:06 -07:00
Linus Torvalds 1ad474de93 Merge tag 'trace-v4.2-rc2-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing sample code fix from Steven Rostedt:
 "He Kuang noticed that the sample code using the trace_event helper
  function __get_dynamic_array_len() is broken.

  This only changes the sample code, and I'm pushing this now instead of
  later because I don't want others using the broken code as an example
  when using it for real"

* tag 'trace-v4.2-rc2-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Fix sample output of dynamic arrays
2015-07-21 14:42:40 -07:00
Linus Torvalds 9d634c410b Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fix from Martin Schwidefsky:
 "Fast path fix for the thread_struct breakage"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: adapt entry.S to the move of thread_struct
2015-07-20 12:18:40 -07:00
Linus Torvalds d7f430d450 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32
Pull AVR32 update from Hans-Christian Egtvedt.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32:
  AVR32/time: Migrate to new 'set-state' interface
2015-07-20 12:17:55 -07:00
Martin Schwidefsky 3827ec3d8f s390: adapt entry.S to the move of thread_struct
git commit 0c8c0f03e3
"x86/fpu, sched: Dynamically allocate 'struct fpu'"
moved the thread_struct to the end of the task_struct.

This causes some of the offsets used in entry.S to overflow their
instruction operand field. To fix this  use aghi to create a
dedicated pointer for the thread_struct.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-07-20 13:22:18 +02:00
Viresh Kumar 09adcdf212 AVR32/time: Migrate to new 'set-state' interface
Migrate avr32 driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.

This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.

We want to call cpu_idle_poll_ctrl() in shutdown only if we were in
oneshot or resume state earlier. Create another variable to save this
information and check that in shutdown callback.

Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
2015-07-20 12:19:10 +02:00
Joachim Eastwood 681ccdcc75 pinctrl: lpc18xx: fix schmitt trigger setup
The param_val variable is what determines if schmitt
trigger is enabled on a pin or not. A typo here mean
that schmitt trigger was always enabled for standard
and i2c pins.

Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:53 +02:00
Uwe Kleine-König 9571b25df1 Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callback
imx1_pinconf_set assumes that the array of pins in struct
imx1_pinctrl_soc_info can be indexed by pin id to get the
pinctrl_pin_desc for a pin. This used to be correct up to commit
607af165c0 which removed some entries from the array and so made it
wrong to access the array by pin id.

The result of this bug is a wrong pin name in the output for small pin
ids and an oops for the bigger ones.

This patch is the result of a discussion that includes patches by Markus
Pargmann and Chris Ruehl.

Fixes: 607af165c0 ("pinctrl: i.MX27: Remove nonexistent pad definitions")
Cc: stable@vger.kernel.org
Reported-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Markus Pargmann <mpa@pengutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:53 +02:00
Jonathan Bell 714b1dd8f7 pinctrl: bcm2835: Clear the event latch register when disabling interrupts
It's possible to hit a race condition if interrupts are generated on a GPIO
pin when the IRQ line in question is being disabled.

If the interrupt is freed, bcm2835_gpio_irq_disable() is called which
disables the event generation sources (edge, level). If an event occurred
between the last disabling of hard IRQs and the write to the event
source registers, a bit would be set in the GPIO event detect register
(GPEDSn) which goes unacknowledged by bcm2835_gpio_irq_handler()
so Linux complains loudly.

There is no per-GPIO mask register, so when disabling GPIO interrupts
write 1 to the relevant bit in GPEDSn to clear out any stale events.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:52 +02:00
Grygorii Strashko c10372e615 pinctrl: single: ensure pcs irq will not be forced threaded
The PSC IRQ is requested using request_irq() API and as result it can
be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ
is enabled for pinctrl domain.

As result, following 'possible irq lock inversion dependency' report
can be seen:
=========================================================
[ INFO: possible irq lock inversion dependency detected ]
3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted
---------------------------------------------------------
irq/369-pinctrl/927 just changed the state of lock:
 (&pcs->lock){+.....}, at: [<c0375b54>] pcs_irq_handle+0x48/0x9c
but this lock was taken by another, HARDIRQ-safe lock in the past:
 (&irq_desc_lock_class){-.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&pcs->lock);
                               local_irq_disable();
                               lock(&irq_desc_lock_class);
                               lock(&pcs->lock);
  <Interrupt>
    lock(&irq_desc_lock_class);

 *** DEADLOCK ***

no locks held by irq/369-pinctrl/927.

the shortest dependencies between 2nd lock and 1st lock:
  -> (&irq_desc_lock_class){-.....} ops: 58724 {
     IN-HARDIRQ-W at:
                       [<c0090040>] lock_acquire+0x9c/0x158
                       [<c07065c8>] _raw_spin_lock+0x48/0x58
                       [<c009edac>] handle_fasteoi_irq+0x24/0x15c
                       [<c009abb0>] generic_handle_irq+0x3c/0x4c
                       [<c000f83c>] handle_IRQ+0x50/0xa0
                       [<c0008674>] gic_handle_irq+0x3c/0x6c
                       [<c0707a04>] __irq_svc+0x44/0x8c
                       [<c000fc44>] arch_cpu_idle+0x40/0x4c
                       [<c009aadc>] cpu_startup_entry+0x270/0x2e0
                       [<c06fcbf8>] rest_init+0xd4/0xe4
                       [<c0a44bfc>] start_kernel+0x3d0/0x3dc
                       [<80008084>] 0x80008084
     INITIAL USE at:
                      [<c0090040>] lock_acquire+0x9c/0x158
                      [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
                      [<c009aff8>] __irq_get_desc_lock+0x64/0xa4
                      [<c009e38c>] irq_set_chip+0x30/0x78
                      [<c009ec30>] irq_set_chip_and_handler_name+0x24/0x3c
                      [<c036ca10>] gic_irq_domain_map+0x48/0xb4
                      [<c00a0a80>] irq_domain_associate+0x84/0x1d4
                      [<c00a1154>] irq_create_mapping+0x80/0x11c
                      [<c00a1270>] irq_create_of_mapping+0x80/0x120
                      [<c05cdaa8>] irq_of_parse_and_map+0x34/0x3c
                      [<c0a4ea24>] omap_dm_timer_init_one+0x90/0x30c
                      [<c0a4eef0>] omap5_realtime_timer_init+0x8c/0x48c
                      [<c0a486b0>] time_init+0x28/0x38
                      [<c0a44a6c>] start_kernel+0x240/0x3dc
                      [<80008084>] 0x80008084
   }
   ... key      at: [<c1049ce0>] irq_desc_lock_class+0x0/0x8
   ... acquired at:
   [<c07065c8>] _raw_spin_lock+0x48/0x58
   [<c0375a90>] pcs_irq_unmask+0x58/0xa0
   [<c009ea48>] irq_enable+0x38/0x48
   [<c009ead0>] irq_startup+0x78/0x7c
   [<c009d440>] __setup_irq+0x4a8/0x4f4
   [<c009d5dc>] request_threaded_irq+0xb8/0x138
   [<c0415a5c>] omap_8250_startup+0x4c/0x148
   [<c041276c>] serial8250_startup+0x24/0x30
   [<c040d0ec>] uart_startup.part.9+0x5c/0x1b4
   [<c040dbcc>] uart_open+0xf4/0x16c
   [<c03f0540>] tty_open+0x170/0x61c
   [<c0157028>] chrdev_open+0xbc/0x1b4
   [<c0150494>] do_dentry_open+0x1e8/0x2bc
   [<c0150a84>] finish_open+0x44/0x5c
   [<c0160d50>] do_last.isra.47+0x710/0xca0
   [<c01613a4>] path_openat+0xc4/0x640
   [<c0162904>] do_filp_open+0x3c/0x98
   [<c0151bdc>] do_sys_open+0x114/0x1d8
   [<c0151cc8>] SyS_open+0x28/0x2c
   [<c0a44d70>] kernel_init_freeable+0x168/0x1e4
   [<c06fcc24>] kernel_init+0x1c/0xf8
   [<c000eee8>] ret_from_fork+0x14/0x20

-> (&pcs->lock){+.....} ops: 65 {
   HARDIRQ-ON-W at:
                    [<c0090040>] lock_acquire+0x9c/0x158
                    [<c07065c8>] _raw_spin_lock+0x48/0x58
                    [<c0375b54>] pcs_irq_handle+0x48/0x9c
                    [<c0375c5c>] pcs_irq_handler+0x1c/0x28
                    [<c009c458>] irq_forced_thread_fn+0x30/0x74
                    [<c009c784>] irq_thread+0x158/0x1c4
                    [<c0063fc4>] kthread+0xd4/0xe8
                    [<c000eee8>] ret_from_fork+0x14/0x20
   INITIAL USE at:
                   [<c0090040>] lock_acquire+0x9c/0x158
                   [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68
                   [<c0375344>] pcs_enable+0x7c/0xe8
                   [<c0372a44>] pinmux_enable_setting+0x178/0x220
                   [<c036fecc>] pinctrl_select_state+0x110/0x194
                   [<c04732dc>] pinctrl_bind_pins+0x7c/0x108
                   [<c045853c>] driver_probe_device+0x70/0x254
                   [<c0458810>] __driver_attach+0x9c/0xa0
                   [<c045674c>] bus_for_each_dev+0x78/0xac
                   [<c0458030>] driver_attach+0x2c/0x30
                   [<c0457c78>] bus_add_driver+0x15c/0x204
                   [<c0458ee0>] driver_register+0x88/0x108
                   [<c045a168>] __platform_driver_register+0x64/0x6c
                   [<c0a8170c>] omap_hsmmc_driver_init+0x1c/0x20
                   [<c0008a94>] do_one_initcall+0x110/0x170
                   [<c0a44d48>] kernel_init_freeable+0x140/0x1e4
                   [<c06fcc24>] kernel_init+0x1c/0xf8
                   [<c000eee8>] ret_from_fork+0x14/0x20
 }
 ... key      at: [<c1088a8c>] __key.18572+0x0/0x8
 ... acquired at:
   [<c008cdd4>] mark_lock+0x388/0x76c
   [<c008df40>] __lock_acquire+0x6d0/0x1f98
   [<c0090040>] lock_acquire+0x9c/0x158
   [<c07065c8>] _raw_spin_lock+0x48/0x58
   [<c0375b54>] pcs_irq_handle+0x48/0x9c
   [<c0375c5c>] pcs_irq_handler+0x1c/0x28
   [<c009c458>] irq_forced_thread_fn+0x30/0x74
   [<c009c784>] irq_thread+0x158/0x1c4
   [<c0063fc4>] kthread+0xd4/0xe8
   [<c000eee8>] ret_from_fork+0x14/0x20

stack backtrace:
CPU: 1 PID: 927 Comm: irq/369-pinctrl Not tainted 3.14.43-rt42-00360-g96ff499-dirty #24
[<c00177e0>] (unwind_backtrace) from [<c00130b0>] (show_stack+0x20/0x24)
[<c00130b0>] (show_stack) from [<c0702958>] (dump_stack+0x84/0xd0)
[<c0702958>] (dump_stack) from [<c008bcfc>] (print_irq_inversion_bug+0x1d0/0x21c)
[<c008bcfc>] (print_irq_inversion_bug) from [<c008bf18>] (check_usage_backwards+0xb4/0x11c)
[<c008bf18>] (check_usage_backwards) from [<c008cdd4>] (mark_lock+0x388/0x76c)
[<c008cdd4>] (mark_lock) from [<c008df40>] (__lock_acquire+0x6d0/0x1f98)
[<c008df40>] (__lock_acquire) from [<c0090040>] (lock_acquire+0x9c/0x158)
[<c0090040>] (lock_acquire) from [<c07065c8>] (_raw_spin_lock+0x48/0x58)
[<c07065c8>] (_raw_spin_lock) from [<c0375b54>] (pcs_irq_handle+0x48/0x9c)
[<c0375b54>] (pcs_irq_handle) from [<c0375c5c>] (pcs_irq_handler+0x1c/0x28)
[<c0375c5c>] (pcs_irq_handler) from [<c009c458>] (irq_forced_thread_fn+0x30/0x74)
[<c009c458>] (irq_forced_thread_fn) from [<c009c784>] (irq_thread+0x158/0x1c4)
[<c009c784>] (irq_thread) from [<c0063fc4>] (kthread+0xd4/0xe8)
[<c0063fc4>] (kthread) from [<c000eee8>] (ret_from_fork+0x14/0x20)

To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced threaded.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:52 +02:00
Sergei Shtylyov 61bb3aef92 sh-pfc: fix sparse GPIOs for R-Car SoCs
The PFC driver causes the kernel to hang on the R-Car gen2 SoC based  boards
when the CPU_ALL_PORT() macro is fixed to reflect the reality, i.e. when the
GPIO space becomes actually sparse.  This happens because the _GP_GPIO() macro
includes  an indexed initializer which causes the "holes" (array entries filled
with all 0s) between the groups  of the existing GPIOs; and the driver can't
cope with that.  There seems to  be no reason to use the indexed initializer,
so we can remove the index specifier and so avoid the "holes".

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:52 +02:00
Linus Walleij 27aa2e3a3c pinctrl: abx500: remove strict mode
Commit a21763a0b1
"pinctrl: nomadik: activate strict mux mode"
put all Nomadik pin controllers to strict mode. This was
not good on the Snowball platform: the muxing of GPIOs to
different pins is done with hogs in the DTS file, and then
these GPIOs are used by offset, relying on hogs to mux the
pins. Since that means the pin controller "owns" the pins
and at the same time we have a GPIO user, this pin controller
is by definition not strict.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-07-20 11:01:51 +02:00
Linus Torvalds 52721d9d33 Linux 4.2-rc3 2015-07-19 14:45:02 -07:00