* [PATCH,v2] [media] vivi: Constify structures
From: Kirill Smelkov @ 2012-12-28 13:12 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Mauro Carvalho Chehab, linux-media, linux-kernel
In-Reply-To: <201212271255.11159.hverkuil@xs4all.nl>
On Thu, Dec 27, 2012 at 12:55:11PM +0100, Hans Verkuil wrote:
> On Wed December 26 2012 16:29:43 Kirill Smelkov wrote:
> > Most of *_ops and other structures in vivi.c were already declared const
> > but some have not. Constify and code/data will take less space:
> >
> > $ size drivers/media/platform/vivi.o
> > text data bss dec hex filename
> > before: 12569 248 8 12825 3219 drivers/media/platform/vivi.o
> > after: 12308 20 8 12336 3030 drivers/media/platform/vivi.o
> >
> > i.e. vivi.o is now ~500 bytes less.
> >
> > Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
> > ---
> > drivers/media/platform/vivi.c | 26 +++++++++++++-------------
> > 1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> > index ec65089..bed04e1 100644
> > --- a/drivers/media/platform/vivi.c
> > +++ b/drivers/media/platform/vivi.c
> > @@ -91,13 +91,13 @@ static const struct v4l2_fract
> > ------------------------------------------------------------------*/
> >
> > struct vivi_fmt {
> > - char *name;
> > + const char *name;
>
> Just use one space before '*' since it no longer lines up to anything.
[...]
> > @@ -191,7 +191,7 @@ struct vivi_buffer {
> > /* common v4l buffer stuff -- must be first */
> > struct vb2_buffer vb;
> > struct list_head list;
> > - struct vivi_fmt *fmt;
> > + struct vivi_fmt const *fmt;
> > };
> >
> > struct vivi_dmaqueue {
> > @@ -250,7 +250,7 @@ struct vivi_dev {
> > int input;
> >
> > /* video capture */
> > - struct vivi_fmt *fmt;
> > + struct vivi_fmt const *fmt;
>
> 'const' should be before 'struct' for consistency reasons.
It's just a matter of style, and in this case I though putting const
after would not distract from the fact that fmt is `struct vivi_fmt *`
and also to align types beginning with non-const ones.
But anyway, style is style and this is not a big deal, so here you are
with corrected patch.
Thanks,
Kirill
---- 8< ----
From: Kirill Smelkov <kirr@navytux.spb.ru>
Date: Wed, 26 Dec 2012 19:23:26 +0400
Subject: [PATCH,v2] [media] vivi: Constify structures
Most of *_ops and other structures in vivi.c were already declared const
but some have not. Constify and code/data will take less space:
$ size drivers/media/platform/vivi.o
text data bss dec hex filename
before: 12569 248 8 12825 3219 drivers/media/platform/vivi.o
after: 12308 20 8 12336 3030 drivers/media/platform/vivi.o
i.e. vivi.o is now ~500 bytes less.
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
drivers/media/platform/vivi.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
v2:
- put 'const' always before anything, as noted by Hans Verkuil.
- no changes otherwise.
diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index ec65089..8a33a71 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -91,13 +91,13 @@ static const struct v4l2_fract
------------------------------------------------------------------*/
struct vivi_fmt {
- char *name;
+ const char *name;
u32 fourcc; /* v4l2 format id */
u8 depth;
bool is_yuv;
};
-static struct vivi_fmt formats[] = {
+static const struct vivi_fmt formats[] = {
{
.name = "4:2:2, packed, YUYV",
.fourcc = V4L2_PIX_FMT_YUYV,
@@ -164,9 +164,9 @@ static struct vivi_fmt formats[] = {
},
};
-static struct vivi_fmt *__get_format(u32 pixelformat)
+static const struct vivi_fmt *__get_format(u32 pixelformat)
{
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
unsigned int k;
for (k = 0; k < ARRAY_SIZE(formats); k++) {
@@ -181,7 +181,7 @@ static struct vivi_fmt *__get_format(u32 pixelformat)
return &formats[k];
}
-static struct vivi_fmt *get_format(struct v4l2_format *f)
+static const struct vivi_fmt *get_format(struct v4l2_format *f)
{
return __get_format(f->fmt.pix.pixelformat);
}
@@ -191,7 +191,7 @@ struct vivi_buffer {
/* common v4l buffer stuff -- must be first */
struct vb2_buffer vb;
struct list_head list;
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
};
struct vivi_dmaqueue {
@@ -250,7 +250,7 @@ struct vivi_dev {
int input;
/* video capture */
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
struct v4l2_fract timeperframe;
unsigned int width, height;
struct vb2_queue vb_vidq;
@@ -297,7 +297,7 @@ struct bar_std {
/* Maximum number of bars are 10 - otherwise, the input print code
should be modified */
-static struct bar_std bars[] = {
+static const struct bar_std bars[] = {
{ /* Standard ITU-R color bar sequence */
{ COLOR_WHITE, COLOR_AMBER, COLOR_CYAN, COLOR_GREEN,
COLOR_MAGENTA, COLOR_RED, COLOR_BLUE, COLOR_BLACK, COLOR_BLACK }
@@ -926,7 +926,7 @@ static void vivi_unlock(struct vb2_queue *vq)
}
-static struct vb2_ops vivi_video_qops = {
+static const struct vb2_ops vivi_video_qops = {
.queue_setup = queue_setup,
.buf_prepare = buffer_prepare,
.buf_queue = buffer_queue,
@@ -957,7 +957,7 @@ static int vidioc_querycap(struct file *file, void *priv,
static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
if (f->index >= ARRAY_SIZE(formats))
return -EINVAL;
@@ -993,7 +993,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct vivi_dev *dev = video_drvdata(file);
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
fmt = get_format(f);
if (!fmt) {
@@ -1102,7 +1102,7 @@ static int vidioc_s_input(struct file *file, void *priv, unsigned int i)
static int vidioc_enum_frameintervals(struct file *file, void *priv,
struct v4l2_frmivalenum *fival)
{
- struct vivi_fmt *fmt;
+ const struct vivi_fmt *fmt;
if (fival->index)
return -EINVAL;
@@ -1330,7 +1330,7 @@ static const struct v4l2_ioctl_ops vivi_ioctl_ops = {
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
-static struct video_device vivi_template = {
+static const struct video_device vivi_template = {
.name = "vivi",
.fops = &vivi_fops,
.ioctl_ops = &vivi_ioctl_ops,
--
1.8.1.rc3.329.g036938a
^ permalink raw reply related
* Re: [patch net-next V3,repost 0/4] net: allow to change carrier from userspace
From: Flavio Leitner @ 2012-12-28 13:18 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, edumazet, bhutchings, mirqus, shemminger, greearb,
john.r.fastabend
In-Reply-To: <1356688180-3549-1-git-send-email-jiri@resnulli.us>
On Fri, Dec 28, 2012 at 10:49:36AM +0100, Jiri Pirko wrote:
> This is basically a V3 of a repost of my previous patchset:
> "[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
>
> The way net-sysfs stores values changed and this patchset reflects it.
> Also, I exposed carrier via rtnetlink iface.
>
> So far, only dummy driver uses carrier change ndo. In very near future
> team driver will use that as well.
>
> V2->V3:
> - updated ndo_change_carrier comment by Dan Williams
>
> V1->v2:
> - added bigger comment to ndo and also note to operstate.txt documentation
> stating the clear purpose of this iface
>
> Jiri Pirko (4):
> net: add change_carrier netdev op
> net: allow to change carrier via sysfs
> rtnl: expose carrier value with possibility to set it
> dummy: implement carrier change
>
> Documentation/networking/operstates.txt | 4 ++++
> drivers/net/dummy.c | 10 ++++++++++
> include/linux/netdevice.h | 12 ++++++++++++
> include/uapi/linux/if_link.h | 1 +
> net/core/dev.c | 19 +++++++++++++++++++
> net/core/net-sysfs.c | 15 ++++++++++++++-
> net/core/rtnetlink.c | 10 ++++++++++
> 7 files changed, 70 insertions(+), 1 deletion(-)
I am using this patch series already with team.
Acked-by: Flavio Leitner <fbl@redhat.com>
^ permalink raw reply
* [Buildroot] Setting up Perf for buildroot
From: Kaiwan Billimoria @ 2012-12-28 13:11 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAPDLWs-tb5qydSKCRCAS1Zg6605_ZhmQn=fA6daVxgUm3tT2rw@mail.gmail.com>
Or, perhaps better:
BR2_LINUX_KERNEL_USERMODE_TOOLS_XXX
On Fri, Dec 28, 2012 at 6:39 PM, Kaiwan Billimoria
<kaiwan.billimoria@gmail.com> wrote:
> So I was thinking, keep a config directive in linux/Config.in called
> BR2_LINUX_KERNEL_TOOLS_XXX
> where XXX is the user-mode tool to be built.
^ permalink raw reply
* [Buildroot] Setting up Perf for buildroot
From: Kaiwan Billimoria @ 2012-12-28 13:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20121228115156.2f91b588@skate>
Reproducing the email referenced for context, below.
Pl see my comments inline below:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[Buildroot] [PATCH v3] usbip: new package
Thomas Petazzoni thomas.petazzoni at free-electrons.com
Wed Dec 26 17:32:20 UTC 2012
Dear Jeremy Rosen,
On Wed, 26 Dec 2012 17:49:57 +0100 (CET), Jeremy Rosen wrote:
> I would be interested too, more and more tools are distributed with
> the kernel that we might want to build... I'm thinking of the perf
> tools in particular
>
> is there an example somewhere on how to handle these ?
> Unfortunately, there isn't a really good and nice way of handling these
> in Buildroot for now.
>
> I see two options:
> * Add sub-options to the "Linux kernel" package, to allow the
> installation of perf, usbip or other userspace packages whose source
> code is bundled with the kernel source code. This is the easiest
> solution, since the kernel version, sources and al. is already
> defined. But it also has major drawbacks: 1/ it makes those tools
> available only if you build your kernel with Buildroot and 2/ it
> puts the configuration options to install those tools inside the
> "Linux kernel" menu, which is not very intuitive.
To my thinking, this (option 1 above) would be the "right" way.
Reasons:
a) As Thomas mentions below, there is an ABI (user<->kernel) that
needs to be honoured, which requires the correct kernel source tree
b) Experienced developers (i.e. buildroot end-users :) ) should be - /
be educated on / - aware of the trade-off's that building a
kernel-tree user-mode tool entails; we should clearly document the
"drawbacks" as well..
c) Drawback 1: Yes it does mean building BR with the kernel; but of
course, a serious end-user can then always choose to use their own
custom kernel afterwards... and regression-test to see whether the
tools work as expected
d) Drawback 2:not a very serious one, IMO... -this can further be
documented in the manual (& word gets around :) )
e) Merely extracting one or 2 folders from the kernel src tree may not
cut it for all tools; in fact, perf has some dependencies on other
portions of the kernel source tree.
So I was thinking, keep a config directive in linux/Config.in called
BR2_LINUX_KERNEL_TOOLS_XXX
where XXX is the user-mode tool to be built.
Thanks,
Kaiwan.
> * Add separate packages for each of those tools in package/, with
> those packages depending on the "linux" package. The extract step of
> those packages could copy the source code of these tools from the
> Linux kernel source tree into their build directory, or simply build
> then directly from within the Linux kernel source tree. It solves
> drawback (2) described above, but not drawback (1).
> * Add separate packages for each of those tools in package/, and make
> them independent from the Linux package. They would for example
> download the latest stable version of the Linux kernel source code,
> and use that as a source. The extract step could be customized to
> only extract the part of the kernel sources that are actually
> relevant for this package. This would solve both drawbacks (1) and
> (2), but adds different drawbacks: it's another place where we have
> to bump the kernel version regularly, and people may want to
> configure the version of the kernel sources used to build those
> tools: the primary reason why those tools are bundled with the
> kernel sources is because the userspace-to-kernel ABI specific to
> those tools gets changed from time to time, and therefore there may
> be compatibility issues in running those tools from kernel version X
> under a system running kernel version Y.
> Best regards,
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Fri, Dec 28, 2012 at 4:21 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Dear Jeremy Rosen,
>
> Please fix your e-mail client to wrap lines at a reasonable width.
>
> On Fri, 28 Dec 2012 11:18:06 +0100 (CET), Jeremy Rosen wrote:
>
> > my guess is that ideally the config entries should be in packages->debug tools, but the makefile should be integrated in the linux kernel makefile
> >
> > I don't think it's possible with KConfig, though...
> >
> >
> > maybe add a perf directory in the packages/ dir with only the Config.in and use the variables set by that Config.in within the kernel makefiles to build the tool
>
> See:
>
> Subject: Re: [Buildroot] [PATCH v3] usbip: new package
> Date: Wed, 26 Dec 2012 18:32:20 +0100
>
> where I did some suggestions on how to do this.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V4 2/2] cfg80211/nl80211: Enable drivers to implement mac address based ACL
From: Johannes Berg @ 2012-12-28 13:09 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1356690070-26612-2-git-send-email-vthiagar@qca.qualcomm.com>
On Fri, 2012-12-28 at 15:51 +0530, Vasanthakumar Thiagarajan wrote:
> + * @acl_type: ACL policy that driver supports,
> + * see &enum nl80211_acl_policy_attr.
That doesn't make a lot of sense, in particular not the way you use it.
What if a driver supports a blacklist but not a whitelist? It seems that
it should be a bitfield. Also setting a default that isn't "unsupported"
is a bad idea.
> + NL80211_ATTR_ACL_POLICY,
> +
> + NL80211_ATTR_MAC_ADDRS,
> +
> + NL80211_ATTR_MAC_ACL_MAX,
> +
> + NL80211_ATTR_ACL_TYPE,
> + if (WARN_ON((wiphy->acl_type <= NL80211_ACL_POLICY_MAX) &&
So basically you could remove the acl_type field completely.
I think maybe if you want to continue supporting the white- & blacklist
you should change it back to nested attributes, but treat the blacklist
there as an optimisation and ignore it for feature advertising.
johannes
^ permalink raw reply
* Re: how to look for source code in kernel
From: Borislav Petkov @ 2012-12-28 13:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: anish singh, amit mehta, Henrique Rodrigues, kishore kumar,
Jonathan Neuschäfer, linux-kernel, Kernelnewbies
In-Reply-To: <87a9syhbma.fsf@xmission.com>
On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote:
> git-ls-files | xargs fgrep 'struct f2fs_inode'
>
> That returns instantly and tells me where to look. If you can do an
> instant brute force search what is the point of an index?
Not if you're using a lame-ass laptop with a rotating disk:
$ time git ls-files | xargs grep -E 'struct mce\W*{'
arch/x86/include/uapi/asm/mce.h:struct mce {
arch/x86/kernel/cpu/mcheck/mce.c: if (!final || memcmp(m, final, sizeof(struct mce))) {
real 2m48.415s
user 0m2.388s
sys 0m15.668s
What I've grown accustomed to is cscope with a prior find run on the
kernel source tree to create a custom cscope.files which cscope uses to
index and then using vim bindings in cscope so that if, for example, the
cursor is on a function call, executing a keyboard shortcut opens the
definition of that function in another vim tab. I.e., a thin IDE done
right.
> My experience with gui editors is that they always hide something I
> need to see, or my code is just strange enough (say having asm file,
> or supporting multiple architectures) that the tools get horribly
> confused.
That's true, then I tend to use another xterm with tabbed vim showing
additional files. Btw, git ls-files assumes a source file is tracked by
git and in the seldom case where you're adding new, yet untracked files,
that won't work.
So probably a mixed approach of cscope in one window and grep + editor
in another would cover all bases. For a newbie who wants to only browse
the code, cscope should be enough for starters, I'd say.
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: Workaround for tcrypt bug?
From: Sandra Schlichting @ 2012-12-28 13:06 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-crypto
In-Reply-To: <20121228145509.16824jqi8bl9komo@www.dalek.fi>
> I think you are using wrong module argument, type= instead of mode=. Try
> 'modprobe tcrypt sec=2 mode=402' instead.
Thanks. I would never have thought of that =)
Now it preforms the test, but gives this interesting error:
[root@amd ~]# modprobe tcrypt sec=2 mode=402
Message from syslogd@amd at Dec 28 14:01:05 ...
kernel:[ 5508.698788] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:3416]
ERROR: could not insert 'tcrypt': Resource temporarily unavailable
and dmesg gives
[ 5483.730759]
[ 5483.730759] testing speed of async md5
[ 5483.730808] test 0 ( 16 byte blocks, 16 bytes per update, 1
updates): 1321110 opers/sec, 21137768 bytes/sec
[ 5485.729538] test 1 ( 64 byte blocks, 16 bytes per update, 4
updates): 580970 opers/sec, 37182112 bytes/sec
[ 5487.728254] test 2 ( 64 byte blocks, 64 bytes per update, 1
updates): 779323 opers/sec, 49876672 bytes/sec
[ 5489.726972] test 3 ( 256 byte blocks, 16 bytes per update, 16
updates): 200928 opers/sec, 51437568 bytes/sec
[ 5491.725692] test 4 ( 256 byte blocks, 64 bytes per update, 4
updates): 304514 opers/sec, 77955712 bytes/sec
[ 5493.724408] test 5 ( 256 byte blocks, 256 bytes per update, 1
updates): 365982 opers/sec, 93691392 bytes/sec
[ 5495.723126] test 6 ( 1024 byte blocks, 16 bytes per update, 64
updates): 55802 opers/sec, 57141248 bytes/sec
[ 5497.721848] test 7 ( 1024 byte blocks, 256 bytes per update, 4
updates): 110900 opers/sec, 113562112 bytes/sec
[ 5499.720564] test 8 ( 1024 byte blocks, 1024 bytes per update, 1
updates): 118861 opers/sec, 121713664 bytes/sec
[ 5501.719281] test 9 ( 2048 byte blocks, 16 bytes per update, 128
updates): 28424 opers/sec, 58212352 bytes/sec
[ 5503.718022] test 10 ( 2048 byte blocks, 256 bytes per update, 8
updates): 57602 opers/sec, 117968896 bytes/sec
[ 5505.716727] test 11 ( 2048 byte blocks, 1024 bytes per update, 2
updates): 61696 opers/sec, 126353408 bytes/sec
[ 5507.715435] test 12 ( 2048 byte blocks, 2048 bytes per update, 1 updates):
[ 5508.698788] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:3416]
[ 5508.698793] Modules linked in: tcrypt(+) ansi_cprng vmac xcbc zlib
seed rmd320 rmd256 rmd160 rmd128 cts ccm lzo ghash_generic gcm
salsa20_generic salsa20_x86_64 camellia_generic camellia_x86_64 fcrypt
pcbc tgr192 anubis wp512 khazad tea michael_mic arc4 cast6 cast5
deflate zlib_deflate sha512_generic serpent_sse2_x86_64
serpent_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul
glue_helper twofish_x86_64 twofish_common blowfish_generic
blowfish_x86_64 blowfish_common md4 des_generic fuse ip6table_filter
ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat
xt_CHECKSUM iptable_mangle lockd sunrpc bridge stp llc be2iscsi
iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio
libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_ipv4
nf_defrag_ipv4 xt_state nf_conntrack dm_crypt btusb eeepc_wmi asus_wmi
sparse_keymap video ath3k bluetooth rfkill microcode serio_raw r8169
mii k10temp i2c_piix4 snd_hda_codec_realtek snd_hda_codec_hdmi
snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm
snd_page_alloc snd_timer snd soundcore binfmt_misc vhost_net tun
macvtap macvlan kvm_amd kvm uinput ata_generic pata_acpi pata_atiixp
wmi radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core
[ 5508.698961] CPU 0
[ 5508.698970] Pid: 3416, comm: modprobe Not tainted
3.6.10-2.fc17.x86_64 #1 System manufacturer System Product
Name/F1A75-I DELUXE
[ 5508.698975] RIP: 0010:[<ffffffff812ddffb>] [<ffffffff812ddffb>]
md5_transform+0x4db/0x800
[ 5508.698991] RSP: 0018:ffff8801fb401a80 EFLAGS: 00000293
[ 5508.698995] RAX: 000000000c00583a RBX: 000000ff812e5114 RCX: 00000000ffffffff
[ 5508.698999] RDX: 00000000a636da5e RSI: 00000000ffffffff RDI: ffff880210c6c8a0
[ 5508.699002] RBP: ffff8801fb401ad8 R08: 00000000ffffffff R09: 00000000ffffffff
[ 5508.699006] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81e77e0a
[ 5508.699009] R13: ffffffff00000006 R14: ffff8801fb401a0e R15: ffffffffffffffff
[ 5508.699015] FS: 00007ff4d87f7740(0000) GS:ffff88021ec00000(0000)
knlGS:0000000000000000
[ 5508.699019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5508.699022] CR2: 00007ff4d86b3000 CR3: 00000001b4911000 CR4: 00000000000007f0
[ 5508.699027] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 5508.699031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 5508.699036] Process modprobe (pid: 3416, threadinfo
ffff8801fb400000, task ffff880213979710)
[ 5508.699038] Stack:
[ 5508.699041] 3e4ebf9e98282ef4 33626d4a33683409 ffffffffffffffff
ffffffffffffffff
[ 5508.699048] ffffffffffffffff ffffffffffffffff ffff8801c495f7c0
ffff880210c6c8a0
[ 5508.699055] ffff880210c6c8b0 0000000000000040 ffff880210c6c8b0
ffff8801fb401b38
[ 5508.699061] Call Trace:
[ 5508.699073] [<ffffffff812abc39>] md5_update+0xe9/0x140
[ 5508.699081] [<ffffffff812a6df5>] crypto_shash_update+0x45/0x120
[ 5508.699088] [<ffffffff812a6ceb>] ? crypto_shash_final+0x3b/0xc0
[ 5508.699095] [<ffffffff812a6f50>] shash_finup_unaligned+0x20/0x40
[ 5508.699102] [<ffffffff812a6f8f>] crypto_shash_finup+0x1f/0x40
[ 5508.699108] [<ffffffff812a6ff8>] shash_digest_unaligned+0x48/0x60
[ 5508.699115] [<ffffffff812a72b0>] ? shash_ahash_digest+0xf0/0xf0
[ 5508.699121] [<ffffffff812a702f>] crypto_shash_digest+0x1f/0x40
[ 5508.699128] [<ffffffff812a727e>] shash_ahash_digest+0xbe/0xf0
[ 5508.699134] [<ffffffff812a72b0>] ? shash_ahash_digest+0xf0/0xf0
[ 5508.699141] [<ffffffff812a72d4>] shash_async_digest+0x24/0x30
[ 5508.699147] [<ffffffff812a6465>] crypto_ahash_op+0x35/0xe0
[ 5508.699153] [<ffffffff812a6526>] crypto_ahash_digest+0x16/0x20
[ 5508.699164] [<ffffffffa0701e89>]
test_ahash_speed.constprop.7+0x659/0x7b0 [tcrypt]
[ 5508.699172] [<ffffffff810b9acc>] ? smp_call_function_many+0x22c/0x260
[ 5508.699185] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699195] [<ffffffffa0702061>] do_test+0x81/0x2404 [tcrypt]
[ 5508.699205] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699214] [<ffffffffa015b06e>] tcrypt_mod_init+0x6e/0x1000 [tcrypt]
[ 5508.699224] [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699233] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180
[ 5508.699242] [<ffffffff810bf16e>] sys_init_module+0xfbe/0x20c0
[ 5508.699248] [<ffffffff812f9220>] ? ddebug_proc_open+0xd0/0xd0
[ 5508.699257] [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
[ 5508.699260] Code: ec 44 8b 6d d4 41 c1 c4 17 41 01 c4 47 8d b4 35
44 ea be a4 41 89 c5 41 31 d5 45 31 e5 45 01 f5 44 8b 75 c8 41 c1 c5
04 45 01 e5 <41> 8d 94 16 a9 cf de 4b 45 8d b4 03 60 4b bb f6 89 55 b4
44 89
[ 5509.714149] 62666 opers/sec, 128339968 bytes/sec
[ 5509.714153] test 13 ( 4096 byte blocks, 16 bytes per update, 256
updates): 14349 opers/sec, 58773504 bytes/sec
[ 5511.712900] test 14 ( 4096 byte blocks, 256 bytes per update, 16
updates): 29364 opers/sec, 120274944 bytes/sec
[ 5513.711616] test 15 ( 4096 byte blocks, 1024 bytes per update, 4
updates): 31516 opers/sec, 129089536 bytes/sec
[ 5515.710331] test 16 ( 4096 byte blocks, 4096 bytes per update, 1
updates): 32178 opers/sec, 131803136 bytes/sec
[ 5517.709019] test 17 ( 8192 byte blocks, 16 bytes per update, 512
updates): 7208 opers/sec, 59047936 bytes/sec
[ 5519.707805] test 18 ( 8192 byte blocks, 256 bytes per update, 32
updates): 14826 opers/sec, 121458688 bytes/sec
[ 5521.706479] test 19 ( 8192 byte blocks, 1024 bytes per update, 8
updates): 15924 opers/sec, 130449408 bytes/sec
[ 5523.705188] test 20 ( 8192 byte blocks, 4096 bytes per update, 2
updates): 16264 opers/sec, 133234688 bytes/sec
[ 5525.703944] test 21 ( 8192 byte blocks, 8192 bytes per update, 1
updates): 16262 opers/sec, 133218304 bytes/sec
[root@amd maj]#
^ permalink raw reply
* [Buildroot] [PATCH 2/2] ulogd: add support for mysql output
From: Gustavo Zacarias @ 2012-12-28 13:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1356699955-27479-1-git-send-email-gustavo@zacarias.com.ar>
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/ulogd/ulogd.mk | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/package/ulogd/ulogd.mk b/package/ulogd/ulogd.mk
index 4620bbd..34d8665 100644
--- a/package/ulogd/ulogd.mk
+++ b/package/ulogd/ulogd.mk
@@ -7,7 +7,7 @@
ULOGD_VERSION = 2.0.1
ULOGD_SOURCE = ulogd-$(ULOGD_VERSION).tar.bz2
ULOGD_SITE = http://www.netfilter.org/projects/ulogd/files
-ULOGD_CONF_OPT = --with-dbi=no --with-mysql=no --with-pgsql=no
+ULOGD_CONF_OPT = --with-dbi=no --with-pgsql=no
ULOGD_AUTORECONF = YES
ULOGD_DEPENDENCIES = host-pkgconf \
libmnl libnetfilter_acct libnetfilter_conntrack libnetfilter_log \
@@ -15,4 +15,11 @@ ULOGD_DEPENDENCIES = host-pkgconf \
ULOGD_LICENSE = GPLv2
ULOGD_LICENSE_FILES = COPYING
+ifeq ($(BR2_PACKAGE_MYSQL_CLIENT),y)
+ULOGD_CONF_OPT += --with-mysql=$(STAGING_DIR)/usr
+ULOGD_DEPENDENCIES += mysql_client
+else
+ULOGD_CONF_OPT += --with-mysql=no
+endif
+
$(eval $(autotools-package))
--
1.7.8.6
^ permalink raw reply related
* [Buildroot] [PATCH 1/2] mysql_client: bump to version 5.1.67
From: Gustavo Zacarias @ 2012-12-28 13:05 UTC (permalink / raw)
To: buildroot
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
package/mysql_client/mysql_client.mk | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/package/mysql_client/mysql_client.mk b/package/mysql_client/mysql_client.mk
index 9785aee..1477b66 100644
--- a/package/mysql_client/mysql_client.mk
+++ b/package/mysql_client/mysql_client.mk
@@ -4,12 +4,14 @@
#
#############################################################
-MYSQL_CLIENT_VERSION = 5.1.66
+MYSQL_CLIENT_VERSION = 5.1.67
MYSQL_CLIENT_SOURCE = mysql-$(MYSQL_CLIENT_VERSION).tar.gz
MYSQL_CLIENT_SITE = http://downloads.skysql.com/archives/mysql-5.1
MYSQL_CLIENT_INSTALL_STAGING = YES
MYSQL_CLIENT_DEPENDENCIES = readline ncurses
-MYSQL_CLIENT_AUTORECONF=YES
+MYSQL_CLIENT_AUTORECONF = YES
+MYSQL_CLIENT_LICENSE = GPLv2
+MYSQL_CLIENT_LICENSE_FILES = README COPYING
MYSQL_CLIENT_CONF_ENV = \
ac_cv_sys_restartable_syscalls=yes \
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH net-next] bridge: respect RFC2863 operational state
From: Flavio Leitner @ 2012-12-28 13:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20121227222854.6ec132dd@nehalam.linuxnetplumber.net>
On Thu, Dec 27, 2012 at 10:28:54PM -0800, Stephen Hemminger wrote:
> The bridge link detection should follow the operational state
> of the lower device, rather than the carrier bit. This allows devices
> like tunnels that are controlled by userspace control plane to work
> with bridge STP link management.
>
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>
> --- a/net/bridge/br_if.c 2012-10-25 09:11:15.627272524 -0700
> +++ b/net/bridge/br_if.c 2012-12-14 08:58:14.329847361 -0800
> @@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
> struct net_device *dev = p->dev;
> struct net_bridge *br = p->br;
>
> - if (netif_running(dev) && netif_carrier_ok(dev))
> + if (netif_running(dev) && netif_oper_up(dev))
> p->path_cost = port_cost(dev);
>
> if (!netif_running(br->dev))
> return;
>
> spin_lock_bh(&br->lock);
> - if (netif_running(dev) && netif_carrier_ok(dev)) {
> + if (netif_running(dev) && netif_oper_up(dev))
> if (p->state == BR_STATE_DISABLED)
> br_stp_enable_port(p);
I found this piece still using netif_carrier_ok():
321 int br_add_if(struct net_bridge *br, struct net_device *dev)
322 {
...
385
386 if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
387 (br->dev->flags & IFF_UP))
388 br_stp_enable_port(p);
389 spin_unlock_bh(&br->lock);
390
Is there any reason for enabling stp on a port using operstate
in br_port_carrier_check() but not in br_add_if() ?
The same thing happens with br_stp_enable_bridge():
56 list_for_each_entry(p, &br->port_list, list) {
57 if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
58 br_stp_enable_port(p);
Also, as operstate UP means that packets are flowing, there is no need to
check if the device is opened, so checking only for operstate should be
enough, right? I.e.
- if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
+ if (netif_oper_up(dev))
> } else {
> --- a/net/bridge/br_notify.c 2012-10-25 09:11:15.631272484 -0700
> +++ b/net/bridge/br_notify.c 2012-12-14 08:57:36.954222724 -0800
> @@ -82,7 +82,7 @@ static int br_device_event(struct notifi
> break;
>
> case NETDEV_UP:
> - if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
> + if (netif_running(br->dev) && netif_oper_up(dev)) {
> spin_lock_bh(&br->lock);
> br_stp_enable_port(p);
> spin_unlock_bh(&br->lock);
You are not just changing to use operstate, but also to check another
flag - before it was IFF_UP and now __LINK_STATE_START. Any reason
for that besides being consistent with other checks?
thanks!
--
fbl
^ permalink raw reply
* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
To: Daniel Kiper
Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3,
maxim.uvarov, kexec, x86, virtualization, mingo, ebiederm,
jbeulich, hpa, tglx, vgoyal
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>
On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
>
> Is this available somewhere? May I have a look at it?
http://marc.info/?l=linux-kernel&m=135581534620383
The for-x86-boot-v7 and -v8 branches.
HTH.
--
Regards/Gruss,
Boris.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
To: Daniel Kiper
Cc: hpa, kexec, xen-devel, konrad.wilk, tglx, ebiederm, maxim.uvarov,
andrew.cooper3, jbeulich, mingo, x86, virtualization, vgoyal,
linux-kernel
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>
On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
>
> Is this available somewhere? May I have a look at it?
http://marc.info/?l=linux-kernel&m=135581534620383
The for-x86-boot-v7 and -v8 branches.
HTH.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
To: Daniel Kiper
Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3,
maxim.uvarov, kexec, x86, virtualization, mingo, ebiederm,
jbeulich, hpa, tglx, vgoyal
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>
On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
>
> Is this available somewhere? May I have a look at it?
http://marc.info/?l=linux-kernel&m=135581534620383
The for-x86-boot-v7 and -v8 branches.
HTH.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 12:57 UTC (permalink / raw)
To: Zhouping Liu
Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
hughd, Andrea Arcangeli, Hillf Danton, sedat.dilek
In-Reply-To: <1828895463.36547216.1356662710202.JavaMail.root@redhat.com>
On 28.12.2012 03:45, Zhouping Liu wrote:
>>
>> Thank you for the report Zhouping!
>>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> Hello Zlatko,
>
> I have tested the below patch(applied it on mainline directly),
> but IMO, I'd like to say it maybe don't fix the issue completely.
>
> run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
> another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such as the dmesg log:
>
> [ 713.066937] Killed process 6085 (oom01) total-vm:18880768kB, anon-rss:7915612kB, file-rss:4kB
> [ 959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ......
>
> I'm not sure whether it's your patch triggering the hung task or not, but reverted cda73a10eb3,
> the reproducer(oom01) can PASS without both 'NULL pointer dereference at 0000000000000500' and hung task issues.
>
> but some time, it's possible that the reproducer(oom01) cause hung task on a box with large RAM(100Gb+), so I can't judge it...
>
Thanks for the test.
Yes, close to OOM things get quite unstable and it's hard to get
reliable test results. Maybe you could run it a few times, and see if
you can get any meaningful statistics out of a few runs. I need to check
oom.c myself and see what it's doing. Thanks for the link.
Regards,
--
Zlatko
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 12:57 UTC (permalink / raw)
To: Zhouping Liu
Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
hughd, Andrea Arcangeli, Hillf Danton, sedat.dilek
In-Reply-To: <1828895463.36547216.1356662710202.JavaMail.root@redhat.com>
On 28.12.2012 03:45, Zhouping Liu wrote:
>>
>> Thank you for the report Zhouping!
>>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> Hello Zlatko,
>
> I have tested the below patch(applied it on mainline directly),
> but IMO, I'd like to say it maybe don't fix the issue completely.
>
> run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
> another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such as the dmesg log:
>
> [ 713.066937] Killed process 6085 (oom01) total-vm:18880768kB, anon-rss:7915612kB, file-rss:4kB
> [ 959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ......
>
> I'm not sure whether it's your patch triggering the hung task or not, but reverted cda73a10eb3,
> the reproducer(oom01) can PASS without both 'NULL pointer dereference at 0000000000000500' and hung task issues.
>
> but some time, it's possible that the reproducer(oom01) cause hung task on a box with large RAM(100Gb+), so I can't judge it...
>
Thanks for the test.
Yes, close to OOM things get quite unstable and it's hard to get
reliable test results. Maybe you could run it a few times, and see if
you can get any meaningful statistics out of a few runs. I need to check
oom.c myself and see what it's doing. Thanks for the link.
Regards,
--
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V4 2/2] cfg80211/nl80211: Enable drivers to implement mac address based ACL
From: Johannes Berg @ 2012-12-28 12:56 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1356694308.9922.1.camel@jlt4.sipsolutions.net>
On Fri, 2012-12-28 at 12:31 +0100, Johannes Berg wrote:
> On Fri, 2012-12-28 at 15:51 +0530, Vasanthakumar Thiagarajan wrote:
>
> > V4:
> > - Change it accordingly so that at any time the driver can
> > support either white or black list not both.
>
> I was under the impression you needed both. Unless I get confirmation
> from Kalle and/or Jouni I'll not apply this lest it needs to be changed
> in yet again incompatible ways later ...
Actually I just talked to Jouni again and it seems that the best way to
think of the combined black/whitelist is to treat it as a whitelist +
"notification avoidance optimisation list". The key here being
optimisation, we don't really have to worry about it in terms of feature
advertising etc. since it can be ignored/managed by the driver.
johannes
^ permalink raw reply
* [U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
From: Enric Balletbo Serra @ 2012-12-28 12:55 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1356699113-30731-1-git-send-email-javier.martinez@collabora.co.uk>
2012/12/28 Javier Martinez Canillas <javier@dowhile0.org>:
> When booting an IGEPv2 board from NAND with SPL, U-Boot hangs
> trying to read the OMAP General Purpose Memory Controller (GPMC).
>
> The reason is that the GPMC initialization function is called
> inside spl_board_init() and this function is only executed when
> CONFIG_SPL_BOARD_INIT is defined.
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
> include/configs/igep00x0.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 47f637e..2110e64 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -318,6 +318,7 @@
> #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1
> #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img"
>
> +#define CONFIG_SPL_BOARD_INIT
> #define CONFIG_SPL_LIBCOMMON_SUPPORT
> #define CONFIG_SPL_LIBDISK_SUPPORT
> #define CONFIG_SPL_I2C_SUPPORT
> --
> 1.7.7.6
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Acked-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
^ permalink raw reply
* Re: Workaround for tcrypt bug?
From: Jussi Kivilinna @ 2012-12-28 12:55 UTC (permalink / raw)
To: Sandra Schlichting; +Cc: linux-crypto
In-Reply-To: <CAELiMBMrmagP14SoE1aaDqnuXvwdtVM69zpmK5dn+9Zqby8sQw@mail.gmail.com>
Quoting Sandra Schlichting <littlesandra88@gmail.com>:
>> Why you want to workaround this? It's safe to ignore hmac(crc32) warning.
>
> Because it stops from proceeding. I would have expected that
>
> modprobe tcrypt sec=1 type=1000
>
> would have executed all test cases.
>
> Even if I just want to test one
>
> [root@amd ~]# modprobe tcrypt sec=2 type=402
> ERROR: could not insert 'tcrypt': No such file or directory
>
> I get an error.
I think you are using wrong module argument, type= instead of mode=.
Try 'modprobe tcrypt sec=2 mode=402' instead.
-Jussi
^ permalink raw reply
* Re: [PATCH v2] sys-tools: Enhance unshare command to support the switching of namespaces
From: Ángel González @ 2012-12-28 12:54 UTC (permalink / raw)
To: Neil Horman; +Cc: util-linux, kerolasa, grawity, Karel Zak
In-Reply-To: <1356027729-26098-1-git-send-email-nhorman@tuxdriver.com>
On 20/12/12 19:22, Neil Horman wrote:
> case 'm':
> - unshare_flags |= CLONE_NEWNS;
> + ns = "mount";
> + if (!optarg)
> + unshare_flags |= CLONE_NEWNS;
> break;
Is this right? I don't have a /proc/<task>/ns/mount locally nor is it
documented in
http://git.kernel.org/?p=docs/man-pages/man-pages.git;a=blob;f=man5/proc.5
However looking at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=fs/proc/namespaces.c
there is a reference to mntns_operations, which is defined in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=fs/proc/namespaces.c
but seems to be called "mnt", not "mount"
There are also pid and user namespaces there, but support for those are
better handled in a different patch IMHO.
> + sprintf(path, "/proc/%d/ns/%s", (int)pid, ns);
> + ns_pids[nscount] = open(path, O_RDONLY);
> + if (ns_pids[nscount] < 0)
> + err(EXIT_FAILURE, _("could not open %s"), path);
> + nscount++;
What about err(EXIT_FAILURE, _("The kernel doesn't seem to support %s
migrations: could not open %s"), ns, path); ?
Mention in the man page the kernel version from which each namespace can
be migrated.
^ permalink raw reply
* [U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
From: Javier Martinez Canillas @ 2012-12-28 12:51 UTC (permalink / raw)
To: u-boot
When booting an IGEPv2 board from NAND with SPL, U-Boot hangs
trying to read the OMAP General Purpose Memory Controller (GPMC).
The reason is that the GPMC initialization function is called
inside spl_board_init() and this function is only executed when
CONFIG_SPL_BOARD_INIT is defined.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
include/configs/igep00x0.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 47f637e..2110e64 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -318,6 +318,7 @@
#define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION 1
#define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME "u-boot.img"
+#define CONFIG_SPL_BOARD_INIT
#define CONFIG_SPL_LIBCOMMON_SUPPORT
#define CONFIG_SPL_LIBDISK_SUPPORT
#define CONFIG_SPL_I2C_SUPPORT
--
1.7.7.6
^ permalink raw reply related
* [PATCH BlueZ 11/11] AVRCP: Fix not checking for media_player_controller_create
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Now that the MediaPlayer1 interface is experimental the interface
registration may fail which return NULL, in that case there is no
point on register to any notifications.
---
profiles/audio/avrcp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
index 4e3d31d..ce070cd 100644
--- a/profiles/audio/avrcp.c
+++ b/profiles/audio/avrcp.c
@@ -1987,6 +1987,11 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
count = pdu->params[1];
+ path = device_get_path(session->dev->btd_dev);
+ mp = media_player_controller_create(path);
+ if (mp == NULL)
+ return FALSE;
+
for (; count > 0; count--) {
uint8_t event = pdu->params[1 + count];
@@ -2001,8 +2006,6 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
}
}
- path = device_get_path(session->dev->btd_dev);
- mp = media_player_controller_create(path);
media_player_set_callbacks(mp, &ct_cbs, player);
player->user_data = mp;
player->destroy = (GDestroyNotify) media_player_destroy;
--
1.8.0.1
^ permalink raw reply related
* [PATCH BlueZ 10/11] player: Enable MediaPlayer1 interface as experimental
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This enable MediaPlayer1 when GDBUS_EXPERIMENTAL=1
---
profiles/audio/player.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/profiles/audio/player.c b/profiles/audio/player.c
index 005d0d1..693a590 100644
--- a/profiles/audio/player.c
+++ b/profiles/audio/player.c
@@ -239,25 +239,31 @@ static void set_setting(const GDBusPropertyTable *property,
}
static const GDBusMethodTable media_player_methods[] = {
- { GDBUS_METHOD("GetTrack",
+ { GDBUS_EXPERIMENTAL_METHOD("GetTrack",
NULL, GDBUS_ARGS({ "metadata", "a{sv}" }),
media_player_get_track) },
{ }
};
static const GDBusSignalTable media_player_signals[] = {
- { GDBUS_SIGNAL("TrackChanged",
+ { GDBUS_EXPERIMENTAL_SIGNAL("TrackChanged",
GDBUS_ARGS({ "metadata", "a{sv}" })) },
{ }
};
static const GDBusPropertyTable media_player_properties[] = {
- { "Position", "u", get_position },
- { "Status", "s", get_status, NULL, status_exists },
- { "Equalizer", "s", get_setting, set_setting, setting_exists },
- { "Repeat", "s", get_setting, set_setting, setting_exists },
- { "Shuffle", "s", get_setting, set_setting, setting_exists },
- { "Scan", "s", get_setting, set_setting, setting_exists },
+ { "Position", "u", get_position, NULL, NULL,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Status", "s", get_status, NULL, status_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Equalizer", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Repeat", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Shuffle", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Scan", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
{ }
};
@@ -298,7 +304,6 @@ struct media_player *media_player_controller_create(const char *path)
g_free, g_free);
mp->progress = g_timer_new();
-#if 0
if (!g_dbus_register_interface(btd_get_dbus_connection(),
mp->path, MEDIA_PLAYER_INTERFACE,
media_player_methods,
@@ -308,7 +313,7 @@ struct media_player *media_player_controller_create(const char *path)
media_player_destroy(mp);
return NULL;
}
-#endif
+
DBG("%s", mp->path);
return mp;
@@ -410,7 +415,6 @@ void media_player_set_status(struct media_player *mp, const char *status)
static gboolean process_metadata_changed(void *user_data)
{
-#if 0
struct media_player *mp = user_data;
DBusMessage *signal;
DBusMessageIter iter, dict;
@@ -439,7 +443,7 @@ static gboolean process_metadata_changed(void *user_data)
dbus_message_iter_close_container(&iter, &dict);
g_dbus_send_message(btd_get_dbus_connection(), signal);
-#endif
+
return FALSE;
}
--
1.8.0.1
^ permalink raw reply related
* [PATCH BlueZ 09/11] media: Enable RegisterPlayer and UnregisterPlayer methods as experimental
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
profiles/audio/media.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/profiles/audio/media.c b/profiles/audio/media.c
index f728460..e4206e3 100644
--- a/profiles/audio/media.c
+++ b/profiles/audio/media.c
@@ -868,7 +868,6 @@ static DBusMessage *unregister_endpoint(DBusConnection *conn, DBusMessage *msg,
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
-#if 0
static struct media_player *media_adapter_find_player(
struct media_adapter *adapter,
const char *sender,
@@ -1533,7 +1532,6 @@ static DBusMessage *unregister_player(DBusConnection *conn, DBusMessage *msg,
return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
}
-#endif
static const GDBusMethodTable media_methods[] = {
{ GDBUS_METHOD("RegisterEndpoint",
@@ -1541,14 +1539,12 @@ static const GDBusMethodTable media_methods[] = {
NULL, register_endpoint) },
{ GDBUS_METHOD("UnregisterEndpoint",
GDBUS_ARGS({ "endpoint", "o" }), NULL, unregister_endpoint) },
-#if 0
- { GDBUS_METHOD("RegisterPlayer",
+ { GDBUS_EXPERIMENTAL_METHOD("RegisterPlayer",
GDBUS_ARGS({ "player", "o" }, { "properties", "a{sv}" },
{ "metadata", "a{sv}" }),
NULL, register_player) },
- { GDBUS_METHOD("UnregisterPlayer",
+ { GDBUS_EXPERIMENTAL_METHOD("UnregisterPlayer",
GDBUS_ARGS({ "player", "o" }), NULL, unregister_player) },
-#endif
{ },
};
@@ -1559,10 +1555,8 @@ static void path_free(void *data)
while (adapter->endpoints)
release_endpoint(adapter->endpoints->data);
-#if 0
while (adapter->players)
media_player_destroy(adapter->players->data);
-#endif
adapters = g_slist_remove(adapters, adapter);
--
1.8.0.1
^ permalink raw reply related
* [PATCH BlueZ 08/11] core: Reuse --compat/-C switch for enabling deprecated interfaces
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
src/main.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/main.c b/src/main.c
index 2e8ba34..f6c4ee6 100644
--- a/src/main.c
+++ b/src/main.c
@@ -524,10 +524,12 @@ int main(int argc, char *argv[])
if (option_experimental)
gdbus_flags = G_DBUS_FLAG_ENABLE_EXPERIMENTAL;
- g_dbus_set_flags(gdbus_flags);
-
- if (option_compat == TRUE)
+ if (option_compat == TRUE) {
sdp_flags |= SDP_SERVER_COMPAT;
+ gdbus_flags |= G_DBUS_FLAG_ENABLE_DEPRECATED;
+ }
+
+ g_dbus_set_flags(gdbus_flags);
start_sdp_server(sdp_mtu, sdp_flags);
--
1.8.0.1
^ permalink raw reply related
* [PATCH BlueZ 07/11] core: Add command line switch for enabling experimental interfaces
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This enable passing --experimental/-E to enable experimental interfaces
---
src/main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/main.c b/src/main.c
index 4a67e0f..2e8ba34 100644
--- a/src/main.c
+++ b/src/main.c
@@ -368,6 +368,7 @@ static gchar *option_noplugin = NULL;
static gboolean option_compat = FALSE;
static gboolean option_detach = TRUE;
static gboolean option_version = FALSE;
+static gboolean option_experimental = FALSE;
static void free_options(void)
{
@@ -453,6 +454,8 @@ static GOptionEntry options[] = {
"Specify plugins not to load", "NAME,..." },
{ "compat", 'C', 0, G_OPTION_ARG_NONE, &option_compat,
"Provide deprecated command line interfaces" },
+ { "experimental", 'E', 0, G_OPTION_ARG_NONE, &option_experimental,
+ "Enable experimental interfaces" },
{ "nodetach", 'n', G_OPTION_FLAG_REVERSE,
G_OPTION_ARG_NONE, &option_detach,
"Run with logging in foreground" },
@@ -467,6 +470,7 @@ int main(int argc, char *argv[])
GError *err = NULL;
uint16_t sdp_mtu = 0;
uint32_t sdp_flags = 0;
+ int gdbus_flags = 0;
GKeyFile *config;
guint signal, watchdog;
const char *watchdog_usec;
@@ -517,6 +521,11 @@ int main(int argc, char *argv[])
exit(1);
}
+ if (option_experimental)
+ gdbus_flags = G_DBUS_FLAG_ENABLE_EXPERIMENTAL;
+
+ g_dbus_set_flags(gdbus_flags);
+
if (option_compat == TRUE)
sdp_flags |= SDP_SERVER_COMPAT;
--
1.8.0.1
^ permalink raw reply related
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.