On 01/22/2015 09:13 AM, Kirill A. Shutemov wrote:
...
vm_normal_page() is never called in this case, since prot_numa is always
zero.
I tracked the bug down. It's a sparc bug. The commit only triggers it,
because affect how GCC optimize the code around faulty point.
Please, test.
From 5b923275
On Thu, Jan 22, 2015 at 07:13:38PM +0200, Kirill A. Shutemov wrote:
> On Wed, Jan 21, 2015 at 07:14:33PM -0800, Guenter Roeck wrote:
> > On 01/21/2015 02:43 AM, Kirill A. Shutemov wrote:
> >
> > >>BUG: Bad page state in process init.sh pfn:0
> > >>page:f05e7460 count:0 mapcount:-1 mapping: (
On Wed, Jan 21, 2015 at 07:14:33PM -0800, Guenter Roeck wrote:
> On 01/21/2015 02:43 AM, Kirill A. Shutemov wrote:
>
> >>BUG: Bad page state in process init.sh pfn:0
> >>page:f05e7460 count:0 mapcount:-1 mapping: (null) index:0x0
> >>flags: 0x400(reserved)
> >>page dumped because: PAGE_FLAGS
On Thursday, January 22, 2015 04:12:41 AM Al Viro wrote:
> On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
> > Al, do you mind if I fold your patch below into the existing patches?
>
> No problem, but I'd probably prefer to put this series through vfs.git.
> With the following as the f
On Wed, Jan 21, 2015 at 09:28:51PM -0500, Paul Moore wrote:
> Al, do you mind if I fold your patch below into the existing patches?
No problem, but I'd probably prefer to put this series through vfs.git.
With the following as the first step:
Cut down on do_path_lookup() callers
Use filename_loo
On 01/21/2015 02:43 AM, Kirill A. Shutemov wrote:
BUG: Bad page state in process init.sh pfn:0
page:f05e7460 count:0 mapcount:-1 mapping: (null) index:0x0
flags: 0x400(reserved)
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags:
flags: 0x400(reserved)
CPU: 0 PI
On Wednesday, January 21, 2015 09:28:33 PM Al Viro wrote:
> On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> > failing case:
> >
> > path_lookupat: calling path_init 'usr' flags=40
> > path_init: link_path_walk() returned 0
> > path_lookupat: path_init 'usr' flags=40[50] returned 0
On Wed, Jan 21, 2015 at 12:43:25PM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 20, 2015 at 07:05:41PM -0800, Guenter Roeck wrote:
> > On 01/20/2015 02:54 PM, Kirill A. Shutemov wrote:
> > >On Tue, Jan 20, 2015 at 12:26:42PM -0800, Guenter Roeck wrote:
> > >>---
> > >>sparc:
> > >>
> > >># bad: [
On Wed, 21 Jan 2015, Al Viro wrote:
> Folks, could you check if the following on top of linux-next fixes the
> problem?
Tested-by: Paul Walmsley # Tegra124 Jetson TK1
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 323957f..cda89c3 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2056,13 +
2015-01-21, 21:28:33 +, Al Viro wrote:
> On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> > ok case (putname commented out):
> >
> > user_path_at_empty lookup usr flags 0x0
> > path_lookupat: calling path_init 'usr' flags=40
> > path_init: link_path_walk() returned 0
> > path_l
On Wed, Jan 21, 2015 at 09:28:33PM +, Al Viro wrote:
> On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> >
> > failing case:
> >
> > path_lookupat: calling path_init 'usr' flags=40
> > path_init: link_path_walk() returned 0
> > path_lookupat: path_init 'usr' flags=40[50] return
2015-01-21, 13:03:20 -0800, Guenter Roeck wrote:
> On 01/21/2015 12:06 PM, Al Viro wrote:
> >On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
> >>On 01/21/2015 10:29 AM, Al Viro wrote:
> >>>On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
> Another data point (though
On Wed, Jan 21, 2015 at 01:03:20PM -0800, Guenter Roeck wrote:
> ok case (putname commented out):
>
> user_path_at_empty lookup usr flags 0x0
> path_lookupat: calling path_init 'usr' flags=40
> path_init: link_path_walk() returned 0
> path_lookupat: path_init 'usr' flags=40[50] returned 0
> walk_c
On 01/21/2015 12:06 PM, Al Viro wrote:
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it means):
In the worki
On Wed, Jan 21, 2015 at 11:06:27AM -0800, Guenter Roeck wrote:
> On 01/21/2015 10:29 AM, Al Viro wrote:
> >On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
> >>Another data point (though I have no idea if it is useful or what it means):
> >>
> >>In the working case, path_init sets nd-
On 01/21/2015 10:29 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
Another data point (though I have no idea if it is useful or what it means):
In the working case, path_init sets nd->flags to 0x50 or 0x51.
In the non-working case (ie for all files with a '/'
On Wed, Jan 21, 2015 at 05:32:13AM -0800, Guenter Roeck wrote:
> Another data point (though I have no idea if it is useful or what it means):
>
> In the working case, path_init sets nd->flags to 0x50 or 0x51.
> In the non-working case (ie for all files with a '/' in the name),
> it sets nd->flags
On 01/21/2015 09:38 AM, Al Viro wrote:
On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote:
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
That doesn't seem to help, at least in my case.
Same here.
Okay, thanks for
On Wed, Jan 21, 2015 at 11:16:23AM -0500, Paul Moore wrote:
> On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote:
> > 2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
> > > That doesn't seem to help, at least in my case.
> >
> > Same here.
>
> Okay, thanks for trying. Sorry that d
On 01/21/2015 07:54 AM, Sabrina Dubroca wrote:
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
2015-0
On Wednesday, January 21, 2015 04:54:07 PM Sabrina Dubroca wrote:
> 2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
> > That doesn't seem to help, at least in my case.
>
> Same here.
Okay, thanks for trying. Sorry that didn't resolve things.
> Well, it's probably not an audit issue. I tried
2015-01-21, 16:39:12 +0100, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
> > On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> > > On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > > > 2015-01-21, 04:36:38 +, Al Viro wro
On Wed, Jan 21, 2015 at 10:24:11AM -0500, Paul Moore wrote:
> On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> > On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > > 2015-01-21, 04:36:38 +, Al Viro wrote:
> > > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guen
On Wednesday, January 21, 2015 03:42:16 PM Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> > 2015-01-21, 04:36:38 +, Al Viro wrote:
> > > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > > > With this patch:
> > > >
> > > > sys_mkdir
On Wednesday, January 21, 2015 04:36:38 AM Al Viro wrote:
> Another thing I really do not understand is
> + if (inode->i_ino) {
> + /* valid inode number, use that for the ...
> + if (n->ino != inode->i_ino ||
> + n
On Wed, Jan 21, 2015 at 12:05:39PM +0100, Sabrina Dubroca wrote:
> 2015-01-21, 04:36:38 +, Al Viro wrote:
> > On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > > With this patch:
> > >
> > > sys_mkdir .:40775 returned -17
> > > sys_mkdir usr:40775 returned 0
> > > sys_mkdir us
On 01/21/2015 03:05 AM, Sabrina Dubroca wrote:
2015-01-21, 04:36:38 +, Al Viro wrote:
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
With this patch:
sys_mkdir .:40775 returned -17
sys_mkdir usr:40775 returned 0
sys_mkdir usr/lib:40775 returned 0
sys_mkdir usr/share:40755 r
2015-01-21, 04:36:38 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> > With this patch:
> >
> > sys_mkdir .:40775 returned -17
> > sys_mkdir usr:40775 returned 0
> > sys_mkdir usr/lib:40775 returned 0
> > sys_mkdir usr/share:40755 returned 0
> > sys_mkdir u
On Tue, Jan 20, 2015 at 07:05:41PM -0800, Guenter Roeck wrote:
> On 01/20/2015 02:54 PM, Kirill A. Shutemov wrote:
> >On Tue, Jan 20, 2015 at 12:26:42PM -0800, Guenter Roeck wrote:
> >>---
> >>sparc:
> >>
> >># bad: [5d0ee6f76de160f7d7f9dc0b64a98ad9b8e9] Add linux-next specific
> >>files for 2
On Tue, Jan 20, 2015 at 08:01:26PM -0800, Guenter Roeck wrote:
> With this patch:
>
> sys_mkdir .:40775 returned -17
> sys_mkdir usr:40775 returned 0
> sys_mkdir usr/lib:40775 returned 0
> sys_mkdir usr/share:40755 returned 0
> sys_mkdir usr/share/udhcpc:40755 returned 0
> sys_mkdir usr/bin:40775
On 01/20/2015 07:36 PM, Al Viro wrote:
On Tue, Jan 20, 2015 at 06:44:34PM -0800, Guenter Roeck wrote:
The shit hits the fan earlier - when we end up missing /dev. There are
two places where it could've been created (depending on CONFIG_BLK_DEV_INITRD);
sys_mkdir(collected, mode);
in ini
On Tue, Jan 20, 2015 at 06:44:34PM -0800, Guenter Roeck wrote:
> >The shit hits the fan earlier - when we end up missing /dev. There are
> >two places where it could've been created (depending on
> >CONFIG_BLK_DEV_INITRD);
> > sys_mkdir(collected, mode);
> >in init/initramfs.c (line 353 in li
On 01/20/2015 02:54 PM, Kirill A. Shutemov wrote:
On Tue, Jan 20, 2015 at 12:26:42PM -0800, Guenter Roeck wrote:
---
sparc:
# bad: [5d0ee6f76de160f7d7f9dc0b64a98ad9b8e9] Add linux-next specific files
for 20150120
# good: [ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc] Linux 3.19-rc5
git bisect
On 01/20/2015 04:41 PM, Al Viro wrote:
The shit hits the fan earlier - when we end up missing /dev. There are
two places where it could've been created (depending on CONFIG_BLK_DEV_INITRD);
sys_mkdir(collected, mode);
in init/initramfs.c (line 353 in linux-next) and
err = sys_m
On Tue, Jan 20, 2015 at 07:14:46PM -0500, Paul Moore wrote:
> > > with the patch applied (+panic)
> > >
> > >
> > > and:
> > >
> > > stat("/dev/root") -> 0
> > > stat("dev") -> 0
> > > with the old version of do_path_lookup.
> >
> > Wait a minute ... at this early stage of boot, I'm pretty sure
On Tuesday, January 20, 2015 07:04:54 PM Paul Moore wrote:
> On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
> > 2015-01-20, 23:17:25 +, Al Viro wrote:
> > > On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > > > doesn't look at _anything_ other than name->name other
On Wednesday, January 21, 2015 12:27:26 AM Sabrina Dubroca wrote:
> 2015-01-20, 23:17:25 +, Al Viro wrote:
> > On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > > doesn't look at _anything_ other than name->name other than for
> > > audit_inode(). And name->name is apparently the sam
2015-01-20, 23:17:25 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> > doesn't look at _anything_ other than name->name other than for
> > audit_inode().
> > And name->name is apparently the same.
> >
> > It looks like something ends up buggering name->name in p
On Tue, Jan 20, 2015 at 10:50:41PM +, Al Viro wrote:
> doesn't look at _anything_ other than name->name other than for audit_inode().
> And name->name is apparently the same.
>
> It looks like something ends up buggering name->name in process, but then
> the damn thing appears to be normal aft
On Tue, Jan 20, 2015 at 12:26:42PM -0800, Guenter Roeck wrote:
> ---
> sparc:
>
> # bad: [5d0ee6f76de160f7d7f9dc0b64a98ad9b8e9] Add linux-next specific
> files for 20150120
> # good: [ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc] Linux 3.19-rc5
> git bisect start 'HEAD' 'v3.19-rc5'
> # good: [f93
On Tue, Jan 20, 2015 at 02:13:09PM -0800, Guenter Roeck wrote:
> > > Nuts... Is reverting just this (do_path_lookup()) part of commit
> > > sufficient
> > > to recover the normal behaviour?
> >
> > Yes.
> >
> Same on microblaze.
This is completely insane.
static int filename_lookup(int dfd, s
On Tue, Jan 20, 2015 at 11:08:23PM +0100, Sabrina Dubroca wrote:
> 2015-01-20, 21:58:31 +, Al Viro wrote:
> > On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote:
> >
> > > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0
> > > [1.539704] fn_lookup bsg 0, f
2015-01-20, 21:58:31 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote:
>
> > [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0
> > [1.539704] fn_lookup bsg 0, 88001f718000 bsg
> > [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f
On Tue, Jan 20, 2015 at 10:38:58PM +0100, Sabrina Dubroca wrote:
> [1.538646] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0
> [1.539704] fn_lookup bsg 0, 88001f718000 bsg
> [1.540559] fn_lookup bsg/0:0:0:0 -2, 88001f718000 bsg/0:0:0:0
> [1.552611] fn_lookup bsg/1:0
On Tue, Jan 20, 2015 at 09:02:03PM +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote:
>
> > printk(KERN_ERR "fn_lookup %s %d\n", name, retval);
> >
> > and I get:
> >
> > [1.618558] fn_lookup bsg/0:0:0:0 -2
> > [1.619437] fn_lookup bsg 0
> > [1.6
2015-01-20, 21:02:03 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote:
>
> > printk(KERN_ERR "fn_lookup %s %d\n", name, retval);
> >
> > and I get:
> >
> > [1.618558] fn_lookup bsg/0:0:0:0 -2
> > [1.619437] fn_lookup bsg 0
> > [1.620236] fn_look
On Tue, Jan 20, 2015 at 09:45:04PM +0100, Sabrina Dubroca wrote:
> printk(KERN_ERR "fn_lookup %s %d\n", name, retval);
>
> and I get:
>
> [1.618558] fn_lookup bsg/0:0:0:0 -2
> [1.619437] fn_lookup bsg 0
> [1.620236] fn_lookup bsg/0:0:0:0 -2
> [1.625996] fn_lookup sda 0
> [1.6
2015-01-20, 19:54:32 +, Al Viro wrote:
> On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
> > 2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> > > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > > > Hello,
> > > >
> > > > Today's linux-next doesn't boot on my
On Tue, Jan 20, 2015 at 06:53:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150119:
>
> The omap tree gained a conflict against the arm-soc tree.
>
> The net-next tree lost its build failure.
>
> The mmc-uh tree gained a conflict against the sunxi tree.
>
> The audit tree g
On Tuesday, January 20, 2015 05:43:01 PM Fabio Estevam wrote:
> On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore wrote:
> > On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote:
> >> On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler
> >>
> >> wrote:
> >> > These were just nuisance warnings, I bel
On Tue, Jan 20, 2015 at 06:51:35PM +0100, Sabrina Dubroca wrote:
> 2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> > On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > > Hello,
> > >
> > > Today's linux-next doesn't boot on my qemu VM:
> >
> > ...
> >
> > > I bisected it down t
On Tue, Jan 20, 2015 at 5:24 PM, Paul Moore wrote:
> On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote:
>> On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler
>>
>> wrote:
>> > These were just nuisance warnings, I believe, so my guess is that this
>> > isn't related to your kernel panic. R
On Tuesday, January 20, 2015 05:16:45 PM Fabio Estevam wrote:
> On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler
>
> wrote:
> > These were just nuisance warnings, I believe, so my guess is that this
> > isn't related to your kernel panic. Reverting Boaz's patches to make
> > these warnings go away
On Tue, Jan 20, 2015 at 5:00 PM, Ross Zwisler
wrote:
> These were just nuisance warnings, I believe, so my guess is that this
> isn't related to your kernel panic. Reverting Boaz's patches to make
> these warnings go away would let you know for sure.
You are right. Reverting 937af5ecd0591e mak
On Tue, 2015-01-20 at 15:54 -0200, Fabio Estevam wrote:
> On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore wrote:
>
> > Thanks for testing this and reporting the problem, especially such a small
> > bisection. Unfortunately nothing is immediately obvious to me, would you
> > mind
> > sharing your ke
On Tue, Jan 20, 2015 at 3:39 PM, Paul Moore wrote:
> Thanks for testing this and reporting the problem, especially such a small
> bisection. Unfortunately nothing is immediately obvious to me, would you mind
> sharing your kernel config so I can try to reproduce and debug the problem?
In case i
2015-01-20, 12:39:08 -0500, Paul Moore wrote:
> On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> > Hello,
> >
> > Today's linux-next doesn't boot on my qemu VM:
>
> ...
>
> > I bisected it down to:
> >
> > 5dc5218840e1 fs: create proper filename objects using getname_kernel()
On Tuesday, January 20, 2015 05:56:55 PM Sabrina Dubroca wrote:
> Hello,
>
> Today's linux-next doesn't boot on my qemu VM:
...
> I bisected it down to:
>
> 5dc5218840e1 fs: create proper filename objects using getname_kernel()
>
> I reverted then reapplied each part of that patch. It works
Hello,
Today's linux-next doesn't boot on my qemu VM:
[1.248357] scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK0
PQ: 0 ANSI: 5
[1.255899] sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00
GiB)
[1.258333] sd 0:0:0:0: [sda] Write Protect is off
[1.259
On Tue, Jan 20, 2015 at 06:53:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150119:
>
> The omap tree gained a conflict against the arm-soc tree.
>
> The net-next tree lost its build failure.
>
> The mmc-uh tree gained a conflict against the sunxi tree.
>
> The audit tree g
60 matches
Mail list logo
