On Wed, Feb 4, 2015 at 4:52 PM, Bruno Prémont wrote:
> On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote:
>> On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote:
>> > On Fri, 30 January 2015 Trond Myklebust wrote:
>> > > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
>> > > > On Sun, J
On Wed, 4 Feb 2015 14:06:48 Trond Myklebust wrote:
> On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont wrote:
> > On Fri, 30 January 2015 Trond Myklebust wrote:
> > > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> > > > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
> > > > > On a
On Wed, Feb 4, 2015 at 12:08 PM, Bruno Prémont
wrote:
>
> On Fri, 30 January 2015 Trond Myklebust wrote:
> > On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
> > > On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont wrote:
> > > > On a system running home-brown container (mntns, utsns, pidns,
nt contexts (for instance in the AUTH_SYS credential) where it
> > isn't always appropriate to have it set to an empty string.
>
> I was rather hoping that Bruno would fix up his patch and resend, but
> since other reports of the same bug are now surfacing... Please could
>
On 2 Feb 2015, Trond Myklebust verbalised:
> Hmm... I'm at a loss to see how rpcb_create can ever call
> rpc_new_client() with a null value for the nodename with that patch
> applied. Are you 100% sure that the above Oops came from a patched
> kernel? That IP address of "rpc_new_client+0x13b/0x1f2"
On Mon, Feb 2, 2015 at 12:41 PM, Nix wrote:
> On 31 Jan 2015, n...@esperi.org.uk told this:
>> I'll let it run overnight and give it a reboot in the morning.
>
> Alas, my latest reboot hit:
>
> [ 215.245158] BUG: unable to handle kernel NULL pointer dereference at
> 0004
> [ 215.251602] IP:
On 31 Jan 2015, n...@esperi.org.uk told this:
> I'll let it run overnight and give it a reboot in the morning.
Alas, my latest reboot hit:
[ 215.245158] BUG: unable to handle kernel NULL pointer dereference at 0004
[ 215.251602] IP: [] rpc_new_client+0x13b/0x1f2
[ 215.251602] *pde = 00
Wednesday.
Thanks,
Bruno
> Thanks
> Trond
>
> 8<-
> From 87557df0ca2241da0edac558286650fdb081152c Mon Sep 17 00:00:00 2001
> From: Trond Myklebust
> Date: Fri, 30 Jan 2015 18:12:28 -0500
> Subjec
On 30 Jan 2015, Trond Myklebust uttered the following:
> On Sun, 2015-01-25 at 16:55 -0500, Trond Myklebust wrote:
>> On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
>> wrote:
>> > On a system running home-brown container (mntns, utsns, pidns, netns)
>> > with NFS mount-point bind-mounted into the
The point is that the rpc_clnt->cl_nodename is used in various
> different contexts (for instance in the AUTH_SYS credential) where it
> isn't always appropriate to have it set to an empty string.
I was rather hoping that Bruno would fix up his patch and resend, but
since other repor
On Sun, Jan 25, 2015 at 4:06 PM, Bruno Prémont
wrote:
> On a system running home-brown container (mntns, utsns, pidns, netns)
> with NFS mount-point bind-mounted into the container I hit the following
> trace if nfs filesystem is first umount()ed in init ns and then later
> umounted from container
On a system running home-brown container (mntns, utsns, pidns, netns)
with NFS mount-point bind-mounted into the container I hit the following
trace if nfs filesystem is first umount()ed in init ns and then later
umounted from container when the container exists.
[51397.767310] BUG: unable to hand
12 matches
Mail list logo
