* [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
This is the start of the longterm review cycle for the 2.6.32.68 release.
All patches will be posted as a response to this one. If anyone has any
issue with these being applied, please let me know. If anyone is a
maintainer of the proper subsystem, and wants to add a Signed-off-by: line
to the patch, please respond with it. If anyone thinks some important
patches are missing and should be added prior to the release, please
report them quickly with their respective mainline commit IDs.
Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
Anything received after that time might be too late. If someone
wants a bit more time for a deeper review, please let me know.
NOTE: 2.6.32 is approaching end of support. There will probably be one
or maybe two other versions issued in the next 3-6 months, and that will
be all, at least for me. Adding to this the time it can take to validate
and deploy in some environments, it probably makes sense to start to
think about switching to another longterm branch. 3.2 and 3.4 are good
candidates for those seeking rock-solid versions. Longterm branches and
their projected EOLs are listed here :
https://www.kernel.org/category/releases.html
The whole patch series can be found in one patch at :
https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
The shortlog and diffstat are appended below.
Thanks,
Willy
===============
Al Viro (1):
sg_start_req(): make sure that there's not too many elements in iovec
Alexander Sverdlin (2):
sctp: Fix race between OOTB responce and route removal
MIPS: Octeon: Remove udelay() causing huge IRQ latency
Andy Lutomirski (1):
x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
Anton Blanchard (1):
powerpc: Align TOC to 256 bytes
Ben Hutchings (2):
pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
x86_64: Fix strnlen_user() to not touch memory after specified maximum
Catalin Marinas (1):
mm: kmemleak: allow safe memory scanning during kmemleak disabling
Dan Carpenter (1):
memstick: mspro_block: add missing curly braces
Darrick J. Wong (1):
jbd2: fix r_count overflows leading to buffer overflow in journal recovery
Dave Olson (1):
powerpc: Fix missing L2 cache size in /sys/devices/system/cpu
David S. Miller (2):
dccp: Fix compile warning in probe code.
ipv6: Fix return of xfrm6_tunnel_rcv()
Dr. David Alan Gilbert (1):
dmaengine: fix missing 'cnt' in ?: in dmatest
Eric Dumazet (1):
udp: fix behavior of wrong checksums
Feng Tang (1):
x86/reboot: Fix a warning message triggered by stop_other_cpus()
Gerrit Renker (1):
dccp: fix auto-loading of dccp(_probe)
Heiko Carstens (2):
s390/hibernate: fix save and restore of kernel text section
s390/process: fix sfpc inline assembly
Jan Kara (7):
udf: Verify i_size when loading inode
udf: Verify symlink size before loading it
udf: Treat symlink component of type 2 as /
udf: Check path length when reading symlink
udf: Check component length before reading it
Remove repeated loads blocksize
udf: Check length of extended attributes and allocation descriptors
Jeff Layton (1):
nfs: increase size of EXCHANGE_ID name string buffer
Jesper Dangaard Brouer (1):
pktgen: adjust spacing in proc file interface output
Jiri Kosina (1):
HID: fix a couple of off-by-ones
Jiri Slaby (1):
TTY: drop driver reference in tty_open fail path
Kirill A. Shutemov (1):
mm: avoid setting up anonymous pages into file mapping
Lars Persson (1):
MIPS: Fix race condition in lazy cache flushing.
Lior Amsalem (1):
dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup
Malcolm Priestley (1):
staging: vt6655: device_rx_srv check sk_buff is NULL
Mark Grondona (1):
__ptrace_may_access() should not deny sub-threads
Mark Hounschell (1):
sd: Disable support for 256 byte/sector disks
Markus F.X.J. Oberhumer (1):
crypto: testmgr - update LZO compression test vectors
Mauro Carvalho Chehab (2):
s5h1420: fix a buffer overflow when checking userspace params
cx24116: fix a buffer overflow when checking userspace params
Michael Halcrow (1):
eCryptfs: Remove buggy and unnecessary write in file name decode routine
Miklos Szeredi (1):
fuse: initialize fc->release before calling it
Mikulas Patocka (1):
libata: increase the timeout when setting transfer mode
NeilBrown (1):
md/raid5: don't record new size if resize_stripes fails.
Oleg Nesterov (2):
ptrace: fix race between ptrace_resume() and wait_task_stopped()
include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid
Olga Kornievskaia (1):
fixing infinite OPEN loop in 4.0 stateid recovery
Pablo Neira Ayuso (1):
netlink: fix possible spoofing from non-root processes
Peter Zijlstra (1):
hrtimer: Allow concurrent hrtimer_start() for self restarting timers
Ralf Baechle (3):
MIPS: Fix cpu_has_mips_r2_exec_hazard.
MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
NET: ROSE: Don't dereference NULL neighbour pointer.
Rusty Russell (1):
lguest: fix out-by-one error in address checking.
Ryan Underwood (1):
Disable write buffering on Toshiba ToPIC95
Sabrina Dubroca (1):
e1000: add dummy allocator to fix race condition between mtu change and netpoll
Sasha Levin (1):
fs, omfs: add NULL terminator in the end up the token list
Steven Rostedt (1):
tracing: Have filter check for balanced ops
Steven Rostedt (Red Hat) (2):
tracing/filter: Do not WARN on operand count going below zero
tracing/filter: Do not allow infix to exceed end of string
Theodore Ts'o (2):
ext4: fix race between truncate and __ext4_journalled_writepage()
ext4: call sync_blockdev() before invalidate_bdev() in put_super()
Trond Myklebust (1):
SUNRPC: Fix a memory leak in the backchannel code
Wang Weidong (1):
dccp: catch failed request_module call in dccp_probe init
arch/mips/include/asm/cacheflush.h | 38 +++++++-----
arch/mips/include/asm/cpu-features.h | 26 +++++++-
.../asm/mach-cavium-octeon/cpu-feature-overrides.h | 1 -
arch/mips/include/asm/octeon/pci-octeon.h | 3 -
arch/mips/mm/cache.c | 12 ++++
arch/mips/pci/pci-octeon.c | 6 --
arch/mips/pci/pcie-octeon.c | 3 -
arch/powerpc/kernel/cacheinfo.c | 43 ++++++++++---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
arch/s390/kernel/process.c | 2 +-
arch/s390/kernel/suspend.c | 6 ++
arch/x86/kernel/reboot.c | 7 ++-
arch/x86/lib/usercopy_64.c | 2 +-
arch/x86/xen/enlighten.c | 40 ++++++++++++
crypto/testmgr.h | 38 ++++++------
drivers/ata/libata-core.c | 3 +-
drivers/char/tty_io.c | 1 +
drivers/dma/dmatest.c | 2 +-
drivers/dma/mv_xor.c | 72 ++++++++++++++--------
drivers/dma/mv_xor.h | 1 +
drivers/hid/hid-cherry.c | 2 +-
drivers/hid/hid-kye.c | 2 +-
drivers/hid/hid-lg.c | 2 +-
drivers/hid/hid-monterey.c | 2 +-
drivers/hid/hid-petalynx.c | 2 +-
drivers/hid/hid-sunplus.c | 2 +-
drivers/lguest/core.c | 2 +-
drivers/md/raid5.c | 3 +-
drivers/media/dvb/frontends/cx24116.c | 8 +--
drivers/media/dvb/frontends/s5h1420.c | 2 +-
drivers/memstick/core/mspro_block.c | 3 +-
drivers/net/e1000/e1000_main.c | 10 ++-
drivers/pcmcia/topic.h | 16 +++++
drivers/scsi/sd.c | 19 ++----
drivers/scsi/sg.c | 3 +
drivers/staging/vt6655/device_main.c | 4 ++
fs/ecryptfs/crypto.c | 1 -
fs/ext4/inode.c | 20 +++++-
fs/ext4/super.c | 1 +
fs/fuse/inode.c | 2 +-
fs/jbd2/recovery.c | 7 ++-
fs/nfs/nfs4state.c | 2 +
fs/omfs/inode.c | 3 +-
fs/pipe.c | 55 ++++++++++-------
fs/udf/dir.c | 3 +-
fs/udf/inode.c | 46 +++++++++++---
fs/udf/namei.c | 3 +-
fs/udf/symlink.c | 67 ++++++++++++++++----
fs/udf/udfdecl.h | 3 +-
fs/udf/unicode.c | 28 +++++----
include/linux/nfs_xdr.h | 2 +-
include/linux/sched.h | 8 +--
kernel/hrtimer.c | 12 +++-
kernel/ptrace.c | 22 ++++++-
kernel/trace/trace_events_filter.c | 18 +++++-
mm/kmemleak.c | 14 ++++-
mm/memory.c | 13 ++--
net/core/pktgen.c | 2 +-
net/dccp/probe.c | 9 ++-
net/ipv4/udp.c | 6 +-
net/ipv6/udp.c | 6 +-
net/ipv6/xfrm6_tunnel.c | 2 +-
net/netlink/af_netlink.c | 3 +-
net/rose/af_rose.c | 3 +-
net/sctp/output.c | 4 +-
net/sunrpc/backchannel_rqst.c | 2 +-
66 files changed, 541 insertions(+), 215 deletions(-)
--
^ permalink raw reply [flat|nested] 87+ messages in thread* [PATCH 2.6.32 01/62] pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@decadent.org.uk>
pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec,
the first time atomically and the second time not. The second attempt
needs to continue from the iovec position, pipe buffer offset and
remaining length where the first attempt failed, but currently the
pipe buffer offset and remaining length are reset. This will corrupt
the piped data (possibly also leading to an information leak between
processes) and may also corrupt kernel memory.
This was fixed upstream by commits f0d1bec9d58d ("new helper:
copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to
copy_page_to_iter()"), but those aren't suitable for stable. This fix
for older kernel versions was made by Seth Jennings for RHEL and I
have extracted it from their update.
CVE-2015-1805
References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 75cf667b7fac08a7b21694adca7dff07361be68a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/pipe.c | 55 ++++++++++++++++++++++++++++++++-----------------------
1 file changed, 32 insertions(+), 23 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index d0cc080..daa71ea 100644
--- a/fs/pipe.c
+++ b/fs/pipe.c
@@ -90,25 +90,27 @@ void pipe_wait(struct pipe_inode_info *pipe)
}
static int
-pipe_iov_copy_from_user(void *to, struct iovec *iov, unsigned long len,
- int atomic)
+pipe_iov_copy_from_user(void *addr, int *offset, struct iovec *iov,
+ size_t *remaining, int atomic)
{
unsigned long copy;
- while (len > 0) {
+ while (*remaining > 0) {
while (!iov->iov_len)
iov++;
- copy = min_t(unsigned long, len, iov->iov_len);
+ copy = min_t(unsigned long, *remaining, iov->iov_len);
if (atomic) {
- if (__copy_from_user_inatomic(to, iov->iov_base, copy))
+ if (__copy_from_user_inatomic(addr + *offset,
+ iov->iov_base, copy))
return -EFAULT;
} else {
- if (copy_from_user(to, iov->iov_base, copy))
+ if (copy_from_user(addr + *offset,
+ iov->iov_base, copy))
return -EFAULT;
}
- to += copy;
- len -= copy;
+ *offset += copy;
+ *remaining -= copy;
iov->iov_base += copy;
iov->iov_len -= copy;
}
@@ -116,25 +118,27 @@ pipe_iov_copy_from_user(void *to, struct iovec *iov, unsigned long len,
}
static int
-pipe_iov_copy_to_user(struct iovec *iov, const void *from, unsigned long len,
- int atomic)
+pipe_iov_copy_to_user(struct iovec *iov, void *addr, int *offset,
+ size_t *remaining, int atomic)
{
unsigned long copy;
- while (len > 0) {
+ while (*remaining > 0) {
while (!iov->iov_len)
iov++;
- copy = min_t(unsigned long, len, iov->iov_len);
+ copy = min_t(unsigned long, *remaining, iov->iov_len);
if (atomic) {
- if (__copy_to_user_inatomic(iov->iov_base, from, copy))
+ if (__copy_to_user_inatomic(iov->iov_base,
+ addr + *offset, copy))
return -EFAULT;
} else {
- if (copy_to_user(iov->iov_base, from, copy))
+ if (copy_to_user(iov->iov_base,
+ addr + *offset, copy))
return -EFAULT;
}
- from += copy;
- len -= copy;
+ *offset += copy;
+ *remaining -= copy;
iov->iov_base += copy;
iov->iov_len -= copy;
}
@@ -354,7 +358,7 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
struct pipe_buffer *buf = pipe->bufs + curbuf;
const struct pipe_buf_operations *ops = buf->ops;
void *addr;
- size_t chars = buf->len;
+ size_t chars = buf->len, remaining;
int error, atomic;
if (chars > total_len)
@@ -368,9 +372,11 @@ pipe_read(struct kiocb *iocb, const struct iovec *_iov,
}
atomic = !iov_fault_in_pages_write(iov, chars);
+ remaining = chars;
redo:
addr = ops->map(pipe, buf, atomic);
- error = pipe_iov_copy_to_user(iov, addr + buf->offset, chars, atomic);
+ error = pipe_iov_copy_to_user(iov, addr, &buf->offset,
+ &remaining, atomic);
ops->unmap(pipe, buf, addr);
if (unlikely(error)) {
/*
@@ -385,7 +391,6 @@ redo:
break;
}
ret += chars;
- buf->offset += chars;
buf->len -= chars;
if (!buf->len) {
buf->ops = NULL;
@@ -480,6 +485,7 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
if (ops->can_merge && offset + chars <= PAGE_SIZE) {
int error, atomic = 1;
void *addr;
+ size_t remaining = chars;
error = ops->confirm(pipe, buf);
if (error)
@@ -488,8 +494,8 @@ pipe_write(struct kiocb *iocb, const struct iovec *_iov,
iov_fault_in_pages_read(iov, chars);
redo1:
addr = ops->map(pipe, buf, atomic);
- error = pipe_iov_copy_from_user(offset + addr, iov,
- chars, atomic);
+ error = pipe_iov_copy_from_user(addr, &offset, iov,
+ &remaining, atomic);
ops->unmap(pipe, buf, addr);
ret = error;
do_wakeup = 1;
@@ -524,6 +530,8 @@ redo1:
struct page *page = pipe->tmp_page;
char *src;
int error, atomic = 1;
+ int offset = 0;
+ size_t remaining;
if (!page) {
page = alloc_page(GFP_HIGHUSER);
@@ -544,14 +552,15 @@ redo1:
chars = total_len;
iov_fault_in_pages_read(iov, chars);
+ remaining = chars;
redo2:
if (atomic)
src = kmap_atomic(page, KM_USER0);
else
src = kmap(page);
- error = pipe_iov_copy_from_user(src, iov, chars,
- atomic);
+ error = pipe_iov_copy_from_user(src, &offset, iov,
+ &remaining, atomic);
if (atomic)
kunmap_atomic(src, KM_USER0);
else
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 02/62] sg_start_req(): make sure that theres not too many elements in iovec
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Al Viro, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <viro@zeniv.linux.org.uk>
commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream.
unfortunately, allowing an arbitrary 16bit value means a possibility of
overflow in the calculation of total number of pages in bio_map_user_iov() -
we rely on there being no more than PAGE_SIZE members of sum in the
first loop there. If that sum wraps around, we end up allocating
too small array of pointers to pages and it's easy to overflow it in
the second loop.
X-Coverup: TINC (and there's no lumber cartel either)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit
fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have
that function.]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 07213eed86c17c544bb10568fc04e49e03730ab7)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/scsi/sg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 040f751..f51e531 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1662,6 +1662,9 @@ static int sg_start_req(Sg_request *srp, unsigned char *cmd)
md->from_user = 0;
}
+ if (unlikely(iov_count > UIO_MAXIOV))
+ return -EINVAL;
+
if (iov_count) {
int len, size = sizeof(struct sg_iovec) * iov_count;
struct iovec *iov;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 03/62] crypto: testmgr - update LZO compression test vectors
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Markus F.X.J. Oberhumer, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Markus F.X.J. Oberhumer" <markus@oberhumer.com>
Update the LZO compression test vectors according to the latest compressor
version.
Signed-off-by: Markus F.X.J. Oberhumer <markus@oberhumer.com>
(cherry picked from commit 0ec7382036922be063b515b2a3f1d6f7a607392c)
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
crypto/testmgr.h | 38 ++++++++++++++++++++------------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 9963b18..2d87892 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -9237,38 +9237,40 @@ static struct pcomp_testvec zlib_decomp_tv_template[] = {
static struct comp_testvec lzo_comp_tv_template[] = {
{
.inlen = 70,
- .outlen = 46,
+ .outlen = 57,
.input = "Join us now and share the software "
"Join us now and share the software ",
.output = "\x00\x0d\x4a\x6f\x69\x6e\x20\x75"
- "\x73\x20\x6e\x6f\x77\x20\x61\x6e"
- "\x64\x20\x73\x68\x61\x72\x65\x20"
- "\x74\x68\x65\x20\x73\x6f\x66\x74"
- "\x77\x70\x01\x01\x4a\x6f\x69\x6e"
- "\x3d\x88\x00\x11\x00\x00",
+ "\x73\x20\x6e\x6f\x77\x20\x61\x6e"
+ "\x64\x20\x73\x68\x61\x72\x65\x20"
+ "\x74\x68\x65\x20\x73\x6f\x66\x74"
+ "\x77\x70\x01\x32\x88\x00\x0c\x65"
+ "\x20\x74\x68\x65\x20\x73\x6f\x66"
+ "\x74\x77\x61\x72\x65\x20\x11\x00"
+ "\x00",
}, {
.inlen = 159,
- .outlen = 133,
+ .outlen = 131,
.input = "This document describes a compression method based on the LZO "
"compression algorithm. This document defines the application of "
"the LZO algorithm used in UBIFS.",
- .output = "\x00\x2b\x54\x68\x69\x73\x20\x64"
+ .output = "\x00\x2c\x54\x68\x69\x73\x20\x64"
"\x6f\x63\x75\x6d\x65\x6e\x74\x20"
"\x64\x65\x73\x63\x72\x69\x62\x65"
"\x73\x20\x61\x20\x63\x6f\x6d\x70"
"\x72\x65\x73\x73\x69\x6f\x6e\x20"
"\x6d\x65\x74\x68\x6f\x64\x20\x62"
"\x61\x73\x65\x64\x20\x6f\x6e\x20"
- "\x74\x68\x65\x20\x4c\x5a\x4f\x2b"
- "\x8c\x00\x0d\x61\x6c\x67\x6f\x72"
- "\x69\x74\x68\x6d\x2e\x20\x20\x54"
- "\x68\x69\x73\x2a\x54\x01\x02\x66"
- "\x69\x6e\x65\x73\x94\x06\x05\x61"
- "\x70\x70\x6c\x69\x63\x61\x74\x76"
- "\x0a\x6f\x66\x88\x02\x60\x09\x27"
- "\xf0\x00\x0c\x20\x75\x73\x65\x64"
- "\x20\x69\x6e\x20\x55\x42\x49\x46"
- "\x53\x2e\x11\x00\x00",
+ "\x74\x68\x65\x20\x4c\x5a\x4f\x20"
+ "\x2a\x8c\x00\x09\x61\x6c\x67\x6f"
+ "\x72\x69\x74\x68\x6d\x2e\x20\x20"
+ "\x2e\x54\x01\x03\x66\x69\x6e\x65"
+ "\x73\x20\x74\x06\x05\x61\x70\x70"
+ "\x6c\x69\x63\x61\x74\x76\x0a\x6f"
+ "\x66\x88\x02\x60\x09\x27\xf0\x00"
+ "\x0c\x20\x75\x73\x65\x64\x20\x69"
+ "\x6e\x20\x55\x42\x49\x46\x53\x2e"
+ "\x11\x00\x00",
},
};
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 04/62] TTY: drop driver reference in tty_open fail path
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jiri Slaby, Alan Cox, Sukadev Bhattiprolu, Greg Kroah-Hartman,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby <jslaby@suse.cz>
commit c290f8358acaeffd8e0c551ddcc24d1206143376 upstream.
When tty_driver_lookup_tty fails in tty_open, we forget to drop a
reference to the tty driver. This was added by commit 4a2b5fddd5 (Move
tty lookup/reopen to caller).
Fix that by adding tty_driver_kref_put to the fail path.
I will refactor the code later. This is for the ease of backporting to
stable.
Introduced-in: v2.6.28-rc2
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[bwh: Backported to 2.6.32: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2011-5321
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/char/tty_io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index cbdd1698..6c71534 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1779,6 +1779,7 @@ got_driver:
if (IS_ERR(tty)) {
mutex_unlock(&tty_mutex);
+ tty_driver_kref_put(driver);
return PTR_ERR(tty);
}
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 05/62] netlink: fix possible spoofing from non-root processes
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Pablo Neira Ayuso, David S. Miller, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <pablo@netfilter.org>
commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef upstream.
Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.
The userspace process usually verifies the legitimate origin in
two ways:
a) Socket credentials. If UID != 0, then the message comes from
some ilegitimate process and the message needs to be dropped.
b) Netlink portID. In general, portID == 0 means that the origin
of the messages comes from the kernel. Thus, discarding any
message not coming from the kernel.
However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.
Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.
This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.
Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 2.6.32:
- Adjust context
- NETLINK_USERSOCK does not exist, so drop that part]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2012-6689
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/netlink/af_netlink.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 39a6d5d..2235885 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1303,7 +1303,8 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
return -EINVAL;
dst_pid = addr->nl_pid;
dst_group = ffs(addr->nl_groups);
- if (dst_group && !netlink_capable(sock, NL_NONROOT_SEND))
+ if ((dst_group || dst_pid) &&
+ !netlink_capable(sock, NL_NONROOT_SEND))
return -EPERM;
} else {
dst_pid = nlk->dst_pid;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 06/62] eCryptfs: Remove buggy and unnecessary write in file name decode routine
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael Halcrow, Dmitry Chernenkov, Kees Cook, Tyler Hicks,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Michael Halcrow <mhalcrow@google.com>
commit 942080643bce061c3dd9d5718d3b745dcb39a8bc upstream.
Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the
end of the allocated buffer during encrypted filename decoding. This
fix corrects the issue by getting rid of the unnecessary 0 write when
the current bit offset is 2.
Signed-off-by: Michael Halcrow <mhalcrow@google.com>
Reported-by: Dmitry Chernenkov <dmitryc@google.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-9683
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/ecryptfs/crypto.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 7e164bb..cc57904 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -2088,7 +2088,6 @@ ecryptfs_decode_from_filename(unsigned char *dst, size_t *dst_size,
break;
case 2:
dst[dst_byte_offset++] |= (src_byte);
- dst[dst_byte_offset] = 0;
current_bit_offset = 0;
break;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 07/62] HID: fix a couple of off-by-ones
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ben Hawkes, Benjamin Tissoires, Jiri Kosina, Ben Hutchings,
Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Kosina <jkosina@suse.cz>
commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream.
There are a few very theoretical off-by-one bugs in report descriptor size
checking when performing a pre-parsing fixup. Fix those.
Reported-by: Ben Hawkes <hawkes@google.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[bwh: Backported to 2.6.32:
- Adjust context
- Drop change to a quirk in hid-lg.c that doesn't exist here]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-3184
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/hid/hid-cherry.c | 2 +-
drivers/hid/hid-kye.c | 2 +-
drivers/hid/hid-lg.c | 2 +-
drivers/hid/hid-monterey.c | 2 +-
drivers/hid/hid-petalynx.c | 2 +-
drivers/hid/hid-sunplus.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hid/hid-cherry.c b/drivers/hid/hid-cherry.c
index 7e597d7..bfce74e 100644
--- a/drivers/hid/hid-cherry.c
+++ b/drivers/hid/hid-cherry.c
@@ -29,7 +29,7 @@
static void ch_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 17 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
+ if (rsize >= 18 && rdesc[11] == 0x3c && rdesc[12] == 0x02) {
dev_info(&hdev->dev, "fixing up Cherry Cymotion report "
"descriptor\n");
rdesc[11] = rdesc[16] = 0xff;
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index f887171..30f723b 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -26,7 +26,7 @@
static void kye_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 74 &&
+ if (rsize >= 75 &&
rdesc[61] == 0x05 && rdesc[62] == 0x08 &&
rdesc[63] == 0x19 && rdesc[64] == 0x08 &&
rdesc[65] == 0x29 && rdesc[66] == 0x0f &&
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index 0f870a3..6d34374 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -44,7 +44,7 @@ static void lg_report_fixup(struct hid_device *hdev, __u8 *rdesc,
{
unsigned long quirks = (unsigned long)hid_get_drvdata(hdev);
- if ((quirks & LG_RDESC) && rsize >= 90 && rdesc[83] == 0x26 &&
+ if ((quirks & LG_RDESC) && rsize >= 91 && rdesc[83] == 0x26 &&
rdesc[84] == 0x8c && rdesc[85] == 0x02) {
dev_info(&hdev->dev, "fixing up Logitech keyboard report "
"descriptor\n");
diff --git a/drivers/hid/hid-monterey.c b/drivers/hid/hid-monterey.c
index 2cd05aa..eaa2ac8 100644
--- a/drivers/hid/hid-monterey.c
+++ b/drivers/hid/hid-monterey.c
@@ -25,7 +25,7 @@
static void mr_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 30 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
+ if (rsize >= 31 && rdesc[29] == 0x05 && rdesc[30] == 0x09) {
dev_info(&hdev->dev, "fixing up button/consumer in HID report "
"descriptor\n");
rdesc[30] = 0x0c;
diff --git a/drivers/hid/hid-petalynx.c b/drivers/hid/hid-petalynx.c
index 500fbd0..38fa74d 100644
--- a/drivers/hid/hid-petalynx.c
+++ b/drivers/hid/hid-petalynx.c
@@ -26,7 +26,7 @@
static void pl_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 60 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
+ if (rsize >= 62 && rdesc[39] == 0x2a && rdesc[40] == 0xf5 &&
rdesc[41] == 0x00 && rdesc[59] == 0x26 &&
rdesc[60] == 0xf9 && rdesc[61] == 0x00) {
dev_info(&hdev->dev, "fixing up Petalynx Maxter Remote report "
diff --git a/drivers/hid/hid-sunplus.c b/drivers/hid/hid-sunplus.c
index 438107d..ac0d488 100644
--- a/drivers/hid/hid-sunplus.c
+++ b/drivers/hid/hid-sunplus.c
@@ -25,7 +25,7 @@
static void sp_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int rsize)
{
- if (rsize >= 107 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
+ if (rsize >= 112 && rdesc[104] == 0x26 && rdesc[105] == 0x80 &&
rdesc[106] == 0x03) {
dev_info(&hdev->dev, "fixing up Sunplus Wireless Desktop "
"report descriptor\n");
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 08/62] udf: Verify i_size when loading inode
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Carl Henrik Lunde, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit e159332b9af4b04d882dbcfe1bb0117f0a6d4b58 upstream.
Verify that inode size is sane when loading inode with data stored in
ICB. Otherwise we may get confused later when working with the inode and
inode size is too big.
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 2.6.32: on error, call make_bad_inode() then return]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-9728, CVE-2014-9729
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/inode.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 11c291e..7901ad7 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1286,6 +1286,24 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
iinfo->i_lenEAttr;
}
+ /* Sanity checks for files in ICB so that we don't get confused later */
+ if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
+ /*
+ * For file in ICB data is stored in allocation descriptor
+ * so sizes should match
+ */
+ if (iinfo->i_lenAlloc != inode->i_size) {
+ make_bad_inode(inode);
+ return;
+ }
+ /* File in ICB has to fit in there... */
+ if (inode->i_size > inode->i_sb->s_blocksize -
+ udf_file_entry_alloc_offset(inode)) {
+ make_bad_inode(inode);
+ return;
+ }
+ }
+
switch (fe->icbTag.fileType) {
case ICBTAG_FILE_TYPE_DIRECTORY:
inode->i_op = &udf_dir_inode_operations;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 09/62] udf: Verify symlink size before loading it
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Carl Henrik Lunde, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit a1d47b262952a45aae62bd49cfaf33dd76c11a2c upstream.
UDF specification allows arbitrarily large symlinks. However we support
only symlinks at most one block large. Check the length of the symlink
so that we don't access memory beyond end of the symlink block.
Reported-by: Carl Henrik Lunde <chlunde@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 2.6.32: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-9728
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/symlink.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index c3265e1..e28a902 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -76,10 +76,16 @@ static int udf_symlink_filler(struct file *file, struct page *page)
struct inode *inode = page->mapping->host;
struct buffer_head *bh = NULL;
char *symlink;
- int err = -EIO;
+ int err;
char *p = kmap(page);
struct udf_inode_info *iinfo;
+ /* We don't support symlinks longer than one block */
+ if (inode->i_size > inode->i_sb->s_blocksize) {
+ err = -ENAMETOOLONG;
+ goto out_unmap;
+ }
+
lock_kernel();
iinfo = UDF_I(inode);
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
@@ -87,8 +93,10 @@ static int udf_symlink_filler(struct file *file, struct page *page)
} else {
bh = sb_bread(inode->i_sb, udf_block_map(inode, 0));
- if (!bh)
- goto out;
+ if (!bh) {
+ err = -EIO;
+ goto out_unlock_inode;
+ }
symlink = bh->b_data;
}
@@ -102,9 +110,10 @@ static int udf_symlink_filler(struct file *file, struct page *page)
unlock_page(page);
return 0;
-out:
+out_unlock_inode:
unlock_kernel();
SetPageError(page);
+out_unmap:
kunmap(page);
unlock_page(page);
return err;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 11/62] udf: Check path length when reading symlink
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Carl Henrik Lunde, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream.
Symlink reading code does not check whether the resulting path fits into
the page provided by the generic code. This isn't as easy as just
checking the symlink size because of various encoding conversions we
perform on path. So we have to check whether there is still enough space
in the buffer on the fly.
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 2.6.32: adjust context, indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-9731
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/dir.c | 3 ++-
fs/udf/namei.c | 3 ++-
fs/udf/symlink.c | 31 ++++++++++++++++++++++++++-----
fs/udf/udfdecl.h | 3 ++-
fs/udf/unicode.c | 28 ++++++++++++++++------------
5 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/fs/udf/dir.c b/fs/udf/dir.c
index 61d9a76..1c551ea 100644
--- a/fs/udf/dir.c
+++ b/fs/udf/dir.c
@@ -164,7 +164,8 @@ static int do_udf_readdir(struct inode *dir, struct file *filp,
struct kernel_lb_addr tloc = lelb_to_cpu(cfi.icb.extLocation);
iblock = udf_get_lb_pblock(dir->i_sb, &tloc, 0);
- flen = udf_get_filename(dir->i_sb, nameptr, fname, lfi);
+ flen = udf_get_filename(dir->i_sb, nameptr, lfi, fname,
+ UDF_NAME_LEN);
dt_type = DT_UNKNOWN;
}
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index b754151..0a6eb3f 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -237,7 +237,8 @@ static struct fileIdentDesc *udf_find_entry(struct inode *dir,
if (!lfi)
continue;
- flen = udf_get_filename(dir->i_sb, nameptr, fname, lfi);
+ flen = udf_get_filename(dir->i_sb, nameptr, lfi, fname,
+ UDF_NAME_LEN);
if (flen && udf_match(flen, fname, child->len, child->name))
goto out_ok;
}
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index 2d60484..500c146 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -32,13 +32,16 @@
#include <linux/buffer_head.h>
#include "udf_i.h"
-static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
- char *to)
+static int udf_pc_to_char(struct super_block *sb, char *from,
+ int fromlen, char *to, int tolen)
{
struct pathComponent *pc;
int elen = 0;
+ int comp_len;
char *p = to;
+ /* Reserve one byte for terminating \0 */
+ tolen--;
while (elen < fromlen) {
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
@@ -51,22 +54,37 @@ static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
break;
/* Fall through */
case 2:
+ if (tolen == 0)
+ return -ENAMETOOLONG;
p = to;
*p++ = '/';
+ tolen--;
break;
case 3:
+ if (tolen < 3)
+ return -ENAMETOOLONG;
memcpy(p, "../", 3);
p += 3;
+ tolen -= 3;
break;
case 4:
+ if (tolen < 2)
+ return -ENAMETOOLONG;
memcpy(p, "./", 2);
p += 2;
+ tolen -= 2;
/* that would be . - just ignore */
break;
case 5:
- p += udf_get_filename(sb, pc->componentIdent, p,
- pc->lengthComponentIdent);
+ comp_len = udf_get_filename(sb, pc->componentIdent,
+ pc->lengthComponentIdent,
+ p, tolen);
+ p += comp_len;
+ tolen -= comp_len;
+ if (tolen == 0)
+ return -ENAMETOOLONG;
*p++ = '/';
+ tolen--;
break;
}
elen += sizeof(struct pathComponent) + pc->lengthComponentIdent;
@@ -75,6 +93,7 @@ static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
p[-1] = '\0';
else
p[0] = '\0';
+ return 0;
}
static int udf_symlink_filler(struct file *file, struct page *page)
@@ -107,8 +126,10 @@ static int udf_symlink_filler(struct file *file, struct page *page)
symlink = bh->b_data;
}
- udf_pc_to_char(inode->i_sb, symlink, inode->i_size, p);
+ err = udf_pc_to_char(inode->i_sb, symlink, inode->i_size, p, PAGE_SIZE);
brelse(bh);
+ if (err)
+ goto out_unlock_inode;
unlock_kernel();
SetPageUptodate(page);
diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
index 8d46f42..1b56330 100644
--- a/fs/udf/udfdecl.h
+++ b/fs/udf/udfdecl.h
@@ -200,7 +200,8 @@ udf_get_lb_pblock(struct super_block *sb, struct kernel_lb_addr *loc,
}
/* unicode.c */
-extern int udf_get_filename(struct super_block *, uint8_t *, uint8_t *, int);
+extern int udf_get_filename(struct super_block *, uint8_t *, int, uint8_t *,
+ int);
extern int udf_put_filename(struct super_block *, const uint8_t *, uint8_t *,
int);
extern int udf_build_ustr(struct ustr *, dstring *, int);
diff --git a/fs/udf/unicode.c b/fs/udf/unicode.c
index cefa8c8..c690157 100644
--- a/fs/udf/unicode.c
+++ b/fs/udf/unicode.c
@@ -27,7 +27,8 @@
#include "udf_sb.h"
-static int udf_translate_to_linux(uint8_t *, uint8_t *, int, uint8_t *, int);
+static int udf_translate_to_linux(uint8_t *, int, uint8_t *, int, uint8_t *,
+ int);
static int udf_char_to_ustr(struct ustr *dest, const uint8_t *src, int strlen)
{
@@ -332,8 +333,8 @@ try_again:
return u_len + 1;
}
-int udf_get_filename(struct super_block *sb, uint8_t *sname, uint8_t *dname,
- int flen)
+int udf_get_filename(struct super_block *sb, uint8_t *sname, int slen,
+ uint8_t *dname, int dlen)
{
struct ustr *filename, *unifilename;
int len = 0;
@@ -346,7 +347,7 @@ int udf_get_filename(struct super_block *sb, uint8_t *sname, uint8_t *dname,
if (!unifilename)
goto out1;
- if (udf_build_ustr_exact(unifilename, sname, flen))
+ if (udf_build_ustr_exact(unifilename, sname, slen))
goto out2;
if (UDF_QUERY_FLAG(sb, UDF_FLAG_UTF8)) {
@@ -365,7 +366,8 @@ int udf_get_filename(struct super_block *sb, uint8_t *sname, uint8_t *dname,
} else
goto out2;
- len = udf_translate_to_linux(dname, filename->u_name, filename->u_len,
+ len = udf_translate_to_linux(dname, dlen,
+ filename->u_name, filename->u_len,
unifilename->u_name, unifilename->u_len);
out2:
kfree(unifilename);
@@ -402,10 +404,12 @@ int udf_put_filename(struct super_block *sb, const uint8_t *sname,
#define EXT_MARK '.'
#define CRC_MARK '#'
#define EXT_SIZE 5
+/* Number of chars we need to store generated CRC to make filename unique */
+#define CRC_LEN 5
-static int udf_translate_to_linux(uint8_t *newName, uint8_t *udfName,
- int udfLen, uint8_t *fidName,
- int fidNameLen)
+static int udf_translate_to_linux(uint8_t *newName, int newLen,
+ uint8_t *udfName, int udfLen,
+ uint8_t *fidName, int fidNameLen)
{
int index, newIndex = 0, needsCRC = 0;
int extIndex = 0, newExtIndex = 0, hasExt = 0;
@@ -439,7 +443,7 @@ static int udf_translate_to_linux(uint8_t *newName, uint8_t *udfName,
newExtIndex = newIndex;
}
}
- if (newIndex < 256)
+ if (newIndex < newLen)
newName[newIndex++] = curr;
else
needsCRC = 1;
@@ -467,13 +471,13 @@ static int udf_translate_to_linux(uint8_t *newName, uint8_t *udfName,
}
ext[localExtIndex++] = curr;
}
- maxFilenameLen = 250 - localExtIndex;
+ maxFilenameLen = newLen - CRC_LEN - localExtIndex;
if (newIndex > maxFilenameLen)
newIndex = maxFilenameLen;
else
newIndex = newExtIndex;
- } else if (newIndex > 250)
- newIndex = 250;
+ } else if (newIndex > newLen - CRC_LEN)
+ newIndex = newLen - CRC_LEN;
newName[newIndex++] = CRC_MARK;
valueCRC = crc_itu_t(0, fidName, fidNameLen);
newName[newIndex++] = hexChar[(valueCRC & 0xf000) >> 12];
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 12/62] udf: Check component length before reading it
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Carl Henrik Lunde, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream.
Check that length specified in a component of a symlink fits in the
input buffer we are reading. Also properly ignore component length for
component types that do not use it. Otherwise we read memory after end
of buffer for corrupted udf image.
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2014-9728, CVE-2014-9730
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/symlink.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index 500c146..c45bb43 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -44,14 +44,17 @@ static int udf_pc_to_char(struct super_block *sb, char *from,
tolen--;
while (elen < fromlen) {
pc = (struct pathComponent *)(from + elen);
+ elen += sizeof(struct pathComponent);
switch (pc->componentType) {
case 1:
/*
* Symlink points to some place which should be agreed
* upon between originator and receiver of the media. Ignore.
*/
- if (pc->lengthComponentIdent > 0)
+ if (pc->lengthComponentIdent > 0) {
+ elen += pc->lengthComponentIdent;
break;
+ }
/* Fall through */
case 2:
if (tolen == 0)
@@ -76,6 +79,9 @@ static int udf_pc_to_char(struct super_block *sb, char *from,
/* that would be . - just ignore */
break;
case 5:
+ elen += pc->lengthComponentIdent;
+ if (elen > fromlen)
+ return -EIO;
comp_len = udf_get_filename(sb, pc->componentIdent,
pc->lengthComponentIdent,
p, tolen);
@@ -87,7 +93,6 @@ static int udf_pc_to_char(struct super_block *sb, char *from,
tolen--;
break;
}
- elen += sizeof(struct pathComponent) + pc->lengthComponentIdent;
}
if (p > to + 1)
p[-1] = '\0';
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 13/62] Remove repeated loads blocksize
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 1:42 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit 79144954278d4bb5989f8b903adcac7a20ff2a5a upstream.
Store blocksize in a local variable in udf_fill_inode() since it is used
a lot of times.
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Needed for the following fix. Backported to 2.6.32: adjust context.]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/inode.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 7901ad7..26b7f31 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1157,6 +1157,7 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
int offset;
struct udf_sb_info *sbi = UDF_SB(inode->i_sb);
struct udf_inode_info *iinfo = UDF_I(inode);
+ int bs = inode->i_sb->s_blocksize;
fe = (struct fileEntry *)bh->b_data;
efe = (struct extendedFileEntry *)bh->b_data;
@@ -1177,41 +1178,38 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
iinfo->i_efe = 1;
iinfo->i_use = 0;
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
+ if (udf_alloc_i_data(inode, bs -
sizeof(struct extendedFileEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct extendedFileEntry),
- inode->i_sb->s_blocksize -
- sizeof(struct extendedFileEntry));
+ bs - sizeof(struct extendedFileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_FE)) {
iinfo->i_efe = 0;
iinfo->i_use = 0;
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
- sizeof(struct fileEntry))) {
+ if (udf_alloc_i_data(inode, bs - sizeof(struct fileEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct fileEntry),
- inode->i_sb->s_blocksize - sizeof(struct fileEntry));
+ bs - sizeof(struct fileEntry));
} else if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_USE)) {
iinfo->i_efe = 0;
iinfo->i_use = 1;
iinfo->i_lenAlloc = le32_to_cpu(
((struct unallocSpaceEntry *)bh->b_data)->
lengthAllocDescs);
- if (udf_alloc_i_data(inode, inode->i_sb->s_blocksize -
+ if (udf_alloc_i_data(inode, bs -
sizeof(struct unallocSpaceEntry))) {
make_bad_inode(inode);
return;
}
memcpy(iinfo->i_ext.i_data,
bh->b_data + sizeof(struct unallocSpaceEntry),
- inode->i_sb->s_blocksize -
- sizeof(struct unallocSpaceEntry));
+ bs - sizeof(struct unallocSpaceEntry));
return;
}
@@ -1297,8 +1295,7 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
return;
}
/* File in ICB has to fit in there... */
- if (inode->i_size > inode->i_sb->s_blocksize -
- udf_file_entry_alloc_offset(inode)) {
+ if (inode->i_size > bs - udf_file_entry_alloc_offset(inode)) {
make_bad_inode(inode);
return;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 13/62] Remove repeated loads blocksize
2015-09-12 22:56 ` [PATCH 2.6.32 13/62] Remove repeated loads blocksize Willy Tarreau
@ 2015-09-15 1:42 ` Ben Hutchings
2015-09-15 7:39 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 1:42 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable, Jan Kara
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
[...]
This is missing the 'udf:' prefix in the subject line. Otherwise fine.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 13/62] Remove repeated loads blocksize
2015-09-15 1:42 ` Ben Hutchings
@ 2015-09-15 7:39 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 7:39 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, stable, Jan Kara
On Tue, Sep 15, 2015 at 02:42:33AM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> [...]
>
> This is missing the 'udf:' prefix in the subject line. Otherwise fine.
Adjusted now, thanks!
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 14/62] udf: Check length of extended attributes and allocation descriptors
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Carl Henrik Lunde, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <jack@suse.cz>
commit 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 upstream.
Check length of extended attributes and allocation descriptors when
loading inodes from disk. Otherwise corrupted filesystems could confuse
the code and make the kernel oops.
Reported-by: Carl Henrik Lunde <chlunde@ping.uio.no>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 2.6.32: use make_bad_inode() instead of returning error]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2015-4167
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/inode.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 26b7f31..b8d7a0e 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1284,6 +1284,19 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
iinfo->i_lenEAttr;
}
+ /*
+ * Sanity check length of allocation descriptors and extended attrs to
+ * avoid integer overflows
+ */
+ if (iinfo->i_lenEAttr > bs || iinfo->i_lenAlloc > bs) {
+ make_bad_inode(inode);
+ return;
+ }
+ /* Now do exact checks */
+ if (udf_file_entry_alloc_offset(inode) + iinfo->i_lenAlloc > bs) {
+ make_bad_inode(inode);
+ return;
+ }
/* Sanity checks for files in ICB so that we don't get confused later */
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
/*
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 15/62] udp: fix behavior of wrong checksums
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 1:44 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Eric Dumazet, Willem de Bruijn, David S. Miller, Ben Hutchings,
Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <edumazet@google.com>
commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream.
We have two problems in UDP stack related to bogus checksums :
1) We return -EAGAIN to application even if receive queue is not empty.
This breaks applications using edge trigger epoll()
2) Under UDP flood, we can loop forever without yielding to other
processes, potentially hanging the host, especially on non SMP.
This patch is an attempt to make things better.
We might in the future add extra support for rt applications
wanting to better control time spent doing a recv() in a hostile
environment. For example we could validate checksums before queuing
packets in socket receive queue.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
CVE-2015-5364
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/ipv4/udp.c | 6 ++----
net/ipv6/udp.c | 6 ++----
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 0b2e07fb..3ae286b 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1016,10 +1016,8 @@ csum_copy_err:
UDP_INC_STATS_USER(sock_net(sk), UDP_MIB_INERRORS, is_udplite);
release_sock(sk);
- if (noblock)
- return -EAGAIN;
-
- /* starting over for a new packet */
+ /* starting over for a new packet, but check if we need to yield */
+ cond_resched();
msg->msg_flags &= ~MSG_TRUNC;
goto try_again;
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index d0367eb..0b023f3 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -301,10 +301,8 @@ csum_copy_err:
}
release_sock(sk);
- if (noblock)
- return -EAGAIN;
-
- /* starting over for a new packet */
+ /* starting over for a new packet, but check if we need to yield */
+ cond_resched();
msg->msg_flags &= ~MSG_TRUNC;
goto try_again;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 15/62] udp: fix behavior of wrong checksums
2015-09-12 22:56 ` [PATCH 2.6.32 15/62] udp: fix behavior of wrong checksums Willy Tarreau
@ 2015-09-15 1:44 ` Ben Hutchings
2015-09-15 7:41 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 1:44 UTC (permalink / raw)
To: Willy Tarreau
Cc: linux-kernel, stable, Eric Dumazet, Willem de Bruijn, David S. Miller
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Eric Dumazet <edumazet@google.com>
>
> commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream.
>
> We have two problems in UDP stack related to bogus checksums :
>
> 1) We return -EAGAIN to application even if receive queue is not empty.
> This breaks applications using edge trigger epoll()
>
> 2) Under UDP flood, we can loop forever without yielding to other
> processes, potentially hanging the host, especially on non SMP.
>
> This patch is an attempt to make things better.
>
> We might in the future add extra support for rt applications
> wanting to better control time spent doing a recv() in a hostile
> environment. For example we could validate checksums before queuing
> packets in socket receive queue.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
>
> CVE-2015-5364
[...]
As there were two different problems, each deserving its own CVE ID,
this also fixes CVE-2015-5366.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 15/62] udp: fix behavior of wrong checksums
2015-09-15 1:44 ` Ben Hutchings
@ 2015-09-15 7:41 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 7:41 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, Eric Dumazet, Willem de Bruijn, David S. Miller
On Tue, Sep 15, 2015 at 02:44:31AM +0100, Ben Hutchings wrote:
> As there were two different problems, each deserving its own CVE ID,
> this also fixes CVE-2015-5366.
Updated, thanks!
willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 16/62] e1000: add dummy allocator to fix race condition between mtu change and netpoll
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sabrina Dubroca, Aaron Brown, Jeff Kirsher, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <sd@queasysnail.net>
commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.
There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:
Changing MTU frees all the rx buffers:
e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
e1000_clean_rx_ring
Then, close to the end of e1000_change_mtu:
pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag
And when we come back to do the rest of the MTU change:
e1000_up -> e1000_configure -> e1000_configure_rx ->
e1000_alloc_jumbo_rx_buffers
alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.
This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81194d6e>] put_compound_page+0x7e/0x330
[...]
Call Trace:
[<ffffffff81195445>] put_page+0x55/0x60
[<ffffffff815d9f44>] e1000_clean_rx_ring+0x134/0x200
[<ffffffff815da055>] e1000_clean_all_rx_rings+0x45/0x60
[<ffffffff815df5e0>] e1000_down+0x1c0/0x1d0
[<ffffffff811e2260>] ? deactivate_slab+0x7f0/0x840
[<ffffffff815e21bc>] e1000_change_mtu+0xdc/0x170
[<ffffffff81647050>] dev_set_mtu+0xa0/0x140
[<ffffffff81664218>] do_setlink+0x218/0xac0
[<ffffffff814459e9>] ? nla_parse+0xb9/0x120
[<ffffffff816652d0>] rtnl_newlink+0x6d0/0x890
[<ffffffff8104f000>] ? kvm_clock_read+0x20/0x40
[<ffffffff810a2068>] ? sched_clock_cpu+0xa8/0x100
[<ffffffff81663802>] rtnetlink_rcv_msg+0x92/0x260
By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers. The allocator is set back to a sane value in
e1000_configure_rx.
Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit f655adbac3de7ce92b2b0f9ce2d426b55b600e38)
[wt: path is drivers/net/e1000/e1000_main.c in 2.6.32]
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/net/e1000/e1000_main.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4079a33..375d332 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -140,6 +140,11 @@ static bool e1000_clean_rx_irq(struct e1000_adapter *adapter,
static bool e1000_clean_jumbo_rx_irq(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int *work_done, int work_to_do);
+static void e1000_alloc_dummy_rx_buffers(struct e1000_adapter *adapter,
+ struct e1000_rx_ring *rx_ring,
+ int cleaned_count)
+{
+}
static void e1000_alloc_rx_buffers(struct e1000_adapter *adapter,
struct e1000_rx_ring *rx_ring,
int cleaned_count);
@@ -3154,8 +3159,11 @@ static int e1000_change_mtu(struct net_device *netdev, int new_mtu)
msleep(1);
/* e1000_down has a dependency on max_frame_size */
hw->max_frame_size = max_frame;
- if (netif_running(netdev))
+ if (netif_running(netdev)) {
+ /* prevent buffers from being reallocated */
+ adapter->alloc_rx_buf = e1000_alloc_dummy_rx_buffers;
e1000_down(adapter);
+ }
/* NOTE: netdev_alloc_skb reserves 16 bytes, and typically NET_IP_ALIGN
* means we reserve 2 more, this pushes us to allocate from the next
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 17/62] powerpc: Fix missing L2 cache size in /sys/devices/system/cpu
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dave Olson, Michael Ellerman, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dave Olson <olson@cumulusnetworks.com>
commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream.
This problem appears to have been introduced in 2.6.29 by commit
93197a36a9c1 "Rewrite sysfs processor cache info code".
This caused lscpu to error out on at least e500v2 devices, eg:
error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory
Some embedded powerpc systems use cache-size in DTS for the unified L2
cache size, not d-cache-size, so we need to allow for both DTS names.
Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle
this.
Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code")
Signed-off-by: Dave Olson <olson@cumulusnetworks.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[bwh: Backported to 3.2:
- Adjust context
- Preserve __cpuinit attribute on cache_do_one_devnode_unified()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit d6de5ca93fd6425dcdb21cc341365991c0c444cc)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/powerpc/kernel/cacheinfo.c | 43 ++++++++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index bb37b1d..ffab94b 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -61,12 +61,22 @@ struct cache_type_info {
};
/* These are used to index the cache_type_info array. */
-#define CACHE_TYPE_UNIFIED 0
-#define CACHE_TYPE_INSTRUCTION 1
-#define CACHE_TYPE_DATA 2
+#define CACHE_TYPE_UNIFIED 0 /* cache-size, cache-block-size, etc. */
+#define CACHE_TYPE_UNIFIED_D 1 /* d-cache-size, d-cache-block-size, etc */
+#define CACHE_TYPE_INSTRUCTION 2
+#define CACHE_TYPE_DATA 3
static const struct cache_type_info cache_type_info[] = {
{
+ /* Embedded systems that use cache-size, cache-block-size,
+ * etc. for the Unified (typically L2) cache. */
+ .name = "Unified",
+ .size_prop = "cache-size",
+ .line_size_props = { "cache-line-size",
+ "cache-block-size", },
+ .nr_sets_prop = "cache-sets",
+ },
+ {
/* PowerPC Processor binding says the [di]-cache-*
* must be equal on unified caches, so just use
* d-cache properties. */
@@ -292,7 +302,8 @@ static struct cache *cache_find_first_sibling(struct cache *cache)
{
struct cache *iter;
- if (cache->type == CACHE_TYPE_UNIFIED)
+ if (cache->type == CACHE_TYPE_UNIFIED ||
+ cache->type == CACHE_TYPE_UNIFIED_D)
return cache;
list_for_each_entry(iter, &cache_list, list)
@@ -323,15 +334,29 @@ static bool cache_node_is_unified(const struct device_node *np)
return of_get_property(np, "cache-unified", NULL);
}
-static struct cache *__cpuinit cache_do_one_devnode_unified(struct device_node *node, int level)
+/*
+ * Unified caches can have two different sets of tags. Most embedded
+ * use cache-size, etc. for the unified cache size, but open firmware systems
+ * use d-cache-size, etc. Check on initialization for which type we have, and
+ * return the appropriate structure type. Assume it's embedded if it isn't
+ * open firmware. If it's yet a 3rd type, then there will be missing entries
+ * in /sys/devices/system/cpu/cpu0/cache/index2/, and this code will need
+ * to be extended further.
+ */
+static int cache_is_unified_d(const struct device_node *np)
{
- struct cache *cache;
+ return of_get_property(np,
+ cache_type_info[CACHE_TYPE_UNIFIED_D].size_prop, NULL) ?
+ CACHE_TYPE_UNIFIED_D : CACHE_TYPE_UNIFIED;
+}
+/*
+ */
+static struct cache *__cpuinit cache_do_one_devnode_unified(struct device_node *node, int level)
+{
pr_debug("creating L%d ucache for %s\n", level, node->full_name);
- cache = new_cache(CACHE_TYPE_UNIFIED, level, node);
-
- return cache;
+ return new_cache(cache_is_unified_d(node), level, node);
}
static struct cache *__cpuinit cache_do_one_devnode_split(struct device_node *node, int level)
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 2:10 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Heiko Carstens, Martin Schwidefsky, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <heiko.carstens@de.ibm.com>
commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
Sebastian reported a crash caused by a jump label mismatch after resume.
This happens because we do not save the kernel text section during suspend
and therefore also do not restore it during resume, but use the kernel image
that restores the old system.
This means that after a suspend/resume cycle we lost all modifications done
to the kernel text section.
The reason for this is the pfn_is_nosave() function, which incorrectly
returns that read-only pages don't need to be saved. This is incorrect since
we mark the kernel text section read-only.
We still need to make sure to not save and restore pages contained within
NSS and DCSS segment.
To fix this add an extra case for the kernel text section and only save
those pages if they are not contained within an NSS segment.
Fixes the following crash (and the above bugs as well):
Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0
Found: c0 04 00 00 00 00
Expected: c0 f4 00 00 00 11
New: c0 04 00 00 00 00
Kernel panic - not syncing: Corrupted kernel text
CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4
Call Trace:
[<0000000000113972>] show_stack+0x72/0xf0
[<000000000081f15e>] dump_stack+0x6e/0x90
[<000000000081c4e8>] panic+0x108/0x2b0
[<000000000081be64>] jump_label_bug.isra.2+0x104/0x108
[<0000000000112176>] __jump_label_transform+0x9e/0xd0
[<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50
[<00000000001d1136>] multi_cpu_stop+0x12e/0x170
[<00000000001d1472>] cpu_stopper_thread+0xb2/0x168
[<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0
[<0000000000158baa>] kthread+0x10a/0x110
[<0000000000824a86>] kernel_thread_starter+0x6/0xc
Reported-and-tested-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
[bwh: Backported to 3.2: add necessary #include directives]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 98b4a75c0792d281beb904911e2271d45c71511a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/s390/kernel/suspend.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/s390/kernel/suspend.c b/arch/s390/kernel/suspend.c
index cf9e5c6..f03c8df 100644
--- a/arch/s390/kernel/suspend.c
+++ b/arch/s390/kernel/suspend.c
@@ -7,6 +7,8 @@
*/
#include <linux/pfn.h>
+#include <asm/ipl.h>
+#include <asm/sections.h>
#include <asm/system.h>
/*
@@ -18,6 +20,8 @@ int pfn_is_nosave(unsigned long pfn)
{
unsigned long nosave_begin_pfn = PFN_DOWN(__pa(&__nosave_begin));
unsigned long nosave_end_pfn = PFN_DOWN(__pa(&__nosave_end));
+ unsigned long eshared_pfn = PFN_DOWN(__pa(&_eshared)) - 1;
+ unsigned long stext_pfn = PFN_DOWN(__pa(&_stext));
/* Always save lowcore pages (LC protection might be enabled). */
if (pfn <= LC_PAGES)
@@ -25,6 +29,8 @@ int pfn_is_nosave(unsigned long pfn)
if (pfn >= nosave_begin_pfn && pfn < nosave_end_pfn)
return 1;
/* Skip memory holes and read-only pages (NSS, DCSS, ...). */
+ if (pfn >= stext_pfn && pfn <= eshared_pfn)
+ return ipl_info.type == IPL_TYPE_NSS ? 1 : 0;
if (tprot(PFN_PHYS(pfn)))
return 1;
return 0;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
2015-09-12 22:56 ` [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section Willy Tarreau
@ 2015-09-15 2:10 ` Ben Hutchings
2015-09-15 6:09 ` Heiko Carstens
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 2:10 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable, Heiko Carstens, Martin Schwidefsky
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
>
> Sebastian reported a crash caused by a jump label mismatch after resume.
> This happens because we do not save the kernel text section during suspend
> and therefore also do not restore it during resume, but use the kernel image
> that restores the old system.
[...]
I don't think this is needed because jump labels aren't implemented in
2.6.32. But maybe there was some other mechanism that changes the
kernel text on s390?
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
2015-09-15 2:10 ` Ben Hutchings
@ 2015-09-15 6:09 ` Heiko Carstens
2015-09-15 7:41 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Heiko Carstens @ 2015-09-15 6:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Willy Tarreau, linux-kernel, stable, Martin Schwidefsky
On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Heiko Carstens <heiko.carstens@de.ibm.com>
> >
> > commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
> >
> > Sebastian reported a crash caused by a jump label mismatch after resume.
> > This happens because we do not save the kernel text section during suspend
> > and therefore also do not restore it during resume, but use the kernel image
> > that restores the old system.
> [...]
>
> I don't think this is needed because jump labels aren't implemented in
> 2.6.32. But maybe there was some other mechanism that changes the
> kernel text on s390?
Broken jump labels were the symptons when the problem was reported. However
we lose everything that modifies kernel text without this patch.
If it's not jump labels then there is still kprobes around where we have
the same problem.
Probably the patch description should have been better.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
2015-09-15 6:09 ` Heiko Carstens
@ 2015-09-15 7:41 ` Willy Tarreau
2015-09-15 7:44 ` Heiko Carstens
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 7:41 UTC (permalink / raw)
To: Heiko Carstens; +Cc: Ben Hutchings, linux-kernel, stable, Martin Schwidefsky
On Tue, Sep 15, 2015 at 08:09:27AM +0200, Heiko Carstens wrote:
> On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote:
> > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> > >
> > > ------------------
> > >
> > > From: Heiko Carstens <heiko.carstens@de.ibm.com>
> > >
> > > commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
> > >
> > > Sebastian reported a crash caused by a jump label mismatch after resume.
> > > This happens because we do not save the kernel text section during suspend
> > > and therefore also do not restore it during resume, but use the kernel image
> > > that restores the old system.
> > [...]
> >
> > I don't think this is needed because jump labels aren't implemented in
> > 2.6.32. But maybe there was some other mechanism that changes the
> > kernel text on s390?
>
> Broken jump labels were the symptons when the problem was reported. However
> we lose everything that modifies kernel text without this patch.
> If it's not jump labels then there is still kprobes around where we have
> the same problem.
> Probably the patch description should have been better.
OK so in the end you suggest you keep it in both 2.6.32 and 3.2 ?
Thanks,
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 18/62] s390/hibernate: fix save and restore of kernel text section
2015-09-15 7:41 ` Willy Tarreau
@ 2015-09-15 7:44 ` Heiko Carstens
0 siblings, 0 replies; 87+ messages in thread
From: Heiko Carstens @ 2015-09-15 7:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Ben Hutchings, linux-kernel, stable, Martin Schwidefsky
On Tue, Sep 15, 2015 at 09:41:49AM +0200, Willy Tarreau wrote:
> On Tue, Sep 15, 2015 at 08:09:27AM +0200, Heiko Carstens wrote:
> > On Tue, Sep 15, 2015 at 03:10:45AM +0100, Ben Hutchings wrote:
> > > On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > > > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> > > >
> > > > ------------------
> > > >
> > > > From: Heiko Carstens <heiko.carstens@de.ibm.com>
> > > >
> > > > commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream.
> > > >
> > > > Sebastian reported a crash caused by a jump label mismatch after resume.
> > > > This happens because we do not save the kernel text section during suspend
> > > > and therefore also do not restore it during resume, but use the kernel image
> > > > that restores the old system.
> > > [...]
> > >
> > > I don't think this is needed because jump labels aren't implemented in
> > > 2.6.32. But maybe there was some other mechanism that changes the
> > > kernel text on s390?
> >
> > Broken jump labels were the symptons when the problem was reported. However
> > we lose everything that modifies kernel text without this patch.
> > If it's not jump labels then there is still kprobes around where we have
> > the same problem.
> > Probably the patch description should have been better.
>
> OK so in the end you suggest you keep it in both 2.6.32 and 3.2 ?
Yes, please.
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 19/62] ptrace: fix race between ptrace_resume() and wait_task_stopped()
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Oleg Nesterov, Pavel Labath, Andrew Morton, Linus Torvalds,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <oleg@redhat.com>
commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream.
ptrace_resume() is called when the tracee is still __TASK_TRACED. We set
tracee->exit_code and then wake_up_state() changes tracee->state. If the
tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T)
wrongly looks like another report from tracee.
This confuses debugger, and since wait_task_stopped() clears ->exit_code
the tracee can miss a signal.
Test-case:
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <pthread.h>
#include <assert.h>
int pid;
void *waiter(void *arg)
{
int stat;
for (;;) {
assert(pid == wait(&stat));
assert(WIFSTOPPED(stat));
if (WSTOPSIG(stat) == SIGHUP)
continue;
assert(WSTOPSIG(stat) == SIGCONT);
printf("ERR! extra/wrong report:%x\n", stat);
}
}
int main(void)
{
pthread_t thread;
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
for (;;)
kill(getpid(), SIGHUP);
}
assert(pthread_create(&thread, NULL, waiter, NULL) == 0);
for (;;)
ptrace(PTRACE_CONT, pid, 0, SIGCONT);
return 0;
}
Note for stable: the bug is very old, but without 9899d11f6544 "ptrace:
ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix
should use lock_task_sighand(child).
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Pavel Labath <labath@google.com>
Tested-by: Pavel Labath <labath@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit e3f81ba2f0546f030fc234f7aade3016532c75b1)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/ptrace.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 4185220..03da336 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -516,6 +516,8 @@ static int ptrace_setsiginfo(struct task_struct *child, const siginfo_t *info)
static int ptrace_resume(struct task_struct *child, long request, long data)
{
+ bool need_siglock;
+
if (!valid_signal(data))
return -EIO;
@@ -543,8 +545,26 @@ static int ptrace_resume(struct task_struct *child, long request, long data)
user_disable_single_step(child);
}
+ /*
+ * Change ->exit_code and ->state under siglock to avoid the race
+ * with wait_task_stopped() in between; a non-zero ->exit_code will
+ * wrongly look like another report from tracee.
+ *
+ * Note that we need siglock even if ->exit_code == data and/or this
+ * status was not reported yet, the new status must not be cleared by
+ * wait_task_stopped() after resume.
+ *
+ * If data == 0 we do not care if wait_task_stopped() reports the old
+ * status and clears the code too; this can't race with the tracee, it
+ * takes siglock after resume.
+ */
+ need_siglock = data && !thread_group_empty(current);
+ if (need_siglock)
+ spin_lock_irq(&child->sighand->siglock);
child->exit_code = data;
wake_up_state(child, __TASK_TRACED);
+ if (need_siglock)
+ spin_unlock_irq(&child->sighand->siglock);
return 0;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 20/62] memstick: mspro_block: add missing curly braces
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dan Carpenter, Alex Dubov, Andrew Morton, Linus Torvalds,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream.
Using the indenting we can see the curly braces were obviously intended.
This is a static checker fix, but my guess is that we don't read enough
bytes, because we don't calculate "t_len" correctly.
Fixes: f1d82698029b ('memstick: use fully asynchronous request processing')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Alex Dubov <oakad@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 0fd0b9f448e1ff459ea4f718def61a197b15bb4c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/memstick/core/mspro_block.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/memstick/core/mspro_block.c b/drivers/memstick/core/mspro_block.c
index 46bd7e2..282348d 100644
--- a/drivers/memstick/core/mspro_block.c
+++ b/drivers/memstick/core/mspro_block.c
@@ -734,7 +734,7 @@ static int mspro_block_complete_req(struct memstick_dev *card, int error)
if (error || (card->current_mrq.tpc == MSPRO_CMD_STOP)) {
if (msb->data_dir == READ) {
- for (cnt = 0; cnt < msb->current_seg; cnt++)
+ for (cnt = 0; cnt < msb->current_seg; cnt++) {
t_len += msb->req_sg[cnt].length
/ msb->page_size;
@@ -742,6 +742,7 @@ static int mspro_block_complete_req(struct memstick_dev *card, int error)
t_len += msb->current_page - 1;
t_len *= msb->page_size;
+ }
}
} else
t_len = blk_rq_bytes(msb->block_req);
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 21/62] md/raid5: dont record new size if resize_stripes fails.
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: NeilBrown, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <neilb@suse.de>
commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream.
If any memory allocation in resize_stripes fails we will return
-ENOMEM, but in some cases we update conf->pool_size anyway.
This means that if we try again, the allocations will be assumed
to be larger than they are, and badness results.
So only update pool_size if there is no error.
This bug was introduced in 2.6.17 and the patch is suitable for
-stable.
Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array")
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit c20694a054e903745591f4f85b39ecbce4e58349)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/md/raid5.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 4d70eef..7eb8b46 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1452,7 +1452,8 @@ static int resize_stripes(raid5_conf_t *conf, int newsize)
conf->slab_cache = sc;
conf->active_name = 1-conf->active_name;
- conf->pool_size = newsize;
+ if (!err)
+ conf->pool_size = newsize;
return err;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 22/62] powerpc: Align TOC to 256 bytes
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Anton Blanchard, Michael Ellerman, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <anton@samba.org>
commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream.
Recent toolchains force the TOC to be 256 byte aligned. We need
to enforce this alignment in our linker script, otherwise pointers
to our TOC variables (__toc_start, __prom_init_toc_start) could
be incorrect.
If they are bad, we die a few hundred instructions into boot.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 303241421684cdd2f9e931bc42b9de811320e7fd)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/powerpc/kernel/vmlinux.lds.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index dcd01c8..5c2ac91 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -215,6 +215,7 @@ SECTIONS
*(.opd)
}
+ . = ALIGN(256);
.got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 23/62] jbd2: fix r_count overflows leading to buffer overflow in journal recovery
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Darrick J. Wong, Theodore Tso, Jan Kara, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Darrick J. Wong" <darrick.wong@oracle.com>
commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream.
The journal revoke block recovery code does not check r_count for
sanity, which means that an evil value of r_count could result in
the kernel reading off the end of the revoke table and into whatever
garbage lies beyond. This could crash the kernel, so fix that.
However, in testing this fix, I discovered that the code to write
out the revoke tables also was not correctly checking to see if the
block was full -- the current offset check is fine so long as the
revoke table space size is a multiple of the record size, but this
is not true when either journal_csum_v[23] are set.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
[bwh: Backported to 3.2: journal checksumming is not supported, so only
the first fix is needed]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 2f6a2bcc01bc9ed73bfb4d698da94ed2a5fcb18c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/jbd2/recovery.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/jbd2/recovery.c b/fs/jbd2/recovery.c
index 7306328..59cc9c5 100644
--- a/fs/jbd2/recovery.c
+++ b/fs/jbd2/recovery.c
@@ -718,11 +718,16 @@ static int scan_revoke_records(journal_t *journal, struct buffer_head *bh,
{
jbd2_journal_revoke_header_t *header;
int offset, max;
+ __u32 rcount;
int record_len = 4;
header = (jbd2_journal_revoke_header_t *) bh->b_data;
offset = sizeof(jbd2_journal_revoke_header_t);
- max = be32_to_cpu(header->r_count);
+ rcount = be32_to_cpu(header->r_count);
+
+ if (rcount > journal->j_blocksize)
+ return -EINVAL;
+ max = rcount;
if (JBD2_HAS_INCOMPAT_FEATURE(journal, JBD2_FEATURE_INCOMPAT_64BIT))
record_len = 8;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 24/62] sd: Disable support for 256 byte/sector disks
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mark Hounschell, Hannes Reinecke, James Bottomley, Ben Hutchings,
Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mark Hounschell <dmarkh@cfl.rr.com>
commit 74856fbf441929918c49ff262ace9835048e4e6a upstream.
256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.
Signed-off-by: Mark Hounschell <dmarkh@cfl.rr.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit fd6b72574fcdaee123768804d8f1ac28c2a5b3de)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/scsi/sd.c | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index a5b55fe..9202fc8 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1045,6 +1045,7 @@ static unsigned int sd_completed_bytes(struct scsi_cmnd *scmd)
{
u64 start_lba = blk_rq_pos(scmd->request);
u64 end_lba = blk_rq_pos(scmd->request) + (scsi_bufflen(scmd) / 512);
+ u64 factor = scmd->device->sector_size / 512;
u64 bad_lba;
int info_valid;
/*
@@ -1066,16 +1067,9 @@ static unsigned int sd_completed_bytes(struct scsi_cmnd *scmd)
if (scsi_bufflen(scmd) <= scmd->device->sector_size)
return 0;
- if (scmd->device->sector_size < 512) {
- /* only legitimate sector_size here is 256 */
- start_lba <<= 1;
- end_lba <<= 1;
- } else {
- /* be careful ... don't want any overflows */
- u64 factor = scmd->device->sector_size / 512;
- do_div(start_lba, factor);
- do_div(end_lba, factor);
- }
+ /* be careful ... don't want any overflows */
+ do_div(start_lba, factor);
+ do_div(end_lba, factor);
/* The bad lba was reported incorrectly, we have no idea where
* the error is.
@@ -1581,8 +1575,7 @@ got_data:
if (sector_size != 512 &&
sector_size != 1024 &&
sector_size != 2048 &&
- sector_size != 4096 &&
- sector_size != 256) {
+ sector_size != 4096) {
sd_printk(KERN_NOTICE, sdkp, "Unsupported sector size %d.\n",
sector_size);
/*
@@ -1631,8 +1624,6 @@ got_data:
sdkp->capacity <<= 2;
else if (sector_size == 1024)
sdkp->capacity <<= 1;
- else if (sector_size == 256)
- sdkp->capacity >>= 1;
blk_queue_physical_block_size(sdp->request_queue, sdkp->hw_sector_size);
sdkp->device->sector_size = sector_size;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 25/62] lguest: fix out-by-one error in address checking.
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rusty Russell, Linus Torvalds, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Rusty Russell <rusty@rustcorp.com.au>
commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream.
This bug has been there since day 1; addresses in the top guest physical
page weren't considered valid. You could map that page (the check in
check_gpte() is correct), but if a guest tried to put a pagetable there
we'd check that address manually when walking it, and kill the guest.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit a8f5259269671acb4f0bdb6e0a53974aa5b351ff)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/lguest/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 8744d24..42ad32c 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -170,7 +170,7 @@ static void unmap_switcher(void)
bool lguest_address_ok(const struct lguest *lg,
unsigned long addr, unsigned long len)
{
- return (addr+len) / PAGE_SIZE < lg->pfn_limit && (addr+len >= addr);
+ return addr+len <= lg->pfn_limit * PAGE_SIZE && (addr+len >= addr);
}
/*
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 26/62] fs, omfs: add NULL terminator in the end up the token list
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Bob Copeland, Andrew Morton, Linus Torvalds,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Sasha Levin <sasha.levin@oracle.com>
commit dcbff39da3d815f08750552fdd04f96b51751129 upstream.
match_token() expects a NULL terminator at the end of the token list so
that it would know where to stop. Not having one causes it to overrun
to invalid memory.
In practice, passing a mount option that omfs didn't recognize would
sometimes panic the system.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit a5045e0fee1a7b2cf132afb94977d4c8d781bd04)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/omfs/inode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
index f3b7c15..66c37eb 100644
--- a/fs/omfs/inode.c
+++ b/fs/omfs/inode.c
@@ -347,7 +347,7 @@ nomem:
}
enum {
- Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask
+ Opt_uid, Opt_gid, Opt_umask, Opt_dmask, Opt_fmask, Opt_err
};
static const match_table_t tokens = {
@@ -356,6 +356,7 @@ static const match_table_t tokens = {
{Opt_umask, "umask=%o"},
{Opt_dmask, "dmask=%o"},
{Opt_fmask, "fmask=%o"},
+ {Opt_err, NULL},
};
static int parse_options(char *options, struct omfs_sb_info *sbi)
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 27/62] x86_64: Fix strnlen_user() to not touch memory after specified maximum
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ben Hutchings, Jan Kara, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@decadent.org.uk>
Inspired by commit f18c34e483ff ("lib: Fix strnlen_user() to not touch
memory after specified maximum") upstream. This version of
strnlen_user(), no longer present upstream, has a similar off-by-one
error.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Jan Kara <jack@suse.cz>
(cherry picked from commit 4797489ce83a5f42d0b38089695a48d4a3d1ee0b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/x86/lib/usercopy_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
index b7c2849..3428d91 100644
--- a/arch/x86/lib/usercopy_64.c
+++ b/arch/x86/lib/usercopy_64.c
@@ -113,7 +113,7 @@ long __strnlen_user(const char __user *s, long n)
char c;
while (1) {
- if (res>n)
+ if (res >= n)
return n+1;
if (__get_user(c, s))
return 0;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 28/62] tracing: Have filter check for balanced ops
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Vince Weaver, Steven Rostedt, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <rostedt@goodmis.org>
commit 2cf30dc180cea808077f003c5116388183e54f9e upstream.
When the following filter is used it causes a warning to trigger:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: No error
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990()
Modules linked in: bnep lockd grace bluetooth ...
CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0
0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c
ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea
Call Trace:
[<ffffffff816ed4f9>] dump_stack+0x4c/0x6e
[<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0
[<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80
[<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20
[<ffffffff81159065>] replace_preds+0x3c5/0x990
[<ffffffff811596b2>] create_filter+0x82/0xb0
[<ffffffff81159944>] apply_event_filter+0xd4/0x180
[<ffffffff81152bbf>] event_filter_write+0x8f/0x120
[<ffffffff811db2a8>] __vfs_write+0x28/0xe0
[<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0
[<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0
[<ffffffff811dc408>] vfs_write+0xb8/0x1b0
[<ffffffff811dc72f>] SyS_write+0x4f/0xb0
[<ffffffff816f5217>] system_call_fastpath+0x12/0x6a
---[ end trace e11028bd95818dcd ]---
Worse yet, reading the error message (the filter again) it says that
there was no error, when there clearly was. The issue is that the
code that checks the input does not check for balanced ops. That is,
having an op between a closed parenthesis and the next token.
This would only cause a warning, and fail out before doing any real
harm, but it should still not caues a warning, and the error reported
should work:
# cd /sys/kernel/debug/tracing
# echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter
-bash: echo: write error: Invalid argument
# cat events/ext4/ext4_truncate_exit/filter
((dev==1)blocks==2)
^
parse_error: Meaningless filter expression
And give no kernel warning.
Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
[bwh: Backported to 3.2: drop the check for OP_NOT, which we don't have]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 9fa3f3e6f2a4f4797df5550a33ec5ac1088647e7)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/trace/trace_events_filter.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 98a6cc5..098a1dc 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1070,19 +1070,25 @@ static int check_preds(struct filter_parse_state *ps)
{
int n_normal_preds = 0, n_logical_preds = 0;
struct postfix_elt *elt;
+ int cnt = 0;
list_for_each_entry(elt, &ps->postfix, list) {
- if (elt->op == OP_NONE)
+ if (elt->op == OP_NONE) {
+ cnt++;
continue;
+ }
if (elt->op == OP_AND || elt->op == OP_OR) {
n_logical_preds++;
+ cnt--;
continue;
}
+ cnt--;
n_normal_preds++;
+ WARN_ON_ONCE(cnt < 0);
}
- if (!n_normal_preds || n_logical_preds >= n_normal_preds) {
+ if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
parse_error(ps, FILT_ERR_INVALID_FILTER, 0);
return -EINVAL;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 29/62] sctp: Fix race between OOTB responce and route removal
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 2:26 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexander Sverdlin, Neil Horman, Marcelo Ricardo Leitner,
Vlad Yasevich, David S. Miller, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
[ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]
There is NULL pointer dereference possible during statistics update if the route
used for OOTB responce is removed at unfortunate time. If the route exists when
we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
ABORT, but in the meantime route is removed under our feet, we take "no_route"
path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).
But sctp_ootb_pkt_new() used to prepare responce packet doesn't call
sctp_transport_set_owner() and therefore there is no asoc associated with this
packet. Probably temporary asoc just for OOTB responces is overkill, so just
introduce a check like in all other places in sctp_packet_transmit(), where
"asoc" is dereferenced.
To reproduce this, one needs to
0. ensure that sctp module is loaded (otherwise ABORT is not generated)
1. remove default route on the machine
2. while true; do
ip route del [interface-specific route]
ip route add [interface-specific route]
done
3. send enough OOTB packets (i.e. HB REQs) from another host to trigger ABORT
responce
On x86_64 the crash looks like this:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
PGD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ...
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.0.5-1-ARCH #1
Hardware name: ...
task: ffffffff818124c0 ti: ffffffff81800000 task.ti: ffffffff81800000
RIP: 0010:[<ffffffffa05ec9ac>] [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
RSP: 0018:ffff880127c037b8 EFLAGS: 00010296
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000015ff66b480
RDX: 00000015ff66b400 RSI: ffff880127c17200 RDI: ffff880123403700
RBP: ffff880127c03888 R08: 0000000000017200 R09: ffffffff814625af
R10: ffffea00047e4680 R11: 00000000ffffff80 R12: ffff8800b0d38a28
R13: ffff8800b0d38a28 R14: ffff8800b3e88000 R15: ffffffffa05f24e0
FS: 0000000000000000(0000) GS:ffff880127c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 00000000c855b000 CR4: 00000000000007f0
Stack:
ffff880127c03910 ffff8800b0d38a28 ffffffff8189d240 ffff88011f91b400
ffff880127c03828 ffffffffa05c94c5 0000000000000000 ffff8800baa1c520
0000000000000000 0000000000000001 0000000000000000 0000000000000000
Call Trace:
<IRQ>
[<ffffffffa05c94c5>] ? sctp_sf_tabort_8_4_8.isra.20+0x85/0x140 [sctp]
[<ffffffffa05d6b42>] ? sctp_transport_put+0x52/0x80 [sctp]
[<ffffffffa05d0bfc>] sctp_do_sm+0xb8c/0x19a0 [sctp]
[<ffffffff810b0e00>] ? trigger_load_balance+0x90/0x210
[<ffffffff810e0329>] ? update_process_times+0x59/0x60
[<ffffffff812c7a40>] ? timerqueue_add+0x60/0xb0
[<ffffffff810e0549>] ? enqueue_hrtimer+0x29/0xa0
[<ffffffff8101f599>] ? read_tsc+0x9/0x10
[<ffffffff8116d4b5>] ? put_page+0x55/0x60
[<ffffffff810ee1ad>] ? clockevents_program_event+0x6d/0x100
[<ffffffff81462b68>] ? skb_free_head+0x58/0x80
[<ffffffffa029a10b>] ? chksum_update+0x1b/0x27 [crc32c_generic]
[<ffffffff81283f3e>] ? crypto_shash_update+0xce/0xf0
[<ffffffffa05d3993>] sctp_endpoint_bh_rcv+0x113/0x280 [sctp]
[<ffffffffa05dd4e6>] sctp_inq_push+0x46/0x60 [sctp]
[<ffffffffa05ed7a0>] sctp_rcv+0x880/0x910 [sctp]
[<ffffffffa05ecb50>] ? sctp_packet_transmit_chunk+0xb0/0xb0 [sctp]
[<ffffffffa05ecb70>] ? sctp_csum_update+0x20/0x20 [sctp]
[<ffffffff814b05a5>] ? ip_route_input_noref+0x235/0xd30
[<ffffffff81051d6b>] ? ack_ioapic_level+0x7b/0x150
[<ffffffff814b27be>] ip_local_deliver_finish+0xae/0x210
[<ffffffff814b2e15>] ip_local_deliver+0x35/0x90
[<ffffffff814b2a15>] ip_rcv_finish+0xf5/0x370
[<ffffffff814b3128>] ip_rcv+0x2b8/0x3a0
[<ffffffff81474193>] __netif_receive_skb_core+0x763/0xa50
[<ffffffff81476c28>] __netif_receive_skb+0x18/0x60
[<ffffffff81476cb0>] netif_receive_skb_internal+0x40/0xd0
[<ffffffff814776c8>] napi_gro_receive+0xe8/0x120
[<ffffffffa03946aa>] rtl8169_poll+0x2da/0x660 [r8169]
[<ffffffff8147896a>] net_rx_action+0x21a/0x360
[<ffffffff81078dc1>] __do_softirq+0xe1/0x2d0
[<ffffffff8107912d>] irq_exit+0xad/0xb0
[<ffffffff8157d158>] do_IRQ+0x58/0xf0
[<ffffffff8157b06d>] common_interrupt+0x6d/0x6d
<EOI>
[<ffffffff810e1218>] ? hrtimer_start+0x18/0x20
[<ffffffffa05d65f9>] ? sctp_transport_destroy_rcu+0x29/0x30 [sctp]
[<ffffffff81020c50>] ? mwait_idle+0x60/0xa0
[<ffffffff810216ef>] arch_cpu_idle+0xf/0x20
[<ffffffff810b731c>] cpu_startup_entry+0x3ec/0x480
[<ffffffff8156b365>] rest_init+0x85/0x90
[<ffffffff818eb035>] start_kernel+0x48b/0x4ac
[<ffffffff818ea120>] ? early_idt_handlers+0x120/0x120
[<ffffffff818ea339>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff818ea49c>] x86_64_start_kernel+0x161/0x184
Code: 90 48 8b 80 b8 00 00 00 48 89 85 70 ff ff ff 48 83 bd 70 ff ff ff 00 0f 85 cd fa ff ff 48 89 df 31 db e8 18 63 e7 e0 48 8b 45 80 <48> 8b 40 20 48 8b 40 30 48 8b 80 68 01 00 00 65 48 ff 40 78 e9
RIP [<ffffffffa05ec9ac>] sctp_packet_transmit+0x63c/0x730 [sctp]
RSP <ffff880127c037b8>
CR2: 0000000000000020
---[ end trace 5aec7fd2dc983574 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
drm_kms_helper: panic occurred, switching back to text console
---[ end Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[bwh: Backported to 3.2: sctp alway uses init_net]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 117b8a10fe0c434d9043267efd51f3ba3f3d359a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/sctp/output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 432361b..88ed1f9 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -580,7 +580,9 @@ out:
return err;
no_route:
kfree_skb(nskb);
- IP_INC_STATS(&init_net, IPSTATS_MIB_OUTNOROUTES);
+
+ if (asoc)
+ IP_INC_STATS(&init_net, IPSTATS_MIB_OUTNOROUTES);
/* FIXME: Returning the 'err' will effect all the associations
* associated with a socket, although only one of the paths of the
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 29/62] sctp: Fix race between OOTB responce and route removal
2015-09-12 22:56 ` [PATCH 2.6.32 29/62] sctp: Fix race between OOTB responce and route removal Willy Tarreau
@ 2015-09-15 2:26 ` Ben Hutchings
2015-09-15 7:43 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 2:26 UTC (permalink / raw)
To: Willy Tarreau
Cc: linux-kernel, stable, Alexander Sverdlin, Neil Horman,
Marcelo Ricardo Leitner, Vlad Yasevich, David S. Miller
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
>
> [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]
>
> There is NULL pointer dereference possible during statistics update if the route
> used for OOTB responce is removed at unfortunate time. If the route exists when
> we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
> ABORT, but in the meantime route is removed under our feet, we take "no_route"
> path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).
[...]
> [bwh: Backported to 3.2: sctp alway uses init_net]
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[...]
This doesn't make sense in 2.6.32 and it didn't make sense for me to
apply it to 3.2 either! Since sctp is not using asoc to look up a net
namespace here, the null pointer doesn't get dereferenced.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 29/62] sctp: Fix race between OOTB responce and route removal
2015-09-15 2:26 ` Ben Hutchings
@ 2015-09-15 7:43 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 7:43 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-kernel, stable, Alexander Sverdlin, Neil Horman,
Marcelo Ricardo Leitner, Vlad Yasevich, David S. Miller
On Tue, Sep 15, 2015 at 03:26:44AM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
> >
> > [ Upstream commit 29c4afc4e98f4dc0ea9df22c631841f9c220b944 ]
> >
> > There is NULL pointer dereference possible during statistics update if the route
> > used for OOTB responce is removed at unfortunate time. If the route exists when
> > we receive OOTB packet and we finally jump into sctp_packet_transmit() to send
> > ABORT, but in the meantime route is removed under our feet, we take "no_route"
> > path and try to update stats with IP_INC_STATS(sock_net(asoc->base.sk), ...).
> [...]
> > [bwh: Backported to 3.2: sctp alway uses init_net]
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> [...]
>
> This doesn't make sense in 2.6.32 and it didn't make sense for me to
> apply it to 3.2 either! Since sctp is not using asoc to look up a net
> namespace here, the null pointer doesn't get dereferenced.
Perfect, I'm dropping it now.
Thanks,
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 30/62] x86/reboot: Fix a warning message triggered by stop_other_cpus()
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Feng Tang, Don Zickus, Peter Zijlstra, Ingo Molnar,
Ben Hutchings, Vinson Lee, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Feng Tang <feng.tang@intel.com>
commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 upstream.
When rebooting our 24 CPU Westmere servers with 3.4-rc6, we
always see this warning msg:
Restarting system.
machine restart
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:125
native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN
Modules linked in: igb [last unloaded: scsi_wait_scan]
Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22
Call Trace:
<IRQ> [<ffffffff8102a41f>] warn_slowpath_common+0x7e/0x96
[<ffffffff8102a44c>] warn_slowpath_null+0x15/0x17
[<ffffffff81018cf7>] native_smp_send_reschedule+0x74/0xa7
[<ffffffff810561c1>] trigger_load_balance+0x279/0x2a6
[<ffffffff81050112>] scheduler_tick+0xe0/0xe9
[<ffffffff81036768>] update_process_times+0x60/0x70
[<ffffffff81062f2f>] tick_sched_timer+0x68/0x92
[<ffffffff81046e33>] __run_hrtimer+0xb3/0x13c
[<ffffffff81062ec7>] ? tick_nohz_handler+0xd0/0xd0
[<ffffffff810474f2>] hrtimer_interrupt+0xdb/0x198
[<ffffffff81019a35>] smp_apic_timer_interrupt+0x81/0x94
[<ffffffff81655187>] apic_timer_interrupt+0x67/0x70
<EOI> [<ffffffff8101a3c4>] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4
[<ffffffff8101c680>] physflat_send_IPI_allbutself+0x12/0x14
[<ffffffff81018db4>] native_nmi_stop_other_cpus+0x8a/0xd6
[<ffffffff810188ba>] native_machine_shutdown+0x50/0x67
[<ffffffff81018926>] machine_shutdown+0xa/0xc
[<ffffffff8101897e>] native_machine_restart+0x20/0x32
[<ffffffff810189b0>] machine_restart+0xa/0xc
[<ffffffff8103b196>] kernel_restart+0x47/0x4c
[<ffffffff8103b2e6>] sys_reboot+0x13e/0x17c
[<ffffffff8164e436>] ? _raw_spin_unlock_bh+0x10/0x12
[<ffffffff810fcac9>] ? bdi_queue_work+0xcf/0xd8
[<ffffffff810fe82f>] ? __bdi_start_writeback+0xae/0xb7
[<ffffffff810e0d64>] ? iterate_supers+0xa3/0xb7
[<ffffffff816547a2>] system_call_fastpath+0x16/0x1b
---[ end trace 320af5cb1cb60c5b ]---
The root cause seems to be the
default_send_IPI_mask_allbutself_phys() takes quite some time (I
measured it could be several ms) to complete sending NMIs to all
the other 23 CPUs, and for HZ=250/1000 system, the time is long
enough for a timer interrupt to happen, which will in turn
trigger to kick load balance to a stopped CPU and cause this
warning in native_smp_send_reschedule().
So disabling the local irq before stop_other_cpu() can fix this
problem (tested 25 times reboot ok), and it is fine as there
should be nobody caring the timer interrupt in such reboot
stage.
The latest 3.4 kernel slightly changes this behavior by sending
REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR
fails, and this patch is still needed to prevent the problem.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Vinson Lee <vlee@twopensource.com>
(cherry picked from commit ea475029e76a0b7fc6e96baf4d414079dec8a90a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/x86/kernel/reboot.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index cf98100..93a933f 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -638,9 +638,12 @@ void native_machine_shutdown(void)
/* Make certain I only run on the appropriate processor */
set_cpus_allowed_ptr(current, cpumask_of(reboot_cpu_id));
- /* O.K Now that I'm on the appropriate processor,
- * stop all of the others.
+ /*
+ * O.K Now that I'm on the appropriate processor, stop all of the
+ * others. Also disable the local irq to not receive the per-cpu
+ * timer interrupt which may trigger scheduler's load balance.
*/
+ local_irq_disable();
stop_other_cpus();
#endif
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 31/62] include/linux/sched.h: dont use task->pid/tgid in same_thread_group/has_group_leader_pid
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Oleg Nesterov, Michal Hocko, Sergey Dyasly, Eric W. Biederman,
Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Andrew Morton,
Linus Torvalds, Ben Hutchings, Sheng Yong, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <oleg@redhat.com>
commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream.
task_struct->pid/tgid should go away.
1. Change same_thread_group() to use task->signal for comparison.
2. Change has_group_leader_pid(task) to compare task_pid(task) with
signal->leader_pid.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Sergey Dyasly <dserrg@gmail.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Sheng Yong <shengyong1@huawei.com>
(cherry picked from commit a7b4d51399316329b6a3d9eaeab224d83eeebe67)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
include/linux/sched.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 56e1771..33c1ec2 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2211,15 +2211,15 @@ extern bool current_is_single_threaded(void);
* all we care about is that we have a task with the appropriate
* pid, we don't actually care if we have the right task.
*/
-static inline int has_group_leader_pid(struct task_struct *p)
+static inline bool has_group_leader_pid(struct task_struct *p)
{
- return p->pid == p->tgid;
+ return task_pid(p) == p->signal->leader_pid;
}
static inline
-int same_thread_group(struct task_struct *p1, struct task_struct *p2)
+bool same_thread_group(struct task_struct *p1, struct task_struct *p2)
{
- return p1->tgid == p2->tgid;
+ return p1->signal == p2->signal;
}
static inline struct task_struct *next_thread(const struct task_struct *p)
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 32/62] __ptrace_may_access() should not deny sub-threads
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mark Grondona, Ben Woodard, Oleg Nesterov, Andrew Morton,
Linus Torvalds, Ben Hutchings, Sheng Yong, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mark Grondona <mgrondona@llnl.gov>
commit 73af963f9f3036dffed55c3a2898598186db1045 upstream.
__ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task !=
current, this can can lead to surprising results.
For example, a sub-thread can't readlink("/proc/self/exe") if the
executable is not readable. setup_new_exec()->would_dump() notices that
inode_permission(MAY_READ) fails and then it does
set_dumpable(suid_dumpable). After that get_dumpable() fails.
(It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we
could add PTRACE_MODE_NODUMPABLE)
Change __ptrace_may_access() to use same_thread_group() instead of "task
== current". Any security check is pointless when the tasks share the
same ->mm.
Signed-off-by: Mark Grondona <mgrondona@llnl.gov>
Signed-off-by: Ben Woodard <woodard@redhat.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Sheng Yong <shengyong1@huawei.com>
(cherry picked from commit f062bd6e420a064a19563b80c26d746b0262e404)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 03da336..426b0c8 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -169,7 +169,7 @@ int __ptrace_may_access(struct task_struct *task, unsigned int mode)
*/
int dumpable = 0;
/* Don't let security modules deny introspection */
- if (task == current)
+ if (same_thread_group(task, current))
return 0;
rcu_read_lock();
tcred = __task_cred(task);
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 33/62] MIPS: Octeon: Remove udelay() causing huge IRQ latency
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexander Sverdlin, linux-mips, David Daney, Rob Herring,
Jiri Kosina, Randy Dunlap, Masanari Iida, Bjorn Helgaas, Mathias,
Ralf Baechle, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
commit 73bf3c2a500b2db8ac966469591196bf55afb409 upstream.
udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon
platforms because these operations are called from PCI_OP_READ() and
PCI_OP_WRITE() under raw_spin_lock_irqsave().
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: linux-mips@linux-mips.org
Cc: David Daney <ddaney@cavium.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Mathias <mathias.rulf@nokia.com>
Patchwork: https://patchwork.linux-mips.org/patch/9576/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 53493d44a771a3155ee12b6ac668fb2543d21a7a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/mips/include/asm/octeon/pci-octeon.h | 3 ---
arch/mips/pci/pci-octeon.c | 6 ------
arch/mips/pci/pcie-octeon.c | 3 ---
3 files changed, 12 deletions(-)
diff --git a/arch/mips/include/asm/octeon/pci-octeon.h b/arch/mips/include/asm/octeon/pci-octeon.h
index 6ac5d3e..5eda9f0 100644
--- a/arch/mips/include/asm/octeon/pci-octeon.h
+++ b/arch/mips/include/asm/octeon/pci-octeon.h
@@ -11,9 +11,6 @@
#include <linux/pci.h>
-/* Some PCI cards require delays when accessing config space. */
-#define PCI_CONFIG_SPACE_DELAY 10000
-
/*
* pcibios_map_irq() is defined inside pci-octeon.c. All it does is
* call the Octeon specific version pointed to by this variable. This
diff --git a/arch/mips/pci/pci-octeon.c b/arch/mips/pci/pci-octeon.c
index 9cb0c80..dae7ff7 100644
--- a/arch/mips/pci/pci-octeon.c
+++ b/arch/mips/pci/pci-octeon.c
@@ -274,9 +274,6 @@ static int octeon_read_config(struct pci_bus *bus, unsigned int devfn,
pci_addr.s.func = devfn & 0x7;
pci_addr.s.reg = reg;
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
switch (size) {
case 4:
*val = le32_to_cpu(cvmx_read64_uint32(pci_addr.u64));
@@ -311,9 +308,6 @@ static int octeon_write_config(struct pci_bus *bus, unsigned int devfn,
pci_addr.s.func = devfn & 0x7;
pci_addr.s.reg = reg;
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
switch (size) {
case 4:
cvmx_write64_uint32(pci_addr.u64, cpu_to_le32(val));
diff --git a/arch/mips/pci/pcie-octeon.c b/arch/mips/pci/pcie-octeon.c
index 6aa5c54..97813f3 100644
--- a/arch/mips/pci/pcie-octeon.c
+++ b/arch/mips/pci/pcie-octeon.c
@@ -1192,9 +1192,6 @@ static inline int octeon_pcie_write_config(int pcie_port, struct pci_bus *bus,
devfn & 0x7, reg, val);
return PCIBIOS_SUCCESSFUL;
}
-#if PCI_CONFIG_SPACE_DELAY
- udelay(PCI_CONFIG_SPACE_DELAY);
-#endif
return PCIBIOS_FUNC_NOT_SUPPORTED;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 34/62] MIPS: Fix race condition in lazy cache flushing.
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lars Persson, linux-mips, paul.burton, Ralf Baechle,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Lars Persson <lars.persson@axis.com>
commit 4d46a67a3eb827ccf1125959936fd51ba318dabc upstream.
The lazy cache flushing implemented in the MIPS kernel suffers from a
race condition that is exposed by do_set_pte() in mm/memory.c.
A pre-condition is a file-system that writes to the page from the CPU
in its readpage method and then calls flush_dcache_page(). One example
is ubifs. Another pre-condition is that the dcache flush is postponed
in __flush_dcache_page().
Upon a page fault for an executable mapping not existing in the
page-cache, the following will happen:
1. Write to the page
2. flush_dcache_page
3. flush_icache_page
4. set_pte_at
5. update_mmu_cache (commits the flush of a dcache-dirty page)
Between steps 4 and 5 another thread can hit the same page and it will
encounter a valid pte. Because the data still is in the L1 dcache the CPU
will fetch stale data from L2 into the icache and execute garbage.
This fix moves the commit of the cache flush to step 3 to close the
race window. It also reduces the amount of flushes on non-executable
mappings because we never enter __flush_dcache_page() for non-aliasing
CPUs.
Regressions can occur in drivers that mistakenly relies on the
flush_dcache_page() in get_user_pages() for DMA operations.
[ralf@linux-mips.org: Folded in patch 9346 to fix highmem issue.]
Signed-off-by: Lars Persson <larper@axis.com>
Cc: linux-mips@linux-mips.org
Cc: paul.burton@imgtec.com
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/9346/
Patchwork: https://patchwork.linux-mips.org/patch/9738/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 6bde6a3df0b4c8680d51c987d446b0ff2d6df0a6)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/mips/include/asm/cacheflush.h | 38 +++++++++++++++++++++++---------------
arch/mips/mm/cache.c | 12 ++++++++++++
2 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/arch/mips/include/asm/cacheflush.h b/arch/mips/include/asm/cacheflush.h
index 03b1d69..2211f24 100644
--- a/arch/mips/include/asm/cacheflush.h
+++ b/arch/mips/include/asm/cacheflush.h
@@ -29,6 +29,20 @@
* - flush_icache_all() flush the entire instruction cache
* - flush_data_cache_page() flushes a page from the data cache
*/
+
+ /*
+ * This flag is used to indicate that the page pointed to by a pte
+ * is dirty and requires cleaning before returning it to the user.
+ */
+#define PG_dcache_dirty PG_arch_1
+
+#define Page_dcache_dirty(page) \
+ test_bit(PG_dcache_dirty, &(page)->flags)
+#define SetPageDcacheDirty(page) \
+ set_bit(PG_dcache_dirty, &(page)->flags)
+#define ClearPageDcacheDirty(page) \
+ clear_bit(PG_dcache_dirty, &(page)->flags)
+
extern void (*flush_cache_all)(void);
extern void (*__flush_cache_all)(void);
extern void (*flush_cache_mm)(struct mm_struct *mm);
@@ -37,12 +51,14 @@ extern void (*flush_cache_range)(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
extern void (*flush_cache_page)(struct vm_area_struct *vma, unsigned long page, unsigned long pfn);
extern void __flush_dcache_page(struct page *page);
+extern void __flush_icache_page(struct vm_area_struct *vma, struct page *page);
static inline void flush_dcache_page(struct page *page)
{
- if (cpu_has_dc_aliases || !cpu_has_ic_fills_f_dc)
+ if (cpu_has_dc_aliases)
__flush_dcache_page(page);
-
+ else if (!cpu_has_ic_fills_f_dc)
+ SetPageDcacheDirty(page);
}
#define flush_dcache_mmap_lock(mapping) do { } while (0)
@@ -60,6 +76,11 @@ static inline void flush_anon_page(struct vm_area_struct *vma,
static inline void flush_icache_page(struct vm_area_struct *vma,
struct page *page)
{
+ if (!cpu_has_ic_fills_f_dc && (vma->vm_flags & VM_EXEC) &&
+ Page_dcache_dirty(page)) {
+ __flush_icache_page(vma, page);
+ ClearPageDcacheDirty(page);
+ }
}
extern void (*flush_icache_range)(unsigned long start, unsigned long end);
@@ -94,19 +115,6 @@ extern void (*flush_icache_all)(void);
extern void (*local_flush_data_cache_page)(void * addr);
extern void (*flush_data_cache_page)(unsigned long addr);
-/*
- * This flag is used to indicate that the page pointed to by a pte
- * is dirty and requires cleaning before returning it to the user.
- */
-#define PG_dcache_dirty PG_arch_1
-
-#define Page_dcache_dirty(page) \
- test_bit(PG_dcache_dirty, &(page)->flags)
-#define SetPageDcacheDirty(page) \
- set_bit(PG_dcache_dirty, &(page)->flags)
-#define ClearPageDcacheDirty(page) \
- clear_bit(PG_dcache_dirty, &(page)->flags)
-
/* Run kernel code uncached, useful for cache probing functions. */
unsigned long run_uncached(void *func);
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 694d51f..37603a4 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -113,6 +113,18 @@ void __flush_anon_page(struct page *page, unsigned long vmaddr)
EXPORT_SYMBOL(__flush_anon_page);
+void __flush_icache_page(struct vm_area_struct *vma, struct page *page)
+{
+ unsigned long addr;
+
+ if (PageHighMem(page))
+ return;
+
+ addr = (unsigned long) page_address(page);
+ flush_data_cache_page(addr);
+}
+EXPORT_SYMBOL_GPL(__flush_icache_page);
+
void __update_cache(struct vm_area_struct *vma, unsigned long address,
pte_t pte)
{
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 35/62] MIPS: Fix cpu_has_mips_r2_exec_hazard.
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 3:02 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ralf Baechle, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ralf Baechle <ralf@linux-mips.org>
commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream.
Returns a non-zero value if the current processor implementation requires
an IHB instruction to deal with an instruction hazard as per MIPS R2
architecture specification, zero otherwise.
For a discussion, see http://patchwork.linux-mips.org/patch/9539/.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
[bwh: Backported to 3.2: trim the CPU type list]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 8feb2a714b3478b2cde5c576fd9f47ef44b60e8d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/mips/include/asm/cpu-features.h | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h
index 1f4df64..a3dbb59 100644
--- a/arch/mips/include/asm/cpu-features.h
+++ b/arch/mips/include/asm/cpu-features.h
@@ -150,8 +150,32 @@
#define cpu_has_mips_r (cpu_has_mips32r1 | cpu_has_mips32r2 | \
cpu_has_mips64r1 | cpu_has_mips64r2)
+/*
+ * cpu_has_mips_r2_exec_hazard - return if IHB is required on current processor
+ *
+ * Returns non-zero value if the current processor implementation requires
+ * an IHB instruction to deal with an instruction hazard as per MIPS R2
+ * architecture specification, zero otherwise.
+ */
#ifndef cpu_has_mips_r2_exec_hazard
-#define cpu_has_mips_r2_exec_hazard cpu_has_mips_r2
+#define cpu_has_mips_r2_exec_hazard \
+({ \
+ int __res; \
+ \
+ switch (current_cpu_type()) { \
+ case CPU_74K: \
+ case CPU_CAVIUM_OCTEON: \
+ case CPU_CAVIUM_OCTEON_PLUS: \
+ case CPU_CAVIUM_OCTEON2: \
+ __res = 0; \
+ break; \
+ \
+ default: \
+ __res = 1; \
+ } \
+ \
+ __res; \
+})
#endif
/*
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 35/62] MIPS: Fix cpu_has_mips_r2_exec_hazard.
2015-09-12 22:56 ` [PATCH 2.6.32 35/62] MIPS: Fix cpu_has_mips_r2_exec_hazard Willy Tarreau
@ 2015-09-15 3:02 ` Ben Hutchings
2015-09-15 7:43 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 3:02 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable, Ralf Baechle
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Ralf Baechle <ralf@linux-mips.org>
>
> commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream.
>
> Returns a non-zero value if the current processor implementation requires
> an IHB instruction to deal with an instruction hazard as per MIPS R2
> architecture specification, zero otherwise.
>
> For a discussion, see http://patchwork.linux-mips.org/patch/9539/.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> [bwh: Backported to 3.2: trim the CPU type list]
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> (cherry picked from commit 8feb2a714b3478b2cde5c576fd9f47ef44b60e8d)
>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> arch/mips/include/asm/cpu-features.h | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h
> index 1f4df64..a3dbb59 100644
> --- a/arch/mips/include/asm/cpu-features.h
> +++ b/arch/mips/include/asm/cpu-features.h
> @@ -150,8 +150,32 @@
> #define cpu_has_mips_r (cpu_has_mips32r1 | cpu_has_mips32r2 | \
> cpu_has_mips64r1 | cpu_has_mips64r2)
>
> +/*
> + * cpu_has_mips_r2_exec_hazard - return if IHB is required on current processor
> + *
> + * Returns non-zero value if the current processor implementation requires
> + * an IHB instruction to deal with an instruction hazard as per MIPS R2
> + * architecture specification, zero otherwise.
> + */
> #ifndef cpu_has_mips_r2_exec_hazard
> -#define cpu_has_mips_r2_exec_hazard cpu_has_mips_r2
> +#define cpu_has_mips_r2_exec_hazard \
> +({ \
> + int __res; \
> + \
> + switch (current_cpu_type()) { \
> + case CPU_74K: \
> + case CPU_CAVIUM_OCTEON: \
> + case CPU_CAVIUM_OCTEON_PLUS: \
> + case CPU_CAVIUM_OCTEON2: \
[...]
These last two constants aren't defined in 2.6.32, so they would need to
be removed too. But I don't think this is needed at all.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 35/62] MIPS: Fix cpu_has_mips_r2_exec_hazard.
2015-09-15 3:02 ` Ben Hutchings
@ 2015-09-15 7:43 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 7:43 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, stable, Ralf Baechle
On Tue, Sep 15, 2015 at 04:02:25AM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Ralf Baechle <ralf@linux-mips.org>
> >
> > commit 9cdf30bd3bac697fc533988f44a117434a858f69 upstream.
> >
> > Returns a non-zero value if the current processor implementation requires
> > an IHB instruction to deal with an instruction hazard as per MIPS R2
> > architecture specification, zero otherwise.
> >
> > For a discussion, see http://patchwork.linux-mips.org/patch/9539/.
> >
> > Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
> > [bwh: Backported to 3.2: trim the CPU type list]
> > Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> > (cherry picked from commit 8feb2a714b3478b2cde5c576fd9f47ef44b60e8d)
> >
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > arch/mips/include/asm/cpu-features.h | 26 +++++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/mips/include/asm/cpu-features.h b/arch/mips/include/asm/cpu-features.h
> > index 1f4df64..a3dbb59 100644
> > --- a/arch/mips/include/asm/cpu-features.h
> > +++ b/arch/mips/include/asm/cpu-features.h
> > @@ -150,8 +150,32 @@
> > #define cpu_has_mips_r (cpu_has_mips32r1 | cpu_has_mips32r2 | \
> > cpu_has_mips64r1 | cpu_has_mips64r2)
> >
> > +/*
> > + * cpu_has_mips_r2_exec_hazard - return if IHB is required on current processor
> > + *
> > + * Returns non-zero value if the current processor implementation requires
> > + * an IHB instruction to deal with an instruction hazard as per MIPS R2
> > + * architecture specification, zero otherwise.
> > + */
> > #ifndef cpu_has_mips_r2_exec_hazard
> > -#define cpu_has_mips_r2_exec_hazard cpu_has_mips_r2
> > +#define cpu_has_mips_r2_exec_hazard \
> > +({ \
> > + int __res; \
> > + \
> > + switch (current_cpu_type()) { \
> > + case CPU_74K: \
> > + case CPU_CAVIUM_OCTEON: \
> > + case CPU_CAVIUM_OCTEON_PLUS: \
> > + case CPU_CAVIUM_OCTEON2: \
> [...]
>
> These last two constants aren't defined in 2.6.32, so they would need to
> be removed too. But I don't think this is needed at all.
Ah thanks, I only built x86_64 and i386. OK I'm dropping the whole patch.
Thanks,
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-15 11:37 ` Ben Hutchings
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Ralf Baechle, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ralf Baechle <ralf@linux-mips.org>
commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.
This is no longer needed with the fixed, new and improved definition
of cpu_has_mips_r2_exec_hazard in <asm/cpu-features.h>.
For a discussion, see http://patchwork.linux-mips.org/patch/9539/.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit af2b0e8019d23d6db0ec339821aec23f6c19e367)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h b/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h
index 425e708..c829fde 100644
--- a/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h
+++ b/arch/mips/include/asm/mach-cavium-octeon/cpu-feature-overrides.h
@@ -51,7 +51,6 @@
#define cpu_has_mips32r2 0
#define cpu_has_mips64r1 0
#define cpu_has_mips64r2 1
-#define cpu_has_mips_r2_exec_hazard 0
#define cpu_has_dsp 0
#define cpu_has_mipsmt 0
#define cpu_has_userlocal 0
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
2015-09-12 22:56 ` [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard Willy Tarreau
@ 2015-09-15 11:37 ` Ben Hutchings
2015-09-16 5:17 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 11:37 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable, Ralf Baechle
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Ralf Baechle <ralf@linux-mips.org>
>
> commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.
>
> This is no longer needed with the fixed, new and improved definition
> of cpu_has_mips_r2_exec_hazard in <asm/cpu-features.h>.
[...]
This needs to be dropped along with the previous patch.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 36/62] MIPS: Octeon: Delete override of cpu_has_mips_r2_exec_hazard.
2015-09-15 11:37 ` Ben Hutchings
@ 2015-09-16 5:17 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-16 5:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, stable, Ralf Baechle
On Tue, Sep 15, 2015 at 12:37:21PM +0100, Ben Hutchings wrote:
> > From: Ralf Baechle <ralf@linux-mips.org>
> >
> > commit f05ff43355e6997c18f82ddcee370a6e5f8643ce upstream.
> >
> > This is no longer needed with the fixed, new and improved definition
> > of cpu_has_mips_r2_exec_hazard in <asm/cpu-features.h>.
> [...]
>
> This needs to be dropped along with the previous patch.
Good catch indeed. Done.
Thanks,
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 37/62] hrtimer: Allow concurrent hrtimer_start() for self restarting timers
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Peter Zijlstra (Intel),
Ben Segall, Roman Gushchin, Paul Turner, Thomas Gleixner,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <peterz@infradead.org>
commit 5de2755c8c8b3a6b8414870e2c284914a2b42e4d upstream.
Because we drop cpu_base->lock around calling hrtimer::function, it is
possible for hrtimer_start() to come in between and enqueue the timer.
If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON
because HRTIMER_STATE_ENQUEUED will be set.
Since the above is a perfectly valid scenario, remove the BUG_ON and
make the enqueue_hrtimer() call conditional on the timer not being
enqueued already.
NOTE: in that concurrent scenario its entirely common for both sites
to want to modify the hrtimer, since hrtimers don't provide
serialization themselves be sure to provide some such that the
hrtimer::function and the hrtimer_start() caller don't both try and
fudge the expiration state at the same time.
To that effect, add a WARN when someone tries to forward an already
enqueued timer, the most common way to change the expiry of self
restarting timers. Ideally we'd put the WARN in everything modifying
the expiry but most of that is inlines and we don't need the bloat.
Fixes: 2d44ae4d7135 ("hrtimer: clean up cpu->base locking tricks")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Ben Segall <bsegall@google.com>
Cc: Roman Gushchin <klamm@yandex-team.ru>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415113105.GT5029@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit ba4a679df78ffd52405af90aae3f4481c6945d6d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/hrtimer.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 2818422..db56532 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -803,6 +803,9 @@ u64 hrtimer_forward(struct hrtimer *timer, ktime_t now, ktime_t interval)
if (delta.tv64 < 0)
return 0;
+ if (WARN_ON(timer->state & HRTIMER_STATE_ENQUEUED))
+ return 0;
+
if (interval.tv64 < timer->base->resolution.tv64)
interval.tv64 = timer->base->resolution.tv64;
@@ -1229,11 +1232,14 @@ static void __run_hrtimer(struct hrtimer *timer, ktime_t *now)
* Note: We clear the CALLBACK bit after enqueue_hrtimer and
* we do not reprogramm the event hardware. Happens either in
* hrtimer_start_range_ns() or in hrtimer_interrupt()
+ *
+ * Note: Because we dropped the cpu_base->lock above,
+ * hrtimer_start_range_ns() can have popped in and enqueued the timer
+ * for us already.
*/
- if (restart != HRTIMER_NORESTART) {
- BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
+ if (restart != HRTIMER_NORESTART &&
+ !(timer->state & HRTIMER_STATE_ENQUEUED))
enqueue_hrtimer(timer, base);
- }
WARN_ON_ONCE(!(timer->state & HRTIMER_STATE_CALLBACK));
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 38/62] s5h1420: fix a buffer overflow when checking userspace params
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Mauro Carvalho Chehab, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up to 7 values:
drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 4bf124b5f179a9c169c57ef7cd3a74f239063ed1)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/media/dvb/frontends/s5h1420.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb/frontends/s5h1420.c b/drivers/media/dvb/frontends/s5h1420.c
index 2e9fd28..6134578 100644
--- a/drivers/media/dvb/frontends/s5h1420.c
+++ b/drivers/media/dvb/frontends/s5h1420.c
@@ -180,7 +180,7 @@ static int s5h1420_send_master_cmd (struct dvb_frontend* fe,
int result = 0;
dprintk("enter %s\n", __func__);
- if (cmd->msg_len > 8)
+ if (cmd->msg_len > sizeof(cmd->msg))
return -EINVAL;
/* setup for DISEQC */
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 39/62] cx24116: fix a buffer overflow when checking userspace params
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Mauro Carvalho Chehab, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream.
The maximum size for a DiSEqC command is 6, according to the
userspace API. However, the code allows to write up much more values:
drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 729c8c5e3700410e3436573abfa5b68e8d3c89d6)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/media/dvb/frontends/cx24116.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/frontends/cx24116.c b/drivers/media/dvb/frontends/cx24116.c
index 2410d8b..b7d4847 100644
--- a/drivers/media/dvb/frontends/cx24116.c
+++ b/drivers/media/dvb/frontends/cx24116.c
@@ -950,6 +950,10 @@ static int cx24116_send_diseqc_msg(struct dvb_frontend *fe,
struct cx24116_state *state = fe->demodulator_priv;
int i, ret;
+ /* Validate length */
+ if (d->msg_len > sizeof(d->msg))
+ return -EINVAL;
+
/* Dump DiSEqC message */
if (debug) {
printk(KERN_INFO "cx24116: %s(", __func__);
@@ -961,10 +965,6 @@ static int cx24116_send_diseqc_msg(struct dvb_frontend *fe,
printk(") toneburst=%d\n", toneburst);
}
- /* Validate length */
- if (d->msg_len > (CX24116_ARGLEN - CX24116_DISEQC_MSGOFS))
- return -EINVAL;
-
/* DiSEqC message */
for (i = 0; i < d->msg_len; i++)
state->dsec_cmd.args[CX24116_DISEQC_MSGOFS + i] = d->msg[i];
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 40/62] pktgen: adjust spacing in proc file interface output
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jesper Dangaard Brouer, David S. Miller, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jesper Dangaard Brouer <brouer@redhat.com>
commit d079abd181950a44cdf31daafd1662388a6c4d2e upstream.
Too many spaces were introduced in commit 63adc6fb8ac0 ("pktgen: cleanup
checkpatch warnings"), thus misaligning "src_min:" to other columns.
Fixes: 63adc6fb8ac0 ("pktgen: cleanup checkpatch warnings")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 7acdcce017318585ddb3eacd1d04610b62f181a5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/core/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index f776b99..5b055af 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -560,7 +560,7 @@ static int pktgen_if_show(struct seq_file *seq, void *v)
" dst_min: %s dst_max: %s\n",
pkt_dev->dst_min, pkt_dev->dst_max);
seq_printf(seq,
- " src_min: %s src_max: %s\n",
+ " src_min: %s src_max: %s\n",
pkt_dev->src_min, pkt_dev->src_max);
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 41/62] staging: vt6655: device_rx_srv check sk_buff is NULL
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Malcolm Priestley, Greg Kroah-Hartman, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Malcolm Priestley <tvboxspy@gmail.com>
commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 upstream.
There is a small chance that pRD->pRDInfo->skb could go NULL
while the interrupt is processing.
Put NULL check on loop to break out.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 35ee488df7402c0549f8329dc20690cf7fe22492)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/staging/vt6655/device_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c
index 269d1e2..1680bed 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1605,6 +1605,10 @@ static int device_rx_srv(PSDevice pDevice, UINT uIdx) {
// DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "pDevice->pCurrRD = %x, works = %d\n", pRD, works);
if (works++>15)
break;
+
+ if (!pRD->pRDInfo->skb)
+ break;
+
if (device_receive_frame(pDevice, pRD)) {
if (!device_alloc_rx_buf(pDevice,pRD)) {
DBG_PRT(MSG_LEVEL_ERR, KERN_ERR
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery
@ 2015-09-12 22:56 ` Willy Tarreau
2015-09-14 23:54 ` Kornievskaia, Olga
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Olga Kornievskaia, Trond Myklebust, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Olga Kornievskaia <kolga@netapp.com>
commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream.
Problem: When an operation like WRITE receives a BAD_STATEID, even though
recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
the open state, because of clearing delegation state for the associated
inode, nfs_inode_find_state_and_recover() gets called and it makes the
same state with RECLAIM_NOGRACE flag again. As a results, when we restart
looking over the open states, we end up in the infinite loop instead of
breaking out in the next test of state flags.
Solution: unset the RECLAIM_NOGRACE set because of
calling of nfs_inode_find_state_and_recover() after returning from calling
recover_open() function.
Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit ef8500b18fc4bb03286a93b6032d56ec7bcbfd15)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/nfs/nfs4state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 2a7f163..71ee6f6 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -929,6 +929,8 @@ restart:
__func__);
}
nfs4_put_open_state(state);
+ clear_bit(NFS4CLNT_RECLAIM_NOGRACE,
+ &state->flags);
goto restart;
}
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery
2015-09-12 22:56 ` [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery Willy Tarreau
@ 2015-09-14 23:54 ` Kornievskaia, Olga
2015-09-15 5:37 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Kornievskaia, Olga @ 2015-09-14 23:54 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable, Trond Myklebust, Ben Hutchings
Hi Willy,
I believe the patch introduced another problem and needs to be corrected.
> On Sep 12, 2015, at 6:56 PM, Willy Tarreau <w@1wt.eu> wrote:
>
> 2.6.32-longterm review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Olga Kornievskaia <kolga@netapp.com>
>
> commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream.
>
> Problem: When an operation like WRITE receives a BAD_STATEID, even though
> recovery code clears the RECLAIM_NOGRACE recovery flag before recovering
> the open state, because of clearing delegation state for the associated
> inode, nfs_inode_find_state_and_recover() gets called and it makes the
> same state with RECLAIM_NOGRACE flag again. As a results, when we restart
> looking over the open states, we end up in the infinite loop instead of
> breaking out in the next test of state flags.
>
> Solution: unset the RECLAIM_NOGRACE set because of
> calling of nfs_inode_find_state_and_recover() after returning from calling
> recover_open() function.
>
> Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
> [bwh: Backported to 3.2: adjust context]
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> (cherry picked from commit ef8500b18fc4bb03286a93b6032d56ec7bcbfd15)
>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> fs/nfs/nfs4state.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index 2a7f163..71ee6f6 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -929,6 +929,8 @@ restart:
> __func__);
> }
> nfs4_put_open_state(state);
> + clear_bit(NFS4CLNT_RECLAIM_NOGRACE,
> + &state->flags);
> goto restart;
> }
> }
> --
> 1.7.12.2.21.g234cd45.dirty
>
>
>
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 42/62] fixing infinite OPEN loop in 4.0 stateid recovery
2015-09-14 23:54 ` Kornievskaia, Olga
@ 2015-09-15 5:37 ` Willy Tarreau
[not found] ` <7E69BA76-E3DF-4389-A8C4-F23C9E1FD5CC@netapp.com>
0 siblings, 1 reply; 87+ messages in thread
From: Willy Tarreau @ 2015-09-15 5:37 UTC (permalink / raw)
To: Kornievskaia, Olga; +Cc: linux-kernel, stable, Trond Myklebust, Ben Hutchings
Hi Olga,
On Mon, Sep 14, 2015 at 11:54:34PM +0000, Kornievskaia, Olga wrote:
> Hi Willy,
>
> I believe the patch introduced another problem and needs to be corrected.
Can you be more specific ? What problem, or how to verify which one ?
Should the patch simply be reverted ?
Thanks,
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 43/62] SUNRPC: Fix a memory leak in the backchannel code
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Trond Myklebust, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Trond Myklebust <trond.myklebust@primarydata.com>
commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream.
req->rq_private_buf isn't initialised when xprt_setup_backchannel calls
xprt_free_allocation.
Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit bd031759bcc0865938ecc52846a3f22f2a26ad8e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/sunrpc/backchannel_rqst.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
index 553621f..b993a49 100644
--- a/net/sunrpc/backchannel_rqst.c
+++ b/net/sunrpc/backchannel_rqst.c
@@ -59,7 +59,7 @@ static void xprt_free_allocation(struct rpc_rqst *req)
dprintk("RPC: free allocations for req= %p\n", req);
BUG_ON(test_bit(RPC_BC_PA_IN_USE, &req->rq_bc_pa_state));
- xbufp = &req->rq_private_buf;
+ xbufp = &req->rq_rcv_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
xbufp = &req->rq_snd_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 44/62] dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Lior Amsalem, Maxime Ripard, Ofer Heifetz, Vinod Koul,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Lior Amsalem <alior@marvell.com>
commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream.
This patch fixes a bug in the XOR driver where the cleanup function can be
called and free descriptors that never been processed by the engine (which
result in data errors).
The cleanup function will free descriptors based on the ownership bit in
the descriptors.
Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine")
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Ofer Heifetz <oferh@marvell.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 26aa1c6949dfef77d3aa77e4cb504ccfd8394ce9)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/dma/mv_xor.c | 72 +++++++++++++++++++++++++++++++++-------------------
drivers/dma/mv_xor.h | 1 +
2 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 076d599..d9cc96d 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -387,7 +387,8 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan *mv_chan)
dma_cookie_t cookie = 0;
int busy = mv_chan_is_busy(mv_chan);
u32 current_desc = mv_chan_get_current_desc(mv_chan);
- int seen_current = 0;
+ int current_cleaned = 0;
+ struct mv_xor_desc *hw_desc;
dev_dbg(mv_chan->device->common.dev, "%s %d\n", __func__, __LINE__);
dev_dbg(mv_chan->device->common.dev, "current_desc %x\n", current_desc);
@@ -399,38 +400,57 @@ static void __mv_xor_slot_cleanup(struct mv_xor_chan *mv_chan)
list_for_each_entry_safe(iter, _iter, &mv_chan->chain,
chain_node) {
- prefetch(_iter);
- prefetch(&_iter->async_tx);
- /* do not advance past the current descriptor loaded into the
- * hardware channel, subsequent descriptors are either in
- * process or have not been submitted
- */
- if (seen_current)
- break;
+ /* clean finished descriptors */
+ hw_desc = iter->hw_desc;
+ if (hw_desc->status & XOR_DESC_SUCCESS) {
+ cookie = mv_xor_run_tx_complete_actions(iter, mv_chan,
+ cookie);
- /* stop the search if we reach the current descriptor and the
- * channel is busy
- */
- if (iter->async_tx.phys == current_desc) {
- seen_current = 1;
- if (busy)
+ /* done processing desc, clean slot */
+ mv_xor_clean_slot(iter, mv_chan);
+
+ /* break if we did cleaned the current */
+ if (iter->async_tx.phys == current_desc) {
+ current_cleaned = 1;
+ break;
+ }
+ } else {
+ if (iter->async_tx.phys == current_desc) {
+ current_cleaned = 0;
break;
+ }
}
-
- cookie = mv_xor_run_tx_complete_actions(iter, mv_chan, cookie);
-
- if (mv_xor_clean_slot(iter, mv_chan))
- break;
}
if ((busy == 0) && !list_empty(&mv_chan->chain)) {
- struct mv_xor_desc_slot *chain_head;
- chain_head = list_entry(mv_chan->chain.next,
- struct mv_xor_desc_slot,
- chain_node);
-
- mv_xor_start_new_chain(mv_chan, chain_head);
+ if (current_cleaned) {
+ /*
+ * current descriptor cleaned and removed, run
+ * from list head
+ */
+ iter = list_entry(mv_chan->chain.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+ mv_xor_start_new_chain(mv_chan, iter);
+ } else {
+ if (!list_is_last(&iter->chain_node, &mv_chan->chain)) {
+ /*
+ * descriptors are still waiting after
+ * current, trigger them
+ */
+ iter = list_entry(iter->chain_node.next,
+ struct mv_xor_desc_slot,
+ chain_node);
+ mv_xor_start_new_chain(mv_chan, iter);
+ } else {
+ /*
+ * some descriptors are still waiting
+ * to be cleaned
+ */
+ tasklet_schedule(&mv_chan->irq_tasklet);
+ }
+ }
}
if (cookie > 0)
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index 977b592..ae2cfba 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -30,6 +30,7 @@
#define XOR_OPERATION_MODE_XOR 0
#define XOR_OPERATION_MODE_MEMCPY 2
#define XOR_OPERATION_MODE_MEMSET 4
+#define XOR_DESC_SUCCESS 0x40000000
#define XOR_CURR_DESC(chan) (chan->mmr_base + 0x210 + (chan->idx * 4))
#define XOR_NEXT_DESC(chan) (chan->mmr_base + 0x200 + (chan->idx * 4))
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 45/62] ext4: fix race between truncate and __ext4_journalled_writepage()
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Theodore Tso, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream.
The commit cf108bca465d: "ext4: Invert the locking order of page_lock
and transaction start" caused __ext4_journalled_writepage() to drop
the page lock before the page was written back, as part of changing
the locking order to jbd2_journal_start -> page_lock. However, this
introduced a potential race if there was a truncate racing with the
data=journalled writeback mode.
Fix this by grabbing the page lock after starting the journal handle,
and then checking to see if page had gotten truncated out from under
us.
This fixes a number of different warnings or BUG_ON's when running
xfstests generic/086 in data=journalled mode, including:
jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7
c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0
- and -
kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200!
...
Call Trace:
[<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
[<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117
[<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117
[<c027d883>] ? lock_buffer+0x36/0x36
[<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22
[<c0229139>] do_invalidatepage+0x22/0x26
[<c0229198>] truncate_inode_page+0x5b/0x85
[<c022934b>] truncate_inode_pages_range+0x156/0x38c
[<c0229592>] truncate_inode_pages+0x11/0x15
[<c022962d>] truncate_pagecache+0x55/0x71
[<c02b913b>] ext4_setattr+0x4a9/0x560
[<c01ca542>] ? current_kernel_time+0x10/0x44
[<c026c4d8>] notify_change+0x1c7/0x2be
[<c0256a00>] do_truncate+0x65/0x85
[<c0226f31>] ? file_ra_state_init+0x12/0x29
- and -
WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396
irty_metadata+0x14a/0x1ae()
...
Call Trace:
[<c01b879f>] ? console_unlock+0x3a1/0x3ce
[<c082cbb4>] dump_stack+0x48/0x60
[<c0178b65>] warn_slowpath_common+0x89/0xa0
[<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae
[<c0178bef>] warn_slowpath_null+0x14/0x18
[<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae
[<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d
[<c02b2f44>] write_end_fn+0x40/0x53
[<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a
[<c02b59e7>] ext4_writepage+0x354/0x3b8
[<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4
[<c02b1b21>] ? wait_on_buffer+0x2c/0x2c
[<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
[<c02b5a5b>] __writepage+0x10/0x2e
[<c0225956>] write_cache_pages+0x22d/0x32c
[<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8
[<c02b6ee8>] ext4_writepages+0x102/0x607
[<c019adfe>] ? sched_clock_local+0x10/0x10e
[<c01a8a7c>] ? __lock_is_held+0x2e/0x44
[<c01a8ad5>] ? lock_is_held+0x43/0x51
[<c0226dff>] do_writepages+0x1c/0x29
[<c0276bed>] __writeback_single_inode+0xc3/0x545
[<c0277c07>] writeback_sb_inodes+0x21f/0x36d
...
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit b77ea3c2439c54f864487fb7a69007027c833bfb)
[wt: adjusted context since we're missing 441c850]
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/ext4/inode.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index babf448..90077ec 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2670,13 +2670,27 @@ static int __ext4_journalled_writepage(struct page *page,
page_bufs = page_buffers(page);
BUG_ON(!page_bufs);
walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
- /* As soon as we unlock the page, it can go away, but we have
- * references to buffers so we are safe */
+ /*
+ * We need to release the page lock before we start the
+ * journal, so grab a reference so the page won't disappear
+ * out from under us.
+ */
+ get_page(page);
unlock_page(page);
handle = ext4_journal_start(inode, ext4_writepage_trans_blocks(inode));
if (IS_ERR(handle)) {
ret = PTR_ERR(handle);
+ put_page(page);
+ goto out_no_pagelock;
+ }
+
+ lock_page(page);
+ put_page(page);
+ if (page->mapping != mapping) {
+ /* The page got truncated from under us */
+ ext4_journal_stop(handle);
+ ret = 0;
goto out;
}
@@ -2694,6 +2708,8 @@ static int __ext4_journalled_writepage(struct page *page,
walk_page_buffers(handle, page_bufs, 0, len, NULL, bput_one);
ext4_set_inode_state(inode, EXT4_STATE_JDATA);
out:
+ unlock_page(page);
+out_no_pagelock:
return ret;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 46/62] Disable write buffering on Toshiba ToPIC95
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ryan C. Underwood, Dominik Brodowski, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Underwood <nemesis@icequake.net>
commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.
Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
Signed-off-by: Ryan C. Underwood <nemesis@icequake.net>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 1e287196507c4272f7096ad4b4f10b1cf4b9d280)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/pcmcia/topic.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pcmcia/topic.h b/drivers/pcmcia/topic.h
index edccfa5..998a2a2 100644
--- a/drivers/pcmcia/topic.h
+++ b/drivers/pcmcia/topic.h
@@ -104,6 +104,9 @@
#define TOPIC_EXCA_IF_CONTROL 0x3e /* 8 bit */
#define TOPIC_EXCA_IFC_33V_ENA 0x01
+#define TOPIC_PCI_CFG_PPBCN 0x3e /* 16-bit */
+#define TOPIC_PCI_CFG_PPBCN_WBEN 0x0400
+
static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket, socket);
@@ -143,6 +146,7 @@ static int topic97_override(struct yenta_socket *socket)
static int topic95_override(struct yenta_socket *socket)
{
u8 fctrl;
+ u16 ppbcn;
/* enable 3.3V support for 16bit cards */
fctrl = exca_readb(socket, TOPIC_EXCA_IF_CONTROL);
@@ -151,6 +155,18 @@ static int topic95_override(struct yenta_socket *socket)
/* tell yenta to use exca registers to power 16bit cards */
socket->flags |= YENTA_16BIT_POWER_EXCA | YENTA_16BIT_POWER_DF;
+ /* Disable write buffers to prevent lockups under load with numerous
+ Cardbus cards, observed on Tecra 500CDT and reported elsewhere on the
+ net. This is not a power-on default according to the datasheet
+ but some BIOSes seem to set it. */
+ if (pci_read_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, &ppbcn) == 0
+ && socket->dev->revision <= 7
+ && (ppbcn & TOPIC_PCI_CFG_PPBCN_WBEN)) {
+ ppbcn &= ~TOPIC_PCI_CFG_PPBCN_WBEN;
+ pci_write_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ppbcn);
+ dev_info(&socket->dev->dev, "Disabled ToPIC95 Cardbus write buffers.\n");
+ }
+
return 0;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 47/62] nfs: increase size of EXCHANGE_ID name string buffer
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Michael Skralivetsky, Jeff Layton, Trond Myklebust,
Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <jlayton@poochiereds.net>
commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.
The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.
Reported-by: Michael Skralivetsky <michael.skralivetsky@primarydata.com>
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit ef24842ca0c24ef7223a0853f7603b1afe7deb11)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
include/linux/nfs_xdr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index 62f63fb..5c8f703 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -902,7 +902,7 @@ struct nfs_impl_id4 {
struct nfstime4 date;
};
-#define NFS4_EXCHANGE_ID_LEN (48)
+#define NFS4_EXCHANGE_ID_LEN (127)
struct nfs41_exchange_id_args {
struct nfs_client *client;
nfs4_verifier *verifier;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 48/62] ext4: call sync_blockdev() before invalidate_bdev() in put_super()
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Theodore Tso, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <tytso@mit.edu>
commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.
Normally all of the buffers will have been forced out to disk before
we call invalidate_bdev(), but there will be some cases, where a file
system operation was aborted due to an ext4_error(), where there may
still be some dirty buffers in the buffer cache for the device. So
try to force them out to memory before calling invalidate_bdev().
This fixes a warning triggered by generic/081:
WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f()
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 5dedaea4936981382ec0d9833ad372ebd3d8af57)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/ext4/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 108515f..045e7bf 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -652,6 +652,7 @@ static void ext4_put_super(struct super_block *sb)
dump_orphan_list(sb, sbi);
J_ASSERT(list_empty(&sbi->s_orphan));
+ sync_blockdev(sb->s_bdev);
invalidate_bdev(sb->s_bdev);
if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {
/*
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 49/62] NET: ROSE: Dont dereference NULL neighbour pointer.
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ralf Baechle, Bernard Pidoux, David S. Miller, Ben Hutchings,
Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Ralf Baechle <ralf@linux-mips.org>
commit d496f7842aada20c61e6044b3395383fa972872c upstream.
A ROSE socket doesn't necessarily always have a neighbour pointer so check
if the neighbour pointer is valid before dereferencing it.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Tested-by: Bernard Pidoux <f6bvp@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 8bbe4f448c01949084ef404eded3622086f052a6)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/rose/af_rose.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/rose/af_rose.c b/net/rose/af_rose.c
index 7119ea6..4457e9a 100644
--- a/net/rose/af_rose.c
+++ b/net/rose/af_rose.c
@@ -194,7 +194,8 @@ static void rose_kill_by_device(struct net_device *dev)
if (rose->device == dev) {
rose_disconnect(s, ENETUNREACH, ROSE_OUT_OF_ORDER, 0);
- rose->neighbour->use--;
+ if (rose->neighbour)
+ rose->neighbour->use--;
rose->device = NULL;
}
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 50/62] mm: kmemleak: allow safe memory scanning during kmemleak disabling
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Catalin Marinas, Vignesh Radhakrishnan, Andrew Morton,
Linus Torvalds, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Catalin Marinas <catalin.marinas@arm.com>
commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.
The kmemleak scanning thread can run for minutes. Callbacks like
kmemleak_free() are allowed during this time, the race being taken care
of by the object->lock spinlock. Such lock also prevents a memory block
from being freed or unmapped while it is being scanned by blocking the
kmemleak_free() -> ... -> __delete_object() function until the lock is
released in scan_object().
When a kmemleak error occurs (e.g. it fails to allocate its metadata),
kmemleak_enabled is set and __delete_object() is no longer called on
freed objects. If kmemleak_scan is running at the same time,
kmemleak_free() no longer waits for the object scanning to complete,
allowing the corresponding memory block to be freed or unmapped (in the
case of vfree()). This leads to kmemleak_scan potentially triggering a
page fault.
This patch separates the kmemleak_free() enabling/disabling from the
overall kmemleak_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed. The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org>
Tested-by: Vignesh Radhakrishnan <vigneshr@codeaurora.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
- Adjust context
- Drop changes to kmemleak_free_percpu()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 3bc68ffc5b43468537a2f0aa415f3b57f3b19d16)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
mm/kmemleak.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index c346660..e9bd6d5 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -191,6 +191,8 @@ static struct kmem_cache *scan_area_cache;
/* set if tracing memory operations is enabled */
static atomic_t kmemleak_enabled = ATOMIC_INIT(0);
+/* same as above but only for the kmemleak_free() callback */
+static int kmemleak_free_enabled;
/* set in the late_initcall if there were no errors */
static atomic_t kmemleak_initialized = ATOMIC_INIT(0);
/* enables or disables early logging of the memory operations */
@@ -870,7 +872,7 @@ void __ref kmemleak_free(const void *ptr)
{
pr_debug("%s(0x%p)\n", __func__, ptr);
- if (atomic_read(&kmemleak_enabled) && ptr && !IS_ERR(ptr))
+ if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
delete_object_full((unsigned long)ptr);
else if (atomic_read(&kmemleak_early_log))
log_early(KMEMLEAK_FREE, ptr, 0, 0, 0, 0);
@@ -1552,6 +1554,13 @@ static void kmemleak_do_cleanup(struct work_struct *work)
mutex_lock(&scan_mutex);
stop_scan_thread();
+ /*
+ * Once the scan thread has stopped, it is safe to no longer track
+ * object freeing. Ordering of the scan thread stopping and the memory
+ * accesses below is guaranteed by the kthread_stop() function.
+ */
+ kmemleak_free_enabled = 0;
+
rcu_read_lock();
list_for_each_entry_rcu(object, &object_list, object_list)
delete_object_full(object->pointer);
@@ -1578,6 +1587,8 @@ static void kmemleak_disable(void)
/* check whether it is too early for a kernel thread */
if (atomic_read(&kmemleak_initialized))
schedule_work(&cleanup_work);
+ else
+ kmemleak_free_enabled = 0;
pr_info("Kernel memory leak detector disabled\n");
}
@@ -1617,6 +1628,7 @@ void __init kmemleak_init(void)
if (!atomic_read(&kmemleak_error)) {
atomic_set(&kmemleak_enabled, 1);
atomic_set(&kmemleak_early_log, 0);
+ kmemleak_free_enabled = 1;
}
local_irq_restore(flags);
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 51/62] tracing/filter: Do not WARN on operand count going below zero
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Vince Weaver, Sasha Levin, Steven Rostedt, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.
When testing the fix for the trace filter, I could not come up with
a scenario where the operand count goes below zero, so I added a
WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
that it can happen (although the filter would be wrong).
# echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
That is, a single operation without any operands will hit the path
where the WARN_ON_ONCE() can trigger. Although this is harmless,
and the filter is reported as a error. But instead of spitting out
a warning to the kernel dmesg, just fail nicely and report it via
the proper channels.
Link: http://lkml.kernel.org/r/558C6082.90608@oracle.com
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit b43dd35952747f563d0dec7aefb7570260f10353)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/trace/trace_events_filter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index 098a1dc..ab10a9f 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1085,7 +1085,9 @@ static int check_preds(struct filter_parse_state *ps)
}
cnt--;
n_normal_preds++;
- WARN_ON_ONCE(cnt < 0);
+ /* all ops should have operands */
+ if (cnt < 0)
+ break;
}
if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 52/62] tracing/filter: Do not allow infix to exceed end of string
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Steven Rostedt, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream.
While debugging a WARN_ON() for filtering, I found that it is possible
for the filter string to be referenced after its end. With the filter:
# echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter
The filter_parse() function can call infix_get_op() which calls
infix_advance() that updates the infix filter pointers for the cnt
and tail without checking if the filter is already at the end, which
will put the cnt to zero and the tail beyond the end. The loop then calls
infix_next() that has
ps->infix.cnt--;
return ps->infix.string[ps->infix.tail++];
The cnt will now be below zero, and the tail that is returned is
already passed the end of the filter string. So far the allocation
of the filter string usually has some buffer that is zeroed out, but
if the filter string is of the exact size of the allocated buffer
there's no guarantee that the charater after the nul terminating
character will be zero.
Luckily, only root can write to the filter.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 7cc2315e7b9c148ee549d4cfbf68735a578b64db)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
kernel/trace/trace_events_filter.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/trace/trace_events_filter.c b/kernel/trace/trace_events_filter.c
index ab10a9f..c23d67b 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -752,6 +752,9 @@ static void parse_init(struct filter_parse_state *ps,
static char infix_next(struct filter_parse_state *ps)
{
+ if (!ps->infix.cnt)
+ return 0;
+
ps->infix.cnt--;
return ps->infix.string[ps->infix.tail++];
@@ -767,6 +770,9 @@ static char infix_peek(struct filter_parse_state *ps)
static void infix_advance(struct filter_parse_state *ps)
{
+ if (!ps->infix.cnt)
+ return;
+
ps->infix.cnt--;
ps->infix.tail++;
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 53/62] fuse: initialize fc->release before calling it
@ 2015-09-12 22:56 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:56 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Miklos Szeredi, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Miklos Szeredi <mszeredi@suse.cz>
commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream.
fc->release is called from fuse_conn_put() which was used in the error
cleanup before fc->release was initialized.
[Jeremiah Mahler <jmmahler@gmail.com>: assign fc->release after calling
fuse_conn_init(fc) instead of before.]
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit 1a713f9828a6abd288ecc9eef0bbe5c56d0ffc0b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/fuse/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
index c95186c..71b0cf0 100644
--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -970,6 +970,7 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent)
goto err_fput;
fuse_conn_init(fc);
+ fc->release = fuse_free_conn;
fc->dev = sb->s_dev;
fc->sb = sb;
@@ -984,7 +985,6 @@ static int fuse_fill_super(struct super_block *sb, void *data, int silent)
fc->dont_mask = 1;
sb->s_flags |= MS_POSIXACL;
- fc->release = fuse_free_conn;
fc->flags = d.flags;
fc->user_id = d.user_id;
fc->group_id = d.group_id;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 54/62] mm: avoid setting up anonymous pages into file mapping
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Kirill A. Shutemov, Oleg Nesterov, Andrew Morton, Willy Tarreau,
Linus Torvalds, Ben Hutchings
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream.
Reading page fault handler code I've noticed that under right
circumstances kernel would map anonymous pages into file mappings: if
the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated
on ->mmap(), kernel would handle page fault to not populated pte with
do_anonymous_page().
Let's change page fault handler to use do_anonymous_page() only on
anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not
shared.
For file mappings without vm_ops->fault() or shred VMA without vm_ops,
page fault on pte_none() entry would lead to SIGBUS.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit e2506476534cff7bb3697fbe0654fdefd101bc80)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
mm/memory.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 085b068..e36dee2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2727,6 +2727,10 @@ static int do_anonymous_page(struct mm_struct *mm, struct vm_area_struct *vma,
pte_unmap(page_table);
+ /* File mapping without ->vm_ops ? */
+ if (vma->vm_flags & VM_SHARED)
+ return VM_FAULT_SIGBUS;
+
/* Check if we need to add a guard page to the stack */
if (check_stack_guard_page(vma, address) < 0)
return VM_FAULT_SIGBUS;
@@ -2979,6 +2983,9 @@ static int do_linear_fault(struct mm_struct *mm, struct vm_area_struct *vma,
- vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
pte_unmap(page_table);
+ /* The VMA was not fully populated on mmap() or missing VM_DONTEXPAND */
+ if (!vma->vm_ops->fault)
+ return VM_FAULT_SIGBUS;
return __do_fault(mm, vma, address, pmd, pgoff, flags, orig_pte);
}
@@ -3037,11 +3044,9 @@ static inline int handle_pte_fault(struct mm_struct *mm,
entry = *pte;
if (!pte_present(entry)) {
if (pte_none(entry)) {
- if (vma->vm_ops) {
- if (likely(vma->vm_ops->fault))
- return do_linear_fault(mm, vma, address,
+ if (vma->vm_ops)
+ return do_linear_fault(mm, vma, address,
pte, pmd, flags, entry);
- }
return do_anonymous_page(mm, vma, address,
pte, pmd, flags);
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 55/62] s390/process: fix sfpc inline assembly
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Heiko Carstens, Martin Schwidefsky, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Heiko Carstens <heiko.carstens@de.ibm.com>
commit e47994dd44bcb4a77b4152bd0eada585934703c0 upstream.
The sfpc inline assembly within execve_tail() may incorrectly set bits
28-31 of the sfpc instruction to a value which is not zero.
These bits however are currently unused and therefore should be zero
so we won't get surprised if these bits will be used in the future.
Therefore remove the second operand from the inline assembly.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit b411a8a3b44d76e782ba4bc6893068f3f590fe8a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/s390/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/process.c b/arch/s390/kernel/process.c
index cea2855..0d3448d 100644
--- a/arch/s390/kernel/process.c
+++ b/arch/s390/kernel/process.c
@@ -261,7 +261,7 @@ asmlinkage void execve_tail(void)
{
current->thread.fp_regs.fpc = 0;
if (MACHINE_HAS_IEEE)
- asm volatile("sfpc %0,%0" : : "d" (0));
+ asm volatile("sfpc %0" : : "d" (0));
}
/*
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 56/62] libata: increase the timeout when setting transfer mode
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mikulas Patocka, Tejun Heo, Ben Hutchings, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Mikulas Patocka <mpatocka@redhat.com>
commit d531be2ca2f27cca5f041b6a140504999144a617 upstream.
I have a ST4000DM000 disk. If Linux is booted while the disk is spun down,
the command that sets transfer mode causes the disk to spin up. The
spin-up takes longer than the default 5s timeout, so the command fails and
timeout is reported.
Fix this by increasing the timeout to 15s, which is enough for the disk to
spin up.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit d6ded32444c070ce41ad0d64fce8957d18009d72)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/ata/libata-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d4f7f99..a61b4c3 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4635,7 +4635,8 @@ static unsigned int ata_dev_set_xfermode(struct ata_device *dev)
else /* In the ancient relic department - skip all of this */
return 0;
- err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0, 0);
+ /* On some disks, this command causes spin-up, so we need longer timeout */
+ err_mask = ata_exec_internal(dev, &tf, NULL, DMA_NONE, NULL, 0, 15000);
DPRINTK("EXIT, err_mask=%x\n", err_mask);
return err_mask;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 57/62] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ingo Molnar, Denys Vlasenko, Jan Beulich, Peter Zijlstra,
Andrew Cooper, H. Peter Anvin, Steven Rostedt, Andy Lutomirski,
David Vrabel, Willy Tarreau, Borislav Petkov, Andy Lutomirski,
Brian Gerst, Sasha Levin, Boris Ostrovsky, xen-devel,
Linus Torvalds, Thomas Gleixner, Ben Hutchings
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <luto@kernel.org>
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.
While we're at it, add comments to help explain what's going on.
This isn't a great long-term fix. This code should probably be
changed to use something like set_memory_ro.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <dvrabel@cantab.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit b48d6a721ba2cb475aea937c707f577aafa660a2)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 126a093..0bba7ac 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -277,6 +277,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+ unsigned char dummy;
ptep = lookup_address((unsigned long)v, &level);
BUG_ON(ptep == NULL);
@@ -286,6 +287,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte = pfn_pte(pfn, prot);
+ /*
+ * Careful: update_va_mapping() will fail if the virtual address
+ * we're poking isn't populated in the page tables. We don't
+ * need to worry about the direct map (that's always in the page
+ * tables), but we need to be careful about vmap space. In
+ * particular, the top level page table can lazily propagate
+ * entries between processes, so if we've switched mms since we
+ * vmapped the target in the first place, we might not have the
+ * top-level page table entry populated.
+ *
+ * We disable preemption because we want the same mm active when
+ * we probe the target and when we issue the hypercall. We'll
+ * have the same nominal mm, but if we're a kernel thread, lazy
+ * mm dropping could change our pgd.
+ *
+ * Out of an abundance of caution, this uses __get_user() to fault
+ * in the target address just in case there's some obscure case
+ * in which the target address isn't readable.
+ */
+
+ preempt_disable();
+
+ pagefault_disable(); /* Avoid warnings due to being atomic. */
+ __get_user(dummy, (unsigned char __user __force *)v);
+ pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
@@ -297,6 +324,8 @@ static void set_aliased_prot(void *v, pgprot_t prot)
BUG();
} else
kmap_flush_unused();
+
+ preempt_enable();
}
static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -304,6 +333,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
+ /*
+ * We need to mark the all aliases of the LDT pages RO. We
+ * don't need to call vm_flush_aliases(), though, since that's
+ * only responsible for flushing aliases out the TLBs, not the
+ * page tables, and Xen will flush the TLB for us if needed.
+ *
+ * To avoid confusing future readers: none of this is necessary
+ * to load the LDT. The hypervisor only checks this when the
+ * LDT is faulted in due to subsequent descriptor access.
+ */
+
for(i = 0; i < entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL_RO);
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 57/62] x86/xen: Probe target addresses in set_aliased_prot() before the hypercall
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andy Lutomirski, Andrew Cooper, Andy Lutomirski, Boris Ostrovsky,
Borislav Petkov, Brian Gerst, David Vrabel, Denys Vlasenko,
H. Peter Anvin, Jan Beulich, Konrad Rzeszutek Wilk,
Linus Torvalds, Peter Zijlstra, Sasha Levin, Steven Rostedt,
Thomas Gleixner, xen-devel, Ingo Molnar, Ben Hutchings,
Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <luto@kernel.org>
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this can
result in an OOPS when the target address is in unpopulated vmap
space.
While we're at it, add comments to help explain what's going on.
This isn't a great long-term fix. This code should probably be
changed to use something like set_memory_ro.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <dvrabel@cantab.net>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
(cherry picked from commit b48d6a721ba2cb475aea937c707f577aafa660a2)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
arch/x86/xen/enlighten.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 126a093..0bba7ac 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -277,6 +277,7 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte_t pte;
unsigned long pfn;
struct page *page;
+ unsigned char dummy;
ptep = lookup_address((unsigned long)v, &level);
BUG_ON(ptep == NULL);
@@ -286,6 +287,32 @@ static void set_aliased_prot(void *v, pgprot_t prot)
pte = pfn_pte(pfn, prot);
+ /*
+ * Careful: update_va_mapping() will fail if the virtual address
+ * we're poking isn't populated in the page tables. We don't
+ * need to worry about the direct map (that's always in the page
+ * tables), but we need to be careful about vmap space. In
+ * particular, the top level page table can lazily propagate
+ * entries between processes, so if we've switched mms since we
+ * vmapped the target in the first place, we might not have the
+ * top-level page table entry populated.
+ *
+ * We disable preemption because we want the same mm active when
+ * we probe the target and when we issue the hypercall. We'll
+ * have the same nominal mm, but if we're a kernel thread, lazy
+ * mm dropping could change our pgd.
+ *
+ * Out of an abundance of caution, this uses __get_user() to fault
+ * in the target address just in case there's some obscure case
+ * in which the target address isn't readable.
+ */
+
+ preempt_disable();
+
+ pagefault_disable(); /* Avoid warnings due to being atomic. */
+ __get_user(dummy, (unsigned char __user __force *)v);
+ pagefault_enable();
+
if (HYPERVISOR_update_va_mapping((unsigned long)v, pte, 0))
BUG();
@@ -297,6 +324,8 @@ static void set_aliased_prot(void *v, pgprot_t prot)
BUG();
} else
kmap_flush_unused();
+
+ preempt_enable();
}
static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
@@ -304,6 +333,17 @@ static void xen_alloc_ldt(struct desc_struct *ldt, unsigned entries)
const unsigned entries_per_page = PAGE_SIZE / LDT_ENTRY_SIZE;
int i;
+ /*
+ * We need to mark the all aliases of the LDT pages RO. We
+ * don't need to call vm_flush_aliases(), though, since that's
+ * only responsible for flushing aliases out the TLBs, not the
+ * page tables, and Xen will flush the TLB for us if needed.
+ *
+ * To avoid confusing future readers: none of this is necessary
+ * to load the LDT. The hypervisor only checks this when the
+ * LDT is faulted in due to subsequent descriptor access.
+ */
+
for(i = 0; i < entries; i += entries_per_page)
set_aliased_prot(ldt + i, PAGE_KERNEL_RO);
}
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* [PATCH 2.6.32 58/62] dccp: fix auto-loading of dccp(_probe)
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gerrit Renker, Neil Horman, David S. Miller, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe:
Fix module load dependencies between dccp and dccp_probe", from 15 Jan).
It fixes the construction of the first argument of try_then_request_module(),
where only valid return codes from the first argument should be returned.
What we do now is assign the result of register_jprobe() to ret, without
the side effect of the comparison.
Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/dccp/probe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 4875998..3ba43b8 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -164,8 +164,8 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- ret = try_then_request_module((register_jprobe(&dccp_send_probe) == 0),
- "dccp");
+ try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
+ "dccp");
if (ret)
goto err1;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 60/62] dccp: catch failed request_module call in dccp_probe init
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Gerrit Renker, Wang Weidong, David S. Miller, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: Wang Weidong <wangweidong1@huawei.com>
Check the return value of request_module during dccp_probe initialisation,
bail out if that call fails.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 965cdea825693c821d200e38fac9402cde6dce6a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/dccp/probe.c | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 89f25cb..1610810 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -151,17 +151,6 @@ static const struct file_operations dccpprobe_fops = {
.read = dccpprobe_read,
};
-static __init int setup_jprobe(void)
-{
- int ret = register_jprobe(&dccp_send_probe);
-
- if (ret) {
- request_module("dccp");
- ret = register_jprobe(&dccp_send_probe);
- }
- return ret;
-}
-
static __init int dccpprobe_init(void)
{
int ret = -ENOMEM;
@@ -175,7 +164,13 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- ret = setup_jprobe();
+ ret = register_jprobe(&dccp_send_probe);
+ if (ret) {
+ ret = request_module("dccp");
+ if (!ret)
+ ret = register_jprobe(&dccp_send_probe);
+ }
+
if (ret)
goto err1;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 61/62] dmaengine: fix missing cnt in ?: in dmatest
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dr. David Alan Gilbert, Dan Carpenter, Paul Gortmaker,
Nicolas Ferre, Dan Williams, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "Dr. David Alan Gilbert" <linux@treblig.org>
Hi,
On the latest tree my compiler has started giving the warning:
drivers/dma/dmatest.c:575:28: warning: the omitted middle operand in ?: will always be ?true?, suggest explicit middle operand [-Wparentheses]
The following patch fixes the missing middle clause with the same
fix that Nicolas Ferre used in the similar clauses.
(There seems to have been a race between him fixing that and
the extra clause going in a little later).
I don't actually know the dmatest code/structures, nor do I own
any hardware to test it on (assuming it needs a DMA engine);
but this patch builds, the existing code is almost certainly
wrong and the fix is the same as the corresponding lines above it.
(WTH is x=y?:z legal C anyway?)
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
(cherry picked from commit d07a74a546981a09ba490936645fbf0d1340b96c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
drivers/dma/dmatest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index a32a4cf..d7c282a 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -552,7 +552,7 @@ static int dmatest_add_channel(struct dma_chan *chan)
}
if (dma_has_cap(DMA_PQ, dma_dev->cap_mask)) {
cnt = dmatest_add_threads(dtc, DMA_PQ);
- thread_count += cnt > 0 ?: 0;
+ thread_count += cnt > 0 ? cnt : 0;
}
pr_info("dmatest: Started %u threads using %s\n",
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* [PATCH 2.6.32 62/62] ipv6: Fix return of xfrm6_tunnel_rcv()
@ 2015-09-12 22:57 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 22:57 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: David S. Miller, Willy Tarreau
2.6.32-longterm review patch. If anyone has any objections, please let me know.
------------------
From: "David S. Miller" <davem@davemloft.net>
Like ipv4, just return xfrm6_rcv_spi()'s return value directly.
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 6ac3f6649223d916bbdf1e823926f8f3b34b5d99)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/ipv6/xfrm6_tunnel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
index 48bb1e3..5980e6e 100644
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -258,7 +258,7 @@ static int xfrm6_tunnel_rcv(struct sk_buff *skb)
__be32 spi;
spi = xfrm6_tunnel_spi_lookup((xfrm_address_t *)&iph->saddr);
- return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi) > 0 ? : 0;
+ return xfrm6_rcv_spi(skb, IPPROTO_IPV6, spi);
}
static int xfrm6_tunnel_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
@ 2015-09-12 23:18 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-12 23:18 UTC (permalink / raw)
To: linux-kernel, stable
On Sun, Sep 13, 2015 at 12:56:06AM +0200, Willy Tarreau wrote:
> Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
I really meant Fri Sep 18 09:00:00 CEST 2015, sorry the unedited message
went out.
Also, special thanks go to Ben Hutchings who provided me with a clean
series of fixes ready to be applied to address the following CVEs :
CVE-2011-5321 CVE-2012-6689 CVE-2014-3184 CVE-2014-9683 CVE-2014-9728
CVE-2014-9729 CVE-2014-9730 CVE-2014-9731 CVE-2015-1805 CVE-2015-4167
CVE-2015-5364
Most of the remaining patches were backported directly from latest 3.2
and a few others were just fixes for build warnings. Nothing really
tricky here (at least I hope).
Willy
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
@ 2015-09-15 12:06 ` Ben Hutchings
2015-09-16 5:23 ` Willy Tarreau
0 siblings, 1 reply; 87+ messages in thread
From: Ben Hutchings @ 2015-09-15 12:06 UTC (permalink / raw)
To: Willy Tarreau; +Cc: linux-kernel, stable
On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> This is the start of the longterm review cycle for the 2.6.32.68 release.
> All patches will be posted as a response to this one. If anyone has any
> issue with these being applied, please let me know. If anyone is a
> maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> to the patch, please respond with it. If anyone thinks some important
> patches are missing and should be added prior to the release, please
> report them quickly with their respective mainline commit IDs.
>
> Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> Anything received after that time might be too late. If someone
> wants a bit more time for a deeper review, please let me know.
>
> NOTE: 2.6.32 is approaching end of support. There will probably be one
> or maybe two other versions issued in the next 3-6 months, and that will
> be all, at least for me. Adding to this the time it can take to validate
> and deploy in some environments, it probably makes sense to start to
> think about switching to another longterm branch. 3.2 and 3.4 are good
> candidates for those seeking rock-solid versions. Longterm branches and
> their projected EOLs are listed here :
>
> https://www.kernel.org/category/releases.html
>
> The whole patch series can be found in one patch at :
> https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
>
> The shortlog and diffstat are appended below.
[...]
Patches 3 "crypto: testmgr - update LZO compression test vectors",
58 "dccp: fix auto-loading of dccp(_probe)",
60 "dccp: catch failed request_module call in dccp_probe init",
61 "dmaengine: fix missing cnt in ?: in dmatest" and
62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
line in the commit mesage rather than the usual "commit xxx upstream."
Patches 10 and 59 didn't reach me at all, though I can guess from its
neighbours that 59 is cherry-picked from commit
d984e6197ecd2babc1537f42dc1e676133005cda upstream.
Ben.
^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
2015-09-15 12:06 ` Ben Hutchings
@ 2015-09-16 5:23 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-16 5:23 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, stable
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
On Tue, Sep 15, 2015 at 01:06:31PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > This is the start of the longterm review cycle for the 2.6.32.68 release.
> > All patches will be posted as a response to this one. If anyone has any
> > issue with these being applied, please let me know. If anyone is a
> > maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> > to the patch, please respond with it. If anyone thinks some important
> > patches are missing and should be added prior to the release, please
> > report them quickly with their respective mainline commit IDs.
> >
> > Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> > Anything received after that time might be too late. If someone
> > wants a bit more time for a deeper review, please let me know.
> >
> > NOTE: 2.6.32 is approaching end of support. There will probably be one
> > or maybe two other versions issued in the next 3-6 months, and that will
> > be all, at least for me. Adding to this the time it can take to validate
> > and deploy in some environments, it probably makes sense to start to
> > think about switching to another longterm branch. 3.2 and 3.4 are good
> > candidates for those seeking rock-solid versions. Longterm branches and
> > their projected EOLs are listed here :
> >
> > https://www.kernel.org/category/releases.html
> >
> > The whole patch series can be found in one patch at :
> > https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
> >
> > The shortlog and diffstat are appended below.
> [...]
>
> Patches 3 "crypto: testmgr - update LZO compression test vectors",
> 58 "dccp: fix auto-loading of dccp(_probe)",
> 60 "dccp: catch failed request_module call in dccp_probe init",
> 61 "dmaengine: fix missing cnt in ?: in dmatest" and
> 62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
> line in the commit mesage rather than the usual "commit xxx upstream."
Yes indeed, I cherry-picked them after the first build attempts when I
discovered build warnings. I'll add the line by hand.
> Patches 10 and 59 didn't reach me at all, though I can guess from its
> neighbours that 59 is cherry-picked from commit
> d984e6197ecd2babc1537f42dc1e676133005cda upstream.
Yep. Sorry for this, I'm attaching both of them to this e-mail, and
will add the upstream commit line to 59 as well.
Thanks,
Willy
[-- Attachment #2: 0010-udf-Treat-symlink-component-of-type-2-as.patch --]
[-- Type: text/plain, Size: 1535 bytes --]
>From 3f3fe288bb34818096135a93062ab588acbda269 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Mon, 12 Dec 2011 15:13:50 +0100
Subject: udf: Treat symlink component of type 2 as /
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: Jan Kara <jack@suse.cz>
commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.
Currently, we ignore symlink component of type 2. But mkisofs and other OS'
seem to treat it as / so do the same for compatibility.
Reported-by: "Gábor S." <otnaccess@hotmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Needed for the following fix]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/symlink.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index e28a902..2d60484 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -43,10 +43,16 @@ static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
case 1:
- if (pc->lengthComponentIdent == 0) {
- p = to;
- *p++ = '/';
- }
+ /*
+ * Symlink points to some place which should be agreed
+ * upon between originator and receiver of the media. Ignore.
+ */
+ if (pc->lengthComponentIdent > 0)
+ break;
+ /* Fall through */
+ case 2:
+ p = to;
+ *p++ = '/';
break;
case 3:
memcpy(p, "../", 3);
--
1.7.12.2.21.g234cd45.dirty
[-- Attachment #3: 0059-dccp-Fix-compile-warning-in-probe-code.patch --]
[-- Type: text/plain, Size: 2149 bytes --]
>From 361fb30bc6abac898b3815bef9e9a56a95f46059 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 1 Dec 2011 14:45:49 -0500
Subject: dccp: Fix compile warning in probe code.
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: "David S. Miller" <davem@davemloft.net>
Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix
auto-loading of dccp(_probe)") fixed a bug but created a new
compiler warning:
net/dccp/probe.c: In function ‘dccpprobe_init’:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses]
try_then_request_module() is built for situations where the
"existence" test is some lookup function that returns a non-NULL
object on success, and with a reference count of some kind held.
Here we're looking for a success return of zero from the jprobe
registry.
Instead of fighting the way try_then_request_module() works, simply
open code what we want to happen in a local helper function.
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d984e6197ecd2babc1537f42dc1e676133005cda)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/dccp/probe.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 3ba43b8..89f25cb 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -151,6 +151,17 @@ static const struct file_operations dccpprobe_fops = {
.read = dccpprobe_read,
};
+static __init int setup_jprobe(void)
+{
+ int ret = register_jprobe(&dccp_send_probe);
+
+ if (ret) {
+ request_module("dccp");
+ ret = register_jprobe(&dccp_send_probe);
+ }
+ return ret;
+}
+
static __init int dccpprobe_init(void)
{
int ret = -ENOMEM;
@@ -164,8 +175,7 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
- "dccp");
+ ret = setup_jprobe();
if (ret)
goto err1;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread* Re: [PATCH 2.6.32 00/62] 2.6.32.68-longterm review
@ 2015-09-16 5:23 ` Willy Tarreau
0 siblings, 0 replies; 87+ messages in thread
From: Willy Tarreau @ 2015-09-16 5:23 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-kernel, stable
[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]
On Tue, Sep 15, 2015 at 01:06:31PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-13 at 00:56 +0200, Willy Tarreau wrote:
> > This is the start of the longterm review cycle for the 2.6.32.68 release.
> > All patches will be posted as a response to this one. If anyone has any
> > issue with these being applied, please let me know. If anyone is a
> > maintainer of the proper subsystem, and wants to add a Signed-off-by: line
> > to the patch, please respond with it. If anyone thinks some important
> > patches are missing and should be added prior to the release, please
> > report them quickly with their respective mainline commit IDs.
> >
> > Responses should be made by Sat Sep 19 00:56:05 CEST 2015.
> > Anything received after that time might be too late. If someone
> > wants a bit more time for a deeper review, please let me know.
> >
> > NOTE: 2.6.32 is approaching end of support. There will probably be one
> > or maybe two other versions issued in the next 3-6 months, and that will
> > be all, at least for me. Adding to this the time it can take to validate
> > and deploy in some environments, it probably makes sense to start to
> > think about switching to another longterm branch. 3.2 and 3.4 are good
> > candidates for those seeking rock-solid versions. Longterm branches and
> > their projected EOLs are listed here :
> >
> > https://www.kernel.org/category/releases.html
> >
> > The whole patch series can be found in one patch at :
> > https://kernel.org/pub/linux/kernel/v2.6/longterm-review/patch-2.6.32.68-rc1.gz
> >
> > The shortlog and diffstat are appended below.
> [...]
>
> Patches 3 "crypto: testmgr - update LZO compression test vectors",
> 58 "dccp: fix auto-loading of dccp(_probe)",
> 60 "dccp: catch failed request_module call in dccp_probe init",
> 61 "dmaengine: fix missing cnt in ?: in dmatest" and
> 62 "ipv6: Fix return of xfrm6_tunnel_rcv()" have a git cherry-pick
> line in the commit mesage rather than the usual "commit xxx upstream."
Yes indeed, I cherry-picked them after the first build attempts when I
discovered build warnings. I'll add the line by hand.
> Patches 10 and 59 didn't reach me at all, though I can guess from its
> neighbours that 59 is cherry-picked from commit
> d984e6197ecd2babc1537f42dc1e676133005cda upstream.
Yep. Sorry for this, I'm attaching both of them to this e-mail, and
will add the upstream commit line to 59 as well.
Thanks,
Willy
[-- Attachment #2: 0010-udf-Treat-symlink-component-of-type-2-as.patch --]
[-- Type: text/plain, Size: 1537 bytes --]
>From 3f3fe288bb34818096135a93062ab588acbda269 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Mon, 12 Dec 2011 15:13:50 +0100
Subject: udf: Treat symlink component of type 2 as /
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: Jan Kara <jack@suse.cz>
commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream.
Currently, we ignore symlink component of type 2. But mkisofs and other OS'
seem to treat it as / so do the same for compatibility.
Reported-by: "G�bor S." <otnaccess@hotmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
[bwh: Needed for the following fix]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
fs/udf/symlink.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/fs/udf/symlink.c b/fs/udf/symlink.c
index e28a902..2d60484 100644
--- a/fs/udf/symlink.c
+++ b/fs/udf/symlink.c
@@ -43,10 +43,16 @@ static void udf_pc_to_char(struct super_block *sb, char *from, int fromlen,
pc = (struct pathComponent *)(from + elen);
switch (pc->componentType) {
case 1:
- if (pc->lengthComponentIdent == 0) {
- p = to;
- *p++ = '/';
- }
+ /*
+ * Symlink points to some place which should be agreed
+ * upon between originator and receiver of the media. Ignore.
+ */
+ if (pc->lengthComponentIdent > 0)
+ break;
+ /* Fall through */
+ case 2:
+ p = to;
+ *p++ = '/';
break;
case 3:
memcpy(p, "../", 3);
--
1.7.12.2.21.g234cd45.dirty
[-- Attachment #3: 0059-dccp-Fix-compile-warning-in-probe-code.patch --]
[-- Type: text/plain, Size: 2149 bytes --]
>From 361fb30bc6abac898b3815bef9e9a56a95f46059 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 1 Dec 2011 14:45:49 -0500
Subject: dccp: Fix compile warning in probe code.
MIME-Version: 1.0
Content-Type: text/plain; charset=latin1
Content-Transfer-Encoding: 8bit
From: "David S. Miller" <davem@davemloft.net>
Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix
auto-loading of dccp(_probe)") fixed a bug but created a new
compiler warning:
net/dccp/probe.c: In function ‘dccpprobe_init’:
net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses]
try_then_request_module() is built for situations where the
"existence" test is some lookup function that returns a non-NULL
object on success, and with a reference count of some kind held.
Here we're looking for a success return of zero from the jprobe
registry.
Instead of fighting the way try_then_request_module() works, simply
open code what we want to happen in a local helper function.
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit d984e6197ecd2babc1537f42dc1e676133005cda)
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
net/dccp/probe.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/dccp/probe.c b/net/dccp/probe.c
index 3ba43b8..89f25cb 100644
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -151,6 +151,17 @@ static const struct file_operations dccpprobe_fops = {
.read = dccpprobe_read,
};
+static __init int setup_jprobe(void)
+{
+ int ret = register_jprobe(&dccp_send_probe);
+
+ if (ret) {
+ request_module("dccp");
+ ret = register_jprobe(&dccp_send_probe);
+ }
+ return ret;
+}
+
static __init int dccpprobe_init(void)
{
int ret = -ENOMEM;
@@ -164,8 +175,7 @@ static __init int dccpprobe_init(void)
if (!proc_net_fops_create(&init_net, procname, S_IRUSR, &dccpprobe_fops))
goto err0;
- try_then_request_module((ret = register_jprobe(&dccp_send_probe)) == 0,
- "dccp");
+ ret = setup_jprobe();
if (ret)
goto err1;
--
1.7.12.2.21.g234cd45.dirty
^ permalink raw reply related [flat|nested] 87+ messages in thread