The pull request you sent on Tue, 22 Sep 2020 22:29:08 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/805c6d3c19210c90c109107d189744e960eae025
Thank you!
--
Deet-doot-dot, I am a bot.
https://
No common topic, just several assorted fixes.
The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fixes
for you to f
On Fri, 20 Apr 2018 20:09:56 +0100 Al Viro wrote:
> On Fri, Apr 20, 2018 at 11:29:45AM -0700, Andrew Morton wrote:
> > On Fri, 20 Apr 2018 16:58:46 +0100 Al Viro wrote:
> >
> > > Assorted fixes. Some of that is only a matter with fault injection
> > > (broken handling of small allocation fai
On Fri, Apr 20, 2018 at 11:29:45AM -0700, Andrew Morton wrote:
> On Fri, 20 Apr 2018 16:58:46 +0100 Al Viro wrote:
>
> > Assorted fixes. Some of that is only a matter with fault injection
> > (broken handling of small allocation failure in various mount-related
> > places),
> > but the last
On Fri, 20 Apr 2018 16:58:46 +0100 Al Viro wrote:
> Assorted fixes. Some of that is only a matter with fault injection
> (broken handling of small allocation failure in various mount-related places),
> but the last one is a root-triggerable stack overflow, and combined with
> userns it get
Assorted fixes. Some of that is only a matter with fault injection
(broken handling of small allocation failure in various mount-related places),
but the last one is a root-triggerable stack overflow, and combined with
userns it gets really nasty ;-/
The following changes since commit 60c
untangle sys_close() abuses in xt_bpf, deal with register_shrinker()
failures in sget()
The following changes since commit d7ee946942bdd12394809305e3df05aa4c8b7b8f:
VFS: Handle lazytime in do_mount() (2017-12-09 20:16:33 -0500)
are available in the git repository at:
git://git.kerne
A couple of fixes; a leak in mntns_install() caught by Andrei
(this cycle regression) + d_invalidate() softlockup fix - that had
been reported by a bunch of people lately, but the problem is pretty
old.
The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:
Linux 4
On Sat, Apr 15, 2017 at 09:51:40AM -0700, Linus Torvalds wrote:
> On Fri, Apr 14, 2017 at 11:41 PM, Vegard Nossum
> wrote:
> >
> > I'm seeing the same memfd_create/name_to_handle_at/path_lookupat
> > use-after-free that Dmitry was seeing here:
>
> Ok, see if that is gone in current git with comm
On Fri, Apr 14, 2017 at 11:41 PM, Vegard Nossum wrote:
>
> I'm seeing the same memfd_create/name_to_handle_at/path_lookupat
> use-after-free that Dmitry was seeing here:
Ok, see if that is gone in current git with commit c0eb027e5aef ("vfs:
don't do RCU lookup of empty pathnames")
On 9 April 2017 at 07:40, Al Viro wrote:
>
> The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf:
>
> Linux 4.11-rc5 (2017-04-02 17:23:54 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
>
> for
On Tue, Apr 11, 2017 at 2:02 PM, Andreas Dilger wrote:
> On Apr 11, 2017, at 12:48 AM, Al Viro wrote:
>>
>> It's more obscure than I would like, and can grow into a bug one day, but...
>> nd_jump_root() can only return non-zero if you have LOOKUP_RCU.
>
> So possibly a comment like the following
On Apr 11, 2017, at 12:48 AM, Al Viro wrote:
> On Mon, Apr 10, 2017 at 11:10:19PM -0700, Linus Torvalds wrote:
>
>> It looks odd because the lock part is
>>
>>if (flags & LOOKUP_RCU)
>>rcu_read_lock();
>>
>> ie it's locked conditionally, and the code in b
On Mon, Apr 10, 2017 at 11:10:19PM -0700, Linus Torvalds wrote:
> It looks odd because the lock part is
>
> if (flags & LOOKUP_RCU)
> rcu_read_lock();
>
> ie it's locked conditionally, and the code in between does not seem to
> return every time LOOKUP_RCU
Hey Al,
mind looking at fs/namei,c line 2186:
if (likely(!nd_jump_root(nd)))
return s;
nd->root.mnt = NULL;
--> rcu_read_unlock(); <--
return ERR_PTR(-ECHILD);
because that rcu_read_unlock() looks odd.
It look
The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf:
Linux 4.11-rc5 (2017-04-02 17:23:54 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
for you to fetch changes up to a8e28440016bfb23bec266c4c66eac
On Mon, 2017-04-03 at 01:00 -0500, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Sun, Apr 02, 2017 at 05:58:41PM -0700, Linus Torvalds wrote:
> >
> > > I had to go and double-check that "DCACHE_DIRECTORY_TYPE" is what
> > > d_can_lookup() actually checks, so _that_ part is perhaps a bit
>
On Mon, 2017-04-03 at 01:00 -0500, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Sun, Apr 02, 2017 at 05:58:41PM -0700, Linus Torvalds wrote:
> >
> > > I had to go and double-check that "DCACHE_DIRECTORY_TYPE" is what
> > > d_can_lookup() actually checks, so _that_ part is perhaps a bit
>
On Mon, Apr 03, 2017 at 01:00:56AM -0500, Eric W. Biederman wrote:
> Refereshing my memory. d_automount mounts things and is what
> is used for nfs referrals. d_manage blocks waiting for
> an automounts to complete or expire. follow_down just calls d_manage,
> follow_manage calls both d_manage
Al Viro writes:
> On Sun, Apr 02, 2017 at 05:58:41PM -0700, Linus Torvalds wrote:
>
>> I had to go and double-check that "DCACHE_DIRECTORY_TYPE" is what
>> d_can_lookup() actually checks, so _that_ part is perhaps a bit
>> subtle, and might be worth noting in that comment that you edited.
>>
>>
On Sun, Apr 02, 2017 at 05:58:41PM -0700, Linus Torvalds wrote:
> I had to go and double-check that "DCACHE_DIRECTORY_TYPE" is what
> d_can_lookup() actually checks, so _that_ part is perhaps a bit
> subtle, and might be worth noting in that comment that you edited.
>
> So the real "rule" ends up
On Sun, Apr 2, 2017 at 5:43 PM, Al Viro wrote:
>
> Do you have any objections against the following (still untested) variant?
> I don't see any point in checking for flags & LOOKUP_RCU in case of !*s -
> flags is in register at that point, so...
Looks sane to me.
I had to go and double-check tha
On Mon, Apr 03, 2017 at 01:30:45AM +0100, Al Viro wrote:
> Currently true and almost certainly will remain so. Point taken, what you
> are suggesting is better. Actually, the invariant to watch for is
> "no d_can_lookup() withtout DCACHE_RCUACCESS" and that we can trivially
> enforce by one-line
On Sun, Apr 02, 2017 at 05:10:08PM -0700, Linus Torvalds wrote:
> On Sun, Apr 2, 2017 at 4:59 PM, Linus Torvalds
> wrote:
> > On Sun, Apr 2, 2017 at 10:01 AM, Al Viro wrote:
> >> statx followup fixes, fix for a nasty corner case in path_init()
> >> leaving path.dentry in RCU mode pointing
On Sun, Apr 02, 2017 at 04:59:10PM -0700, Linus Torvalds wrote:
> On Sun, Apr 2, 2017 at 10:01 AM, Al Viro wrote:
> > statx followup fixes, fix for a nasty corner case in path_init()
> > leaving path.dentry in RCU mode pointing to a dentry without
> > DCACHE_RCUACCESS
> > and a fix for st
On Sun, Apr 2, 2017 at 4:59 PM, Linus Torvalds
wrote:
> On Sun, Apr 2, 2017 at 10:01 AM, Al Viro wrote:
>> statx followup fixes, fix for a nasty corner case in path_init()
>> leaving path.dentry in RCU mode pointing to a dentry without DCACHE_RCUACCESS
>> and a fix for stack-smashing on a
On Sun, Apr 2, 2017 at 10:01 AM, Al Viro wrote:
> statx followup fixes, fix for a nasty corner case in path_init()
> leaving path.dentry in RCU mode pointing to a dentry without DCACHE_RCUACCESS
> and a fix for stack-smashing on alpha.
These were apparently committed minutes before sendin
statx followup fixes, fix for a nasty corner case in path_init()
leaving path.dentry in RCU mode pointing to a dentry without DCACHE_RCUACCESS
and a fix for stack-smashing on alpha.
The following changes since commit c02ed2e75ef4c74e41e421acb4ef1494671585e8:
Linux 4.11-rc4 (2017-03-26 1
A couple more of d_walk()/d_subdirs reordering fixes (stable fodder; ought to
solve that crap for good) and a fix for a brown paperbag bug in
d_alloc_parallel() (this cycle).
The following changes since commit 1607f09c226d1378439c411b020042750338:
coredump: fix dumping through pipes (2016-0
Fixes for crap of assorted ages: EOPENSTALE one is 4.2+, autofs
one is 4.6, d_walk - 3.2+, atomic_open() and coredump ones are this window
regressions.
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available i
work.lookups followups - update docs, restore killability of
the places that used to take ->i_mutex killably now that we have
down_write_killable() merged. Additionally, it turns out that I missed
a prereq for security_d_instantiate() stuff - ->getxattr() wasn't the
only thing that could b
The following changes since commit 7ae8fd0351f912b075149a1e03a017be8b903b9a:
fs/pnode.c: treat zero mnt_group_id-s as unequal (2016-02-20 00:15:52 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
for you to fetch changes up
A couple of fixes for bugs caught while digging in fs/namei.c.
The first one is this cycle regression, the second is 3.11 and later.
Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (2):
namei: d_is_negative()
On 26 September 2014 23:28, Joachim Eastwood wrote:
> On 26 September 2014 22:58, Al Viro wrote:
>> On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote:
>>> On 14 September 2014 21:47, Al Viro wrote:
>>> > double iput() on failure exit in lustre, racy removal of spliced dentries
>>
On 26 September 2014 22:58, Al Viro wrote:
> On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote:
>> On 14 September 2014 21:47, Al Viro wrote:
>> > double iput() on failure exit in lustre, racy removal of spliced dentries
>> > from ->s_anon in __d_materialise_dentry() plus a bunch o
On Fri, Sep 26, 2014 at 10:46:14PM +0200, Joachim Eastwood wrote:
> On 14 September 2014 21:47, Al Viro wrote:
> > double iput() on failure exit in lustre, racy removal of spliced dentries
> > from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU
> > pathwalk
> > fixes. Please,
On 14 September 2014 21:47, Al Viro wrote:
> double iput() on failure exit in lustre, racy removal of spliced dentries
> from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU
> pathwalk
> fixes. Please, pull from the usual place -
> git://git.kernel.org/pub/scm/linux/kernel/git/
On 14 September 2014 21:47, Al Viro wrote:
> double iput() on failure exit in lustre, racy removal of spliced dentries
> from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU
> pathwalk
> fixes. Please, pull from the usual place -
> git://git.kernel.org/pub/scm/linux/kernel/git/
double iput() on failure exit in lustre, racy removal of spliced dentries
from ->s_anon in __d_materialise_dentry() plus a bunch of assorted RCU pathwalk
fixes. Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (5):
[f
Hi Linus,
here's a userspace triggered vfsmount leak fix, and a compile warning
fix for 3.16:
The following changes since commit 82e13c71bc655b6dc7110da4e164079dadb44892:
Merge branch 'for-3.16' of git://linux-nfs.org/~bfields/linux (2014-07-23
17:55:11 -0700)
are available in the git repos
On Sun, Mar 30, 2014 at 03:39:33PM -0700, Linus Torvalds wrote:
> On Sun, Mar 30, 2014 at 1:55 PM, Al Viro wrote:
> >
> > Commit ID of that branch should be 7fc5aaa083922420e2dec5d985420cb5f959b1ce;
> > diffs are the same as what sat there since last Sunday, commit messages
> > got updated a bit.
On Sun, Mar 30, 2014 at 1:55 PM, Al Viro wrote:
>
> Commit ID of that branch should be 7fc5aaa083922420e2dec5d985420cb5f959b1ce;
> diffs are the same as what sat there since last Sunday, commit messages
> got updated a bit.
Ugh. You have apparently rebased the parts that I already pulled too,
whi
On Sun, Mar 30, 2014 at 09:33:07PM +0100, Al Viro wrote:
> Al, finally back to life and digging himself from under ~5e3 mails in l-k
> mailbox...
Several fixes; a couple of fdget_pos()-related ones from Eric Biggers,
prepend_name() fix (bug was reported by many people, Imre and Jan being t
On Wed, Mar 26, 2014 at 01:55:51PM -0700, Linus Torvalds wrote:
> On Wed, Mar 26, 2014 at 9:36 AM, Sedat Dilek wrote:
> >
> > Looking at [1] you did not pull-in the new changes.
> > Are you waiting for a new pull-request?
>
> Yeah, with the top commit updated, I'd like to make sure I get the righ
On Wed, Mar 26, 2014 at 9:55 PM, Linus Torvalds
wrote:
> On Wed, Mar 26, 2014 at 9:36 AM, Sedat Dilek wrote:
>>
>> Looking at [1] you did not pull-in the new changes.
>> Are you waiting for a new pull-request?
>
> Yeah, with the top commit updated, I'd like to make sure I get the right pull.
>
A
On Wed, Mar 26, 2014 at 9:36 AM, Sedat Dilek wrote:
>
> Looking at [1] you did not pull-in the new changes.
> Are you waiting for a new pull-request?
Yeah, with the top commit updated, I'd like to make sure I get the right pull.
Linus
--
To unsubscribe from this list: send the
On Tue, Mar 25, 2014 at 1:46 AM, Linus Torvalds
wrote:
> Just to clarify: the current vfs tree from Al works for you, no new issues?
>
> I was delaying the release first a day, and now I think I'll just do
> an rc8 after all (and do the final 3.14 next weekend), but I'd like to
> be sure what the
On Mon, Mar 24, 2014 at 11:58 PM, Imre Deak wrote:
>> [...]
>> Shortlog:
>> Al Viro (6):
>> make prepend_name() work correctly when called with negative
> *buflen
>
> A proper attribution for the above fix would have been nice. Tracking
> down the bug was the main thing after all:
>
> https:
Just to clarify: the current vfs tree from Al works for you, no new issues?
I was delaying the release first a day, and now I think I'll just do
an rc8 after all (and do the final 3.14 next weekend), but I'd like to
be sure what the status of Al's tree is.
Al, can you send a new pull request with
> [...]
> Shortlog:
> Al Viro (6):
> make prepend_name() work correctly when called with negative
*buflen
A proper attribution for the above fix would have been nice. Tracking
down the bug was the main thing after all:
https://lkml.org/lkml/2014/3/12/620
--Imre
--
To unsubscribe from this
On Sun, Mar 23, 2014 at 6:01 PM, Linus Torvalds
wrote:
> On Sun, Mar 23, 2014 at 9:45 AM, Al Viro wrote:
>>
>> It's easier to skip checking the overflow on prepend() of "\0" in the
>> beginning of the whole thing and just let the next operation to fail.
>> That's where the corner case comes from.
On Sun, Mar 23, 2014 at 9:45 AM, Al Viro wrote:
>
> It's easier to skip checking the overflow on prepend() of "\0" in the
> beginning of the whole thing and just let the next operation to fail.
> That's where the corner case comes from.
Ok, I'll buy the first four commits. Let's wait for Sedat's
On Sun, Mar 23, 2014 at 03:35:05PM +, Al Viro wrote:
> On Sun, Mar 23, 2014 at 11:57:16AM +0100, Sedat Dilek wrote:
>
> > Your branch on top of Linux v3.14-rc7-66-g774868c7094d is freezing my
> > Ubuntu/precise AMD64 (WUBI) system when running LTP.
>
> Which test?
Argh... I see what's going
On Sun, Mar 23, 2014 at 09:36:28AM -0700, Linus Torvalds wrote:
> On Sun, Mar 23, 2014 at 12:16 AM, Al Viro wrote:
> > Several fixes; first 4 commits are obvious fixes (a couple
> > of fdget_pos()-related ones from Eric Biggers, prepend_name() fix, missing
> > checks for false negatives fr
On Sun, Mar 23, 2014 at 12:16 AM, Al Viro wrote:
> Several fixes; first 4 commits are obvious fixes (a couple
> of fdget_pos()-related ones from Eric Biggers, prepend_name() fix, missing
> checks for false negatives from __lookup_mnt() in fs/namei.c)
I'm not seeing the obvious fix in the
On Sun, Mar 23, 2014 at 11:57:16AM +0100, Sedat Dilek wrote:
> Your branch on top of Linux v3.14-rc7-66-g774868c7094d is freezing my
> Ubuntu/precise AMD64 (WUBI) system when running LTP.
Which test?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Several fixes; first 4 commits are obvious fixes (a couple
of fdget_pos()-related ones from Eric Biggers, prepend_name() fix, missing
checks for false negatives from __lookup_mnt() in fs/namei.c), followed
by 4 commits dealing with the bug found by Max last week - switch of
mnt_hash to hlis
sget() one is a long-standing bug and will need to go into
-stable (in fact, it had been originally caught in RHEL6), the
other two are 3.11-only. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (2):
allow O_TMPFILE to work wi
Several fixes for bugs caught while looking through f_pos (ab)users.
Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (3):
mconsole: we'd better initialize pos before passing it to vfs_read()...
splice: don't pas
-stable fodder; assorted deadlock fixes. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (3):
Don't bother with redoing rw_verify_area() from default_file_splice_from()
Nest rename_lock inside vfsmount_lock
vt: synchronize
60 matches
Mail list logo
