* Re: linux-next: net tree build failure
From: David Miller @ 2008-11-26 8:45 UTC (permalink / raw)
To: sfr; +Cc: linux-next, herbert, kaber, adobriyan
In-Reply-To: <20081126181543.0d7fba17.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 26 Nov 2008 18:15:43 +1100
> Today's linux-next build (x86_64 allmodconfig) failed like this:
Stephen, thanks for all of these merge and build fixups.
I think I'll do a preemptive merge later today of net-2.6 into
net-next-2.6 to try and resolve most of this.
But no promises as it's my birthday :)
^ permalink raw reply
* linux-next: manual merge of the wireless tree
From: Stephen Rothwell @ 2008-11-26 8:40 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, Sujith, Luis R. Rodriguez, Bennyam Malavazi,
David S. Miller
Hi John,
Today's linux-next merge of the wireless tree got a conflict in
drivers/net/wireless/ath9k/recv.c between commits
b4b6cda2298b0c9a0af902312184b775b8867c65 ("ath9k: correct expected max RX
buffer size") and ca0c7e5101fd4f37fed8e851709f08580b92fbb3 ("ath9k: Fix
SW-IOMMU bounce buffer starvation") from the wireless-current tree and
commits fd568653b38a91154b193338c312927385e77da1 ("ath9k: Revamp RX
handling") and from the wireless tree.
I fixed it up (see below - I hope it is correct) and assume that it will
be fixed soon.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc drivers/net/wireless/ath9k/recv.c
index d36b5e2,743ad22..0000000
--- a/drivers/net/wireless/ath9k/recv.c
+++ b/drivers/net/wireless/ath9k/recv.c
@@@ -49,12 -41,9 +41,11 @@@ static void ath_rx_buf_link(struct ath_
ASSERT(skb != NULL);
ds->ds_vdata = skb->data;
- /* setup rx descriptors */
+ /* setup rx descriptors. The sc_rxbufsize here tells the harware
+ * how much data it can DMA to us and that we are prepared
+ * to process */
- ath9k_hw_setuprxdesc(ah,
- ds,
+ ath9k_hw_setuprxdesc(ah, ds,
- skb_tailroom(skb), /* buffer size */
+ sc->sc_rxbufsize,
0);
if (sc->sc_rxlink == NULL)
@@@ -229,10 -298,9 +307,9 @@@ int ath_rx_init(struct ath_softc *sc, i
bf->bf_mpdu = skb;
bf->bf_buf_addr = pci_map_single(sc->pdev, skb->data,
- skb_end_pointer(skb) - skb->head,
+ sc->sc_rxbufsize,
PCI_DMA_FROMDEVICE);
bf->bf_dmacontext = bf->bf_buf_addr;
- ATH_RX_CONTEXT(skb)->ctx_rxbuf = bf;
}
sc->sc_rxlink = NULL;
@@@ -518,167 -512,43 +521,43 @@@ int ath_rx_tasklet(struct ath_softc *sc
}
}
- /* XXX: we do not support frames spanning
- * multiple descriptors */
- bf->bf_status |= ATH_BUFSTATUS_DONE;
-
skb = bf->bf_mpdu;
- if (skb == NULL) { /* XXX ??? can this happen */
- spin_unlock_bh(&sc->sc_rxbuflock);
+ if (!skb)
continue;
- }
- /*
- * Now we know it's a completed frame, we can indicate the
- * frame. Remove the previous holding descriptor and leave
- * this one in the queue as the new holding descriptor.
- */
- if (bf_held) {
- list_del(&bf_held->list);
- bf_held->bf_status &= ~ATH_BUFSTATUS_STALE;
- if (bf_held->bf_status & ATH_BUFSTATUS_FREE) {
- list_add_tail(&bf_held->list, &sc->sc_rxbuf);
- /* try to requeue this descriptor */
- ath_rx_buf_link(sc, bf_held);
- }
- }
- bf->bf_status |= ATH_BUFSTATUS_STALE;
- bf_held = bf;
/*
- * Release the lock here in case ieee80211_input() return
- * the frame immediately by calling ath_rx_mpdu_requeue().
+ * If we're asked to flush receive queue, directly
+ * chain it back at the queue without processing it.
*/
- spin_unlock_bh(&sc->sc_rxbuflock);
+ if (flush)
+ goto requeue;
- if (flush) {
- /*
- * If we're asked to flush receive queue, directly
- * chain it back at the queue without processing it.
- */
- goto rx_next;
- }
+ if (!ds->ds_rxstat.rs_datalen)
+ goto requeue;
- hdr = (struct ieee80211_hdr *)skb->data;
- fc = hdr->frame_control;
- memset(&rx_status, 0, sizeof(struct ath_recv_status));
+ /* The status portion of the descriptor could get corrupted. */
+ if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
+ goto requeue;
- if (ds->ds_rxstat.rs_more) {
- /*
- * Frame spans multiple descriptors; this
- * cannot happen yet as we don't support
- * jumbograms. If not in monitor mode,
- * discard the frame.
- */
- #ifndef ERROR_FRAMES
- /*
- * Enable this if you want to see
- * error frames in Monitor mode.
- */
- if (sc->sc_ah->ah_opmode != ATH9K_M_MONITOR)
- goto rx_next;
- #endif
- /* fall thru for monitor mode handling... */
- } else if (ds->ds_rxstat.rs_status != 0) {
- if (ds->ds_rxstat.rs_status & ATH9K_RXERR_CRC)
- rx_status.flags |= ATH_RX_FCS_ERROR;
- if (ds->ds_rxstat.rs_status & ATH9K_RXERR_PHY) {
- phyerr = ds->ds_rxstat.rs_phyerr & 0x1f;
- goto rx_next;
- }
+ if (!ath_rx_prepare(skb, ds, &rx_status, &decrypt_error, sc))
+ goto requeue;
- if (ds->ds_rxstat.rs_status & ATH9K_RXERR_DECRYPT) {
- /*
- * Decrypt error. We only mark packet status
- * here and always push up the frame up to let
- * mac80211 handle the actual error case, be
- * it no decryption key or real decryption
- * error. This let us keep statistics there.
- */
- rx_status.flags |= ATH_RX_DECRYPT_ERROR;
- } else if (ds->ds_rxstat.rs_status & ATH9K_RXERR_MIC) {
- /*
- * Demic error. We only mark frame status here
- * and always push up the frame up to let
- * mac80211 handle the actual error case. This
- * let us keep statistics there. Hardware may
- * post a false-positive MIC error.
- */
- if (ieee80211_is_ctl(fc))
- /*
- * Sometimes, we get invalid
- * MIC failures on valid control frames.
- * Remove these mic errors.
- */
- ds->ds_rxstat.rs_status &=
- ~ATH9K_RXERR_MIC;
- else
- rx_status.flags |= ATH_RX_MIC_ERROR;
- }
- /*
- * Reject error frames with the exception of
- * decryption and MIC failures. For monitor mode,
- * we also ignore the CRC error.
- */
- if (sc->sc_ah->ah_opmode == ATH9K_M_MONITOR) {
- if (ds->ds_rxstat.rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC |
- ATH9K_RXERR_CRC))
- goto rx_next;
- } else {
- if (ds->ds_rxstat.rs_status &
- ~(ATH9K_RXERR_DECRYPT | ATH9K_RXERR_MIC)) {
- goto rx_next;
- }
- }
- }
- /*
- * The status portion of the descriptor could get corrupted.
- */
- if (sc->sc_rxbufsize < ds->ds_rxstat.rs_datalen)
- goto rx_next;
- /*
- * Sync and unmap the frame. At this point we're
- * committed to passing the sk_buff somewhere so
- * clear buf_skb; this means a new sk_buff must be
- * allocated when the rx descriptor is setup again
- * to receive another frame.
- */
- skb_put(skb, ds->ds_rxstat.rs_datalen);
- skb->protocol = cpu_to_be16(ETH_P_CONTROL);
- rx_status.tsf = ath_extend_tsf(sc, ds->ds_rxstat.rs_tstamp);
- rx_status.rateieee =
- sc->sc_hwmap[ds->ds_rxstat.rs_rate].ieeerate;
- rx_status.rateKbps =
- sc->sc_hwmap[ds->ds_rxstat.rs_rate].rateKbps;
- rx_status.ratecode = ds->ds_rxstat.rs_rate;
-
- /* HT rate */
- if (rx_status.ratecode & 0x80) {
- /* TODO - add table to avoid division */
- if (ds->ds_rxstat.rs_flags & ATH9K_RX_2040) {
- rx_status.flags |= ATH_RX_40MHZ;
- rx_status.rateKbps =
- (rx_status.rateKbps * 27) / 13;
- }
- if (ds->ds_rxstat.rs_flags & ATH9K_RX_GI)
- rx_status.rateKbps =
- (rx_status.rateKbps * 10) / 9;
- else
- rx_status.flags |= ATH_RX_SHORT_GI;
- }
+ /* Ensure we always have an skb to requeue once we are done
+ * processing the current buffer's skb */
+ requeue_skb = ath_rxbuf_alloc(sc, sc->sc_rxbufsize);
- /* sc_noise_floor is only available when the station
- attaches to an AP, so we use a default value
- if we are not yet attached. */
- rx_status.abs_rssi =
- ds->ds_rxstat.rs_rssi + sc->sc_ani.sc_noise_floor;
+ /* If there is no memory we ignore the current RX'd frame,
+ * tell hardware it can give us a new frame using the old
+ * skb and put it at the tail of the sc->sc_rxbuf list for
+ * processing. */
+ if (!requeue_skb)
+ goto requeue;
- pci_dma_sync_single_for_cpu(sc->pdev,
- bf->bf_buf_addr,
+ /* Sync and unmap the frame */
+ pci_dma_sync_single_for_cpu(sc->pdev, bf->bf_buf_addr,
- skb_tailroom(skb),
+ sc->sc_rxbufsize,
PCI_DMA_FROMDEVICE);
- pci_unmap_single(sc->pdev,
- bf->bf_buf_addr,
+ pci_unmap_single(sc->pdev, bf->bf_buf_addr,
sc->sc_rxbufsize,
PCI_DMA_FROMDEVICE);
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: stephane eranian @ 2008-11-26 8:32 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <20081126033318.GE8242@elte.hu>
Ingo,
On Wed, Nov 26, 2008 at 4:33 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> > In any case, until that happens and until there's agreement with
>> > the x86 maintainers (there's none at the moment) the perfmon3 tree
>> > (or at least its x86 bits) needs to be removed from linux-next. I
>> > already see a number of problems with the patchset that we'll have
>> > to work out via an iterative review process.
>>
>> That process has been happening except it seems that the x86
>> maintainers haven't bothered to participate. [...]
>
> uhm, that's plain not true. There are three x86 maintainers and we
> take pride in replying to all x86 patch submission within a day
> typically, so i reject your suggestion.
>
> We know and knew about the existence of the perfmon patches, but they
> were always in the vague RFC category and never directly submitted or
> Cc:-ed to us.
>
As Stephen pointed out, the full patchset was posted on LKML in October
I never saw any comments from you or any other x86 maintainers. I always
assumed you were ALL on LKML anyway.
The perfmon patchset has been posted on LKML numerous times. I have
listened to all comments and made tons of changes both internally and to
the syscall APIs. I would not call this patchset a 'vague RFC'.
> The authors of those patches never even bothered to Cc: the x86 arch
> maintainers, and never asked for those patches to be Ack-ed, accepted
> or reviewed. If that is not so, please show me the lkml link that
> contradicts my claim.
>
You were cc'ed but apparently there is a problem with the script I am using
to post this patchset as it seems it was sent only to LKML and the cc-list
got dropped.
>
> All i'm asking for is to not use linux-next as a backdoor to get
> _unreviewed_ and _clearly bad_ patches behind the back of architecture
> maintainers who specifically asked to be involved.
>
I would appreciate if you could explain and point me to the x86 code which
you think is bad. I am always happy to take constructive comments to
improve the code.
I have reposted the full patchset yesterday on LKML but unfortunately my
script dropped the cc-list. I will repost today making sure x86@kernel.org
is cc'ed. I am sorry about that, it never was intentional. I will be waiting for
your feedback on the x86 code.
^ permalink raw reply
* Re: linux-next: net tree build failure
From: Herbert Xu @ 2008-11-26 7:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, linux-next, Patrick McHardy, Alexey Dobriyan
In-Reply-To: <20081126181543.0d7fba17.sfr@canb.auug.org.au>
On Wed, Nov 26, 2008 at 06:15:43PM +1100, Stephen Rothwell wrote:
> Hi Dave,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> net/bridge/br_netfilter.c:112: error: unknown field 'entry_size' specified in initializer
> net/bridge/br_netfilter.c:112: warning: initialization makes pointer from integer without a cast
>
> Caused by commit 631339f1e544a4d39a63cfe6708c5bddcd5a2c48 ("bridge:
> netfilter: fix update_pmtu crash with GRE") from the net-current tree
> interacting with commit 6bb3ce25d05f2990c8a19adaf427531430267c1f ("net:
> remove struct dst_entry::entry_size") from the net tree.
>
> I added the below patch as a temporary merge fix.
Yes your patch is correct. Thanks Stephen!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: Ingo Molnar @ 2008-11-26 7:16 UTC (permalink / raw)
To: Paul Mackerras
Cc: Stephen Rothwell, eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <18732.62831.286805.400379@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Ingo Molnar writes:
>
> > We know and knew about the existence of the perfmon patches, but they
> > were always in the vague RFC category and never directly submitted or
> > Cc:-ed to us.
>
> So at least now we have your attention. :)
>
> The best thing now might be for Stephane to do a patch set with the
> perfmon3 core + powerpc bits. I'd be happy to take that through my
> tree, and I really want to see perfmon3 get upstream. X86 can
> follow whenever you can get some time to take a look at it.
Sounds sensible. x86 doesnt always have to be the guinea pig for new
kernel features :)
Ingo
^ permalink raw reply
* linux-next: net tree build failure
From: Stephen Rothwell @ 2008-11-26 7:15 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Herbert Xu, Patrick McHardy, Alexey Dobriyan
Hi Dave,
Today's linux-next build (x86_64 allmodconfig) failed like this:
net/bridge/br_netfilter.c:112: error: unknown field 'entry_size' specified in initializer
net/bridge/br_netfilter.c:112: warning: initialization makes pointer from integer without a cast
Caused by commit 631339f1e544a4d39a63cfe6708c5bddcd5a2c48 ("bridge:
netfilter: fix update_pmtu crash with GRE") from the net-current tree
interacting with commit 6bb3ce25d05f2990c8a19adaf427531430267c1f ("net:
remove struct dst_entry::entry_size") from the net tree.
I added the below patch as a temporary merge fix.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 0b3cd89..274194b 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -109,7 +109,6 @@ static struct dst_ops fake_dst_ops = {
.family = AF_INET,
.protocol = __constant_htons(ETH_P_IP),
.update_pmtu = fake_update_pmtu,
- .entry_size = sizeof(struct rtable),
.entries = ATOMIC_INIT(0),
};
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: manual merge of the perfmon3 tree
From: Paul Mackerras @ 2008-11-26 7:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <20081126033318.GE8242@elte.hu>
Ingo Molnar writes:
> We know and knew about the existence of the perfmon patches, but they
> were always in the vague RFC category and never directly submitted or
> Cc:-ed to us.
So at least now we have your attention. :)
The best thing now might be for Stephane to do a patch set with the
perfmon3 core + powerpc bits. I'd be happy to take that through my
tree, and I really want to see perfmon3 get upstream. X86 can follow
whenever you can get some time to take a look at it.
Paul.
^ permalink raw reply
* Re: userns tree ready
From: Stephen Rothwell @ 2008-11-26 6:55 UTC (permalink / raw)
To: James Morris; +Cc: Serge E. Hallyn, David Howells, linux-next
In-Reply-To: <alpine.LRH.1.10.0811261720350.26924@tundra.namei.org>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
Hi James, Serge,
On Wed, 26 Nov 2008 17:21:21 +1100 (EST) James Morris <jmorris@namei.org> wrote:
>
> I've now merged your branch above into:
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
I will remove it completely from linux-next tomorrow and leave you two to
keep it up to date between yourselves.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net tree
From: Stephen Rothwell @ 2008-11-26 6:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Luis R. Rodriguez, John W. Linville, Martin Xu
Hi Dave,
Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/ath5k/base.c between commit
02969b38e6f7cef80e71d673d1e512e029a7009f ("ath5k: disable beacon filter
when station is not associated") from the net-current tree and commits da966bcae70e4012b7d999820b728dd6502047e0 ("Ath5k: add AP mode") and 296bf2aefdf7b4b1bf093a7b42a86ee21b46d07f ("ath5k: allow APs to receive
beacons") from the net tree.
I fixed it up (see below) and assume it will be fixed in the net tree
soon.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc drivers/net/wireless/ath5k/base.c
index 2d14255,34cd1a4..0000000
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@@ -238,12 -240,7 +240,11 @@@ static int ath5k_get_tx_stats(struct ie
struct ieee80211_tx_queue_stats *stats);
static u64 ath5k_get_tsf(struct ieee80211_hw *hw);
static void ath5k_reset_tsf(struct ieee80211_hw *hw);
- static int ath5k_beacon_update(struct ieee80211_hw *hw,
- struct sk_buff *skb);
+ static int ath5k_beacon_update(struct ath5k_softc *sc, struct sk_buff *skb);
+static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_bss_conf *bss_conf,
+ u32 changes);
static struct ieee80211_ops ath5k_hw_ops = {
.tx = ath5k_tx,
@@@ -2947,13 -2952,16 +2957,16 @@@ static void ath5k_configure_filter(stru
sc->opmode != NL80211_IFTYPE_MESH_POINT &&
test_bit(ATH_STAT_PROMISC, sc->status))
rfilt |= AR5K_RX_FILTER_PROM;
- if (sc->opmode == NL80211_IFTYPE_STATION ||
+ if ((sc->opmode == NL80211_IFTYPE_STATION && sc->assoc) ||
- sc->opmode == NL80211_IFTYPE_ADHOC) {
+ sc->opmode == NL80211_IFTYPE_ADHOC ||
+ sc->opmode == NL80211_IFTYPE_AP)
rfilt |= AR5K_RX_FILTER_BEACON;
- }
+ if (sc->opmode == NL80211_IFTYPE_MESH_POINT)
+ rfilt |= AR5K_RX_FILTER_CONTROL | AR5K_RX_FILTER_BEACON |
+ AR5K_RX_FILTER_PROBEREQ | AR5K_RX_FILTER_PROM;
/* Set filters */
- ath5k_hw_set_rx_filter(ah,rfilt);
+ ath5k_hw_set_rx_filter(ah, rfilt);
/* Set multicast bits */
ath5k_hw_set_mcast_filter(ah, mfilt[0], mfilt[1]);
@@@ -3085,35 -3090,6 +3095,34 @@@ ath5k_beacon_update(struct ath5k_softc
mmiowb();
}
- end:
return ret;
}
+static void
+set_beacon_filter(struct ieee80211_hw *hw, bool enable)
+{
+ struct ath5k_softc *sc = hw->priv;
+ struct ath5k_hw *ah = sc->ah;
+ u32 rfilt;
+ rfilt = ath5k_hw_get_rx_filter(ah);
+ if (enable)
+ rfilt |= AR5K_RX_FILTER_BEACON;
+ else
+ rfilt &= ~AR5K_RX_FILTER_BEACON;
+ ath5k_hw_set_rx_filter(ah, rfilt);
+ sc->filter_flags = rfilt;
+}
+static void ath5k_bss_info_changed(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_bss_conf *bss_conf,
+ u32 changes)
+{
+ struct ath5k_softc *sc = hw->priv;
+ if (changes & BSS_CHANGED_ASSOC) {
+ mutex_lock(&sc->lock);
+ sc->assoc = bss_conf->assoc;
+ if (sc->opmode == NL80211_IFTYPE_STATION)
+ set_beacon_filter(hw, sc->assoc);
+ mutex_unlock(&sc->lock);
+ }
+}
^ permalink raw reply
* linux-next: manual merge of the net tree
From: Stephen Rothwell @ 2008-11-26 6:42 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Ingo Molnar, John W. Linville, Johannes Berg
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
Hi Dave,
Today's linux-next merge of the net tree got a conflict in
net/wireless/reg.c between commit
020cf6ba7a91ccc5db359f91e9abba175fd3a0aa ("net/wireless/reg.c: fix bad
WARN_ON in if statement") from the net-current tree and commit
2083c4997b95fffe8d4f71741bef2298810805a3 ("wireless: clean up regulatory
ignore_request function") from the net tree.
The latter removed the code that the former fixed. I assume that this
conflict will be fixed in the net tree soon.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: userns tree ready
From: James Morris @ 2008-11-26 6:21 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: Stephen Rothwell, David Howells, linux-next
In-Reply-To: <20081125142406.GA9761@us.ibm.com>
On Tue, 25 Nov 2008, Serge E. Hallyn wrote:
> Quoting James Morris (jmorris@namei.org):
> > On Mon, 24 Nov 2008, Serge E. Hallyn wrote:
> >
> > > Hi Stephen,
> > >
> > > I've created a new userns tree - although the patches are completely
> > > unchanged from before they were pulled along with David's patches.
> > > They apply fine either right after James' security-next tree or at
> > > the end of linux-next. The tree is at
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/userns-2.6#next
> > >
> > > like before, and is based on James's security-next tree.
> >
> > I can merge this into my tree, although if it breaks, I'll need help from
> > you to fix it.
>
> Thanks, James. I don't know which (security-next or linux-next) is more
> appropriate, but I think Stephen may have already added it to
> Next/Trees. I'll of course fix any breakages in any case.
I've now merged your branch above into:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: linux-next: ocfs2 tree build failure
From: Stephen Rothwell @ 2008-11-26 5:30 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linux-next, Jan Kara
In-Reply-To: <20081125164204.6817a397.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
Hi Mark,
On Tue, 25 Nov 2008 16:42:04 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> usr/include/linux/dqblk_v2.h:8: included file 'linux/dqblk_qtree.h' is not exported
> make[4]: *** [/scratch/sfr/x86_64_allmodconfig/usr/include/linux/.check] Error 1
>
> Caused by commit 603f68d0c2b66052093ea29bf1ff7a8a58667af6 ("quota: Split
> off quota tree handling into a separate file"). dqblk_qtree.h needs to
> be added to the Kbuild file.
Still fails, so I have dropped the ocfs2 tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: arm build failure
From: Eric Miao @ 2008-11-26 4:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Russell King, Dmitry Baryshkov
In-Reply-To: <20081126133052.082e1d45.sfr@canb.auug.org.au>
On Wed, Nov 26, 2008 at 10:30 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Eric,
>
> next-20081125 build (arm corgi_defconfig) failed like this:
>
> arch/arm/mach-pxa/built-in.o: In function `sleep_save_sp':
> tosa.c:(.data+0x3978): undefined reference to `tc6393xb_lcd_set_power'
> tosa.c:(.data+0x397c): undefined reference to `tc6393xb_lcd_mode'
>
> Caused by commit fc37aa322a7e9170979a044c3f178ae4162ca285 ("[ARM]
> pxa/tosa: support tc6393xb/tmiofb.").
>
Thanks Stephen.
This is caused by corgi_defconfig being incorrectly including the tosa
support, patch is ready for this and will be pushed out soon.
Dmitry,
Please handle the config dependency of tosa.c, tc6393xb.c and tmiofb
correctly.
^ permalink raw reply
* linux-next: kbuild tree build failure
From: Stephen Rothwell @ 2008-11-26 4:42 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
Hi Sam,
Today's linux-next build (x86_64 allmodconfig) failed like this:
In file included from arch/x86/include/asm/processor.h:15,
from include/linux/prefetch.h:14,
from include/linux/list.h:6,
from include/linux/module.h:9,
from kernel/configs.mod.c:1:
arch/x86/include/asm/current.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'struct'
and went rapidly down hill from there.
I have dropped the kbuild tree again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: linux-next: manual merge of the perfmon3 tree
From: H. Peter Anvin @ 2008-11-26 4:24 UTC (permalink / raw)
To: Ingo Molnar, Stephen Rothwell
Cc: eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, Thomas Gleixner, Peter Zijlstra,
Andrew Morton
I guess it really comes down to: is -next a merge window preview tree, or is it another -mm tree just based on a different toolset/workflow?
-hpa
--
Sent from my mobile phone (pardon any lack of formatting)
-----Original Message-----
From: Ingo Molnar <mingo@elte.hu>
Sent: Tuesday, November 25, 2008 19:33
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: eranian@gmail.com; linux-next@vger.kernel.org; Alexander van Heukelum <heukelum@mailshack.com>; the arch/x86 maintainers <x86@kernel.org>; H. Peter Anvin <hpa@zytor.com>; Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra <a.p.zijlstra@chello.nl>; Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: manual merge of the perfmon3 tree
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > In any case, until that happens and until there's agreement with
> > the x86 maintainers (there's none at the moment) the perfmon3 tree
> > (or at least its x86 bits) needs to be removed from linux-next. I
> > already see a number of problems with the patchset that we'll have
> > to work out via an iterative review process.
>
> That process has been happening except it seems that the x86
> maintainers haven't bothered to participate. [...]
uhm, that's plain not true. There are three x86 maintainers and we
take pride in replying to all x86 patch submission within a day
typically, so i reject your suggestion.
We know and knew about the existence of the perfmon patches, but they
were always in the vague RFC category and never directly submitted or
Cc:-ed to us.
The authors of those patches never even bothered to Cc: the x86 arch
maintainers, and never asked for those patches to be Ack-ed, accepted
or reviewed. If that is not so, please show me the lkml link that
contradicts my claim.
And how did we notice that this was going on? Not because we were
told, but due to a bad perfmon commit modifying x86 code that suddenly
showed up in linux-next ...
> [...] If, as you say, all the x86 parts have to go via the x86 tree,
> then be aware that this woukd probably delay x86 perfmon integration
> until 2.6.30 or later [...]
Why should that be so?
All i'm asking for you is to follow the upstream kernel integration
process. All i'm asking you is when a new tree matches such a wide
pattern of x86 modifications:
25 files changed, 2340 insertions(+), 6 deletions(-)
_to at least Cc: the maintainers and ask their opinion_
this isnt just a file here and there. It goes straight into the guts
of the architecture.
All i'm asking for is to not use linux-next as a backdoor to get
_unreviewed_ and _clearly bad_ patches behind the back of architecture
maintainers who specifically asked to be involved.
> [...] (*cough* ftrace *cough*). [...]
I'm not sure what you want to imply by that. ftrace was delayed for
several kernel releases before it went upstream and the initial port
went upstream with the full knowledge (and participation) of the
architecture maintainers. (x86, incidentally)
> [...] As Andrew pointed out in another thread you seem to have
> missed, the integration of perfmon (or something like it) is way
> over due. The way he suggested to go forward was to get it into
> linux-next and aim for 2.6.29 integration.
>
> Several other architectures want this code in the kernel, so if they
> have to wait for the x86 maintainers to decide what they want, then
> the only way forward may be to separate the generic parts of the
> code and get that integrated along with one of the other
> architectures.
There's a proper process for merging brand new features, and it starts
with asking the opinion of the maintainers. This isnt just a random
stale subsystem no-one is interested in. This is a highly active piece
of code maintained by three maintainers. This subsystem saw more than
5800 commits in the last year alone.
Stephen, this is kernel maintenance 101, and you must follow it.
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: Ingo Molnar @ 2008-11-26 3:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <20081126140032.72d86f17.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > In any case, until that happens and until there's agreement with
> > the x86 maintainers (there's none at the moment) the perfmon3 tree
> > (or at least its x86 bits) needs to be removed from linux-next. I
> > already see a number of problems with the patchset that we'll have
> > to work out via an iterative review process.
>
> That process has been happening except it seems that the x86
> maintainers haven't bothered to participate. [...]
uhm, that's plain not true. There are three x86 maintainers and we
take pride in replying to all x86 patch submission within a day
typically, so i reject your suggestion.
We know and knew about the existence of the perfmon patches, but they
were always in the vague RFC category and never directly submitted or
Cc:-ed to us.
The authors of those patches never even bothered to Cc: the x86 arch
maintainers, and never asked for those patches to be Ack-ed, accepted
or reviewed. If that is not so, please show me the lkml link that
contradicts my claim.
And how did we notice that this was going on? Not because we were
told, but due to a bad perfmon commit modifying x86 code that suddenly
showed up in linux-next ...
> [...] If, as you say, all the x86 parts have to go via the x86 tree,
> then be aware that this woukd probably delay x86 perfmon integration
> until 2.6.30 or later [...]
Why should that be so?
All i'm asking for you is to follow the upstream kernel integration
process. All i'm asking you is when a new tree matches such a wide
pattern of x86 modifications:
25 files changed, 2340 insertions(+), 6 deletions(-)
_to at least Cc: the maintainers and ask their opinion_
this isnt just a file here and there. It goes straight into the guts
of the architecture.
All i'm asking for is to not use linux-next as a backdoor to get
_unreviewed_ and _clearly bad_ patches behind the back of architecture
maintainers who specifically asked to be involved.
> [...] (*cough* ftrace *cough*). [...]
I'm not sure what you want to imply by that. ftrace was delayed for
several kernel releases before it went upstream and the initial port
went upstream with the full knowledge (and participation) of the
architecture maintainers. (x86, incidentally)
> [...] As Andrew pointed out in another thread you seem to have
> missed, the integration of perfmon (or something like it) is way
> over due. The way he suggested to go forward was to get it into
> linux-next and aim for 2.6.29 integration.
>
> Several other architectures want this code in the kernel, so if they
> have to wait for the x86 maintainers to decide what they want, then
> the only way forward may be to separate the generic parts of the
> code and get that integrated along with one of the other
> architectures.
There's a proper process for merging brand new features, and it starts
with asking the opinion of the maintainers. This isnt just a random
stale subsystem no-one is interested in. This is a highly active piece
of code maintained by three maintainers. This subsystem saw more than
5800 commits in the last year alone.
Stephen, this is kernel maintenance 101, and you must follow it.
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the perfmon3 tree
From: Stephen Rothwell @ 2008-11-26 3:00 UTC (permalink / raw)
To: Ingo Molnar
Cc: eranian, linux-next, Alexander van Heukelum,
the arch/x86 maintainers, H. Peter Anvin, Thomas Gleixner,
Peter Zijlstra, Andrew Morton
In-Reply-To: <20081125165118.GF22504@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
Hi Ingo,
On Tue, 25 Nov 2008 17:51:18 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> There are a number of ways to do that - and we'll sure be able to work
> that out - but first please submit the full patchset (x86 and generic
> bits as well) to lkml with the x86 maintainers Cc:-ed.
Let see ... the permfmon patches have been submitted to LKML several
times over the past couple of years. In their latest incarnation they
were posted to LKML on October 18 (lkml is, of course, also the mailing
list for x86 patches noted in MAINTAINERS - maybe you should submit a
patch noting that x86 code has to be submitted on x86@kernel.org as
well). There has been ample time for the x86 maintainers to comment and
notice that their code is being modified. I have seen no attempt at
review from them.
Also this code has been in linux-next since next-20081106 (i.e. November
6) and the only problem reports have been from the ia64 people.
> In any case, until that happens and until there's agreement with the
> x86 maintainers (there's none at the moment) the perfmon3 tree (or at
> least its x86 bits) needs to be removed from linux-next. I already see
> a number of problems with the patchset that we'll have to work out via
> an iterative review process.
That process has been happening except it seems that the x86 maintainers
haven't bothered to participate. If, as you say, all the x86 parts have
to go via the x86 tree, then be aware that this woukd probably delay x86
perfmon integration until 2.6.30 or later (*cough* ftrace *cough*). As
Andrew pointed out in another thread you seem to have missed, the
integration of perfmon (or something like it) is way over due. The way
he suggested to go forward was to get it into linux-next and aim for
2.6.29 integration.
Several other architectures want this code in the kernel, so if they have
to wait for the x86 maintainers to decide what they want, then the only
way forward may be to separate the generic parts of the code and get that
integrated along with one of the other architectures.
/me dons flame-proof suite :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: arm build failure
From: Stephen Rothwell @ 2008-11-26 2:30 UTC (permalink / raw)
To: Eric Miao; +Cc: linux-next, Russell King, Dmitry Baryshkov
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
Hi Eric,
next-20081125 build (arm corgi_defconfig) failed like this:
arch/arm/mach-pxa/built-in.o: In function `sleep_save_sp':
tosa.c:(.data+0x3978): undefined reference to `tc6393xb_lcd_set_power'
tosa.c:(.data+0x397c): undefined reference to `tc6393xb_lcd_mode'
Caused by commit fc37aa322a7e9170979a044c3f178ae4162ca285 ("[ARM]
pxa/tosa: support tc6393xb/tmiofb.").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: ftrace tree build failure
From: Luis R. Rodriguez @ 2008-11-26 0:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Luis Rodriguez, John W. Linville, Ingo Molnar, Thomas Gleixner,
H. Peter Anvin, linux-next@vger.kernel.org, Steven Rostedt,
David S. Miller
In-Reply-To: <20081126110847.4d9cf9f2.sfr@canb.auug.org.au>
On Tue, Nov 25, 2008 at 04:08:47PM -0800, Stephen Rothwell wrote:
> Hi,
>
> On Tue, 25 Nov 2008 10:46:30 -0800 "Luis R. Rodriguez" <lrodriguez@atheros.com> wrote:
> >
> > On Tue, Nov 25, 2008 at 06:57:01AM -0800, John W. Linville wrote:
> > > I have the patch now...thanks!
> > >
> > > Now, if I only knew why my build didn't fail with the original code...
> >
> > Same here I run tests with sparse too prior to sending patches.
>
> It is valid C.
>
> if (a, b)
>
> you evaluate a and discard it then evaluate b and that is the value of
> the conditional expression. In this case b is just a string which is
> effectively a non NULL "const char *" which is just non zero as far as if
> is concerned. So the conditional expression evaluates to (constant)
> true. So this was, in fact a bug ...
Thanks, and good catch :)
Luis
^ permalink raw reply
* Re: linux-next: ftrace tree build failure
From: Stephen Rothwell @ 2008-11-26 0:08 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John W. Linville, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
linux-next@vger.kernel.org, Steven Rostedt, Luis Rodriguez,
David S. Miller
In-Reply-To: <20081125184630.GA5950@tesla>
[-- Attachment #1: Type: text/plain, Size: 825 bytes --]
Hi,
On Tue, 25 Nov 2008 10:46:30 -0800 "Luis R. Rodriguez" <lrodriguez@atheros.com> wrote:
>
> On Tue, Nov 25, 2008 at 06:57:01AM -0800, John W. Linville wrote:
> > I have the patch now...thanks!
> >
> > Now, if I only knew why my build didn't fail with the original code...
>
> Same here I run tests with sparse too prior to sending patches.
It is valid C.
if (a, b)
you evaluate a and discard it then evaluate b and that is the value of
the conditional expression. In this case b is just a string which is
effectively a non NULL "const char *" which is just non zero as far as if
is concerned. So the conditional expression evaluates to (constant)
true. So this was, in fact a bug ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: ttydev import warning
From: Stephen Rothwell @ 2008-11-26 0:04 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 221 bytes --]
Hi Alan,
The patch tty-n-tty-sigio actually contained no patch so it will no
appear in today's linux-next.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the security-testing tree
From: J. Bruce Fields @ 2008-11-25 21:49 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: James Morris, linux-next, David Howells
In-Reply-To: <20081125191137.d5474c9e.sfr@canb.auug.org.au>
On Tue, Nov 25, 2008 at 07:11:37PM +1100, Stephen Rothwell wrote:
> Hi James,
>
> Today's linux-next merge of the security-testing tree got a conflict in
> fs/nfsd/nfs4recover.c between commit
> e4625eb826de4f6774ee602c442ba23b686bdcc7 ("nfsd: use of unitialized list
> head on error exit in nfs4recover.c") from the nfsd tree and commit
> d84f4f992cbd76e8f39c488cf0c5d123843923b1 ("CRED: Inaugurate COW
> credentials") from the security-testing tree.
>
> Just a context change. I fixed it up (see below) and can carry the fix as
> necessary.
Thanks!--b.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> diff --cc fs/nfsd/nfs4recover.c
> index cf94563,9371ea1..0000000
> --- a/fs/nfsd/nfs4recover.c
> +++ b/fs/nfsd/nfs4recover.c
> @@@ -224,10 -230,12 +230,13 @@@ nfsd4_list_rec_dir(struct dentry *dir,
> if (!rec_dir_init)
> return 0;
>
> - nfs4_save_user(&uid, &gid);
> + status = nfs4_save_creds(&original_cred);
> + if (status < 0)
> + return status;
> + INIT_LIST_HEAD(dentries);
>
> - filp = dentry_open(dget(dir), mntget(rec_dir.mnt), O_RDONLY);
> + filp = dentry_open(dget(dir), mntget(rec_dir.mnt), O_RDONLY,
> + current_cred());
> status = PTR_ERR(filp);
> if (IS_ERR(filp))
> goto out;
^ permalink raw reply
* Re: [BUILD_FAILURE] linux-next: 20081125 - 8390 network driver build fails
From: David Miller @ 2008-11-25 21:42 UTC (permalink / raw)
To: randy.dunlap
Cc: alan, kamalesh, sfr, linux-next, linux-kernel, p_gortmaker,
netdev, mel, shemminger
In-Reply-To: <492C5B52.6090803@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 25 Nov 2008 12:08:50 -0800
> Looks like it's due to CONFIG_COMPAT_NET_DEV_OPS.
Right, I've asked Stephen Hemminger to fix this.
> Dave, no need to drop my hp-plus driver patch.
Yes, I knew this :)
^ permalink raw reply
* Re: [BUILD_FAILURE] linux-next: 20081125 - 8390 network driver build fails
From: Randy Dunlap @ 2008-11-25 20:08 UTC (permalink / raw)
To: Alan Cox
Cc: Randy Dunlap, Kamalesh Babulal, Stephen Rothwell, linux-next,
LKML, p_gortmaker, netdev, mel, shemminger
In-Reply-To: <20081125195756.12317499@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>> drivers/net/8390p.o: In function `ei_get_stats':
>> (.text+0x1050): multiple definition of `ei_get_stats'
>> drivers/net/8390.o:(.text+0xe20): first defined here
>> drivers/net/8390p.o: In function `ei_start_xmit':
>> (.text+0x1100): multiple definition of `ei_start_xmit'
>> drivers/net/8390.o:(.text+0xef0): first defined here
>> drivers/net/8390p.o: In function `ei_tx_timeout':
>> (.text+0xec0): multiple definition of `ei_tx_timeout'
>> drivers/net/8390.o:(.text+0xce0): first defined here
>> drivers/net/8390p.o: In function `ei_set_multicast_list':
>> (.text+0x1000): multiple definition of `ei_set_multicast_list'
>> drivers/net/8390.o:(.text+0xea0): first defined here
>> make[2]: *** [drivers/net/built-in.o] Error 1
>>
>> and none of these functions is static in lib8390.c.
>
> They seem to be just fine in the base tree, so somebody has merged
> something stoopid.
>
>
> */
>
> static int ei_start_xmit(struct sk_buff *skb, struct net_device *dev)
> {
OK, ack that, thanks.
Looks like it's due to CONFIG_COMPAT_NET_DEV_OPS.
Dave, no need to drop my hp-plus driver patch.
~Randy
^ permalink raw reply
* Re: [BUILD_FAILURE] linux-next: 20081125 - 8390 network driver build fails
From: Alan Cox @ 2008-11-25 19:57 UTC (permalink / raw)
Cc: Randy Dunlap, Kamalesh Babulal, Stephen Rothwell, linux-next,
LKML, p_gortmaker, netdev, mel
In-Reply-To: <492C562E.9090302@oracle.com>
> drivers/net/8390p.o: In function `ei_get_stats':
> (.text+0x1050): multiple definition of `ei_get_stats'
> drivers/net/8390.o:(.text+0xe20): first defined here
> drivers/net/8390p.o: In function `ei_start_xmit':
> (.text+0x1100): multiple definition of `ei_start_xmit'
> drivers/net/8390.o:(.text+0xef0): first defined here
> drivers/net/8390p.o: In function `ei_tx_timeout':
> (.text+0xec0): multiple definition of `ei_tx_timeout'
> drivers/net/8390.o:(.text+0xce0): first defined here
> drivers/net/8390p.o: In function `ei_set_multicast_list':
> (.text+0x1000): multiple definition of `ei_set_multicast_list'
> drivers/net/8390.o:(.text+0xea0): first defined here
> make[2]: *** [drivers/net/built-in.o] Error 1
>
> and none of these functions is static in lib8390.c.
They seem to be just fine in the base tree, so somebody has merged
something stoopid.
*/
static int ei_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
Alan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox