On May 25, 2016, at 1:24 AM, Al Viro wrote:
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 28cb431..0cd5227 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -101,7 +101,7 @@
> #define iterate_and_advance(i, n, v, I, B, K) { \
> if (unlikely(i->count
On 05/25/2016 01:24 AM, Al Viro wrote:
On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote:
On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote:
On May 24, 2016, at 2:36 PM, Larry Finger wrote:
On 05/24/2016 02:25 PM, Matthew McClintock wrote:
On May 24, 2016, at 2:16 PM
On Wed, May 25, 2016 at 12:41:33AM +0100, Al Viro wrote:
> On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote:
> >
> > > On May 24, 2016, at 2:36 PM, Larry Finger
> > > wrote:
> > >
> > > On 05/24/2016 02:25 PM, Matthew McClintock wrote:
> > >> On May 24, 2016, at 2:16 PM, Larry
On Tue, May 24, 2016 at 09:06:03PM -0500, Matthew McClintock wrote:
>
> > On May 24, 2016, at 8:28 PM, Al Viro wrote:
> >
> > The next obvious question is which binary it is and what's the return
> > address to userland; make that
> > if (!size)
> > printk(KERN_ERR "crap in %s[%x
> On May 24, 2016, at 8:28 PM, Al Viro wrote:
>
> The next obvious question is which binary it is and what's the return
> address to userland; make that
> if (!size)
> printk(KERN_ERR "crap in %s[%x]",
> current->comm,
> current_pt_
On Tue, May 24, 2016 at 08:20:46PM -0500, Matthew McClintock wrote:
>
> > On May 24, 2016, at 8:10 PM, Al Viro wrote:
> >
> > Slap the WARN_ON(!size); in the very beginning of iov_iter_advance(), see
> > where it's triggered...
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 28cb431..d
> On May 24, 2016, at 8:10 PM, Al Viro wrote:
>
> Slap the WARN_ON(!size); in the very beginning of iov_iter_advance(), see
> where it's triggered...
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 28cb431..d89e154 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -488,6 +488,7 @@ EXPORT_S
On Tue, May 24, 2016 at 07:58:13PM -0500, Matthew McClintock wrote:
>
> > On May 24, 2016, at 6:41 PM, Al Viro wrote:
> >
> > Again, I understand what's going on kernel-side; the only tricky part is how
> > to fix it without bringing the nasal daemons back. I think I have a
> > solution
> > an
> On May 24, 2016, at 6:41 PM, Al Viro wrote:
>
> Again, I understand what's going on kernel-side; the only tricky part is how
> to fix it without bringing the nasal daemons back. I think I have a solution
> and I'm going to post it tonight if it survives the local beating. In any
> case, the
On Tue, May 24, 2016 at 05:31:51PM -0500, Matthew McClintock wrote:
>
> > On May 24, 2016, at 2:36 PM, Larry Finger wrote:
> >
> > On 05/24/2016 02:25 PM, Matthew McClintock wrote:
> >> On May 24, 2016, at 2:16 PM, Larry Finger
> >> wrote:
> >>>
> >>> On 05/24/2016 02:13 PM, Matthew McClintoc
> On May 24, 2016, at 2:36 PM, Larry Finger wrote:
>
> On 05/24/2016 02:25 PM, Matthew McClintock wrote:
>> On May 24, 2016, at 2:16 PM, Larry Finger wrote:
>>>
>>> On 05/24/2016 02:13 PM, Matthew McClintock wrote:
I’m seeing this too, same commit if you want another person to
test/
On 05/24/2016 02:25 PM, Matthew McClintock wrote:
On May 24, 2016, at 2:16 PM, Larry Finger wrote:
On 05/24/2016 02:13 PM, Matthew McClintock wrote:
I’m seeing this too, same commit if you want another person to test/reproduce.
If you do a pull today, does that fix your problem?
Hmm, no.
On May 24, 2016, at 2:16 PM, Larry Finger wrote:
>
> On 05/24/2016 02:13 PM, Matthew McClintock wrote:
>> I’m seeing this too, same commit if you want another person to
>> test/reproduce.
>
> If you do a pull today, does that fix your problem?
Hmm, no. Which commit am I looking for? I’m on
a5
On 05/24/2016 02:13 PM, Matthew McClintock wrote:
I’m seeing this too, same commit if you want another person to test/reproduce.
If you do a pull today, does that fix your problem?
Larry
I’m seeing this too, same commit if you want another person to test/reproduce.
-M
> On May 24, 2016, at 11:10 AM, Larry Finger wrote:
>
> On 05/23/2016 07:18 PM, Al Viro wrote:
>> On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote:
>>> The mainline kernels past 4.6.0 fail hang when lo
On 05/24/2016 11:28 AM, Al Viro wrote:
On Tue, May 24, 2016 at 11:10:09AM -0500, Larry Finger wrote:
For now, the following one-line hack allows my system to boot:
diff --git a/fs/read_write.c b/fs/read_write.c
index 933b53a..d5d64d9 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -721,6
On Tue, May 24, 2016 at 11:10:09AM -0500, Larry Finger wrote:
> For now, the following one-line hack allows my system to boot:
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 933b53a..d5d64d9 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -721,6 +721,7 @@ static ssize_t do
On 05/23/2016 07:18 PM, Al Viro wrote:
On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote:
The mainline kernels past 4.6.0 fail hang when logging in. There are no
error messages, and the machine seems to be waiting for some event that
never happens.
The problem has been bisected to co
On 05/23/2016 07:18 PM, Al Viro wrote:
On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote:
The mainline kernels past 4.6.0 fail hang when logging in. There are no
error messages, and the machine seems to be waiting for some event that
never happens.
The problem has been bisected to co
On Mon, May 23, 2016 at 04:30:43PM -0500, Larry Finger wrote:
> The mainline kernels past 4.6.0 fail hang when logging in. There are no
> error messages, and the machine seems to be waiting for some event that
> never happens.
>
> The problem has been bisected to commit dd254f5a382c ("fold checks
The mainline kernels past 4.6.0 fail hang when logging in. There are no error
messages, and the machine seems to be waiting for some event that never happens.
The problem has been bisected to commit dd254f5a382c ("fold checks into
iterate_and_advance()"). The bisection has been verified.
The
21 matches
Mail list logo
