On Thu, Sep 19, 2024 at 04:14:05AM +0530, Neeraj Upadhyay wrote:
> On 9/18/2024 12:48 PM, Linus Torvalds wrote:
> > On Tue, 17 Sept 2024 at 16:34, Boqun Feng wrote:
> >>
> >> This series introduces hazard pointers [1] to kernel space. A TL;DR
> >> description of hazard pointers is "a scalable refc
probe lookup will be sufficient, or maybe some
other hackery is viable without messing with fences in
vma_start_write.
--
Mateusz Guzik
On Thu, Aug 15, 2024 at 10:45:45AM -0700, Suren Baghdasaryan wrote:
> >From all the above, my understanding of your objection is that
> checking mmap_lock during our speculation is too coarse-grained and
> you would prefer to use the VMA seq counter to check that the VMA we
> are working on is unch
On Tue, Aug 13, 2024 at 08:36:03AM -0700, Suren Baghdasaryan wrote:
> On Mon, Aug 12, 2024 at 11:18 PM Mateusz Guzik wrote:
> >
> > On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote:
> > > Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely a
On Mon, Aug 12, 2024 at 09:29:17PM -0700, Andrii Nakryiko wrote:
> Now that files_cachep is SLAB_TYPESAFE_BY_RCU, we can safely access
> vma->vm_file->f_inode lockless only under rcu_read_lock() protection,
> attempting uprobe look up speculatively.
>
> We rely on newly added mmap_lock_speculation
On Mon, Aug 12, 2024 at 09:29:16PM -0700, Andrii Nakryiko wrote:
> Add RCU protection for file struct's backing memory by adding
> SLAB_TYPESAFE_BY_RCU flag to files_cachep. This will allow to locklessly
> access struct file's fields under RCU lock protection without having to
> take much more expe
On Sun, Jun 23, 2024 at 3:22 AM Xi Ruoyao wrote:
>
> On Sun, 2024-06-23 at 03:07 +0200, Mateusz Guzik wrote:
> > On Sun, Jun 23, 2024 at 2:59 AM Xi Ruoyao wrote:
> > >
> > > On Sat, 2024-06-22 at 15:41 -0700, Linus Torvalds wrote:
> > >
> > > >
int ret;
struct filename *name;
+ if (flags == AT_EMPTY_PATH && filename == NULL)
+ return do_statx_by_fd(...);
+
name = getname_flags(filename, getname_statx_lookup_flags(flags));
ret = do_statx(dfd, name, flags, mask, buffer);
putname(name);
and so on
Personally I would prefer if fstatx was added instead, fwiw most
massaging in the area will be the same regardless.
--
Mateusz Guzik
+cc Linus
On Sat, Jun 22, 2024 at 06:56:08PM +0800, Xi Ruoyao wrote:
> It's cheap to check if the path is empty in the userspace, but expensive
> to check if a userspace string is empty from the kernel. So using statx
> and AT_EMPTY_PATH to implement fstat is slower than a "native" fstat
> call.
adding the spinlock for args. The downside is growth of mm_struct.
i.e. the code can be refactored to just hold the lock and relock only if
necessary (unable to copy to user without faulting)
--
Mateusz Guzik
set_mm(). Since we
> already have dedicated lock to protect them, it is safe to change back
> to down_read.
>
> Signed-off-by: Yang Shi
> Cc: Alexey Dobriyan
> Cc: Michal Hocko
> Cc: Matthew Wilcox
> Cc: Mateusz Guzik
> Cc: Cyrill Gorcunov
> ---
> v1 --&
schedule_work(work);
}
}
+#endif
/*
* Unnamed block devices are dummy devices used by virtual
--
Mateusz Guzik
get_task_umask locks/unlocks the task on its own. The only caller does
the same thing immediately after.
Utilize the fact the task has to be locked anyway and just do it once.
Since there are no other users and the code is short, fold it in.
Signed-off-by: Mateusz Guzik
---
fs/proc/array.c
alloc_fd
__close_fd
fd_install
__close_fd will either see a NULL pointer and return -EBADF or will see
an installed pointer and proceed with the close.
Your proposed patch seems to be buggy in this regard.
You call idr_remove, which from what I understand will free up the slot
no matter what. You only detect an error based on whether there was a
non-NULL pointer there or not. If so, fd_install can proceed to play
with a deallocated entry.
--
Mateusz Guzik
in order to keep the sb
locked the whole time.
The first patch moves sb iteration found in emergency remount to a
dedicated func for code reuse. This patch patch is a no-op.
The second employs factored out code to do both bdev and sb thaws.
Mateusz Guzik (2):
vfs: factor sb iteration out
is
employed.
Signed-off-by: Mateusz Guzik
---
fs/buffer.c| 25 +
fs/super.c | 44 ++--
include/linux/fs.h | 1 +
3 files changed, 44 insertions(+), 26 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 170df85
The intent is to reduce code duplication with other code
iterating the list.
No functional changes.
Signed-off-by: Mateusz Guzik
---
fs/super.c | 61 -
1 file changed, 36 insertions(+), 25 deletions(-)
diff --git a/fs/super.c b/fs
ot be enforced.
I don't see any benefits from sleeping over locking and not sleeping makes
the function slightly nicer.
Mateusz Guzik (2):
vfs: stop clearing close on exec when closing a fd
vfs: grab the lock instead of blocking in __fd_install during resizing
Documentation/filesystems/po
removed.
Signed-off-by: Mateusz Guzik
---
Documentation/filesystems/porting | 4
fs/file.c | 11 +++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/Documentation/filesystems/porting
b/Documentation/filesystems/porting
index 93e0a24..17bb4dc
Codepaths allocating a fd always make sure the bit is set/unset
depending on flags, thus clearing on close is redundant.
Signed-off-by: Mateusz Guzik
---
fs/file.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/file.c b/fs/file.c
index 1fc7fbb..9d047bd 100644
--- a/fs/file.c
+++ b/fs
On Sun, Feb 05, 2017 at 11:22:12PM -0800, Cong Wang wrote:
> On Tue, Jan 31, 2017 at 10:14 AM, Mateusz Guzik wrote:
> > On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote:
> >> Mind being more specific?
> >
> > Consider 2 threads which bind the same so
On Mon, Jan 30, 2017 at 10:44:03PM -0800, Cong Wang wrote:
> On Thu, Jan 26, 2017 at 10:41 PM, Mateusz Guzik wrote:
> > On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote:
> >> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote:
> >> > Currently the f
On Mon, Jan 30, 2017 at 07:41:59PM +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers use-after-free in timerfd_remove_cancel:
> https://gist.githubusercontent.com/dvyukov/202576d437c84ffbbe52e9ccd77e1b44/raw/5562bff8626a73627157331ea2b837f59080ac84/gistfile1.txt
>
> BUG: KAS
On Thu, Jan 26, 2017 at 09:11:07PM -0800, Cong Wang wrote:
> On Thu, Jan 26, 2017 at 3:29 PM, Mateusz Guzik wrote:
> > On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote:
> >> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote:
> >> > On Fri, Dec 9, 2
On Tue, Jan 17, 2017 at 01:21:48PM -0800, Cong Wang wrote:
> On Mon, Jan 16, 2017 at 1:32 AM, Dmitry Vyukov wrote:
> > On Fri, Dec 9, 2016 at 7:41 AM, Al Viro wrote:
> >> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote:
> >>
> >>> > Why do we do autobind there, anyway, and why is it con
sumers to use *_bdev variants
- somewhat cosmetic, introduce nesting limit for freezes (say 2048 or
whatever, just to have something)
The ioctl used use freeze_bdev but this was changed with 18e9e5104fcd
"Introduce freeze_super and thaw_super for the fsfreeze ioctl" which
cites btrfs as the reason for freeze_super as opposed to freeze_bdev.
CC'ing the author for comments.
--
Mateusz Guzik
gt; + return error;
> }
> EXPORT_SYMBOL(thaw_bdev);
>
Apparently this never got in.
The bug is still there, reproducible with mere:
echo j > /proc/sysrq-trigger
--
Mateusz Guzik
27;t know this code. Perhaps it will be perfectly fine performance wise to
just drop out of RCU lookup in this case.
--
Mateusz Guzik
f linux-next.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I think this is fixed with:
commit e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8
Author: Vegard Nossum
Date: Mon Aug 22 12:47:43 2016 +0200
bdev: fix NULL pointer dereference
in mainline. The commit is absent in linux-next.
--
Mateusz Guzik
string then, like in case of smaps.
> >
>
> Thanks for the testing Jacek!
>
> I had a look around the corresponding smaps code, but I'm not seeing any
> checks, do you know where that check actually is made?
>
See m_start in f/sproc/task_mmu.c. It not only check for non-null mm,
but also tries to bump ->mm_users and only then proceeds to walk the mm.
--
Mateusz Guzik
On Tue, Aug 30, 2016 at 02:50:21PM -0400, Richard Guy Briggs wrote:
> On 2016-08-23 16:20, Mateusz Guzik wrote:
> > audit_exe_compare directly accesses mm->exe_file without making sure the
> > object is stable. Fixing it using current primitives results in
> > pa
On Tue, Aug 23, 2016 at 04:48:13PM +0200, Oleg Nesterov wrote:
> On 08/23, Mateusz Guzik wrote:
> >
> > +struct file *get_task_exe_file(struct task_struct *task)
> > +{
> > + struct file *exe_file = NULL;
> > + struct mm_struct *mm;
> > +
> &g
v1:
* removed an unused 'out' label which crept in
Mateusz Guzik (2):
mm: introduce get_task_exe_file
audit: fix exe_file access in audit_exe_compare
fs/proc/base.c | 7 +--
include/linux/mm.h | 1 +
kernel/audit_watch.c | 8 +---
kernel/fork.
For more convenient access if one has a pointer to the task.
As a minor nit take advantage of the fact that only task lock + rcu are
needed to safely grab ->exe_file. This saves mm refcount dance.
Use the helper in proc_exe_link.
Signed-off-by: Mateusz Guzik
Acked-by: Konstantin Khlebni
Prior to the change the function would blindly deference mm, exe_file
and exe_file->f_inode, each of which could have been NULL or freed.
Use get_task_exe_file to safely obtain stable exe_file.
Signed-off-by: Mateusz Guzik
Acked-by: Konstantin Khlebnikov
---
kernel/audit_watch.c
Prior to the change the function would blindly deference mm, exe_file
and exe_file->f_inode, each of which could have been NULL or freed.
Use get_task_exe_file to safely obtain stable exe_file.
Signed-off-by: Mateusz Guzik
---
kernel/audit_watch.c | 8 +---
1 file changed, 5 inserti
audit_exe_compare directly accesses mm->exe_file without making sure the
object is stable. Fixing it using current primitives results in
partially duplicating what proc_exe_link is doing.
As such, introduce a trivial helper which can be used in both places and
fix the func.
Mateusz Guzik
For more convenient access if one has a pointer to the task.
As a minor nit take advantage of the fact that only task lock + rcu are
needed to safely grab ->exe_file. This saves mm refcount dance.
Use the helper in proc_exe_link.
Signed-off-by: Mateusz Guzik
---
fs/proc/base.c |
;s_dev;
> - rcu_read_unlock();
> + fput(exe_file);
> return audit_mark_compare(mark, ino, dev);
> }
I think this works but I have a better idea. This basically duplicates a
part of proc_exe_link and does unnecessary work.
Instead, one can introduce get_task_exe_file. task_lo
t show_smaps() way.
>
> mm = get_task_mm(priv->task) is needed to iterate through all of the
> mappings. Is there a preferable way of doing that?
In the other part of the mail I stated smaps goes to proc_maps_open
which has:
priv->mm = proc_mem_open(inode, PTRACE_MODE_READ);
This gives you stable access to mm and all needed permission checks.
Then, in the read routine you can just:
if (!atomic_inc_not_zero(&mm->mm_users))
goto thats_it;
See smaps routines or e.g. environ_read.
--
Mateusz Guzik
if (!priv->task) {
> + kfree(priv->mss);
> + kfree(priv);
> + return -ESRCH;
> + }
> +
> + ret = single_open(file, totmaps_proc_show, priv);
> + if (ret) {
> + put_task_struct(priv->task);
> + kfree(priv->mss);
> + kfree(priv);
> + }
> + }
> + return ret;
> +}
> +
--
Mateusz Guzik
r application
this translates into kilobytes of memory which would have to allocated
just to hold it, sounds like a non-starter to me.
--
Mateusz Guzik
Modifying get_mm_exe_file to retry is trivial and in effect never return
NULL is trivial. With arbitrary number of changes allowed this may
require some cond_resched() or something.
For comments I cc'ed Richard Guy Briggs, who is both an audit person and
the author of audit_exe_compare.
--
Mateusz Guzik
en if not, can it
mount procfs and use /proc/pid/root of processes outside of said
container?
The spawned process should be subject to all limitations imposed on the
container (which may mean it just must be in the container).
--
Mateusz Guzik
The commit 25841ee0e9d2a ("Validate lockless_dereference() is used on a
pointer type") added a second use of the parameter to the macro.
This leads to trouble with consumers which use arguments with side
effects.
Instead, reuse the value which was read the first time.
Signed-off-b
e(p) \
({ \
- __maybe_unused const void * const _p2 = p; \
typeof(p) _p1 = READ_ONCE(p); \
+ __maybe_unused const void * const _p2 = _p1; \
smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
(_p1); \
})
--
Mateusz Guzik
uce
->pos field for this purpose since ->written was already reused.
Fixes: a00839395103 ("get rid of coredump_params->written").
Reported-by: Zbigniew Jędrzejewski-Szmek
Signed-off-by: Mateusz Guzik
Reviewed-by: Omar Sandoval
---
arch/powerpc/platforms/cell/spufs/coredu
tore explicit tracking of the offset in coredump_params. Introduce
->pos field for this purpose since ->written was already reused.
Reported-by: Zbigniew Jędrzejewski-Szmek
Signed-off-by: Mateusz Guzik
---
arch/powerpc/platforms/cell/spufs/coredump.c | 2 +-
fs/binfmt_elf.c
Commit-ID: 4afd0565552c87f23834db9121dd9cf6955d0b43
Gitweb: http://git.kernel.org/tip/4afd0565552c87f23834db9121dd9cf6955d0b43
Author: Mateusz Guzik
AuthorDate: Tue, 10 May 2016 22:56:43 +0200
Committer: Ingo Molnar
CommitDate: Fri, 13 May 2016 13:50:15 +0200
x86/arch_prctl/64
On Tue, May 10, 2016 at 01:58:24PM -0700, Andy Lutomirski wrote:
> On Tue, May 10, 2016 at 1:56 PM, Mateusz Guzik wrote:
> > This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization"
>
> Indeed. How did that survive lockdep?
>
lockdep_sys_exit on
This fixes 731e33e39a5b95ad770 "Remove FSBASE/GSBASE < 4G optimization"
Signed-off-by: Mateusz Guzik
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 4285f6a..6b16c36 100644
-
d:
- do_prlimit: stop taking tasklist_lock at all and only lock sighand when
necessary
- proc_pid_limits: lock group leader in order to obtain a stable copy
Signed-off-by: Mateusz Guzik
---
fs/proc/base.c | 6 ++
kernel/sys.c | 22 ++
0x0800 /* being looked up
(with parent locked shared) */
Verified with switching one to 0x1000 and the warning went away.
--
Mateusz Guzik
|| !mm->env_end)
> return 0;
>
> page = (char *)__get_free_page(GFP_TEMPORARY);
In this case get_cmdline in mm/util.c should also be patched for
completness. It tests for arg_end, but later accesses env_end.
--
Mateusz Guzik
struct sb_writers s_writers;
> + int s_freezers;
>
> char s_id[32]; /* Informational
> name */
> u8 s_uuid[16]; /* UUID */
> --
> 2.8.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Mateusz Guzik
such, maybe the feature you are looking for would count how many
times the fs is frozen.
--
Mateusz Guzik
On Wed, Feb 17, 2016 at 02:15:24PM -0600, Eric W. Biederman wrote:
> Mateusz Guzik writes:
> > On Tue, Feb 16, 2016 at 07:33:39PM +0800, Zhao Lei wrote:
> >> For container based on namespace design, it is good to allow
> >> each container keeping their own coredump set
ize, just have a
buffer on the stack.
Finally, the code setting it could simply xchg the pointer to avoid
locks if there is no good lock to be taken here, and then kfree_rcu the
old buffer.
Just my $0,03.
--
Mateusz Guzik
The code could leak xattrs->lock on error.
Problem introduced with 786534b92f3ce68f4 "tmpfs: listxattr should
include POSIX ACL xattrs".
Signed-off-by: Mateusz Guzik
---
fs/xattr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/xattr.c b/fs/xattr.c
0x460
[ 106.636380] [] alloc_pages_vma+0x28b/0x2d0
[ 106.648440] [] do_huge_pmd_anonymous_page+0x13e/0x540
[ 106.660497] [] handle_mm_fault+0x7e4/0x980
[ 106.672585] [] ? handle_mm_fault+0x59/0x980
[ 106.684595] [] __do_page_fault+0x1cd/0x470
[ 106.696524] [] trace_do_page_fault+0x6e/0x250
[ 106.708477] [] do_async_page_fault+0x1a/0xb0
[ 106.720407] [] async_page_fault+0x28/0x30
--
Mateusz Guzik
-by: Milos Vyletel
Signed-off-by: Mateusz Guzik
---
drivers/tty/tty_io.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 892c923..1b10469 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
On Wed, Jan 06, 2016 at 03:14:22PM +0530, Anshuman Khandual wrote:
> On Wed, Jan 6, 2016 at 10:32 AM, Mateusz Guzik wrote:
> > Only functions doing more than one read are modified. Consumeres
> > happened to deal with possibly changing data, but it does not seem
> > like a
On Wed, Jan 06, 2016 at 03:05:09PM +0530, Anshuman Khandual wrote:
> On Wed, Jan 6, 2016 at 10:32 AM, Mateusz Guzik wrote:
> > The code was taking the semaphore for reading, which does not protect
> > against readers nor concurrent modifications.
>
> (down/up)_read doe
Number of fds is already known based on passed list.
No functional changes.
Signed-off-by: Mateusz Guzik
---
fs/select.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/select.c b/fs/select.c
index 0155473..79d0d49 100644
--- a/fs/select.c
+++ b/fs/select.c
they seem to be fine despite possible modificaton.
Signed-off-by: Mateusz Guzik
---
kernel/sys.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 6af9212..78947de 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -18
Only functions doing more than one read are modified. Consumeres
happened to deal with possibly changing data, but it does not seem
like a good thing to rely on.
Signed-off-by: Mateusz Guzik
---
fs/proc/base.c | 13 ++---
mm/util.c | 16
2 files changed, 22
o benefit from similar
treatment and are left untouched.
Mateusz Guzik (2):
prctl: take mmap sem for writing to protect against others
proc read mm's {arg,env}_{start,end} with mmap semaphore taken.
fs/proc/base.c | 13 ++---
kernel/sys.c | 20 ++--
mm/util.c
ount point */
> seq_puts(m, " mounted on ");
> /* mountpoints outside of chroot jail will give SEQ_SKIP on this */
> err = seq_path_root(m, &mnt_path, &p->root, " \t\n\\");
> if (err)
> goto out;
>
I would sugg
in this case without serious
tinkering. In fact this code cannot realiably work without weird
locking. By the time anon_inode_getfd returns, the file could have been
closed by a different thread.
What you want instead is anon_inode_getfile. See perf_event_open for an
example how to use it.
--
Mateusz
is populated.
Signed-off-by: Mateusz Guzik
---
fs/file.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 6c672ad..103d931 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -365,7 +365,7 @@ out:
return NULL
On Mon, Apr 13, 2015 at 11:39:01AM +1000, James Morris wrote:
> On Wed, 8 Apr 2015, Mateusz Guzik wrote:
>
> > This is still a problem. Any feedback about the patch?
> >
>
> I'd like to see feedback from vfs folk (Al).
>
Ping? Are there any concerns with the
way which can
interrupt the loop upcoming loop before it gets the chance to set error.
--
Mateusz Guzik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Apr 21, 2015 at 09:59:28PM -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Mateusz Guzik reported :
>
> Currently obtaining a new file descriptor results in locking fdtable
> twice - once in order to reserve a slot and second time to fill it.
>
>
On Tue, Apr 21, 2015 at 02:06:53PM -0700, Eric Dumazet wrote:
> On Tue, 2015-04-21 at 22:12 +0200, Mateusz Guzik wrote:
>
> > in dup_fd:
> >for (i = open_files; i != 0; i--) {
> > struct file *f = *old_fds++;
&
On Tue, Apr 21, 2015 at 10:06:24PM +0200, Mateusz Guzik wrote:
> On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:
> > On Mon, 2015-04-20 at 13:49 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> > > > On Mon, 2015
On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:
> On Mon, 2015-04-20 at 13:49 -0700, Eric Dumazet wrote:
> > On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-04-20 at 17:10 +0200, Mateusz Guzik wrote:
> > >
> > > > So
On Mon, Apr 20, 2015 at 03:43:26PM +0200, Mateusz Guzik wrote:
> On Mon, Apr 20, 2015 at 03:06:33PM +0200, Mateusz Guzik wrote:
> > On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> > > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> > >
>
On Mon, Apr 20, 2015 at 03:06:33PM +0200, Mateusz Guzik wrote:
> On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> >
> > > I would say this makes the use of seq counter impossible. Even if we
>
On Sat, Apr 18, 2015 at 12:41:38PM -0700, Eric Dumazet wrote:
> On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote:
> > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> >
> > > I would say this makes the use of seq counter impossible. Even if we
> > &g
On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
>
> > I would say this makes the use of seq counter impossible. Even if we
> > decided to fall back to a lock on retry, we cannot know what to do if
> &
On Fri, Apr 17, 2015 at 02:46:56PM -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 14:16 +0200, Mateusz Guzik wrote:
> > Hi,
> >
> > Currently obtaining a new file descriptor results in locking fdtable
> > twice - once in order to reserve a slot
On Thu, Apr 16, 2015 at 07:09:32PM +0100, Al Viro wrote:
> On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > @@ -165,8 +165,10 @@ static int expand_fdtable(struct files_struct *files,
> > int nr)
> > cur_fdt = files_fdtable(files);
> >
On Thu, Apr 16, 2015 at 01:55:39PM -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 13:42 -0700, Eric Dumazet wrote:
> > On Thu, 2015-04-16 at 19:09 +0100, Al Viro wrote:
> > > On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > > > @@ -165,8 +165,1
o ensure we updated the right table.
Signed-off-by: Mateusz Guzik
---
fs/file.c | 24 +++-
include/linux/fdtable.h | 5 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 93c5f89..bd1ef4c 100644
--- a/fs/file.c
Since the table is about to be freed, there is no reason to set file
pointer to NULL on closing.
At this point open_fd map is supposed to indicate whether a file is
installed, so NULL-checking it is unnecessary.
Signed-off-by: Mateusz Guzik
---
fs/file.c | 7 ++-
1 file changed, 2
;
> if (iattr->ia_valid & ATTR_SIZE) {
> xfs_ilock(ip, XFS_IOLOCK_EXCL);
> - error = xfs_setattr_size(ip, iattr);
> + error = xfs_setattr_size(dentry, ip, iattr);
> xfs_iunlock(ip, XFS_IOLOCK_EXCL);
> } else {
> - error = xfs_setattr_nonsize(ip, iattr, 0);
> + error = xfs_setattr_nonsize(dentry, ip, iattr, 0);
> }
>
> return error;
> diff --git a/fs/xfs/xfs_iops.h b/fs/xfs/xfs_iops.h
> index 1c34e43..6994d3e 100644
> --- a/fs/xfs/xfs_iops.h
> +++ b/fs/xfs/xfs_iops.h
> @@ -32,8 +32,14 @@ extern void xfs_setup_inode(struct xfs_inode *);
> */
> #define XFS_ATTR_NOACL 0x01/* Don't call posix_acl_chmod */
>
> -extern int xfs_setattr_nonsize(struct xfs_inode *ip, struct iattr *vap,
> +/*
> + * XXX Several callers have to pass dentry = NULL and this should
> + * work but it's really ugly.
> + */
> +extern int xfs_setattr_nonsize(struct dentry *dentry,
> +struct xfs_inode *ip, struct iattr *vap,
> int flags);
> -extern int xfs_setattr_size(struct xfs_inode *ip, struct iattr *vap);
> +extern int xfs_setattr_size(struct dentry *dentry,
> + struct xfs_inode *ip, struct iattr *vap);
>
> #endif /* __XFS_IOPS_H__ */
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 9ab779e..7cad5d1 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2663,6 +2663,7 @@ extern int buffer_migrate_page(struct address_space *,
> extern int inode_change_ok(const struct inode *, struct iattr *);
> extern int inode_newsize_ok(const struct inode *, loff_t offset);
> extern void setattr_copy(struct inode *inode, const struct iattr *attr);
> +extern int setattr_killpriv(struct dentry *dentry, struct iattr *attr);
>
> extern int file_update_time(struct file *file);
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 185836b..d1d4b9b 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -557,6 +557,10 @@ static int shmem_setattr(struct dentry *dentry, struct
> iattr *attr)
> if (error)
> return error;
>
> + error = setattr_killpriv(dentry, attr);
> + if (error)
> + return error;
> +
> if (S_ISREG(inode->i_mode) && (attr->ia_valid & ATTR_SIZE)) {
> loff_t oldsize = inode->i_size;
> loff_t newsize = attr->ia_size;
>
>
> --
> Ben Hutchings
> The first rule of tautology club is the first rule of tautology club.
--
Mateusz Guzik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, Mar 13, 2015 at 10:02:46AM -0400, Paul Moore wrote:
> On Monday, March 09, 2015 09:35:46 PM Mateusz Guzik wrote:
> > Can be used to determine whether two given sets have the same
> > capabilities.
> >
> > Signed-off-by: Mateusz Guzik
> > ---
>
On Mon, Mar 09, 2015 at 09:35:45PM +0100, Mateusz Guzik wrote:
> Sometimes faccessat needs to modify current thread's credentials, but
> calls prepare_creds unconditionally.
>
> However, typically resulting credentials are identical to original ones
> and in that cas
Can be used to determine whether two given sets have the same
capabilities.
Signed-off-by: Mateusz Guzik
---
include/linux/capability.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index af9f0b9..2fcf941 100644
--- a
Sometimes faccessat needs to modify current thread's credentials, but
calls prepare_creds unconditionally.
Take advantage of the fact that we can detect whether any modification
to credentials is needed and in turn avoid unnecessary allocations.
Signed-off-by: Mateusz Guzik
---
fs/open.c
eries adds a helper which allows comparing capability sets and
modifies faccessat to use it.
Mateusz Guzik (2):
CAPABILITIES: add cap_isequal helper
fs: avoid unnecessary prepare_creds in faccessat
fs/open.c | 53 ++
include/
On Mon, Mar 02, 2015 at 05:38:29AM +0100, Mateusz Guzik wrote:
> On Sun, Mar 01, 2015 at 08:31:26AM +1100, Dave Chinner wrote:
> > On Sat, Feb 28, 2015 at 05:25:57PM +0300, Alexey Dobriyan wrote:
> > > Freezing and thawing are separate system calls, task which is supposed
> &
ld see it blocked, we had no presumptive evidence to pin freezing on
it. A matching name, while still not 100% conclusive, would be ok enough
to push the case forward and avoid a rountrip of systemap scripts
showing freezer process tree.
--
Mateusz Guzik
--
To unsubscribe from this list: send t
#define CL_MAKE_SHARED 0x008
> +#define CL_PRIVATE 0x010
> +#define CL_SHARED_TO_SLAVE 0x020
> +#define CL_UNPRIVILEGED 0x040
> +#define CL_COPY_MNT_NS_FILE 0x080
> +#define CL_MAKE_RDONLY 0x100
>
> #define CL_COPY_ALL
snprintf(pid_buf, 16, "%u",
> + pid_vnr(find_pid_ns(1, ns)));
> + seq_printf(m, "%s ", pid_buf);
> + }
> +
> + seq_putc(m, '\n');
> + }
> +
> + free_pidn
ort->port_num);
> - strncat(proppath, temp, 255);
> + snprintf(&proppath[(len < proppath_len ? len : 0)], proppath_len - len,
> + "-%d", port->port_num);
> }
>
> static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
r_level == -1)
> + continue;
> +
> + for (i = curr_level + 1; i <= pid->level; i++) {
> + ns = pid->numbers[i].ns;
> + /* show PID '1' in specific pid ns */
> + snprintf(pid_buf, 32, "/proc/%u/ns/pid&quo
gt; + if (ns == curr_ns)
> + curr_level = curr_ns->level;
> +
> + if (curr_level == -1)
> + continue;
> +
> + for (i = curr_level + 1; i <= pid->level; i++) {
> +
uct dentry *anon)
>
> dparent = dentry->d_parent;
>
> - switch_names(dentry, anon);
> + switch_names(dentry, anon, false);
> swap(dentry->d_name.hash, anon->d_name.hash);
>
> dentry->d_parent = dentry;
> --
> 1.8.5.5
>
&
On Thu, Sep 11, 2014 at 06:39:58PM -0500, Chuck Ebbert wrote:
> On Sun, 7 Sep 2014 09:56:08 +0200
> Mateusz Guzik wrote:
>
> > On Sat, Sep 06, 2014 at 11:44:32PM +0200, Piotr Karbowski wrote:
> > > Hi,
> > >
> > > Starting with kernel 3.15 the '
1 - 100 of 161 matches
Mail list logo
