* Re: linux-next: Tree for Jan 30
From: Stephen Rothwell @ 2017-01-30 6:49 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
In-Reply-To: <20170130174901.6c7e88bd@canb.auug.org.au>
Hi all,
On Mon, 30 Jan 2017 17:49:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> There will be no linux-next release until Monday (next-20170130).
Obviously, this is not longer relevant :-)
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Christoph Hellwig @ 2017-01-30 6:34 UTC (permalink / raw)
To: Jens Axboe; +Cc: Stephen Rothwell, linux-next, linux-kernel, Christoph Hellwig
In-Reply-To: <5f2da80f-c6fe-8c45-0e56-819aae7d925c@kernel.dk>
On Sun, Jan 29, 2017 at 06:53:42PM -0700, Jens Axboe wrote:
> Huh, I wonder how that snuck past my allmodconfig builds, that looks
> like a clear failure.
I also did tons of test builds and never saw it, not sure why
the NVMe-SCSI code still someone how an implicit include of scsi_cmnd.h.
But in the end it should not be using the defintion anyway, and I sent
a patch on Saturday so that it doesn't:
[PATCH 1/5] nvme/scsi: don't rely on BLK_MAX_CDB
might make sense to expedite that.
^ permalink raw reply
* linux-next: manual merge of the gpio tree with the staging tree
From: Stephen Rothwell @ 2017-01-30 4:28 UTC (permalink / raw)
To: Linus Walleij, Greg KH
Cc: linux-next, linux-kernel, Roman Sommer, Mika Westerberg
Hi Linus,
Today's linux-next merge of the gpio tree got a conflict in:
drivers/staging/greybus/gpio.c
between commit:
1d3dfbd1dd34 ("staging: greybus: fix checkpatch unsigned warnings")
from the staging tree and commit:
2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
from the gpio tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/staging/greybus/gpio.c
index 558550cfe687,51384bdde450..000000000000
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@@ -474,17 -474,20 +474,20 @@@ static void gb_gpio_set(struct gpio_chi
gb_gpio_set_value_operation(ggc, (u8)offset, !!value);
}
- static int gb_gpio_set_debounce(struct gpio_chip *chip, unsigned int offset,
- unsigned int debounce)
-static int gb_gpio_set_config(struct gpio_chip *chip, unsigned offset,
++static int gb_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
{
struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
- u16 usec;
+ u32 debounce;
+ if (pinconf_to_config_param(config) != PIN_CONFIG_INPUT_DEBOUNCE)
+ return -ENOTSUPP;
+
+ debounce = pinconf_to_config_argument(config);
if (debounce > U16_MAX)
return -EINVAL;
- usec = (u16)debounce;
- return gb_gpio_set_debounce_operation(ggc, (u8)offset, usec);
+ return gb_gpio_set_debounce_operation(ggc, (u8)offset, (u16)debounce);
}
static int gb_gpio_controller_setup(struct gb_gpio_controller *ggc)
^ permalink raw reply
* Re: linux-next: manual merge of the rcu tree with the powerpc-fixes tree
From: Michael Ellerman @ 2017-01-30 4:00 UTC (permalink / raw)
To: Stephen Rothwell, Paul E. McKenney, Benjamin Herrenschmidt,
PowerPC
Cc: linux-next, linux-kernel
In-Reply-To: <20170130134645.5464272d@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Paul,
>
> Today's linux-next merge of the rcu tree got a conflict in:
>
> arch/powerpc/Kconfig
>
> between commit:
>
> f2574030b0e3 ("powerpc: Revert the initial stack protector support")
>
> from the powerpc-fixes tree and commit:
>
> c7327406b3c3 ("rcu: Make arch select smp_mb__after_unlock_lock() strength")
>
> from the rcu tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks.
One of these years I'm totally going to sort the selects under config
PPC :/
cheers
^ permalink raw reply
* linux-next: manual merge of the staging tree with the staging.current tree
From: Stephen Rothwell @ 2017-01-30 3:59 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Rui Miguel Silva
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
drivers/staging/greybus/timesync_platform.c
between commit:
b17c1bba9cec ("staging: greybus: timesync: validate platform state callback")
from the staging.current tree and commit:
bdfb95c4baab ("staging: greybus: remove timesync protocol support")
from the staging tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Jens Axboe @ 2017-01-30 3:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig
In-Reply-To: <5f2da80f-c6fe-8c45-0e56-819aae7d925c@kernel.dk>
On 01/29/2017 06:53 PM, Jens Axboe wrote:
> On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
>> drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
>> u8 cmd[BLK_MAX_CDB];
>> ^
>> drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
>> u8 cmd[BLK_MAX_CDB];
>> ^
>> drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
>> drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)
>> if (hdr.cmd_len > BLK_MAX_CDB)
>> ^
>>
>> Caused by commit
>>
>> 82ed4db499b8 ("block: split scsi_request out of struct request")
>>
>> I have used the block tree from next-20170125 for today.
>
> Huh, I wonder how that snuck past my allmodconfig builds, that looks
> like a clear failure.
Fixed, sorry about that.
--
Jens Axboe
^ permalink raw reply
* linux-next: manual merge of the rcu tree with the powerpc-fixes tree
From: Stephen Rothwell @ 2017-01-30 2:46 UTC (permalink / raw)
To: Paul E. McKenney, Michael Ellerman, Benjamin Herrenschmidt,
PowerPC
Cc: linux-next, linux-kernel
Hi Paul,
Today's linux-next merge of the rcu tree got a conflict in:
arch/powerpc/Kconfig
between commit:
f2574030b0e3 ("powerpc: Revert the initial stack protector support")
from the powerpc-fixes tree and commit:
c7327406b3c3 ("rcu: Make arch select smp_mb__after_unlock_lock() strength")
from the rcu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/Kconfig
index a0fe262408a5,9fecd004fee8..000000000000
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@@ -164,9 -164,11 +164,10 @@@ config PP
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE
select HAVE_ARCH_HARDENED_USERCOPY
select HAVE_KERNEL_GZIP
- select HAVE_CC_STACKPROTECTOR
+ select ARCH_WEAK_RELEASE_ACQUIRE
config GENERIC_CSUM
- def_bool CPU_LITTLE_ENDIAN
+ def_bool n
config EARLY_PRINTK
bool
^ permalink raw reply
* linux-next: manual merge of the tip tree with the drm-misc-fixes tree
From: Stephen Rothwell @ 2017-01-30 2:22 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Daniel Vetter, Intel Graphics, DRI
Cc: linux-next, Michel Dänzer, linux-kernel,
Christian König
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/gpu/drm/ttm/ttm_bo.c
between commit:
7c6d639d465e ("drm/ttm: Make sure BOs being swapped out are cacheable")
from the drm-misc-fixes tree and commit:
bdfafc4ffdd2 ("locking/atomic, kref: Kill kref_sub()")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/ttm/ttm_bo.c
index 86e3b233b722,ffc6cb55c78c..000000000000
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@@ -1669,7 -1645,7 +1645,6 @@@ static int ttm_bo_swapout(struct ttm_me
container_of(shrink, struct ttm_bo_global, shrink);
struct ttm_buffer_object *bo;
int ret = -EBUSY;
- int put_count;
- uint32_t swap_placement = (TTM_PL_FLAG_CACHED | TTM_PL_FLAG_SYSTEM);
spin_lock(&glob->lru_lock);
list_for_each_entry(bo, &glob->swap_lru, swap) {
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: build failure after merge of the block tree
From: Jens Axboe @ 2017-01-30 1:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Christoph Hellwig
In-Reply-To: <20170130124350.36a57549@canb.auug.org.au>
On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
> drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
> u8 cmd[BLK_MAX_CDB];
> ^
> drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
> drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
> u8 cmd[BLK_MAX_CDB];
> ^
> drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
> drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)
> if (hdr.cmd_len > BLK_MAX_CDB)
> ^
>
> Caused by commit
>
> 82ed4db499b8 ("block: split scsi_request out of struct request")
>
> I have used the block tree from next-20170125 for today.
Huh, I wonder how that snuck past my allmodconfig builds, that looks
like a clear failure.
--
Jens Axboe
^ permalink raw reply
* linux-next: build failure after merge of the block tree
From: Stephen Rothwell @ 2017-01-30 1:43 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Christoph Hellwig
Hi Jens,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (first use in this function)
u8 cmd[BLK_MAX_CDB];
^
drivers/nvme/host/scsi.c:2350:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/nvme/host/scsi.c:2350:5: warning: unused variable 'cmd' [-Wunused-variable]
u8 cmd[BLK_MAX_CDB];
^
drivers/nvme/host/scsi.c: In function 'nvme_sg_io':
drivers/nvme/host/scsi.c:2454:20: error: 'BLK_MAX_CDB' undeclared (first use in this function)
if (hdr.cmd_len > BLK_MAX_CDB)
^
Caused by commit
82ed4db499b8 ("block: split scsi_request out of struct request")
I have used the block tree from next-20170125 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h
From: Gideon D'souza @ 2017-01-27 17:18 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Andrew Morton, LKML, Greg Ungerer, Geert Uytterhoeven, linux-m68k,
linux-next@vger.kernel.org
In-Reply-To: <CAP=VYLobUppjdMpeoQ7gXn60zmbEZU6d5Ga1mccCPbbpw9n1yA@mail.gmail.com>
>You've gone from printf to print here. This commit is breaking the
>linux-next builds on m68k. I see the kbuild bot tripped over the same
>issue and did the same bisect.
I did do a build before sending, as you may guess I'm not on an m68k machine.
Forgive the newbie please!
I'm re-sending my patch with the correction.
On Fri, Jan 27, 2017 at 10:09 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On Tue, Jan 24, 2017 at 7:14 AM, Gideon Israel Dsouza
> <gidisrael@gmail.com> wrote:
>> There is <linux/compiler.h> which provides macros for various gcc specific
>> constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
>> instances of gcc specific attributes with the right macros for all files
>> under /arch/m68k
>>
>> This patch depends on the previous with changes in
>
>> @@ -17,6 +18,6 @@ void nf_init(void);
>> void nf_shutdown(void);
>>
>> void nfprint(const char *fmt, ...)
>> - __attribute__ ((format (printf, 1, 2)));
>> + __print(1, 2);
>>
>
> You've gone from printf to print here. This commit is breaking the
> linux-next builds on m68k. I see the kbuild bot tripped over the same
> issue and did the same bisect.
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/12916834/
>
> Paul.
> --
^ permalink raw reply
* Re: [PATCH 2/2] m68k: replaced gcc specific macros with ones from compiler.h
From: Paul Gortmaker @ 2017-01-27 16:39 UTC (permalink / raw)
To: Gideon Israel Dsouza
Cc: Andrew Morton, LKML, gerg, Geert Uytterhoeven, linux-m68k,
linux-next@vger.kernel.org
In-Reply-To: <1485260068-2495-2-git-send-email-gidisrael@gmail.com>
On Tue, Jan 24, 2017 at 7:14 AM, Gideon Israel Dsouza
<gidisrael@gmail.com> wrote:
> There is <linux/compiler.h> which provides macros for various gcc specific
> constructs. Eg: __weak for __attribute__((weak)). I've cleaned all
> instances of gcc specific attributes with the right macros for all files
> under /arch/m68k
>
> This patch depends on the previous with changes in
> @@ -17,6 +18,6 @@ void nf_init(void);
> void nf_shutdown(void);
>
> void nfprint(const char *fmt, ...)
> - __attribute__ ((format (printf, 1, 2)));
> + __print(1, 2);
>
You've gone from printf to print here. This commit is breaking the
linux-next builds on m68k. I see the kbuild bot tripped over the same
issue and did the same bisect.
http://kisskb.ellerman.id.au/kisskb/buildresult/12916834/
Paul.
--
^ permalink raw reply
* Re: [next-20170124] Kernel oops(rt6_fill_node) during reboot of LPAR
From: David Ahern @ 2017-01-27 15:34 UTC (permalink / raw)
To: Sachin Sant, linux-next@vger.kernel.org, netdev
Cc: linuxppc-dev, Stephen Rothwell, davem, Michael Ellerman
In-Reply-To: <9520531C-6458-4442-9ED5-3598E72C7C6A@linux.vnet.ibm.com>
On 1/27/17 5:54 AM, Sachin Sant wrote:
> While rebooting PowerVM LPAR running 4.10.0-rc5-next-20170124
> on a POWER8 box, following kernel oops is displayed.
>
> This problem was introduced with next-20170123. next-20170120 works.
> Initial analysis points to following patch included with next-20170123
>
> commit a1a22c12060e4b9c52f45d4b3460f614e00162a2
> net: ipv6: Keep nexthop of multipath route on admin down
Thanks for the report. Fixed by:
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=1f17e2f2c8a8be3430813119fa7b633398f6185b
^ permalink raw reply
* [next-20170124] Kernel oops(rt6_fill_node) during reboot of LPAR
From: Sachin Sant @ 2017-01-27 12:54 UTC (permalink / raw)
To: linux-next@vger.kernel.org, netdev, dsa
Cc: Michael Ellerman, Stephen Rothwell, linuxppc-dev, davem
While rebooting PowerVM LPAR running 4.10.0-rc5-next-20170124
on a POWER8 box, following kernel oops is displayed.
This problem was introduced with next-20170123. next-20170120 works.
Initial analysis points to following patch included with next-20170123
commit a1a22c12060e4b9c52f45d4b3460f614e00162a2
net: ipv6: Keep nexthop of multipath route on admin down
[ OK ] Stopped Logout off all iSCSI sessions on shutdown.
[ OK ] Stopped CUPS Printing Service.
[ OK ] Stopped Dynamic System Tuning Daemon.
[ OK ] Stopped target Network.
Stopping LSB: Bring up/down networking...
[ 86.292027] Unable to handle kernel paging request for data at address 0x000001d4
[ 86.292050] Faulting instruction address: 0xc0000000008734b0
[ 86.292054] Oops: Kernel access of bad area, sig: 11 [#1]
[ 86.292056] SMP NR_CPUS=2048
[ 86.292057] NUMA
[ 86.292059] pSeries
[ 86.292062] Modules linked in: xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun kvm_pr kvm ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm iw_cxgb3 ib_core ghash_generic xts gf128mul tpm_ibmvtpm tpm vmx_crypto sg pseries_rng nfsd auth_rpcgss nfs_acl lockd
[ 86.292099] grace sunrpc ip_tables xfs libcrc32c sr_mod sd_mod cdrom cxgb3 ibmvscsi ibmveth scsi_transport_srp mdio dm_mirror dm_region_hash dm_log dm_mod
[ 86.292109] CPU: 0 PID: 1500 Comm: NetworkManager Not tainted 4.10.0-rc5-next-20170124 #1
[ 86.292113] task: c00000000319b800 task.stack: c0000000fb9e0000
[ 86.292115] NIP: c0000000008734b0 LR: c000000000873444 CTR: c000000000879490
[ 86.292118] REGS: c0000000fb9e33d0 TRAP: 0300 Not tainted (4.10.0-rc5-next-20170124)
[ 86.292121] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>
[ 86.292124] CR: 28004428 XER: 00000000
[ 86.292128] CFAR: c000000000008850 DAR: 00000000000001d4 DSISR: 40000000 SOFTE: 1
[ 86.292128] GPR00: c000000000873444 c0000000fb9e3650 c000000000ff9f00 0000000000000000
[ 86.292128] GPR04: c0000000fb9e36b4 0000000000000004 c00000026ff50024 0000000000007e80
[ 86.292128] GPR08: 0000000000000000 0000000000000000 0000000000000002 0000000000000014
[ 86.292128] GPR12: c000000000879490 c00000000e800000 0000000000000000 0000000000000000
[ 86.292128] GPR16: 0000000000000000 0000000000000000 0000000000000000 c000000000fa6d00
[ 86.292128] GPR20: 0000000000000000 c000000000fa6d00 0000000000000000 c00000026a5bba00
[ 86.292128] GPR24: c000000000fa6d00 0000000000000000 0000000000000000 00000000384005dc
[ 86.292128] GPR28: 0000000000000000 c00000026a5bba00 c000000279f71c00 c00000026ff50000
[ 86.292163] NIP [c0000000008734b0] rt6_fill_node.isra.42+0x150/0x640
[ 86.292166] LR [c000000000873444] rt6_fill_node.isra.42+0xe4/0x640
[ 86.292169] Call Trace:
[ 86.292171] [c0000000fb9e3650] [c000000000873444] rt6_fill_node.isra.42+0xe4/0x640 (unreliable)
[ 86.292175] [c0000000fb9e3710] [c000000000878718] rt6_dump_route+0x68/0xa0
[ 86.292178] [c0000000fb9e3780] [c0000000008794d8] fib6_dump_node+0x48/0xb0
[ 86.292182] [c0000000fb9e37b0] [c000000000878de8] fib6_walk_continue+0x1d8/0x200
[ 86.292185] [c0000000fb9e3800] [c000000000879134] fib6_walk+0x44/0xa0
[ 86.292189] [c0000000fb9e3840] [c00000000087a0f4] inet6_dump_fib+0x1f4/0x2d0
[ 86.292193] [c0000000fb9e38f0] [c0000000007ae9cc] netlink_dump+0x14c/0x370
[ 86.292196] [c0000000fb9e3940] [c0000000007af428] __netlink_dump_start+0x198/0x210
[ 86.292201] [c0000000fb9e3990] [c0000000007833f4] rtnetlink_rcv_msg+0x194/0x300
[ 86.292204] [c0000000fb9e3a10] [c0000000007b1e48] netlink_rcv_skb+0x128/0x140
[ 86.292208] [c0000000fb9e3a50] [c00000000077f46c] rtnetlink_rcv+0x3c/0x60
[ 86.292211] [c0000000fb9e3a80] [c0000000007b13dc] netlink_unicast+0x1ec/0x370
[ 86.292215] [c0000000fb9e3ae0] [c0000000007b1adc] netlink_sendmsg+0x40c/0x480
[ 86.292219] [c0000000fb9e3b70] [c00000000073caec] sock_sendmsg+0x5c/0x90
[ 86.292223] [c0000000fb9e3ba0] [c00000000073d79c] ___sys_sendmsg+0x31c/0x330
[ 86.292226] [c0000000fb9e3d30] [c00000000073ece4] __sys_sendmsg+0x54/0xc0
[ 86.292229] [c0000000fb9e3dd0] [c00000000073f88c] SyS_socketcall+0x35c/0x3e0
[ 86.292234] [c0000000fb9e3e30] [c00000000000b184] system_call+0x38/0xe0
[ 86.292236] Instruction dump:
[ 86.292238] 39200000 913f0018 e93e0018 e9490048 794807e1 41820010 e9290048 792af7e3
[ 86.292243] 41820024 39200010 913f0018 e93e0158 <812901d4> 2f890000 419e000c 39200011
[ 86.292249] ---[ end trace 6bc185aea0ad63a6 ]---
[ 86.292251]
[ 88.292296] Kernel panic - not syncing: Fatal exception in interrupt
[ 88.292399] Rebooting in 10 seconds..
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Paul Gortmaker @ 2017-01-26 16:19 UTC (permalink / raw)
To: Stafford Horne
Cc: linux, fengguang.wu, Stephen Rothwell, Stefan Kristiansson,
linux-next@vger.kernel.org, LKML
In-Reply-To: <20170126150838.GA21641@lianli.shorne-pla.net>
[Re: linux-next: Tree for Jan 19] On 27/01/2017 (Fri 00:08) Stafford Horne wrote:
> On Thu, Jan 26, 2017 at 02:45:15PM +0900, Stafford Horne wrote:
> > On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote:
> > > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
> > >
> > > [...]
> > >
> > > >
> > > > Are all of these builds using the tests from lkp-tests [0]?
> > >
> > > Not using any specific tests, other than compiling allmodconfig and
> > > defconfig.
> > >
> > > >
> > > > If so and no one is working on openrisc toolchain updates I will package up
> > > > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > > >
> > > > If there is something else that needs to be done let me know.
> > > >
> > > > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> > >
> > > If you could work with Tony (his email is at the bottom of the crosstool
> > > front page in [1]) to get the or32 binutils updated, that would be
> > > great. With all the arch currrently in linux, I pretty much have to
> > > just use what is available from kernel.org as prebuilts.
> > >
> >
> > Thanks,
> >
> > I will followup with Tony.
>
> Hi Paul,
>
> Just in case you are interested I have uploaded toolchains to here:
>
> http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
Thanks, I was able to use this to build or32 defconfig.
Paul.
--
>
> I will be sending the same (the files/patches dir) to Tony.
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Stafford Horne @ 2017-01-26 15:08 UTC (permalink / raw)
To: Paul Gortmaker
Cc: linux, fengguang.wu, Stephen Rothwell, Stefan Kristiansson,
linux-next@vger.kernel.org, LKML
In-Reply-To: <20170126054515.GI7836@lianli.shorne-pla.net>
On Thu, Jan 26, 2017 at 02:45:15PM +0900, Stafford Horne wrote:
> On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote:
> > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
> >
> > [...]
> >
> > >
> > > Are all of these builds using the tests from lkp-tests [0]?
> >
> > Not using any specific tests, other than compiling allmodconfig and
> > defconfig.
> >
> > >
> > > If so and no one is working on openrisc toolchain updates I will package up
> > > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > >
> > > If there is something else that needs to be done let me know.
> > >
> > > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> >
> > If you could work with Tony (his email is at the bottom of the crosstool
> > front page in [1]) to get the or32 binutils updated, that would be
> > great. With all the arch currrently in linux, I pretty much have to
> > just use what is available from kernel.org as prebuilts.
> >
>
> Thanks,
>
> I will followup with Tony.
Hi Paul,
Just in case you are interested I have uploaded toolchains to here:
http://shorne.noip.me/crosstool/files/bin/x86_64/5.4.0/
I will be sending the same (the files/patches dir) to Tony.
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Paul Gortmaker @ 2017-01-26 14:52 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stafford Horne, fengguang.wu, Stephen Rothwell,
Stefan Kristiansson, linux-next@vger.kernel.org, LKML
In-Reply-To: <2a1ef925-a217-31b6-ada7-4a2a0dfae51f@roeck-us.net>
[Re: linux-next: Tree for Jan 19] On 26/01/2017 (Thu 06:22) Guenter Roeck wrote:
> On 01/25/2017 09:38 PM, Stafford Horne wrote:
> >On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote:
> >>On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
> >>>[Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
> >>>
> >>>[...]
> >>>
> >>>>
> >>>>Are all of these builds using the tests from lkp-tests [0]?
> >>>
> >>>Not using any specific tests, other than compiling allmodconfig and
> >>>defconfig.
> >>>
> >>>>
> >>>>If so and no one is working on openrisc toolchain updates I will package up
> >>>>a modern toolchain for the cdn [1] and send patches for lkp-test.
> >>>>
> >>>>If there is something else that needs to be done let me know.
> >>>>
> >>>>[0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> >>>>[1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> >>>
> >>>If you could work with Tony (his email is at the bottom of the crosstool
> >>>front page in [1]) to get the or32 binutils updated, that would be
> >>>great. With all the arch currrently in linux, I pretty much have to
> >>>just use what is available from kernel.org as prebuilts.
> >>>
> >>
> >>Different problem, but from the 0day info I thought you might be interested
> >>in the following breakage as well (seen in -next).
> >>
> >>/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 'do_adedata':
> >>/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: implicit declaration of function 'search_exception_tables'
> >>
> >>Reported on kerneltests.org.
> >
> >Thanks Guenter,
> >
> >Is this for me of Paul?
> >
> Paul, sorry.
Thanks for the heads up. I'll make an appropriate addition to the score
patch. Odd that I didn't see a mail from the 0day bot.
Paul.
--
>
> Guenter
>
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Guenter Roeck @ 2017-01-26 14:22 UTC (permalink / raw)
To: Stafford Horne
Cc: Paul Gortmaker, fengguang.wu, Stephen Rothwell,
Stefan Kristiansson, linux-next@vger.kernel.org, LKML
In-Reply-To: <20170126053801.GH7836@lianli.shorne-pla.net>
On 01/25/2017 09:38 PM, Stafford Horne wrote:
> On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote:
>> On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
>>> [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
>>>
>>> [...]
>>>
>>>>
>>>> Are all of these builds using the tests from lkp-tests [0]?
>>>
>>> Not using any specific tests, other than compiling allmodconfig and
>>> defconfig.
>>>
>>>>
>>>> If so and no one is working on openrisc toolchain updates I will package up
>>>> a modern toolchain for the cdn [1] and send patches for lkp-test.
>>>>
>>>> If there is something else that needs to be done let me know.
>>>>
>>>> [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>>>> [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
>>>
>>> If you could work with Tony (his email is at the bottom of the crosstool
>>> front page in [1]) to get the or32 binutils updated, that would be
>>> great. With all the arch currrently in linux, I pretty much have to
>>> just use what is available from kernel.org as prebuilts.
>>>
>>
>> Different problem, but from the 0day info I thought you might be interested
>> in the following breakage as well (seen in -next).
>>
>> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 'do_adedata':
>> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: implicit declaration of function 'search_exception_tables'
>>
>> Reported on kerneltests.org.
>
> Thanks Guenter,
>
> Is this for me of Paul?
>
Paul, sorry.
Guenter
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Stafford Horne @ 2017-01-26 5:45 UTC (permalink / raw)
To: Paul Gortmaker
Cc: linux, fengguang.wu, Stephen Rothwell, Stefan Kristiansson,
linux-next@vger.kernel.org, LKML
In-Reply-To: <20170125163711.GE29778@windriver.com>
On Wed, Jan 25, 2017 at 11:37:11AM -0500, Paul Gortmaker wrote:
> [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
>
> [...]
>
> >
> > Are all of these builds using the tests from lkp-tests [0]?
>
> Not using any specific tests, other than compiling allmodconfig and
> defconfig.
>
> >
> > If so and no one is working on openrisc toolchain updates I will package up
> > a modern toolchain for the cdn [1] and send patches for lkp-test.
> >
> > If there is something else that needs to be done let me know.
> >
> > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
>
> If you could work with Tony (his email is at the bottom of the crosstool
> front page in [1]) to get the or32 binutils updated, that would be
> great. With all the arch currrently in linux, I pretty much have to
> just use what is available from kernel.org as prebuilts.
>
Thanks,
I will followup with Tony.
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Stafford Horne @ 2017-01-26 5:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: Paul Gortmaker, fengguang.wu, Stephen Rothwell,
Stefan Kristiansson, linux-next@vger.kernel.org, LKML
In-Reply-To: <1014aa6f-447d-9dcc-2a60-01156dcdf88f@roeck-us.net>
On Wed, Jan 25, 2017 at 08:54:53PM -0800, Guenter Roeck wrote:
> On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
> > [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
> >
> > [...]
> >
> > >
> > > Are all of these builds using the tests from lkp-tests [0]?
> >
> > Not using any specific tests, other than compiling allmodconfig and
> > defconfig.
> >
> > >
> > > If so and no one is working on openrisc toolchain updates I will package up
> > > a modern toolchain for the cdn [1] and send patches for lkp-test.
> > >
> > > If there is something else that needs to be done let me know.
> > >
> > > [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> > > [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
> >
> > If you could work with Tony (his email is at the bottom of the crosstool
> > front page in [1]) to get the or32 binutils updated, that would be
> > great. With all the arch currrently in linux, I pretty much have to
> > just use what is available from kernel.org as prebuilts.
> >
>
> Different problem, but from the 0day info I thought you might be interested
> in the following breakage as well (seen in -next).
>
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 'do_adedata':
> /opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: implicit declaration of function 'search_exception_tables'
>
> Reported on kerneltests.org.
Thanks Guenter,
Is this for me of Paul?
You reported score above, but I think probably this is also impacting
openrisc.
Anyway,
I think this is due to Puals changes which separated out extable from
module. traps.c in score and openrisc use search_exception_tables and
include <linux/module.h> to get it.
I did see Paul post a patch to fix traps.c too,
This should be fixed by today.
-Stafford
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Guenter Roeck @ 2017-01-26 4:54 UTC (permalink / raw)
To: Paul Gortmaker, Stafford Horne
Cc: fengguang.wu, Stephen Rothwell, Stefan Kristiansson,
linux-next@vger.kernel.org, LKML
In-Reply-To: <20170125163711.GE29778@windriver.com>
On 01/25/2017 08:37 AM, Paul Gortmaker wrote:
> [Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
>
> [...]
>
>>
>> Are all of these builds using the tests from lkp-tests [0]?
>
> Not using any specific tests, other than compiling allmodconfig and
> defconfig.
>
>>
>> If so and no one is working on openrisc toolchain updates I will package up
>> a modern toolchain for the cdn [1] and send patches for lkp-test.
>>
>> If there is something else that needs to be done let me know.
>>
>> [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
>
> If you could work with Tony (his email is at the bottom of the crosstool
> front page in [1]) to get the or32 binutils updated, that would be
> great. With all the arch currrently in linux, I pretty much have to
> just use what is available from kernel.org as prebuilts.
>
Different problem, but from the 0day info I thought you might be interested
in the following breakage as well (seen in -next).
/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c: In function 'do_adedata':
/opt/buildbot/slave/next-next/build/arch/score/kernel/traps.c:185:2: error: implicit declaration of function 'search_exception_tables'
Reported on kerneltests.org.
Guenter
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the userns tree
From: Stephen Rothwell @ 2017-01-26 3:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Eric W. Biederman, linux-next, linux-kernel, Aleksa Sarai
In-Reply-To: <20170125174322.777ddcb0e232d5409569e95c@linux-foundation.org>
Hi Andrew,
On Wed, 25 Jan 2017 17:43:22 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 26 Jan 2017 13:59:23 +1300 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> > Andrew do you see merit in Aleksa's patch that I don't? Otherwise can
> > you remove it from your tree?
>
> I have done so.
I'll drop it from linux-next on Monday (if there is no new mmotm by then).
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the userns tree
From: Andrew Morton @ 2017-01-26 1:43 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Stephen Rothwell, linux-next, linux-kernel, Aleksa Sarai
In-Reply-To: <871svqeivo.fsf@xmission.com>
On Thu, 26 Jan 2017 13:59:23 +1300 ebiederm@xmission.com (Eric W. Biederman) wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> > fs/proc/base.c
> >
> > between commit:
> >
> > 68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user namespaces")
> >
> > from the userns tree and commit:
> >
> > d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")
> >
> > from the akpm-current tree.
> >
> > I *think* that the former supercedes the latter?
>
> Sort of. After a long conversation it turns out what they are trying to
> do is orthogonal.
>
> The first (mine) is handling the case of non-dumpable tasks in user
> namespaces.
>
> The second by Aleksa Sarai is trying to trying to relax the permission
> checks in proc so that non-dumpable is not as strict, to sort out some
> runC issues where they are having challenges coding themselves into a
> corner. In the case of /proc/self I think there may be a case but in
> general relaxing the permission checks in proc gives me the Heebie
> Jeebies.
>
> Andrew do you see merit in Aleksa's patch that I don't? Otherwise can
> you remove it from your tree?
I have done so.
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the userns tree
From: Eric W. Biederman @ 2017-01-26 0:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Aleksa Sarai
In-Reply-To: <20170125160835.1b94db55@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> fs/proc/base.c
>
> between commit:
>
> 68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user namespaces")
>
> from the userns tree and commit:
>
> d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files")
>
> from the akpm-current tree.
>
> I *think* that the former supercedes the latter?
Sort of. After a long conversation it turns out what they are trying to
do is orthogonal.
The first (mine) is handling the case of non-dumpable tasks in user
namespaces.
The second by Aleksa Sarai is trying to trying to relax the permission
checks in proc so that non-dumpable is not as strict, to sort out some
runC issues where they are having challenges coding themselves into a
corner. In the case of /proc/self I think there may be a case but in
general relaxing the permission checks in proc gives me the Heebie
Jeebies.
Andrew do you see merit in Aleksa's patch that I don't? Otherwise can
you remove it from your tree?
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Stephen thank you for pointing this out.
Eric
^ permalink raw reply
* Re: linux-next: Tree for Jan 19
From: Paul Gortmaker @ 2017-01-25 16:37 UTC (permalink / raw)
To: Stafford Horne
Cc: linux, fengguang.wu, Stephen Rothwell, Stefan Kristiansson,
linux-next@vger.kernel.org, LKML
In-Reply-To: <20170123141159.GE7836@lianli.shorne-pla.net>
[Re: linux-next: Tree for Jan 19] On 23/01/2017 (Mon 23:11) Stafford Horne wrote:
[...]
>
> Are all of these builds using the tests from lkp-tests [0]?
Not using any specific tests, other than compiling allmodconfig and
defconfig.
>
> If so and no one is working on openrisc toolchain updates I will package up
> a modern toolchain for the cdn [1] and send patches for lkp-test.
>
> If there is something else that needs to be done let me know.
>
> [0] git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.5.1/
If you could work with Tony (his email is at the bottom of the crosstool
front page in [1]) to get the or32 binutils updated, that would be
great. With all the arch currrently in linux, I pretty much have to
just use what is available from kernel.org as prebuilts.
Paul.
--
>
> -Stafford
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox