logfs: destroy the reserved inodes while unmounting

We were assuming that the evict_inode() would never be called on
reserved inodes. However, (after the commit 8e22c1a4e logfs: get rid
of magical inodes) while unmounting the file system, in put_super, we
call iput() on all of the reserved inodes.

The following simple test used to cause a kernel panic on LogFS:

1. Mount a LogFS file system on /mnt

2. Create a file
   $ touch /mnt/a

3. Try to unmount the FS
   $ umount /mnt

The simple fix would be to drop the assumption and properly destroy
the reserved inodes.

Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
logfs: initialize the number of iovecs in bio

This fixes the following crash when a LogFS file system, created on a
encrypted LVM volume, was mounted

[  526.548034] BUG: unable to handle kernel NULL pointer dereference at
[  526.550106] IP: [<ffffffff8131ecab>] memcpy+0xb/0x120
[  526.551008] PGD bd60067 PUD 1778d067 PMD 0
[  526.551783] Oops: 0000 [#1] SMP

<d>Pid: 2043, comm: mount
<d>RIP: 0010:[<ffffffff8131ecab>]  [<ffffffff8131ecab>] memcpy+0xb/0x120
Call Trace:
	kcryptd_io_read+0xdb/0x100
	crypt_map+0xfd/0x190
	__map_bio+0x48/0x150
	__split_and_process_bio+0x51b/0x630
	dm_request+0x138/0x230
	generic_make_request+0xca/0x100
	submit_bio+0x87/0x110
	sync_request+0xdd/0x120 [logfs]
	bdev_readpage+0x2e/0x70 [logfs]
	do_read_cache_page+0x82/0x180
	logfs_mount+0x2ad/0x770 [logfs]
	mount_fs+0x47/0x1c0
	vfs_kern_mount+0x72/0x110
	do_kern_mount+0x54/0x110
	do_mount+0x520/0x7f0
	sys_mount+0x90/0xe0

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42292
Reported-by: Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
logfs: create a pagecache page if it is not present

While writing the partial journal entries we assumed that the page
associated with the journal would always in locatable. This incorrect
assumption resulted in the following BUG

kernel BUG at /home/benixon/WD_SMR/kernels/linux-3.3.7-logfs/fs/logfs/journal.c:569!
EIP is at logfs_write_area+0xb6/0x109 [logfs]
EAX: 00000000 EBX: 00000000 ECX: ef6efea4 EDX: 00000000
ESI: 001b9000 EDI: f009e000 EBP: c3c13f14 ESP: c3c13ef0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process sync (pid: 1799, ti=c3c12000 task=f07825b0 task.ti=c3c12000)
Stack:
01001000 c3c13f26 781b9000 00000000 f009e000 f7286000 f1f83400 f8445071
f1f83400 c3c13f30 f8445ae9 c3c13f20 0000100a 000ee000 f009e000 00000001
c3c13f5c f8445d17 c05eb0ee 00000000 f1f83400 ef718000 f009e25c ea9c3d80
Call Trace:
[<f8445071>] ? account_shadow+0x16d/0x16d [logfs]
[<f8445ae9>] logfs_write_je+0x2a/0x44 [logfs]
[<f8445d17>] logfs_write_anchor+0x114/0x228 [logfs]
[<c05eb0ee>] ? empty+0x5/0x5
[<f8444522>] logfs_sync_fs+0x1e/0x31 [logfs]
[<c051be66>] __sync_filesystem+0x5d/0x6f
[<c051be8d>] sync_one_sb+0x15/0x17
[<c04ff8b0>] iterate_supers+0x59/0x9a
[<c051be78>] ? __sync_filesystem+0x6f/0x6f
[<c051befc>] sys_sync+0x29/0x4f
[<c084285f>] sysenter_do_call+0x12/0x28
EIP: [<f8445127>] logfs_write_area+0xb6/0x109 [logfs] SS:ESP 0068:c3c13ef0
---[ end trace ef6e9ef52601a945 ]---

The fix is to create the pagecache page if it is not locatable.

Reported-and-tested-by: Benixon Dhas <Benixon.Dhas@wdc.com>
Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
logfs: maintain the ordering of meta-inode destruction

LogFS does not use a specialized area to maintain the inodes. The
inodes information is kept in a specialized file called inode file.
Similarly, the segment information is kept in a segment file. Since
the segment file also has an inode which is kept in the inode file,
the inode for segment file must be evicted before the inode for inode
file. The change fixes the following BUG during unmount

Pid: 2057, comm: umount Not tainted 3.5.0-rc6+ #25 Bochs Bochs
RIP: 0010:[<ffffffffa005c5f2>]  [<ffffffffa005c5f2>] move_page_to_btree+0x32/0x1f0 [logfs]
Process umount (pid: 2057, threadinfo ...)
Call Trace:
[<ffffffff8112adca>] ? find_get_pages+0x2a/0x180
[<ffffffffa00549f5>] logfs_invalidatepage+0x85/0x90 [logfs]
[<ffffffff81136c51>] truncate_inode_page+0xb1/0xd0
[<ffffffff81136dcf>] truncate_inode_pages_range+0x15f/0x490
[<ffffffff81558549>] ? printk+0x78/0x7a
[<ffffffff81137185>] truncate_inode_pages+0x15/0x20
[<ffffffffa005b7fc>] logfs_evict_inode+0x6c/0x190 [logfs]
[<ffffffff8155c75b>] ? _raw_spin_unlock+0x2b/0x40
[<ffffffff8119e3d7>] evict+0xa7/0x1b0
[<ffffffff8119ea6e>] dispose_list+0x3e/0x60
[<ffffffff8119f1c4>] evict_inodes+0xf4/0x110
[<ffffffff81185b53>] generic_shutdown_super+0x53/0xf0
[<ffffffffa005d8f2>] logfs_kill_sb+0x52/0xf0 [logfs]
[<ffffffff81185ec5>] deactivate_locked_super+0x45/0x80
[<ffffffff81186a4a>] deactivate_super+0x4a/0x70
[<ffffffff811a228e>] mntput_no_expire+0xde/0x140
[<ffffffff811a30ff>] sys_umount+0x6f/0x3a0
[<ffffffff8155d8e9>] system_call_fastpath+0x16/0x1b
---[ end trace 45f7752082cefafd ]---

Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
logfs: query block device for number of pages to send with bio

The block device driver puts a limit on maximum number of pages that
can be sent with the bio. Not all block devices can handle
BIO_MAX_PAGES number of pages in bio. Specifically the virtio-blk
diriver limits it to 126. When the LogFS file system was excersized in
KVM, the following bug from do_virtblk_request() was observed

static void do_virtblk_request(struct request_queue *q)
{
	....
	....
	while ((req = blk_peek_request(q)) != NULL) {
		BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems);
		....
		....
	}
	....
}

The patch fixes the problem by querring the maximum number of pages in
bio allowed from block device driver and then using those many pages
during submit_bio.

Signed-off-by: Prasad Joshi <prasadjoshi.linux@gmail.com>
block: reorganize rounding of max_discard_sectors

Mostly a preparation for the next patch.

In principle this fixes an infinite loop if max_discard_sectors < granularity,
but that really shouldn't happen.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Tested-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: split discard into aligned requests

When a disk has large discard_granularity and small max_discard_sectors,
discards are not split with optimal alignment.  In the limit case of
discard_granularity == max_discard_sectors, no request could be aligned
correctly, so in fact you might end up with no discarded logical blocks
at all.

Another example that helps showing the condition in the patch is with
discard_granularity == 64, max_discard_sectors == 128.  A request that is
submitted for 256 sectors 2..257 will be split in two: 2..129, 130..257.
However, only 2 aligned blocks out of 3 are included in the request;
128..191 may be left intact and not discarded.  With this patch, the
first request will be truncated to ensure good alignment of what's left,
and the split will be 2..127, 128..255, 256..257.  The patch will also
take into account the discard_alignment.

At most one extra request will be introduced, because the first request
will be reduced by at most granularity-1 sectors, and granularity
must be less than max_discard_sectors.  Subsequent requests will run
on round_down(max_discard_sectors, granularity) sectors, as in the
current code.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Tested-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
fs/block-dev.c:fix performance regression in O_DIRECT writes to md block devices

For regular file, write operaion used blk_plug function.But for block
file,write operation did not use blk_plug.
This patch is also for write-cache mode for block-device.

Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Reviewed-by: NeilBrown <neilb@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: Introduce __blk_segment_map_sg() helper

Split the mapping code in blk_rq_map_sg() to a helper
__blk_segment_map_sg(), so that other mapping function, e.g.
blk_bio_map_sg(), can share the code.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Shaohua Li <shli@kernel.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Suggested-by: Jens Axboe <axboe@kernel.dk>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: Add blk_bio_map_sg() helper

Add a helper to map a bio to a scatterlist, modelled after
blk_rq_map_sg.

This helper is useful for any driver that wants to create
a scatterlist from its ->make_request_fn method.

Changes in v2:
 - Use __blk_segment_map_sg to avoid duplicated code
 - Add cocbook style function comment

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Tejun Heo <tj@kernel.org>
Cc: Shaohua Li <shli@kernel.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block: Don't use static to define "void *p" in show_partition_start()

I met a odd prblem:read /proc/partitions may return zero.

