2013-07-19 05:21:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 00/38] 3.9.11-stable review

---------------
Note, this is the LAST 3.9-stable kernel release that I will be doing.
Please move to the 3.10-stable branch as soon as possible.
---------------

This is the start of the stable review cycle for the 3.9.11 release.
There are 38 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 3.9.11-rc1

Steve French <[email protected]>
Handle big endianness in NTLM (ntlmv2) authentication

Wanpeng Li <[email protected]>
mm/memory-hotplug: fix lowmem count overflow when offline pages

Michal Hocko <[email protected]>
memcg, kmem: fix reference count handling on the error path

Bartlomiej Zolnierkiewicz <[email protected]>
drivers/dma/pl330.c: fix locking in pl330_free_chan_resources()

Theodore Ts'o <[email protected]>
ext4: don't allow ext4_free_blocks() to fail due to ENOMEM

Jan Kara <[email protected]>
ext4: fix overflow when counting used blocks on 32-bit architectures

Jan Kara <[email protected]>
ext4: fix data offset overflow in ext4_xattr_fiemap() on 32-bit archs

Jan Kara <[email protected]>
ext4: fix overflows in SEEK_HOLE, SEEK_DATA implementations

Jan Kara <[email protected]>
ext4: fix data offset overflow on 32-bit archs in ext4_inline_data_fiemap()

Josef Bacik <[email protected]>
Btrfs: only do the tree_mod_log_free_eb if this is our last ref

Josef Bacik <[email protected]>
Btrfs: fix estale with btrfs send

Bart Van Assche <[email protected]>
timer: Fix jiffies wrap behavior of round_jiffies_common()

Shane Huang <[email protected]>
ahci: remove pmp link online check in FBS EH

Jiang Liu <[email protected]>
PCI: Fix refcount issue in pci_create_root_bus() error recovery path

Xudong Hao <[email protected]>
PCI: Finish SR-IOV VF setup before adding the device

Paul Clements <[email protected]>
nbd: correct disconnect behavior

Junxiao Bi <[email protected]>
ocfs2: xattr: fix inlined xattr reflink

Rafael J. Wysocki <[email protected]>
ACPI / PM: Fix corner case in acpi_bus_update_power()

Lv Zheng <[email protected]>
ACPICA: Do not use extended sleep registers unless HW-reduced bit is set

Lan Tianyu <[email protected]>
ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan

Axel Lin <[email protected]>
drivers/rtc/rtc-rv3029c2.c: fix disabling AIE irq

Ben Hutchings <[email protected]>
genirq: Fix can_request_irq() for IRQs without an action

Konrad Rzeszutek Wilk <[email protected]>
xen/pcifront: Deal with toolstack missing 'XenbusStateClosing' state.

Laszlo Ersek <[email protected]>
xen/time: remove blocked time accounting from xen "clockchip"

Li Zefan <[email protected]>
cgroup: fix umount vs cgroup_event_remove() race

Joachim Eastwood <[email protected]>
pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status

Jason Wang <[email protected]>
drivers: hv: switch to use mb() instead of smp_mb()

George Cherian <[email protected]>
usb: host: xhci-plat: release mem region while removing module

Mathias Nyman <[email protected]>
xhci: check for failed dma pool allocation

UCHINO Satoshi <[email protected]>
usb: gadget: f_mass_storage: add missing memory barrier for thread_wakeup_needed

Al Viro <[email protected]>
ext3,ext4: don't mess with dir_file->f_pos in htree_dirblock_to_tree()

Maarten ter Huurne <[email protected]>
ext4: fix corruption when online resizing a fs with 1K block size

Theodore Ts'o <[email protected]>
jbd2: fix theoretical race in jbd2__journal_restart

Theodore Ts'o <[email protected]>
jbd2: move superblock checksum calculation to jbd2_write_superblock()

Larry Finger <[email protected]>
rtlwifi: rtl8192cu: Fix duplicate if test

Larry Finger <[email protected]>
rtlwifi: rtl8723ae: Fix typo in firmware names

Pavel Shilovsky <[email protected]>
CIFS: Fix a deadlock when a file is reopened

Steve French <[email protected]>
CIFS use sensible file nlink values if unprovided


-------------

Diffstat:

Makefile | 4 ++--
arch/x86/xen/time.c | 17 ++------------
drivers/acpi/acpica/hwxfsleep.c | 8 ++++---
drivers/acpi/device_pm.c | 23 ++++++++++++++-----
drivers/acpi/ec.c | 4 ++++
drivers/ata/libahci.c | 3 +--
drivers/block/nbd.c | 7 +++++-
drivers/dma/pl330.c | 4 ++--
drivers/hv/ring_buffer.c | 10 ++++-----
drivers/hv/vmbus_drv.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8723ae/sw.c | 6 ++---
drivers/pci/iov.c | 5 ++---
drivers/pci/probe.c | 14 +++++++-----
drivers/pci/xen-pcifront.c | 7 +++---
drivers/pcmcia/at91_cf.c | 4 ++--
drivers/rtc/rtc-rv3029c2.c | 2 +-
drivers/usb/gadget/f_mass_storage.c | 2 ++
drivers/usb/host/xhci-mem.c | 4 ++++
drivers/usb/host/xhci-plat.c | 1 +
fs/btrfs/ctree.c | 3 ++-
fs/btrfs/send.c | 35 +++++++++++++++++++++++++++++
fs/cifs/cifs_unicode.h | 8 +++----
fs/cifs/cifsencrypt.c | 6 ++---
fs/cifs/file.c | 9 ++++----
fs/cifs/inode.c | 5 +++++
fs/ext3/namei.c | 7 ++----
fs/ext4/extents.c | 4 ++--
fs/ext4/file.c | 14 ++++++------
fs/ext4/inline.c | 2 +-
fs/ext4/inode.c | 4 ++--
fs/ext4/mballoc.c | 11 ++++++---
fs/ext4/namei.c | 7 ++----
fs/ext4/resize.c | 4 +---
fs/jbd2/journal.c | 3 ++-
fs/jbd2/transaction.c | 2 +-
fs/ocfs2/xattr.c | 10 +++++++++
include/linux/nbd.h | 1 +
kernel/cgroup.c | 25 ++++++++++++++++-----
kernel/irq/manage.c | 6 ++---
kernel/timer.c | 8 ++++---
mm/memcontrol.c | 8 -------
mm/page_alloc.c | 4 ++++
43 files changed, 196 insertions(+), 119 deletions(-)


2013-07-19 05:21:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 10/38] xhci: check for failed dma pool allocation

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream.

Fail and free the container context in case dma_pool_alloc() can't allocate
the raw context data part of it

This patch should be backported to kernels as old as 2.6.31, that
contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci:
Support for 64-byte contexts".

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Sarah Sharp <[email protected]>
Cc: John Youn <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-mem.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -369,6 +369,10 @@ static struct xhci_container_ctx *xhci_a
ctx->size += CTX_SIZE(xhci->hcc_params);

ctx->bytes = dma_pool_alloc(xhci->device_pool, flags, &ctx->dma);
+ if (!ctx->bytes) {
+ kfree(ctx);
+ return NULL;
+ }
memset(ctx->bytes, 0, ctx->size);
return ctx;
}

2013-07-19 05:21:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 12/38] drivers: hv: switch to use mb() instead of smp_mb()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jason Wang <[email protected]>

commit 35848f68b07df3f917cb13fc3c134718669f569b upstream.

Even if guest were compiled without SMP support, it could not assume that host
wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for
UP guest.

Signed-off-by: Jason Wang <[email protected]>
Cc: Haiyang Zhang <[email protected]>
Signed-off-by: K. Y. Srinivasan <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/hv/ring_buffer.c | 10 +++++-----
drivers/hv/vmbus_drv.c | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -32,7 +32,7 @@
void hv_begin_read(struct hv_ring_buffer_info *rbi)
{
rbi->ring_buffer->interrupt_mask = 1;
- smp_mb();
+ mb();
}

