Tony Lindgren writes:
> * Kalle Valo [161004 12:42]:
>> Tony Lindgren writes:
>>
>> > And the patch below seems to fix the issue as the driver is now
>> > using devm_kzalloc. Will do some more testing and then will post
>> > a proper patch. The same issue might be there for SPI glue also.
>>
On Tue 04-10-16 15:56:39, Al Viro wrote:
> On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > Hi!
> >
> > On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> > > I'm seeing a repeatable oops with Linux next while running
> > > update-initramfs, see below. I tried reverting commit 59aa5a3ae
* Kalle Valo [161004 12:42]:
> Tony Lindgren writes:
>
> > * Tony Lindgren [161004 12:17]:
> >> Hi,
> >>
> >> * Al Viro [161004 08:00]:
> >> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote:
> >> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> >> > > > Never see
Tony Lindgren writes:
> * Tony Lindgren [161004 12:17]:
>> Hi,
>>
>> * Al Viro [161004 08:00]:
>> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote:
>> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
>> > > > Never seen this but I suspect it is a fallout from Al's d
* Tony Lindgren [161004 12:17]:
> Hi,
>
> * Al Viro [161004 08:00]:
> > On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote:
> > > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > > > Never seen this but I suspect it is a fallout from Al's directory
> > > > locking
> > >
* Theodore Ts'o [161004 12:08]:
> On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote:
> > Jan is wrong - we do have per-struct-file serialization for getdents()
> > et.al. It might be a race between getdents() on *different* struct
> > file for the same directory, but ->private_data is not a
Hi,
* Al Viro [161004 08:00]:
> On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote:
> > On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > > Never seen this but I suspect it is a fallout from Al's directory locking
> > > changes. In particular ext4_htree_fill_tree() builds r
On Tue, Oct 04, 2016 at 03:59:15PM +0100, Al Viro wrote:
> Jan is wrong - we do have per-struct-file serialization for getdents()
> et.al. It might be a race between getdents() on *different* struct
> file for the same directory, but ->private_data is not a problem.
So the rb_insert_color() OOPS
On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> Hi!
>
> On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> > I'm seeing a repeatable oops with Linux next while running
> > update-initramfs, see below. I tried reverting commit 59aa5a3aeead
> > ("fscrypto: make filename crypto functions re
On Tue, Oct 04, 2016 at 10:02:31AM -0400, Theodore Ts'o wrote:
> On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > Never seen this but I suspect it is a fallout from Al's directory locking
> > changes. In particular ext4_htree_fill_tree() builds rb-tree of found
> > directory entries in
* Theodore Ts'o [161004 07:04]:
> On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> > Never seen this but I suspect it is a fallout from Al's directory locking
> > changes. In particular ext4_htree_fill_tree() builds rb-tree of found
> > directory entries in file->private_data (and gener
* Jan Kara [161004 02:01]:
> Hi!
>
> On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> > I'm seeing a repeatable oops with Linux next while running
> > update-initramfs, see below. I tried reverting commit 59aa5a3aeead
> > ("fscrypto: make filename crypto functions return 0 on success")
> > as tha
On Tue, Oct 04, 2016 at 11:00:41AM +0200, Jan Kara wrote:
> Never seen this but I suspect it is a fallout from Al's directory locking
> changes. In particular ext4_htree_fill_tree() builds rb-tree of found
> directory entries in file->private_data (and generally modifies the
> structure stored ther
Hi!
On Mon 03-10-16 16:30:55, Tony Lindgren wrote:
> I'm seeing a repeatable oops with Linux next while running
> update-initramfs, see below. I tried reverting commit 59aa5a3aeead
> ("fscrypto: make filename crypto functions return 0 on success")
> as that's the only commit changing ext4_htree_st
Hi,
I'm seeing a repeatable oops with Linux next while running
update-initramfs, see below. I tried reverting commit 59aa5a3aeead
("fscrypto: make filename crypto functions return 0 on success")
as that's the only commit changing ext4_htree_store_dirent, but
that did not help.
Anybody else seeing
15 matches
Mail list logo