On Sun, Mar 17, 2013 at 07:00:36PM +0100, Oleg Nesterov wrote:
> Cleanup. Now that we have f_inode/file_inode() we can use it
> instead of ->f_mapping->host.
No. This is *not* guaranteed to be the same thing in general; note that
e.g. for block devices ->f_mapping->host is *not* equal to file_ino
PENDING alone when deciding whether to hit do_notify_resume()
or not. Looks like the following ought to fix that:
Signed-off-by: Al Viro
---
diff --git a/arch/sh/kernel/cpu/sh5/entry.S b/arch/sh/kernel/cpu/sh5/entry.S
index b7cf6a5..7e605b9 100644
--- a/arch/sh/kernel/cpu/sh5/entry.S
+++ b/ar
On Fri, Aug 31, 2012 at 12:48:07PM -0400, Namjae Jeon wrote:
> As after file is removed fat_evict_inode will be called and fat_detach will
> be called from that place. So, fat_detach can be removed from vfat_unlink
NAK. Please, realize that unlink and destruction of file are separate
operations.
On Mon, Sep 03, 2012 at 06:05:38PM +0200, Oleg Nesterov wrote:
> This is not easy to fix. ptrace_disable() and user_disable_single_step()
> is arch dependant, but at least on x86 it assumes that the tracee is not
> running, so exit_ptrace() can't do this.
True (IOW, proposed fix is hopeless - we
On Tue, Sep 04, 2012 at 05:39:38PM +0200, Oleg Nesterov wrote:
> > BTW, speaking of alpha, what about PTRACE_SINGLESTEP when the task is
> > stopped
> > on syscall entry/exit after previous PTRACE_SYSCALL, BTW? Looks like it
> > will
> > be like PTRACE_CONT until we hit the first signal, at whi
On Wed, Sep 05, 2012 at 12:57:44AM +0900, Namjae Jeon wrote:
> From: Namjae Jeon
>
> All the files on a FAT partition have an on-disk directory entry.
> The location of these entries, i_pos, is unique and is constructed by the
> fat_make_i_pos() function.We can use this as the inode number making
On Wed, Sep 12, 2012 at 01:55:52AM +0100, Meredydd Luff wrote:
> Al (in particular): I've reworked this on top of your generic
> execve() changes, as well as incorporating feedback from HPA.
> Could you take another look please (and merge if all is well)?
>
> [v3: now rebased onto signal.git#execv
On Fri, Feb 01, 2008 at 01:04:42AM +0100, Santiago Garcia Mantinan wrote:
> > I have today compiled dl2k from git, the version with the 2007-12-23 patches
> > from Al Viro: dl2k endianness fixes (.24 fodder?) Right before the Al Viro
> > patches. This seems to be working perf
Misc audit updates and fixes. Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/ audit.b46
Shortlog:
Al Viro (2):
switch audit_get_loginuid() to task_struct *
get rid of loginuid races
Andrew Morton (1):
[patch 1/2] kernel/audit.c
On Sat, Feb 02, 2008 at 01:45:15PM -0500, Erez Zadok wrote:
> > You are thinking about non-interesting case. _Files_ are not much
> > of a problem. Directory tree is. The real problems with all unionfs and
> > stacking implementations I've seen so far, all way back to Heidemann et.al.
> > start
; cat >a.c <<'EOF'
const char foo[] __attribute__ ((__section__(".blah"))) = "";
const char * const bar __attribute__((__section__(".blah"))) = "";
EOF
; gcc -m32 -S a.c
; gcc -m64 -S a.c
a.c:2: error: bar causes a section type conflict
;
That's 4.1.2 on ppc. What happens is that the second decla
On Sun, Feb 03, 2008 at 06:26:35PM +0100, Sam Ravnborg wrote:
> On Sun, Feb 03, 2008 at 01:08:44PM +0000, Al Viro wrote:
> > ; cat >a.c <<'EOF'
> > const char foo[] __attribute__ ((__section__(".blah"))) = "";
> > const char * const bar _
On Sun, Feb 03, 2008 at 09:30:02PM +0100, Sam Ravnborg wrote:
> And I'm suprised to see that gcc thinks bar is writeable.
> If I try to assign it gcc error out as expected.
That's because "not modifiable" and "goes into r/o section" are not the
same thing. The former belongs to C and is target-in
On Mon, Feb 04, 2008 at 11:19:44PM +1100, Rusty Russell wrote:
> This patch lets timer callback functions have their natural type
> (ie. exactly match the data pointer type); it allows the old "unsigned
> long data" type as well.
>
> Downside: if you use the old "unsigned long" callback type, you
This is *not* all; fs/dcache.c bits will go separately, for one
thing - that's just the first pile. Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (67):
do_add_mount()/umount -l races
close the ra
On Tue, Oct 02, 2012 at 07:31:58PM -0700, Linus Torvalds wrote:
> On Tue, Oct 2, 2012 at 6:39 PM, Al Viro wrote:
> > This is *not* all; fs/dcache.c bits will go separately, for one
> > thing - that's just the first pile. Please, pull from the usual place -
>
>
On Wed, Oct 03, 2012 at 09:38:52AM -0700, Linus Torvalds wrote:
> Yeah, that bugzilla shows the problem with Kay as a maintainer too,
> not willing to own up to problems he caused.
>
> Can you actually see the problem? I did add the attached patch as an
> attachment to the bugzilla, so the reporte
On Wed, Oct 03, 2012 at 10:32:08AM -0700, Linus Torvalds wrote:
> On Wed, Oct 3, 2012 at 10:09 AM, Al Viro wrote:
> >
> > + if (!S_ISREG(inode->i_mode))
> > + return false;
> > + size = i_size_read(inode);
> >
> > Probably bet
On Wed, Oct 03, 2012 at 03:23:56PM -0700, Chris Zankel wrote:
> Hi Linus,
>
> Please pull the changes for the Xtensa architecture for v3.7.
>
> Thanks,
> -Chris
BTW, could you do an xtensa counterpart of the stuff in
git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel
On Thu, Oct 04, 2012 at 07:56:40PM -0400, Sasha Levin wrote:
> Commit "fs: add link restriction audit reporting" has added auditing of failed
> attempts to follow symlinks. Unfortunately, the auditing was being done after
> the struct path structure was released earlier.
Applied, and it's -stable
On Thu, Oct 04, 2012 at 07:57:31PM -0400, Sasha Levin wrote:
> audit_log_start() may return NULL, this is unchecked by the caller in
> audit_log_link_denied() and could cause a NULL ptr deref.
>
> Introduced by commit a51d9eaa ("fs: add link restriction audit reporting").
Again, -stable fodder.
On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
> I fetched the series from your arch-tile branch and built it, and it works
> fine. It looks good from my inspection:
>
> Acked-by: Chris Metcalf
Thanks; Acked-by applied, branch pushed and put into no-rebase mode.
BTW, something
On Tue, Oct 23, 2012 at 03:22:36PM -0400, Chris Metcalf wrote:
> On 10/23/2012 2:41 PM, Al Viro wrote:
> > On Tue, Oct 23, 2012 at 01:30:26PM -0400, Chris Metcalf wrote:
> >> As you had suggested in an earlier email, I went ahead and eliminated the
> >> special pt_re
On Wed, Oct 24, 2012 at 04:02:49AM +0300, Linus Torvalds wrote:
> On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner wrote:
> >>
> >> It is spelled:
> >>
> >> git notes add -m SHA1
> >
> > Cool!
>
> Don't use them for anything global.
>
> Use them for local codeflow, but don't expect them to b
On Wed, Oct 24, 2012 at 04:20:32PM -0700, Kees Cook wrote:
> If a series of scripts are executed, each triggering module loading via
> unprintable bytes in the script header, kernel stack contents can leak
> into the command line.
>
> Normally execution of binfmt_script and binfmt_misc happens
> r
On Thu, Oct 25, 2012 at 05:16:22PM +0530, P J P wrote:
>
> Hello Kees,
>
> +-- On Wed, 24 Oct 2012, Kees Cook wrote --+
> | What should the code here _actually_ be doing? The _script and _misc
> | handlers expect to rewrite the bprm contents and recurse, but the module
> | loader want to try
On Thu, Oct 25, 2012 at 01:09:53PM +0100, Al Viro wrote:
> On Thu, Oct 25, 2012 at 05:16:22PM +0530, P J P wrote:
> >
> > Hello Kees,
> >
> > +-- On Wed, 24 Oct 2012, Kees Cook wrote --+
> > | What should the code here _actually_ be doing? The _script an
On Thu, Oct 25, 2012 at 09:31:31AM -0400, Chris Metcalf wrote:
> On 10/23/2012 4:36 PM, Al Viro wrote:
> > Could you test the following on top of your patch? It gets rid of
> > regs use in sys_clone() *and* of the regs argument in copy_thread().
> > If that work (includi
On Thu, Oct 25, 2012 at 05:46:38PM +0200, Jonas Bonn wrote:
> Signed-off-by: Jonas Bonn
> ---
> arch/openrisc/kernel/process.c |6 +-
> arch/openrisc/kernel/sys_or32.c |8 +---
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/arch/openrisc/kernel/process.c b/a
On Thu, Oct 25, 2012 at 05:46:39PM +0200, Jonas Bonn wrote:
> copy_thread can use current_pt_regs() to get the pt_regs data that
> it needs so there's no need to pass this in as an argument.
>
> As do_fork() doesn't use the regs argument for anything other than
> to pass it straight through to cop
On Thu, Oct 25, 2012 at 08:38:25PM -0700, Linus Torvalds wrote:
> It's valid to cast a non-const pointer to a const one. It's the
> *other* way around that is invalid.
>
> So marking fw_path[] as having 'const char *' elements just means that
> we won't be changing those elements through the fw_p
On Fri, Oct 26, 2012 at 01:57:43PM +0400, ??? wrote:
> I'm working a kernel module, and one of my tasks is to disallow a
> process to open my character device(/dev/xxx) more than once. I tried
> to solve this problem by creating /proc/apu directory, and creating a
> /proc/xxx/{pid} fil
On Tue, Feb 12, 2008 at 10:20:44PM +, Alan Cox wrote:
> > I think the best way to get the serial drivers maintained would be to cat
> > them all onto the end of synclink.c and hope that Paul thinks he did it.
>
> Well I've already broken the buffering so he'd fix it ;)
>
> We have a pile of o
On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > Ahem... Use of git-cherry-pick preserves commit information just fine.
>
> Not by default, at least (note they said "commiters", not "authors"):
That's why you give it -r.
--
To unsubscribe from this list: send the line "unsubs
On Tue, Feb 12, 2008 at 03:51:07PM -0800, David Miller wrote:
> From: Jeff Garzik <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 11:31:48 -0500
>
> > I understand the desire to want a nice and clean history, but the
> > frequency here really has a negative impact on your downstreams.
>
> Ok, fair
On Tue, Feb 12, 2008 at 04:59:23PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Feb 2008, Al Viro wrote:
>
> > On Tue, Feb 12, 2008 at 07:16:50PM -0500, J. Bruce Fields wrote:
> > > > Ahem... Use of git-cherry-pick preserves commit information just fine.
> &g
test_and_set_bit() on address of uint32_t is a Bad Idea(tm)...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/md/dm-raid1.c b/drivers/md/dm-raid1.c
index edc057f..2928ef2 100644
--- a/drivers/md/dm-raid1.c
+++ b/drivers/md/dm-raid1.c
@@ -124,7 +124,7 @@ enum dm_raid1
readl(sock + ...) that should've been readl(sock->addr + ...)
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/memstick/host/tifm_ms.c b/drivers/memstick/host/tifm_ms.c
index f55b71a..4fb2421 100644
--- a/drivers/memstick/host/tifm_ms.c
+++ b/drivers/memstick/
On Wed, Feb 13, 2008 at 03:56:59AM +, Al Viro wrote:
> readl(sock + ...) that should've been readl(sock->addr + ...)
s/readl(/writel(..., / in the changelog message...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
d2d6f5b9eb315a53043a722d952bb21ed5ca1229
diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c
index 457ed3d..efacc9f 100644
--- a/drivers/acpi/wmi.c
+++ b/drivers/acpi/wmi.c
@@ -247,7 +247,7 @@ u32 method_id, const struct acpi_buffer *in,
On Tue, Feb 12, 2008 at 06:46:54PM -0800, Andrew Morton wrote:
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -20,9 +20,6 @@
> > #ifndef _LINUX_MEMCONTROL_H
> > #define _LINUX_MEMCONTROL_H
>
On Tue, Feb 12, 2008 at 11:15:53AM -0800, Greg KH wrote:
> Remember, we are currently clocking along at the steady rate of:
> 4000 lines added every day
> 1900 lines removed every day
> 1300 lines modified every day
lines reviewed every day.
AFAICS, we are in situa
On Tue, Feb 12, 2008 at 10:59:00AM -0800, Linus Torvalds wrote:
>
>
> On Tue, 12 Feb 2008, Linus Torvalds wrote:
> >
> > In other words, I'm perfectly happy to be an a*hole and tell people that I
> > simply won't merge things that cause undue API churn at all, and that were
> > not thought out
On Tue, Feb 12, 2008 at 12:50:51PM -0800, Greg KH wrote:
> I can run the numbers, but almost every one of those changes has at
> least 2 signed-off-by: on them, so they should all be being reviewed
> properly.
>
> > AFAICS, we are in situation when review bandwidth is where the bottleneck
> > is.
On Fri, Nov 02, 2012 at 12:51:36AM +0900, Namjae Jeon wrote:
> When a user is monitoring an FS_UMOUNT watch using the inotify framework,
> there can be a potential race condition between the umount path &
> inotify_rm_watch. This scenario can be like-
> =
and non-O_CREAT opens common.
>
> This allows atomic_open to be hooked into the slow lookup part.
>
> Signed-off-by: Miklos Szeredi
> Signed-off-by: Al Viro
Hmm... Looking at that commit, we seem to have one change introduced by it.
Namely,
behaviour of ope
ly. I think
we need this, but I wonder if that's all; ->atomic_open() instances
might need to be corrected as well. I've pushed this into for-next/for-linus
for now:
commit f8310c59201b183ebee2e3fe0c7242f5729be0af
Author: Al Viro
Date: Mon Jul 30 11:50:30 2012 +0400
fix O_EX
On Mon, Jul 30, 2012 at 10:05:36AM +0200, Markus Trippelsdorf wrote:
> On 2012.07.30 at 08:56 +0100, Al Viro wrote:
> > On Mon, Jul 30, 2012 at 09:10:23AM +0200, Markus Trippelsdorf wrote:
> > >
> > > Looks like you're right. The first warning happens dur
On Tue, Jul 31, 2012 at 04:38:39PM +0800, Fengguang Wu wrote:
> Hi Jan,
>
> Here is another warning for the fs freeze series.
>
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git fsfreeze
> head: 7aff72a61f45337d83ab2b7fb16d7b542db16ad8
> commit: bc875c078f72993e6c44925cdedef5
On Tue, Jul 31, 2012 at 04:29:43PM +0800, Fengguang Wu wrote:
> Hi Jan,
>
> I caught the following warning at this commit. Note that the head
> commit actually boots OK, so it may either be not 100% reproduciable,
> or get fixed somewhere in your patchset.
In the next commit, actually. I'm still
On Fri, Sep 21, 2012 at 12:26:36PM -0400, Mark Salter wrote:
> Here are a set of c6x patches to work with your experimental-kernel_thread
> branch.
>
> Mark Salter (3):
> c6x: add ret_from_kernel_thread(), simplify kernel_thread()
> c6x: switch to generic kernel_execve
> c6x: switch to gener
On Sat, Sep 22, 2012 at 09:16:11PM +1000, Greg Ungerer wrote:
> I sent the patch to the m68k-linux list. Its been acked by Geert.
>
> http://marc.info/?l=linux-m68k&m=134742688015639&w=2
>
> I was going to push it through the m68knommu git tree, but I don't mind
> if you would rather take it wit
On Sat, Sep 22, 2012 at 08:50:44PM -0700, Eric W. Biederman wrote:
> +struct inode *devpts_redirect(struct file *filp)
> +{
> + struct inode *inode;
> + struct file *filp2;
> +
> + /* Is the inode already a devpts inode? */
> + inode = filp->f_dentry->d_inode;
> + if (filp->f_d
On Sun, Sep 23, 2012 at 05:19:06AM +0100, Al Viro wrote:
> On Sat, Sep 22, 2012 at 08:50:44PM -0700, Eric W. Biederman wrote:
>
> > +struct inode *devpts_redirect(struct file *filp)
> > +{
> > + struct inode *inode;
> > + struct file *filp2;
> > +
>
On Sat, Sep 22, 2012 at 10:59:04PM -0700, Eric W. Biederman wrote:
> The test:
> >> + if (filp->f_vfsmnt->mnt_root == filp->f_dentry)
> kicks in and no redirection is performed.
Umm... OK, after the first round of recursion. Unless you bind /something/pts
on /something. Or simply create a sym
On Sun, Sep 23, 2012 at 07:30:38AM +0100, Al Viro wrote:
> On Sat, Sep 22, 2012 at 10:59:04PM -0700, Eric W. Biederman wrote:
>
> > The test:
> > >> +if (filp->f_vfsmnt->mnt_root == filp->f_dentry)
> > kicks in and no redirection is performed.
&g
On Tue, Sep 25, 2012 at 12:20:55PM -0700, Linus Torvalds wrote:
> IOW, this part of the patch:
>
> - c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include user.h
> $(CFLAGS_$(basetarget).o)
> + c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) -include
> $(srctree)/include/linux/kern_levels.h
The situation got much better by now. More than a half of
architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
parisc sparc tile um unicore32 and x86.
Two more avait ACKs from maintainers - powerpc and s390. Should work,
AFAICS.
xtensa - Max was g
On Fri, Oct 26, 2012 at 11:08:20PM +0530, P J P wrote:
> +-- On Thu, 25 Oct 2012, Al Viro wrote --+
> | * every bleeding script will have bogus execution of modprobe done
> | at execve time (and you'd better pray that /sbin/modprobe isn't a shell
> | script wrapper around
On Fri, Oct 26, 2012 at 11:50:21AM -0700, Kees Cook wrote:
> +config PROTECTED_SYMLINKS_SYSCTL
> + int
> + default "1" if PROTECTED_SYMLINKS
> + default "0"
If anything, use IS_ENABLED instead...
> -int sysctl_protected_symlinks __read_mostly = 0;
> -int sysctl_protected_hardlinks __
On Fri, Oct 26, 2012 at 07:31:07PM +0100, Al Viro wrote:
> The situation got much better by now. More than a half of
> architectures are done - alpha arm arm64 c6x hexagon ia64 m68k mips openrisc
> parisc sparc tile um unicore32 and x86.
>
> Two more avait ACKs f
On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote:
> Oops, sorry. I tested this weeks ago but it seems I never wrote a mail to
> indicate success. The current git kernel works just fine.
"Current git" being what? Linus' tree? linux-next? signal.git#arch-s390?
FWIW, the relevan
On Mon, Oct 29, 2012 at 03:38:23PM +0100, Martin Schwidefsky wrote:
> On Mon, 29 Oct 2012 13:25:21 +
> Al Viro wrote:
>
> > On Mon, Oct 29, 2012 at 08:53:39AM +0100, Martin Schwidefsky wrote:
> >
> > > Oops, sorry. I tested this weeks ago but it seems I never
On Mon, Oct 29, 2012 at 05:41:20PM -0700, Kees Cook wrote:
> From: Will Drewry
>
> There is very little difference in the TIF_SECCOMP and TIF_SYSCALL_TRACE
> path in entry-common.S. In order to add support for
> CONFIG_HAVE_ARCH_SECCOMP_FILTER without mangling the assembly too badly,
> seccomp wa
On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote:
> This patch passes a data pointer along to the alloc_inode
> super_operations function. The value will initially be used by
> bdev_alloc_inode to allocate the bdev_inode on the same numa
> node as the device to which it is tied.
Yecchhh
On Tue, Oct 30, 2012 at 08:51:42PM +, Al Viro wrote:
> On Tue, Oct 30, 2012 at 04:14:39PM -0400, Jeff Moyer wrote:
> > This patch passes a data pointer along to the alloc_inode
> > super_operations function. The value will initially be used by
> > bdev_alloc_inode to al
On Tue, Oct 30, 2012 at 09:02:33PM +, Arvid Brodin wrote:
> +config PROC_TEXT_MD5SUM
> + bool "/proc//text_md5sum support"
> + depends on PROC_FS
> + select CRYPTO
> + select CRYPTO_MD5
> + help
> + Read /proc//text_md5sum to get the kernel to perform an MD5
> +
On Tue, Oct 30, 2012 at 06:25:46PM -0700, Linus Torvalds wrote:
> But whatever. This series has gotten way too much bike-shedding
> anyway. I think it should just be applied, since it does remove lines
> of code overall. I'd even possibly apply it to mainline, but it seems
> to be against linux-ne
On Tue, Oct 30, 2012 at 07:48:19PM -0700, Linus Torvalds wrote:
> On Tue, Oct 30, 2012 at 7:24 PM, Al Viro wrote:
> >
> > BTW, how serious have you been back at KS when you were talking about
> > pull requests killing a thousand of lines of code being acceptable
> >
On Fri, Aug 23, 2013 at 02:07:26AM +0100, Al Viro wrote:
> On Thu, Aug 22, 2013 at 01:54:15PM -0700, Linus Torvalds wrote:
> > On Thu, Aug 22, 2013 at 1:48 PM, Andy Lutomirski
> > wrote:
> > >
> > > Sure. But aren't they always last?
> >
> >
On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote:
> I doubt it. It seems to me that most such entries are implemented
> for completeness while most valid uses only concern /proc/self/fd.
> Maybe if we had an option so that only /proc/self/fd would actually
> allow to access the fds wh
On Sun, Aug 25, 2013 at 12:26:34AM -0700, Andy Lutomirski wrote:
> I think this is more screwed up than just flink and open. For example:
>
> $ echo 'WTF' >test
> $ truncate -s 1 /proc/self/fd/3 3 $ cat test
> W$
>
> IMO that should have failed.
Why? truncate() always follows links, so what's
On Sun, Aug 25, 2013 at 11:32:45AM -0700, Linus Torvalds wrote:
> On Sat, Aug 24, 2013 at 10:23 PM, Al Viro wrote:
> >
> > We are really stuck with the current semantics here - switching to
> > *BSD one would not only mean serious surgery on descriptor handling
> > (it
On Sun, Aug 25, 2013 at 12:57:25PM -0700, Linus Torvalds wrote:
> Yes. I think we should do this, but I think we should also look at
> what _other_ LOOKUP_xyz we should do for the /proc case.
>
> For the read-only fd case, we should have a LOOKUP_WRITE flag, and
> return -EPERM if an operation is
On Tue, Aug 27, 2013 at 12:12:49AM +0800, Chuansheng Liu wrote:
>
> When one thread is calling sys_ioctl(), and another thread is calling
> sys_close(), current code has protected most cases.
>
> But for the below case, it will cause issue:
> T1T2
On Mon, Aug 26, 2013 at 09:49:48AM -0700, Eric W. Biederman wrote:
> How does changing the permissions to S_IRUSR prevent someone from
> opening the file before, and reading the file after a suid exec?
>
> > This patch restores the old mode which was 0400
>
> Which seems to add no security whats
On Mon, Aug 26, 2013 at 11:56:43PM +, Liu, Chuansheng wrote:
> Yes, the fix is really insane, I realized it after sent it.
> But I think the race is there, right?
Yes, in userland code. Depending on the timing, T3 might
* issue ioctl() on old file if called before close() in T1
On Tue, Aug 27, 2013 at 01:42:47AM +0100, Al Viro wrote:
> Might be buggered refcounting on struct file somewhere (i.e. extra fput()
> done,
> getting the file freed *before* close(), leaving a dangling pointer in
> descriptor table). Might be memory corruption of some kind, s
On Tue, Aug 27, 2013 at 12:16:34PM -0700, Andy Lutomirski wrote:
> This is an experiment to see if we can get nice semantics for all syscalls
> that either follow symlinks or allow AT_EMPTY_PATH without jumping through
> enormous hoops. This converts truncate (although you can't tell using
> trunc
On Tue, Aug 27, 2013 at 01:28:27PM -0700, Andy Lutomirski wrote:
> It would if it works. It certainly would for truncate, setxattr, etc.
>
> There are funny cases, though. For example, execing an O_WRONLY fd
> should probably fail, as should opening an O_WRONLY fd as O_RDWR.
> O_APPEND is also
On Wed, Aug 28, 2013 at 12:04:43PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 27, 2013 at 11:16 PM, Al Viro wrote:
> > On Tue, Aug 27, 2013 at 01:28:27PM -0700, Andy Lutomirski wrote:
> >> There are also O_PATH fds, and I'm not sure what the semantics of
> >>
The fix in "super: fix for destroy lrus" didn't - they need to be
destroyed, all right, but that's the wrong place... Please, pull
from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
fs/super.c: fix lr
On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> Maybe I am missing something obvious ?
Yes. do_execve_common() starts with unshare_files(); there can be
no other thread capable of modifying that descriptor table.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On Mon, Sep 30, 2013 at 08:49:21PM +0100, Al Viro wrote:
> OK... AFAICS, we are not too far from being able to handle RCU pathwalk
> straying into fs in the middle of being shut down.
> * There are 5 methods that can be called:
> ->d_hash(...)
> ->d_compare(
On Wed, Oct 02, 2013 at 07:13:19AM +0200, Ingo Molnar wrote:
>
> * Al Viro wrote:
>
> > On Tue, Oct 01, 2013 at 02:41:58PM -0700, Eric Dumazet wrote:
> > > Maybe I am missing something obvious ?
> >
> > Yes. do_execve_common() starts with unshare_files
On Tue, Sep 17, 2013 at 10:18:25AM -0400, Benjamin LaHaise wrote:
> +static int aio_set_page_dirty(struct page *page)
> +{
> + return 0;
> +};
> +
> +static const struct address_space_operations aio_aops = {
> + .set_page_dirty = aio_set_page_dirty,
> +};
> +
> +/*
> + * A single inode exis
On Thu, Oct 03, 2013 at 03:22:51AM +0100, Al Viro wrote:
> > + /*
> > +* Link the inode to a directory entry by creating a unique name
> > +* using the inode sequence number.
> > +*/
> > + file = ERR_PTR(-ENOMEM);
> > + this.name =
On Mon, Sep 30, 2013 at 08:49:21PM +0100, Al Viro wrote:
> * btrfs: wants btrfs_root_readonly(BTRFS_I(inode)->root) usable in
> ->permission(). Delayed freeing of struct btrfs_root, perhaps?
Not needed, actually - it's only checked with MAY_WRITE, and we don't
pass tha
Signed-off-by: Al Viro
---
fs/namespace.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index da5c494..6d73d3a 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -39,7 +39,7 @@ static int mnt_group_start = 1;
static struct
Signed-off-by: Al Viro
---
fs/namespace.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 6d73d3a..f6b7010 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2873,7 +2873,7 @@ bool fs_fully_visible(struct file_system_type *type
mnt_list is protected by namespace_sem, not vfsmount_lock
Signed-off-by: Al Viro
---
fs/namespace.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index f6b7010..09a255d 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2444,9
, so those who see it already marked that way can safely
drop mount_lock, do rcu_read_unlock() and be gone - the damn thing
won't be freed under them.
The last commit definitely needs a splitup; it's too big.
Shortlog:
Al Viro (17):
initialize namespace_sem statically
fs_is
MNT_WRITER_UNDERFLOW_LIMIT has been missed 4 years ago when it became unused.
Signed-off-by: Al Viro
---
fs/namespace.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index f00d9f6..8ea6676 100644
--- a/fs/namespace.c
+++ b/fs
->mnt_expire is protected by namespace_sem
Signed-off-by: Al Viro
---
fs/namespace.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 2632998..d5cd086 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2080,11 +2080,9 @@ f
should've been done 6 years ago...
Signed-off-by: Al Viro
---
fs/namespace.c | 48 ++--
1 files changed, 18 insertions(+), 30 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index d5cd086..632c551 100644
--- a/fs/namespace.c
+++
Signed-off-by: Al Viro
---
fs/namespace.c | 39 ---
1 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 41663dd..f00d9f6 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -872,28 +872,6 @@ static struct
... and don't bother with dropping and regaining vfsmount_lock
Signed-off-by: Al Viro
---
fs/namespace.c |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 09a255d..41663dd 100644
--- a/fs/namespace.c
+++ b/fs/namesp
Signed-off-by: Al Viro
---
fs/namespace.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 8ea6676..2632998 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2064,9 +2064,7 @@ fail:
/* remove m from any expiration list it
Instead of passing the direction as argument (and checking it on every
step through the hash chain), just have separate __lookup_mnt() and
__lookup_mnt_last(). And use the standard iterators...
Signed-off-by: Al Viro
---
fs/mount.h |3 ++-
fs/namei.c |4 ++--
fs/namespace.c
Signed-off-by: Al Viro
---
fs/mount.h |2 +-
fs/namespace.c | 22 +++---
fs/pnode.c |3 +--
3 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/fs/mount.h b/fs/mount.h
index 64a8581..3168dc4 100644
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -55,7 +55,7
101 - 200 of 6610 matches
Mail list logo
