* [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-23 14:42 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Jiri Slaby, Alan Cox, linux-kernel
New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
--- a/drivers/tty/pty.c 2011-05-19 08:06:34.000000000 +0400
+++ b/drivers/tty/pty.c 2011-10-23 18:01:20.000000000 +0400
@@ -36,13 +36,15 @@
static struct tty_driver *ptm_driver;
static struct tty_driver *pts_driver;
#endif
+static int pty_count;
static void pty_close(struct tty_struct *tty, struct file *filp)
{
BUG_ON(!tty);
- if (tty->driver->subtype == PTY_TYPE_MASTER)
+ if (tty->driver->subtype == PTY_TYPE_MASTER) {
WARN_ON(tty->count > 1);
- else {
+ pty_count--;
+ } else {
if (tty->count > 2)
return;
}
@@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
int pty_limit = NR_UNIX98_PTY_DEFAULT;
static int pty_limit_min;
static int pty_limit_max = NR_UNIX98_PTY_MAX;
-static int pty_count;
static struct cdev ptmx_cdev;
@@ -599,15 +600,9 @@ free_mem_out:
return -ENOMEM;
}
-static void pty_unix98_remove(struct tty_driver *driver, struct
tty_struct *tty)
-{
- pty_count--;
-}
-
static const struct tty_operations ptm_unix98_ops = {
.lookup = ptm_unix98_lookup,
.install = pty_unix98_install,
- .remove = pty_unix98_remove,
.open = pty_open,
.close = pty_close,
.write = pty_write,
@@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
static const struct tty_operations pty_unix98_ops = {
.lookup = pts_unix98_lookup,
.install = pty_unix98_install,
- .remove = pty_unix98_remove,
.open = pty_open,
.close = pty_close,
.write = pty_write,
^ permalink raw reply
* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: Julian Anastasov @ 2011-10-23 14:52 UTC (permalink / raw)
To: Yan, Zheng
Cc: netdev@vger.kernel.org, davem@davemloft.net,
eric.dumazet@gmail.com, Kim Phillips
In-Reply-To: <4EA3C91C.3090801@intel.com>
Hello,
On Sun, 23 Oct 2011, Yan, Zheng wrote:
> There is bug in commit 5e2b61f(ipv4: Remove flowi from struct rtable).
> It makes xfrm4_fill_dst() modify wrong data structure.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> ---
> net/ipv4/xfrm4_policy.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
> index fc5368a..a0b4c5d 100644
> --- a/net/ipv4/xfrm4_policy.c
> +++ b/net/ipv4/xfrm4_policy.c
> @@ -79,13 +79,13 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
> struct rtable *rt = (struct rtable *)xdst->route;
> const struct flowi4 *fl4 = &fl->u.ip4;
>
> - rt->rt_key_dst = fl4->daddr;
> - rt->rt_key_src = fl4->saddr;
> - rt->rt_key_tos = fl4->flowi4_tos;
> - rt->rt_route_iif = fl4->flowi4_iif;
> - rt->rt_iif = fl4->flowi4_iif;
> - rt->rt_oif = fl4->flowi4_oif;
> - rt->rt_mark = fl4->flowi4_mark;
> + xdst->u.rt.rt_key_dst = fl4->daddr;
> + xdst->u.rt.rt_key_src = fl4->saddr;
> + xdst->u.rt.rt_key_tos = fl4->flowi4_tos;
> + xdst->u.rt.rt_route_iif = fl4->flowi4_iif;
May be I'm missing something but I don't see where
flowi4_iif is set for the forwarding case. __xfrm_route_forward
calls xfrm_decode_session which does not appear to set
flowi4_iif. When providing fl4 for output routes flowi4_iif
is always set to 0, so it represents rt_route_iif. But
then there are 2 variants for __ip_route_output_key:
- ip_route_output_slow sets flowi4_iif to loopback and
flowi4_oif to outdev during lookup but never restores them
to original values. It is assumed that caller uses outdev
from dst, not from flowi4_oif.
- for cached route we do not update flowi4_iif and flowi4_oif
in __ip_route_output_key, so the resulting fl4 can not be
used for these values. I assume, the current rules are that
only fl4.saddr and daddr are updated while flowi4_iif and
flowi4_oif are not. It looks wrong flowi code to rely on them.
Currently, we have 3 values for devices:
rt_iif: indev for input routes, resulting outdev for output routes
which plays the role as indev for loopback traffic.
rt_oif: original outdev key, 0 for input routes, can be 0 for
output routes if socket is not bound to oif
rt_route_iif: indev for input routes, 0 for output routes
With above rules for flowi4_iif and flowi4_oif
it is impossible to select value for rt_iif from fl4.
I don't know the xfrm code well, may be after the
mentioned change we damaged rt_oif and rt_route_iif values
for cached dst which can lead to using slow path all the time.
Even if rt_intern_hash() avoids caching similar dsts multiple
times, if cached entry is damaged we will add more and
more new entries after every damage.
> + xdst->u.rt.rt_iif = fl4->flowi4_iif;
> + xdst->u.rt.rt_oif = fl4->flowi4_oif;
> + xdst->u.rt.rt_mark = fl4->flowi4_mark;
>
> xdst->u.dst.dev = dev;
> dev_hold(dev);
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [U-Boot] debugX macro
From: Marek Vasut @ 2011-10-23 14:46 UTC (permalink / raw)
To: u-boot
Hi,
I've been doing the debug() cleanup and found the debugX() macro is used only in
very few patches. Maybe punting it altogether won't hurt.
The following do use it:
./board/spc1920/hpi.c
./drivers/mtd/nand/s3c2410_nand.c
Opinions?
Thanks, Cheers!
^ permalink raw reply
* Re: bitbake eating more than 6GB ram while parsing recipes
From: Khem Raj @ 2011-10-23 14:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <20111023075715.GD3497@jama.jama.net>
On Sun, Oct 23, 2011 at 12:57 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> Hi,
>
> I know this was reported a while ago and I had this issue for few days
> with 4 GB RAM on my workstation it was hard to do anything when bitbake
> was parsing and today I've "resolved" it by removing cache.
yes I have exact same problem. As you add more machines to same tmpdir
build. It keeps becoming s bigger pig. And so far I have been removing
cache dir too since s parse from scratch is way faster in this case.
I think we have to profile bitbake and find the memory wastage even after
parse right now it keeps like 600M through out the build process which
could be reduced too.
>
> first I've tried to remove
> #PARALLEL_MAKE="-j3"
> #BB_NUMBER_THREADS = "2"
> from my local.conf and it didn't help I still had 6 bitbake processes
> 4 eating ~ 1GB ad 2 with ~ 512MB. So I've removed tmp/cache except
> bb_persist_data.sqlite3:
>
> OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/*
> 35M tmp/cache/bb_codeparser.dat
> 0 tmp/cache/bb_codeparser.dat.lock.13293
> 0 tmp/cache/bb_codeparser.dat.lock.13294
> 0 tmp/cache/bb_codeparser.dat.lock.13295
> 0 tmp/cache/bb_codeparser.dat.lock.15708
> 0 tmp/cache/bb_codeparser.dat.lock.16878
> 0 tmp/cache/bb_codeparser.dat.lock.16879
> 0 tmp/cache/bb_codeparser.dat.lock.16880
> 0 tmp/cache/bb_codeparser.dat.lock.25605
> 68K tmp/cache/bb_persist_data.sqlite3
> 87M tmp/cache/default-eglibc
> OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/bb_codeparser.dat*
>
> OE om-gta02@shr ~/shr-core $ du -hs tmp/cache/default-eglibc/*
> 13M tmp/cache/default-eglibc/nokia900
> 13M tmp/cache/default-eglibc/om-gta02
> 13M tmp/cache/default-eglibc/palmpre
> 13M tmp/cache/default-eglibc/qemuarm
> 13M tmp/cache/default-eglibc/qemux86
> 13M tmp/cache/default-eglibc/qemux86-64
> 13M tmp/cache/default-eglibc/spitz
> OE om-gta02@shr ~/shr-core $ rm -rf tmp/cache/default-eglibc/
>
> and now it's sane again and memory used is < 2GB.
>
> Regards,
> --
> Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
^ permalink raw reply
* [PATCH] init:enable usermodehelper as soon as we have a root filesystem
From: wangyanqing @ 2011-10-23 14:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
before we have a root filesystem , it is useless to enable usermodehelper,
and it may cause bug if we enable usermodehelper too early.This patch
enable usermodehelper as soon as we have a root filesystem.
---
init/do_mounts.c | 3 +++
init/initramfs.c | 2 ++
init/main.c | 1 -
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index c0851a8..9575bdd 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -490,4 +490,7 @@ out:
devtmpfs_mount("dev");
sys_mount(".", "/", NULL, MS_MOVE, NULL);
sys_chroot((const char __user __force *)".");
+#ifndef CONFIG_BLK_DEV_INITRD
+ usermodehelper_enable();
+#endif
}
diff --git a/init/initramfs.c b/init/initramfs.c
index 2531811..881fc4b 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -581,6 +581,7 @@ static int __init populate_rootfs(void)
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
if (!err) {
+ usermodehelper_enable();
free_initrd();
return 0;
} else {
@@ -603,6 +604,7 @@ static int __init populate_rootfs(void)
initrd_end - initrd_start);
if (err)
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", err);
+ usermodehelper_enable();
free_initrd();
#endif
}
diff --git a/init/main.c b/init/main.c
index 03b408d..2e232cb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -730,7 +730,6 @@ static void __init do_basic_setup(void)
driver_init();
init_irq_proc();
do_ctors();
- usermodehelper_enable();
do_initcalls();
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 01/16] pmac_zilog: fix unexpected irq
From: Finn Thain @ 2011-10-23 14:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <20111023141108.856998818@telegraphics.com.au>
On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be masked. This can be a problem when pmac_zilog starts up.
For example, the serial debugging code in arch/m68k/kernel/head.S may be used beforehand. It disables the SCC interrupts at the chip but doesn't ack them. Then when a pmac_zilog port is opened and SCC chip interrupts become enabled, the machine locks up with "unexpected interrupt" because request_irq() hasn't happened yet.
Fix this by setting the SCC master interrupt enable bit only after the handler is installed. This is achieved by extracting that operation out of __pmz_startup() and placing it into a seperate routine.
A similar problem arises when the irq is freed. Fix this by resetting the chip first (on m68k mac).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
This patch has been tested on a variety of m68k Macs but no PowerMacs.
Index: linux-m68k/drivers/tty/serial/pmac_zilog.c
===================================================================
--- linux-m68k.orig/drivers/tty/serial/pmac_zilog.c 2011-10-22 23:02:22.000000000 +1100
+++ linux-m68k/drivers/tty/serial/pmac_zilog.c 2011-10-22 23:02:38.000000000 +1100
@@ -910,8 +910,8 @@ static int __pmz_startup(struct uart_pma
/* Clear handshaking, enable BREAK interrupts */
uap->curregs[R15] = BRKIE;
- /* Master interrupt enable */
- uap->curregs[R9] |= NV | MIE;
+ /* No vector */
+ uap->curregs[R9] |= NV;
pmz_load_zsregs(uap, uap->curregs);
@@ -925,6 +925,17 @@ static int __pmz_startup(struct uart_pma
return pwr_delay;
}
+static void pmz_master_int_control(struct uart_pmac_port *uap, int enable)
+{
+ if (enable) {
+ uap->curregs[R9] |= MIE; /* Master interrupt enable */
+ write_zsreg(uap, R9, uap->curregs[R9]);
+ } else {
+ uap->curregs[R9] &= ~MIE;
+ write_zsreg(uap, 9, FHWRES);
+ }
+}
+
static void pmz_irda_reset(struct uart_pmac_port *uap)
{
uap->curregs[R5] |= DTR;
@@ -976,6 +987,19 @@ static int pmz_startup(struct uart_port
return -ENXIO;
}
+ /*
+ * Most 68k Mac models cannot mask the SCC IRQ so they must enable
+ * interrupts after the handler is installed and not before.
+ */
+#ifndef CONFIG_MAC
+ if (!ZS_IS_CONS(uap))
+#endif
+ {
+ spin_lock_irqsave(&port->lock, flags);
+ pmz_master_int_control(uap, 1);
+ spin_unlock_irqrestore(&port->lock, flags);
+ }
+
mutex_unlock(&pmz_irq_mutex);
/* Right now, we deal with delay by blocking here, I'll be
@@ -1015,6 +1039,11 @@ static void pmz_shutdown(struct uart_por
mutex_lock(&pmz_irq_mutex);
+#ifdef CONFIG_MAC
+ if (!ZS_IS_OPEN(uap->mate))
+ pmz_master_int_control(uap, 0);
+#endif
+
/* Release interrupt handler */
free_irq(uap->port.irq, uap);
@@ -1734,6 +1763,7 @@ static int pmz_resume(struct macio_dev *
goto bail;
}
pwr_delay = __pmz_startup(uap);
+ pmz_master_int_control(uap, 1);
/* Take care of config that may have changed while asleep */
__pmz_set_termios(&uap->port, &uap->termios_cache, NULL);
@@ -2178,6 +2208,9 @@ static int __init pmz_console_setup(stru
* Enable the hardware
*/
pwr_delay = __pmz_startup(uap);
+#ifndef CONFIG_MAC
+ pmz_master_int_control(uap, 1);
+#endif
if (pwr_delay)
mdelay(pwr_delay);
^ permalink raw reply
* Re: [PATCH 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB
From: Tabi Timur-B04825 @ 2011-10-23 14:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1319318452-27036-3-git-send-email-galak@kernel.crashing.org>
On Sat, Oct 22, 2011 at 4:20 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> * Move SoC specific details like irq mapping to SoC dtsi
> * Update interrupt property to cover both error interrupt and PCIe
> =A0runtime interrupts
Are we going to be doing this for all our device trees? If so, then I
think we need to document what properties the board dts should be
defining when it includes a node from a dtsi. Something like this:
dtsi:
pcie@0 {
/* dts should define 'reg' and 'ranges' */
reg =3D <0 0 0 0 0>;
#interrupt-cells =3D <1>;
I suppose it's obvious that 'reg' and 'ranges' should be defined, so
this isn't the best example. But we should document if any other
properties should be defined.
For example, the SSI nodes contain a bunch of SOC- and board-specific
properties.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: Register cache different from the real register values
From: Mark Brown @ 2011-10-23 14:37 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: alsa-devel
In-Reply-To: <CALq1K=Lg=JGzGeuK04hVsC9iME=Q8Exv0N5nfcKWuYWFN4as5g@mail.gmail.com>
On Sun, Oct 23, 2011 at 04:14:07PM +0200, Leon Romanovsky wrote:
> On Sun, Oct 23, 2011 at 15:51, Mark Brown
> > Post your code for review and we
> > might be able to spot something.
> Our code is located at
> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c
Please post for upstream, it's much easier to review and ideally we
could even get the driver merged.
> > At a guess you're doing cache_only and
> > something's going wrong there
> I also tried to add codec->cache_sync = 1 to the _probe function, but
> without luck.
> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c#line998
You should only set cache_sync if you dirty the cache and then you need
to call cache_sync() at some point to actually sync the cache.
> > the register defaults are wrong or the
> Our style is a little different, because it is a port from the
> android, we will be change it later, before merging into the mainline
> to be more convenient.
> http://gitorious.org/~marvin24/ac100/marvin24s-kernel/blobs/chromeos-ac100-2.6.38/sound/soc/codecs/alc5632.c#line1023
Android is using the same kernel - there's no differences introduced by
Android here. If you're seeing differences they're driver quality
issues (probably caused by not being mainline).
Looking briefly at the code that android_init() function is just broken
and should be removed, any missing control should be implemented in the
driver. The fill_cache() function looks suspect also - in general all
the code peering directly into the register cache data structure smells
bad. You should have register defaults hard coded into the driver which
reflect the chip defaults so when we reset we know that's where the chip
is at.
Another thing to check is that the registers in the chip aren't
volatile, if the chip can change register values underneath the driver
then obviously things might get confused. Multiple copies of the same
control are a common culprit.
^ permalink raw reply
* Re: [patch net-next V2] net: introduce ethernet teaming device
From: Eric Dumazet @ 2011-10-23 14:37 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, bhutchings, shemminger, fubar, andy, tgraf,
ebiederm, mirqus, kaber, greearb, jesse, fbl, benjamin.poirier,
jzupka
In-Reply-To: <20111023125101.GA20078@minipsycho.orion>
Le dimanche 23 octobre 2011 à 14:51 +0200, Jiri Pirko a écrit :
> Yes. And team->mode_ops.receive can change only after synchronize_rcu is
> done. It's not possible it changes within the window you are talking about.
If it was true, you would not need the synchronize_rcu() call you added
in __team_change_mode() :
----------------------------------------------------------------------
static int __team_change_mode(struct team *team,
const struct team_mode *new_mode)
{
/* Check if mode was previously set and do cleanup if so */
if (team->mode_kind) {
void (*exit_op)(struct team *team) = team->mode_ops.exit;
/* Clear ops area so no callback is called any longer */
team_mode_ops_clear(&team->mode_ops);
synchronize_rcu();
if (exit_op)
exit_op(team);
-----------------------------------------------------------------------
So the question is : Why do you have this synchronize_rcu() call here ?
^ permalink raw reply
* [PATCH 2/2] pulseaudio: inherit perlnative
From: Khem Raj @ 2011-10-23 14:31 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1319380267-29794-1-git-send-email-raj.khem@gmail.com>
manpage generatition uses xmltoman utility
which inturn uses xml-parser. So we add
libxml-parser-perl-native to DEPENDS and also
inherit perlnative so it does not use the one
from build host
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../pulseaudio/pulseaudio_0.9.23.bb | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
index 33f5e15..9521ab0 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio_0.9.23.bb
@@ -1,10 +1,10 @@
require pulseaudio.inc
-PR = "r5"
+PR = "r6"
-DEPENDS += "gdbm speex"
+DEPENDS += "gdbm speex libxml-parser-perl-native"
-inherit gettext
+inherit gettext perlnative
SRC_URI = "http://freedesktop.org/software/pulseaudio/releases/pulseaudio-${PV}.tar.gz \
file://buildfix.patch \
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] matchbox-stroke: Fix linking error with gold
From: Khem Raj @ 2011-10-23 14:31 UTC (permalink / raw)
To: openembedded-core
Gold defaults to no-add-needed thetefore
it does not link with librtaries that are not on cmdline
it needs libXrender but is not on the linker cmdline
so add it.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
.../matchbox-stroke/files/ldadd_libXrender.patch | 25 ++++++++++++++++++++
.../matchbox-stroke/matchbox-stroke_git.bb | 6 +++-
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
diff --git a/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch b/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
new file mode 100644
index 0000000..90d2057
--- /dev/null
+++ b/meta/recipes-sato/matchbox-stroke/files/ldadd_libXrender.patch
@@ -0,0 +1,25 @@
+with GNU binutils-gold the
+important difference is that --no-add-needed is the default behavior of GNU
+binutils-gold. Please provide all needed libraries to the linker when building
+your executables.
+
+Otherwise we get link errors like
+
+/home/kraj/work/angstrom/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/4.6.2/ld: matchbox-stroke-ui.o: in function mb_stroke_ui_resources_create:matchbox-stroke-ui.c:223: error: undefined reference to 'XRenderCreatePicture'collect2: ld returned 1 exit statusmake[2]: *** [matchbox-stroke] Error 1
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+Upstream-Status: Pending
+Index: git/src/Makefile.am
+===================================================================
+--- git.orig/src/Makefile.am 2011-10-22 19:25:52.000000000 -0700
++++ git/src/Makefile.am 2011-10-22 19:27:07.746428946 -0700
+@@ -6,7 +6,7 @@
+
+ bin_PROGRAMS = matchbox-stroke
+
+-matchbox_stroke_LDADD = $(MBSTROKE_LIBS) $(EXPAT_LIBS) -lm
++matchbox_stroke_LDADD = $(MBSTROKE_LIBS) $(EXPAT_LIBS) -lm -lXrender
+
+ matchbox_stroke_SOURCES = \
+ matchbox-stroke.h \
diff --git a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
index 44b316d..2c2e940 100644
--- a/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
+++ b/meta/recipes-sato/matchbox-stroke/matchbox-stroke_git.bb
@@ -9,11 +9,13 @@ DEPENDS = "libfakekey expat libxft"
SECTION = "x11/wm"
SRCREV = "8edfd9a2bf1f0d6b28d4afee4bda9d3635f26a0b"
PV = "0.0+git${SRCPV}"
-PR = "r0"
+PR = "r1"
SRC_URI = "git://git.yoctoproject.org/${BPN};protocol=git \
file://single-instance.patch \
- file://configure_fix.patch;maxrev=1819"
+ file://configure_fix.patch;maxrev=1819 \
+ file://ldadd_libXrender.patch \
+ "
S = "${WORKDIR}/git"
--
1.7.5.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-23 14:33 UTC (permalink / raw)
To: Alexander Graf; +Cc: Kevin Wolf, qemu-devel, avi
In-Reply-To: <CDC49CE5-315D-4484-BB1F-842FF9EA7D42@csgraf.de>
On 10/22/2011 05:07 PM, Alexander Graf wrote:
>
> On 21.10.2011, at 11:44, Paolo Bonzini wrote:
>
>> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>>> Avi complained that not even writing out qcow2's cache on
>>> bdrv_flush() made cache=unsafe too unsafe to be useful. He's got
>>> a point.
>>
>> Why? cache=unsafe is explicitly allowing to s/data/manure/ on
>> crash.
>
> Exactly, but not on kill. By not flushing internal caches you're
> almost guaranteed to get an inconsistent qcow2 image.
This should be covered already by termsig_handler. bdrv_close_all
closes all block devices, and qcow2_close does flush the caches.
SIGKILL doesn't give any guarantee of course but it does not in general,
even without cache=unsafe; you might get a SIGKILL "a moment before" a
bdrv_flush even without cache=unsafe, and get unclean qcow2 metadata.
> By not flushing internal caches you're almost guaranteed to get an
> inconsistent qcow2 image.
Of course the inconsistencies with cache=unsafe will be massive if you
don't have a clean exit, but that's expected. If in some cases you want
a clean exit, but right now you don't, the place to fix those cases
doesn't seem to be the block layer, but the main loop.
Also,
1) why should cache=unsafe differentiate an OS that sends a flush from
one that doesn't (e.g. MS-DOS), from the point of view of image metadata?
2) why should the guest actually send a flush if cache=unsafe? Currently
if (flags & BDRV_O_CACHE_WB)
bs->enable_write_cache = 1;
covers cache=unsafe. However, in the end write cache enable means "do I
need to flush data", and the answer is "no" when cache=unsafe, because
the flushes are useless and guests are free to reorder requests.
<shot-in-the-dark>Perhaps what you want is to make qcow2 caches
writethrough in cache=unsafe mode, so that at least a try is made to
write the metadata</shot-in-the-dark> (even though the underlying raw
protocol won't flush it)? I'm not sure that is particularly useful, but
maybe it can help me understanding the benefit of this change.
Paolo
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of staging
From: KY Srinivasan @ 2011-10-23 14:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, virtualization@lists.osdl.org,
linux-input@vger.kernel.org, Haiyang Zhang, Jiri Kosina
In-Reply-To: <20111023072427.GA13268@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Sunday, October 23, 2011 3:24 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; linux-
> input@vger.kernel.org; Haiyang Zhang; Jiri Kosina
> Subject: Re: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of
> staging
>
> Hi K. Y.,
>
> On Fri, Oct 14, 2011 at 11:08:27PM -0700, K. Y. Srinivasan wrote:
> > In preparation for moving the mouse driver out of staging, seek community
> > review of the mouse driver code.
> >
>
> Because it is a HID driver it should go through Jiri Kosina's tree
> (CCed). Still, a few comments below.
Thanks Dmitry. I will address the comments you have given me, and will
work with Jiri to get this driver out of staging.
Regards,
K. Y
^ permalink raw reply
* RE: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of staging
From: KY Srinivasan @ 2011-10-23 14:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Haiyang Zhang, gregkh@suse.de,
linux-kernel@vger.kernel.org, virtualization@lists.osdl.org,
linux-input@vger.kernel.org, devel@linuxdriverproject.org
In-Reply-To: <20111023072427.GA13268@core.coreip.homeip.net>
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Sunday, October 23, 2011 3:24 AM
> To: KY Srinivasan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; virtualization@lists.osdl.org; linux-
> input@vger.kernel.org; Haiyang Zhang; Jiri Kosina
> Subject: Re: [PATCH 1/1] Staging: hv: mousevsc: Move the mouse driver out of
> staging
>
> Hi K. Y.,
>
> On Fri, Oct 14, 2011 at 11:08:27PM -0700, K. Y. Srinivasan wrote:
> > In preparation for moving the mouse driver out of staging, seek community
> > review of the mouse driver code.
> >
>
> Because it is a HID driver it should go through Jiri Kosina's tree
> (CCed). Still, a few comments below.
Thanks Dmitry. I will address the comments you have given me, and will
work with Jiri to get this driver out of staging.
Regards,
K. Y
^ permalink raw reply
* Re: a bug when execute "git status" in git version 1.7.7.431.g89633
From: René Scharfe @ 2011-10-23 14:28 UTC (permalink / raw)
Cc: John Hsing, Matthieu Moy, git, Jeff King
In-Reply-To: <4EA415BD.1040109@lsrfire.ath.cx>
Am 23.10.2011 15:25, schrieb René Scharfe:
> Am 23.10.2011 10:35, schrieb John Hsing:
>> ok,when i finish compiling git 1.7.7.431.g89633，I use it to check
>> Cyanogenod（an Android mod source） by “git status”，it happend this
>> error！but when i reuse git v1.7.7，it is OK！so i think it is a bug in
>> git 1.7.7.431.g89633！My OS is Ubuntu Linux 10.10，sorry for my bad
>> english！ If you want to reproduce this error,please excute "git status"
>> in https://github.com/CyanogenMod/android_packages_apps_DSPManager.git
>> repo!
>
> I can reproduce the malloc crash on Ubuntu 11.10 with these simple steps:
>
> $ a=android_packages_apps_DSPManager
> $ git-v1.7.7 clone https://github.com/CyanogenMod/$a.git
> Cloning into android_packages_apps_DSPManager...
> remote: Counting objects: 902, done.
> remote: Compressing objects: 100% (412/412), done.
> remote: Total 902 (delta 367), reused 838 (delta 324)
> Receiving objects: 100% (902/902), 136.78 KiB | 264 KiB/s, done.
> Resolving deltas: 100% (367/367), done.
> $ cd $a
>
> $ git-v1.7.7 status
> # On branch gingerbread
> nothing to commit (working directory clean)
>
> $ git-master status
> git: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
> Aborted
And valgrind reports the following errors (git was compiled with -O0 and
-g) for master, but not for 1.7.7 nor master plus my ugly patch:
Invalid write of size 1
at 0x4029DE5: memcpy (mc_replace_strmem.c:635)
by 0x81159A5: convert_from_disk (read-cache.c:1247)
by 0x8115BE4: read_index_from (read-cache.c:1326)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Address 0x41f2d5e is 2 bytes after a block of size 6,356 alloc'd
at 0x4028876: malloc (vg_replace_malloc.c:236)
by 0x814C070: xmalloc (wrapper.c:35)
by 0x8115B8E: read_index_from (read-cache.c:1315)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Syscall param lstat64(file_name) points to unaddressable byte(s)
at 0x4131D32: __lxstat64@@GLIBC_2.2 (lxstat64.c:48)
by 0x81154DE: refresh_index (read-cache.c:1133)
by 0x8068687: cmd_status (commit.c:1226)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Address 0x41f2d5c is 0 bytes after a block of size 6,356 alloc'd
at 0x4028876: malloc (vg_replace_malloc.c:236)
by 0x814C070: xmalloc (wrapper.c:35)
by 0x8115B8E: read_index_from (read-cache.c:1315)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Invalid read of size 1
at 0x402A682: bcmp (mc_replace_strmem.c:679)
by 0x8113D12: df_name_compare (read-cache.c:387)
by 0x81478F9: do_compare_entry (unpack-trees.c:499)
by 0x814791B: compare_entry (unpack-trees.c:504)
by 0x8148086: unpack_callback (unpack-trees.c:747)
by 0x8145EA5: traverse_trees (tree-walk.c:407)
by 0x81477EB: traverse_trees_recursive (unpack-trees.c:460)
by 0x814823D: unpack_callback (unpack-trees.c:809)
by 0x8145EA5: traverse_trees (tree-walk.c:407)
by 0x81477EB: traverse_trees_recursive (unpack-trees.c:460)
by 0x814823D: unpack_callback (unpack-trees.c:809)
by 0x8145EA5: traverse_trees (tree-walk.c:407)
Address 0x41f2d5c is 0 bytes after a block of size 6,356 alloc'd
at 0x4028876: malloc (vg_replace_malloc.c:236)
by 0x814C070: xmalloc (wrapper.c:35)
by 0x8115B8E: read_index_from (read-cache.c:1315)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Invalid read of size 1
at 0x8100E0E: hash_name (name-hash.c:28)
by 0x8100F3D: hash_index_entry (name-hash.c:78)
by 0x8100FD3: lazy_init_name_hash (name-hash.c:96)
by 0x8101197: index_name_exists (name-hash.c:159)
by 0x80EADA9: dir_add_name (dir.c:596)
by 0x80EB8CD: read_directory_recursive (dir.c:994)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EBCED: read_directory (dir.c:1101)
Address 0x41f2d5c is 0 bytes after a block of size 6,356 alloc'd
at 0x4028876: malloc (vg_replace_malloc.c:236)
by 0x814C070: xmalloc (wrapper.c:35)
by 0x8115B8E: read_index_from (read-cache.c:1315)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
Invalid read of size 1
at 0x402A687: bcmp (mc_replace_strmem.c:679)
by 0x8113DF4: cache_name_compare (read-cache.c:413)
by 0x81010F8: same_name (name-hash.c:134)
by 0x81011E0: index_name_exists (name-hash.c:164)
by 0x80EADA9: dir_add_name (dir.c:596)
by 0x80EB8CD: read_directory_recursive (dir.c:994)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
by 0x80EB895: read_directory_recursive (dir.c:983)
Address 0x41f2d5c is 0 bytes after a block of size 6,356 alloc'd
at 0x4028876: malloc (vg_replace_malloc.c:236)
by 0x814C070: xmalloc (wrapper.c:35)
by 0x8115B8E: read_index_from (read-cache.c:1315)
by 0x81157D7: read_index (read-cache.c:1202)
by 0x813A802: gitmodules_config (submodule.c:105)
by 0x806857E: cmd_status (commit.c:1209)
by 0x804B7F8: run_builtin (git.c:308)
by 0x804B956: handle_internal_command (git.c:466)
by 0x804BA4E: run_argv (git.c:512)
by 0x804BBC0: main (git.c:585)
^ permalink raw reply
* [PATCH v2 3/7] clk: Add fixed-rate clock
From: Shawn Guo @ 2011-10-23 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-4-git-send-email-mturquette@ti.com>
On Thu, Sep 22, 2011 at 03:26:58PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr <jeremy.kerr@canonical.com>
>
> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Mike Turquette <mturquette@ti.com>
> ---
> Changes since v1:
> Add copyright header
>
> drivers/clk/Kconfig | 4 ++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-fixed.c | 24 ++++++++++++++++++++++++
> include/linux/clk.h | 14 ++++++++++++++
> 4 files changed, 43 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/clk-fixed.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index c53ed59..d8313d7 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -8,3 +8,7 @@ config HAVE_MACH_CLKDEV
>
> config GENERIC_CLK
> bool
> +
> +config GENERIC_CLK_FIXED
> + bool
> + depends on GENERIC_CLK
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 570d5b9..9a3325a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -1,3 +1,4 @@
>
> obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
> obj-$(CONFIG_GENERIC_CLK) += clk.o
> +obj-$(CONFIG_GENERIC_CLK_FIXED) += clk-fixed.o
> diff --git a/drivers/clk/clk-fixed.c b/drivers/clk/clk-fixed.c
> new file mode 100644
> index 0000000..956fb9a
> --- /dev/null
> +++ b/drivers/clk/clk-fixed.c
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd <jeremy.kerr@canonical.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Simple fixed-rate clock implementation
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +
> +#define to_clk_fixed(c) container_of(c, struct clk_hw_fixed, hw)
> +
> +static unsigned long clk_fixed_recalc_rate(struct clk_hw *hw)
> +{
> + return to_clk_fixed(hw)->rate;
> +}
> +
> +struct clk_hw_ops clk_fixed_ops = {
> + .recalc_rate = clk_fixed_recalc_rate,
> +};
> +EXPORT_SYMBOL_GPL(clk_fixed_ops);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 0d2cd5e..1903dd8 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -110,6 +110,20 @@ int clk_prepare(struct clk *clk);
> */
> void clk_unprepare(struct clk *clk);
>
> +/* Base clock implementations. Platform clock implementations can use these
> + * directly, or 'subclass' as approprate */
> +
/*
* Multiple lines comments
*/
Regards,
Shawn
> +#ifdef CONFIG_GENERIC_CLK_FIXED
> +
> +struct clk_hw_fixed {
> + struct clk_hw hw;
> + unsigned long rate;
> +};
> +
> +extern struct clk_hw_ops clk_fixed_ops;
> +
> +#endif /* CONFIG_GENERIC_CLK_FIXED */
> +
> /**
> * clk_register - register and initialize a new clock
> *
> --
> 1.7.4.1
>
>
^ permalink raw reply
* [refpolicy] [PATCH 2/2] Allow user domains to call links
From: Sven Vermeulen @ 2011-10-23 14:30 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <20111023142947.GA17397@siphos.be>
Grant the links_role to the default user domains (staff, sysadm and the
regular user).
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
policy/modules/roles/staff.te | 4 ++++
policy/modules/roles/sysadm.te | 4 ++++
policy/modules/roles/unprivuser.te | 4 ++++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/policy/modules/roles/staff.te b/policy/modules/roles/staff.te
index c10c3d6..ae4a59a 100644
--- a/policy/modules/roles/staff.te
+++ b/policy/modules/roles/staff.te
@@ -109,6 +109,10 @@ ifndef(`distro_redhat',`
')
optional_policy(`
+ links_role(staff_r, staff_t)
+ ')
+
+ optional_policy(`
lockdev_role(staff_r, staff_t)
')
diff --git a/policy/modules/roles/sysadm.te b/policy/modules/roles/sysadm.te
index 954417f..200e490 100644
--- a/policy/modules/roles/sysadm.te
+++ b/policy/modules/roles/sysadm.te
@@ -461,5 +461,9 @@ ifndef(`distro_redhat',`
optional_policy(`
java_role(sysadm_r, sysadm_t)
')
+
+ optional_policy(`
+ links_role(sysadm_r, sysadm_t)
+ ')
')
diff --git a/policy/modules/roles/unprivuser.te b/policy/modules/roles/unprivuser.te
index c576b6c..074155f 100644
--- a/policy/modules/roles/unprivuser.te
+++ b/policy/modules/roles/unprivuser.te
@@ -86,6 +86,10 @@ ifndef(`distro_redhat',`
')
optional_policy(`
+ links_role(user_r, user_t)
+ ')
+
+ optional_policy(`
lockdev_role(user_r, user_t)
')
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Nicolas Ferre @ 2011-10-23 14:30 UTC (permalink / raw)
To: vinod.koul
Cc: linux-arm-kernel, robherring2, devicetree-discuss, linux-kernel
In-Reply-To: <4E9C258D.3030509@atmel.com>
On 10/17/2011 02:54 PM, Nicolas Ferre :
> On 10/12/2011 06:57 PM, Nicolas Ferre :
>> This series add the device tree support to Atmel DMA controller driver:
>> at_hdmac.
>> The removal of platform data ease the conversion to device tree. It also have
>> the additional benefit of being simpler and cleaner.
>>
>> Nicolas Ferre (4):
>> dmaengine: at_hdmac: platform data move to use .id_table
>> dmaengine: at_hdmac: add device tree support
>> ARM: at91/dma: remove platform data from DMA controller
>> ARM: at91/dma: DMA controller registering with DT support
>>
>> .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
>> arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
>> arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
>> arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
>> drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
>> drivers/dma/at_hdmac_regs.h | 8 ++
>> 6 files changed, 97 insertions(+), 36 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
>
> Vinod,
>
> I have just rebased the dmaengine at_hdmac driver patches on top of your
> "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> right now.
Vinod,
Ping?
Do you want me to provide you a git tree for those two patches?
Do you think it can make it for 3.2 merge window?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* LVM2/test t-lvcreate-large.sh
From: mornfall @ 2011-10-23 14:30 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: mornfall at sourceware.org 2011-10-23 14:30:51
Modified files:
test : t-lvcreate-large.sh
Log message:
In t-lvcreate-large, do not create a clustered VG. LV activation/suspend does
not work yet with singlenode clvmd in clustered VGs.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/test/t-lvcreate-large.sh.diff?cvsroot=lvm2&r1=1.2&r2=1.3
--- LVM2/test/t-lvcreate-large.sh 2011/09/16 14:32:47 1.2
+++ LVM2/test/t-lvcreate-large.sh 2011/10/23 14:30:51 1.3
@@ -13,9 +13,6 @@
. lib/test
-# FIXME: remove it later when locking in virtual origin is fixed
-test -e LOCAL_CLVMD && exit 200
-
aux prepare_vg 4
lvcreate -s -l 100%FREE -n $lv $vg --virtualsize 1024T
@@ -26,7 +23,7 @@
aux lvmconf 'devices/filter = [ "a/dev\/mapper\/.*$/", "a/dev\/LVMTEST/", "r/.*/" ]'
pvcreate $DM_DEV_DIR/$vg/$lv
-vgcreate $vg1 $DM_DEV_DIR/$vg/$lv
+vgcreate -c n $vg1 $DM_DEV_DIR/$vg/$lv
lvcreate -l 100%FREE -n $lv1 $vg1
check lv_field $vg1/$lv1 size "1024.00t"
@@ -40,4 +37,4 @@
check lv_field $vg1/$lv1 size "737.28t"
lvremove -ff $vg1/$lv1
-lvremove -ff $vg/$lv
\ No newline at end of file
+lvremove -ff $vg/$lv
^ permalink raw reply
* Re: Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
From: Michael Leun @ 2011-10-23 14:30 UTC (permalink / raw)
To: Alasdair G Kergon; +Cc: Linus Torvalds, LKML, dm-devel, Mikulas Patocka
In-Reply-To: <20111023134449.GA13703@agk-dp.fab.redhat.com>
On Sun, 23 Oct 2011 14:44:49 +0100
Alasdair G Kergon <agk@redhat.com> wrote:
> On Sun, Oct 23, 2011 at 12:52:06PM +0300, Linus Torvalds wrote:
> > Mikulas, Alasdair? I see the mempool_free() for the "master job",
> > what about everything else? Does the dm_kcopyd_prepare_callback()
> > perhaps need to do a
> >
> > job->master_job = job;
> >
> > or similar?
>
> If you look at the other place that performs that mempool_alloc, it's
> indeed present there.
>
> Michael - can you test if this solves the problem?
>
> Alasdair
>
> --- a/drivers/md/dm-kcopyd.c
> +++ b/drivers/md/dm-kcopyd.c
> @@ -628,6 +628,7 @@ void *dm_kcopyd_prepare_callback(struct
> dm_kcopyd_client *kc, job->kc = kc;
> job->fn = fn;
> job->context = context;
> + job->master_job = job;
>
> atomic_inc(&kc->nr_jobs);
>
>
Yup, it indeed does.
--
MfG,
Michael Leun
^ permalink raw reply
* [refpolicy] [PATCH 1/2] Support the console/graphical links browser
From: Sven Vermeulen @ 2011-10-23 14:30 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <20111023142947.GA17397@siphos.be>
Introduce the links_t domain for the links browser, which is an
ncurses/svgalib/X11 browser (so supports both commandline-only as
well as GUI environments)
Signed-off-by: Sven Vermeulen <sven.vermeulen@siphos.be>
---
links.fc | 6 ++++++
links.if | 36 ++++++++++++++++++++++++++++++++++++
links.te | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 links.fc
create mode 100644 links.if
create mode 100644 links.te
diff --git a/links.fc b/links.fc
new file mode 100644
index 0000000..5749b58
--- /dev/null
+++ b/links.fc
@@ -0,0 +1,6 @@
+HOME_DIR/\.links(/.*)? gen_context(system_u:object_r:links_home_t,s0)
+
+#
+# /usr
+#
+/usr/bin/links -- gen_context(system_u:object_r:links_exec_t,s0)
diff --git a/links.if b/links.if
new file mode 100644
index 0000000..bf3e20a
--- /dev/null
+++ b/links.if
@@ -0,0 +1,36 @@
+## <summary>Links web browser</summary>
+
+#######################################
+## <summary>
+## The role interface for the links module.
+## </summary>
+## <param name="user_role">
+## <summary>
+## The role associated with the user domain.
+## </summary>
+## </param>
+## <param name="user_domain">
+## <summary>
+## The type of the user domain.
+## </summary>
+## </param>
+#
+interface(`links_role',`
+ gen_require(`
+ type links_t, links_exec_t, links_tmpfs_t, links_home_t;
+ ')
+
+ role $1 types links_t;
+
+ manage_dirs_pattern($2, links_home_t, links_home_t)
+ manage_files_pattern($2, links_home_t, links_home_t)
+ manage_lnk_files_pattern($2, links_home_t, links_home_t)
+
+ relabel_dirs_pattern($2, links_home_t, links_home_t)
+ relabel_files_pattern($2, links_home_t, links_home_t)
+ relabel_lnk_files_pattern($2, links_home_t, links_home_t)
+
+ domtrans_pattern($2, links_exec_t, links_t)
+
+ ps_process_pattern($2, links_t)
+')
diff --git a/links.te b/links.te
new file mode 100644
index 0000000..6289570
--- /dev/null
+++ b/links.te
@@ -0,0 +1,57 @@
+policy_module(links, 1.0.0)
+
+############################
+#
+# Declarations
+#
+
+type links_t;
+type links_exec_t;
+application_domain(links_t, links_exec_t)
+
+type links_home_t;
+typealias links_home_t alias { user_links_home_t staff_links_home_t sysadm_links_home_t };
+userdom_user_home_content(links_home_t)
+
+type links_tmpfs_t;
+typealias links_tmpfs_t alias { user_links_tmpfs_t staff_links_tmpfs_t sysadm_links_tmpfs_t };
+files_tmpfs_file(links_tmpfs_t)
+ubac_constrained(links_tmpfs_t)
+
+############################
+#
+# Policy
+#
+
+allow links_t self:process signal_perms;
+allow links_t self:unix_stream_socket create_stream_socket_perms;
+
+manage_dirs_pattern(links_t, links_home_t, links_home_t)
+manage_files_pattern(links_t, links_home_t, links_home_t)
+manage_lnk_files_pattern(links_t, links_home_t, links_home_t)
+manage_sock_files_pattern(links_t, links_home_t, links_home_t)
+manage_fifo_files_pattern(links_t, links_home_t, links_home_t)
+
+manage_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_lnk_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_fifo_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+manage_sock_files_pattern(links_t, links_tmpfs_t, links_tmpfs_t)
+fs_tmpfs_filetrans(links_t, links_tmpfs_t, { file lnk_file sock_file fifo_file })
+
+userdom_user_home_dir_filetrans(links_t, links_home_t, dir)
+
+corenet_tcp_connect_http_port(links_t)
+
+domain_use_interactive_fds(links_t)
+
+auth_use_nsswitch(links_t)
+
+miscfiles_read_localization(links_t)
+
+userdom_manage_user_home_content_dirs(links_t)
+userdom_manage_user_home_content_files(links_t)
+userdom_use_user_terminals(links_t)
+
+optional_policy(`
+ xserver_user_x_domain_template(links, links_t, links_tmpfs_t)
+')
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Nicolas Ferre @ 2011-10-23 14:30 UTC (permalink / raw)
To: vinod.koul; +Cc: devicetree-discuss, linux-kernel, linux-arm-kernel
In-Reply-To: <4E9C258D.3030509@atmel.com>
On 10/17/2011 02:54 PM, Nicolas Ferre :
> On 10/12/2011 06:57 PM, Nicolas Ferre :
>> This series add the device tree support to Atmel DMA controller driver:
>> at_hdmac.
>> The removal of platform data ease the conversion to device tree. It also have
>> the additional benefit of being simpler and cleaner.
>>
>> Nicolas Ferre (4):
>> dmaengine: at_hdmac: platform data move to use .id_table
>> dmaengine: at_hdmac: add device tree support
>> ARM: at91/dma: remove platform data from DMA controller
>> ARM: at91/dma: DMA controller registering with DT support
>>
>> .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
>> arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
>> arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
>> arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
>> drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
>> drivers/dma/at_hdmac_regs.h | 8 ++
>> 6 files changed, 97 insertions(+), 36 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
>
> Vinod,
>
> I have just rebased the dmaengine at_hdmac driver patches on top of your
> "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> right now.
Vinod,
Ping?
Do you want me to provide you a git tree for those two patches?
Do you think it can make it for 3.2 merge window?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Nicolas Ferre @ 2011-10-23 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E9C258D.3030509@atmel.com>
On 10/17/2011 02:54 PM, Nicolas Ferre :
> On 10/12/2011 06:57 PM, Nicolas Ferre :
>> This series add the device tree support to Atmel DMA controller driver:
>> at_hdmac.
>> The removal of platform data ease the conversion to device tree. It also have
>> the additional benefit of being simpler and cleaner.
>>
>> Nicolas Ferre (4):
>> dmaengine: at_hdmac: platform data move to use .id_table
>> dmaengine: at_hdmac: add device tree support
>> ARM: at91/dma: remove platform data from DMA controller
>> ARM: at91/dma: DMA controller registering with DT support
>>
>> .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
>> arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
>> arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
>> arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
>> drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
>> drivers/dma/at_hdmac_regs.h | 8 ++
>> 6 files changed, 97 insertions(+), 36 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
>
> Vinod,
>
> I have just rebased the dmaengine at_hdmac driver patches on top of your
> "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> right now.
Vinod,
Ping?
Do you want me to provide you a git tree for those two patches?
Do you think it can make it for 3.2 merge window?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [refpolicy] [PATCH 0/2] Add links_t domain for the links browser
From: Sven Vermeulen @ 2011-10-23 14:29 UTC (permalink / raw)
To: refpolicy
This patchset adds support for the links browser.
^ permalink raw reply
* [ath9k-devel] Can't associate with a particular AP
From: Julien Valroff @ 2011-10-23 14:25 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <CAJ-VmokrVE+qVV721aSG933JUZ37kQ2z+j_OyYXFGEZRVvOLbQ@mail.gmail.com>
Hi,
Le dimanche 16 oct. 2011 ? 17:31:44 (+0200 CEST), Adrian Chadd a ?crit?:
> Can you please grab a third device and grab a dump of the actual
> probe/association frames?
>
> I think it'd be helpful to see what's changed.
I have tried and captured the association process from my 2 other laptops
using wireshark, but unfortunately, I am unable to capture packets in
monitoring mode: in Wireshark, the box is not greyed out, but I cannot tick
it.
I've tried reading the Wireshark documentation on this point, but I could
not see anything about this problem.
I have followed Peter's instructions and the ones described in [0] both
with the same results.
But still, I have been able to capture something from the problematic
laptop, you will find the wireshark logs attached.
When failing to associate, I can see a lot of lines as follows:
50 11.081661 ba:f4:8a:c6:c8:44 (TA) 74:2f:68:57:2c:dc (RA) 802.11 46 Request-to-send, Flags=........C
followed by:
166 23.082827 ba:f4:8a:c6:c8:44 74:2f:68:57:2c:dc 802.11 56 Deauthentication, SN=1142, FN=0, Flags=........C
where:
ba:f4:8a:c6:c8:44 is my AP
74:2f:68:57:2c:dc is my Atheros wlan NIC
When the association succeeds, I notice the MAC address of the AP changes:
99 5.752088 c6:6e:27:a6:be:a4 74:2f:68:57:2c:dc 802.11 272 Probe Response, SN=269, FN=0, Flags=........C, BI=100, SSID=Kirya
^^^^
Which is confirmed by iwlist scan.
Before the association:
Cell 01 - Address: BA:F4:8A:C6:C8:44
Channel:3
Frequency:2.422 GHz (Channel 3)
Quality=26/70 Signal level=-84 dBm
Encryption key:on
ESSID:"Kirya"
After the succeeded association:
Cell 04 - Address: C6:6E:27:A6:BE:A4
Channel:3
Frequency:2.422 GHz (Channel 3)
Quality=70/70 Signal level=-35 dBm
Encryption key:on
ESSID:"Kirya"
How is this possible?
Please continue and CC me as I am not subscribed to the list.
Cheers,
Julien
[0] http://wiki.wireshark.org/CaptureSetup/WLAN#Linux
--
.''`. Julien Valroff ~ <julien@kirya.net> ~ <julien@debian.org>
: :' : Debian Developer & Free software contributor
`. `'` http://www.kirya.net/
`- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireshark_failed-association
Type: application/octet-stream
Size: 27710 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20111023/cb08a59e/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireshark_succeeded-association
Type: application/octet-stream
Size: 46875 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20111023/cb08a59e/attachment-0003.obj
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.