u32 hv_end_read(struct hv_ring_buffer_info *rbi)
@@ -41,7 +41,7 @@ u32 hv_end_read(struct hv_ring_buffer_in
u32 write;

rbi->ring_buffer->interrupt_mask = 0;
- smp_mb();
+ mb();

/*
* Now check to see if the ring buffer is still empty.
@@ -71,7 +71,7 @@ u32 hv_end_read(struct hv_ring_buffer_in

static bool hv_need_to_signal(u32 old_write, struct hv_ring_buffer_info *rbi)
{
- smp_mb();
+ mb();
if (rbi->ring_buffer->interrupt_mask)
return false;

@@ -442,7 +442,7 @@ int hv_ringbuffer_write(struct hv_ring_b
sizeof(u64));

/* Issue a full memory barrier before updating the write index */
- smp_mb();
+ mb();

/* Now, update the write location */
hv_set_next_write_location(outring_info, next_write_location);
@@ -549,7 +549,7 @@ int hv_ringbuffer_read(struct hv_ring_bu
/* Make sure all reads are done before we update the read index since */
/* the writer may start writing to the read area once the read index */
/*is updated */
- smp_mb();
+ mb();

/* Update the read index */
hv_set_next_read_location(inring_info, next_read_location);
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -434,7 +434,7 @@ static void vmbus_on_msg_dpc(unsigned lo
* will not deliver any more messages since there is
* no empty slot
*/
- smp_mb();
+ mb();

if (msg->header.message_flags.msg_pending) {
/*

2013-07-19 05:22:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 15/38] xen/time: remove blocked time accounting from xen "clockchip"

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Laszlo Ersek <[email protected]>

commit 0b0c002c340e78173789f8afaa508070d838cf3d upstream.

... because the "clock_event_device framework" already accounts for idle
time through the "event_handler" function pointer in
xen_timer_interrupt().

The patch is intended as the completion of [1]. It should fix the double
idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to
stolen time accounting (the removed code seems to be isolated).

The approach may be completely misguided.

[1] https://lkml.org/lkml/2011/10/6/10
[2] http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01068.html

John took the time to retest this patch on top of v3.10 and reported:
"idle time is correctly incremented for pv and hvm for the normal
case, nohz=off and nohz=idle." so lets put this patch in.

Signed-off-by: Laszlo Ersek <[email protected]>
Signed-off-by: John Haxby <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/xen/time.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)

--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -36,9 +36,8 @@ static DEFINE_PER_CPU(struct vcpu_runsta
/* snapshots of runstate info */
static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate_snapshot);

-/* unused ns of stolen and blocked time */
+/* unused ns of stolen time */
static DEFINE_PER_CPU(u64, xen_residual_stolen);
-static DEFINE_PER_CPU(u64, xen_residual_blocked);

/* return an consistent snapshot of 64-bit time/counter value */
static u64 get64(const u64 *p)
@@ -115,7 +114,7 @@ static void do_stolen_accounting(void)
{
struct vcpu_runstate_info state;
struct vcpu_runstate_info *snap;
- s64 blocked, runnable, offline, stolen;
+ s64 runnable, offline, stolen;
cputime_t ticks;

get_runstate_snapshot(&state);
@@ -125,7 +124,6 @@ static void do_stolen_accounting(void)
snap = &__get_cpu_var(xen_runstate_snapshot);

/* work out how much time the VCPU has not been runn*ing* */
- blocked = state.time[RUNSTATE_blocked] - snap->time[RUNSTATE_blocked];
runnable = state.time[RUNSTATE_runnable] - snap->time[RUNSTATE_runnable];
offline = state.time[RUNSTATE_offline] - snap->time[RUNSTATE_offline];

@@ -141,17 +139,6 @@ static void do_stolen_accounting(void)
ticks = iter_div_u64_rem(stolen, NS_PER_TICK, &stolen);
__this_cpu_write(xen_residual_stolen, stolen);
account_steal_ticks(ticks);
-
- /* Add the appropriate number of ticks of blocked time,
- including any left-overs from last time. */
- blocked += __this_cpu_read(xen_residual_blocked);
-
- if (blocked < 0)
- blocked = 0;
-
- ticks = iter_div_u64_rem(blocked, NS_PER_TICK, &blocked);
- __this_cpu_write(xen_residual_blocked, blocked);
- account_idle_ticks(ticks);
}

/* Get the TSC speed from Xen */

2013-07-19 05:22:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 22/38] ocfs2: xattr: fix inlined xattr reflink

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Junxiao Bi <[email protected]>

commit ef962df057aaafd714f5c22ba3de1be459571fdf upstream.

Inlined xattr shared free space of inode block with inlined data or data
extent record, so the size of the later two should be adjusted when
inlined xattr is enabled. See ocfs2_xattr_ibody_init(). But this isn't
done well when reflink. For inode with inlined data, its max inlined
data size is adjusted in ocfs2_duplicate_inline_data(), no problem. But
for inode with data extent record, its record count isn't adjusted. Fix
it, or data extent record and inlined xattr may overwrite each other,
then cause data corruption or xattr failure.

One panic caused by this bug in our test environment is the following:

kernel BUG at fs/ocfs2/xattr.c:1435!
invalid opcode: 0000 [#1] SMP
Pid: 10871, comm: multi_reflink_t Not tainted 2.6.39-300.17.1.el5uek #1
RIP: ocfs2_xa_offset_pointer+0x17/0x20 [ocfs2]
RSP: e02b:ffff88007a587948 EFLAGS: 00010283
RAX: 0000000000000000 RBX: 0000000000000010 RCX: 00000000000051e4
RDX: ffff880057092060 RSI: 0000000000000f80 RDI: ffff88007a587a68
RBP: ffff88007a587948 R08: 00000000000062f4 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000010
R13: ffff88007a587a68 R14: 0000000000000001 R15: ffff88007a587c68
FS: 00007fccff7f06e0(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000015cf000 CR3: 000000007aa76000 CR4: 0000000000000660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process multi_reflink_t
Call Trace:
ocfs2_xa_reuse_entry+0x60/0x280 [ocfs2]
ocfs2_xa_prepare_entry+0x17e/0x2a0 [ocfs2]
ocfs2_xa_set+0xcc/0x250 [ocfs2]
ocfs2_xattr_ibody_set+0x98/0x230 [ocfs2]
__ocfs2_xattr_set_handle+0x4f/0x700 [ocfs2]
ocfs2_xattr_set+0x6c6/0x890 [ocfs2]
ocfs2_xattr_user_set+0x46/0x50 [ocfs2]
generic_setxattr+0x70/0x90
__vfs_setxattr_noperm+0x80/0x1a0
vfs_setxattr+0xa9/0xb0
setxattr+0xc3/0x120
sys_fsetxattr+0xa8/0xd0
system_call_fastpath+0x16/0x1b

Signed-off-by: Junxiao Bi <[email protected]>
Reviewed-by: Jie Liu <[email protected]>
Acked-by: Joel Becker <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Sunil Mushran <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ocfs2/xattr.c | 10 ++++++++++
1 file changed, 10 insertions(+)

--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -6499,6 +6499,16 @@ static int ocfs2_reflink_xattr_inline(st
}

new_oi = OCFS2_I(args->new_inode);
+ /*
+ * Adjust extent record count to reserve space for extended attribute.
+ * Inline data count had been adjusted in ocfs2_duplicate_inline_data().
+ */
+ if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) &&
+ !(ocfs2_inode_is_fast_symlink(args->new_inode))) {
+ struct ocfs2_extent_list *el = &new_di->id2.i_list;
+ le16_add_cpu(&el->l_count, -(inline_size /
+ sizeof(struct ocfs2_extent_rec)));
+ }
spin_lock(&new_oi->ip_lock);
new_oi->ip_dyn_features |= OCFS2_HAS_XATTR_FL | OCFS2_INLINE_XATTR_FL;
new_di->i_dyn_features = cpu_to_le16(new_oi->ip_dyn_features);

2013-07-19 05:22:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 33/38] ext4: fix overflow when counting used blocks on 32-bit architectures

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit 8af8eecc1331dbf5e8c662022272cf667e213da5 upstream.

The arithmetics adding delalloc blocks to the number of used blocks in
ext4_getattr() can easily overflow on 32-bit archs as we first multiply
number of blocks by blocksize and then divide back by 512. Make the
arithmetics more clever and also use proper type (unsigned long long
instead of unsigned long).

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4616,7 +4616,7 @@ int ext4_getattr(struct vfsmount *mnt, s
struct kstat *stat)
{
struct inode *inode;
- unsigned long delalloc_blocks;
+ unsigned long long delalloc_blocks;

inode = dentry->d_inode;
generic_fillattr(inode, stat);
@@ -4634,7 +4634,7 @@ int ext4_getattr(struct vfsmount *mnt, s
delalloc_blocks = EXT4_C2B(EXT4_SB(inode->i_sb),
EXT4_I(inode)->i_reserved_data_blocks);

- stat->blocks += (delalloc_blocks << inode->i_sb->s_blocksize_bits)>>9;
+ stat->blocks += delalloc_blocks << (inode->i_sb->s_blocksize_bits-9);
return 0;
}


2013-07-19 05:22:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 07/38] ext4: fix corruption when online resizing a fs with 1K block size

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Maarten ter Huurne <[email protected]>

commit 6ca792edc13c409e8d4eb9001e048264c6a2eb64 upstream.

Subtracting the number of the first data block places the superblock
backups one block too early, corrupting the file system. When the block
size is larger than 1K, the first data block is 0, so the subtraction
has no effect and no corruption occurs.

Signed-off-by: Maarten ter Huurne <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/resize.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)

--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -1656,12 +1656,10 @@ errout:
err = err2;

if (!err) {
- ext4_fsblk_t first_block;
- first_block = ext4_group_first_block_no(sb, 0);
if (test_opt(sb, DEBUG))
printk(KERN_DEBUG "EXT4-fs: extended group to %llu "
"blocks\n", ext4_blocks_count(es));
- update_backups(sb, EXT4_SB(sb)->s_sbh->b_blocknr - first_block,
+ update_backups(sb, EXT4_SB(sb)->s_sbh->b_blocknr,
(char *)es, sizeof(struct ext4_super_block), 0);
}
return err;

2013-07-19 05:22:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 06/38] jbd2: fix theoretical race in jbd2__journal_restart

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Theodore Ts'o <[email protected]>

commit 39c04153fda8c32e85b51c96eb5511a326ad7609 upstream.

Once we decrement transaction->t_updates, if this is the last handle
holding the transaction from closing, and once we release the
t_handle_lock spinlock, it's possible for the transaction to commit
and be released. In practice with normal kernels, this probably won't
happen, since the commit happens in a separate kernel thread and it's
unlikely this could all happen within the space of a few CPU cycles.

On the other hand, with a real-time kernel, this could potentially
happen, so save the tid found in transaction->t_tid before we release
t_handle_lock. It would require an insane configuration, such as one
where the jbd2 thread was set to a very high real-time priority,
perhaps because a high priority real-time thread is trying to read or
write to a file system. But some people who use real-time kernels
have been known to do insane things, including controlling
laser-wielding industrial robots. :-)

Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/jbd2/transaction.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -518,10 +518,10 @@ int jbd2__journal_restart(handle_t *hand
&transaction->t_outstanding_credits);
if (atomic_dec_and_test(&transaction->t_updates))
wake_up(&journal->j_wait_updates);
+ tid = transaction->t_tid;
spin_unlock(&transaction->t_handle_lock);

jbd_debug(2, "restarting handle %p\n", handle);
- tid = transaction->t_tid;
need_to_start = !tid_geq(journal->j_commit_request, tid);
read_unlock(&journal->j_state_lock);
if (need_to_start)

2013-07-19 05:22:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 05/38] jbd2: move superblock checksum calculation to jbd2_write_superblock()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Theodore Ts'o <[email protected]>

commit fe52d17cdd343ac43c85cf72940a58865b9d3bfb upstream.

Some of the functions which modify the jbd2 superblock were not
updating the checksum before calling jbd2_write_superblock(). Move
the call to jbd2_superblock_csum_set() to jbd2_write_superblock(), so
that the checksum is calculated consistently.

