This is the start of the stable review cycle for the 3.0.84 release.
There are 17 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu Jun 27 18:35:59 UTC 2013.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.84-rc1.gz
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 3.0.84-rc1
Anders Hammarquist <[email protected]>
USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
Guillaume Nault <[email protected]>
l2tp: Fix sendmsg() return value
Guillaume Nault <[email protected]>
l2tp: Fix PPP header erasure and memory leak
Daniel Borkmann <[email protected]>
packet: packet_getname_spkt: make sure string is always 0-terminated
Daniel Borkmann <[email protected]>
net: sctp: fix NULL pointer dereference in socket destruction
Gao feng <[email protected]>
ipv6: assign rt6_info to inet6_ifaddr in init_loopback
Eric Dumazet <[email protected]>
net: force a reload of first item in hlist_nulls_for_each_entry_rcu
Andy Lutomirski <[email protected]>
net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
Eric Dumazet <[email protected]>
ip_tunnel: fix kernel panic with icmp_dest_unreach
Eric Dumazet <[email protected]>
tcp: xps: fix reordering issues
Paul Moore <[email protected]>
netlabel: improve domain mapping validation
Eric Dumazet <[email protected]>
ipv6: fix possible crashes in ip6_cork_release()
Wei Yongjun <[email protected]>
gianfar: add missing iounmap() on error in gianfar_ptp_probe()
Eric Dumazet <[email protected]>
tcp: fix tcp_md5_hash_skb_data()
Zhanghaoyu (A) <[email protected]>
KVM: x86: remove vcpu's CPL check in host-invoked XCR set
Chris Metcalf <[email protected]>
tilepro: work around module link error with gcc 4.7
Clemens Ladisch <[email protected]>
ALSA: usb-audio: work around Android accessory firmware bug
-------------
Diffstat:
Makefile | 4 +-
arch/tile/lib/exports.c | 2 +
arch/x86/kvm/x86.c | 5 +--
drivers/net/gianfar_ptp.c | 1 +
drivers/usb/serial/ti_usb_3410_5052.c | 3 +-
drivers/usb/serial/ti_usb_3410_5052.h | 4 +-
include/linux/rculist_nulls.h | 7 +++-
include/linux/socket.h | 3 ++
net/compat.c | 13 ++++++-
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ipip.c | 2 +-
net/ipv4/tcp.c | 6 ++-
net/ipv4/tcp_output.c | 10 +++--
net/ipv6/addrconf.c | 4 +-
net/ipv6/ip6_output.c | 2 +-
net/l2tp/l2tp_ppp.c | 6 +--
net/netlabel/netlabel_domainhash.c | 69 +++++++++++++++++++++++++++++++++++
net/packet/af_packet.c | 5 +--
net/sctp/socket.c | 6 +++
net/socket.c | 67 +++++++++++++++++++++++-----------
sound/usb/card.c | 22 ++++++++++-
21 files changed, 194 insertions(+), 49 deletions(-)
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Zhanghaoyu (A)" <[email protected]>
commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.
__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
called in two flows, one is invoked by guest, call stack shown as below,
handle_xsetbv(or xsetbv_interception)
kvm_set_xcr
__kvm_set_xcr
the other one is invoked by host, for example during system reset:
kvm_arch_vcpu_ioctl
kvm_vcpu_ioctl_x86_set_xcrs
__kvm_set_xcr
The former does need the CPL check, but the latter does not.
Signed-off-by: Zhang Haoyu <[email protected]>
[Tweaks to commit message. - Paolo]
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kvm/x86.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -548,8 +548,6 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
if (index != XCR_XFEATURE_ENABLED_MASK)
return 1;
xcr0 = xcr;
- if (kvm_x86_ops->get_cpl(vcpu) != 0)
- return 1;
if (!(xcr0 & XSTATE_FP))
return 1;
if ((xcr0 & XSTATE_YMM) && !(xcr0 & XSTATE_SSE))
@@ -563,7 +561,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
{
- if (__kvm_set_xcr(vcpu, index, xcr)) {
+ if (kvm_x86_ops->get_cpl(vcpu) != 0 ||
+ __kvm_set_xcr(vcpu, index, xcr)) {
kvm_inject_gp(vcpu, 0);
return 1;
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guillaume Nault <[email protected]>
[ Upstream commit a6f79d0f26704214b5b702bbac525cb72997f984 ]
PPPoL2TP sockets should comply with the standard send*() return values
(i.e. return number of bytes sent instead of 0 upon success).
Signed-off-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_ppp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -362,7 +362,7 @@ static int pppol2tp_sendmsg(struct kiocb
sock_put(ps->tunnel_sock);
sock_put(sk);
- return error;
+ return total_len;
error_put_sess_tun:
sock_put(ps->tunnel_sock);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
[ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
a7526eb5d06b0084ef12d7b168d008fcf516caab ]
MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
it's a hack that steals a bit to indicate to other networking code
that a compat entry was used. So don't allow it from a non-compat
syscall.
This prevents an oops when running this code:
int main()
{
int s;
struct sockaddr_in addr;
struct msghdr *hdr;
char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
if (highpage == MAP_FAILED)
err(1, "mmap");
s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
if (s == -1)
err(1, "socket");
addr.sin_family = AF_INET;
addr.sin_port = htons(1);
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
err(1, "connect");
void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
printf("Evil address is %p\n", evil);
if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
err(1, "sendmmsg");
return 0;
}
Cc: David S. Miller <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/socket.h | 3 ++
net/compat.c | 13 ++++++++-
net/socket.c | 67 ++++++++++++++++++++++++++++++++-----------------
3 files changed, 59 insertions(+), 24 deletions(-)
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -332,6 +332,9 @@ extern int put_cmsg(struct msghdr*, int
struct timespec;
+/* The __sys_...msg variants allow MSG_CMSG_COMPAT */
+extern long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags);
+extern long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
unsigned int flags, struct timespec *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
--- a/net/compat.c
+++ b/net/compat.c
@@ -732,19 +732,25 @@ static unsigned char nas[21] = {
asmlinkage long compat_sys_sendmsg(int fd, struct compat_msghdr __user *msg, unsigned flags)
{
- return sys_sendmsg(fd, (struct msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_sendmsg(fd, (struct msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_sendmmsg(int fd, struct compat_mmsghdr __user *mmsg,
unsigned vlen, unsigned int flags)
{
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recvmsg(int fd, struct compat_msghdr __user *msg, unsigned int flags)
{
- return sys_recvmsg(fd, (struct msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_recvmsg(fd, (struct msghdr __user *)msg, flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recv(int fd, void __user *buf, size_t len, unsigned flags)
@@ -766,6 +772,9 @@ asmlinkage long compat_sys_recvmmsg(int
int datagrams;
struct timespec ktspec;
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+
if (timeout == NULL)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, NULL);
--- a/net/socket.c
+++ b/net/socket.c
@@ -1876,9 +1876,9 @@ struct used_address {
unsigned int name_len;
};
-static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
- struct msghdr *msg_sys, unsigned flags,
- struct used_address *used_address)
+static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
+ struct msghdr *msg_sys, unsigned flags,
+ struct used_address *used_address)
{
struct compat_msghdr __user *msg_compat =
(struct compat_msghdr __user *)msg;
@@ -1998,22 +1998,30 @@ out:
* BSD sendmsg interface
*/
-SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned, flags)
+long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags)
{
int fput_needed, err;
struct msghdr msg_sys;
- struct socket *sock = sockfd_lookup_light(fd, &err, &fput_needed);
+ struct socket *sock;
+ sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (!sock)
goto out;
- err = __sys_sendmsg(sock, msg, &msg_sys, flags, NULL);
+ err = ___sys_sendmsg(sock, msg, &msg_sys, flags, NULL);
fput_light(sock->file, fput_needed);
out:
return err;
}
+SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned int, flags)
+{
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_sendmsg(fd, msg, flags);
+}
+
/*
* Linux sendmmsg interface
*/
@@ -2044,15 +2052,16 @@ int __sys_sendmmsg(int fd, struct mmsghd
while (datagrams < vlen) {
if (MSG_CMSG_COMPAT & flags) {
- err = __sys_sendmsg(sock, (struct msghdr __user *)compat_entry,
- &msg_sys, flags, &used_address);
+ err = ___sys_sendmsg(sock, (struct msghdr __user *)compat_entry,
+ &msg_sys, flags, &used_address);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
- err = __sys_sendmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags, &used_address);
+ err = ___sys_sendmsg(sock,
+ (struct msghdr __user *)entry,
+ &msg_sys, flags, &used_address);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
@@ -2076,11 +2085,13 @@ int __sys_sendmmsg(int fd, struct mmsghd
SYSCALL_DEFINE4(sendmmsg, int, fd, struct mmsghdr __user *, mmsg,
unsigned int, vlen, unsigned int, flags)
{
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
return __sys_sendmmsg(fd, mmsg, vlen, flags);
}
-static int __sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
- struct msghdr *msg_sys, unsigned flags, int nosec)
+static int ___sys_recvmsg(struct socket *sock, struct msghdr __user *msg,
+ struct msghdr *msg_sys, unsigned flags, int nosec)
{
struct compat_msghdr __user *msg_compat =
(struct compat_msghdr __user *)msg;
@@ -2177,23 +2188,31 @@ out:
* BSD recvmsg interface
*/
-SYSCALL_DEFINE3(recvmsg, int, fd, struct msghdr __user *, msg,
- unsigned int, flags)
+long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags)
{
int fput_needed, err;
struct msghdr msg_sys;
- struct socket *sock = sockfd_lookup_light(fd, &err, &fput_needed);
+ struct socket *sock;
+ sock = sockfd_lookup_light(fd, &err, &fput_needed);
if (!sock)
goto out;
- err = __sys_recvmsg(sock, msg, &msg_sys, flags, 0);
+ err = ___sys_recvmsg(sock, msg, &msg_sys, flags, 0);
fput_light(sock->file, fput_needed);
out:
return err;
}
+SYSCALL_DEFINE3(recvmsg, int, fd, struct msghdr __user *, msg,
+ unsigned int, flags)
+{
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_recvmsg(fd, msg, flags);
+}
+
/*
* Linux recvmmsg interface
*/
@@ -2231,17 +2250,18 @@ int __sys_recvmmsg(int fd, struct mmsghd
* No need to ask LSM for more than the first datagram.
*/
if (MSG_CMSG_COMPAT & flags) {
- err = __sys_recvmsg(sock, (struct msghdr __user *)compat_entry,
- &msg_sys, flags & ~MSG_WAITFORONE,
- datagrams);
+ err = ___sys_recvmsg(sock, (struct msghdr __user *)compat_entry,
+ &msg_sys, flags & ~MSG_WAITFORONE,
+ datagrams);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
- err = __sys_recvmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags & ~MSG_WAITFORONE,
- datagrams);
+ err = ___sys_recvmsg(sock,
+ (struct msghdr __user *)entry,
+ &msg_sys, flags & ~MSG_WAITFORONE,
+ datagrams);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
@@ -2308,6 +2328,9 @@ SYSCALL_DEFINE5(recvmmsg, int, fd, struc
int datagrams;
struct timespec timeout_sys;
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+
if (!timeout)
return __sys_recvmmsg(fd, mmsg, vlen, flags, NULL);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anders Hammarquist <[email protected]>
commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.
Signed-off-by: Anders Hammarquist <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/serial/ti_usb_3410_5052.c | 3 ++-
drivers/usb/serial/ti_usb_3410_5052.h | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -179,7 +179,8 @@ static struct usb_device_id ti_id_table_
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,7 +52,9 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_PRODUCT_ID 0x3410
+#define ABBOTT_STEREO_PLUG_ID 0x3410
+#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
+#define ABBOTT_STRIP_PORT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gao feng <[email protected]>
[ Upstream commit 534c877928a16ae5f9776436a497109639bf67dc ]
Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"
forgot to assign rt6_info to the inet6_ifaddr.
When disable the net device, the rt6_info which allocated
in init_loopback will not be destroied in __ipv6_ifa_notify.
This will trigger the waring message below
[23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage count = 1
Reported-by: Arkadiusz Miskiewicz <[email protected]>
Signed-off-by: Gao feng <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/addrconf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2360,8 +2360,10 @@ static void init_loopback(struct net_dev
sp_rt = addrconf_dst_alloc(idev, &sp_ifa->addr, 0);
/* Failure cases are ignored */
- if (!IS_ERR(sp_rt))
+ if (!IS_ERR(sp_rt)) {
+ sp_ifa->rt = sp_rt;
ip6_ins_rt(sp_rt);
+ }
}
read_unlock_bh(&idev->lock);
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guillaume Nault <[email protected]>
[ Upstream commit 55b92b7a11690bc377b5d373872a6b650ae88e64 ]
Copy user data after PPP framing header. This prevents erasure of the
added PPP header and avoids leaking two bytes of uninitialised memory
at the end of skb's data buffer.
Signed-off-by: Guillaume Nault <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/l2tp/l2tp_ppp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -350,12 +350,12 @@ static int pppol2tp_sendmsg(struct kiocb
skb_put(skb, 2);
/* Copy user data into skb */
- error = memcpy_fromiovec(skb->data, m->msg_iov, total_len);
+ error = memcpy_fromiovec(skb_put(skb, total_len), m->msg_iov,
+ total_len);
if (error < 0) {
kfree_skb(skb);
goto error_put_sess_tun;
}
- skb_put(skb, total_len);
l2tp_xmit_skb(session, skb, session->hdr_len);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <[email protected]>
[ Upstream commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c ]
While stress testing sctp sockets, I hit the following panic:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
PGD 7cead067 PUD 7ce76067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: sctp(F) libcrc32c(F) [...]
CPU: 7 PID: 2950 Comm: acc Tainted: GF 3.10.0-rc2+ #1
Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
task: ffff88007ce0e0c0 ti: ffff88007b568000 task.ti: ffff88007b568000
RIP: 0010:[<ffffffffa0490c4e>] [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
RSP: 0018:ffff88007b569e08 EFLAGS: 00010292
RAX: 0000000000000000 RBX: ffff88007db78a00 RCX: dead000000200200
RDX: ffffffffa049fdb0 RSI: ffff8800379baf38 RDI: 0000000000000000
RBP: ffff88007b569e18 R08: ffff88007c230da0 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff880077990d00 R14: 0000000000000084 R15: ffff88007db78a00
FS: 00007fc18ab61700(0000) GS:ffff88007fc60000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 000000007cf9d000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffff88007b569e38 ffff88007db78a00 ffff88007b569e38 ffffffffa049fded
ffffffff81abf0c0 ffff88007db78a00 ffff88007b569e58 ffffffff8145b60e
0000000000000000 0000000000000000 ffff88007b569eb8 ffffffff814df36e
Call Trace:
[<ffffffffa049fded>] sctp_destroy_sock+0x3d/0x80 [sctp]
[<ffffffff8145b60e>] sk_common_release+0x1e/0xf0
[<ffffffff814df36e>] inet_create+0x2ae/0x350
[<ffffffff81455a6f>] __sock_create+0x11f/0x240
[<ffffffff81455bf0>] sock_create+0x30/0x40
[<ffffffff8145696c>] SyS_socket+0x4c/0xc0
[<ffffffff815403be>] ? do_page_fault+0xe/0x10
[<ffffffff8153cb32>] ? page_fault+0x22/0x30
[<ffffffff81544e02>] system_call_fastpath+0x16/0x1b
Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
RIP [<ffffffffa0490c4e>] sctp_endpoint_free+0xe/0x40 [sctp]
RSP <ffff88007b569e08>
CR2: 0000000000000020
---[ end trace e0d71ec1108c1dd9 ]---
I did not hit this with the lksctp-tools functional tests, but with a
small, multi-threaded test program, that heavily allocates, binds,
listens and waits in accept on sctp sockets, and then randomly kills
some of them (no need for an actual client in this case to hit this).
Then, again, allocating, binding, etc, and then killing child processes.
This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
is set. The cause for that is actually very simple: in sctp_endpoint_init()
we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
our crypto transforms through crypto_alloc_hash(). In our scenario,
it then can happen that crypto_alloc_hash() fails with -EINTR from
crypto_larval_wait(), thus we bail out and release the socket via
sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
dereference as soon as we try to access members in the endpoint during
sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
if we have that case, we do not need to do any cleanup work and just
leave the destruction handler.
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Neil Horman <[email protected]>
Acked-by: Vlad Yasevich <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/sctp/socket.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3809,6 +3809,12 @@ SCTP_STATIC void sctp_destroy_sock(struc
/* Release our hold on the endpoint. */
ep = sctp_sk(sk)->ep;
+ /* This could happen during socket init, thus we bail out
+ * early, since the rest of the below is not setup either.
+ */
+ if (ep == NULL)
+ return;
+
sctp_endpoint_free(ep);
local_bh_disable();
percpu_counter_dec(&sctp_sockets_allocated);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Borkmann <[email protected]>
[ Upstream commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe ]
uaddr->sa_data is exactly of size 14, which is hard-coded here and
passed as a size argument to strncpy(). A device name can be of size
IFNAMSIZ (== 16), meaning we might leave the destination string
unterminated. Thus, use strlcpy() and also sizeof() while we're
at it. We need to memset the data area beforehand, since strlcpy
does not padd the remaining buffer with zeroes for user space, so
that we do not possibly leak anything.
Signed-off-by: Daniel Borkmann <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/packet/af_packet.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1767,12 +1767,11 @@ static int packet_getname_spkt(struct so
return -EOPNOTSUPP;
uaddr->sa_family = AF_PACKET;
+ memset(uaddr->sa_data, 0, sizeof(uaddr->sa_data));
rcu_read_lock();
dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex);
if (dev)
- strncpy(uaddr->sa_data, dev->name, 14);
- else
- memset(uaddr->sa_data, 0, 14);
+ strlcpy(uaddr->sa_data, dev->name, sizeof(uaddr->sa_data));
rcu_read_unlock();
*uaddr_len = sizeof(*uaddr);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]
commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
added some code duplication and bad error recovery, leading to potential
crash in ip6_cork_release() as kfree() could be called with garbage.
use kzalloc() to make sure this wont happen.
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Hideaki YOSHIFUJI <[email protected]>
Cc: Neal Cardwell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/ip6_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1248,7 +1248,7 @@ int ip6_append_data(struct sock *sk, int
if (WARN_ON(np->cork.opt))
return -EINVAL;
- np->cork.opt = kmalloc(opt->tot_len, sk->sk_allocation);
+ np->cork.opt = kzalloc(opt->tot_len, sk->sk_allocation);
if (unlikely(np->cork.opt == NULL))
return -ENOBUFS;
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]
Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
first item in the rcu protected list, in case the loop was restarted.
This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37
rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
ptr->field :
In some cases, gcc caches the value or ptr->field in a register.
Use a barrier() to disallow such caching, as documented in
Documentation/atomic_ops.txt line 114
Thanks a lot to Roman for providing analysis and numerous patches.
Diagnosed-by: Roman Gushchin <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Boris Zhmurov <[email protected]>
Signed-off-by: Roman Gushchin <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
include/linux/rculist_nulls.h | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -105,9 +105,14 @@ static inline void hlist_nulls_add_head_
* @head: the head for your list.
* @member: the name of the hlist_nulls_node within the struct.
*
+ * The barrier() is needed to make sure compiler doesn't cache first element [1],
+ * as this loop can be restarted [2]
+ * [1] Documentation/atomic_ops.txt around line 114
+ * [2] Documentation/RCU/rculist_nulls.txt around line 146
*/
#define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member) \
- for (pos = rcu_dereference_raw(hlist_nulls_first_rcu(head)); \
+ for (({barrier();}), \
+ pos = rcu_dereference_raw(hlist_nulls_first_rcu(head)); \
(!is_a_nulls(pos)) && \
({ tpos = hlist_nulls_entry(pos, typeof(*tpos), member); 1; }); \
pos = rcu_dereference_raw(hlist_nulls_next_rcu(pos)))
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <[email protected]>
[ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]
The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
does not properly validate new domain hash entries resulting in
potential problems when an administrator attempts to add an invalid
entry. One such problem, as reported by Vlad Halilov, is a kernel
BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
adding an IPv6 outbound mapping with a CIPSO configuration.
This patch corrects this problem by adding the necessary validation
code to netlbl_domhsh_add() via the newly created
netlbl_domhsh_validate() function.
Ideally this patch should also be pushed to the currently active
-stable trees.
Reported-by: Vlad Halilov <[email protected]>
Signed-off-by: Paul Moore <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/netlabel/netlabel_domainhash.c | 69 +++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -246,6 +246,71 @@ static void netlbl_domhsh_audit_add(stru
}
}
+/**
+ * netlbl_domhsh_validate - Validate a new domain mapping entry
+ * @entry: the entry to validate
+ *
+ * This function validates the new domain mapping entry to ensure that it is
+ * a valid entry. Returns zero on success, negative values on failure.
+ *
+ */
+static int netlbl_domhsh_validate(const struct netlbl_dom_map *entry)
+{
+ struct netlbl_af4list *iter4;
+ struct netlbl_domaddr4_map *map4;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ struct netlbl_af6list *iter6;
+ struct netlbl_domaddr6_map *map6;
+#endif /* IPv6 */
+
+ if (entry == NULL)
+ return -EINVAL;
+
+ switch (entry->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ if (entry->type_def.cipsov4 != NULL ||
+ entry->type_def.addrsel != NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_CIPSOV4:
+ if (entry->type_def.cipsov4 == NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_ADDRSELECT:
+ netlbl_af4list_foreach(iter4, &entry->type_def.addrsel->list4) {
+ map4 = netlbl_domhsh_addr4_entry(iter4);
+ switch (map4->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ if (map4->type_def.cipsov4 != NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_CIPSOV4:
+ if (map4->type_def.cipsov4 == NULL)
+ return -EINVAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ netlbl_af6list_foreach(iter6, &entry->type_def.addrsel->list6) {
+ map6 = netlbl_domhsh_addr6_entry(iter6);
+ switch (map6->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+#endif /* IPv6 */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/*
* Domain Hash Table Functions
*/
@@ -312,6 +377,10 @@ int netlbl_domhsh_add(struct netlbl_dom_
struct netlbl_af6list *tmp6;
#endif /* IPv6 */
+ ret_val = netlbl_domhsh_validate(entry);
+ if (ret_val != 0)
+ return ret_val;
+
/* XXX - we can remove this RCU read lock as the spinlock protects the
* entire function, but before we do we need to fixup the
* netlbl_af[4,6]list RCU functions to do "the right thing" with
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]
Daniel Petre reported crashes in icmp_dst_unreach() with following call
graph:
Daniel found a similar problem mentioned in
http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html
And indeed this is the root cause : skb->cb[] contains data fooling IP
stack.
We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
is called. Or else skb->cb[] might contain garbage from GSO segmentation
layer.
A similar fix was tested on linux-3.9, but gre code was refactored in
linux-3.10. I'll send patches for stable kernels as well.
Many thanks to Daniel for providing reports, patches and testing !
Reported-by: Daniel Petre <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ipip.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -716,6 +716,7 @@ static netdev_tx_t ipgre_tunnel_xmit(str
tiph = &tunnel->parms.iph;
}
+ memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
if ((dst = tiph->daddr) == 0) {
/* NBMA tunnel */
@@ -853,7 +854,6 @@ static netdev_tx_t ipgre_tunnel_xmit(str
skb_reset_transport_header(skb);
skb_push(skb, gre_hlen);
skb_reset_network_header(skb);
- memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED |
IPSKB_REROUTED);
skb_dst_drop(skb);
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -448,6 +448,7 @@ static netdev_tx_t ipip_tunnel_xmit(stru
if (tos & 1)
tos = old_iph->tos;
+ memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
if (!dst) {
/* NBMA tunnel */
if ((rt = skb_rtable(skb)) == NULL) {
@@ -531,7 +532,6 @@ static netdev_tx_t ipip_tunnel_xmit(stru
skb->transport_header = skb->network_header;
skb_push(skb, sizeof(struct iphdr));
skb_reset_network_header(skb);
- memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED |
IPSKB_REROUTED);
skb_dst_drop(skb);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]
commit 3853b5841c01a ("xps: Improvements in TX queue selection")
introduced ooo_okay flag, but the condition to set it is slightly wrong.
In our traces, we have seen ACK packets being received out of order,
and RST packets sent in response.
We should test if we have any packets still in host queue.
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Tom Herbert <[email protected]>
Cc: Yuchung Cheng <[email protected]>
Cc: Neal Cardwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp_output.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -833,11 +833,13 @@ static int tcp_transmit_skb(struct sock
&md5);
tcp_header_size = tcp_options_size + sizeof(struct tcphdr);
- if (tcp_packets_in_flight(tp) == 0) {
+ if (tcp_packets_in_flight(tp) == 0)
tcp_ca_event(sk, CA_EVENT_TX_START);
- skb->ooo_okay = 1;
- } else
- skb->ooo_okay = 0;
+
+ /* if no packet is in qdisc/device queue, then allow XPS to select
+ * another queue.
+ */
+ skb->ooo_okay = sk_wmem_alloc_get(sk) == 0;
skb_push(skb, tcp_header_size);
skb_reset_transport_header(skb);
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Yongjun <[email protected]>
[ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]
Add the missing iounmap() before return from gianfar_ptp_probe()
in the error handling case.
Signed-off-by: Wei Yongjun <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/gianfar_ptp.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/gianfar_ptp.c
+++ b/drivers/net/gianfar_ptp.c
@@ -521,6 +521,7 @@ static int gianfar_ptp_probe(struct plat
return 0;
no_clock:
+ iounmap(etsects->regs);
no_ioremap:
release_resource(etsects->rsrc);
no_resource:
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]
TCP md5 communications fail [1] for some devices, because sg/crypto code
assume page offsets are below PAGE_SIZE.
This was discovered using mlx4 driver [2], but I suspect loopback
might trigger the same bug now we use order-3 pages in tcp_sendmsg()
[1] Failure is giving following messages.
huh, entered softirq 3 NET_RX ffffffff806ad230 preempt_count 00000100,
exited with 00000101?
[2] mlx4 driver uses order-2 pages to allocate RX frags
Reported-by: Matt Schnall <[email protected]>
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Bernhard Beck <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/tcp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3043,7 +3043,11 @@ int tcp_md5_hash_skb_data(struct tcp_md5
for (i = 0; i < shi->nr_frags; ++i) {
const struct skb_frag_struct *f = &shi->frags[i];
- sg_set_page(&sg, f->page, f->size, f->page_offset);
+ unsigned int offset = f->page_offset;
+ struct page *page = f->page + (offset >> PAGE_SHIFT);
+
+ sg_set_page(&sg, page, f->size,
+ offset_in_page(offset));
if (crypto_hash_update(desc, &sg, f->size))
return 1;
}
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Metcalf <[email protected]>
commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.
gcc 4.7.x is emitting calls to __ffsdi2 where previously
it used to inline the appropriate ctz instructions.
While this needs to be fixed in gcc, it's also easy to avoid
having it cause build failures when building with those
compilers by exporting __ffsdi2 to modules.
Signed-off-by: Chris Metcalf <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/tile/lib/exports.c | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/tile/lib/exports.c
+++ b/arch/tile/lib/exports.c
@@ -89,4 +89,6 @@ uint64_t __ashrdi3(uint64_t, unsigned in
EXPORT_SYMBOL(__ashrdi3);
uint64_t __ashldi3(uint64_t, unsigned int);
EXPORT_SYMBOL(__ashldi3);
+int __ffsdi2(uint64_t);
+EXPORT_SYMBOL(__ffsdi2);
#endif
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Clemens Ladisch <[email protected]>
commit 342cda29343a6272c630f94ed56810a76740251b upstream.
When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function. However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.
To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.
Reported-by: Jeremy Rosen <[email protected]>
Tested-by: Jeremy Rosen <[email protected]>
Signed-off-by: Clemens Ladisch <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/usb/card.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -148,14 +148,32 @@ static int snd_usb_create_stream(struct
return -EINVAL;
}
+ alts = &iface->altsetting[0];
+ altsd = get_iface_desc(alts);
+
+ /*
+ * Android with both accessory and audio interfaces enabled gets the
+ * interface numbers wrong.
+ */
+ if ((chip->usb_id == USB_ID(0x18d1, 0x2d04) ||
+ chip->usb_id == USB_ID(0x18d1, 0x2d05)) &&
+ interface == 0 &&
+ altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
+ altsd->bInterfaceSubClass == USB_SUBCLASS_VENDOR_SPEC) {
+ interface = 2;
+ iface = usb_ifnum_to_if(dev, interface);
+ if (!iface)
+ return -EINVAL;
+ alts = &iface->altsetting[0];
+ altsd = get_iface_desc(alts);
+ }
+
if (usb_interface_claimed(iface)) {
snd_printdd(KERN_INFO "%d:%d:%d: skipping, already claimed\n",
dev->devnum, ctrlif, interface);
return -EINVAL;
}
- alts = &iface->altsetting[0];
- altsd = get_iface_desc(alts);
if ((altsd->bInterfaceClass == USB_CLASS_AUDIO ||
altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC) &&
altsd->bInterfaceSubClass == USB_SUBCLASS_MIDISTREAMING) {
On Tue, Jun 25, 2013 at 11:39:15AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.0.84 release.
> There are 17 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jun 27 18:35:59 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.84-rc1.gz
> and the diffstat can be found below.
>
Build results are as follows. I did not check every failure, but as far as I
recall there are no new failures.
Guenter
--
Build reference: v3.0.83-17-g45bec3c
Build x86_64:defconfig passed
Build x86_64:allyesconfig passed
Build x86_64:allmodconfig passed
Build x86_64:allnoconfig passed
Build x86_64:alldefconfig passed
Build i386:defconfig passed
Build i386:allyesconfig passed
Build i386:allmodconfig passed
Build i386:allnoconfig passed
Build i386:alldefconfig passed
Build mips:defconfig passed
Build mips:bcm47xx_defconfig passed
Build mips:bcm63xx_defconfig passed
Build mips:ar7_defconfig passed
Build mips:fuloong2e_defconfig passed
Build mips:e55_defconfig passed
Build mips:powertv_defconfig passed
Build mips:malta_defconfig passed
Build powerpc:defconfig failed
Build powerpc:allyesconfig failed
Build powerpc:allmodconfig failed
Build powerpc:maple_defconfig failed
Build powerpc:ppc6xx_defconfig passed
Build powerpc:mpc83xx_defconfig passed
Build powerpc:mpc85xx_defconfig passed
Build powerpc:mpc85xx_smp_defconfig passed
Build powerpc:tqm8xx_defconfig passed
Build powerpc:85xx/sbc8548_defconfig passed
Build powerpc:83xx/mpc834x_mds_defconfig passed
Build powerpc:86xx/sbc8641d_defconfig passed
Build arm:defconfig passed
Build arm:allyesconfig failed
Build arm:allmodconfig failed
Build arm:exynos4_defconfig passed
Build arm:kirkwood_defconfig passed
Build arm:omap2plus_defconfig passed
Build arm:tegra_defconfig passed
Build arm:u8500_defconfig failed
Build arm:ap4evb_defconfig passed
Build arm:pxa910_defconfig passed
Build m68k:defconfig passed
Build m68k:apollo_defconfig passed
Build m68k:m5272c3_defconfig failed
Build m68k:m5307c3_defconfig failed
Build m68k:m5249evb_defconfig failed
Build m68k:m5407c3_defconfig failed
Build m68k:mac_defconfig passed
Build m68k:multi_defconfig passed
Build m68k:sun3_defconfig passed
Build m68k:sun3x_defconfig passed
Build m68k:mvme16x_defconfig passed
Build m68k:hp300_defconfig passed
Build sparc:defconfig passed
Build sparc:sparc64_defconfig passed
Build xtensa:defconfig failed
Build xtensa:iss_defconfig failed
Build microblaze:mmu_defconfig failed
Build microblaze:nommu_defconfig failed
Build blackfin:defconfig failed
Build parisc:defconfig failed
-----------------------
Total builds: 60 Total build errors: 17
Hi Günther,
On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
> Build m68k:defconfig passed
> Build m68k:apollo_defconfig passed
> Build m68k:m5272c3_defconfig failed
> Build m68k:m5307c3_defconfig failed
> Build m68k:m5249evb_defconfig failed
> Build m68k:m5407c3_defconfig failed
> Build m68k:mac_defconfig passed
> Build m68k:multi_defconfig passed
> Build m68k:sun3_defconfig passed
> Build m68k:sun3x_defconfig passed
> Build m68k:mvme16x_defconfig passed
> Build m68k:hp300_defconfig passed
m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
one of them.
Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
only marginally. Of course, if you have too many spare cycles ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
> Hi G?nther,
>
> On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
> > Build m68k:defconfig passed
> > Build m68k:apollo_defconfig passed
> > Build m68k:m5272c3_defconfig failed
> > Build m68k:m5307c3_defconfig failed
> > Build m68k:m5249evb_defconfig failed
> > Build m68k:m5407c3_defconfig failed
> > Build m68k:mac_defconfig passed
> > Build m68k:multi_defconfig passed
> > Build m68k:sun3_defconfig passed
> > Build m68k:sun3x_defconfig passed
> > Build m68k:mvme16x_defconfig passed
> > Build m68k:hp300_defconfig passed
>
> m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
> one of them.
>
> Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
> defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
> Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
> mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
> only marginally. Of course, if you have too many spare cycles ;-)
>
Thanks, I'll do that. The complete build for three releases takes 15+ hours
with i7-3700k, so reducing that a bit doesn't hurt.
Would there be any useful builds to add ?
Thanks,
Guenter
In a message of Tue, 25 Jun 2013 11:39:32 -0700, Greg Kroah-Hartman writes:
>3.0-stable review patch. If anyone has any objections, please let me know.
>
>From: Anders Hammarquist <[email protected]>
>
>commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
>
>Add product id for Abbott strip port cable for Precision meter which
>uses the TI 3410 chip.
Given the statically sized arrays, I think this patch should not go in
alone. It needs to go together with the later patches I sent you that
fix the array sizing.
(this applies to all trees)
/Anders
On Tue, Jun 25, 2013 at 12:23:00PM -0700, Guenter Roeck wrote:
> On Tue, Jun 25, 2013 at 11:39:15AM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.0.84 release.
> > There are 17 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu Jun 27 18:35:59 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.84-rc1.gz
> > and the diffstat can be found below.
> >
> Build results are as follows. I did not check every failure, but as far as I
> recall there are no new failures.
Thanks for testing and letting us know.
greg k-h
On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <[email protected]> wrote:
> On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
>> Hi Günther,
>>
>> On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
>> > Build m68k:defconfig passed
>> > Build m68k:apollo_defconfig passed
>> > Build m68k:m5272c3_defconfig failed
>> > Build m68k:m5307c3_defconfig failed
>> > Build m68k:m5249evb_defconfig failed
>> > Build m68k:m5407c3_defconfig failed
>> > Build m68k:mac_defconfig passed
>> > Build m68k:multi_defconfig passed
>> > Build m68k:sun3_defconfig passed
>> > Build m68k:sun3x_defconfig passed
>> > Build m68k:mvme16x_defconfig passed
>> > Build m68k:hp300_defconfig passed
>>
>> m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
>> one of them.
>>
>> Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
>> defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
>> Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
>> mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
>> only marginally. Of course, if you have too many spare cycles ;-)
>>
> Thanks, I'll do that. The complete build for three releases takes 15+ hours
> with i7-3700k, so reducing that a bit doesn't hurt.
FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
> Would there be any useful builds to add ?
You could add m68k:m5475evb_defconfig, which is the only Coldfire
defconfig with MMU=y.
Greg: Any other advice for Coldfire?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Jun 26, 2013 at 09:34:42AM +0200, Geert Uytterhoeven wrote:
> On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <[email protected]> wrote:
> > On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
> >> Hi G?nther,
> >>
> >> On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
> >> > Build m68k:defconfig passed
> >> > Build m68k:apollo_defconfig passed
> >> > Build m68k:m5272c3_defconfig failed
> >> > Build m68k:m5307c3_defconfig failed
> >> > Build m68k:m5249evb_defconfig failed
> >> > Build m68k:m5407c3_defconfig failed
> >> > Build m68k:mac_defconfig passed
> >> > Build m68k:multi_defconfig passed
> >> > Build m68k:sun3_defconfig passed
> >> > Build m68k:sun3x_defconfig passed
> >> > Build m68k:mvme16x_defconfig passed
> >> > Build m68k:hp300_defconfig passed
> >>
> >> m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
> >> one of them.
> >>
> >> Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
> >> defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
> >> Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
> >> mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
> >> only marginally. Of course, if you have too many spare cycles ;-)
> >>
> > Thanks, I'll do that. The complete build for three releases takes 15+ hours
> > with i7-3700k, so reducing that a bit doesn't hurt.
>
> FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
>
Thanks for the note. Must have mmissed it.
> > Would there be any useful builds to add ?
>
> You could add m68k:m5475evb_defconfig, which is the only Coldfire
> defconfig with MMU=y.
>
Done, thanks!
Guenter
On 06/25/2013 04:00 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.0.84 release.
> There are 17 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Jun 27 18:35:59 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.84-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Patches applied cleanly to 3.0.83, 3.4.50, and 3.9.7
Compiled and booted on the following systems:
Samsung Series 9 900X4C Intel Corei5:
(3.4.51-rc1, and 3.9.8-rc1)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics:
(3.0.84-rc1, 3.4.51-rc1, and 3.9.8-rc1)
dmesgs for all releases look good. No regressions compared to the previous
dmesgs for each of these releases.
Cross-compile testing:
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2:
(3.0.84-rc1, 3.4.51-rc1, and 3.9.8-rc1)
Cross-compile tests results:
alpha: defconfig passed on 3.0.y and 3.9.y
arm: defconfig passed on 3.0.y and 3.9.y
arm64: not applicable to 3.0.y, 3.4.y. defconfig passed on 3.9.y
c6x: not applicable to 3.0.y, defconfig passed 3.9.y
mips: defconfig passed on 3.0.y and 3.9.y
mipsel: defconfig passed on 3.0.y and 3.9.y
powerpc: wii_defconfig passed on all
sh: defconfig passed on all
sparc: defconfig passed on all
tile: tilegx_defconfig passed on all
3.4.51-rc1 build failures:
alpha: (both defconfig and allmodconfig)
CC [M] drivers/infiniband/core/addr.o
In file included from include/linux/if_vlan.h:18:0,
from include/rdma/ib_addr.h:42,
from drivers/infiniband/core/addr.c:47:
include/linux/etherdevice.h: In function ?ether_addr_equal_64bits?:
include/linux/etherdevice.h:308:9: error: implicit declaration of
function ?ether_addr_equal? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/infiniband/core/addr.o] Error 1
make[2]: *** [drivers/infiniband/core] Error 2
make[1]: *** [drivers/infiniband] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
arm: (defconfig)
CC drivers/net/Space.o
In file included from drivers/net/Space.c:31:0:
include/linux/etherdevice.h: In function ?ether_addr_equal_64bits?:
include/linux/etherdevice.h:308:9: error: implicit declaration of
function ?ether_addr_equal? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/net/Space.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
mips and mipsel:
CC drivers/net/Space.o
In file included from drivers/net/Space.c:31:0:
include/linux/etherdevice.h: In function ?ether_addr_equal_64bits?:
include/linux/etherdevice.h:308:9: error: implicit declaration of
function ?ether_addr_equal? [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/net/Space.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
-- Shuah
Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research
America (Silicon Valley) [email protected] | (970) 672-0658
On Tue, Jun 25, 2013 at 11:39:26PM +0200, Anders Hammarquist wrote:
> In a message of Tue, 25 Jun 2013 11:39:32 -0700, Greg Kroah-Hartman writes:
> >3.0-stable review patch. If anyone has any objections, please let me know.
> >
> >From: Anders Hammarquist <[email protected]>
> >
> >commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
> >
> >Add product id for Abbott strip port cable for Precision meter which
> >uses the TI 3410 chip.
>
> Given the statically sized arrays, I think this patch should not go in
> alone. It needs to go together with the later patches I sent you that
> fix the array sizing.
>
> (this applies to all trees)
Yes, but, thanks to the fact that you are only adding one more device
id, I don't think we are overflowing anything with this patch alone,
right? The only "bad" thing that could happen here is if a user
specifies a device/vendor id on the module command line, is it would
replace the device id you added, so all should be fine.
Or am I reading the code wrong?
thanks,
greg k-h
On 26/06/13 17:34, Geert Uytterhoeven wrote:
> On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <[email protected]> wrote:
>> On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
>>> Hi Günther,
>>>
>>> On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
>>>> Build m68k:defconfig passed
>>>> Build m68k:apollo_defconfig passed
>>>> Build m68k:m5272c3_defconfig failed
>>>> Build m68k:m5307c3_defconfig failed
>>>> Build m68k:m5249evb_defconfig failed
>>>> Build m68k:m5407c3_defconfig failed
>>>> Build m68k:mac_defconfig passed
>>>> Build m68k:multi_defconfig passed
>>>> Build m68k:sun3_defconfig passed
>>>> Build m68k:sun3x_defconfig passed
>>>> Build m68k:mvme16x_defconfig passed
>>>> Build m68k:hp300_defconfig passed
>>>
>>> m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
>>> one of them.
>>>
>>> Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
>>> defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
>>> Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
>>> mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
>>> only marginally. Of course, if you have too many spare cycles ;-)
>>>
>> Thanks, I'll do that. The complete build for three releases takes 15+ hours
>> with i7-3700k, so reducing that a bit doesn't hurt.
>
> FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
>
>> Would there be any useful builds to add ?
>
> You could add m68k:m5475evb_defconfig, which is the only Coldfire
> defconfig with MMU=y.
>
> Greg: Any other advice for Coldfire?
I might have some, except I am not sure what we are talking about.
I don't have enough context from the above alone :-)
I take it this is test building 3.0.84?
I haven't built a 3.0.x for a while, so not sure why the above
ColdFire targets are failing without going and trying it out.
Regards
Greg
On Thu, Jun 27, 2013 at 09:06:11AM +1000, Greg Ungerer wrote:
> On 26/06/13 17:34, Geert Uytterhoeven wrote:
> >On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <[email protected]> wrote:
> >>On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
> >>>Hi Günther,
> >>>
> >>>On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
> >>>>Build m68k:defconfig passed
> >>>>Build m68k:apollo_defconfig passed
> >>>>Build m68k:m5272c3_defconfig failed
> >>>>Build m68k:m5307c3_defconfig failed
> >>>>Build m68k:m5249evb_defconfig failed
> >>>>Build m68k:m5407c3_defconfig failed
> >>>>Build m68k:mac_defconfig passed
> >>>>Build m68k:multi_defconfig passed
> >>>>Build m68k:sun3_defconfig passed
> >>>>Build m68k:sun3x_defconfig passed
> >>>>Build m68k:mvme16x_defconfig passed
> >>>>Build m68k:hp300_defconfig passed
> >>>
> >>>m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
> >>>one of them.
> >>>
> >>>Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
> >>>defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
> >>>Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
> >>>mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
> >>>only marginally. Of course, if you have too many spare cycles ;-)
> >>>
> >>Thanks, I'll do that. The complete build for three releases takes 15+ hours
> >>with i7-3700k, so reducing that a bit doesn't hurt.
> >
> >FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
> >
> >>Would there be any useful builds to add ?
> >
> >You could add m68k:m5475evb_defconfig, which is the only Coldfire
> >defconfig with MMU=y.
> >
> >Greg: Any other advice for Coldfire?
>
> I might have some, except I am not sure what we are talking about.
> I don't have enough context from the above alone :-)
>
Just trying to figure out an optimal set of targets for test builds.
> I take it this is test building 3.0.84?
Yes
> I haven't built a 3.0.x for a while, so not sure why the above
> ColdFire targets are failing without going and trying it out.
>
Lots of assembler error messages, plus complaints about redefinitions and
implicit declarations.
arch/m68k/platform/coldfire/entry.S: Assembler messages:
arch/m68k/platform/coldfire/entry.S:64: Error: Unknown operator -- statement `save_all' ignored
arch/m68k/platform/coldfire/entry.S:91: Error: operands mismatch -- statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
arch/m68k/platform/coldfire/entry.S:143: Error: Unknown operator -- statement `restore_user' ignored
arch/m68k/platform/coldfire/entry.S:192: Error: Unknown operator -- statement `rdusp' ignored
arch/m68k/platform/coldfire/entry.S:201: Error: Unknown operator -- statement `wrusp' ignored
In file included from arch/m68k/mm/init.c:4:0:
arch/m68k/mm/init_no.c:45:15: error: conflicting types for ‘empty_zero_page’
/home/groeck/src/linux-stable/arch/m68k/include/asm/pgtable_mm.h:92:14: note: previous declaration of ‘empty_zero_page’ was here
arch/m68k/kernel/setup_no.c: In function 'setup_arch':
arch/m68k/kernel/setup_no.c:264:2: error: implicit declaration of function 'paging_init' [-Werror=implicit-function-declaration]
/tmp/ccjVitY8.s:120: Error: invalid instruction for this architecture; needs 68010 or higher (68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `moves.l %d1,(%a2)' ignored
and so on. Not that it tells me anything. I'd guess I have the wrong compiler, but it does
build for 3.9, so maybe not. If you have an insight, please let me know.
gcc version is 4.6.3 from kernel.org:
Using built-in specs.
COLLECT_GCC=/opt/kernel/gcc-4.6.3-nolibc/m68k-linux/bin/m68k-linux-gcc
COLLECT_LTO_WRAPPER=/opt/kernel/gcc-4.6.3-nolibc/m68k-linux/bin/../libexec/gcc/m68k-linux/4.6.3/lto-wrapper
Target: m68k-linux
Configured with: /home/tony/buildall/src/gcc/configure --target=m68k-linux
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-targets=all
--prefix=/opt/cross/gcc-4.6.3-nolibc/m68k-linux/ --enable-languages=c
--with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--enable-checking=release --with-mpfr=/home/tony/buildall/src/sys-x86_64
--with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap
--disable-libquadmath
Thread model: single
gcc version 4.6.3 (GCC)
Guenter
In a message of Wed, 26 Jun 2013 10:21:22 -0700, Greg Kroah-Hartman writes:
>On Tue, Jun 25, 2013 at 11:39:26PM +0200, Anders Hammarquist wrote:
>> In a message of Tue, 25 Jun 2013 11:39:32 -0700, Greg Kroah-Hartman writes:
>> >3.0-stable review patch. If anyone has any objections, please let me know.
>> >
>> >From: Anders Hammarquist <[email protected]>
>> >
>> >commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
>> >
>> >Add product id for Abbott strip port cable for Precision meter which
>> >uses the TI 3410 chip.
>>
>> Given the statically sized arrays, I think this patch should not go in
>> alone. It needs to go together with the later patches I sent you that
>> fix the array sizing.
>>
>> (this applies to all trees)
>
>Yes, but, thanks to the fact that you are only adding one more device
>id, I don't think we are overflowing anything with this patch alone,
>right? The only "bad" thing that could happen here is if a user
>specifies a device/vendor id on the module command line, is it would
>replace the device id you added, so all should be fine.
>
>Or am I reading the code wrong?
I'm reading the code the same way you are. From what I can see there
is no place that counts on there enough space beyond the last entry,
so nothing truly bad should happen.
/Anders
Hi Guenter,
Sorry, I am way behind on this...
On 27/06/13 09:29, Guenter Roeck wrote:
> On Thu, Jun 27, 2013 at 09:06:11AM +1000, Greg Ungerer wrote:
>> On 26/06/13 17:34, Geert Uytterhoeven wrote:
>>> On Tue, Jun 25, 2013 at 9:39 PM, Guenter Roeck <[email protected]> wrote:
>>>> On Tue, Jun 25, 2013 at 09:32:26PM +0200, Geert Uytterhoeven wrote:
>>>>> Hi Günther,
>>>>>
>>>>> On Tue, Jun 25, 2013 at 9:23 PM, Guenter Roeck <[email protected]> wrote:
>>>>>> Build m68k:defconfig passed
>>>>>> Build m68k:apollo_defconfig passed
>>>>>> Build m68k:m5272c3_defconfig failed
>>>>>> Build m68k:m5307c3_defconfig failed
>>>>>> Build m68k:m5249evb_defconfig failed
>>>>>> Build m68k:m5407c3_defconfig failed
>>>>>> Build m68k:mac_defconfig passed
>>>>>> Build m68k:multi_defconfig passed
>>>>>> Build m68k:sun3_defconfig passed
>>>>>> Build m68k:sun3x_defconfig passed
>>>>>> Build m68k:mvme16x_defconfig passed
>>>>>> Build m68k:hp300_defconfig passed
>>>>>
>>>>> m68k:defconfig is an alias for m68k:multi_defconfig, so you can drop
>>>>> one of them.
>>>>>
>>>>> Furthermore, m68k:multi_defconfig is the union of all m68k "classic MMU"
>>>>> defconfigs, except for sun3_defconfig (due to the incompatible MMU type).
>>>>> Hence dropping apollo_defconfig, mac_defconfig, sun3x_defconfig,
>>>>> mvme16x_defconfig, and hp300_defconfig would reduce your build coverage
>>>>> only marginally. Of course, if you have too many spare cycles ;-)
>>>>>
>>>> Thanks, I'll do that. The complete build for three releases takes 15+ hours
>>>> with i7-3700k, so reducing that a bit doesn't hurt.
>>>
>>> FYI, you still built m68k:mvme16x_defconfig for v3.9.7-95-g6a2f14b.
>>>
>>>> Would there be any useful builds to add ?
>>>
>>> You could add m68k:m5475evb_defconfig, which is the only Coldfire
>>> defconfig with MMU=y.
>>>
>>> Greg: Any other advice for Coldfire?
>>
>> I might have some, except I am not sure what we are talking about.
>> I don't have enough context from the above alone :-)
>>
> Just trying to figure out an optimal set of targets for test builds.
>
>> I take it this is test building 3.0.84?
>
> Yes
>
>> I haven't built a 3.0.x for a while, so not sure why the above
>> ColdFire targets are failing without going and trying it out.
>>
> Lots of assembler error messages, plus complaints about redefinitions and
> implicit declarations.
>
> arch/m68k/platform/coldfire/entry.S: Assembler messages:
> arch/m68k/platform/coldfire/entry.S:64: Error: Unknown operator -- statement `save_all' ignored
> arch/m68k/platform/coldfire/entry.S:91: Error: operands mismatch -- statement `moveml %a3-%a6/%d6-%d7,%sp@-' ignored
> arch/m68k/platform/coldfire/entry.S:143: Error: Unknown operator -- statement `restore_user' ignored
> arch/m68k/platform/coldfire/entry.S:192: Error: Unknown operator -- statement `rdusp' ignored
> arch/m68k/platform/coldfire/entry.S:201: Error: Unknown operator -- statement `wrusp' ignored
> In file included from arch/m68k/mm/init.c:4:0:
> arch/m68k/mm/init_no.c:45:15: error: conflicting types for ‘empty_zero_page’
> /home/groeck/src/linux-stable/arch/m68k/include/asm/pgtable_mm.h:92:14: note: previous declaration of ‘empty_zero_page’ was here
> arch/m68k/kernel/setup_no.c: In function 'setup_arch':
> arch/m68k/kernel/setup_no.c:264:2: error: implicit declaration of function 'paging_init' [-Werror=implicit-function-declaration]
> /tmp/ccjVitY8.s:120: Error: invalid instruction for this architecture; needs 68010 or higher (68010, 68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060], cpu32 [68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349, 68360], fidoa [fido]) -- statement `moves.l %d1,(%a2)' ignored
>
> and so on. Not that it tells me anything. I'd guess I have the wrong compiler, but it does
> build for 3.9, so maybe not. If you have an insight, please let me know.
Yes, this is the wrong compiler. You needed to use a m68k-uclinux
targeted toolchain for 3.0 and older kernels. There are changes to
the m68k arch Makefile and linker scripts on newer kernels that mean
you can now use an m68k-linux- toolchain (that is why 3.9 compiles
cleanly).
Its reasonably easy to fix this on 3.0.x kernels if you want this.
The below patch does it. I don't have any firm opinion on whether
you want to apply this to the stable 3.0.x tree. Anyone using 3.0.x
on m68knommu has always had to use a m68k-uclinux- toolchain up to
now.
Regards
Greg
m68k: allow m68knommu targets to build with an m68k-linux toolchain
Non-mmu m68k arch targets fail to compile with a traditional m68k-linux
toolchain. Some code relies on __uClinux__ being implicitly defined.
We can just define it in our arch Makefile to satisfy this. We will
also need to add the notes section to the linker script to get a
successful build.
Singed-off-by: Greg Ungerer <[email protected]>
--- linux-3.0.88/arch/m68k/Makefile_no.org 2013-08-01 23:47:39.953081304
+1000
+++ linux-3.0.88/arch/m68k/Makefile_no 2013-08-01 23:50:37.453077257 +1000
@@ -107,9 +107,11 @@
cflags-$(CONFIG_M68360) := -m68332
KBUILD_AFLAGS += $(cflags-y)
+KBUILD_AFLAGS += -D__uClinux__
KBUILD_CFLAGS += $(cflags-y)
KBUILD_CFLAGS += -D__linux__
+KBUILD_CFLAGS += -D__uClinux__
KBUILD_CFLAGS += -DUTS_SYSNAME=\"uClinux\"
head-y := arch/m68k/platform/$(cpuclass-y)/head.o
--- linux-3.0.88/arch/m68k/kernel/vmlinux.lds_no.S.org 2013-08-01
23:58:49.913160401 +1000
+++ linux-3.0.88/arch/m68k/kernel/vmlinux.lds_no.S 2013-08-02
00:00:34.373904823 +1000
@@ -75,6 +75,10 @@
*(__ex_table)
__stop___ex_table = .;
+ __start_notes = .;
+ *(.note.*)
+ __stop_notes = .;
+
*(.rodata) *(.rodata.*)
*(__vermagic) /* Kernel version magic */
*(__markers_strings)
On 08/01/2013 07:35 AM, Greg Ungerer wrote:
> Hi Guenter,
>
> Sorry, I am way behind on this...
>
No problem. Happens to me too.
>> and so on. Not that it tells me anything. I'd guess I have the wrong compiler, but it does
>> build for 3.9, so maybe not. If you have an insight, please let me know.
>
> Yes, this is the wrong compiler. You needed to use a m68k-uclinux
> targeted toolchain for 3.0 and older kernels. There are changes to
> the m68k arch Makefile and linker scripts on newer kernels that mean
> you can now use an m68k-linux- toolchain (that is why 3.9 compiles
> cleanly).
>
> Its reasonably easy to fix this on 3.0.x kernels if you want this.
> The below patch does it. I don't have any firm opinion on whether
> you want to apply this to the stable 3.0.x tree. Anyone using 3.0.x
> on m68knommu has always had to use a m68k-uclinux- toolchain up to
> now.
>
I don't think so. Of course, it would simplify my life, but then it appears
everyone using any of those kernels already knows what to do. So all the patch
really does is to make my life easier, at the cost of adding risk for everyone else.
That does not seem to be worth the trouble.
I'll see if I can update my scripts to use the correct compiler for 3.0 instead.
Thanks,
Guenter