On Wed, Oct 09, 2013 at 02:18:33AM +0100, Al Viro wrote:
> Point, but I would argue that we should yell very loud if we get 0 from
> vfs_write() for non-zero size. I'm not sure if POSIX allows write(2)
> to return that, but a lot of userland code won't be expecting that and
On Tue, Oct 08, 2013 at 06:38:47PM -0700, Linus Torvalds wrote:
> On Tue, Oct 8, 2013 at 6:18 PM, Al Viro wrote:
> >
> > Point, but I would argue that we should yell very loud if we get 0 from
> > vfs_write() for non-zero size. I'm not sure if POSIX allows write(2)
>
On Wed, Oct 09, 2013 at 05:18:53PM +0200, Jan Kara wrote:
> This is really weird. We are delivering a signal to a task. While task is
ITYM "a fatal signal"
> returning from kernel space we are running queued task works and one of
get_signal_to_deliver() notices that the signal has to be dealt
gt;f_mapping during ->open()
> and no longer need to adjust inode mappings. As fs/anon_inodes.c already
> provides a minimal internal FS mount, we extend it to also provide
> anonymous inodes for use in drivers like DRM.
>
> Signed-off-by: David Herrmann
> Wa
We used to require register_filesystem() before any mounts
(including the internal ones) could be done. For userland mounts
it's obviously right - how else could fs type name -> file_system_type
lookup be done? For internal ones, it used to be really needed for
a while, but after some API
On Fri, Aug 30, 2013 at 03:20:48PM -0400, Waiman Long wrote:
> There are more contention in the lglock than I remember for the run
> in 3.10. This is an area that I need to look at. In fact, lglock is
> becoming a problem for really large machine with a lot of cores. We
> have a prototype 16-socke
On Fri, Aug 30, 2013 at 03:52:49PM -0400, Waiman Long wrote:
> So it is the mnput_no_expire() function that is doing all the
> lg_global_lock() calls.
Interesting... So you are getting a lot of mntput() with ->mnt_ns being
NULL? I wonder which type it is... Note that anything mounted will
have
On Fri, Aug 30, 2013 at 01:43:11PM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2013 at 1:15 PM, Waiman Long wrote:
> >
> > The prepend_path() isn't all due to getcwd. The correct profile should be
>
> Ugh. I really think that prepend_path() should just be rewritten to
> run entirely under RCU.
On Fri, Aug 30, 2013 at 04:35:49PM -0400, Waiman Long wrote:
> The AIM7 test was run on a set of 16 ramdisk formated with ext3
> filesystem with the following mount options:
> barrier=0,async,noatime,nodiratime. Maybe that is a factor.
I would be really surprised if it was... Could you slap the
On Fri, Aug 30, 2013 at 05:10:45PM -0400, Waiman Long wrote:
> On 08/30/2013 04:54 PM, Al Viro wrote:
> >On Fri, Aug 30, 2013 at 01:43:11PM -0700, Linus Torvalds wrote:
> >>On Fri, Aug 30, 2013 at 1:15 PM, Waiman Long wrote:
> >>>The prepend_path() isn't all
On Fri, Aug 30, 2013 at 02:03:59PM -0700, Linus Torvalds wrote:
> Yes, yes, you haev to be careful and cannot just blindly trust the
> length: you also have to check for NUL character as you are copying it
> and stop if you hit it. But that's trivial.
Point... Actually, I wonder if _that_ could
y shmem_file_setup() gets closed. For no reason whatsoever...
Signed-off-by: Al Viro
---
diff --git a/mm/shmem.c b/mm/shmem.c
index e43dc55..445162c 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2615,7 +2615,7 @@ int shmem_fill_super(struct super_block *sb, void *data,
int silent)
* tmpfs
On Sat, Aug 31, 2013 at 03:35:16AM +0100, Al Viro wrote:
> Aha... OK, I see what's going on. We end up with shm_mnt *not* marked
> as long-living vfsmount, even though it lives forever. See if the
> following helps; if it does (and I very much expect it to), we want to
> put i
On Sat, Aug 31, 2013 at 05:53:11AM +, Liu, Chuansheng wrote:
> I think I found one of possible race here(two processes P1 and P2):
> P1 has the the files_struct pointer FILES1, P2 has the files_struct pointer
> FILES2,
>
> When P1 open file, the new struct file pointer SHARE_FILE will be ins
On Sat, Aug 31, 2013 at 07:01:33AM +, Liu, Chuansheng wrote:
> My scenario is:
> P1 files_struct refcount is 1, P2's is 1 also.
> P1 get_files_struct(P2)
> P1 install one file into P2's files_struct
> P1 put_files_struct(P2)
>
> Then P1 and P2's files_struct refcount are 1, then when P1 is do
On Sat, Aug 31, 2013 at 08:55:16PM +0200, Arnd Bergmann wrote:
> > Maybe this removal request is a bit early, but architecture support seems
> > to have vanished entirely. At the very least this puts interested parties
> > (if there are any) on notice.
>
> AFAICT, this is the least maintained arc
On Fri, Aug 30, 2013 at 03:30:14PM -0700, Linus Torvalds wrote:
> On Fri, Aug 30, 2013 at 2:44 PM, Al Viro wrote:
> >
> > Point... Actually, I wonder if _that_ could be a solution for ->d_name.name
> > printk races as well. Remember that story? You objected against
On Sat, Aug 31, 2013 at 03:49:31PM -0700, Linus Torvalds wrote:
> On Sat, Aug 31, 2013 at 2:23 PM, Al Viro wrote:
> >
> > Hmm... OK, most of these suckers are actually doing just one component;
> > we can look into 'print the ancestors as well' later, but t
On Sun, Sep 01, 2013 at 12:27:58AM +0100, Al Viro wrote:
> On Sat, Aug 31, 2013 at 03:49:31PM -0700, Linus Torvalds wrote:
> > On Sat, Aug 31, 2013 at 2:23 PM, Al Viro wrote:
> > >
> > > Hmm... OK, most of these suckers are actually doing just one component;
> &
On Sun, Sep 01, 2013 at 01:13:06AM +0100, Al Viro wrote:
> > Actually, right now I'm debugging a variant that avoids local buffers; use
> > is %pD3 for grandparent/parent/name, etc., up to %pD4. %pd is equivalent
> > to %pD1 (just the dentry name). Keep in mind that th
btle issues where
it played...
[1] sits in the local queue, will push tonight:
commit e7db6c4c1d01032f53262f03b5f38899f9db8add
Author: Al Viro
Date: Sat Aug 31 12:57:10 2013 -0400
shm_mnt is as longterm as it gets, TYVM...
Signed-off-by: Al Viro
diff --git a/mm/shmem.c b/mm/shmem.c
in
On Sun, Sep 01, 2013 at 03:16:24PM -0700, Linus Torvalds wrote:
> Does not seem to matter. Still 66% mntput_no_expire, 31% path_init.
> And that lg_local_lock() takes 5-6% of CPU, pretty much all of which
> is that single xadd instruction that implements the spinlock.
>
> This is on /tmp, which i
On Sun, Sep 01, 2013 at 11:35:21PM +0100, Al Viro wrote:
> > I wonder if there is some false sharing going on. But I don't see that
> > either, this is the percpu offset map afaik:
> >
> > f560 d files_lglock_lock
> > f564 d nr_dentr
On Sun, Sep 01, 2013 at 03:48:01PM -0700, Linus Torvalds wrote:
> I made DEFINE_LGLOCK use DEFINE_PER_CPU_SHARED_ALIGNED for the
> spinlock, so that each local lock gets its own cacheline, and the
> total loops jumped to 62M (from 52-54M before). So when I looked at
> the numbers, I thought "oh, th
On Mon, Sep 02, 2013 at 11:18:17PM +0800, Lennox Wu wrote:
> Before we start the development of the S+core, Sunplus had licensed
> ARM and MIPS. We develop S+core for other reason such as the price.
> Some products on the web of Sunplus adopt S+core , for example
> the SPV7050.(http://w3.sunplus.co
On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
> extreme sample: let 'kernel code style' and 'gcc code style' in one file,
> that will make the code very ugly.
gcc style will make any code very ugly, no matter what (if anything) else is
in the same file...
[digs out the ports
On Wed, Sep 04, 2013 at 08:54:57AM +0800, Ian Kent wrote:
> +static int kern_path_top(const char *pathname,
> + unsigned int flags, struct path *path)
> +{
> + struct dentry *dentry;
> + struct qstr name;
> + const char *tmp;
> + unsigned int len;
> + int er
On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote:
> E... NAK in that form. Just what will happen if the last component
> given to that sucker will be . or .., for starters? Or a symlink, with
> '/' added to it to force following the damn thing?
OK, in more de
On Tue, Sep 03, 2013 at 07:18:42PM -0700, Linus Torvalds wrote:
> On Tue, Sep 3, 2013 at 7:00 PM, Al Viro wrote:
> >
> > That aside, I'm really not happy with this kind of games; this stuff clearly
> > belongs in fs/namei.c where we can simply see the last component.
On Wed, Sep 04, 2013 at 03:26:17AM +0100, Al Viro wrote:
> I've applied slightly modified variant of Jeff's "vfs: allow umount to handle
> mountpoints without revalidating them" (modified by just leaving the
> struct path filled with mountpoint and leaving the equival
On Wed, Sep 25, 2013 at 12:10:57AM +0200, Alexander Holler wrote:
> Sure and I'm the last one who wants that people do have to use
> anything else than i for simple loop counters. And allowing longer
> lines doesn't mean people have to use long names, it allows them use
> them (if it makes sense).
On Wed, Sep 25, 2013 at 09:14:37PM +0100, Djalal Harouni wrote:
> The f_cred field of the file struct contains the cred of current at
> open time. This field can be used to get the context of open, and track
> current's cred changes after.
>
> The procfs is one of those fs that need to track curre
On Wed, Sep 25, 2013 at 05:22:51PM -0700, Linus Torvalds wrote:
> On Wed, Sep 25, 2013 at 1:14 PM, Djalal Harouni wrote:
> >
> > Therefor add the f_cred field to the seq_file struct and a helper
> > seq_f_cred() to return it.
>
> I hate how you've split up this patch from the next one that actual
On Thu, Sep 26, 2013 at 04:57:32AM +0200, Alexander Holler wrote:
> Am 26.09.2013 04:52, schrieb Alexander Holler:
>
> > I'm aware of people which do nest 8 levels deep just to avoid a return,
> > break or goto.
> >
> > But trying to limit that by limiting the line length is like ...
> > (choose
On Thu, Sep 26, 2013 at 05:27:15AM +0200, Alexander Holler wrote:
> Oh, personally I don't have any limit there. ;) I like descriptive
> function and variable names whenever they make sense. And often they
> make comments uneccessary and therefor prevent errors because those
> descriptive names ar
FWIW, I think I have a kinda-sorta solution for that and I'd like
to hear your comments on that. I want to replace vfsmount_lock with seqlock
and store additional seq number in nameidata, set to vfsmount_seq in the
beginning and rechecked in unlazy_walk/complete_walk.
The obvious
On Sat, Sep 28, 2013 at 01:43:49PM -0700, Linus Torvalds wrote:
> Sounds reasonable to to me.
Sigh... Looks like there's a lot of fun in shrink_dcache_for_umount() -
at the very least, it needs to bump ->d_seq on everything, because with
that change we *can* walk into a filesystem in the middle
On Sun, Sep 29, 2013 at 10:19:59AM -0700, Linus Torvalds wrote:
> I have to say, that when I was working with the dcache lockref code, I
> absolutely _detested_ the magical shrink_dcache_for_umount() code that
> violated all the locking rules.
... and duplicated random-half-of-an-arseload of stuff
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
> fuse_dentry_revalidate() we have a case (reachable with LOOKUP_RCU) where
> we do this:
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode. Not a pretty sight, that... ;-/ First catch: in
[snip]
and another, this one completely unrelated to RCU:
unsigned long gen
On Sun, Sep 29, 2013 at 06:37:50PM +0900, Namhyung Kim wrote:
> The file->f_op check in do_readv_writev() is redundant since all of
> its caller (vfs_readv and vfs_writev) already did the check. The
> same goes to compat_do_readv_writev().
... and the right fix is to kill all those checks complet
On Sun, Sep 29, 2013 at 07:10:47PM +0100, Al Viro wrote:
> FWIW, right now I'm reviewing the subset of fs code that can be hit in
> RCU mode.
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 ar
On Mon, Sep 30, 2013 at 11:13:23AM -0700, Aditya Kali wrote:
> +Ted Ts'o, Tejun Heo, Jens Axboe
>
>
> On 09/30/2013 10:54 AM, Aditya Kali wrote:
> >Hi Al and other fs-developers,
> >
> >Please let me know what you think about this patch.
Don't top-post, please... What prevents a race between MS
On Mon, Sep 30, 2013 at 06:05:03PM -0700, Eric Dumazet wrote:
> Speaking of spinlock contention, the files->file_lock is a good example.
>
> Multi threaded programs hit this spinlock three times per fd :
>
> alloc_fd() / fd_install() / close()
>
> I think fd_install() could be done without thi
On Mon, Sep 30, 2013 at 07:02:23PM -0700, Linus Torvalds wrote:
> Shouldn't a cmpxchg() in just the dup2 code solve that?
>
> If the old value was NULL, you'd have to repeat and go back and see if
> the open_fds[] bit had been cleared in the meantime (ie it's NULL not
> because somebody else is b
On Fri, Sep 20, 2013 at 12:47:32PM -0400, Dave Jones wrote:
> Probably harmless, but still not a nice thing to do.
>
> Signed-off-by: Dave Jones
>
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 368a4d5..75d3556 100644
> --- a/kernel/trace/trace_events.c
> +++ b/
On Sat, Sep 21, 2013 at 01:10:48AM +0200, Michal Nazarewicz wrote:
> On Fri, Sep 20 2013, Al Viro wrote:
> > There's a bunch of failure exits in ffs_fs_mount() with
> > seriously broken recovery logics. Most of that appears to stem
> > from misunderstanding of
On Tue, Sep 17, 2013 at 06:17:45AM +0800, zwu.ker...@gmail.com wrote:
> From: Zhi Yong Wu
>
> The patchset is trying to introduce hot tracking function in
> VFS layer, which will keep track of real disk I/O in memory.
> By it, you will easily know more details about disk I/O, and
> then detect
On Tue, Sep 24, 2013 at 01:50:22AM -0700, Christoph Hellwig wrote:
> Al, can you add this to the next VFS pile?
Applied.
--
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/
On Tue, Sep 24, 2013 at 11:38:54AM -0700, Joe Perches wrote:
> Checkpatch doesn't currently find CamelCase definitions
> of structs, unions or enums.
>
> Add that ability.
Fix your regex. As it is, it catches the things that are not camelcase
by any stretch of definition - [A-Z][a-z]+ will get c
On Wed, Sep 25, 2013 at 08:35:44AM -0700, Joe Perches wrote:
> We disagree.
Obviously.
> I think Propercase should be discouraged.
> ie: Qdisc et al.
Excuse me, but "Joe happens to think that something should be discouraged"
is not a problem. "Joe uses checkpatch.pl as force multiplier, recrui
On Wed, Sep 25, 2013 at 12:22:00PM -0700, Joe Perches wrote:
> It's pretty obvious from fs/binfmt_misc.c that you have
> your own taste.
>
> $ scripts/checkpatch.pl -f --strict fs/binfmt_misc.c
> [...]
> total: 45 errors, 39 warnings, 10 checks, 725 lines checked
*snort*
Most of those are whites
On Wed, Sep 25, 2013 at 01:03:52PM -0700, Andrew Morton wrote:
> On Wed, 25 Sep 2013 21:54:49 +0200 Alexander Holler
> wrote:
>
> > Am 25.09.2013 21:48, schrieb Joe Perches:
> >
> > > As I've said multiple times, checkpatch is a stupid
> > > little tool that can be ignored by anyone with
> > >
To architecture maintainers: please, review the current
situation in git.kernel.org/pub/scm/linux/kernel/git/viro/signal #execve2
and consider sending the corresponding patches for missing architectures.
What's getting done is unification of sys_execve()/kernel_execve()
into
On Fri, Sep 07, 2012 at 07:20:04PM +0100, Al Viro wrote:
> To architecture maintainers: please, review the current
> situation in git.kernel.org/pub/scm/linux/kernel/git/viro/signal #execve2
It should be commit 50343ee2889f5a8cff1aa30110f07b0e01563500 right now.
--
To unsubscribe fro
On Fri, Sep 07, 2012 at 07:43:36PM +, Arnd Bergmann wrote:
> > + asm("addx0, %0, %1\n\t"
> > + "movx1, %2\n\t"
> > + "movx2, %3\n\t"
> > + "bl memmove\n\t"/* copy regs to top of stack */
> > + "movx27, #0\
On Mon, Sep 10, 2012 at 08:47:53AM +0800, Fengguang Wu wrote:
> Al,
>
> Something bad happens since the below commit. Because commit [12/18] f411932
> was not tested, it might also be the first bad commit.
There's a damn good reason why the branch is called the way it's called ;-)
It's missing a
On Mon, Sep 10, 2012 at 09:07:07AM +0800, Fengguang Wu wrote:
> Not sure if it's an unrelated warning, but anyway.
>
> commit: c2865bb326476f031ce7121e876c656cdc12c894 [13/18] x86, um/x86: switch
> to generic sys_execve and kernel_execve
[commit in experimental-kernel_thread, not one in execve2/
On Mon, Sep 10, 2012 at 11:40:11PM +1000, Greg Ungerer wrote:
> Hi Al,
>
> On 09/08/2012 04:20 AM, Al Viro wrote:
> > To architecture maintainers: please, review the current
> >situation in git.kernel.org/pub/scm/linux/kernel/git/viro/signal #execve2
> >and conside
On Fri, Oct 05, 2012 at 05:07:47PM +0100, Catalin Marinas wrote:
> Al,
>
> On 1 October 2012 22:38, Al Viro wrote:
> > Right now the tree lives in
> > git.kernel.org/pub/scm/linux/kernel/git/viro/signal
> > experimental-kernel_thread
> > Some of t
On Fri, Oct 05, 2012 at 09:03:09PM +0900, ? wrote:
> +static int f2fs_create(struct inode *dir, struct dentry *dentry, umode_t
> mode,
> + bool excl)
> +{
> + struct super_block *sb = dir->i_sb;
> + struct f2fs_sb_info *sbi = F2FS_SB(sb);
On Sun, Oct 07, 2012 at 06:55:34PM +0200, Oleg Nesterov wrote:
> Hmm. I know nothing about arch/alpha and I can't understand its entry.S.
> But _it seems_ to me that do_notify_resume() is called with irqs disabled.
> If this is true, then imho arch/alpha should be fixed.
>
> Before this commit ta
On Sun, Oct 07, 2012 at 07:33:36PM +0200, Oleg Nesterov wrote:
> > Um... There's a bunch of architectures that are in the same situation.
> > grep for do_notify_resume() and you'll see...
>
> And every do_notify_resume() should be changed anyway, do_signal() and
> tracehook_notify_resume() shoul
On Sun, Oct 07, 2012 at 08:32:51PM -0700, Hugh Dickins wrote:
> Thank you, Sasha: this should fix it, and similar in other FSes.
>
>
> [PATCH] tmpfs,ceph,gfs2,isofs,reiserfs,xfs: fix fh_len checking
>
> Fuzzing with trinity oopsed on the 1st instruction of shmem_fh_to_dentry(),
> u64 inum
On Mon, Oct 08, 2012 at 02:58:05PM -0700, Boaz Harrosh wrote:
> Hi Marco
>
> I was sure you guys where pushing this patch through some
> vfs tree. (Hence my Acked-by below). I have just sent Linus
> a pull request for the 3.7 Kernel. I could perhaps append this
> one and resend.
>
> I do want thi
ution into
signal.git#proposed-merge. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus
Shortlog:
Al Viro (26):
x86: get rid of TIF_IRET hackery
get rid of generic instances of asm/exec.h
the only place that needs to include asm/exec.h is linux
On Tue, Oct 09, 2012 at 05:55:12PM +0200, Marco Stornelli wrote:
> Thanks Al. For me there aren't problems to push it via Al or via
> other trees. For example the patch for ext4 is in Ted's tree. You
> tell me what you want and I do it :)
Um... Then I'd better drop the ext4 part and hold the fin
On Tue, Oct 09, 2012 at 04:09:18PM -0700, Mark Moseley wrote:
> On Fri, Sep 16, 2011 at 5:12 PM, John Feuerstein wrote:
> > Hi,
> >
> > I would like to audit all changes to a directory tree using the linux
> > auditing system[1].
> >
> > # auditctl -a exit,always -F dir=/etc/ -F perm=wa
> >
> > It
On Tue, Oct 09, 2012 at 04:09:18PM -0700, Mark Moseley wrote:
> If you see my recent linux-audit posting, another related thing (at
> least as far as missing relevant information in the logs) is that the
> audit logs are logging pathnames relative to the chroot, instead of
> the pathnames relative
On Tue, Oct 09, 2012 at 04:47:17PM -0700, Mark Moseley wrote:
> > BTW, what makes you think that container's root is even reachable from
> > "the host's /"? There is no such thing as "root of the OS itself";
> > different
> > processes can (and in case of containers definitely do) run in differen
On Tue, Oct 09, 2012 at 03:48:16PM -0400, Chris Metcalf wrote:
> On 10/1/2012 5:38 PM, Al Viro wrote:
> > There's an interesting ongoing project around kernel_thread() and
> > friends, including execve() variants. I really need help from architecture
> > maintainers
On Mon, Oct 08, 2012 at 04:18:06PM -0400, David Miller wrote:
>
> There is an attempt to fix a bad interaction between syscall tracing
> and force_successful_syscall() from Al Viro, but it needs to be redone
> as it introduced regressions and thus had to be reverted for now.
>
>
On Fri, Nov 30, 2012 at 01:58:18PM +, Myklebust, Trond wrote:
> The reason for the choice of d_drop over d_invalidate() is the d_count
> checks. It really doesn't matter whether or not the client thinks it has
> users for a directory if the server is telling you that it is ESTALE. So
> we forc
On Wed, Dec 05, 2012 at 04:08:18PM +, James Hogan wrote:
> other work not included:
> * switch to generic kernel_{thread,execve} (will be posted separately to
> aid review)
> other changes:
...
> * switch to generic sys_execve
... which should've broken your kernel_execve().
--
To unsubscr
> + if (__copy_from_user(&st, &frame->uc.uc_stack, sizeof(st)))
> + goto badframe;
> + /* It is more difficult to avoid calling this function than to
> +call it and ignore errors. */
> + do_sigaltstack((__force const stack_t __user *)&st, NULL, regs->REG_SP);
"Dear
On Wed, Dec 05, 2012 at 04:08:41PM +, James Hogan wrote:
> +TBIRES tail_end(TBIRES State, unsigned long orig_syscall)
> +{
> + struct pt_regs *regs = (struct pt_regs *)State.Sig.pCtx;
> + unsigned long flags;
> +
> + if (user_mode(regs)) {
> + local_irq_enable();
> +
On Wed, Dec 05, 2012 at 05:11:32PM +, Al Viro wrote:
> On Wed, Dec 05, 2012 at 04:08:18PM +, James Hogan wrote:
>
> > other work not included:
> > * switch to generic kernel_{thread,execve} (will be posted separately to
> > aid review)
>
> > other chang
On Wed, Oct 17, 2012 at 04:27:06PM +0200, Michal Simek wrote:
> In the patch above there is directly used current_pt_regs() function
> which works good for newly created threads
> when pt_regs are exactly in current_pt_regs() position but not for
> pt_regs which are saved on the stack
> which is t
On Wed, Oct 17, 2012 at 05:07:03PM +0100, Al Viro wrote:
> What happens during boot is this:
> * init_task (not to be confused with init) is used as current during
> infrastructure initializations. Once everything needed for scheduler and
> for working fork is set, we spawn
On Wed, Oct 17, 2012 at 03:02:15PM +0100, Catalin Marinas wrote:
> Hi Al,
>
> On 15 October 2012 02:30, Al Viro wrote:
> > arch-arm64 - patches from maintainer with minor followup folded
>
> Thanks for updating the arm64 branch. I've adapted the changes, tested
> an
On Wed, Oct 17, 2012 at 09:47:50PM +0800, yan yan wrote:
> [ 896.957678] BUG: unable to handle kernel paging request at 72747461
> [ 896.957824] IP: [] strlen+0x12/0x20
strlen() getting 4 bytes out of an ASCII string ("attr") as pointer.
Lovely...
> [ 896.961222] [] audit_log_untrustedstring+
On Wed, Oct 17, 2012 at 08:55:49PM -0700, Hugh Dickins wrote:
> On Wed, 17 Oct 2012, David Rientjes wrote:
>
> > Commit 38f38657444d ("xattr: extract simple_xattr code from tmpfs") moved
> > some code from tmpfs but introduced a subtle bug along the way.
> >
> > If the name passed to simple_xattr
On Fri, Oct 19, 2012 at 04:43:09PM +0800, Guan Xuetao wrote:
> From: Al Viro
>
> Signed-off-by: Al Viro
> Acked-and-Tested-by: Guan Xuetao
You mean, it worked modulo obvious missing ')'? Wow... OK, merged
into signal.git#for-next, obviously in no-rebase mode (as t
On Tue, Oct 16, 2012 at 11:35:08PM +0100, Al Viro wrote:
> 1. Basic rules for process lifetime.
> Except for the initial process (init_task, eventual idle thread on the boot
> CPU) all processes are created by do_fork(). There are three classes of
> those: kernel threa
On Fri, Oct 19, 2012 at 09:33:18AM -0700, Dmitry Torokhov wrote:
> We are now removing instance of character device corresponding to input
> device when input device disappears.
>
> Ah, I know... cdev is embedded in evdev, but lives longer.. I do want to
> keep cdev embedded as it allows me to ea
On Fri, Oct 19, 2012 at 05:16:50PM +, Luck, Tony wrote:
> > Surprisingly enough, ia64 one seems to work on actual hardware; I have sent
> > Tony an incremental patch cleaning copy_thread() up, waiting for results of
> > testing that on SMP box.
>
> Tiny bit faster than plain 3.7-rc1. lmbench3
On Fri, Oct 19, 2012 at 10:36:39AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 19, 2012 at 06:09:51PM +0100, Al Viro wrote:
> > On Fri, Oct 19, 2012 at 09:33:18AM -0700, Dmitry Torokhov wrote:
> >
> > > We are now removing instance of character device corresponding to
On Fri, Oct 19, 2012 at 11:01:53AM -0700, Tony Luck wrote:
> On Fri, Oct 19, 2012 at 10:30 AM, Al Viro wrote:
> > IIRC, the lack of comments on function with unusual calling conventions was
> > the last remaining issue...
>
> Stylistically other asm functions have huge bl
On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote:
> Also provide an optimized current_pt_regs() while we're at it.
Applied. BTW, are you sure you want to record parent's pid and not tid?
Anyway, here's a followup on top of this one (again, completely untested) -
switching to generic
... and fix the race in updating unaligned control ones
Signed-off-by: Al Viro
---
diff --git a/arch/alpha/include/asm/thread_info.h
b/arch/alpha/include/asm/thread_info.h
index 4554ecb..1f8c729 100644
--- a/arch/alpha/include/asm/thread_info.h
+++ b/arch/alpha/include/asm/thread_info.h
On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote:
> First, the compat_sys_execve() declaration provided in
> arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only
> deleted the PTREGS_SYSCALL trampoline declaration, _compat_sys_execve).
>
> However, then arch/til
On Sat, Oct 20, 2012 at 04:34:01PM +0100, Al Viro wrote:
> On Sat, Oct 20, 2012 at 09:06:57AM -0400, Chris Metcalf wrote:
> > First, the compat_sys_execve() declaration provided in
> > arch/tile/include/asm/compat.h isn't right, so I deleted that (you had only
> >
On Sun, Oct 21, 2012 at 12:24:30AM -0700, Dmitry Torokhov wrote:
> In certain cases (for example when a cdev structure is embedded into
> another object whose lifetime is controlled by a separate device object)
> it is beneficial to tie lifetime of another struct device to the lifetime
> of charact
On Mon, Oct 22, 2012 at 08:02:12AM +0300, Linus Torvalds wrote:
> This series looks good to me, and looks to fix the issue about as
> cleanly as it can. Al, holler if you have any concerns, but I'm
> planning on applying it ASAP,
Add my ACKed-by. And from the look of it, we'll need something simi
On Thu, Dec 06, 2012 at 11:17:34AM +, James Hogan wrote:
> Agreed, it looks wrong. Looking at the sh version, is there a particular
> reason to only check for -EFAULT and not the other errors that
> do_sigaltstack can return (-EPERM, -EINVAL, and -ENOMEM)?
See commit fae2ae2a900a5c7bb385fe407
Current situation:
* most of the architectures are OK - alpha arm arm64 c6x frv hexagon ia64 m68k
microblaze mips openrisc parisc sparc s390 tile um unicore32 x86 xtensa
* powerpc *still* awaits an ACK from maintainers; no reports of any breakage
on linux-next and seems to be doing fine on my tes
On Thu, Dec 06, 2012 at 10:09:55PM +, Al Viro wrote:
> "Subtle and undocumented" is an extremely polite way to describe that.
> By now we had at least a dozen architectures step on that trap, simply because
> they had different calling conventions and the same log
On Thu, Dec 06, 2012 at 10:09:55PM +, Al Viro wrote:
> What we need to guarantee is
> * restarts do not happen on signals caught in interrupts or exceptions
> * restarts do not happen on signals caught in sigreturn()
> * restart should happen only once, even if we get throu
On Sun, Dec 09, 2012 at 01:37:33PM -0600, Chris Adams wrote:
> Once upon a time, Tristan Wibberley said:
> >A common idiom on Linux is to open a file and keep the fd open so that
> >the underlying file can be unlinked from its directory. But if the file
> >needs to be read from several differen
On Tue, Dec 11, 2012 at 06:00:00PM +0400, Stanislav Kinsbursky wrote:
> 11.12.2012 00:28, J. Bruce Fields ??:
> >On Thu, Dec 06, 2012 at 06:34:47PM +0300, Stanislav Kinsbursky wrote:
> >>NFSd does lookup. Lookup is done starting from current->fs->root.
> >>NFSd is a kthread, cloned by kthre
401 - 500 of 7633 matches
Mail list logo
