* Re: [Qemu-trivial] [Qemu-devel] [PATCH] cmd: Fix potential NULL pointer dereference
From: Pavel Borzenkov @ 2011-10-31 7:18 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-trivial, qemu-devel
In-Reply-To: <m3pqhdn09j.fsf@blackfin.pond.sub.org>
On Mon, Oct 31, 2011 at 10:27 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Pavel Borzenkov <pavel.borzenkov@gmail.com> writes:
>
>> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
>> ---
>> Note, that almost all code in the file violates CODING STYLE. The changed lines
>> are written wrt CODING STYLE (like commits 7d7d975c and c32d766a).
>>
>> ---
>>
>> cmd.c | 11 +++--------
>> 1 files changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/cmd.c b/cmd.c
>> index f77897e..abcf206 100644
>> --- a/cmd.c
>> +++ b/cmd.c
>> @@ -49,7 +49,7 @@ void
>> add_command(
>> const cmdinfo_t *ci)
>> {
>> - cmdtab = realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> + cmdtab = g_realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> cmdtab[ncmds - 1] = *ci;
>> qsort(cmdtab, ncmds, sizeof(*cmdtab), compare);
>> }
>
> Inconsistent indentation.
>
> Either stick to the original indentation, or reindent the whole
> function.
I'll send second version with coding style fixes made in a separate commit.
--
Pavel
>
> [More of the same...]
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] cmd: Fix potential NULL pointer dereference
From: Pavel Borzenkov @ 2011-10-31 7:18 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-trivial, qemu-devel
In-Reply-To: <m3pqhdn09j.fsf@blackfin.pond.sub.org>
On Mon, Oct 31, 2011 at 10:27 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Pavel Borzenkov <pavel.borzenkov@gmail.com> writes:
>
>> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
>> ---
>> Note, that almost all code in the file violates CODING STYLE. The changed lines
>> are written wrt CODING STYLE (like commits 7d7d975c and c32d766a).
>>
>> ---
>>
>> cmd.c | 11 +++--------
>> 1 files changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/cmd.c b/cmd.c
>> index f77897e..abcf206 100644
>> --- a/cmd.c
>> +++ b/cmd.c
>> @@ -49,7 +49,7 @@ void
>> add_command(
>> const cmdinfo_t *ci)
>> {
>> - cmdtab = realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> + cmdtab = g_realloc((void *)cmdtab, ++ncmds * sizeof(*cmdtab));
>> cmdtab[ncmds - 1] = *ci;
>> qsort(cmdtab, ncmds, sizeof(*cmdtab), compare);
>> }
>
> Inconsistent indentation.
>
> Either stick to the original indentation, or reindent the whole
> function.
I'll send second version with coding style fixes made in a separate commit.
--
Pavel
>
> [More of the same...]
>
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: Arno Wagner @ 2011-10-31 7:18 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4EAE1643.9030501@binarysignals.net>
I am opposed to this. cryptsetup is not at fault here, it displays
a big, fat warning (unless disabled). If an installer decides
to suppress that warning and give something far less clear,
then the installer is broken and needs to be fixed. A good
installer would give a very clear warning and require
more than just a click or "RETURN" as confirmation.
cryptsetup already does both.
In addition, any kind of automatic header backup
breaks the LUKS security model and needs to come
with a very clear warning if automatized (as in an
installer). The problem is that old passphrases will
be stored and will survive deletion in the active LUKS
header. That is not good at all.
The right thing here is to complain to those that made the
broken (or not careful enough) installer and to ask them to
either keep the very clear warning and verification question
asked by cryptsetup, or to do something equally clear
themselves.
Side note: I am unsure whether Ubuntu has fixed this issue by now.
Does anybody know?
Side note 2: Added a generic warning about dangerous distro installers
to the FAQ.
Arno
On Mon, Oct 31, 2011 at 04:30:11AM +0100, ingo.schmitt@binarysignals.net wrote:
> Another idea: Cryptsetup should offer to backup the header
> on the same drive when changes to an existing header are requested.
>
> I assume that headers size isn't an issue.
>
> Thx,
> Ingo
>
> On 10/31/2011 01:30 AM, Aleksander Swirski wrote:
> >I'm pretty sure this warning is only displayed when someone decides to
> >create new crypto on some partition or fill encrypted device with random
> >data in the next step after setting the password. but just setting the
> >password on an existing device makes data unusable without warning. when
> >the partitioning is finished there is a list of partitions that will be
> >wiped out, and also, during my installation crypto-deviced and /home
> >inside LVM was not listed there, but already lost few clicks earlier.
> >
> >i understand that it wasn't taken into consideration that someone can
> >attach existing encrypted device, but only that a new one will be
> >created. this is inconsistent with how it goes with unencrypted
> >partitions, where you can reattach them without formatting and keep your
> >data. so i guess with encrypted partition this should also work that
> >way. or maybe i miss the point? i will try to make the whole scenario
> >clear, and then send my proposition, to debian-boot@lists.debian.org
> ><mailto:debian-boot@lists.debian.org>
> >
> >On 30 October 2011 23:25, Jonas Meurer <jonas@freesources.org
> ><mailto:jonas@freesources.org>> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi Aleksander,
> >
> > Am 30.10.2011 19:56, schrieb Aleksander Swirski:
> > > I will also try to push this info to the debian devs. I'm not sure
> > > how to do that properly (hint appreciated). I know, that the route
> > > of installation I took is not a common one, but a simple warning
> > > would suffice to avoid this kind of trouble. After all my encrypted
> > > LVM and specifically the /home partition within LVM wasn't listed
> > > among those, which are to be erased at any point during the
> > > installation. (I marked them with - K - keep the data)
> >
> > I guess that you selected to configure the device which contained the
> > LVM volume group as new encrypted device. Then you where asked for the
> > new passphrase twice, and a new LUKS header was written to the device,
> > overwriting the old LUKS header. That way you shredded all the
> > encrypted data on that device, regardless what it was.
> >
> > The partitions you marked as "keep the data" weren't overwritten, just
> > the LUKS header of underlying device was overwritten.
> >
> > I agree, that a warning in the Debian Installer is a good idea, but to
> > be honest, there's already a big fat warning:
> >
> > > _Description: Really erase the data on ${DEVICE}? The data on
> > > ${DEVICE} will be overwritten with random data. It can no longer be
> > > recovered after this step has completed. This is the last
> > > opportunity to abort the erase.
> >
> > (from
> > http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git;a=blob;f=debian/partman-crypto.templates)
> >
> > If you like to propose changes to the (warnings in the) process of
> > configuring encrypted volumes during installation of Debian, feel free
> > to discuss this on debian-boot@lists.debian.org
> > <mailto:debian-boot@lists.debian.org>. You might as well
> > take a look at the following page:
> > http://wiki.debian.org/DebianInstaller/PartmanCrypto
> >
> > Greetings,
> > jonas
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQIcBAEBAgAGBQJOrc7tAAoJEFJi5/9JEEn+bo4P/0vX3AxnpXzWO3NUvYW2wh6H
> > k7v8Dhx6Rw5HXttHuF8JSypkvcHuLfWyGLq0J4qlsw4GvK/cPtwdCuSe//uJvqSB
> > 4Z6qj55E/3/M+aEBMzT9oBeZ5DVGPp0+76VWFNijGzHYMoT4YYm0pZBsmfZ7U2RJ
> > +7xFyGP0d7oXJIqoW8aUyufgdYnRNdcZdJtY27XHgKW1m9ytllIuK0h7hl410/L0
> > vy2t4IqSlO5Uko1/bOf3FETNkBRTUl4T2jWMP3dEpNMRobB1ZH5I5menXWSwzgR9
> > c2QWRkwQ8iUsAdakofnl9O1jhtw3Z9MKxHQbnxh32oNuS5Aaf5xxfiI7jXf3yY/L
> > GUKyIOa5nGtNtwUt4l0RTJAKoyY2J2KtBJm+JL51tQ3q/iyZsfRLVmyczlkzKUhj
> > vMKgSzhV8/IyQ/snqftAMqmRXYgaOE3qDCe8MR+EChIFwX2Zr+eRWdRzVFDjQ0kP
> > Cyc6Yw3TrthD8GuWWxU93tE3YMVxgI76+lDk/LBLZjviMTEfkR5e+gmuoff+Xdta
> > aBYek7loOjkqb+gJ6qeqAKuDLAZnw/BmHfgpYQpatdSeiV6jpGPkGMbYTwDHLlXR
> > rE72FJe1emdcDWQ6TE8SP+6KW22HirBPD5q6DPqJ2Oxcxx+AotXeLvDpnhd9S5b2
> > fDNHacCUklPyCeH81nsH
> > =PLsS
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de <mailto:dm-crypt@saout.de>
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> >
> >
> >_______________________________________________
> >dm-crypt mailing list
> >dm-crypt@saout.de
> >http://www.saout.de/mailman/listinfo/dm-crypt
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply
* Re: How best replace /etc/init.d files with debugging versions right before jffs2 file is generated?
From: Anders Darander @ 2011-10-31 7:08 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <4EAC2342.1090401@telia.com>
* Ulf Samuelsson <ulf_samuelsson@telia.com> [111029 18:02]:
> 2011-10-29 17:00, Anders Darander skrev:
> > On 29 okt 2011, at 16:22, "Ulf Samuelsson"<ulf_samuelsson@telia.com> wrote:
> >> 2011-10-29 15:52, Ulf Samuelsson skrev:
> >>> Having some problems booting a rootfs generated by openembedded,
> >>> "hwclock can't find /dev/misc/rtc"
> >>> and I would like to emit some debug information by replacing some files
> >>> in the /etc/init.d directory before the rootfs is finalized.
> >>> If I try to "install" from another package, I will get a conflict.
> >>> I guess I could loop mount the file system and then copy.
> >>> Any other suggestions?
> >> Just discovered that loop mounting jffs2 isn't that easy.
> >> Need to find the blkmtd driver somewhere, recompile kernel?
> > Yes, loop mounting filesystems designed for raw flash requires quite some extra steps. It's generally doable, but...
> >> I can of course add some files to tmp/rootfs and regenerate the jffs2.
> >> Other ideas (allowing automation) appreciated.
> > Well, you could always use a bbappend to the recipe in question, and override/replace the files that way. Or, if it's just temporarily, just modify the scripts directly in the oe tree, or if the file is taken from a tarball, modify it in the build directory and force a re-install and packaging.
> > Cheers,
> > Anders
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> One would think that it was possible to do something with the rootfs,
> just before the mkfs.jffs2 was started.
> Key seems to be redefining "IMAGE_CMD_jffs2"
> This is set in conf/bitbake.conf:
> IMAGE_CMD_jffs2 = "mkfs.jffs2 -x lzo --root=${IMAGE_ROOTFS} --faketime
> --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
> It is possible to add something either in this file, or override in
> "local.conf"
> PREPROCESS_JFFS2 = "tar -jxvf <myfile>.tar.bz2 -C ${IMAGE_ROOTFS}"
Well, maybe IMAGE_PREPROCESS_COMMAND from image.bbclass could be used to
do this? (I've not tested this myself, though).
You'll also have IMAGE_POSTPROCESS_COMMAND and MACHINE_POSTPROCESS_COMMAND being executed in that order. Although in your case, IMAGE_PREPROCESS_COMMAND should be the one to look at.
Cheers,
Anders
> IMAGE_CMD_jffs2 = "${PREPROCESS_JFFS2} ; mkfs.jffs2 -x lzo
> --root=${IMAGE_ROOTFS} --faketime
> --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 ${EXTRA_IMAGECMD}"
> If it is added to bitbake.conf, then PREPROCESS_JFFS2 needs to be set to
> something harmless.
> PREPROCESS_JFFS2 ?= "touch ${IMAGE_ROOTFS}"
--
Anders Darander
ChargeStorm AB / eStorm AB
^ permalink raw reply
* [PATCH v2 4/4] mac80211: Populate QoS header on mesh frames sent to gates.
From: Thomas Pedersen @ 2011-10-31 7:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, johannes, linville
In-Reply-To: <1320045161-16144-1-git-send-email-thomas@cozybit.com>
From: Javier Cardona <javier@cozybit.com>
Also set correct skb queue mapping once next hop is known, and set
txinfo jiffies when forwarding.
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
net/mac80211/mesh_hwmp.c | 5 ++++-
net/mac80211/mesh_pathtbl.c | 5 +++++
net/mac80211/rx.c | 8 +++++---
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index b7d9dfd..d46109b 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -1028,8 +1028,11 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
PREQ_Q_F_START | PREQ_Q_F_REFRESH);
}
next_hop = rcu_dereference(mpath->next_hop);
- if (next_hop)
+ if (next_hop) {
memcpy(hdr->addr1, next_hop->sta.addr, ETH_ALEN);
+ skb_set_queue_mapping(skb,
+ ieee80211_select_queue(sdata, skb));
+ }
else
err = -ENOENT;
} else {
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 332b5ff1..9d2f55f 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -270,6 +270,11 @@ static void prepare_for_gate(struct sk_buff *skb, char *dst_addr,
memcpy(hdr->addr1, next_hop, ETH_ALEN);
rcu_read_unlock();
memcpy(hdr->addr3, dst_addr, ETH_ALEN);
+
+ /* once next hop is set we can set qos header */
+ skb_set_queue_mapping(skb,
+ ieee80211_select_queue(gate_mpath->sdata, skb));
+ ieee80211_set_qos_hdr(gate_mpath->sdata, skb);
}
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 0995685..00b3db7 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1964,12 +1964,10 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
info->control.vif = &rx->sdata->vif;
+ info->control.jiffies = jiffies;
if (is_multicast_ether_addr(fwd_hdr->addr1)) {
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_mcast);
- skb_set_queue_mapping(fwd_skb,
- ieee80211_select_queue(sdata, fwd_skb));
- ieee80211_set_qos_hdr(sdata, fwd_skb);
} else {
int err;
/*
@@ -1990,6 +1988,10 @@ ieee80211_rx_h_mesh_fwding(struct ieee80211_rx_data *rx)
}
IEEE80211_IFSTA_MESH_CTR_INC(&sdata->u.mesh,
fwded_frames);
+
+ /* next hop is now known, update the queue mapping */
+ skb_set_queue_mapping(fwd_skb,
+ ieee80211_select_queue(sdata, fwd_skb));
ieee80211_add_pending_skb(local, fwd_skb);
}
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 3/4] mac80211: check if frame is really part of this BA
From: Thomas Pedersen @ 2011-10-31 7:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320045161-16144-1-git-send-email-thomas@cozybit.com>
There was an an implicit assumption that any QoS data frame received
from a STA/TID with an active BA session was sent to this vif as part of
a BA. This is not true if IFF_PROMISC is enabled and the frame was
destined for a different peer, for example. Don't treat these frames as
part of a BA from the sending STA.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
net/mac80211/rx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b9d3236..0995685 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -777,6 +777,10 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
(ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
goto dont_reorder;
+ /* not actually part of this BA session */
+ if (compare_ether_addr(hdr->addr1, rx->sdata->vif.addr) != 0)
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-10-31 7:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, johannes, linville
In-Reply-To: <1320045161-16144-1-git-send-email-thomas@cozybit.com>
Previously QoS multicast frames had the Normal Acknowledgment QoS
control bits set. This would cause broadcast frames to be discarded by
peers with which we have a BA session, since their sequence number would
fall outside the allowed range. Set No Ack QoS control bits on multicast
QoS frames and filter these in de-aggregation code.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
---
v2: Use proper QoS Ack Policy control field mask (Christian)
include/linux/ieee80211.h | 1 +
net/mac80211/rx.c | 9 ++++++++-
net/mac80211/wme.c | 3 ++-
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 48363c3..bc61e69 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -128,6 +128,7 @@
#define IEEE80211_QOS_CTL_ACK_POLICY_NOACK 0x0020
#define IEEE80211_QOS_CTL_ACK_POLICY_NO_EXPL 0x0040
#define IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK 0x0060
+#define IEEE80211_QOS_CTL_ACK_POLICY_MASK 0x0060
/* A-MSDU 802.11n */
#define IEEE80211_QOS_CTL_A_MSDU_PRESENT 0x0080
/* Mesh Control 802.11s */
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index b867bd5..b9d3236 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -747,7 +747,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
struct sta_info *sta = rx->sta;
struct tid_ampdu_rx *tid_agg_rx;
u16 sc;
- int tid;
+ u8 tid, ack_policy;
if (!ieee80211_is_data_qos(hdr->frame_control))
goto dont_reorder;
@@ -760,6 +760,8 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (!sta)
goto dont_reorder;
+ ack_policy = *ieee80211_get_qos_ctl(hdr) &
+ IEEE80211_QOS_CTL_ACK_POLICY_MASK;
tid = *ieee80211_get_qos_ctl(hdr) & IEEE80211_QOS_CTL_TID_MASK;
tid_agg_rx = rcu_dereference(sta->ampdu_mlme.tid_rx[tid]);
@@ -770,6 +772,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
goto dont_reorder;
+ /* not part of a BA session */
+ if (!((ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK) ||
+ (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
+ goto dont_reorder;
+
/* new, potentially un-ordered, ampdu frame - process it */
/* reset session timer */
diff --git a/net/mac80211/wme.c b/net/mac80211/wme.c
index fd52e69..a440a4a 100644
--- a/net/mac80211/wme.c
+++ b/net/mac80211/wme.c
@@ -147,7 +147,8 @@ void ieee80211_set_qos_hdr(struct ieee80211_sub_if_data *sdata,
tid = skb->priority & IEEE80211_QOS_CTL_TAG1D_MASK;
- if (unlikely(sdata->local->wifi_wme_noack_test))
+ if (unlikely(sdata->local->wifi_wme_noack_test) ||
+ is_multicast_ether_addr(hdr->addr1))
ack_policy |= IEEE80211_QOS_CTL_ACK_POLICY_NOACK;
/* qos header is 2 bytes */
*p++ = ack_policy | tid;
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 1/4] mac80211: Avoid filling up mesh preq queue with redundant requests
From: Thomas Pedersen @ 2011-10-31 7:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Javier Cardona, johannes, linville
From: Javier Cardona <javier@cozybit.com>
Don't accept redundant PREQs for a given destination. This fixes a
problem under high load:
kernel: [20386.250913] mesh_queue_preq: 235 callbacks suppressed
kernel: [20386.253335] Mesh HWMP (mesh0): PREQ node queue full
kernel: [20386.253352] Mesh HWMP (mesh0): PREQ node queue full
(...)
The 802.11s protocol has a provision to limit the rate of path requests
(PREQs) are transmitted (dot11MeshHWMPpreqMinInterval) but there was no
limit on the rate at which PREQs were being queued up. There is a valid
reason for queuing PREQs: this way we can even out PREQ bursts. But
queueing multiple PREQs for the same destination is useless.
Reported-by: Pedro Larbig <pedro.larbig@carhs.de>
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
net/mac80211/mesh.h | 3 +++
net/mac80211/mesh_hwmp.c | 15 +++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/mesh.h b/net/mac80211/mesh.h
index 8c00e2d..b3745e8 100644
--- a/net/mac80211/mesh.h
+++ b/net/mac80211/mesh.h
@@ -31,6 +31,8 @@
* @MESH_PATH_FIXED: the mesh path has been manually set and should not be
* modified
* @MESH_PATH_RESOLVED: the mesh path can has been resolved
+ * @MESH_PATH_REQ_QUEUED: there is an unsent path request for this destination
+ * already queued up, waiting for the discovery process to start.
*
* MESH_PATH_RESOLVED is used by the mesh path timer to
* decide when to stop or cancel the mesh path discovery.
@@ -41,6 +43,7 @@ enum mesh_path_flags {
MESH_PATH_SN_VALID = BIT(2),
MESH_PATH_FIXED = BIT(3),
MESH_PATH_RESOLVED = BIT(4),
+ MESH_PATH_REQ_QUEUED = BIT(5),
};
/**
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 9a1f8bb..b7d9dfd 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -867,9 +867,19 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
return;
}
+ spin_lock_bh(&mpath->state_lock);
+ if (mpath->flags & MESH_PATH_REQ_QUEUED) {
+ spin_unlock_bh(&mpath->state_lock);
+ spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
+ return;
+ }
+
memcpy(preq_node->dst, mpath->dst, ETH_ALEN);
preq_node->flags = flags;
+ mpath->flags |= MESH_PATH_REQ_QUEUED;
+ spin_unlock_bh(&mpath->state_lock);
+
list_add_tail(&preq_node->list, &ifmsh->preq_queue.list);
++ifmsh->preq_queue_len;
spin_unlock_bh(&ifmsh->mesh_preq_queue_lock);
@@ -921,6 +931,7 @@ void mesh_path_start_discovery(struct ieee80211_sub_if_data *sdata)
goto enddiscovery;
spin_lock_bh(&mpath->state_lock);
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
if (preq_node->flags & PREQ_Q_F_START) {
if (mpath->flags & MESH_PATH_RESOLVING) {
spin_unlock_bh(&mpath->state_lock);
@@ -1028,8 +1039,7 @@ int mesh_nexthop_lookup(struct sk_buff *skb,
mesh_queue_preq(mpath, PREQ_Q_F_START);
}
- if (skb_queue_len(&mpath->frame_queue) >=
- MESH_FRAME_QUEUE_LEN)
+ if (skb_queue_len(&mpath->frame_queue) >= MESH_FRAME_QUEUE_LEN)
skb_to_free = skb_dequeue(&mpath->frame_queue);
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
@@ -1062,6 +1072,7 @@ void mesh_path_timer(unsigned long data)
++mpath->discovery_retries;
mpath->discovery_timeout *= 2;
spin_unlock_bh(&mpath->state_lock);
+ mpath->flags &= ~MESH_PATH_REQ_QUEUED;
mesh_queue_preq(mpath, 0);
} else {
mpath->flags = 0;
--
1.7.5.4
^ permalink raw reply related
* Re: cq error timeout issue
From: Vlad Weinbaum @ 2011-10-31 7:08 UTC (permalink / raw)
To: Hefty, Sean; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1828884A29C6694DAF28B7E6B8A8237316E8B236-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
Thank you Sean,
I have an access to OpenSM configuration on the switch in my testing
environment. I tried to reduce the timout there (subnet_timeout,
packet_life_time), but unsuccessfully.
Btw, I found detail that I cannot explain. I query the QP after
connect and get timeout value 16, that must be 4 us * 2^ 16 = 256 ms,
but I get about 800 ms.
Thanks,
Vlad
On Mon, Oct 31, 2011 at 8:51 AM, Hefty, Sean <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> I try to use ibv_poll_cq to identify connectivity problems. The
>> scenario is following, based on modified rping example:
>>
>> 1) preliminary steps done and rdma connection established between
>> Client and Server, retry_count in rdma_conn_param is set 1;
>> 2) Server lost its link (corresponding switch port disabled), Client
>> is still connected to the switch;
>> 3) Client calls ibv_post_send
>> 4) Client polls cq with ibv_poll_cq and gets expected
>> IBV_WC_RETRY_EXC_ERR after about 1 second.
>>
>> Can this timeout be decreased? If it is impossible, can you suggest
>> something else?
>
> I don't believe easily. The timeout is based on the path record returned by the SM, which is really what an app should use. If you can adjust the timeout at the SM, that would be best.
>
> If you can use a newer kernel, another alternative is to use rdma_set_option to provide your own path record as input in place of calling rdma_resolve_route.
>
> Btw, with a small timeout and few retries, if you're not using QoS, you may want to enable that to prevent false timeouts.
>
> - Sean
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] powerpc/fsl-pci: Only scan PCI bus if configured as a host
From: Jia Hongtao @ 2011-10-31 5:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: B11780, b38951
In-Reply-To: <1320040492-6407-1-git-send-email-B38951@freescale.com>
If we're an agent/end-point or fsl_add_bridge doesn't succeed due to some
resource failure we should not scan the PCI bus. We change fsl_add_bridge()
to return -ENODEV in the case we're an agent/end-point.
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/sysdev/fsl_pci.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4d4536f..11c1e23 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -370,7 +370,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
iounmap(hose->cfg_data);
iounmap(hose->cfg_addr);
pcibios_free_controller(hose);
- return 0;
+ return -ENODEV;
}
setup_pci_cmd(hose);
@@ -418,6 +418,8 @@ void fsl_pci_setup(int primary_phb_addr)
{
struct device_node *np;
struct pci_controller *hose;
+ int ret;
+ int has_host = 0;
dma_addr_t min_dma_addr = 0xffffffff;
for_each_node_by_type(np, "pci") {
@@ -425,14 +427,17 @@ void fsl_pci_setup(int primary_phb_addr)
struct resource rsrc;
of_address_to_resource(np, 0, &rsrc);
if ((rsrc.start & 0xfffff) == primary_phb_addr)
- fsl_add_bridge(np, 1);
+ ret = fsl_add_bridge(np, 1);
else
- fsl_add_bridge(np, 0);
-
- hose = pci_find_hose_for_OF_device(np);
- min_dma_addr = min(min_dma_addr,
- hose->dma_window_base_cur
- + hose->dma_window_size);
+ ret = fsl_add_bridge(np, 0);
+
+ if (ret == 0) {
+ has_host = 1;
+ hose = pci_find_hose_for_OF_device(np);
+ min_dma_addr = min(min_dma_addr,
+ hose->dma_window_base_cur
+ + hose->dma_window_size);
+ }
}
}
@@ -442,7 +447,7 @@ void fsl_pci_setup(int primary_phb_addr)
* if we couldn't map all of DRAM via the dma windows we need SWIOTLB
* to handle buffers located outside of dma capable memory region
*/
- if (memblock_end_of_DRAM() > min_dma_addr) {
+ if (has_host && memblock_end_of_DRAM() > min_dma_addr) {
ppc_swiotlb_enable = 1;
set_pci_dma_ops(&swiotlb_dma_ops);
ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
--
1.7.5.1
^ permalink raw reply related
* [PATCH 1/2] Unify pci/pcie initialization code
From: Jia Hongtao @ 2011-10-31 5:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: B11780, b38951
In-Reply-To: <1320040492-6407-1-git-send-email-B38951@freescale.com>
In previous version pci/pcie initialization is in platform code which
Initialize PCI bridge base on EP/RC or host/agent settings.
We unified pci/pcie initialization as common APIs named fsl_pci_setup
which can be called by platform code.
Signed-off-by: Jia Hongtao <B38951@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 30 ++-----------------
arch/powerpc/sysdev/fsl_pci.c | 48 ++++++++++++++++++++++++++++++
arch/powerpc/sysdev/fsl_pci.h | 5 +++
3 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index 10e7db0..7188c0b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -157,33 +157,12 @@ extern void __init mpc85xx_smp_init(void);
#endif
static void __init mpc85xx_ds_setup_arch(void)
{
-#ifdef CONFIG_PCI
- struct device_node *np;
- struct pci_controller *hose;
-#endif
- dma_addr_t max = 0xffffffff;
-
if (ppc_md.progress)
ppc_md.progress("mpc85xx_ds_setup_arch()", 0);
-#ifdef CONFIG_PCI
- for_each_node_by_type(np, "pci") {
- if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
- of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
- of_device_is_compatible(np, "fsl,p2020-pcie")) {
- struct resource rsrc;
- of_address_to_resource(np, 0, &rsrc);
- if ((rsrc.start & 0xfffff) == primary_phb_addr)
- fsl_add_bridge(np, 1);
- else
- fsl_add_bridge(np, 0);
-
- hose = pci_find_hose_for_OF_device(np);
- max = min(max, hose->dma_window_base_cur +
- hose->dma_window_size);
- }
- }
+ fsl_pci_setup(primary_phb_addr);
+#ifdef CONFIG_PCI
ppc_md.pci_exclude_device = mpc85xx_exclude_device;
#endif
@@ -192,11 +171,8 @@ static void __init mpc85xx_ds_setup_arch(void)
#endif
#ifdef CONFIG_SWIOTLB
- if (memblock_end_of_DRAM() > max) {
+ if (memblock_end_of_DRAM() > 0xffffffff)
ppc_swiotlb_enable = 1;
- set_pci_dma_ops(&swiotlb_dma_ops);
- ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
- }
#endif
printk("MPC85xx DS board from Freescale Semiconductor\n");
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 80b8b7a..4d4536f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -402,6 +402,54 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
+static struct of_device_id pci_ids[] = {
+ { .compatible = "fsl,mpc8540-pci", },
+ { .compatible = "fsl,mpc8548-pcie", },
+ {},
+};
+
+/**
+ * fsl_pci_setup - Initialization for PCI
+ * @primary_phb_addr: primary bus address
+ *
+ * Add bridge if pci controller is a host
+ */
+void fsl_pci_setup(int primary_phb_addr)
+{
+ struct device_node *np;
+ struct pci_controller *hose;
+ dma_addr_t min_dma_addr = 0xffffffff;
+
+ for_each_node_by_type(np, "pci") {
+ if (of_match_node(pci_ids, np)) {
+ struct resource rsrc;
+ of_address_to_resource(np, 0, &rsrc);
+ if ((rsrc.start & 0xfffff) == primary_phb_addr)
+ fsl_add_bridge(np, 1);
+ else
+ fsl_add_bridge(np, 0);
+
+ hose = pci_find_hose_for_OF_device(np);
+ min_dma_addr = min(min_dma_addr,
+ hose->dma_window_base_cur
+ + hose->dma_window_size);
+
+ }
+ }
+
+#ifdef CONFIG_SWIOTLB
+ /*
+ * if we couldn't map all of DRAM via the dma windows we need SWIOTLB
+ * to handle buffers located outside of dma capable memory region
+ */
+ if (memblock_end_of_DRAM() > min_dma_addr) {
+ ppc_swiotlb_enable = 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup = pci_dma_dev_setup_swiotlb;
+ }
+#endif
+}
+
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, quirk_fsl_pcie_header);
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a39ed5c..775ea21 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -89,6 +89,11 @@ struct ccsr_pci {
};
extern int fsl_add_bridge(struct device_node *dev, int is_primary);
+#ifndef CONFIG_PCI
+#define fsl_pci_setup(p)
+#else
+extern void fsl_pci_setup(int primary_phb_addr);
+#endif
extern void fsl_pcibios_fixup_bus(struct pci_bus *bus);
extern int mpc83xx_add_bridge(struct device_node *dev);
u64 fsl_pci_immrbar_base(struct pci_controller *hose);
--
1.7.5.1
^ permalink raw reply related
* [PATCH SDK1.1 v2 0/2] PCIEP Patches Description
From: Jia Hongtao @ 2011-10-31 5:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: B11780, b38951
These patches against kernel 3.0 for SDK 1.1.
The patches include contents from topic branch 15-pciep.
Also we add PCI related patch from topic branch 05-MPC8572DS here.
We update the pci/pcie initialization code.
^ permalink raw reply
* Re: [PATCHv4] virtio-blk: use ida to allocate disk index
From: Jens Axboe @ 2011-10-31 7:05 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Rusty Russell, Tejun Heo, virtualization, kvm, linux-kernel,
Greg Kroah-Hartman
In-Reply-To: <20111030192959.GA31143@redhat.com>
On 2011-10-30 20:29, Michael S. Tsirkin wrote:
> Based on a patch by Mark Wu <dwu@redhat.com>
>
> Current index allocation in virtio-blk is based on a monotonically
> increasing variable "index". This means we'll run out of numbers
> after a while. It also could cause confusion about the disk
> name in the case of hot-plugging disks.
> Change virtio-blk to use ida to allocate index, instead.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Changes from Mark's versions:
> use the new ida_simple_get
> error handling cleanup
> fix user after free
>
> Works fine for me.
>
> Jens, could you merge this for 3.2?
> That is, unless Rusty complains shortly ...
Yep, tentatively added.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCHv4] virtio-blk: use ida to allocate disk index
From: Jens Axboe @ 2011-10-31 7:05 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, Greg Kroah-Hartman, linux-kernel, virtualization, Tejun Heo
In-Reply-To: <20111030192959.GA31143@redhat.com>
On 2011-10-30 20:29, Michael S. Tsirkin wrote:
> Based on a patch by Mark Wu <dwu@redhat.com>
>
> Current index allocation in virtio-blk is based on a monotonically
> increasing variable "index". This means we'll run out of numbers
> after a while. It also could cause confusion about the disk
> name in the case of hot-plugging disks.
> Change virtio-blk to use ida to allocate index, instead.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Changes from Mark's versions:
> use the new ida_simple_get
> error handling cleanup
> fix user after free
>
> Works fine for me.
>
> Jens, could you merge this for 3.2?
> That is, unless Rusty complains shortly ...
Yep, tentatively added.
--
Jens Axboe
^ permalink raw reply
* [patch] target: blk_make_request() returns an ERR_PTR()
From: Dan Carpenter @ 2011-10-31 7:03 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-scsi, target-devel, kernel-janitors
The check is wrong here because blk_make_request() returns an
ERR_PTR() and it doesn't return NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index b452efe..ed32e1e 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1092,7 +1092,7 @@ static int pscsi_do_task(struct se_task *task)
req = blk_make_request(pdv->pdv_sd->request_queue, hbio,
GFP_KERNEL);
- if (!req) {
+ if (IS_ERR(req)) {
pr_err("pSCSI: blk_make_request() failed\n");
goto fail;
}
^ permalink raw reply related
* [patch] target: blk_make_request() returns an ERR_PTR()
From: Dan Carpenter @ 2011-10-31 7:03 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-scsi, target-devel, kernel-janitors
The check is wrong here because blk_make_request() returns an
ERR_PTR() and it doesn't return NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/target/target_core_pscsi.c b/drivers/target/target_core_pscsi.c
index b452efe..ed32e1e 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -1092,7 +1092,7 @@ static int pscsi_do_task(struct se_task *task)
req = blk_make_request(pdv->pdv_sd->request_queue, hbio,
GFP_KERNEL);
- if (!req) {
+ if (IS_ERR(req)) {
pr_err("pSCSI: blk_make_request() failed\n");
goto fail;
}
^ permalink raw reply related
* [U-Boot] Payment Update
From: Western Union Company @ 2011-10-31 7:03 UTC (permalink / raw)
To: u-boot
Sir/Madam,
On behalf of the United Nations Compensation Commission (UNCC) in affiliation
with Western Union Campaign for Global Economic Crisis eradication, we wish
to notify you that your E-mail Address has won (Two Hundred and Fifty
Thousand United State Dollars only) $250,000.00.
For security reasons and to avoid misappropriation of funds, proper
verifications must be carried out before the fund is transferred. We require
the details below for verification so that the transfer can be carried out.
(1)Your Name:----------------
(2)Your Country:------------
(3)Tel:--------------------
(4)Age:---------------------
(6)Sex:--------------
(7) Occupation---------
Send the above details to us via the email addresses stated below:
Western Union District Manager (Mr. Frank Amos)
Website: www.westernunion.com
E-mail: western-money70 at hotmail.com
Tel: +2347031908911
As soon as these details are received and verified, the fund will be
transferred to you.
Thanks and God Bless,
Mrs. Maureen Mbe.
Organization Dept
Copyright ? 2001-2011 The Western Union Company. All Rights Reserved
^ permalink raw reply
* Re: [PATCH 2/4] mac80211: QoS multicast frames have No Ack policy
From: Thomas Pedersen @ 2011-10-31 7:03 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, devel, johannes, linville
In-Reply-To: <201110291140.12311.chunkeey@googlemail.com>
On Sat, Oct 29, 2011 at 2:40 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Saturday 29 October 2011 07:05:30 Thomas Pedersen wrote:
>> Previously QoS multicast frames had the Normal Acknowledgment QoS
>> control bits set. This would cause broadcast frames to be discarded by
>> peers with which we have a BA session, since their sequence number would
>> fall outside the allowed range. Set No Ack QoS control bits on multicast
>> QoS frames and filter these in de-aggregation code.
>>
>> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
>> ---
>> net/mac80211/rx.c | 8 +++++++-
>> net/mac80211/wme.c | 3 ++-
>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
>> index b867bd5..ee9e71b 100644
>> --- a/net/mac80211/rx.c
>> +++ b/net/mac80211/rx.c
>> @@ -747,7 +747,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
>> struct sta_info *sta = rx->sta;
>> struct tid_ampdu_rx *tid_agg_rx;
>> u16 sc;
>> - int tid;
>> + u8 tid, ack_policy;
>>
>> if (!ieee80211_is_data_qos(hdr->frame_control))
>> goto dont_reorder;
>> @@ -760,6 +760,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
>> if (!sta)
>> goto dont_reorder;
>>
>> + ack_policy = *ieee80211_get_qos_ctl(hdr) & ~IEEE80211_QOS_CTL_TID_MASK;
> uh, while it might be a bit far fetched, but ack_policy might now clash with
> frames that have set:
>
> IEEE80211_QOS_CTL_EOSP (0x10)
> IEEE80211_QOS_CTL_A_MSDU_PRESENT (0x80)
> IEEE80211_QOS_CTL_MESH_CONTROL_PRESENT (0x100)
>
> so I think we would be better of with something like:
>
> (in include/linux/ieee80211.h)
> #define IEEE80211_QOS_CTL_ACK_POLICY_MASK 0x0060
>
> ack_policy = *ieee80211_get_qos_ctl(hdr) & ~IEEE80211_QOS_CTL_ACK_POLICY_MASK;
Good idea. Will fix and resubmit.
>
>> @@ -770,6 +771,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
>> if (unlikely(hdr->frame_control & cpu_to_le16(IEEE80211_STYPE_NULLFUNC)))
>> goto dont_reorder;
>>
>> + /* not part of a BA session */
>> + if (!((ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK) ||
>> + (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)))
>> + goto dont_reorder;
>> +
Thanks,
Thomas
^ permalink raw reply
* [PATCH] staging:rts_pstor:Complete scanning_done variable
From: wei_wang @ 2011-10-31 7:02 UTC (permalink / raw)
To: gregkh, devel, linux-kernel; +Cc: wwang
From: wwang <wei_wang@realsil.com.cn>
Complete scanning_done variable if rtsx-scan thread created failed.
Signed-off-by: wwang <wei_wang@realsil.com.cn>
---
drivers/staging/rts_pstor/rtsx.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/rts_pstor/rtsx.c b/drivers/staging/rts_pstor/rtsx.c
index 480b0ed..115635f 100644
--- a/drivers/staging/rts_pstor/rtsx.c
+++ b/drivers/staging/rts_pstor/rtsx.c
@@ -1021,6 +1021,7 @@ static int __devinit rtsx_probe(struct pci_dev *pci,
th = kthread_create(rtsx_scan_thread, dev, "rtsx-scan");
if (IS_ERR(th)) {
printk(KERN_ERR "Unable to start the device-scanning thread\n");
+ complete(&dev->scanning_done);
quiesce_and_remove_host(dev);
err = PTR_ERR(th);
goto errout;
--
1.7.5.4
^ permalink raw reply related
* [U-Boot] [PATCH v5 01/11] usb, davinci: add enable_vbus() weak function
From: Igor Grinberg @ 2011-10-31 7:02 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320036790-24283-2-git-send-email-hs@denx.de>
Hi Heiko,
On 10/31/11 06:53, Heiko Schocher wrote:
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: Remy Bohmer <linux@bohmer.net>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
>
> ---
> changes for v4:
> - patch is new since v4, as Igor Grinberg suggested.
>
> drivers/usb/musb/davinci.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
> index f56f2df..27dc4bc 100644
> --- a/drivers/usb/musb/davinci.c
> +++ b/drivers/usb/musb/davinci.c
> @@ -78,6 +78,18 @@ static void phy_off(void)
> writel(USBPHY_OSCPDWN | USBPHY_PHYPDWN, USBPHY_CTL_PADDR);
> }
>
> +#ifndef DAVINCI_DM365EVM
> +__attribute__((weak))
> +void enable_vbus(void)
> +{
> + /*
> + * nothing to do, vbus is handled through the cpu.
> + * Define this function in board code, if it is
> + * different on your board.
> + */
> +}
> +#endif
I'd suggest, instead of closing the weak declaration inside
ifdef/ifndef, make it available to all boards with alias.
> +
> /*
> * This function performs Davinci platform specific initialization for usb0.
> */
--
Regards,
Igor.
^ permalink raw reply
* RE: [PATCH 2/2] powerpc/fsl-pci: Only scan PCI bus if configured as a host
From: Jia Hongtao-B38951 @ 2011-10-31 6:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: Gala Kumar-B11780, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <A40D3EA1-8172-4267-A509-2409CF32310D@kernel.crashing.org>
-----Original Message-----
From: linuxppc-dev-bounces+b38951=3Dfreescale.com@lists.ozlabs.org [mailto:=
linuxppc-dev-bounces+b38951=3Dfreescale.com@lists.ozlabs.org] On Behalf Of =
Kumar Gala
Sent: Friday, October 28, 2011 9:10 PM
To: Jia Hongtao-B38951
Cc: Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] powerpc/fsl-pci: Only scan PCI bus if configured a=
s a host
On Oct 28, 2011, at 3:03 AM, Jia Hongtao wrote:
> If we're an agent/end-point or fsl_add_bridge doesn't succeed due to=20
> some resource failure we should not scan the PCI bus. We change=20
> fsl_add_bridge() to return -ENODEV in the case we're an agent/end-point.
>=20
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 17 ++++++++++-------
> 1 files changed, 10 insertions(+), 7 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_pci.c=20
> b/arch/powerpc/sysdev/fsl_pci.c index 4d4536f..caa7801 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -370,7 +370,7 @@ int __init fsl_add_bridge(struct device_node *dev, in=
t is_primary)
> iounmap(hose->cfg_data);
> iounmap(hose->cfg_addr);
> pcibios_free_controller(hose);
> - return 0;
> + return -ENODEV;
> }
>=20
> setup_pci_cmd(hose);
> @@ -418,6 +418,7 @@ void fsl_pci_setup(int primary_phb_addr) {
> struct device_node *np;
> struct pci_controller *hose;
> + int ret;
> dma_addr_t min_dma_addr =3D 0xffffffff;
>=20
> for_each_node_by_type(np, "pci") {
> @@ -425,14 +426,16 @@ void fsl_pci_setup(int primary_phb_addr)
> struct resource rsrc;
> of_address_to_resource(np, 0, &rsrc);
> if ((rsrc.start & 0xfffff) =3D=3D primary_phb_addr)
> - fsl_add_bridge(np, 1);
> + ret =3D fsl_add_bridge(np, 1);
> else
> - fsl_add_bridge(np, 0);
> + ret =3D fsl_add_bridge(np, 0);
>=20
> - hose =3D pci_find_hose_for_OF_device(np);
> - min_dma_addr =3D min(min_dma_addr,
> - hose->dma_window_base_cur
> - + hose->dma_window_size);
> + if (ret =3D=3D 0) {
> + hose =3D pci_find_hose_for_OF_device(np);
> + min_dma_addr =3D min(min_dma_addr,
> + hose->dma_window_base_cur
> + + hose->dma_window_size);
> + }
>=20
> }
> }
In the failure case (i.e. when ret !=3D 0), what about the following code:
+#ifdef CONFIG_SWIOTLB
+ /*
+ * if we couldn't map all of DRAM via the dma windows we need SWIOTLB
+ * to handle buffers located outside of dma capable memory region
+ */
+ if (memblock_end_of_DRAM() > min_dma_addr) {
+ ppc_swiotlb_enable =3D 1;
+ set_pci_dma_ops(&swiotlb_dma_ops);
+ ppc_md.pci_dma_dev_setup =3D pci_dma_dev_setup_swiotlb;
+ }
+#endif
This should get updated to be:
if ((ret =3D=3D 0) && (memblock_end_of_DRAM() > min_dma_arr)) {
[Jia Hongtao-B38951] A board could have more than one pci controllers, so t=
his update is not right for it only checked the last one. I will submit ano=
ther patch to solve this issue.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [smatch stuff] re: [SCSI] lpfc 8.3.27: Changed worst case mailbox timeout
From: Dan Carpenter @ 2011-10-31 6:58 UTC (permalink / raw)
To: James Smart; +Cc: linux-scsi
Smatch complains about a183a15f "[SCSI] lpfc 8.3.27: Changed worst
case mailbox timeout".
drivers/scsi/lpfc/lpfc_sli.c +2220 lpfc_sli_handle_mb_event(66)
error: we previously assumed 'pmb->vport' could be null (see line 2177)
+ pmb->vport ? pmb->vport->vpi : 0,
^^^^^^^^^^
Checked.
+ pmbox->mbxCommand,
+ lpfc_sli_config_mbox_subsys_get(phba,
+ pmb),
+ lpfc_sli_config_mbox_opcode_get(phba,
+ pmb),
+ pmbox->mbxStatus,
+ pmbox->un.varWords[0],
+ pmb->vport->port_state);
^^^^^^^^^^^^
Dereferenced without checking.
regards,
dan carpenter
^ permalink raw reply
* RE: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Ganir, Chen @ 2011-10-31 6:57 UTC (permalink / raw)
To: Ajay Pillai, Anderson Lizardo
Cc: Luiz Augusto von Dentz, Mat Martineau, Claudio Takahasi,
linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
ingas@codeaurora.org
In-Reply-To: <8DCFA6B89B9E70418E47A2348D55495A4790BF0B@banasiexm01.ASIA.ROOT.PRI>
Ajay,
> The problem I see with this approach is that the DBUS client does not
> get to know that the value that it got while doing a getProperty() is
> the value remembered by BlueZ and not the one directly read from the
> server at that time and hence potentially a stale value. I think it is
> important because some DBUS clients may just want to ignore any
> potentially stale value and not process it until it gets a "Property
> changed" signal. Now in that case, the DBUS client may have to handle
> the situation where it may never get a "Property Changed" signal
> (because the connection did not go through), but there would be app
> specific ways of handling it and it may or may not involve just letting
> the user know the hard truth.
> Hence I think it is crucial to let the DBUS App know what kind of value
> it is getting inorder to empower it to make decisions.
>
> One alternative would be to let the "value" property always read from
> cache and a "readValue" API always read from a connection, so that the
> DBUS application can decide which DBUS operation to use based on its
> usecase. The "readValue" API must return the value if the connection is
> active, or else return a status code indicating that connection
> procedure has been triggered and later (once connection and read
> procedures are over) emit a signal (maybe "propertyChanged") to signal
> the read value.
>
Can you please try and think of a situation where a client may need the old value, knowing that it may not be the correct one? Why would anyone needing a value from the server need a cached value which has no meaning at the time of the "get_properties", knowing also that it should wait for the "property_changed" event ? This design is totally wrong, and may cause problems. I really see no reason for keeping the cached value. The correct behavior can be one of the two :
1. ReadValue method, blocking if a connection is up, returning the value, or returning some kind of error to let the client know that a value can not be read at the moment if the link is down or pending.
2. ReadValue method invokes a procedure for reading the value. A ReadValueComplete signal/watcher method is then raised when the value was actually read from the server (connection is successful).
These should replace the "Value" property, removing it from the list.
I would prefer method 1, since it's more straight forward, and allows the client to know exactly what is going on.
BR
Chen Ganir.
^ permalink raw reply
* RE: cq error timeout issue
From: Hefty, Sean @ 2011-10-31 6:51 UTC (permalink / raw)
To: Vlad Weinbaum, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAFAcbYPXqcOc79fcWHK7iHkfEX0ecmg4CBSUgUk=C=xiScSRRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> I try to use ibv_poll_cq to identify connectivity problems. The
> scenario is following, based on modified rping example:
>
> 1) preliminary steps done and rdma connection established between
> Client and Server, retry_count in rdma_conn_param is set 1;
> 2) Server lost its link (corresponding switch port disabled), Client
> is still connected to the switch;
> 3) Client calls ibv_post_send
> 4) Client polls cq with ibv_poll_cq and gets expected
> IBV_WC_RETRY_EXC_ERR after about 1 second.
>
> Can this timeout be decreased? If it is impossible, can you suggest
> something else?
I don't believe easily. The timeout is based on the path record returned by the SM, which is really what an app should use. If you can adjust the timeout at the SM, that would be best.
If you can use a newer kernel, another alternative is to use rdma_set_option to provide your own path record as input in place of calling rdma_resolve_route.
Btw, with a small timeout and few retries, if you're not using QoS, you may want to enable that to prevent false timeouts.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
From: Pandita, Vikram @ 2011-10-31 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315521779.2313.29.camel@deneb.redhat.com>
On Thu, Sep 8, 2011 at 3:41 PM, Mark Salter <msalter@redhat.com> wrote:
> On Wed, 2011-08-31 at 20:35 +0100, Will Deacon wrote:
>> On Wed, Aug 31, 2011 at 07:19:33PM +0100, Rob Herring wrote:
>> > On 08/31/2011 12:51 PM, Will Deacon wrote:
>> > > Another thing that Marc and I tried on OMAP4 was not bringing up the secondary
>> > > CPU during boot (by commenting out most of smp_init). In this case, I/O
>> > > performance was good until we tried to online the secondary CPU. The online
>> > > failed but after that the I/O performance was certainly degraded.
>> > >
>> >
>> > Was the SCU enabled at that point? One diff between nosmp boot and
>> > offlining the 2nd core would be that the SCU remains enabled in the
>> > latter case. I think the SCU does not get enabled for nosmp.
>>
>> Our rudimentary test (printing out the SCU control register during boot)
>> showed that it *was* enabled for nosmp. I think this is due to the secure
>> world having to do that on OMAP so it's probably not true for other
>> platforms.
>
> I've done a little test and found that turning on the MMU of the second
> core causes the problem to show up. I patched head.S so I stopped the
> second core in an infinite loop just before turning on the MMU. The
> system continues booting on core#0 and I see ~20MB/s with hdparm -t to
> an attached usb disk. Same setup but with second core being stopped with
> infinite loop just after MMU is enabled shows ~5MB/s. So whatever is
> going wrong, its not because of anything the second core is doing beyond
> turning on its MMU and doing an empty loop.
what was the final take on the optimization?
Excuse if i could not follow the whole thread - could someone
summarize for the benefit of many.
Thanks
>
> --Mark
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ 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.