Signed-off-by: "Theodore Ts'o" <[email protected]>
Cc: Darrick J. Wong <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/jbd2/journal.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1320,6 +1320,7 @@ static int journal_reset(journal_t *jour
static void jbd2_write_superblock(journal_t *journal, int write_op)
{
struct buffer_head *bh = journal->j_sb_buffer;
+ journal_superblock_t *sb = journal->j_superblock;
int ret;

trace_jbd2_write_superblock(journal, write_op);
@@ -1341,6 +1342,7 @@ static void jbd2_write_superblock(journa
clear_buffer_write_io_error(bh);
set_buffer_uptodate(bh);
}
+ jbd2_superblock_csum_set(journal, sb);
get_bh(bh);
bh->b_end_io = end_buffer_write_sync;
ret = submit_bh(write_op, bh);
@@ -1437,7 +1439,6 @@ void jbd2_journal_update_sb_errno(journa
jbd_debug(1, "JBD2: updating superblock error (errno %d)\n",
journal->j_errno);
sb->s_errno = cpu_to_be32(journal->j_errno);
- jbd2_superblock_csum_set(journal, sb);
read_unlock(&journal->j_state_lock);

jbd2_write_superblock(journal, WRITE_SYNC);

2013-07-19 05:23:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 37/38] mm/memory-hotplug: fix lowmem count overflow when offline pages

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Wanpeng Li <[email protected]>

commit cea27eb2a202959783f81254c48c250ddd80e129 upstream.

The logic for the memory-remove code fails to correctly account the
Total High Memory when a memory block which contains High Memory is
offlined as shown in the example below. The following patch fixes it.

Before logic memory remove:

MemTotal: 7603740 kB
MemFree: 6329612 kB
Buffers: 94352 kB
Cached: 872008 kB
SwapCached: 0 kB
Active: 626932 kB
Inactive: 519216 kB
Active(anon): 180776 kB
Inactive(anon): 222944 kB
Active(file): 446156 kB
Inactive(file): 296272 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 7294672 kB
HighFree: 5704696 kB
LowTotal: 309068 kB
LowFree: 624916 kB

After logic memory remove:

MemTotal: 7079452 kB
MemFree: 5805976 kB
Buffers: 94372 kB
Cached: 872000 kB
SwapCached: 0 kB
Active: 626936 kB
Inactive: 519236 kB
Active(anon): 180780 kB
Inactive(anon): 222944 kB
Active(file): 446156 kB
Inactive(file): 296292 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 7294672 kB
HighFree: 5181024 kB
LowTotal: 4294752076 kB
LowFree: 624952 kB

[[email protected]: fix CONFIG_HIGHMEM=n build]
Signed-off-by: Wanpeng Li <[email protected]>
Reviewed-by: Michal Hocko <[email protected]>
Cc: KAMEZAWA Hiroyuki <[email protected]>
Cc: David Rientjes <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/page_alloc.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6078,6 +6078,10 @@ __offline_isolated_pages(unsigned long s
list_del(&page->lru);
rmv_page_order(page);
zone->free_area[order].nr_free--;
+#ifdef CONFIG_HIGHMEM
+ if (PageHighMem(page))
+ totalhigh_pages -= 1 << order;
+#endif
for (i = 0; i < (1 << order); i++)
SetPageReserved((page+i));
pfn += (1 << order);

2013-07-19 05:23:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 38/38] Handle big endianness in NTLM (ntlmv2) authentication

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit fdf96a907c1fbb93c633e2b7ede3b8df26d6a4c0 upstream.

This is RH bug 970891
Uppercasing of username during calculation of ntlmv2 hash fails
because UniStrupr function does not handle big endian wchars.

Also fix a comment in the same code to reflect its correct usage.

[To make it easier for stable (rather than require 2nd patch) fixed
this patch of Shirish's to remove endian warning generated
by sparse -- steve f.]

Reported-by: steve <[email protected]>
Signed-off-by: Shirish Pargaonkar <[email protected]>
Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/cifs_unicode.h | 8 ++++----
fs/cifs/cifsencrypt.c | 6 +++---
2 files changed, 7 insertions(+), 7 deletions(-)

--- a/fs/cifs/cifs_unicode.h
+++ b/fs/cifs/cifs_unicode.h
@@ -327,14 +327,14 @@ UniToupper(register wchar_t uc)
/*
* UniStrupr: Upper case a unicode string
*/
-static inline wchar_t *
-UniStrupr(register wchar_t *upin)
+static inline __le16 *
+UniStrupr(register __le16 *upin)
{
- register wchar_t *up;
+ register __le16 *up;

up = upin;
while (*up) { /* For all characters */
- *up = UniToupper(*up);
+ *up = cpu_to_le16(UniToupper(le16_to_cpu(*up)));
up++;
}
return upin; /* Return input pointer */
--- a/fs/cifs/cifsencrypt.c
+++ b/fs/cifs/cifsencrypt.c
@@ -415,7 +415,7 @@ static int calc_ntlmv2_hash(struct cifs_
int rc = 0;
int len;
char nt_hash[CIFS_NTHASH_SIZE];
- wchar_t *user;
+ __le16 *user;
wchar_t *domain;
wchar_t *server;

@@ -440,7 +440,7 @@ static int calc_ntlmv2_hash(struct cifs_
return rc;
}

- /* convert ses->user_name to unicode and uppercase */
+ /* convert ses->user_name to unicode */
len = ses->user_name ? strlen(ses->user_name) : 0;
user = kmalloc(2 + (len * 2), GFP_KERNEL);
if (user == NULL) {
@@ -450,7 +450,7 @@ static int calc_ntlmv2_hash(struct cifs_
}

if (len) {
- len = cifs_strtoUTF16((__le16 *)user, ses->user_name, len, nls_cp);
+ len = cifs_strtoUTF16(user, ses->user_name, len, nls_cp);
UniStrupr(user);
} else {
memset(user, '\0', 2);

2013-07-19 05:23:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 09/38] usb: gadget: f_mass_storage: add missing memory barrier for thread_wakeup_needed

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: UCHINO Satoshi <[email protected]>

commit d68c277b501889b3a50c179d1c3d704db7947b83 upstream.

Without this memory barrier, the file-storage thread may fail to
escape from the following while loop, because it may observe new
common->thread_wakeup_needed and old bh->state which are updated by
the callback functions.

/* Wait for the CBW to arrive */
while (bh->state != BUF_STATE_FULL) {
rc = sleep_thread(common);
if (rc)
return rc;
}

Signed-off-by: UCHINO Satoshi <[email protected]>
Acked-by: Michal Nazarewicz <[email protected]>
Signed-off-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/gadget/f_mass_storage.c | 2 ++
1 file changed, 2 insertions(+)

--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -413,6 +413,7 @@ static int fsg_set_halt(struct fsg_dev *
/* Caller must hold fsg->lock */
static void wakeup_thread(struct fsg_common *common)
{
+ smp_wmb(); /* ensure the write of bh->state is complete */
/* Tell the main thread that something has happened */
common->thread_wakeup_needed = 1;
if (common->thread_task)
@@ -632,6 +633,7 @@ static int sleep_thread(struct fsg_commo
}
__set_current_state(TASK_RUNNING);
common->thread_wakeup_needed = 0;
+ smp_rmb(); /* ensure the latest bh->state is visible */
return rc;
}


2013-07-19 05:24:32

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 08/38] ext3,ext4: dont mess with dir_file->f_pos in htree_dirblock_to_tree()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Al Viro <[email protected]>

commit 64cb927371cd2ec43758d8a094a003d27bc3d0dc upstream.

Both ext3 and ext4 htree_dirblock_to_tree() is just filling the
in-core rbtree for use by call_filldir(). All updates of ->f_pos are
done by the latter; bumping it here (on error) is obviously wrong - we
might very well have it nowhere near the block we'd found an error in.

Signed-off-by: Al Viro <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext3/namei.c | 7 ++-----
fs/ext4/namei.c | 7 ++-----
2 files changed, 4 insertions(+), 10 deletions(-)

--- a/fs/ext3/namei.c
+++ b/fs/ext3/namei.c
@@ -576,11 +576,8 @@ static int htree_dirblock_to_tree(struct
if (!ext3_check_dir_entry("htree_dirblock_to_tree", dir, de, bh,
(block<<EXT3_BLOCK_SIZE_BITS(dir->i_sb))
+((char *)de - bh->b_data))) {
- /* On error, skip the f_pos to the next block. */
- dir_file->f_pos = (dir_file->f_pos |
- (dir->i_sb->s_blocksize - 1)) + 1;
- brelse (bh);
- return count;
+ /* silently ignore the rest of the block */
+ break;
}
ext3fs_dirhash(de->name, de->name_len, hinfo);
if ((hinfo->hash < start_hash) ||
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -917,11 +917,8 @@ static int htree_dirblock_to_tree(struct
bh->b_data, bh->b_size,
(block<<EXT4_BLOCK_SIZE_BITS(dir->i_sb))
+ ((char *)de - bh->b_data))) {
- /* On error, skip the f_pos to the next block. */
- dir_file->f_pos = (dir_file->f_pos |
- (dir->i_sb->s_blocksize - 1)) + 1;
- brelse(bh);
- return count;
+ /* silently ignore the rest of the block */
+ break;
}
ext4fs_dirhash(de->name, de->name_len, hinfo);
if ((hinfo->hash < start_hash) ||

2013-07-19 05:24:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 04/38] rtlwifi: rtl8192cu: Fix duplicate if test

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Larry Finger <[email protected]>

commit 10d0b9030a3f86e1e26c710c7580524d7787d688 upstream.

A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the
same condition twice. The problem was found using cppcheck-1.49, and the
proper fix was verified against the pre-mac80211 version of the code.

This patch was originally included as commit 1288aa4, but was accidentally
reverted in a later patch.

Reported-by: David Binderman <[email protected]> [original report]
Reported-by: Andrea Morello <[email protected]> [report of accidental reversion]
Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rtlwifi/rtl8192cu/rf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/rf.c
@@ -104,7 +104,7 @@ void rtl92cu_phy_rf6052_set_cck_txpower(
tx_agc[RF90_PATH_A] = 0x10101010;
tx_agc[RF90_PATH_B] = 0x10101010;
} else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
- TXHIGHPWRLEVEL_LEVEL1) {
+ TXHIGHPWRLEVEL_LEVEL2) {
tx_agc[RF90_PATH_A] = 0x00000000;
tx_agc[RF90_PATH_B] = 0x00000000;
} else{

2013-07-19 05:25:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 03/38] rtlwifi: rtl8723ae: Fix typo in firmware names

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Larry Finger <[email protected]>

commit 73e088ed17c2880a963cc760a78af8a06d4a4d9d upstream.

The driver loads its firmware from files rtlwifi/rtl8723fw*.bin, but the
MODULE_FIRMWARE macros refer to rtlwifi/RTL8723aefw*.bin.

Signed-off-by: Larry Finger <[email protected]>
Reported-by: Axel Köllhofer <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/rtlwifi/rtl8723ae/sw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/rtlwifi/rtl8723ae/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723ae/sw.c
@@ -251,7 +251,7 @@ static struct rtl_hal_cfg rtl8723ae_hal_
.bar_id = 2,
.write_readback = true,
.name = "rtl8723ae_pci",
- .fw_name = "rtlwifi/rtl8723aefw.bin",
+ .fw_name = "rtlwifi/rtl8723fw.bin",
.ops = &rtl8723ae_hal_ops,
.mod_params = &rtl8723ae_mod_params,
.maps[SYS_ISO_CTRL] = REG_SYS_ISO_CTRL,
@@ -353,8 +353,8 @@ MODULE_AUTHOR("Realtek WlanFAE <wlanfae@
MODULE_AUTHOR("Larry Finger <[email protected]>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 8723E 802.11n PCI wireless");
-MODULE_FIRMWARE("rtlwifi/rtl8723aefw.bin");
-MODULE_FIRMWARE("rtlwifi/rtl8723aefw_B.bin");
+MODULE_FIRMWARE("rtlwifi/rtl8723fw.bin");
+MODULE_FIRMWARE("rtlwifi/rtl8723fw_B.bin");

module_param_named(swenc, rtl8723ae_mod_params.sw_crypto, bool, 0444);
module_param_named(debug, rtl8723ae_mod_params.debug, int, 0444);

2013-07-19 05:25:47

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 36/38] memcg, kmem: fix reference count handling on the error path

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Michal Hocko <[email protected]>

commit f37a96914d1aea10fed8d9af10251f0b9caea31b upstream.

mem_cgroup_css_online calls mem_cgroup_put if memcg_init_kmem fails.
This is not correct because only memcg_propagate_kmem takes an
additional reference while mem_cgroup_sockets_init is allowed to fail as
well (although no current implementation fails) but it doesn't take any
reference. This all suggests that it should be memcg_propagate_kmem
that should clean up after itself so this patch moves mem_cgroup_put
over there.

Unfortunately this is not that easy (as pointed out by Li Zefan) because
memcg_kmem_mark_dead marks the group dead (KMEM_ACCOUNTED_DEAD) if it is
marked active (KMEM_ACCOUNTED_ACTIVE) which is the case even if
memcg_propagate_kmem fails so the additional reference is dropped in
that case in kmem_cgroup_destroy which means that the reference would be
dropped two times.

The easiest way then would be to simply remove mem_cgrroup_put from
mem_cgroup_css_online and rely on kmem_cgroup_destroy doing the right
thing.

Signed-off-by: Michal Hocko <[email protected]>
Signed-off-by: Li Zefan <[email protected]>
Acked-by: KAMEZAWA Hiroyuki <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Glauber Costa <[email protected]>
Cc: Johannes Weiner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/memcontrol.c | 8 --------
1 file changed, 8 deletions(-)

--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -6179,14 +6179,6 @@ mem_cgroup_css_online(struct cgroup *con

error = memcg_init_kmem(memcg, &mem_cgroup_subsys);
mutex_unlock(&memcg_create_mutex);
- if (error) {
- /*
- * We call put now because our (and parent's) refcnts
- * are already in place. mem_cgroup_put() will internally
- * call __mem_cgroup_free, so return directly
- */
- mem_cgroup_put(memcg);
- }
return error;
}


2013-07-19 05:26:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 35/38] drivers/dma/pl330.c: fix locking in pl330_free_chan_resources()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bartlomiej Zolnierkiewicz <[email protected]>

commit da331ba8e9c5de72a27e50f71105395bba6eebe0 upstream.

tasklet_kill() may sleep so call it before taking pch->lock.

Fixes following lockup:

BUG: scheduling while atomic: cat/2383/0x00000002
Modules linked in:
unwind_backtrace+0x0/0xfc
__schedule_bug+0x4c/0x58
__schedule+0x690/0x6e0
sys_sched_yield+0x70/0x78
tasklet_kill+0x34/0x8c
pl330_free_chan_resources+0x24/0x88
dma_chan_put+0x4c/0x50
[...]
BUG: spinlock lockup suspected on CPU#0, swapper/0/0
lock: 0xe52aa04c, .magic: dead4ead, .owner: cat/2383, .owner_cpu: 1
unwind_backtrace+0x0/0xfc
do_raw_spin_lock+0x194/0x204
_raw_spin_lock_irqsave+0x20/0x28
pl330_tasklet+0x2c/0x5a8
tasklet_action+0xfc/0x114
__do_softirq+0xe4/0x19c
irq_exit+0x98/0x9c
handle_IPI+0x124/0x16c
gic_handle_irq+0x64/0x68
__irq_svc+0x40/0x70
cpuidle_wrap_enter+0x4c/0xa0
cpuidle_enter_state+0x18/0x68
cpuidle_idle_call+0xac/0xe0
cpu_idle+0xac/0xf0

Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Kyungmin Park <[email protected]>
Acked-by: Jassi Brar <[email protected]>
Cc: Vinod Koul <[email protected]>
Cc: Tomasz Figa <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/dma/pl330.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2485,10 +2485,10 @@ static void pl330_free_chan_resources(st
struct dma_pl330_chan *pch = to_pchan(chan);
unsigned long flags;

- spin_lock_irqsave(&pch->lock, flags);
-
tasklet_kill(&pch->task);

+ spin_lock_irqsave(&pch->lock, flags);
+
pl330_release_channel(pch->pl330_chid);
pch->pl330_chid = NULL;


2013-07-19 05:22:24

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 30/38] ext4: fix data offset overflow on 32-bit archs in ext4_inline_data_fiemap()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit eaf3793728d07d995f1e74250b2d0005f7ae98b5 upstream.

On 32-bit archs when sector_t is defined as 32-bit the logic computing
data offset in ext4_inline_data_fiemap(). Fix that by properly typing
the shifted value.

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/inline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -1702,7 +1702,7 @@ int ext4_inline_data_fiemap(struct inode
if (error)
goto out;

- physical = iloc.bh->b_blocknr << inode->i_sb->s_blocksize_bits;
+ physical = (__u64)iloc.bh->b_blocknr << inode->i_sb->s_blocksize_bits;
physical += (char *)ext4_raw_inode(&iloc) - iloc.bh->b_data;
physical += offsetof(struct ext4_inode, i_block);
length = i_size_read(inode);

2013-07-19 05:47:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 34/38] ext4: dont allow ext4_free_blocks() to fail due to ENOMEM

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Theodore Ts'o <[email protected]>

commit e7676a704ee0a1ef71a6b23760b5a8f6896cb1a1 upstream.

The filesystem should not be marked inconsistent if ext4_free_blocks()
is not able to allocate memory. Unfortunately some callers (most
notably ext4_truncate) don't have a way to reflect an error back up to
the VFS. And even if we did, most userspace applications won't deal
with most system calls returning ENOMEM anyway.

Reported-by: Nagachandra P <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/mballoc.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)

--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -4622,11 +4622,16 @@ do_more:
* blocks being freed are metadata. these blocks shouldn't
* be used until this transaction is committed
*/
+ retry:
new_entry = kmem_cache_alloc(ext4_free_data_cachep, GFP_NOFS);
if (!new_entry) {
- ext4_mb_unload_buddy(&e4b);
- err = -ENOMEM;
- goto error_return;
+ /*
+ * We use a retry loop because
+ * ext4_free_blocks() is not allowed to fail.
+ */
+ cond_resched();
+ congestion_wait(BLK_RW_ASYNC, HZ/50);
+ goto retry;
}
new_entry->efd_start_cluster = bit;
new_entry->efd_group = block_group;

2013-07-19 05:47:43

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 32/38] ext4: fix data offset overflow in ext4_xattr_fiemap() on 32-bit archs

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit a60697f411eb365fb09e639e6f183fe33d1eb796 upstream.

On 32-bit architectures with 32-bit sector_t computation of data offset
in ext4_xattr_fiemap() can overflow resulting in reporting bogus data
location. Fix the problem by typing block number to proper type before
shifting.

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/extents.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4605,7 +4605,7 @@ static int ext4_xattr_fiemap(struct inod
error = ext4_get_inode_loc(inode, &iloc);
if (error)
return error;
- physical = iloc.bh->b_blocknr << blockbits;
+ physical = (__u64)iloc.bh->b_blocknr << blockbits;
offset = EXT4_GOOD_OLD_INODE_SIZE +
EXT4_I(inode)->i_extra_isize;
physical += offset;
@@ -4613,7 +4613,7 @@ static int ext4_xattr_fiemap(struct inod
flags |= FIEMAP_EXTENT_DATA_INLINE;
brelse(iloc.bh);
} else { /* external block */
- physical = EXT4_I(inode)->i_file_acl << blockbits;
+ physical = (__u64)EXT4_I(inode)->i_file_acl << blockbits;
length = inode->i_sb->s_blocksize;
}


2013-07-19 05:48:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 31/38] ext4: fix overflows in SEEK_HOLE, SEEK_DATA implementations

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit e7293fd146846e2a44d29e0477e0860c60fb856b upstream.

ext4_lblk_t is just u32 so multiplying it by blocksize can easily
overflow for files larger than 4 GB. Fix that by properly typing the
block offsets before shifting.

Signed-off-by: Jan Kara <[email protected]>
Signed-off-by: Theodore Ts'o <[email protected]>
Reviewed-by: Zheng Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/ext4/file.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -311,7 +311,7 @@ static int ext4_find_unwritten_pgoff(str
blkbits = inode->i_sb->s_blocksize_bits;
startoff = *offset;
lastoff = startoff;
- endoff = (map->m_lblk + map->m_len) << blkbits;
+ endoff = (loff_t)(map->m_lblk + map->m_len) << blkbits;

index = startoff >> PAGE_CACHE_SHIFT;
end = endoff >> PAGE_CACHE_SHIFT;
@@ -456,7 +456,7 @@ static loff_t ext4_seek_data(struct file
ret = ext4_map_blocks(NULL, inode, &map, 0);
if (ret > 0 && !(map.m_flags & EXT4_MAP_UNWRITTEN)) {
if (last != start)
- dataoff = last << blkbits;
+ dataoff = (loff_t)last << blkbits;
break;
}

@@ -467,7 +467,7 @@ static loff_t ext4_seek_data(struct file
ext4_es_find_delayed_extent(inode, last, &es);
if (es.es_len != 0 && in_range(last, es.es_lblk, es.es_len)) {
if (last != start)
- dataoff = last << blkbits;
+ dataoff = (loff_t)last << blkbits;
break;
}

@@ -485,7 +485,7 @@ static loff_t ext4_seek_data(struct file
}

last++;
- dataoff = last << blkbits;
+ dataoff = (loff_t)last << blkbits;
} while (last <= end);

mutex_unlock(&inode->i_mutex);
@@ -539,7 +539,7 @@ static loff_t ext4_seek_hole(struct file
ret = ext4_map_blocks(NULL, inode, &map, 0);
if (ret > 0 && !(map.m_flags & EXT4_MAP_UNWRITTEN)) {
last += ret;
- holeoff = last << blkbits;
+ holeoff = (loff_t)last << blkbits;
continue;
}

@@ -550,7 +550,7 @@ static loff_t ext4_seek_hole(struct file
ext4_es_find_delayed_extent(inode, last, &es);
if (es.es_len != 0 && in_range(last, es.es_lblk, es.es_len)) {
last = es.es_lblk + es.es_len;
- holeoff = last << blkbits;
+ holeoff = (loff_t)last << blkbits;
continue;
}

@@ -565,7 +565,7 @@ static loff_t ext4_seek_hole(struct file
&map, &holeoff);
if (!unwritten) {
last += ret;
- holeoff = last << blkbits;
+ holeoff = (loff_t)last << blkbits;
continue;
}
}

2013-07-19 05:48:40

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 02/38] CIFS: Fix a deadlock when a file is reopened

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Pavel Shilovsky <[email protected]>

commit 689c3db4d57a73bee6c5ad7797fce7b54d32a87c upstream.

If we request reading or writing on a file that needs to be
reopened, it causes the deadlock: we are already holding rw
semaphore for reading and then we try to acquire it for writing
in cifs_relock_file. Fix this by acquiring the semaphore for
reading in cifs_relock_file due to we don't make any changes in
locks and don't need a write access.

Signed-off-by: Pavel Shilovsky <[email protected]>
Acked-by: Jeff Layton <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/file.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)

--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -557,11 +557,10 @@ cifs_relock_file(struct cifsFileInfo *cf
struct cifs_tcon *tcon = tlink_tcon(cfile->tlink);
int rc = 0;

- /* we are going to update can_cache_brlcks here - need a write access */
- down_write(&cinode->lock_sem);
+ down_read(&cinode->lock_sem);
if (cinode->can_cache_brlcks) {
- /* can cache locks - no need to push them */
- up_write(&cinode->lock_sem);
+ /* can cache locks - no need to relock */
+ up_read(&cinode->lock_sem);
return rc;
}

@@ -572,7 +571,7 @@ cifs_relock_file(struct cifsFileInfo *cf
else
rc = tcon->ses->server->ops->push_mand_locks(cfile);

- up_write(&cinode->lock_sem);
+ up_read(&cinode->lock_sem);
return rc;
}


2013-07-19 05:48:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 29/38] Btrfs: only do the tree_mod_log_free_eb if this is our last ref

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Josef Bacik <[email protected]>

commit 7fb7d76f96bfcbea25007d190ba828b18e13d29d upstream.

There is another bug in the tree mod log stuff in that we're calling
tree_mod_log_free_eb every single time a block is cow'ed. The problem with this
is that if this block is shared by multiple snapshots we will call this multiple
times per block, so if we go to rewind the mod log for this block we'll BUG_ON()
in __tree_mod_log_rewind because we try to rewind a free twice. We only want to
call tree_mod_log_free_eb if we are actually freeing the block. With this patch
I no longer hit the panic in __tree_mod_log_rewind. Thanks,

Reviewed-by: Jan Schmidt <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/ctree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1049,7 +1049,8 @@ static noinline int __btrfs_cow_block(st
btrfs_set_node_ptr_generation(parent, parent_slot,
trans->transid);
btrfs_mark_buffer_dirty(parent);
- tree_mod_log_free_eb(root->fs_info, buf);
+ if (last_ref)
+ tree_mod_log_free_eb(root->fs_info, buf);
btrfs_free_tree_block(trans, root, buf, parent_start,
last_ref);
}

2013-07-19 05:49:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 28/38] Btrfs: fix estale with btrfs send

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Josef Bacik <[email protected]>

commit 139f807a1eba1e484941a98fb93ee32ad859a6a1 upstream.

This fixes bugzilla 57491. If we take a snapshot of a fs with a unlink ongoing
and then try to send that root we will run into problems. When comparing with a
parent root we will search the parents and the send roots commit_root, which if
we've just created the snapshot will include the file that needs to be evicted
by the orphan cleanup. So when we find a changed extent we will try and copy
that info into the send stream, but when we lookup the inode we use the normal
root, which no longer has the inode because the orphan cleanup deleted it. The
best solution I have for this is to check our otransid with the generation of
the commit root and if they match just commit the transaction again, that way we
get the changes from the orphan cleanup. With this patch the reproducer I made
for this bugzilla no longer returns ESTALE when trying to do the send. Thanks,

Reported-by: Chris Wilson <[email protected]>
Signed-off-by: Josef Bacik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/btrfs/send.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)

--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@ -4579,6 +4579,41 @@ long btrfs_ioctl_send(struct file *mnt_f
send_root = BTRFS_I(file_inode(mnt_file))->root;
fs_info = send_root->fs_info;

+ /*
+ * This is done when we lookup the root, it should already be complete
+ * by the time we get here.
+ */
+ WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE);
+
+ /*
+ * If we just created this root we need to make sure that the orphan
+ * cleanup has been done and committed since we search the commit root,
+ * so check its commit root transid with our otransid and if they match
+ * commit the transaction to make sure everything is updated.
+ */
+ down_read(&send_root->fs_info->extent_commit_sem);
+ if (btrfs_header_generation(send_root->commit_root) ==
+ btrfs_root_otransid(&send_root->root_item)) {
+ struct btrfs_trans_handle *trans;
+
+ up_read(&send_root->fs_info->extent_commit_sem);
+
+ trans = btrfs_attach_transaction_barrier(send_root);
+ if (IS_ERR(trans)) {
+ if (PTR_ERR(trans) != -ENOENT) {
+ ret = PTR_ERR(trans);
+ goto out;
+ }
+ /* ENOENT means theres no transaction */
+ } else {
+ ret = btrfs_commit_transaction(trans, send_root);
+ if (ret)
+ goto out;
+ }
+ } else {
+ up_read(&send_root->fs_info->extent_commit_sem);
+ }
+
arg = memdup_user(arg_, sizeof(*arg));
if (IS_ERR(arg)) {
ret = PTR_ERR(arg);

2013-07-19 05:22:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 21/38] ACPI / PM: Fix corner case in acpi_bus_update_power()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: "Rafael J. Wysocki" <[email protected]>

commit 91bdad0b6237c25a7bf8fd4604d0cc64a2005a23 upstream.

The role of acpi_bus_update_power() is to update the given ACPI
device object's power.state field to reflect the current physical
state of the device (as inferred from the configuration of power
resources and _PSC, if available). For this purpose it calls
acpi_device_set_power() that should update the power resources'
reference counters and set power.state as appropriate. However,
that doesn't work if the "new" state is D1, D2 or D3hot and the
the current value of power.state means D3cold, because in that
case acpi_device_set_power() will refuse to transition the device
from D3cold to non-D0.

To address this problem, make acpi_bus_update_power() call
acpi_power_transition() directly to update the power resources'
reference counters and only use acpi_device_set_power() to put
the device into D0 if the current physical state of it cannot
be determined.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/device_pm.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)

--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -295,14 +295,27 @@ int acpi_bus_update_power(acpi_handle ha
if (result)
return result;

- if (state == ACPI_STATE_UNKNOWN)
+ if (state == ACPI_STATE_UNKNOWN) {
state = ACPI_STATE_D0;
-
- result = acpi_device_set_power(device, state);
- if (!result && state_p)
+ result = acpi_device_set_power(device, state);
+ if (result)
+ return result;
+ } else {
+ if (device->power.flags.power_resources) {
+ /*
+ * We don't need to really switch the state, bu we need
+ * to update the power resources' reference counters.
+ */
+ result = acpi_power_transition(device, state);
+ if (result)
+ return result;
+ }
+ device->power.state = state;
+ }
+ if (state_p)
*state_p = state;

- return result;
+ return 0;
}
EXPORT_SYMBOL_GPL(acpi_bus_update_power);


2013-07-19 05:49:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 27/38] timer: Fix jiffies wrap behavior of round_jiffies_common()

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Bart Van Assche <[email protected]>

commit 9e04d3804d3ac97d8c03a41d78d0f0674b5d01e1 upstream.

Direct compare of jiffies related values does not work in the wrap
around case. Replace it with time_is_after_jiffies().

Signed-off-by: Bart Van Assche <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/timer.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -148,9 +148,11 @@ static unsigned long round_jiffies_commo
/* now that we have rounded, subtract the extra skew again */
j -= cpu * 3;

- if (j <= jiffies) /* rounding ate our timeout entirely; */
- return original;
- return j;
+ /*
+ * Make sure j is still in the future. Otherwise return the
+ * unmodified value.
+ */
+ return time_is_after_jiffies(j) ? j : original;
}

/**

2013-07-19 05:49:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 25/38] PCI: Fix refcount issue in pci_create_root_bus() error recovery path

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jiang Liu <[email protected]>

commit 343df771e671d821478dd3ef525a0610b808dbf8 upstream.

After calling device_register(&bridge->dev), the bridge is reference-
counted, and it is illegal to call kfree() on it except in the release
function.

[bhelgaas: changelog, use put_device() after device_register() failure]
Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/probe.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1694,12 +1694,16 @@ struct pci_bus *pci_create_root_bus(stru
bridge->dev.release = pci_release_bus_bridge_dev;
dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
error = pcibios_root_bridge_prepare(bridge);
- if (error)
- goto bridge_dev_reg_err;
+ if (error) {
+ kfree(bridge);
+ goto err_out;
+ }

error = device_register(&bridge->dev);
- if (error)
- goto bridge_dev_reg_err;
+ if (error) {
+ put_device(&bridge->dev);
+ goto err_out;
+ }
b->bridge = get_device(&bridge->dev);
device_enable_async_suspend(b->bridge);
pci_set_bus_of_node(b);
@@ -1753,8 +1757,6 @@ struct pci_bus *pci_create_root_bus(stru
class_dev_reg_err:
put_device(&bridge->dev);
device_unregister(&bridge->dev);
-bridge_dev_reg_err:
- kfree(bridge);
err_out:
kfree(b);
return NULL;

2013-07-19 05:49:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 26/38] ahci: remove pmp link online check in FBS EH

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Shane Huang <[email protected]>

commit 912b9ac683b112615d5605686f1dc086402ce9f7 upstream.

ata_link_online() check in ahci_error_intr() is unnecessary, it should
be removed otherwise may lead to lockup with FBS enabled PMP.
http://marc.info/?l=linux-ide&m=137050421603272&w=2

Reported-by: Yu Liu <[email protected]>
Signed-off-by: Shane Huang <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/ata/libahci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -1560,8 +1560,7 @@ static void ahci_error_intr(struct ata_p
u32 fbs = readl(port_mmio + PORT_FBS);
int pmp = fbs >> PORT_FBS_DWE_OFFSET;

- if ((fbs & PORT_FBS_SDE) && (pmp < ap->nr_pmp_links) &&
- ata_link_online(&ap->pmp_link[pmp])) {
+ if ((fbs & PORT_FBS_SDE) && (pmp < ap->nr_pmp_links)) {
link = &ap->pmp_link[pmp];
fbs_need_dec = true;
}

2013-07-19 05:22:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 20/38] ACPICA: Do not use extended sleep registers unless HW-reduced bit is set

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lv Zheng <[email protected]>

commit 7cec7048fe22e3e92389da2cd67098f6c4284e7f upstream.

Previous implementation incorrectly used the ACPI 5.0 extended
sleep registers if they were simply populated. This caused
problems on some non-HW-reduced machines. As per the ACPI spec,
they should only be used if the HW-reduced bit is set. Lv Zheng,
ACPICA BZ 1020.

Reported-by: Daniel Rowe <[email protected]>
References: https://bugzilla.kernel.org/show_bug.cgi?id=54181
References: https://bugs.acpica.org/show_bug.cgi?id=1020
Bisected-by: Brint E. Kriebel <[email protected]>
Signed-off-by: Lv Zheng <[email protected]>
Signed-off-by: Bob Moore <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/acpica/hwxfsleep.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -240,12 +240,14 @@ static acpi_status acpi_hw_sleep_dispatc
&acpi_sleep_dispatch[function_id];

#if (!ACPI_REDUCED_HARDWARE)
-
/*
* If the Hardware Reduced flag is set (from the FADT), we must
- * use the extended sleep registers
+ * use the extended sleep registers (FADT). Note: As per the ACPI
+ * specification, these extended registers are to be used for HW-reduced
+ * platforms only. They are not general-purpose replacements for the
+ * legacy PM register sleep support.
*/
- if (acpi_gbl_reduced_hardware || acpi_gbl_FADT.sleep_control.address) {
+ if (acpi_gbl_reduced_hardware) {
status = sleep_functions->extended_function(sleep_state);
} else {
/* Legacy sleep */

2013-07-19 05:50:52

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 24/38] PCI: Finish SR-IOV VF setup before adding the device

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Xudong Hao <[email protected]>

commit fbf33f516bdbcc2ab1ba1e54dfb720b0cfaa6874 upstream.

Commit 4f535093cf "PCI: Put pci_dev in device tree as early as possible"
moves device registering from pci_bus_add_devices() to pci_device_add().
That causes problems for virtual functions because device_add(&virtfn->dev)
is called before setting the virtfn->is_virtfn flag, which then causes Xen
to report PCI virtual functions as PCI physical functions.

Fix it by setting virtfn->is_virtfn before calling pci_device_add().

[Jiang Liu]: Move the setting of virtfn->is_virtfn ahead further for better
readability and modify changelog.

Signed-off-by: Xudong Hao <[email protected]>
Signed-off-by: Jiang Liu <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/iov.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -92,6 +92,8 @@ static int virtfn_add(struct pci_dev *de
pci_read_config_word(dev, iov->pos + PCI_SRIOV_VF_DID, &virtfn->device);
pci_setup_device(virtfn);
virtfn->dev.parent = dev->dev.parent;
+ virtfn->physfn = pci_dev_get(dev);
+ virtfn->is_virtfn = 1;

for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
res = dev->resource + PCI_IOV_RESOURCES + i;
@@ -113,9 +115,6 @@ static int virtfn_add(struct pci_dev *de
pci_device_add(virtfn, virtfn->bus);
mutex_unlock(&iov->dev->sriov->lock);

- virtfn->physfn = pci_dev_get(dev);
- virtfn->is_virtfn = 1;
-
rc = pci_bus_add_device(virtfn);
sprintf(buf, "virtfn%u", id);
rc = sysfs_create_link(&dev->dev.kobj, &virtfn->dev.kobj, buf);

2013-07-19 05:51:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 23/38] nbd: correct disconnect behavior

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paul Clements <[email protected]>

commit c378f70adbc1bbecd9e6db145019f14b2f688c7c upstream.

Currently, when a disconnect is requested by the user (via NBD_DISCONNECT
ioctl) the return from NBD_DO_IT is undefined (it is usually one of
several error codes). This means that nbd-client does not know if a
manual disconnect was performed or whether a network error occurred.
Because of this, nbd-client's persist mode (which tries to reconnect after
error, but not after manual disconnect) does not always work correctly.

This change fixes this by causing NBD_DO_IT to always return 0 if a user
requests a disconnect. This means that nbd-client can correctly either
persist the connection (if an error occurred) or disconnect (if the user
requested it).

Signed-off-by: Paul Clements <[email protected]>
Acked-by: Rob Landley <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/nbd.c | 7 ++++++-
include/linux/nbd.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)