I wrote a file test.c:
int main()
{
	char buff[4096];
	int ret;
	int fd;
	printf("pid=%d\n",getpid());
	while (1) {
		fd = open("/proc/partitions", O_RDONLY);
		if (fd < 0) {
			printf("open error %s\n", strerror(errno));
			return 0;
		}
		ret = read(fd, buff, 4096);
		if (ret <= 0)
			printf("ret=%d, %s, %ld\n", ret,
				strerror(errno), lseek(fd,0,SEEK_CUR));
		close(fd);
	}
	exit(0);
}

You can reproduce by:
1:while true;do cat /proc/partitions > /dev/null ;done
2:./test

I reviewed the code and found:

>> static void *show_partition_start(struct seq_file *seqf, loff_t *pos)
>> {
>> 	static void *p;
>>
>> 	p = disk_seqf_start(seqf, pos);
>> 	if (!IS_ERR_OR_NULL(p) && !*pos)
>> 		seq_puts(seqf, "major minor  #blocks  name\n\n");
>> 	return p;
>> }
		test								cat /proc/partitions
	p = disk_seqf_start()(Not NULL)
									p = disk_seqf_start()(NULL because pos)
	if (!IS_ERR_OR_NULL(p) && !*pos)

Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
powerpc/fsl-pci: Only scan PCI bus if configured as a host

We change fsl_add_bridge to return -ENODEV if the controller is working in
agent mode. Then check the return value of fsl_add_bridge to guarantee
that only successfully added host bus will be scanned.

Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
KVM: x86: update KVM_SAVE_MSRS_BEGIN to correct value

When MSR_KVM_PV_EOI_EN was added to msrs_to_save array
KVM_SAVE_MSRS_BEGIN was not updated accordingly.

Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Revert "ARM: OMAP3530evm: set pendown_state and debounce time for ads7846"

1) The above commit introduced a common ->get_pendown_state() function
into the generic code, but that function was board-specific for the
OMAP3EVM and thus broke most other boards using this code.

2) The above commit was mis-merged introducing another bug which
prevents the ads7846 driver probe function to succeed.
The omap_ads7846_init() function frees the pendown GPIO in case there is
no ->get_pendown_state() function set by the caller (board specific
code), so it can be requested later by the ads7846 driver.
The above commit add a common ->get_pendown_state() function without
removing the gpio_free() call and thus once the ads7846 driver tries
to use the pendown GPIO, it crashes as the pendown GPIO has not been
requested.

3) The above commit introduces NO new functionality as
get_pendown_state() function is already implemented in a suitable way by
the ads7846 driver and the debounce time handling has already been
fixed by commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code).

This reverts commit 16aced80f6739beb2a6ff7b6f96c83ba80d331e8.

Conflicts:
	arch/arm/mach-omap2/common-board-devices.c

Solved by taking the working version prior to the above commit.

Cc: Zumeng Chen <zumeng.chen@windriver.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
ARM: OMAP3: igep0020: set GPIO mode for mux mcspi1_cs2 pin

According to the IGEPv2 Rev.C data-sheet the LAN9221i pin 14 (IRQ) is
connected to the OMAP3730 mcspi1_cs2 pin. Since this omap mux pin acts
as an IRQ line, it has to be configured as an input GPIO.

IGEPv2 platform code sets the smsc911x_cfg->gpio_irq to GPIO 176 but
since the mux pin default mode is MODE7 (safe_mode) the driver fails
when trying to register the IRQ with the following error message:

[    1.994598] smsc911x: Driver version 2008-10-21
[    3.704162] irq 272: nobody cared (try booting with the "irqpoll" option)
[    3.711364] [<c001a114>] (unwind_backtrace+0x0/0xf0) from [<c009a0d4>] (__report_bad_irq+0x20/0xbc)
[    3.720916] [<c009a0d4>] (__report_bad_irq+0x20/0xbc) from [<c009a41c>] (note_interrupt+0x1d8/0x238)
[    3.730560] [<c009a41c>] (note_interrupt+0x1d8/0x238) from [<c0098234>] (handle_irq_event_percpu+0xc0/0x260)
[    3.740936] [<c0098234>] (handle_irq_event_percpu+0xc0/0x260) from [<c0098410>] (handle_irq_event+0x3c/0x5c)
[    3.751312] [<c0098410>] (handle_irq_event+0x3c/0x5c) from [<c009abe0>] (handle_level_irq+0xac/0x10c)
[    3.761047] [<c009abe0>] (handle_level_irq+0xac/0x10c) from [<c0097a34>] (generic_handle_irq+0x30/0x48)
[    3.770935] [<c0097a34>] (generic_handle_irq+0x30/0x48) from [<c02a6b74>] (gpio_irq_handler+0x180/0x1d4)
[    3.780944] [<c02a6b74>] (gpio_irq_handler+0x180/0x1d4) from [<c0097a34>] (generic_handle_irq+0x30/0x48)
[    3.790954] [<c0097a34>] (generic_handle_irq+0x30/0x48) from [<c0013e18>] (handle_IRQ+0x4c/0xac)
[    3.800231] [<c0013e18>] (handle_IRQ+0x4c/0xac) from [<c000858c>] (omap3_intc_handle_irq+0x60/0x74)
[    3.809783] [<c000858c>] (omap3_intc_handle_irq+0x60/0x74) from [<c04979e4>] (__irq_svc+0x44/0x60)
[    3.819213] Exception stack(0xee42fde0 to 0xee42fe28)
[    3.824554] fde0: 00000001 00000001 00000000 00000000 60000013 c06cce14 c06cce14 00000110
[    3.833190] fe00: 00000000 c06ccdf4 60000013 ee41d000 fb058064 ee42fe28 c0089e08 c04976b4
[    3.841796] fe20: 20000013 ffffffff
[    3.845489] [<c04979e4>] (__irq_svc+0x44/0x60) from [<c04976b4>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[    3.855499] [<c04976b4>] (_raw_spin_unlock_irqrestore+0x34/0x44) from [<c0099744>] (__setup_irq+0x1b8/0x3f0)
[    3.865875] [<c0099744>] (__setup_irq+0x1b8/0x3f0) from [<c0099a34>] (request_threaded_irq+0xb8/0x140)
[    3.875701] [<c0099a34>] (request_threaded_irq+0xb8/0x140) from [<c0487950>] (smsc911x_drv_probe+0x75c/0x11a4)
[    3.886260] [<c0487950>] (smsc911x_drv_probe+0x75c/0x11a4) from [<c02e9bcc>] (platform_drv_probe+0x18/0x1c)
[    3.906707] [<c02e89b8>] (driver_probe_device+0x90/0x210) from [<c02e8bcc>] (__driver_attach+0x94/0x98)
[    3.916625] [<c02e8bcc>] (__driver_attach+0x94/0x98) from [<c02e7298>] (bus_for_each_dev+0x50/0x7c)
[    3.926177] [<c02e7298>] (bus_for_each_dev+0x50/0x7c) from [<c02e81d4>] (bus_add_driver+0x184/0x248)
[    3.935821] [<c02e81d4>] (bus_add_driver+0x184/0x248) from [<c02e909c>] (driver_register+0x78/0x12c)
[    3.945465] [<c02e909c>] (driver_register+0x78/0x12c) from [<c0008648>] (do_one_initcall+0x34/0x178)
[    3.955108] [<c0008648>] (do_one_initcall+0x34/0x178) from [<c066e8f4>] (kernel_init+0xfc/0x1c0)
[    3.964385] [<c066e8f4>] (kernel_init+0xfc/0x1c0) from [<c00140b0>] (kernel_thread_exit+0x0/0x8)
[    3.973632] handlers:
[    3.976043] [<c034e2cc>] smsc911x_irqhandler
[    3.980560] Disabling IRQ #272

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Acked-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arm/dts: Fix am33xx wdt node

Add am33xx wdt node.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
[tony@atomide.com: I messed up and produced an empty commit db27ac80 with stg apply]
Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP2+: Fix random config build break with !ARM_CPU_SUSPEND

The random config builds with PM and !ARM_CPU_SUSPEND breaks with below
error on omap2plus_defconfig.

arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume'
arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend'

This is because recently merged OMAP5 platform shares the common files
with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND
the sleep code is meaningless.

Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from
Russell King in an off-list discussion.

Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Kevin Hilman <khilman@ti.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
arm/dts: Mark vcxio, v2v1 and v1v8 regulators as always on

vcxio, v2v1 and v1v8 are expected to be always on, update the dtsi
for twl6030 to reflect this.

commit '86f5fc' regulator: core: Mark all DT based boards as having
full constraints) caused these to be disabled at late boot causing
OMAP4 boards (using twl6030) to lockup.

Reported-by: Kishon Vijay Abraham I <kishon@ti.com>
Reported-by: J Keerthy <j-keerthy@ti.com>
Signed-off-by: Rajendra nayak <rnayak@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Merge branch 'for_3.6/fixes/ads7846-2' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into fixes
OMAP: remove unused parameter arch_id from uncompress.h

There is not point in having arch_id as parameter of __arch_decomp_setup(),
nothing in it uses arch_id. The machine id is already exported (and used)
with symbol __machine_arch_type as per mach-types.h.

Removing the pointless macro as well.

Signed-off-by: Domenico Andreoli <domenico.andreoli@linux.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>