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
On Thu, Apr 11, 2013 at 01:48:26PM -0700, Eric W. Biederman wrote:
> Last time I was looking at this I was noticing that there is a lock
> (mmap_sem?) that is held over every ->vm_op->foo() call. If that is
> true today it should be possible to just grab that lock and change
> vm_ops. That makes
On Fri, Apr 12, 2013 at 04:47:50PM -0700, Linus Torvalds wrote:
> This is a much more generic bug in kobjects, and I would hate to add
> some random workaround for just one case of this bug like you do. The
> more fundamental bug needs to be fixed too.
>
> I think the more fundamental bugfix is to
On Sat, Apr 13, 2013 at 09:42:06PM -0700, Anatol Pomozov wrote:
> > in kobject_cleanup(). Why don't we require kobject_del() before the final
> > kobject_put(), if the sucker had been added? FWIW, I thought it *was*
> > required all along...
>
> But kobject_release/kobject_cleanup function is c
On Mon, Apr 15, 2013 at 05:30:41PM +0200, Miklos Szeredi wrote:
> On Mon, Apr 15, 2013 at 5:08 PM, Miklos Szeredi wrote:
> > For example doing a readlink() on a magic symlink under /proc
> > shouldn't result in a synchronous call to a fuse filesystem. Making
> > fput() synchronous may actually en
On Tue, Apr 16, 2013 at 03:11:13PM +0900, Simon Horman wrote:
> On Thu, Apr 11, 2013 at 02:30:09PM +0100, David Howells wrote:
> > Don't use create_proc_read_entry() as that is deprecated, but rather use
> > proc_create_data() and seq_file instead.
>
> Paul, do you want me to handle this?
FWIW, I
On Fri, May 17, 2013 at 02:35:42PM -0700, Greg Kroah-Hartman wrote:
> 3.9-stable review patch. If anyone has any objections, please let me know.
This is seriously wrong. For 3.9 you _need_ asmlinkage_protect() in that
thing; by the time when that went into the tree, mainline already had
it gener
fset,
then dropping locks and assigning the offset is obviously racy.
Moreover, we _must_ do hpfs_add_pos(), or the machinery in dnode.c
won't modify the sucker on B-tree surgeries.
Signed-off-by: Al Viro
--
diff --git a/fs/hpfs/dir.c b/fs/hpfs/dir.c
index 546f6d3..834ac13 100644
--- a/fs/hpfs/dir.
On Tue, May 21, 2013 at 03:22:44PM -0700, Linus Torvalds wrote:
> The *one* insane exception is ncpfs, which actually wants to look at
> the parent (ie directory) inode data in order to decide if it should
> use a case sensitive hash or not. However, even in that case, I'd
> argue that we could jus
On Wed, May 22, 2013 at 11:48:51PM -0400, Vince Weaver wrote:
>
> In case anyone cares, the Oops is happening here:
>
> 1a56: 48 c1 e8 0c shr$0xc,%rax
> 1a5a: 48 ff c0inc%rax
> > 1a5d: f0 48 29 45 60 lock sub %rax,0x60(%rbp)
On Fri, May 24, 2013 at 08:21:08PM -0700, Linus Torvalds wrote:
> On Tue, May 21, 2013 at 3:22 PM, Linus Torvalds
> wrote:
> >
> > Untested patch attached. It compiles cleanly, looks sane, and most of
> > it is just making the function prototypes look much nicer. I think it
> > works.
>
> Ok, her
-stable fodder; assorted deadlock fixes. Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (3):
Don't bother with redoing rw_verify_area() from default_file_splice_from()
Nest rename_lock inside vfsmount_lock
houghts ?
Actually, that's my fault - check lost in patch reordering. My apologies ;-/
Eventually, we want that in fs/splice.c side of things (no point repeating it
for every buffer, after all), but for now this is the obvious minimal fix.
Signed-off-by: Al Viro
---
diff --git a/fs/read_writ
On Wed, Mar 27, 2013 at 09:33:35AM -0700, Linus Torvalds wrote:
> Applied.
>
> Do we actually have files with NULL f_ops pointers? Should we? What
> could we possibly do with a file descriptor that doesn't have any
> fops?
We shouldn't, at least not for something that has been successfully
opene
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> Hi Al,
>
> Hans de Bruin found a regression due to one of your changes. I asked him to
> test a fix and he reported back that it worked. (Thanks!) Can you see if you
> agree with the fix? Patch is attached due to webmail..
On Mon, Apr 01, 2013 at 04:58:05AM -0700, Anatol Pomozov wrote:
> lo->lo_flags |= LO_FLAGS_PARTSCAN;
> if (lo->lo_flags & LO_FLAGS_PARTSCAN)
> ioctl_by_bdev(bdev, BLKRRPART, 0);
> +
> + /* bdev lifecycle is defined by its bd_inode (see
> + * struct bdev_in
On Wed, Mar 27, 2013 at 05:45:06PM +, Al Viro wrote:
> We shouldn't, at least not for something that has been successfully
> opened. I've a patch series cleaning that up a bit in the local
> queue; will check for bitrot and throw into for-next.
Egads... OK, that has gone
On Mon, Apr 01, 2013 at 02:00:29PM -0700, Greg Kroah-Hartman wrote:
> > IOW, how do we deal with a race between attempt to open a debugfs file and
> > its removal on driver unload? Greg?
>
> Hm, I thought the i_fop->owner thing would be the needed protection, but
It will be, if you manage to fe
On Mon, Apr 01, 2013 at 02:44:36PM -0700, Greg Kroah-Hartman wrote:
> > > I guess you are right, it will not. I guess we need to do what
> > > character devices do and have an "intermediate" fops in order to protect
> > > this. Would that work?
> >
> > You mean, with reassigning ->f_op in ->open
On Tue, Apr 02, 2013 at 12:27:18AM +0100, Al Viro wrote:
> On Mon, Apr 01, 2013 at 02:44:36PM -0700, Greg Kroah-Hartman wrote:
> > > > I guess you are right, it will not. I guess we need to do what
> > > > character devices do and have an "intermediate"
On Tue, Apr 02, 2013 at 11:26:27AM +1100, Stephen Rothwell wrote:
> Hi Al,
>
> After merging the vfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/kernel/lparcfg.c:44:31: error: 'proc_ppc64_lparcfg' defined but
> not used [-Werror=unused-variable]
On Mon, Apr 01, 2013 at 10:58:55PM -0700, Anatol Pomozov wrote:
> >>
> >> loop_set_fd/loop_clr_fd (and any other loop ioctl) is called under
> >> loop_device->lo_ctl_mutex.
> >
> > Ok, good enough for me, I applied it, and it's commit
> > c1681bf8a7b1b98edee8b862a42c19c4e53205fd in my tree.
> >
> >
On Fri, Mar 08, 2013 at 10:30:01AM -0800, Linus Torvalds wrote:
> I must be missing something, and I wonder if the thing I'm missing is
> that with OPEN_PATH we may now have open calls that don't actually
> have FMODE_READ or FMODE_WRITE set at all.
With OPEN_PATH we don't call ->open() (or anyth
ut the following?
make nd_jump_link() fail sanely when asked to jump into a symlink
Signed-off-by: Al Viro
---
diff --git a/fs/namei.c b/fs/namei.c
index 57ae9c8..9029d60 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -682,13 +682,18 @@ static inline void path_to_nameidata(const struct path
On Fri, Mar 08, 2013 at 01:26:49PM -0500, J??rn Engel wrote:
> On Fri, 8 March 2013 10:30:01 -0800, Linus Torvalds wrote:
> >
> > Hmm. So I've been trying to figure this out, and I really don't see
> > it. Every single pipe open routine *should* make sure that the inode
> > has an inode->i_pipe fi
On Thu, Mar 07, 2013 at 02:50:55PM -0800, Linus Torvalds wrote:
> and you get the oops, because when it follows that pseudo-symlink for
> fd3, it will hit that symlink we just looked up. And trigger the
> BUG_ON() you see.
>
> Al, I think the BUG_ON() is simply bogus. Should we just remove it? Or
On Sun, Mar 10, 2013 at 10:10:47PM +, Al Viro wrote:
> On Fri, Mar 08, 2013 at 10:30:01AM -0800, Linus Torvalds wrote:
>
> > I must be missing something, and I wonder if the thing I'm missing is
> > that with OPEN_PATH we may now have open calls that don't act
On Mon, Mar 11, 2013 at 08:10:10AM -0700, Linus Torvalds wrote:
> On Sun, Mar 10, 2013 at 5:35 PM, Al Viro wrote:
> >
> > Hmm... How the devil would things like pipe_read_open() get called, anyway?
> > pipe_rdwr_open() can be called, all right - that happens if you do pip
. There
probably will be another pull request, but that stuff won't be in it.
Sorry.
In case you prefer to pull it as-is and resolve the conflicts
in merge commit, it's in the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog
On Wed, Aug 01, 2012 at 04:30:22PM -0700, H. Peter Anvin wrote:
> On 08/01/2012 04:09 PM, Meredydd Luff wrote:
> >>> #
> >>> # x32-specific system call numbers start at 512 to avoid cache impact
> >>
> >> I think that should be common, not 64 (as should kcmp be).
> >
> > I copied the original ex
On Thu, Aug 02, 2012 at 10:14:53AM +0100, Meredydd Luff wrote:
> On Thu, Aug 2, 2012 at 7:55 AM, Al Viro wrote:
> >> This means you need an x32 version of the function -- execve
> >> unfortunately is one of the few system calls which require a special x32
> >> v
On Fri, Aug 03, 2012 at 05:30:28PM +0800, Fengguang Wu wrote:
> Hi Al,
>
> > I got a boot warning on commit
> >
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal.git
> > execve2
> > head: 1ade99215ed3c334a544b9e1773602ff0f0251ab
> > commit: 1ade99215ed3c334a544b9e1773602ff0
On Fri, Aug 03, 2012 at 11:37:53AM +0200, Jiri Slaby wrote:
> On 08/03/2012 03:46 AM, Fengguang Wu wrote:
> > Hi all,
>
> Hi,
>
> > The IRQ should be disabled somewhere in the path walk, which makes
> > the GFP_KERNEL allocation in uart_startup() no longer valid..
> >
> > [0.499537] kworker/
On Fri, Aug 03, 2012 at 01:23:29PM -0700, Linus Torvalds wrote:
> On Thu, Aug 2, 2012 at 11:47 PM, Artem Bityutskiy wrote:
> >
> > We have had 11 of 13 pieces of the 'sync_supers()' removal patch-sets
> > merged. The 12th piece removes dead code in exofs was supposed to go
> > through the exofs tr
On Sat, Aug 04, 2012 at 08:38:35AM +0300, Artem Bityutskiy wrote:
> On Sat, 2012-08-04 at 05:46 +0100, Al Viro wrote:
> > OK... I've ported Artem's patchset on top of exofs merge; Artem, could
> > you check if you are OK with the result currently in vfs.git#for-linus
On Sat, Aug 04, 2012 at 03:51:01PM +0800, Dongsheng Song wrote:
> On Sat, Aug 4, 2012 at 2:19 PM, Al Viro wrote:
> >
> > Documentation/sysctl/vm.txt.rej| 21 +
>
> vm.txt.rej ???
Grrr... git add Documentation/sysctl/ during conflict-resolving in git
On Sat, Aug 04, 2012 at 12:59:31PM +0200, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest, using latest -next
> kernel, I've stumbled on the dump below.
>
> I think this is the result of commit 765927b2 ("switch dentry_open() to
> struct path, make it grab r
On Tue, Aug 07, 2012 at 01:04:12PM +0800, Fengguang Wu wrote:
> FYI, here is a different back trace on that commit.
>
> [3.255043] ==
> [3.255052] [ INFO: possible circular locking dependency detected ]
> [3.255052] 3.5.0-rc6-bisect-
On Tue, Aug 21, 2012 at 05:22:27PM -0400, Jim Rees wrote:
> J. Bruce Fields wrote:
>
> From: "J. Bruce Fields"
>
> I've seen a couple examples recently where we've gotten this wrong.
> Maybe something like this would help? Is there some better way?
>
> (Approximation due to Jim Ree
On Tue, Aug 21, 2012 at 04:38:23PM -0700, David Miller wrote:
> 8) Fix all the netprio file handling bugs found by Al Viro, from John
>Fastabend.
Great, I was just about to start figuring out how to deal with inter-tree
dependencies; now I'll just rebase my internal queue ;-)
On Wed, Aug 22, 2012 at 01:27:21PM +0800, Michael Wang wrote:
> And can we make sure that it is safe to sleep(schedule) at this point?
> It may need some totally testing to cover all the situation...
task_work callback can bloody well block, so yes, it is safe. Hell,
we are doing final close fro
Assorted fixes, with an unexpected detour into vfio refcounting logics
(fell out when digging in an analog of eventpoll race in there). Please,
pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog:
Al Viro (7):
mqueue: lift
On Thu, Aug 23, 2012 at 07:22:07PM +0200, wbrana wrote:
> - wastes time of developers who can spend their time supporting X32
> instead of x86-32 or support x86-64 only as 99% of users will be able
> to run x86-64 software if x86-32 will be dropped
How much of your time is being wasted? I don't
On Thu, Aug 23, 2012 at 08:40:19PM +0200, wbrana wrote:
> On 8/23/12, David Daney wrote:
> > I suspected as much. So from your point of view, this issue is of
> > exactly zero importance.
> I'm using software which is developed by others.
... which gives you no right whatsoever to demand anythi
On Thu, Aug 23, 2012 at 02:43:24PM +0400, Cyrill Gorcunov wrote:
> This patch prepares the ground for further extension of
> /proc/pid/fd[info] handling code by moving fdinfo handling
> code into fs/proc/fd.c.
>
> I think such move makes both fs/proc/base.c and fs/proc/fd.c
> easier to read.
BTW,
On Sat, Aug 25, 2012 at 09:39:58PM +0400, Cyrill Gorcunov wrote:
> On Sat, Aug 25, 2012 at 06:16:05PM +0100, Al Viro wrote:
> > On Thu, Aug 23, 2012 at 02:43:24PM +0400, Cyrill Gorcunov wrote:
> > > This patch prepares the ground for further extension of
> > > /proc/pi
On Sat, Aug 25, 2012 at 10:58:29PM +0400, Cyrill Gorcunov wrote:
> On Sat, Aug 25, 2012 at 06:55:04PM +0100, Al Viro wrote:
> > > Well, this could be simplified indeed, if I understand you correctly
> > > you propose just save f_mode in flexible array and use it instead
> &
On Sat, Aug 25, 2012 at 11:43:25PM +0400, Cyrill Gorcunov wrote:
> Would the patch below improve the code? Look, I've not dropped
> find_inode_number call since it's a bit unclear for me what
> would happen if !child case hit
>
> child = d_lookup(dir, &qname);
> if (!child) {
>
On Sat, Aug 25, 2012 at 06:16:05PM +0100, Al Viro wrote:
> On Thu, Aug 23, 2012 at 02:43:24PM +0400, Cyrill Gorcunov wrote:
> > This patch prepares the ground for further extension of
> > /proc/pid/fd[info] handling code by moving fdinfo handling
> > code into fs/proc/fd.c.
On Thu, Aug 23, 2012 at 02:43:25PM +0400, Cyrill Gorcunov wrote:
> This patch converts /proc/pid/fdinfo/ handling routines to seq-file which
> is needed to extend seq operations and plug in auxiliary fdinfo provides
> from subsystems like eventfd/eventpoll/fsnotify.
>
> Note the proc_fd_link no lo
On Sun, Aug 26, 2012 at 06:28:20PM +0400, Cyrill Gorcunov wrote:
> On Sun, Aug 26, 2012 at 03:46:53AM +0100, Al Viro wrote:
> >
> > IMO doing that at open() time is just a headache for no good reason -
> > resolving descriptor to struct file * at read() time as we do
On Fri, Sep 14, 2012 at 06:49:01PM -0700, Jacob Sowles wrote:
> Is there an easy way to get the path to where debugfs is mounted? I
> found a function called debugfs_find_mountpoint(), which is exactly
> what I want, but it’s not exported, so I can’t use it. The only
> exported debugfs functions th
On Fri, Sep 14, 2012 at 07:07:43PM -0700, Jacob Sowles wrote:
> Multiple instances of my code can be run simultaneously, and all
> instances use the same debugfs directory, so I need the path to the
> debugfs root directory so that I can use filp_open to get the dentry
> for that directory.
What's
On Fri, Sep 14, 2012 at 07:17:12PM -0700, Jacob Sowles wrote:
> The first instance of my code calls debugfs_create_file and stores a
> pointer to the dentry of that directory. But when the second instance
> calls debugfs_create_file, the function returns NULL because that
> directory already exists
On Mon, Sep 10, 2012 at 06:20:01PM -0400, Mark Salter wrote:
> C6X works fine with these patches to switch over to generic code.
>
>
> Mark Salter (2):
> c6x: implement ret_from_kernel_execve() and switch to generic
> kernel_execve()
> c6x: switch to generic sys_execve()
>
> arch/c6x/in
On Mon, Sep 17, 2012 at 10:23:30PM +0200, Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> IBM reported a deadlock in select_parent(). This was found to be caused by
> taking rename_lock when already locked when restarting the tree traversal.
>
> There are two cases when the traversal needs to
On Mon, Sep 17, 2012 at 11:29:10AM +0200, Michal Simek wrote:
> Hi Al,
>
> On 09/07/2012 08:20 PM, 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 Tue, Sep 18, 2012 at 08:19:21PM +0200, Geert Uytterhoeven wrote:
> Still not fixed after almost 4 months...
Gyah... I really need to trim that pile of internal branches; the fixed
commit had not been cherry-picked into for-next. My apologies ;-/
--
To unsubscribe from this list: send the lin
On Wed, Sep 19, 2012 at 02:21:56PM +1000, James Morris wrote:
> On Tue, 18 Sep 2012, Kasatkin, Dmitry wrote:
>
> > I looked to and found that there is a possibility to to
> > add additional flag for sb->s_flags.
> > For example
> >
> > #define MS_NOT_IMA (1<<25) /* NOT_IMA */
> > #d
On Wed, Sep 19, 2012 at 05:50:34PM +0530, Vineet Gupta wrote:
> Hi Al,
>
> It must be noted that despite having seemingly independent
> __ARCH_WANT_(KERNEL|SYS)_EXECVE, arches which have a kernel syscall trap
> based kernel_execve(), e.g. MIPS, can't implement __ARCH_WANT_SYS_EXECVE
> alone - the
On Thu, Feb 21, 2008 at 01:13:48AM +1100, Stephen Rothwell wrote:
> Hi Miklos,
>
> On Tue, 19 Feb 2008 14:32:28 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> >
> > I've created a git tree with the following mounts related stuff:
> >
> > - read-only bind mounts
> > - /proc//mountinfo
> >
On Thu, Feb 21, 2008 at 01:42:56PM +0100, Johannes Berg wrote:
> >> [patch doing CHECKFLAGS += -D__CHECK_ENDIAN__ in the
> >> net/mac80211/Makefile]
>
> > I would prefer it to be kernel wide enabled.
> > Tried a defconfig build.
>
> Hm. I tend to think there was a reason for this, since this is a
On Thu, Feb 21, 2008 at 09:52:36AM -0800, Harvey Harrison wrote:
Could you please use more descriptive names? NULL noise removal
is not the same as shadowing or endianness annotations or endianness
fixes or __user/__iomem annotations/fixes, etc.
--
To unsubscribe from this list: send the line "un
On Fri, Feb 15, 2008 at 12:35:23PM +0100, Mikael Pettersson wrote:
> Andi Kleen writes:
> > Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> > >this subdir;
> > > 3. sysctl inodes are now smaller than the procfs ones.
> >
> > That's always a good thing.
> >
> > > Note: update your initscr
On Fri, Feb 22, 2008 at 12:16:45PM +1030, David Newall wrote:
> Krzysztof Halasa wrote:
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >> I'm personally of the opinion that a lot of checkpatch "fixes" are
> >> anything but. That mainly concerns fixing overlong lines
> >>
> >
> > Perhaps we
On Fri, Feb 22, 2008 at 03:23:45AM +0100, Krzysztof Halasa wrote:
> Al Viro <[EMAIL PROTECTED]> writes:
>
> > ... if your style is lousy. I agree that situation with printks is
> > not normal in that respect and I certainly have no love for the
> > checkpatch nons
On Fri, Feb 22, 2008 at 06:21:16PM +1100, Stephen Rothwell wrote:
> On Fri, 22 Feb 2008 17:04:21 +1100 Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> >
> > Status of my local build tests is at
> > http://kisskb.ellerman.id.au/kisskb/branch/9/. The sparc builds have
> > been mostly disabled while I
601 - 700 of 6610 matches
Mail list logo
