On Tue, Mar 26, 2013 at 10:46:40AM -0400, J. Bruce Fields wrote:
> > fs/locks.c:2093 says that we did the final fput of a file that still had
> > posix locks held on it.
> >
> > I can't see how that would happen, but admittedly the nfsd4 code here is
> > much too complicated for its own good.
> >
On Tue, Mar 26, 2013 at 03:19:29PM +, James Hogan wrote:
> +struct da_stat {
> + short st_dev;
> + unsigned short st_ino;
> + unsigned st_mode;
> + unsigned short st_nlink;
> + unsigned short st_uid;
> + unsigned short st_gid;
> + short st_rdev;
> + int st_size;
elies on eventfd.h
pulling file.h; move that include there. Switch from eventfd_fget()/fput()
to fdget()/fdput(), while we are at it - eventfd_ctx_fileget() will fail
on non-eventfd descriptors just fine, no need to do that check twice...
Signed-off-by: Al Viro
---
diff --git a/include/linux/e
On Mon, Aug 19, 2013 at 02:16:36PM -0700, Linus Torvalds wrote:
> On Mon, Aug 19, 2013 at 1:29 PM, Christoph Lameter wrote:
> > On Mon, 19 Aug 2013, Simon Kirby wrote:
> >
> >>[... ] The
> >> alloc/free traces are always the same -- always alloc_pipe_info and
> >> free_pipe_info. This is seen
On Tue, Aug 20, 2013 at 10:55:40AM +0530, Arun KS wrote:
> >From 932a134abeac597f18c86c513704709ad154994b Mon Sep 17 00:00:00 2001
> From: Arun KS
> Date: Mon, 19 Aug 2013 12:06:33 +0530
> Subject: seq_file: Fix overflow condition in seq_commit
>
> seq_path()/seq_commit() is treating a d_path() f
On Tue, Aug 20, 2013 at 12:17:52AM -0700, Ian Applegate wrote:
> We are also seeing this or a similar issue. On a fairly widespread
> deployment of 3.10.1 & 3.10.6 this occurred fairly consistently on the
> order of 36 days (combined MTBF.)
Do you have any boxen with CONFIG_DEBUG_MUTEXES among tho
On Tue, Aug 20, 2013 at 12:51:56PM +0530, Arun KS wrote:
> d_path expects the pathname to be less than 64 bytes. If its more than
> 64, it returns -ENAMETOOLONG.
?!?!? d_path() does not expect anything of that sort - it can very
well produce names much longer, without ENAMETOOLONG.
> char *dyna
O_TMPFILE ABI changes, Oleg's fput() series, misc cleanups,
including making simple_lookup() usable for filesystems with non-NULL,
which allows to get rid of quite a bit of ugliness. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al
On Mon, Jul 15, 2013 at 08:25:14PM -0700, Linus Torvalds wrote:
> The "pipe -> cred_guard_mutex" lock chain is pretty direct, and can be
> clearly attributed to splicing into /proc. Now, whether that is a
> *good* idea or not is clearly debatable, and I do think that maybe we
> should just not spl
On Tue, Jul 16, 2013 at 04:03:51PM +1000, Dave Chinner wrote:
> I posted patches to fix this i_mutex/i_iolock inversion a couple of
> years ago (july 2011):
>
> https://lkml.org/lkml/2011/7/18/4
>
> And V2 was posted here and reviewed (aug 2011):
>
> http://xfs.9218.n7.nabble.com/PATCH-0-2-spli
On Tue, Jul 16, 2013 at 10:36:25PM +0530, Ramkumar Ramachandra wrote:
> Richard Weinberger wrote:
> > If you don't want devtmpfs, just disable it in your config.
>
> I don't understand: is this not a good default? Why is creating bogus
> devices, confusing systemd, and making um Linux hard to boo
On Tue, Jul 16, 2013 at 11:42:55PM +0530, Ramkumar Ramachandra wrote:
> Leave aside the fact that I could not find the uml-utils upstream [1],
> and didn't have a /uml/port-helper to connect the xterms for a second;
> I didn't even understand what was supposed to happen. Why do we spawn
> xterms,
On Tue, Jul 16, 2013 at 02:29:20PM -0500, Serge Hallyn wrote:
> All the files will be owned by host root, so there's no security
> concern in allowing this.
Files owned by root != very bad things can't be done by non-root.
Especially for debugfs, which is very much a "don't even think about
mounti
On Wed, Jul 17, 2013 at 10:38:55AM +0100, Stefano Stabellini wrote:
> There is a very fine line between cursing and what people might perceive
> as a personal attack.
I wanted to stay out of that thread, but that argument really goes over
the top. Look, ANYTHING might be perceived as a personal
On Wed, Jul 17, 2013 at 06:00:46PM +0100, Stefano Stabellini wrote:
> On Wed, 17 Jul 2013, Steven Rostedt wrote:
> > The last thing I want to do is to lower the quality of the kernel just
> > to get a wider range of developers.
>
> Can we stop bringing the quality of the code into the discussion?
On Wed, Jul 17, 2013 at 06:56:16PM +0100, Stefano Stabellini wrote:
> Abuse is never justified, I hope that's clear for everybody.
Depends on details of your definition of abuse.
> So we are down to the definition of verbal abuse.
> The Oxford dictionary gives me:
>
> "speak to (someone) in an
On Wed, Jul 17, 2013 at 03:24:18PM -0700, Sarah Sharp wrote:
> > > Abuse is never justified, I hope that's clear for everybody.
> >
> > Depends on details of your definition of abuse.
[snip]
> http://outofthefog.net/CommonBehaviors/VerbalAbuse.html
" "Always" and "Never" Statements - "Always"
On Thu, Jul 18, 2013 at 02:28:49PM +0800, Chen Gang wrote:
> When "str >= end", necessary to reset 'str' to "end - 1", or the return
> value will be larger than the real one, the callers which depend on the
> return value, may cause memory overflow.
You do realize that snprintf(s, 1, "abc") should
On Thu, Jul 18, 2013 at 03:29:17PM +0800, Chen Gang wrote:
> On 07/18/2013 12:28 PM, Chen Gang wrote:
> >
> >>strcpy(fmt1, fmt);
> >> @@ -199,46 +214,51 @@ static void prepare_error_buf(const char *fmt,
> >> va_list args)
> >>while ((k = is_there_reiserfs_struct(fmt1, &what)) != NULL) {
[nathan cc'd since he's the only person mentioned in mgc_request.c]
One general observation: drivers/taging/lustre is highly reviewer-hostile...
Found by unrelated grep:
drivers/staging/lustre/lustre/mgc/mgc_request.c:1040: if (vallen !=
sizeof(struct super_block))
Huh? The code aro
On Thu, Jul 18, 2013 at 06:11:23PM +0900, Jaegeuk Kim wrote:
> The error is reproducible by:
>
> After this, when we retrieve the inode->i_name of test2 by dump.f2fs, we get
> test1 instead of test2.
> This is because f2fs didn't update the file name during the f2fs_rename.
Er... Correct me if I
rting from
2.6.23.
Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
reiserfs: fix deadlock in umount
Andy Lutomirski (2):
fs: Fix file mode for O_TMPFILE
fs: Allow unprivileged linkat(..., AT_EMP
On Tue, Aug 20, 2013 at 08:36:22AM +0100, Al Viro wrote:
> Aha. _That_ is a bug, all right - dynamic_dname() is simply not suitable
> for that kind of uses. ashmem.c is certainly abusing shmem_file_setup();
> feeding that kind of mess as dentry name is a Bad Idea(tm). Anyway,
>
On Tue, Aug 20, 2013 at 01:18:07PM -0600, Alex Williamson wrote:
> eventfd_fget() tests to see whether the file is an eventfd file, which
> we then immediately pass to eventfd_ctx_fileget(), which again tests
> whether the file is an eventfd file. Simplify slightly by using
> fdget() so that we on
On Thu, Aug 08, 2013 at 05:24:41PM +0200, Miklos Szeredi wrote:
> Here's a series for fixing issues with d_drop on a directory dentry with
> children and adding support for such dropped directories in fuse.
>
> This one fixes a couple of issues I found with the previous incarnation and
> split out
On Thu, Aug 22, 2013 at 05:04:59AM +0900, Ryusuke Konishi wrote:
> On Wed, 21 Aug 2013 06:40:56 +0100, Al Viro wrote:
> > And I would like to understand what nilfs one is trying to do...
> > Unless I'm seriously misreading that code, it's *not* on any kind of a hot
>
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?
>
> What do you mean? I'd say that the /proc lookup is always *innermost*.
> Which means that it certainly cannot bail out, since t
On Sat, Aug 24, 2013 at 05:14:34PM +0200, Oleg Nesterov wrote:
> proc_readfd_common() does dir_emit_dots() twice in a row,
> we need to do this only once.
I really wonder how that one had happened - it's harmless, fortunately,
but... Ugh. Applied, will push to Linus today
--
To unsubscribe from
Hopefully linux.org.uk mail setup got fixed and this one won't bounce...
Assorted fixes from the last week or so; please pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
cope with potentially long ->d_dname() ou
On Tue, Aug 06, 2013 at 08:42:01AM +0200, Andi Kleen wrote:
> On Mon, Aug 05, 2013 at 10:59:49PM -0700, Andrew Morton wrote:
> > On Mon, 5 Aug 2013 15:09:35 -0700 Andi Kleen wrote:
> >
> > > From: Andi Kleen
> > >
> > > Use standard gcc __attribute__((alias(foo))) to define
> > > the syscall a
On Thu, Jul 18, 2013 at 11:40:16AM -0700, Nathan Rutman wrote:
> >>}
> >>RETURN(rc);
> >>}
> >> What is going on here? We cast something to struct super_block *?
> >> Where does it come from? The function it's in is
> Well, addressing the "what's going on"
On Fri, Jul 19, 2013 at 12:40:47PM +0900, Kim Jaegeuk wrote:
> Hi,
>
> 2013. 7. 18. 6:22?? "Al Viro" :
> >
> > On Thu, Jul 18, 2013 at 06:11:23PM +0900, Jaegeuk Kim wrote:
> > > The error is reproducible by:
> > >
> > >
On Thu, Jul 18, 2013 at 02:57:11PM -0600, Andreas Dilger wrote:
> > _THAT_ was going to be a remotely supplied data? I really hope I've
> > misparsed what you said above...
> >
> > And that still leaves the question about the code path that could
> > lead to execution of mgc_fs_setup().
>
> The
On Fri, Jul 19, 2013 at 08:14:05PM +0800, Zheng Liu wrote:
> Hi Dave,
>
> After applied this patch, the problem has been fixed in my own sand box.
> But that would be great if you could give it a try. I want to make sure
> that this patch can fix the problem. It looks like there has the same
> p
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
On Thu, Mar 14, 2013 at 10:35:59AM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Al et al,
>
> Documenting O_PATH fell by the wayside last year
> (http://thread.gmane.org/gmane.linux.man/2790) as I got distracted
> with other tasks. A recent prod or two have reminded me restart this.
> I have
On Sat, Jul 20, 2013 at 01:30:13PM -0700, Greg KH wrote:
> Hi Al,
>
> Is the patch below something that we need to worry about for 3.10 and
> older kernels? Or does the recent changes to the vfs in 3.11-rc1 make
> it so that this can't be hit in older kernels?
Needed since 2.6.35 or so (earlier
On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote:
> I'll just point out that it can make the whole thing worse, too.
> For example, for ext3/4, the tmpfile being created has to be added
> to the orphan inode list which is protected by a filesystem global
> mutex. Hence scalability of O
On Mon, Jul 22, 2013 at 03:15:14PM +0530, Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
> > [1]:
> > http://lists.freedesktop.org/archives/systemd-devel/2013-July/012152.html
>
> ... and the patches were rejected. Lennart says that UML providing
> /dev/tty* is wrong, and that UML sho
On Tue, Jul 23, 2013 at 07:47:07AM +0200, richard -rw- weinberger wrote:
> Adding Al again, someone dropped him from the CC list...
FWIW, all this crap stems from the old decision to use major 4 for
uml consoles. And it was a bad decision, no arguments here.
It's also a decision we are years too
On Fri, Mar 01, 2013 at 02:36:29PM +0800, Li Zefan wrote:
> On 2013/2/28 22:49, Tejun Heo wrote:
> > On Wed, Feb 27, 2013 at 10:53 PM, Li Zefan wrote:
> >>> static const struct cgroup_name root_cgroup_name = { .name = "/" };
> >>
> >> Can't... That's char name[0] not char *name.
> >
> > Flexible
On Sat, Mar 02, 2013 at 03:49:35PM +1100, Stephen Rothwell wrote:
> On Fri, 01 Mar 2013 17:10:08 -0500 (EST) David Miller
> wrote:
> > Ok, next I'm hitting some regression in Al Viro's signal changes when
> > userland
> > starts up. :-)
>
> If only we had some way of testing this stuff before
On Sat, Mar 02, 2013 at 12:35:28PM +0100, Heiko Carstens wrote:
> >From 16f8402d45de11a1699ca584a6605806fe60bfc5 Mon Sep 17 00:00:00 2001
> From: Heiko Carstens
> Date: Sat, 2 Mar 2013 12:26:30 +0100
> Subject: [PATCH] compat: restore timerfd settime and gettime compat syscalls
>
> Both compat sy
Fixes for several regressions introduced in the last signal.git pile,
along with fixing bugs in truncate and ftruncate compat (on just about
anything biarch at least one of those two had been done wrong).
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> CPU0 calls syscall fcntl(fd, F_SETFL, FASYNC)
> fcntl calls fdget_raw, the count on the filp is 1, so it is not
> incremented (no reference taken)
> fcntl calls do_fcntl, which calls setfl which calls filp->op->fasync
> which calls fasyn
On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
> occurring, but the following is my best guess. A kernel log is
> attached.
>
> The comment for fasync_insert_entry:
>
> * NOTE! It is very important that the FASYN
On Sat, Mar 02, 2013 at 06:42:43PM +, Al Viro wrote:
> ... what makes you think that it's fown->lock, in the first place?
>
> > [172635.399651] <> [] _raw_read_lock+0x13/0x20
> > [172635.399654] [] send_sigio+0x52/0xf0
>
> send_sigio() is
>
On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
> occurring, but the following is my best guess. A kernel log is
> attached.
[snip the analysis - it's a different lock anyway]
The traces below are essentially sys_e
ng got fixed by that
and AFAICS your reproducer is also taken care of. The fix is definitely
needed; the only question is if there's something else going on. Linus,
please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Viro (1):
fix compa
/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (13):
selinux: opened file can't have NULL or negative ->f_path.dentry
more file_inode() open-coded instances
9p: don't bother with private lock in ->d_fsdata; dentry->d_lock will do
just fine
hoc vfree()
deferral scheme killed.
Comments?
Signed-off-by: Al Viro
---
diff --git a/fs/file.c b/fs/file.c
index 3906d95..4a78f98 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -23,24 +23,10 @@
#include
#include
-struct fdtable_defer {
- spinlock_t lock;
- struct work_struc
On Sun, Mar 03, 2013 at 06:47:36PM +, Al Viro wrote:
> To bring back the thing discussed back in, IIRC, December: we have
> a bunch of places where inability to do vfree() from interrupt contexts
> (the most common case is doing that from RCU callback) leads to very
> ugl
On Sun, Mar 03, 2013 at 02:34:00PM -0800, Linus Torvalds wrote:
> On Sun, Mar 3, 2013 at 10:47 AM, Al Viro wrote:
> > To bring back the thing discussed back in, IIRC, December: we have
> > a bunch of places where inability to do vfree() from interrupt contexts
> > (th
On Fri, May 10, 2013 at 09:55:00PM +0200, Borislav Petkov wrote:
> On Fri, May 10, 2013 at 12:35:10PM -0700, Andrew Morton wrote:
> > I forget who did this initially and peeling back those layers with git
> > is tiresome.
>
> 1a94bc34768e4 from 2009, although those SyS* things started appearing in
On Fri, May 10, 2013 at 04:56:22PM -0400, Steven Rostedt wrote:
> On Fri, May 10, 2013 at 09:05:03PM +0100, Al Viro wrote:
> > On Fri, May 10, 2013 at 09:55:00PM +0200, Borislav Petkov wrote:
> > > On Fri, May 10, 2013 at 12:35:10PM -0700, Andrew Morton wrote:
> > &
On Fri, May 10, 2013 at 04:38:07PM -0700, Darrick J. Wong wrote:
> Al Viro complained of a ton of bogosity with regards to the jbd2 block tag
> header checksum. This one checksum is 16 bits, so cut off the upper 16 bits
> and treat it as a 16-bit value and don't mess around with be3
On Sat, May 11, 2013 at 10:05:05AM -0700, Linus Torvalds wrote:
> Ugh. You know what? I'd almost prefer to just do it as a single big
> commit, *without* the extra churn of then also renaming things.
> Because the renaming will just be painful and result in *more*
> problems, and quite frankly, th
On Sat, May 11, 2013 at 12:16:22PM -0700, Linus Torvalds wrote:
> >> Because renaming really doesn't buy us anything but pain.
> >
> > Umm... I'd rather go the whole way and get rid of inode argument as well,
> > while we are at it. It's completely redundant and it's unused in very large
> > maj
On Sat, May 11, 2013 at 02:12:25PM -0700, Linus Torvalds wrote:
> On Sat, May 11, 2013 at 2:06 PM, Al Viro wrote:
> >
> > Less boilerplate? We used to pass inode to fput() as well, but
> > switched to passing file alone...
>
> .. and that was painful.
>
>
On Sun, May 12, 2013 at 01:06:16AM +0100, Al Viro wrote:
> media_file_operations
> v4l2_file_operations
> snd_hwdep_ops
> sound_info_entry_ops
> proto_ops
> auth_ops
> BTW, a lot of those guys are returning void, but there are some that return
> int and I think we ought
On Mon, May 13, 2013 at 08:19:46AM +0800, Jeff Chua wrote:
> Anyone on lkml working on patches for vmware to make it run on
> Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
> diva/eicon and fio modules.
>
> Every modules is now broken and needs to be reworked. Is there a more
On Wed, May 15, 2013 at 01:38:48PM +0100, P??draig Brady wrote:
> >> In today's Austin Group meeting, I was tasked to open a new bug that
> >> would state specifically how the empty symlink is resolved; the intent
> >> is to allow both Solaris behavior (current directory) and BSD behavior
> >> (ENO
On Sat, Apr 06, 2013 at 12:03:00PM +0200, Marco Stornelli wrote:
> Hi all,
>
> with this patch series we try to change the fs freeze behavior in order
> to sleep in a killable state instead of sleeping in uninterruptible
> state. The patches are *NOT* tested because but a first review is welcome.
On Sat, Apr 06, 2013 at 09:56:00AM -0700, Greg KH wrote:
> From: Kay Sievers
>
> Some drivers want to tell userspace what uid and gid should be used for
> their device nodes, so allow that information to percolate through the
> driver core to userspace in order to make this happen. This means th
On Sat, Apr 06, 2013 at 10:26:12AM -0700, Greg KH wrote:
> Why not? "closed" systems, like Android and other embedded systems,
> have "assigned" uid and gid values that never change. Right now they
> have to have a horrible shell-script to set these values in devtmpfs
> when the device shows up
On Sat, Apr 06, 2013 at 12:04:52PM +0200, Marco Stornelli wrote:
> In every place where sb_start_write was called now we must manage
> the error code and return -EINTR.
Now go and look for callers of mnt_want_write() ;-/ The really
painful one is in do_last(), but kern_path_create() is not much
b
On Sun, Apr 07, 2013 at 11:37:27AM +0600, Rakib Mullick wrote:
> Hello,
>
> In copy_fs_struct(), old->umask is assigned to fs->umask outside of
> spin_lock(&old->lock). Shouldn't it be inside spin_lock()? Since we're
> dealing with fs_struct *old ? Isn't it unsafe? Following lines -
>
>
On Mon, Apr 08, 2013 at 11:53:25AM +1000, Stephen Rothwell wrote:
> The only use outside of kernel/timer.c was in kernel/compat.c, so move
> compat_sys_sysinfo() next to sys_sysinfo() in kernel/timer.c.
Please, switch it to COMPAT_SYSCALL_DEFINE, while you are at it.
--
To unsubscribe from this li
On Mon, Apr 08, 2013 at 10:34:07AM -0500, Nathan Zimmer wrote:
> On 04/05/2013 04:00 PM, Al Viro wrote:
> >On Fri, Apr 05, 2013 at 03:56:17PM -0500, Nathan Zimmer wrote:
> >
> >>That didn't produce anything. I'll run some bisections over the
> >>w
On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote:
> Further digging seems to indicate 9984d7394618df9, the one right
> after the commit I previously identified.
> Not sure what I did wrong with my bisect to put it off by one.
Ugh... Can't reproduce here ;-/ Could you give more deta
On Mon, Apr 08, 2013 at 10:23:27PM +0100, Al Viro wrote:
> On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote:
>
> > Further digging seems to indicate 9984d7394618df9, the one right
> > after the commit I previously identified.
> > Not sure what I did wrong with
On Mon, Apr 08, 2013 at 04:17:17PM -0600, Stephen Warren wrote:
> On 04/08/2013 03:48 PM, Al Viro wrote:
> > On Mon, Apr 08, 2013 at 10:23:27PM +0100, Al Viro wrote:
> >> On Mon, Apr 08, 2013 at 03:52:08PM -0500, Nathan Zimmer wrote:
> >>
> >>> Further di
On Mon, Apr 08, 2013 at 11:46:37PM +0100, Al Viro wrote:
> Very interesting... Just in case, could you try this on top of that
> branch and see if it triggers?
>
> diff --git a/fs/pipe.c b/fs/pipe.c
> index 8ce279b..b6cd51b 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
On Mon, Apr 08, 2013 at 03:45:31PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Apr 8, 2013 at 3:17 PM, Stephen Warren wrote:
> >> Anyway, I've just pushed a splitup of that commit (carved in 3 pieces)
> >> into vfs.git#pipe-splitup; could you check which part triggers that
> >> hang? Should pr
/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (3):
ecryptfs: close rmmod race
procfs: add proc_remove_subtree()
palinfo fixes
Andrey Vagin (1):
mnt: release locks on error path in do_loopback
Diffstat:
arch/ia64/kernel/palinfo.c | 77 +---
fs
On Tue, Apr 09, 2013 at 05:33:29PM +0400, Andrey Vagin wrote:
> do_loopback calls lock_mount(path) and forget to unlock_mount
> if clone_mnt or copy_mnt fails.
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mostly about syscall wrappers this time; there will be another pile with
patches in the same general area from various people, but I'd rather push
those after both that and vfs.git pile are in. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlo
On Wed, May 01, 2013 at 10:31:33AM +0530, Vasant Hegde wrote:
> On 05/01/2013 07:36 AM, Stephen Rothwell wrote:
> >Hi Al,
> >
> >Today's linux-next merge of the vfs tree got a conflict in
> >arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573
> >("powerpc/rtas_flash: Fix bad memory access"
On Wed, May 01, 2013 at 10:04:17PM +0100, James Hogan wrote:
> Al's commit e1b5bb6d1236d4ad2084c53aa83dde7cdf6f8eea ("consolidate
> cond_syscall and SYSCALL_ALIAS declarations") broke the build on
> blackfin and metag due to the following code:
>
> #ifndef SYMBOL_NAME
> #ifdef CONFIG_SYMBOL_PR
On Wed, May 01, 2013 at 10:43:35PM +0100, Al Viro wrote:
> Oh, hell... Guys, my deep apologies - what happened is that this thing
> has been caught in -next, rebase done here (on top of Rusty's commit)
> and *not* pushed to linux-next.
Curiouser and curiouser... FWIW, what I have
On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote:
> After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9 that
> umount above works (not busy).
Sigh... Check if the following fix works for your testcase:
diff --git a/fs/namespace.c b/fs/namespace.c
index b4f96a5..b68eef2d
On Sat, May 04, 2013 at 08:02:40PM +0200, Michael Leun wrote:
> On Sat, 4 May 2013 16:52:14 +0100
> Al Viro wrote:
>
> > On Sat, May 04, 2013 at 12:45:19PM +0200, Michael Leun wrote:
> >
> > > After reverting 57eccb830f1cc93d4b506ba306d8dfa685e0c88f from 3.9
>
On Fri, May 03, 2013 at 10:03:43PM +0200, Geert Uytterhoeven wrote:
> Ping?
>
> Now the build failure is also in Linus' tree:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/8674437/
>
> BTW, this patch depends on "[PATCH 1/2] sun3_scsi: Fill in missing
> scsi_host_template.proc_info method"
On Sat, May 04, 2013 at 12:11:23AM +0200, Jan Kara wrote:
> When BSD process accounting is enabled and logs information to a
> filesystem which gets frozen, system easily becomes unusable because
> each attempt to account process information blocks. Thus e.g. every task
> gets blocked in exit.
>
>
Assorted fixes, etc. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (6):
do_mount(): fix a leak introduced in 3.9 ("mount: consolidate permission
checks")
do_coredump(): don't wait for thaw if coredump h
into
reasonably-sized pieces (more or less "comes from the same tree"). Please,
pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (15):
arm: single_open() leaks
cris: single_open() leaks
h8300: single_open() leaks
On Mon, May 06, 2013 at 09:01:05PM +0100, Will Deacon wrote:
> The Alpha Architecture Reference Manual states that any memory access
> performed between an LD_xL and a STx_C instruction may cause the
> store-conditional to fail unconditionally and, as such, `no useful
> program should do this'.
>
On Mon, May 06, 2013 at 01:19:51PM -0700, Matt Turner wrote:
> I'm not sure of the interpretation that LDA counts as a memory access.
>
> The manual says it's Ra <- Rbv + SEXT(disp).
>
> It's not touching memory that I can see.
More to the point, the same manual gives explicit list of instructi
On Tue, May 07, 2013 at 11:52:00AM +0200, Geert Uytterhoeven wrote:
> arch/h8300/kernel/syscalls.S | 646
> +++---
NAK on this part - either turn it into array initialized in something.c,
or at least do something like
#define CALL(x) .long _##x
and use that to
A couple of fixes + getting rid of __blkdev_put() return value.
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (4):
hfs: SMP race on directory close()
mtd_blktrans_ops->release() should return void
block_device_operati
On Wed, May 08, 2013 at 09:29:10AM -0700, H. Peter Anvin wrote:
> Unlikely, since the kernel source tree is clean.
>
> The error is on os_dep/os_intfs.c:
>
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c: In function
> ?rtw_proc_init_one?:
> /home/hpa/kernel/rtl8723au/os_dep/os_intfs.c:315:3: erro
On Wed, May 08, 2013 at 01:32:06PM -0700, Ben Greear wrote:
> I'm seeing a crash when unloading the ath9k module.
>
> It seems relay_close() is being passed bad memory.
>
> The relay_open call uses an ath9k debugfs directory, so
> that may be removed before the call to relay_close()
> is called.
This is going to be a major PITA, but surprisingly it seems to be
more or less feasible. Background: ->release() method in file_operations
has wrong prototype.
0.96a: void (*release)(struct inode *, struct file *) introduced
as abstraction for minix_release (same type). Called by
On Thu, May 09, 2013 at 11:58:24AM +0400, Denis Efremov wrote:
> EXPORT_SYMBOL and inline directives are contradictory to each other.
> The patch fixes this inconsistency.
What makes them contradictory, in your opinion? With references to
relevant parts of C99, please.
--
To unsubscribe from this
Regression fix from Geert + yet another open-coded kernel_read().
Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (1):
ecryptfs: don't open-code kernel_read()
Geert Uytterhoeven (1):
xtensa simdisk: Fix proc_create
On Thu, May 09, 2013 at 01:12:43PM -0700, Linus Torvalds wrote:
> On Thu, May 9, 2013 at 12:26 PM, Al Viro wrote:
> > Regression fix from Geert + yet another open-coded kernel_read().
>
> Hmm. I get one more commit - a racy usbmon thing.
Oops - pull stats not updated..
On Thu, May 09, 2013 at 09:28:15PM +0100, Al Viro wrote:
> The only place checking that sucker is in a fairly large area protected by
> ->b_lock (in mon_bin_event()); I really don't want to dig deep enough to
> tell if having it changed right after it had been checked is safe
On Fri, May 10, 2013 at 01:19:26PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the akpm tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/md/bcache/super.c:656:2: warning: initialization from incompatible
> pointer type [enabled by default]
Several syscall-related commits that were missing from the original
pull request. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Viro (3):
unify compat fanotify_mark(2), switch to COMPAT_SYSCALL_DEFINE
unicore32: just use mmap_pgoff
On Tue, Apr 23, 2013 at 03:41:18PM +0400, Dmitry Monakhov wrote:
> The only guess I have is that this is a miss typo because buffer
> is busy if some one hold an reference (bh->b_count !=0 ) ||
> it is (dirty | locked). So following patch
... is pointless. All callers only care about the return
601 - 700 of 7633 matches
Mail list logo
