* Re: next-20090630: audit/fsnotify build failure
From: Eric Paris @ 2009-07-01 12:38 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next
In-Reply-To: <a4423d670907010507g5c1d205epd8383319f9db6aa@mail.gmail.com>
On Wed, 2009-07-01 at 16:07 +0400, Alexander Beregalov wrote:
> Hi Eric
>
> Another problem today (0701)
>
> kernel/auditfilter.c: In function 'audit_data_to_entry':
> kernel/auditfilter.c:501: error: expected expression before '{' token
> kernel/auditfilter.c: In function 'audit_add_rule':
> kernel/auditfilter.c:891: error: expected expression before '{' token
>
> CONFIG_AUDIT_WATCH is not set
This one is just me being stupid and committing the wrong version to the
tree :( Thank you so much for testing this!
s/{ -EINVAL }/-EINVAL/
-Eric
^ permalink raw reply
* Re: linux-next: boot failure
From: Eric Paris @ 2009-07-01 12:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20090701160014.595e1338.sfr@canb.auug.org.au>
On Wed, 2009-07-01 at 16:00 +1000, Stephen Rothwell wrote:
> Hi Eric,
>
> next-20090630 failed to boot (on PowerPC Power5/6 machines):
>
> calling .audit_watch_init+0x0/0x80 @ 1
> Unable to handle kernel paging request for data at address 0xffffffffffffffff
> Faulting instruction address: 0xc00000000008b440
> cpu 0x0: Vector: 300 (Data Access) at [c0000000be683990]
> pc: c00000000008b440: .srcu_read_lock+0x20/0x40
> lr: c0000000001607cc: .fsnotify_recalc_global_mask+0x2c/0xa0
> sp: c0000000be683c10
> msr: 8000000000009032
> dar: ffffffffffffffff
> dsisr: 40010000
> current = 0xc0000000be67e000
> paca = 0xc00000000093b200
> pid = 1, comm = swapper
> enter ? for help
> [link register ] c0000000001607cc .fsnotify_recalc_global_mask+0x2c/0xa0
> [c0000000be683c10] c0000000be683ca0 (unreliable)
> [c0000000be683ca0] c000000000160bc0 .fsnotify_obtain_group+0x1e0/0x260
> [c0000000be683d60] c0000000007879e4 .audit_watch_init+0x34/0x80
> [c0000000be683de0] c00000000000947c .do_one_initcall+0x6c/0x1e0
> [c0000000be683ee0] c00000000076fd6c .kernel_init+0x23c/0x2c0
> [c0000000be683f90] c00000000002a9bc .kernel_thread+0x54/0x70
Hmmmm, I'm looking. The best I can guess is that the srcu struct in
fsnotify_recalc_global_mask hasn't been initialized. Both
audit_watch_init() (where you are having problems) and fsnotify_init()
(where we initialize the srcu struct) use subsys_initcall()
I will check the makefiles to see if kernel/built-in.o is linked in
before fs/buildin-in.o. I don't see a reason why audit watches need to
be that early in the kernel init process. This isn't happening on my
system so I'm asking if anyone hitting it can apply this patch and test?
Audit: audit watch init should not be before fsnotify init
From: Eric Paris <eparis@redhat.com>
Audit watch init and fsnotify init both use subsys_initcall() but since the
audit watch code is linked in before the fsnotify code the audit watch code
would be using the fsnotify srcu struct before it was initialized. This
patch fixes that problem by moving audit watch init to device_initcall() so
it happens after fsnotify is ready.
---
kernel/audit_watch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 177e4b8..1295120 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -584,4 +584,4 @@ static int __init audit_watch_init(void)
}
return 0;
}
-subsys_initcall(audit_watch_init);
+device_initcall(audit_watch_init);
^ permalink raw reply related
* Re: linux-next: manual merge of the kvm tree with Linus' tree
From: Gregory Haskins @ 2009-07-01 12:31 UTC (permalink / raw)
To: Avi Kivity, Davide Libenzi
Cc: Stephen Rothwell, linux-next, Linux Kernel Mailing List,
Andrew Morton
In-Reply-To: <4A4B1106.8000506@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]
Avi Kivity wrote:
> On 07/01/2009 10:10 AM, Davide Libenzi wrote:
>> On Wed, 1 Jul 2009, Stephen Rothwell wrote:
>>
>>
>>> Hi Avi,
>>>
>>> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
>>> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
>>> revised interface and cleanups") from Linus' tree and commit
>>> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
>>> notified about the eventfd file* going away") from the kvm tree.
>>>
>>> Overlapping changes. I fixed it up (see below), but don't know if this
>>> is the correct fix.
>>>
>>> --
>>> Cheers,
>>> Stephen Rothwell sfr@canb.auug.org.au
>>>
>>> diff --cc fs/eventfd.c
>>> index 31d12de,72f5f8d..0000000
>>> --- a/fs/eventfd.c
>>> +++ b/fs/eventfd.c
>>> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>>> {
>>> struct eventfd_ctx *ctx = file->private_data;
>>>
>>> - wake_up_poll(&ctx->wqh, POLLHUP);
>>> + /*
>>> + * No need to hold the lock here, since we are on the file
>>> cleanup
>>> + * path and the ones still attached to the wait queue will be
>>> + * serialized by wake_up_locked_poll().
>>> + */
>>> + wake_up_locked_poll(&ctx->wqh, POLLHUP);
>>> - kfree(ctx);
>>> + eventfd_ctx_put(ctx);
>>> return 0;
>>> }
>>>
>>
>> That's fine.
>> There are a couple of extra spaces before the last two -+ in that patch
>> though ;)
>>
>
> No, that's a git N-way diff format. The first column shows the
> changes relative to mainline by kvm.git, and the second the changes to
> kvm.git made by mainline.
>
> I've merged and will push soon, which will resolve the conflict, but I
> think the patch wake_up_locked_poll() is better off in mainline rather
> than kvm.git.
Just to be clear: the final form will need to be wake_up_poll(), not
wake_up_locked_poll. However, I think what Steven did was optimal
because converting to the locked form without coordinating with kvm.git
would break bisectability.
In the irqfd-fixes series, I had 3 patches related to this situation
(1/5 to prepare to change, 2/5 was Davide's patch, and 3/5 did the final
change-over). Now that the vast majority of Davide's work is in
mainline+kvm.git, here is my proposal:
*) drop 2/5 (already upstream, sans the locked POLLHUP)
*) fold 1/5 + 3/5, and add new fs/eventfd.c hunk to convert to locked
variant
*) drop 5/5
Sound good?
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree with Linus' tree
From: Gregory Haskins @ 2009-07-01 12:30 UTC (permalink / raw)
To: Avi Kivity, Davide Libenzi
Cc: Stephen Rothwell, linux-next, Linux Kernel Mailing List,
Andrew Morton
In-Reply-To: <4A4B1106.8000506@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]
Avi Kivity wrote:
> On 07/01/2009 10:10 AM, Davide Libenzi wrote:
>> On Wed, 1 Jul 2009, Stephen Rothwell wrote:
>>
>>
>>> Hi Avi,
>>>
>>> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
>>> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
>>> revised interface and cleanups") from Linus' tree and commit
>>> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
>>> notified about the eventfd file* going away") from the kvm tree.
>>>
>>> Overlapping changes. I fixed it up (see below), but don't know if this
>>> is the correct fix.
>>>
>>> --
>>> Cheers,
>>> Stephen Rothwell sfr@canb.auug.org.au
>>>
>>> diff --cc fs/eventfd.c
>>> index 31d12de,72f5f8d..0000000
>>> --- a/fs/eventfd.c
>>> +++ b/fs/eventfd.c
>>> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
>>> {
>>> struct eventfd_ctx *ctx = file->private_data;
>>>
>>> - wake_up_poll(&ctx->wqh, POLLHUP);
>>> + /*
>>> + * No need to hold the lock here, since we are on the file
>>> cleanup
>>> + * path and the ones still attached to the wait queue will be
>>> + * serialized by wake_up_locked_poll().
>>> + */
>>> + wake_up_locked_poll(&ctx->wqh, POLLHUP);
>>> - kfree(ctx);
>>> + eventfd_ctx_put(ctx);
>>> return 0;
>>> }
>>>
>>
>> That's fine.
>> There are a couple of extra spaces before the last two -+ in that patch
>> though ;)
>>
>
> No, that's a git N-way diff format. The first column shows the
> changes relative to mainline by kvm.git, and the second the changes to
> kvm.git made by mainline.
>
> I've merged and will push soon, which will resolve the conflict, but I
> think the patch wake_up_locked_poll() is better off in mainline rather
> than kvm.git.
Just to be clear: the final form will need to be wake_up_poll(), not
wake_up_locked_poll. However, I think what Steven did was optimal
because converting to the locked form without coordinating with kvm.git
would break bisectability.
In the irqfd-fixes series, I had 3 patches related to this situation
(1/5 to prepare to change, 2/5 was Davide's patch, and 3/5 did the final
change-over). Now that the vast majority of Davide's work is in
mainline+kvm.git, here is my proposal:
*) drop 2/5 (already upstream, sans the locked POLLHUP)
*) fold 1/5 + 3/5, and add new fs/eventfd.c hunk to convert to locked
variant
*) drop 5/5
Sound good?
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]
^ permalink raw reply
* Re: linux-next: boot failure
From: Stephen Rothwell @ 2009-07-01 12:20 UTC (permalink / raw)
To: Sachin Sant; +Cc: Eric Paris, linux-next, LKML
In-Reply-To: <4A4B4E1B.6090900@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
Hi Sachin,
On Wed, 01 Jul 2009 17:22:59 +0530 Sachin Sant <sachinp@in.ibm.com> wrote:
>
> I too am facing similar issue on both Power and x86.
> Culprit seems to be 2nd patch in the above list.
>
> commit e1b79967e2b29839d16c12b534597a15d8630fc4
> audit: convert audit watches to use fsnotify instead of inotify
>
> I wasn't able to remove only patch 2 because of dependencies
> on other patches. After i reverted patches 2 to 7 in the above
> list, i was able to boot the machine. Then i applied patch 2
> and the machine failed to boot.
Thanks for tracking this down. Now we just need a solution :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Alexander Beregalov @ 2009-07-01 12:07 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-next
In-Reply-To: <1246384996.22562.19.camel@dhcp235-23.rdu.redhat.com>
Hi Eric
Another problem today (0701)
kernel/auditfilter.c: In function 'audit_data_to_entry':
kernel/auditfilter.c:501: error: expected expression before '{' token
kernel/auditfilter.c: In function 'audit_add_rule':
kernel/auditfilter.c:891: error: expected expression before '{' token
CONFIG_AUDIT_WATCH is not set
^ permalink raw reply
* Re: linux-next: boot failure
From: Sachin Sant @ 2009-07-01 11:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Eric Paris, linux-next, LKML
In-Reply-To: <20090701160014.595e1338.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> next-20090629 was fine. The commits in 0630 and not in 0629 (from the
> fsnotify tree) are:
>
> Audit: clean up the audit_watch split
> audit: convert audit watches to use fsnotify instead of inotify
> audit: redo audit watch locking and refcnt in light of fsnotify
> audit: do not get and put just to free a watch
> fsnotify: duplicate fsnotify_mark_entry data between 2 marks
> fsnotify: allow addition of duplicate fsnotify marks
> audit: reimplement audit_trees using fsnotify rather than inotify
> inotify: deprecate the inotify kernel interface
>
Stephen / Eric,
I too am facing similar issue on both Power and x86.
Culprit seems to be 2nd patch in the above list.
commit e1b79967e2b29839d16c12b534597a15d8630fc4
audit: convert audit watches to use fsnotify instead of inotify
I wasn't able to remove only patch 2 because of dependencies
on other patches. After i reverted patches 2 to 7 in the above
list, i was able to boot the machine. Then i applied patch 2
and the machine failed to boot.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* linux-next: Tree for July 1
From: Stephen Rothwell @ 2009-07-01 8:39 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 7258 bytes --]
Hi all,
Changes since 20090630:
Dropped tree: sfi (build problems)
This tree fails to build for powerpc allyesconfig.
The kvm tree gained a conflict against Linus' tree.
The rr tree lost a conflict and a build failure.
The block tree gained a conflict against Linus' tree.
The percpu tree gained 2 conflicts against Linus' tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES) and i386, sparc and sparc64 defconfig.
These builds also have CONFIG_ENABLE_WARN_DEPRECATED,
CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 132 trees (counting Linus' and 19 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging dwmw2/master
Merging arm/devel
Merging davinci/for-next
Merging pxa/for-next
Merging avr32/avr32-arch
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
CONFLICT (add/add): Merge conflict in arch/mips/cavium-octeon/executive/cvmx-helper-errata.c
CONFLICT (content): Merge conflict in arch/mips/mm/tlbex.c
CONFLICT (content): Merge conflict in arch/mips/sibyte/swarm/setup.c
CONFLICT (content): Merge conflict in drivers/char/hw_random/Kconfig
CONFLICT (content): Merge conflict in drivers/char/hw_random/Makefile
CONFLICT (add/add): Merge conflict in drivers/dma/txx9dmac.c
Merging parisc/master
Merging powerpc/next
Merging 4xx/next
Merging galak/next
Merging s390/features
Merging sh/master
Merging sparc/master
Merging xtensa/master
Merging cifs/master
Merging configfs/linux-next
CONFLICT (content): Merge conflict in fs/configfs/dir.c
Merging ext4/next
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging jfs/next
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging squashfs/master
Merging v9fs/for-next
CONFLICT (content): Merge conflict in net/9p/protocol.c
Merging ubifs/linux-next
Merging xfs/master
Merging reiserfs-bkl/reiserfs/kill-bkl-rc6
CONFLICT (content): Merge conflict in fs/reiserfs/super.c
Merging vfs/for-next
Merging pci/linux-next
CONFLICT (content): Merge conflict in arch/ia64/include/asm/pci.h
CONFLICT (content): Merge conflict in arch/mn10300/include/asm/pci.h
CONFLICT (content): Merge conflict in include/asm-generic/pci.h
$ git reset --hard HEAD^
Merging refs/next/20090629/pci
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging quota/for_next
Merging kbuild/master
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
$ git checkout HEAD drivers/platform/x86/eeepc-laptop.c
[master 7050032] Revert "eeepc-laptop: Register as a pci-hotplug device"
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in fs/eventfd.c
Merging dlm/next
Merging scsi/master
Merging async_tx/next
Merging udf/for_next
Merging net/master
Merging wireless/master
Merging mtd/master
Merging crypto/master
Merging sound/for-next
Merging cpufreq/next
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/powerpc/platforms/powermac/setup.c
Applying: rr/pmac: fix for cpumask accessor changes
Merging mmc/next
Merging input/next
Merging bkl-removal/bkl-removal
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in mm/page-writeback.c
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging voltage/for-next
Merging security-testing/next
Merging lblnet/master
Merging quilt/ttydev
CONFLICT (content): Merge conflict in drivers/char/tty_ldisc.c
Merging agp/agp-next
Merging uwb/for-upstream
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging omap/for-next
Merging quilt/aoe
Merging suspend/linux-next
Merging bluetooth/master
Merging edac-amd/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging hwlat/for-linus
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/include/asm/termios.h
Merging percpu/for-next
CONFLICT (content): Merge conflict in arch/alpha/include/asm/percpu.h
CONFLICT (content): Merge conflict in arch/mn10300/kernel/vmlinux.lds.S
CONFLICT (content): Merge conflict in include/linux/percpu-defs.h
Merging sfi/sfi-test
$ git reset --hard HEAD^
Merging asm-generic/next
Merging quilt/driver-core
Merging quilt/usb
Merging quilt/staging
Merging scsi-post-merge/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the percpu tree with Linus' tree
From: Stephen Rothwell @ 2009-07-01 7:25 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter, Ingo Molnar
Cc: linux-next, linux-kernel, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
include/linux/percpu-defs.h between commit
b01e8dc34379f4ba2f454390e340a025edbaaa7e ("alpha: fix percpu build
breakage") from Linus' tree and commit
7c756e6e19e71f0327760d8955f7077118ebb2b1 ("percpu: implement optional
weak percpu definitions") from the percpu tree.
The latter seems to subsume the former changes, so I just used the percpu
tree version of this file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the percpu tree with Linus' tree
From: Stephen Rothwell @ 2009-07-01 7:19 UTC (permalink / raw)
To: Tejun Heo, Rusty Russell, Christoph Lameter, Ingo Molnar
Cc: linux-next, linux-kernel, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
Hi all,
Today's linux-next merge of the percpu tree got a conflict in
arch/alpha/include/asm/percpu.h between commit
b01e8dc34379f4ba2f454390e340a025edbaaa7e ("alpha: fix percpu build
breakage") from Linus' tree and commit
6088464cf1ae9fb3d2ccc0ec5feb3f5b971098d8 ("alpha: kill unnecessary __used
attribute in PER_CPU_ATTRIBUTES") from the percpu tree.
The latter just removes what the former changed, so I used the percpu
tree version of this file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the kvm tree with Linus' tree
From: Davide Libenzi @ 2009-07-01 7:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Avi Kivity, linux-next, Linux Kernel Mailing List, Andrew Morton,
Gregory Haskins
In-Reply-To: <20090701145711.1c9c8935.sfr@canb.auug.org.au>
On Wed, 1 Jul 2009, Stephen Rothwell wrote:
> Hi Avi,
>
> Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
> between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
> revised interface and cleanups") from Linus' tree and commit
> 28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
> notified about the eventfd file* going away") from the kvm tree.
>
> Overlapping changes. I fixed it up (see below), but don't know if this
> is the correct fix.
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc fs/eventfd.c
> index 31d12de,72f5f8d..0000000
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
> {
> struct eventfd_ctx *ctx = file->private_data;
>
> - wake_up_poll(&ctx->wqh, POLLHUP);
> + /*
> + * No need to hold the lock here, since we are on the file cleanup
> + * path and the ones still attached to the wait queue will be
> + * serialized by wake_up_locked_poll().
> + */
> + wake_up_locked_poll(&ctx->wqh, POLLHUP);
> - kfree(ctx);
> + eventfd_ctx_put(ctx);
> return 0;
> }
That's fine.
There are a couple of extra spaces before the last two -+ in that patch
though ;)
- Davide
^ permalink raw reply
* Re: linux-next: manual merge of the block tree with the tree
From: Jens Axboe @ 2009-07-01 6:59 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Richard Kennedy, Andrew Morton
In-Reply-To: <20090701153715.7e2935a8.sfr@canb.auug.org.au>
On Wed, Jul 01 2009, Stephen Rothwell wrote:
> Hi Jens,
>
> Today's linux-next merge of the block tree got a conflict in
> mm/page-writeback.c between commit
> d7831a0bdf06b9f722b947bb0c205ff7d77cebd8 ("mm: prevent balance_dirty_pages
> () from doing too much work") from Linus' tree and commit
> 83f866f06c6d0266330e1631f4644ba6a63e6925 ("writeback: switch to per-bdi
> threads for flushing data") from the block tree.
>
> Context changes. I fixed it up (see below) but am not sure if this is
> the correct fix.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
>
> diff --cc mm/page-writeback.c
> index 7687879,7b87d10..0000000
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@@ -541,12 -527,9 +527,12 @@@ static void balance_dirty_pages(struct
> * filesystems (i.e. NFS) in which data may have been
> * written to the server's write cache, but has not yet
> * been flushed to permanent storage.
> + * Only move pages to writeback if this bdi is over its
> + * threshold otherwise wait until the disk writes catch
> + * up.
> */
> - if (bdi_nr_reclaimable) {
> + if (bdi_nr_reclaimable > bdi_thresh) {
> - writeback_inodes(&wbc);
> + generic_sync_bdi_inodes(NULL, &wbc);
> pages_written += write_chunk - wbc.nr_to_write;
> get_dirty_limits(&background_thresh, &dirty_thresh,
> &bdi_thresh, bdi);
I'll fix that up, I didn't expect this patch to go in, since there are
still pending issues with it...
--
Jens Axboe
^ permalink raw reply
* linux-next: boot failure
From: Stephen Rothwell @ 2009-07-01 6:00 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-next, LKML
[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]
Hi Eric,
next-20090630 failed to boot (on PowerPC Power5/6 machines):
calling .audit_watch_init+0x0/0x80 @ 1
Unable to handle kernel paging request for data at address 0xffffffffffffffff
Faulting instruction address: 0xc00000000008b440
cpu 0x0: Vector: 300 (Data Access) at [c0000000be683990]
pc: c00000000008b440: .srcu_read_lock+0x20/0x40
lr: c0000000001607cc: .fsnotify_recalc_global_mask+0x2c/0xa0
sp: c0000000be683c10
msr: 8000000000009032
dar: ffffffffffffffff
dsisr: 40010000
current = 0xc0000000be67e000
paca = 0xc00000000093b200
pid = 1, comm = swapper
enter ? for help
[link register ] c0000000001607cc .fsnotify_recalc_global_mask+0x2c/0xa0
[c0000000be683c10] c0000000be683ca0 (unreliable)
[c0000000be683ca0] c000000000160bc0 .fsnotify_obtain_group+0x1e0/0x260
[c0000000be683d60] c0000000007879e4 .audit_watch_init+0x34/0x80
[c0000000be683de0] c00000000000947c .do_one_initcall+0x6c/0x1e0
[c0000000be683ee0] c00000000076fd6c .kernel_init+0x23c/0x2c0
[c0000000be683f90] c00000000002a9bc .kernel_thread+0x54/0x70
next-20090629 was fine. The commits in 0630 and not in 0629 (from the
fsnotify tree) are:
Audit: clean up the audit_watch split
audit: convert audit watches to use fsnotify instead of inotify
audit: redo audit watch locking and refcnt in light of fsnotify
audit: do not get and put just to free a watch
fsnotify: duplicate fsnotify_mark_entry data between 2 marks
fsnotify: allow addition of duplicate fsnotify marks
audit: reimplement audit_trees using fsnotify rather than inotify
inotify: deprecate the inotify kernel interface
If I have time, I may do a bisection.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the block tree with the tree
From: Stephen Rothwell @ 2009-07-01 5:37 UTC (permalink / raw)
To: Jens Axboe; +Cc: linux-next, linux-kernel, Richard Kennedy, Andrew Morton
Hi Jens,
Today's linux-next merge of the block tree got a conflict in
mm/page-writeback.c between commit
d7831a0bdf06b9f722b947bb0c205ff7d77cebd8 ("mm: prevent balance_dirty_pages
() from doing too much work") from Linus' tree and commit
83f866f06c6d0266330e1631f4644ba6a63e6925 ("writeback: switch to per-bdi
threads for flushing data") from the block tree.
Context changes. I fixed it up (see below) but am not sure if this is
the correct fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/page-writeback.c
index 7687879,7b87d10..0000000
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -541,12 -527,9 +527,12 @@@ static void balance_dirty_pages(struct
* filesystems (i.e. NFS) in which data may have been
* written to the server's write cache, but has not yet
* been flushed to permanent storage.
+ * Only move pages to writeback if this bdi is over its
+ * threshold otherwise wait until the disk writes catch
+ * up.
*/
- if (bdi_nr_reclaimable) {
+ if (bdi_nr_reclaimable > bdi_thresh) {
- writeback_inodes(&wbc);
+ generic_sync_bdi_inodes(NULL, &wbc);
pages_written += write_chunk - wbc.nr_to_write;
get_dirty_limits(&background_thresh, &dirty_thresh,
&bdi_thresh, bdi);
^ permalink raw reply
* linux-next: manual merge of the kvm tree with Linus' tree
From: Stephen Rothwell @ 2009-07-01 4:57 UTC (permalink / raw)
To: Avi Kivity
Cc: linux-next, linux-kernel, Davide Libenzi, Andrew Morton,
Gregory Haskins
Hi Avi,
Today's linux-next merge of the kvm tree got a conflict in fs/eventfd.c
between commit 133890103b9de08904f909995973e4b5c08a780e ("eventfd:
revised interface and cleanups") from Linus' tree and commit
28ddf0aebbf546e56efd1951725d5457ce1ebf98 ("eventfd: Allow waiters to be
notified about the eventfd file* going away") from the kvm tree.
Overlapping changes. I fixed it up (see below), but don't know if this
is the correct fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc fs/eventfd.c
index 31d12de,72f5f8d..0000000
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@@ -105,8 -63,13 +105,13 @@@ static int eventfd_release(struct inod
{
struct eventfd_ctx *ctx = file->private_data;
- wake_up_poll(&ctx->wqh, POLLHUP);
+ /*
+ * No need to hold the lock here, since we are on the file cleanup
+ * path and the ones still attached to the wait queue will be
+ * serialized by wake_up_locked_poll().
+ */
+ wake_up_locked_poll(&ctx->wqh, POLLHUP);
- kfree(ctx);
+ eventfd_ctx_put(ctx);
return 0;
}
^ permalink raw reply
* Re: linux-next: pci tree build failure
From: Jesse Barnes @ 2009-06-30 20:31 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20090630022453.GE24061@linux.intel.com>
On Mon, 29 Jun 2009 19:24:53 -0700
Matthew Wilcox <willy@linux.intel.com> wrote:
> On Mon, Jun 29, 2009 at 07:13:24PM -0700, Jesse Barnes wrote:
> > On Tue, 30 Jun 2009 12:07:27 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi Jesse,
> > >
> > > Today's linux-next build (x86_64 allmodconfig) failed like this:
> > >
> > > ERROR: "pci_claim_resource" [drivers/pcmcia/yenta_socket.ko]
> > > undefined!
> > >
> > > Caused by commit 6bb04b65dbff5a5bb01617351dbb0af577084752
> > > ("yenta: Use pci_claim_resource"). yenta can be built as a
> > > module, but pci_claim_resource is not exported ...
> > >
> > > I have used the pci tree from next-20090629 for today.
> >
> > Damn, thought I built that. linux-next earns its keep yet again.
>
> Sorry about that. I thought I'd checked that. Must have been
> confused with another function. There do seem to be legitimate
> *drivers* that could use it (i2o for one), so I propose making it a
> full-bodied 'EXPORT_SYMBOL' and not bother with the _GPL tag.
> Thoughts?
Fine by me; that matches most of the PCI core (though the slots bits
are _GPL).
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Eric Paris @ 2009-06-30 19:17 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Alexander Beregalov, linux-next
In-Reply-To: <4A4A6248.90706@oracle.com>
On Tue, 2009-06-30 at 12:06 -0700, Randy Dunlap wrote:
> Eric Paris wrote:
> > On Tue, 2009-06-30 at 16:27 +0400, Alexander Beregalov wrote:
> >> Hi
> >>
> >> kernel/audit_watch.c: In function 'audit_get_parent':
> >> kernel/audit_watch.c:85: error: implicit declaration of function
> >> 'fsnotify_get_mark'
> >
> > Should be fixed for you by:
> >
> > http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=aae48cb2b8719e8a374faea141373b7ce0b89bc6
> > http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=de85e5bc3690c3063aea790279e898adb5bac0ba
> >
> >> $ egrep "NOTIFY|AUDIT" .config
> >> CONFIG_AUDIT_ARCH=y
> >> CONFIG_AUDIT=y
> >> # CONFIG_AUDITSYSCALL is not set
> >> # CONFIG_FSNOTIFY is not set
> >> CONFIG_INOTIFY=y
> >
> > Unrelated note, CONFIG_INOTIFY in linux-next is completely and totally
> > useless.....
>
> Please explain.
> Looks like it still controls building fs/notify/inotify/inotify.o,
> based on fs/notify/inotify/Makefile.
Which in turn is used by nothing. Although it is EXPORT_SYMBOL_GPL, so
you could have some out of tree module that uses it, but I haven't found
one....
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Randy Dunlap @ 2009-06-30 19:06 UTC (permalink / raw)
To: Eric Paris; +Cc: Alexander Beregalov, linux-next
In-Reply-To: <1246384996.22562.19.camel@dhcp235-23.rdu.redhat.com>
Eric Paris wrote:
> On Tue, 2009-06-30 at 16:27 +0400, Alexander Beregalov wrote:
>> Hi
>>
>> kernel/audit_watch.c: In function 'audit_get_parent':
>> kernel/audit_watch.c:85: error: implicit declaration of function
>> 'fsnotify_get_mark'
>
> Should be fixed for you by:
>
> http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=aae48cb2b8719e8a374faea141373b7ce0b89bc6
> http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=de85e5bc3690c3063aea790279e898adb5bac0ba
>
>> $ egrep "NOTIFY|AUDIT" .config
>> CONFIG_AUDIT_ARCH=y
>> CONFIG_AUDIT=y
>> # CONFIG_AUDITSYSCALL is not set
>> # CONFIG_FSNOTIFY is not set
>> CONFIG_INOTIFY=y
>
> Unrelated note, CONFIG_INOTIFY in linux-next is completely and totally
> useless.....
Please explain.
Looks like it still controls building fs/notify/inotify/inotify.o,
based on fs/notify/inotify/Makefile.
--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Alexander Beregalov @ 2009-06-30 19:06 UTC (permalink / raw)
To: Eric Paris; +Cc: linux-next
In-Reply-To: <1246384996.22562.19.camel@dhcp235-23.rdu.redhat.com>
2009/6/30 Eric Paris <eparis@redhat.com>:
> On Tue, 2009-06-30 at 16:27 +0400, Alexander Beregalov wrote:
>> Hi
>>
>> kernel/audit_watch.c: In function 'audit_get_parent':
>> kernel/audit_watch.c:85: error: implicit declaration of function
>> 'fsnotify_get_mark'
>
> Should be fixed for you by:
>
> http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=aae48cb2b8719e8a374faea141373b7ce0b89bc6
> http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=de85e5bc3690c3063aea790279e898adb5bac0ba
>
>> $ egrep "NOTIFY|AUDIT" .config
>> CONFIG_AUDIT_ARCH=y
>> CONFIG_AUDIT=y
>> # CONFIG_AUDITSYSCALL is not set
>> # CONFIG_FSNOTIFY is not set
>> CONFIG_INOTIFY=y
>
> Unrelated note, CONFIG_INOTIFY in linux-next is completely and totally
> useless.....
Thanks Eric.
This config is not for a real kernel.
I just test randconfig build from time to time.
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Eric Paris @ 2009-06-30 18:03 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next
In-Reply-To: <a4423d670906300527w42557b9kf5a20e5b527fc1eb@mail.gmail.com>
On Tue, 2009-06-30 at 16:27 +0400, Alexander Beregalov wrote:
> Hi
>
> kernel/audit_watch.c: In function 'audit_get_parent':
> kernel/audit_watch.c:85: error: implicit declaration of function
> 'fsnotify_get_mark'
Should be fixed for you by:
http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=aae48cb2b8719e8a374faea141373b7ce0b89bc6
http://git.infradead.org/users/eparis/notify.git?a=commitdiff;h=de85e5bc3690c3063aea790279e898adb5bac0ba
> $ egrep "NOTIFY|AUDIT" .config
> CONFIG_AUDIT_ARCH=y
> CONFIG_AUDIT=y
> # CONFIG_AUDITSYSCALL is not set
> # CONFIG_FSNOTIFY is not set
> CONFIG_INOTIFY=y
Unrelated note, CONFIG_INOTIFY in linux-next is completely and totally
useless.....
-Eric
^ permalink raw reply
* Re: linux-next: manual merge of the pci tree with Linus' tree
From: Jesse Barnes @ 2009-06-30 16:00 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Stephen Rothwell, linux-next, linux-kernel, Alex Chiang
In-Reply-To: <20090630021612.GD24061@linux.intel.com>
On Mon, 29 Jun 2009 19:16:13 -0700
Matthew Wilcox <willy@linux.intel.com> wrote:
> On Mon, Jun 29, 2009 at 07:01:35PM -0700, Jesse Barnes wrote:
> > On Tue, 30 Jun 2009 11:56:38 +1000
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi Jesse,
> > >
> > > Today's linux-next merge of the pci tree got conflicts in
> > > arch/ia64/include/asm/pci.h, arch/mn10300/include/asm/pci.h and
> > > include/asm-generic/pci.h between commit
> > > a6c140969b4685f9b9f6773c0760f55ca66d1825 ("Delete
> > > pcibios_select_root") from Linus' tree and commit
> > > a53cd7419b22c14b5a1e6859a940fb6bfa77963f ("PCI: remove
> > > pcibios_scan_all_fns()") from the pci tree.
> > >
> > > Just context changes (adjacent removals). I fixed it up (see
> > > below) and can carry the fix for a while.
> >
> > Ah ok, thanks. That'll get fixed up after I send the current
> > for-linus bits over and refresh my PCI tree.
>
> I think you need to pull from Linus' tree before you send the bits
> over -- that's a conflict between Linus' tree and your tree, and you
> don't want to annoy Linus by making him merge them ;-)
Ah but I don't want to annoy Linus by merging either. In fact, he's
stated explicitly several times that I should *not* pull his tree into
mine, either by rebasing or merging; his position is that pulling an
old tree from me should be fine, since no one else should have commits
in the PCI area, or if they do they'll be trivial and he'll fix them
up.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: next-20090630: audit/fsnotify build failure
From: Eric Paris @ 2009-06-30 12:31 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linux-next
In-Reply-To: <a4423d670906300527w42557b9kf5a20e5b527fc1eb@mail.gmail.com>
On Tue, 2009-06-30 at 16:27 +0400, Alexander Beregalov wrote:
> Hi
>
> kernel/audit_watch.c: In function 'audit_get_parent':
> kernel/audit_watch.c:85: error: implicit declaration of function
> 'fsnotify_get_mark'
> kernel/audit_watch.c: In function 'audit_put_parent':
> kernel/audit_watch.c:91: error: implicit declaration of function
> 'fsnotify_put_mark'
> kernel/audit_watch.c: In function 'audit_find_parent':
> kernel/audit_watch.c:104: error: implicit declaration of function
> 'fsnotify_find_mark_entry'
> kernel/audit_watch.c:104: warning: assignment makes pointer from
> integer without a cast
> kernel/audit_watch.c: In function 'audit_init_parent':
> kernel/audit_watch.c:161: error: implicit declaration of function
> 'fsnotify_init_mark'
> kernel/audit_watch.c:163: error: implicit declaration of function
> 'fsnotify_add_mark'
> kernel/audit_watch.c: In function 'audit_remove_parent_watches':
> kernel/audit_watch.c:354: error: implicit declaration of function
> 'fsnotify_destroy_mark_by_entry'
> kernel/audit_watch.c: In function 'audit_watch_should_send_event':
> kernel/audit_watch.c:513: warning: assignment makes pointer from
> integer without a cast
> kernel/audit_watch.c: In function 'audit_watch_init':
> kernel/audit_watch.c:578: error: implicit declaration of function
> 'fsnotify_obtain_group'
> kernel/audit_watch.c:579: warning: assignment makes pointer from
> integer without a cast
audit now depends on FSNOTIFY. Will fix for tomorrow. (and I'll try to
break audit_watches out to their own config option so you don't have to
have notification.
Sorry for the breakage.
-Eric
^ permalink raw reply
* next-20090630: audit/fsnotify build failure
From: Alexander Beregalov @ 2009-06-30 12:27 UTC (permalink / raw)
To: linux-next, Eric Paris
Hi
kernel/audit_watch.c: In function 'audit_get_parent':
kernel/audit_watch.c:85: error: implicit declaration of function
'fsnotify_get_mark'
kernel/audit_watch.c: In function 'audit_put_parent':
kernel/audit_watch.c:91: error: implicit declaration of function
'fsnotify_put_mark'
kernel/audit_watch.c: In function 'audit_find_parent':
kernel/audit_watch.c:104: error: implicit declaration of function
'fsnotify_find_mark_entry'
kernel/audit_watch.c:104: warning: assignment makes pointer from
integer without a cast
kernel/audit_watch.c: In function 'audit_init_parent':
kernel/audit_watch.c:161: error: implicit declaration of function
'fsnotify_init_mark'
kernel/audit_watch.c:163: error: implicit declaration of function
'fsnotify_add_mark'
kernel/audit_watch.c: In function 'audit_remove_parent_watches':
kernel/audit_watch.c:354: error: implicit declaration of function
'fsnotify_destroy_mark_by_entry'
kernel/audit_watch.c: In function 'audit_watch_should_send_event':
kernel/audit_watch.c:513: warning: assignment makes pointer from
integer without a cast
kernel/audit_watch.c: In function 'audit_watch_init':
kernel/audit_watch.c:578: error: implicit declaration of function
'fsnotify_obtain_group'
kernel/audit_watch.c:579: warning: assignment makes pointer from
integer without a cast
$ egrep "NOTIFY|AUDIT" .config
CONFIG_AUDIT_ARCH=y
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_FSNOTIFY is not set
CONFIG_INOTIFY=y
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Pekka Enberg @ 2009-06-30 10:57 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Sachin Sant, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630102958.GF1114@wotan.suse.de>
On Tue, 2009-06-30 at 12:29 +0200, Nick Piggin wrote:
> On Tue, Jun 30, 2009 at 12:09:29PM +0200, Heiko Carstens wrote:
> > On Tue, Jun 30, 2009 at 11:06:31AM +0200, Nick Piggin wrote:
> > > On Mon, Jun 29, 2009 at 04:12:34PM +0200, Heiko Carstens wrote:
> > > > slqb returns ZERO_SIZE_PTR instead of NULL for large size requests it cannot
> > > > handle.
> > > > The patch below would fix it. But I think its too ugly. So I leave it up to
> > > > Nick to come up with a real and nice patch ;)
> > >
> > > Could you try this patch and see if it helps? (it fixes a number
> > > of simple corner cases here, *blush*)
> >
> > Yes, it does work now. Thanks!
>
> Thanks. Pekka, can you please merge this with
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
Done. Thanks everyone!
^ permalink raw reply
* Re: Next June 29: Boot failure with SLQB on s390
From: Sachin Sant @ 2009-06-30 10:56 UTC (permalink / raw)
To: Nick Piggin
Cc: Heiko Carstens, Pekka Enberg, Stephen Rothwell, linux-next,
linux-s390
In-Reply-To: <20090630083410.GA1114@wotan.suse.de>
Nick Piggin wrote:
> If you are not seeing any extra messages from the patch, then it
> could be that you are seeing ZERO_SIZE_PTR or similar errors as
> well. I will ask if you can try the patch I sent in the other
> thread.
Still facing same problem after applying the patch you mentioned.
Probably the s390 issue is different that the Power6 issue.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox