That pile is the first part of dealing with livelocks, etc. around
shrink_dcache_parent().
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/lin
fs/dcache.c work, mostly - part of that is what trylock elimination
series has turned into, part - making d_move() preserve the parent (and thus
the path) of victim, plus some general cleanups.
The following changes since commit 8cc07c808c9d595e81cbe5aad419b7769eb2e5c9:
fs: dcache: Use
This time there's too many branches to push them one by one,
unfortunately. This pile:
* more ->d_init() stuff (work.dcache)
* pathname resolution cleanups (work.namei)
* a few missing iov_iter primitives - copy_from_iter_full() and
friends. Either copy the full re
On Mon, 10 Oct 2016, Linus Torvalds wrote:
> But the fact that it reacts _so_ badly to double-freeing issues when
> the freelist has become corrupted due to an object being free'd and
> then modified is clearly very fragile and not great.
Yup that is why the debug options move the freepointer aft
On Mon, Oct 10, 2016 at 10:39 PM, Linus Torvalds
wrote:
>
> I guess I will have to double-check that the slub corruption is gone
> still with that fixed.
So I'm not getting any warnings now from SLUB debugging. So the
original bug seems to not have re-surfaced, and the registration bug
is gone, s
On Sun, Oct 9, 2016 at 8:41 PM, Linus Torvalds
wrote:
> This COMPLETELY UNTESTED patch tries to fix the nf_hook_entry code to do this.
>
> I repeat: it's ENTIRELY UNTESTED.
Gaah.
That patch was subtle garbage.
The "add to list" thing did this:
rcu_assign_pointer(entry->next, p);
On Mon, Oct 10, 2016 at 7:03 AM, Christoph Lameter wrote:
>
> Hmm.. Then get_freepointer_safe may not be ok. Should not trigger any
> faults.
So the reason seems to be that SLUB doesn't actually react well to
double-freeing bugs.
I'm not sure how to fix that. I think the optimistic load that SLU
Linus Torvalds writes:
> On Mon, Oct 10, 2016 at 9:28 AM, Linus Torvalds
> wrote:
>>
>> So as I already answered to Dave, I'm not actually sure that this was
>> the buggy code, or that my patch would make any difference at all.
>
> My patch does seem to fix things, and in fact the warning about
On Mon, Oct 10, 2016 at 9:28 AM, Linus Torvalds
wrote:
>
> So as I already answered to Dave, I'm not actually sure that this was
> the buggy code, or that my patch would make any difference at all.
My patch does seem to fix things, and in fact the warning about "hook
not found" now triggers.
So
On Mon, Oct 10, 2016 at 6:49 AM, Aaron Conole wrote:
>
> Okay, I'm looking it over. Sorry for the mess.
So as I already answered to Dave, I'm not actually sure that this was
the buggy code, or that my patch would make any difference at all.
I never got a good reproducer for the bug: I spent muc
On Sun, 9 Oct 2016, Linus Torvalds wrote:
> Hmm. When I enabled SLUB debugging, I also enabled DEBUG_PAGEALLOC,
> because "why not". But it turns out that that may have been a mistake,
> because it changes the very path that failed to no longer do that
> failing access (or rather, it does it as a
Linus Torvalds writes:
> On Sun, Oct 9, 2016 at 7:49 PM, Linus Torvalds
> wrote:
>>
>> There is one *correct* way to remove an entry from a singly linked
>> list, and it looks like this:
>>
>> struct entry **pp, *p;
>>
>> pp = &head;
>> while ((p = *pp) != NULL) {
>> if (righ
On Sun, Oct 9, 2016 at 7:49 PM, Linus Torvalds
wrote:
>
> There is one *correct* way to remove an entry from a singly linked
> list, and it looks like this:
>
> struct entry **pp, *p;
>
> pp = &head;
> while ((p = *pp) != NULL) {
> if (right_entry(p)) {
> *pp = p->n
On Sun, Oct 9, 2016 at 6:35 PM, Aaron Conole wrote:
>
> I was just about to build and test something similar:
So I haven't actually tested that one, but looking at the code, it
really looks very bogus. In fact, that code just looks like crap. It
does *not* do a proper "remove singly linked list e
Florian Westphal writes:
> Linus Torvalds wrote:
>> On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
>> wrote:
>> >
>> > Anyway, I don't think I can bisect it, but I'll try to narrow it down
>> > a *bit* at least.
>> >
>> > Not doing any more pulls on this unstable base, I've been puttering
>> >
Linus Torvalds wrote:
> On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
> wrote:
> >
> > Anyway, I don't think I can bisect it, but I'll try to narrow it down
> > a *bit* at least.
> >
> > Not doing any more pulls on this unstable base, I've been puttering
> > around in trying to clean up some st
On Sun, Oct 9, 2016 at 12:11 PM, Linus Torvalds
wrote:
>
> Anyway, I don't think I can bisect it, but I'll try to narrow it down
> a *bit* at least.
>
> Not doing any more pulls on this unstable base, I've been puttering
> around in trying to clean up some stupid printk logging issues
> instead.
On Sun, Oct 9, 2016 at 11:40 AM, Linus Torvalds
wrote:
>
> I'll continue with *just* SLUB debugging on, but I thought it was
> interesting how enabling more memory access debugging actually ends up
> changing some really subtle code.
Indeed, now with DEBUG_PAGEALLOC disabled, I got a crash again.
On Sat, Oct 8, 2016 at 11:05 PM, Linus Torvalds
wrote:
>
> Hmm. I've now gotten two oopses today, all at __kmalloc+0xc3/0x1f0,
> which seems to be the
>
> *(void **)(object + s->offset);
>
> in get_freepointer().
Actually, it's in "get_freepointer_safe()", it's just that without
DEBUG_PAGEALLOC
On Fri, Oct 7, 2016 at 3:20 PM, Al Viro wrote:
> splice stuff.
Hmm. I've now gotten two oopses today, all at __kmalloc+0xc3/0x1f0,
which seems to be the
*(void **)(object + s->offset);
in get_freepointer(). Because it started happening today, I'm inclined
to blame mainly stuff I merge
splice stuff. There are conflicts in lustre; proposed resolution
is in #merge-candidate (same as it is in linux-next). There's a bunch of
branches this cycle, both mine and from other folks and I'd rather send
pull requests separately. This one is the conversion of ->splice_read()
to ITE
In this one: d_move fixes (Eric), UFS fixes (me; locking is mostly sane
now, a bunch of bugs in error handling ought to be fixed), switch of sb_writers
to percpu rwsem (Oleg), superblock scalability (Josef and Dave), swapon(2) race
fix (Hugh). Please, pull from the usual place -
git://git.
In this pile: pathname resolution rewrite.
* recursion in link_path_walk() is gone.
* nesting limits on symlinks are gone (the only limit remaining is that
the total amount of symlinks is no more than 40, no matter how nested).
* "fast" (inline) symlinks are handled without leaving rcuwalk
On Thu 30-01-14 11:02:49, Kim Jaegeuk wrote:
> 2014-01-29 Jan Kara :
> > On Tue 28-01-14 19:26:08, Linus Torvalds wrote:
> >> On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote:
> >> > Assorted stuff; the biggest pile here is Christoph's ACL series.
> >> > Plus assorted cleanups and fixes all
On Tue, Jan 28, 2014 at 07:26:08PM -0800, Linus Torvalds wrote:
> but the mode we're changing to (and what ATTR_MODE guards) is actually
> attr->ia_mode, not inode->i_mode. And quite frankly, passing in
> inode->i_mode looks stupid, since we're already passing in the inode
> pointer, so that's just
2014-01-29 Jan Kara :
> On Tue 28-01-14 19:26:08, Linus Torvalds wrote:
>> On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote:
>> > Assorted stuff; the biggest pile here is Christoph's ACL series.
>> > Plus assorted cleanups and fixes all over the place... There will be
>> > another pile late
On Tue 28-01-14 19:26:08, Linus Torvalds wrote:
> On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote:
> > Assorted stuff; the biggest pile here is Christoph's ACL series.
> > Plus assorted cleanups and fixes all over the place... There will be
> > another pile later this week.
>
> The posix_
On Mon, Jan 27, 2014 at 6:25 AM, Al Viro wrote:
> Assorted stuff; the biggest pile here is Christoph's ACL series.
> Plus assorted cleanups and fixes all over the place... There will be
> another pile later this week.
The posix_acl_chmod() code looks wrong.
Not that it looked right befo
Hi Al,
On Mon, 27 Jan 2014 14:25:20 + Al Viro wrote:
>
> Assorted stuff; the biggest pile here is Christoph's ACL series.
> Plus assorted cleanups and fixes all over the place... There will be
> another pile later this week.
>
> There's a couple of conflicts - rcupdate.h and posix_acl
Assorted stuff; the biggest pile here is Christoph's ACL series.
Plus assorted cleanups and fixes all over the place... There will be
another pile later this week.
There's a couple of conflicts - rcupdate.h and posix_acl.h; proposed resolution
in vfs.git#conflict-resolution. Please, pull
Unfortunately, this merge window it'll have a be a lot of small piles - my
fault, actually, for not keeping #for-next in anything that would resemble
a sane shape ;-/ This pile: assorted fixes (the first 3 are -stable fodder,
IMO) and cleanups + %pd/%pD formats (dentry/file pathname, up to 4 last
Assorted stuff - cleaning namei.c up a bit, fixing ->d_name/->d_parent
locking violations, etc. The most visible changes here are death of
FS_REVAL_DOT (replaced with "has ->d_weak_revalidate()") and a new helper
getting from struct file to inode. Some bits of preparation to xattr
method
32 matches
Mail list logo