--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -623,8 +623,10 @@ static int __nbd_ioctl(struct block_devi
if (!nbd->sock)
return -EINVAL;

+ nbd->disconnect = 1;
+
nbd_send_req(nbd, &sreq);
- return 0;
+ return 0;
}

case NBD_CLEAR_SOCK: {
@@ -654,6 +656,7 @@ static int __nbd_ioctl(struct block_devi
nbd->sock = SOCKET_I(inode);
if (max_part > 0)
bdev->bd_invalidated = 1;
+ nbd->disconnect = 0; /* we're connected now */
return 0;
} else {
fput(file);
@@ -743,6 +746,8 @@ static int __nbd_ioctl(struct block_devi
set_capacity(nbd->disk, 0);
if (max_part > 0)
ioctl_by_bdev(bdev, BLKRRPART, 0);
+ if (nbd->disconnect) /* user requested, ignore socket errors */
+ return 0;
return nbd->harderror;
}

--- a/include/linux/nbd.h
+++ b/include/linux/nbd.h
@@ -41,6 +41,7 @@ struct nbd_device {
u64 bytesize;
pid_t pid; /* pid of nbd-client, if attached */
int xmit_timeout;
+ int disconnect; /* a disconnect has been requested by user */
};

#endif

2013-07-19 05:22:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 16/38] xen/pcifront: Deal with toolstack missing XenbusStateClosing state.

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Konrad Rzeszutek Wilk <[email protected]>

commit 098b1aeaf4d6149953b8f1f8d55c21d85536fbff upstream.

There are two tool-stack that can instruct the Xen PCI frontend
and backend to change states: 'xm' (Python code with a daemon),
and 'xl' (C library - does not keep state changes).

With the 'xm', the path to disconnect a single PCI device (xm pci-detach
<guest> <BDF>) is:

4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected)->5(Closing*).

The * is for states that the tool-stack sets. For 'xl', it is similar:

4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected)

Both of them also tear down the XenBus structure, so the backend
state ends up going in the 3(Initialised) and calls pcifront_xenbus_remove.

When a PCI device is plugged back in (xm pci-attach <guest> <BDF>)
both of them follow the same pattern:

2(InitWait*), 3(Initialized*), 4(Connected*)->4(Connected).

[xen-pcifront ignores the 2,3 state changes and only acts when
4 (Connected) has been reached]

Note that this is for a _single_ PCI device. If there were two
PCI devices and only one was disconnected 'xm' would show the same
state changes.

The problem is that git commit 3d925320e9e2de162bd138bf97816bda8c3f71be
("xen/pcifront: Use Xen-SWIOTLB when initting if required") introduced
a mechanism to initialize the SWIOTLB when the Xen PCI front moves to
Connected state. It also had some aggressive seatbelt code check that
would warn the user if one tried to change to Connected state without
hitting first the Closing state:

pcifront pci-0: PCI frontend already installed!

However, that code can be relaxed and we can continue on working
even if the frontend is instructed to be the 'Connected' state with
no devices and then gets tickled to be in 'Connected' state again.

In other words, this 4(Connected)->5(Closing)->4(Connected) state
was expected, while 4(Connected)->.... anything but 5(Closing)->4(Connected)
was not. This patch removes that aggressive check and allows
Xen pcifront to work with the 'xl' toolstack (for one or more
PCI devices) and with 'xm' toolstack (for more than two PCI
devices).

Acked-by: Bjorn Helgaas <[email protected]>
Cc: [email protected]
[v2: Added in the description about two PCI devices]
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pci/xen-pcifront.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -678,10 +678,9 @@ static int pcifront_connect_and_init_dma
if (!pcifront_dev) {
dev_info(&pdev->xdev->dev, "Installing PCI frontend\n");
pcifront_dev = pdev;
- } else {
- dev_err(&pdev->xdev->dev, "PCI frontend already installed!\n");
+ } else
err = -EEXIST;
- }
+
spin_unlock(&pcifront_dev_lock);

if (!err && !swiotlb_nr_tbl()) {
@@ -848,7 +847,7 @@ static int pcifront_try_connect(struct p
goto out;

err = pcifront_connect_and_init_dma(pdev);
- if (err) {
+ if (err && err != -EEXIST) {
xenbus_dev_fatal(pdev->xdev, err,
"Error setting up PCI Frontend");
goto out;

2013-07-19 05:51:49

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 01/38] CIFS use sensible file nlink values if unprovided

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Steve French <[email protected]>

commit 6658b9f70ebca5fc0795b1d6d733996af1e2caa7 upstream.

Certain servers may not set the NumberOfLinks field in query file/path
info responses. In such a case, cifs_inode_needs_reval() assumes that
all regular files are hardlinks and triggers revalidation, leading to
excessive and unnecessary network traffic.

This change hardcodes cf_nlink (and subsequently i_nlink) when not
returned by the server, similar to what already occurs in cifs_mkdir().

Signed-off-by: David Disseldorp <[email protected]>
Signed-off-by: Steve French <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/cifs/inode.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -556,6 +556,11 @@ cifs_all_info_to_fattr(struct cifs_fattr
fattr->cf_mode &= ~(S_IWUGO);

fattr->cf_nlink = le32_to_cpu(info->NumberOfLinks);
+ if (fattr->cf_nlink < 1) {
+ cifs_dbg(1, "replacing bogus file nlink value %u\n",
+ fattr->cf_nlink);
+ fattr->cf_nlink = 1;
+ }
}

fattr->cf_uid = cifs_sb->mnt_uid;

2013-07-19 05:52:16

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 19/38] ACPI / EC: Add HP Folio 13 to ec_dmi_table in order to skip DSDT scan

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Lan Tianyu <[email protected]>

commit eff9a4b62b14cf0d9913e3caf1f26f8b7a6105c9 upstream.

HP Folio 13's BIOS defines CMOS RTC Operation Region and the EC's
_REG method will access that region. To allow the CMOS RTC region
handler to be installed before the EC _REG method is first invoked,
add ec_skip_dsdt_scan() as HP Folio 13's callback to ec_dmi_table.

References: https://bugzilla.kernel.org/show_bug.cgi?id=54621
Reported-and-tested-by: Stefan Nagy <[email protected]>
Signed-off-by: Lan Tianyu <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/acpi/ec.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -983,6 +983,10 @@ static struct dmi_system_id __initdata e
ec_enlarge_storm_threshold, "CLEVO hardware", {
DMI_MATCH(DMI_SYS_VENDOR, "CLEVO Co."),
DMI_MATCH(DMI_PRODUCT_NAME, "M720T/M730T"),}, NULL},
+ {
+ ec_skip_dsdt_scan, "HP Folio 13", {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13"),}, NULL},
{},
};


2013-07-19 05:52:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 18/38] drivers/rtc/rtc-rv3029c2.c: fix disabling AIE irq

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Axel Lin <[email protected]>

commit 29ecd78c0fd6ee05f2c6b07b23823a6ae43c13ff upstream.

In the disable AIE irq code path, current code passes "1" to enable
parameter of rv3029c2_rtc_i2c_alarm_set_irq(). Thus it does not disable
AIE irq.

Signed-off-by: Axel Lin <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/rtc/rtc-rv3029c2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/rtc/rtc-rv3029c2.c
+++ b/drivers/rtc/rtc-rv3029c2.c
@@ -310,7 +310,7 @@ static int rv3029c2_rtc_i2c_set_alarm(st
dev_dbg(&client->dev, "alarm IRQ armed\n");
} else {
/* disable AIE irq */
- ret = rv3029c2_rtc_i2c_alarm_set_irq(client, 1);
+ ret = rv3029c2_rtc_i2c_alarm_set_irq(client, 0);
if (ret)
return ret;


2013-07-19 05:52:51

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 17/38] genirq: Fix can_request_irq() for IRQs without an action

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ben Hutchings <[email protected]>

commit 2779db8d37d4b542d9ca2575f5f178dbeaca6c86 upstream.

Commit 02725e7471b8 ('genirq: Use irq_get/put functions'),
inadvertently changed can_request_irq() to return 0 for IRQs that have
no action. This causes pcibios_lookup_irq() to select only IRQs that
already have an action with IRQF_SHARED set, or to fail if there are
none. Change can_request_irq() to return 1 for IRQs that have no
action (if the first two conditions are met).

Reported-by: Bjarni Ingi Gislason <[email protected]>
Tested-by: Bjarni Ingi Gislason <[email protected]> (against 3.2)
Signed-off-by: Ben Hutchings <[email protected]>
Cc: [email protected]
Link: http://bugs.debian.org/709647
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/irq/manage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -555,9 +555,9 @@ int can_request_irq(unsigned int irq, un
return 0;

if (irq_settings_can_request(desc)) {
- if (desc->action)
- if (irqflags & desc->action->flags & IRQF_SHARED)
- canrequest =1;
+ if (!desc->action ||
+ irqflags & desc->action->flags & IRQF_SHARED)
+ canrequest = 1;
}
irq_put_desc_unlock(desc, flags);
return canrequest;

2013-07-19 05:53:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 13/38] pcmcia: at91_cf: fix gpio_get_value in at91_cf_get_status

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joachim Eastwood <[email protected]>

commit e39506b466edcda2a7e9d0174d7987ae654137b7 upstream.

Commit 80af9e6d (pcmcia at91_cf: fix raw gpio number usage) forgot
to change the parameter in gpio_get_value after adding gpio
validation.

Signed-off-by: Joachim Eastwood <[email protected]>
Signed-off-by: Nicolas Ferre <[email protected]>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/pcmcia/at91_cf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/pcmcia/at91_cf.c
+++ b/drivers/pcmcia/at91_cf.c
@@ -100,9 +100,9 @@ static int at91_cf_get_status(struct pcm
int vcc = gpio_is_valid(cf->board->vcc_pin);

*sp = SS_DETECT | SS_3VCARD;
- if (!rdy || gpio_get_value(rdy))
+ if (!rdy || gpio_get_value(cf->board->irq_pin))
*sp |= SS_READY;
- if (!vcc || gpio_get_value(vcc))
+ if (!vcc || gpio_get_value(cf->board->vcc_pin))
*sp |= SS_POWERON;
} else
*sp = 0;

2013-07-19 05:53:19

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 14/38] cgroup: fix umount vs cgroup_event_remove() race

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: Li Zefan <[email protected]>

commit 1c8158eeae0f37d0eee9f1fbe68080df6a408df2 upstream.

commit 5db9a4d99b0157a513944e9a44d29c9cec2e91dc
Author: Tejun Heo <[email protected]>
Date: Sat Jul 7 16:08:18 2012 -0700

cgroup: fix cgroup hierarchy umount race

This commit fixed a race caused by the dput() in css_dput_fn(), but
the dput() in cgroup_event_remove() can also lead to the same BUG().

Signed-off-by: Li Zefan <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/cgroup.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)

--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3773,6 +3773,23 @@ static int cgroup_write_notify_on_releas
}

/*
+ * When dput() is called asynchronously, if umount has been done and
+ * then deactivate_super() in cgroup_free_fn() kills the superblock,
+ * there's a small window that vfs will see the root dentry with non-zero
+ * refcnt and trigger BUG().
+ *
+ * That's why we hold a reference before dput() and drop it right after.
+ */
+static void cgroup_dput(struct cgroup *cgrp)
+{
+ struct super_block *sb = cgrp->root->sb;
+
+ atomic_inc(&sb->s_active);
+ dput(cgrp->dentry);
+ deactivate_super(sb);
+}
+
+/*
* Unregister event and free resources.
*
* Gets called from workqueue.
@@ -3792,7 +3809,7 @@ static void cgroup_event_remove(struct w

eventfd_ctx_put(event->eventfd);
kfree(event);
- dput(cgrp->dentry);
+ cgroup_dput(cgrp);
}

/*
@@ -4075,12 +4092,8 @@ static void css_dput_fn(struct work_stru
{
struct cgroup_subsys_state *css =
container_of(work, struct cgroup_subsys_state, dput_work);
- struct dentry *dentry = css->cgroup->dentry;
- struct super_block *sb = dentry->d_sb;

- atomic_inc(&sb->s_active);
- dput(dentry);
- deactivate_super(sb);
+ cgroup_dput(css->cgroup);
}

static void init_cgroup_css(struct cgroup_subsys_state *css,

2013-07-19 05:54:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [ 11/38] usb: host: xhci-plat: release mem region while removing module

3.9-stable review patch. If anyone has any objections, please let me know.

------------------

From: George Cherian <[email protected]>

commit 5388a3a5faba8dfa69e5f06c3a415d373c1a4316 upstream.

Do a release_mem_region of the hcd resource. Without this the
subsequent insertion of module fails in request_mem_region.

Signed-off-by: George Cherian <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-plat.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -179,6 +179,7 @@ static int xhci_plat_remove(struct platf

usb_remove_hcd(hcd);
iounmap(hcd->regs);
+ release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
kfree(xhci);


2013-07-19 16:45:31

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> ---------------
> Note, this is the LAST 3.9-stable kernel release that I will be doing.
> Please move to the 3.10-stable branch as soon as possible.
> ---------------
>
> This is the start of the stable review cycle for the 3.9.11 release.
> There are 38 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Greg,

Build failed with the following error:

LD ipc/built-in.o
CC [M] fs/cifs/inode.o
fs/cifs/inode.c: In function ?cifs_all_info_to_fattr?:
fs/cifs/inode.c:560:4: error: implicit declaration of function
?cifs_dbg? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [fs/cifs/inode.o] Error 1
make[1]: *** [fs/cifs] Error 2
make: *** [fs] Error 2
make: *** Waiting for unfinished jobs....
CC security/selinux/hooks.o

I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
cifs_dbg() is not defined.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) [email protected] | (970) 672-0658

2013-07-19 19:25:20

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On Fri, Jul 19, 2013 at 04:45:25PM +0000, Shuah Khan wrote:
> On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> > ---------------
> > Note, this is the LAST 3.9-stable kernel release that I will be doing.
> > Please move to the 3.10-stable branch as soon as possible.
> > ---------------
> >
> > This is the start of the stable review cycle for the 3.9.11 release.
> > There are 38 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> Greg,
>
> Build failed with the following error:
>
> LD ipc/built-in.o
> CC [M] fs/cifs/inode.o
> fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’:
> fs/cifs/inode.c:560:4: error: implicit declaration of function
> ‘cifs_dbg’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[2]: *** [fs/cifs/inode.o] Error 1
> make[1]: *** [fs/cifs] Error 2
> make: *** [fs] Error 2
> make: *** Waiting for unfinished jobs....
> CC security/selinux/hooks.o
>
> I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
> cifs_dbg() is not defined.

Ugh, I thought I fixed that one... I did it for the 3.4 and other
trees, I'll go see what I did wrong...

thanks for letting me know,

greg k-h

2013-07-19 23:49:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 19, 2013 at 04:45:25PM +0000, Shuah Khan wrote:
> > On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> > > ---------------
> > > Note, this is the LAST 3.9-stable kernel release that I will be doing.
> > > Please move to the 3.10-stable branch as soon as possible.
> > > ---------------
> > >
> > > This is the start of the stable review cycle for the 3.9.11 release.
> > > There are 38 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> > > and the diffstat can be found below.
> > >
> > > thanks,
> > >
> > > greg k-h
> > >
> >
> > Greg,
> >
> > Build failed with the following error:
> >
> > LD ipc/built-in.o
> > CC [M] fs/cifs/inode.o
> > fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’:
> > fs/cifs/inode.c:560:4: error: implicit declaration of function
> > ‘cifs_dbg’ [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > make[2]: *** [fs/cifs/inode.o] Error 1
> > make[1]: *** [fs/cifs] Error 2
> > make: *** [fs] Error 2
> > make: *** Waiting for unfinished jobs....
> > CC security/selinux/hooks.o
> >
> > I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
> > cifs_dbg() is not defined.
>
> Ugh, I thought I fixed that one... I did it for the 3.4 and other
> trees, I'll go see what I did wrong...

Ok, I've now fixed this, I don't know how it got through my tests, when
I tried it again, it failed. Before it wasn't, odd...

Anyway, there is a new -rc2 kernel patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz

If you could test that out, I would appreciate it, to ensure I didn't do
anything stupid with this one too.

Ick, handling 4 kernels at once really takes its toll on me, this was
not a good review cycle...

thanks,

greg k-h

2013-07-20 00:10:08

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote:
> On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
>> On Fri, Jul 19, 2013 at 04:45:25PM +0000, Shuah Khan wrote:
>>> On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
>>>> ---------------
>>>> Note, this is the LAST 3.9-stable kernel release that I will be doing.
>>>> Please move to the 3.10-stable branch as soon as possible.
>>>> ---------------
>>>>
>>>> This is the start of the stable review cycle for the 3.9.11 release.
>>>> There are 38 patches in this series, all will be posted as a response
>>>> to this one. If anyone has any issues with these being applied, please
>>>> let me know.
>>>>
>>>> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
>>>> Anything received after that time might be too late.
>>>>
>>>> The whole patch series can be found in one patch at:
>>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
>>>> and the diffstat can be found below.
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>>
>>>
>>> Greg,
>>>
>>> Build failed with the following error:
>>>
>>> LD ipc/built-in.o
>>> CC [M] fs/cifs/inode.o
>>> fs/cifs/inode.c: In function ?cifs_all_info_to_fattr?:
>>> fs/cifs/inode.c:560:4: error: implicit declaration of function
>>> ?cifs_dbg? [-Werror=implicit-function-declaration]
>>> cc1: some warnings being treated as errors
>>> make[2]: *** [fs/cifs/inode.o] Error 1
>>> make[1]: *** [fs/cifs] Error 2
>>> make: *** [fs] Error 2
>>> make: *** Waiting for unfinished jobs....
>>> CC security/selinux/hooks.o
>>>
>>> I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
>>> cifs_dbg() is not defined.
>>
>> Ugh, I thought I fixed that one... I did it for the 3.4 and other
>> trees, I'll go see what I did wrong...
>
> Ok, I've now fixed this, I don't know how it got through my tests, when
> I tried it again, it failed. Before it wasn't, odd...
>
> Anyway, there is a new -rc2 kernel patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz
>
> If you could test that out, I would appreciate it, to ensure I didn't do
> anything stupid with this one too.
>
> Ick, handling 4 kernels at once really takes its toll on me, this was
> not a good review cycle...
>
> thanks,
>
> greg k-h
>

Greg,

rc2 compiled on x86-64. I will run cross-compile tests and boot tests
later on today or tomorrow morning and report the results.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) [email protected] | (970) 672-0658

2013-07-20 16:34:48

by Shuah Khan

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On 07/19/2013 06:10 PM, Shuah Khan wrote:
> On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote:
>> On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
>>> On Fri, Jul 19, 2013 at 04:45:25PM +0000, Shuah Khan wrote:
>>>> On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
>>>>> ---------------
>>>>> Note, this is the LAST 3.9-stable kernel release that I will be doing.
>>>>> Please move to the 3.10-stable branch as soon as possible.
>>>>> ---------------
>>>>>
>>>>> This is the start of the stable review cycle for the 3.9.11 release.
>>>>> There are 38 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>
>>>> Greg,
>>>>
>>>> Build failed with the following error:
>>>>
>>>> LD ipc/built-in.o
>>>> CC [M] fs/cifs/inode.o
>>>> fs/cifs/inode.c: In function ?cifs_all_info_to_fattr?:
>>>> fs/cifs/inode.c:560:4: error: implicit declaration of function
>>>> ?cifs_dbg? [-Werror=implicit-function-declaration]
>>>> cc1: some warnings being treated as errors
>>>> make[2]: *** [fs/cifs/inode.o] Error 1
>>>> make[1]: *** [fs/cifs] Error 2
>>>> make: *** [fs] Error 2
>>>> make: *** Waiting for unfinished jobs....
>>>> CC security/selinux/hooks.o
>>>>
>>>> I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
>>>> cifs_dbg() is not defined.
>>>
>>> Ugh, I thought I fixed that one... I did it for the 3.4 and other
>>> trees, I'll go see what I did wrong...
>>
>> Ok, I've now fixed this, I don't know how it got through my tests, when
>> I tried it again, it failed. Before it wasn't, odd...
>>
>> Anyway, there is a new -rc2 kernel patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz
>>
>> If you could test that out, I would appreciate it, to ensure I didn't do
>> anything stupid with this one too.
>>
>> Ick, handling 4 kernels at once really takes its toll on me, this was
>> not a good review cycle...
>>
>> thanks,
>>
>> greg k-h
>>
>
> Greg,
>
> rc2 compiled on x86-64. I will run cross-compile tests and boot tests
> later on today or tomorrow morning and report the results.
>
> -- Shuah
>
> Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
> America (Silicon Valley) [email protected] | (970) 672-0658
>

3.9.11-rc2 boot tests passed on my test systems and cross-compile tests
passed. No regressions in dmesgs.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) [email protected] | (970) 672-0658

2013-07-20 16:49:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On Sat, Jul 20, 2013 at 04:34:41PM +0000, Shuah Khan wrote:
> On 07/19/2013 06:10 PM, Shuah Khan wrote:
> > On 07/19/2013 05:50 PM, Greg Kroah-Hartman wrote:
> >> On Fri, Jul 19, 2013 at 12:25:24PM -0700, Greg Kroah-Hartman wrote:
> >>> On Fri, Jul 19, 2013 at 04:45:25PM +0000, Shuah Khan wrote:
> >>>> On 07/19/2013 09:34 AM, Greg Kroah-Hartman wrote:
> >>>>> ---------------
> >>>>> Note, this is the LAST 3.9-stable kernel release that I will be doing.
> >>>>> Please move to the 3.10-stable branch as soon as possible.
> >>>>> ---------------
> >>>>>
> >>>>> This is the start of the stable review cycle for the 3.9.11 release.
> >>>>> There are 38 patches in this series, all will be posted as a response
> >>>>> to this one. If anyone has any issues with these being applied, please
> >>>>> let me know.
> >>>>>
> >>>>> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> >>>>> Anything received after that time might be too late.
> >>>>>
> >>>>> The whole patch series can be found in one patch at:
> >>>>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc1.gz
> >>>>> and the diffstat can be found below.
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> greg k-h
> >>>>>
> >>>>
> >>>> Greg,
> >>>>
> >>>> Build failed with the following error:
> >>>>
> >>>> LD ipc/built-in.o
> >>>> CC [M] fs/cifs/inode.o
> >>>> fs/cifs/inode.c: In function ‘cifs_all_info_to_fattr’:
> >>>> fs/cifs/inode.c:560:4: error: implicit declaration of function
> >>>> ‘cifs_dbg’ [-Werror=implicit-function-declaration]
> >>>> cc1: some warnings being treated as errors
> >>>> make[2]: *** [fs/cifs/inode.o] Error 1
> >>>> make[1]: *** [fs/cifs] Error 2
> >>>> make: *** [fs] Error 2
> >>>> make: *** Waiting for unfinished jobs....
> >>>> CC security/selinux/hooks.o
> >>>>
> >>>> I have CONFIG_CIFS=m in my config and CONFIG_CIFS_DEBUG is disabled.
> >>>> cifs_dbg() is not defined.
> >>>
> >>> Ugh, I thought I fixed that one... I did it for the 3.4 and other
> >>> trees, I'll go see what I did wrong...
> >>
> >> Ok, I've now fixed this, I don't know how it got through my tests, when
> >> I tried it again, it failed. Before it wasn't, odd...
> >>
> >> Anyway, there is a new -rc2 kernel patch at:
> >> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.11-rc2.gz
> >>
> >> If you could test that out, I would appreciate it, to ensure I didn't do
> >> anything stupid with this one too.
> >>
> >> Ick, handling 4 kernels at once really takes its toll on me, this was
> >> not a good review cycle...
> >>
> >> thanks,
> >>
> >> greg k-h
> >>
> >
> > Greg,
> >
> > rc2 compiled on x86-64. I will run cross-compile tests and boot tests
> > later on today or tomorrow morning and report the results.
> >
> > -- Shuah
> >
> > Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
> > America (Silicon Valley) [email protected] | (970) 672-0658
> >
>
> 3.9.11-rc2 boot tests passed on my test systems and cross-compile tests
> passed. No regressions in dmesgs.

Wonderful, thanks so much for testing and letting me know.

greg k-h

2013-07-21 00:38:04

by Satoru Takeuchi

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

At Thu, 18 Jul 2013 22:21:16 -0700,
Greg Kroah-Hartman wrote:
>
> ---------------
> Note, this is the LAST 3.9-stable kernel release that I will be doing.
> Please move to the 3.10-stable branch as soon as possible.
> ---------------
>
> This is the start of the stable review cycle for the 3.9.11 release.
> There are 38 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> Anything received after that time might be too late.

This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.

- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB

- Test machine: debian jessy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB

Thanks,
Satoru

2013-07-21 01:34:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [ 00/38] 3.9.11-stable review

On Sun, Jul 21, 2013 at 09:37:56AM +0900, Satoru Takeuchi wrote:
> At Thu, 18 Jul 2013 22:21:16 -0700,
> Greg Kroah-Hartman wrote:
> >
> > ---------------
> > Note, this is the LAST 3.9-stable kernel release that I will be doing.
> > Please move to the 3.10-stable branch as soon as possible.
> > ---------------
> >
> > This is the start of the stable review cycle for the 3.9.11 release.
> > There are 38 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Jul 21 05:20:01 UTC 2013.
> > Anything received after that time might be too late.
>
> This kernel can be built and boot without any problem.
> Building a kernel with this kernel also works fine.
>
> - Build Machine: debian jessy x86_64
> CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
> memory: 8GB
>
> - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
> vCPU: x2
> memory: 2GB

Thanks for testing this, and the other kernels, out and letting me know.

greg k-h