On Sun, 2012-11-11 at 17:57 -0500, Chas Williams (CONTRACTOR) wrote:
> In message <1352667081.9449.135.ca...@shinybook.infradead.org>,David
> Woodhouse writes:
> >Acked-by: David Woodhouse for your new
> >version of patch #6 (returning DROP_PACKET for !VF_READY), and your
Krzysztof, you've fixed a bunch of races... but I think there's one
still left.
An ATM driver will often have code like this, which gets called from
arbitrary contexts:
if (vcc->pop)
vcc->pop(vcc, skb);
Now, what happens if pppoatm_send(vcc, NULL) happens after the address
On Tue, 2012-11-27 at 18:39 +0100, Krzysztof Mazur wrote:
> Yes, I missed that one - it's even worse, I introduced that bug
> in "[PATCH 1/7] atm: detach protocol before closing vcc". Before that
> patch that scenario shouldn't happen because vcc was closed before
> calling pppoatm_send(vcc, NULL)
We should no longer be calling the old pop routine for the vcc, after
vcc_release() has completed. Make sure we wait for any pending TX skbs
to complete, by waiting for our own PKT_PCLOSE control skb to be sent.
Signed-off-by: David Woodhouse
---
On Tue, 2012-11-27 at 13:54 -0500, chas williams
Avoid submitting patches to a vcc which is being closed. Things go badly
wrong when the ->pop method gets later called after everything's been
torn down.
Signed-off-by: David Woodhouse
---
On Tue, 2012-11-27 at 22:36 +0000, David Woodhouse wrote:
> Nathan, does this help?
I t
7;ve tried to collect together the latest version of
everything we've discussed:
http://git.infradead.org/users/dwmw2/atm.git
git://git.infradead.org/users/dwmw2/atm.git
David Woodhouse (5):
solos-pci: Wait for pending TX to complete when releasing vcc
br2684: don't send
On Wed, 2012-11-28 at 00:51 +0100, Krzysztof Mazur wrote:
> If you do this actually it's better to don't use patch 1/7 because
> it introduces race condition that you found earlier.
Right. I've omitted that from the git tree I just pushed out.
> With this patch you have still theoretical race tha
On Wed, 2012-11-28 at 09:12 +0100, Krzysztof Mazur wrote:
> On Wed, Nov 28, 2012 at 12:48:17AM +0000, David Woodhouse wrote:
> > On Tue, 2012-11-27 at 10:23 -0500, chas williams - CONTRACTOR wrote:
> > > yes, but dont call it 8/7 since that doesnt make sense.
> >
> >
On Wed, 2012-11-28 at 09:08 +0100, Krzysztof Mazur wrote:
>
> I think you might need also an equivalent of
> "[PATCH v3 3/7] pppoatm: allow assign only on a connected socket".
>
> I'm not sure yet. In will test if I can trigger that Oops on pppoatm
> without that patch. Testing vcc flags might be
the BLOCKED bit in the
normal flow control case, by setting it at the nospace: label!
From b2cf6a466697ecf19061cb11b8f4ec5bb381550a Mon Sep 17 00:00:00 2001
From: David Woodhouse
Date: Wed, 28 Nov 2012 10:15:05 +
Subject: [PATCH] pppoatm: optimise PPP channel wakeups after
sock_owned_by_user(
On Wed, 2012-11-28 at 11:04 +0100, Krzysztof Mazur wrote:
>
> The ->close() routine can just abort any pending rx/tx and just wait
> for completion of currently running rx/tx code. That shouldn't take
> long.
If it's been submitted to the hardware for DMA, it can't do that very
easily.
And if I
On Wed, 2012-11-28 at 11:41 -0500, David Miller wrote:
>
> Please:
>
> if (X ||
> Y ||
> Z)
>
> not:
>
> if (X
> || Y
> || Z)
Thanks. Fixed in both Krzysztof's original pppoatm version, and my
br2684 patch, in the git tree at git:
On Wed, 2012-11-28 at 12:04 -0500, David Miller wrote:
> Do you want me to pull that tree into net-next or is there a plan to
> repost the entire series of work for a final submission?
I think it needs a little more testing/consensus first. I'd like an ack
from Chas on the atm ->release_cb() thing
On Wed, 2012-11-28 at 21:18 +0100, Krzysztof Mazur wrote:
>
> +void vcc_pop_any(struct atm_vcc *vcc, struct sk_buff *skb)
> +{
> + if (vcc->pop)
> + vcc->pop(vcc, skb);
if (vcc && vcc->pop) perhaps?
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
on Sep 17 00:00:00 2001
From: David Woodhouse
Date: Tue, 27 Nov 2012 23:49:24 +
Subject: [PATCH] solos-pci: Wait for pending TX to complete when releasing
vcc
We should no longer be calling the old pop routine for the vcc, after
vcc_release() has completed. Make sure we wait for any pending T
On Thu, 2012-11-29 at 11:57 +0100, Krzysztof Mazur wrote:
> do we really need to wait here?
> Why don't just do something like that:
>
> tasklet_disable(&card->tlet);
> spin_lock(&card->tx_queue_lock);
> for each skb in queue
> SKB_CB(skb)->vcc = NULL;
> spin_
On Thu, 2012-11-29 at 13:43 +0100, Krzysztof Mazur wrote:
>
> Removing packets from tx_queue is not needed. We can transmit packets
> also after close. We just can't call vcc->pop() after close,
> so we can just set SKB_CB(skb)->vcc of such packets to NULL so
> fpga_tx() won't call vcc->pop().
Yo
On Thu, 2012-11-29 at 14:20 +0100, Krzysztof Mazur wrote:
> if (card->tx_skb[port] == skb) {
> skb_get(skb);
> solos_pop(SKB_CB(skb)->vcc, skb);
> SKB_CB(skb)->vcc = NULL;
Um... yes, that would probably work. B
On Thu, 2012-11-29 at 16:09 +0100, Krzysztof Mazur wrote:
>
> I don't like two thinks about this patch:
>
> - if allos_skb(sizeof(*header), GFP_ATOMIC) at beginning of
> pclose() fails we will crash
>
> - if card wakes up after this timeout we will probably crash too
>
On Thu, 2012-11-29 at 10:37 -0500, chas williams - CONTRACTOR wrote:
> you shouldnt clear ATM_VF_ADDR until the vpi/vci is actually closed and
> ready for reuse. at this point, it isnt.
So I should always wait for the completion of my PKT_CLOSE and only
clear ATM_VF_ADDR when it's actually done?
On Thu, 2012-11-29 at 10:59 -0500, chas williams - CONTRACTOR wrote:
> the part that bothers me (and i dont have the programmer's guide for
> the solos hardware) is that you are watching for the PKT_PCLOSE to be
> sent to the card. shouldnt you be watching for the PKT_PCLOSE to be
> returned from
On Thu, 2012-11-29 at 12:17 -0500, chas williams - CONTRACTOR wrote:
> most atm hardware that i am familiar with, wont deliver vpi/vci data
> unless you are actually trying to receive it. however, this hardware
> is generally doing its reassembly in hardware and delivering aal5
> pdu's and needs t
On Thu, 2012-11-29 at 13:29 -0500, chas williams - CONTRACTOR wrote:
> On Thu, 29 Nov 2012 18:11:48 +
> David Woodhouse wrote:
>
> > We do see the 'packet received for unknown VCC' complaint, after we
> > reboot the host without resetting the card. And as
On Fri, 2012-11-30 at 12:18 +1100, Nathan Williams wrote:
> The customer has confirmed that they haven't seen any panics. I tested
> these patches on OpenWrt with Kernel 3.3.8 and couldn't get a panic:
Thanks.
> I haven't tested these ones:
>
> 230a012 pppoatm: fix missing wakeup in pppoatm_sen
On Thu, 2012-11-29 at 20:38 -0500, Chas Williams (CONTRACTOR) wrote:
> it isnt clear to me that fixes the race entirely either.
> vcc_destroy_socket() and any of the push()/sends()'s are not
> serialized.
> while you may clear the ATM_VF_READY flag, you might not clear it soon
> enough for any part
On Fri, 2012-11-30 at 01:57 +, David Woodhouse wrote:
> I think it's actually fixed for pppoatm by the bh_lock_sock() and the
> sock_owned_by_user() check. As soon as vcc_release() calls lock_sock(),
> pppoatm stops accepting packets.
>
> It should be simple enough to d
On Thu, 2013-02-07 at 18:27 +0100, Joerg Roedel wrote:
>
> Second, I think that it should be a pr_warn instead of a full WARN. When
> IRQ remapping could not be enabled it's most likely because of the BIOS
> or the hardware. So a message in the kernel log will do and the
> backtrace provides no ad
On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote:
> To use another, perhaps more applicable analogy:
>
> If one has the choice to start a new business in the U.S., it
> would be reasonable to do that. There's a lot of supporting
> infrastructure, trust, distribution, standards, enforcement
On Mon, 2013-02-11 at 16:47 +0200, Pekka Enberg wrote:
> On Mon, Feb 11, 2013 at 2:26 PM, Ingo Molnar wrote:
> > IIRC Windows support for kmvtool is work in progress - some
> > patches already got applied.
>
> People are working on SeaBIOS support which is just one part of
> running Windows. But
've occasionally spoken about working around such a
problem by setting a bit to make subsequent faults *silent*. Would that
work?
> What we have to do is stopping DMA transaction
> before DMA-remapping is disabled in 2nd kernel.
The IOMMU is there to stop DMA transactions. That is its *job*. :
On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote:
>
> - DMAR fault messages floods and second kernel does not boot. Recently I
> saw similar report. https://lkml.org/lkml/2013/3/8/120
Right. So the fix for that is to make the subsequent errors silent,
until/unless we actually get a request
On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
> );
> > +
> > + if ((revision == 0x13) && irq_remapping_enabled) {
> > +pr_warn(HW_ERR "This system BIOS has enabled interrupt
> > remapping\n"
> > +"on a chipset that contains an errata making
eam-fixes&id=8e725c7f8a60feaa88edacd4dee2c754d5ae7706
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
On Mon, 2013-03-25 at 09:42 -0700, Roland Dreier wrote:
> Hi Linus,
>
> Please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
> tags/rdma-for-linus
> Vinit Agnihotri (1):
> IB/qib: change QLogic to Intel
> firmware/Makefile
> Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file
> potentially breaking the ABI.
>
> This patch reverts that aspect of the fix as well as reverting the
> firmware name as used in qib.
>
> Reported-by: David Woodhouse
> Signed-off-by:
On Sun, 2013-01-27 at 11:02 -0800, H. Peter Anvin wrote:
> This is intentionally a protocol only patch, which may be possible to
> push into 3.8 as an urgent patch. David, if I understand our
> discussions right it might be better to not export XLF_EFI_HANDOFF_32
> at this time?
That won't stop
dicate that the EFI stub is present and
usable. So please do NOT add it for 32-bit unless you've also merged the
outstanding patches which actually fix it. Or at least marked EFI_STUB
as 'depends on BROKEN'.
Other than that,
Acked-by: David Woodhouse
--
dwmw2
smime.p7s
On Wed, 2013-03-13 at 17:48 +, Jason Cooper wrote:
> From: David Woodhouse
>
> While investigating (ab)use of krealloc, David found this bug. It's
> unlikely to occur, but now we detect the condition and error out
> appropriately.
>
> Signed-off-by: David Woodhou
On Tue, 2012-09-25 at 16:30 +0100, Alan Cox wrote:
> On Tue, 25 Sep 2012 16:09:54 +0100
> David Howells wrote:
>
> >
> > The X.509 certificate has a pair of times in it that delineate the valid
> > period of the cert, and I'm checking that the system clock is within the
> > bounds they define be
in he boot sequence, things *should* have started working. But
they didn't...
Signed-off-by: David Woodhouse
---
Arguably, for the specific case of module signing we shouldn't bother
checking for a current time before the ValidFrom date *at all*. It's
*always* going to be a scr
support entirely.
Some use cases *might* want to check the dates, and should be permitted
to do so. Just don't refuse to even *parse* the key outside its valid
date range... :)
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
If krealloc() returns NULL, it *doesn't* free the original. So any code
of the form 'foo = krealloc(foo, …);' is almost certainly a bug.
Signed-off-by: David Woodhouse
---
drivers/hwmon/pmbus/pmbus_core.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff
ike a classic realloc() usage bug.
Signed-off-by: David Woodhouse
---
kernel/params.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/params.c b/kernel/params.c
index ed35345..53b958f 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -613,10 +613,13 @@ static __mo
On Thu, 2013-03-14 at 17:22 +0100, Alexander Holler wrote:
>
> Agreed (thats what my patch did).
>
> I've introduced a new config option because I don't know if something (a
> use case I don't know) relies on the validity check of the dates in the
> parser. If there currently isn't such a user,
On Thu, 2012-09-13 at 21:02 +0100, Grant Likely wrote:
> In commit 7e30ed6b, "gmux: Add generic write32 function", the new
> gmux_write32() function didn't include the io offset when writing
> registers. This means that backlight update writes never go to the
> right
> place. This patch fixes it.
>
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely
> > wrote:
> >> Some platforms (for instance MacbookPros) have custom backlight drivers
> >> and don't use the integrated i915 bac
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
>
> > Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> > gmux_backlight devices get registered and userspace doesn't know which
> > it should use.
>
On Fri, 2012-09-14 at 14:06 +0100, Grant Likely wrote:
> What patches are you running on top of mainline for the mbp8,3?
A slightly simpler answer: I'm running the Fedora 18 3.6 kernel, with
these two patches backported:
commit f462ed939de67c20528bc08f11d2fc4f2d59c0d5
Author: Matthew Garrett
Dat
On Thu, 2012-10-04 at 21:03 -0700, Divy Le Ray wrote:
>
> > No, it appears David has pulled and pushed out your change.
>
> Great, thanks a lot!
Um, I hadn't. I have now.
--
David WoodhouseOpen Source Technology Centre
david
On Tue, 2012-10-23 at 02:52 -0400, David Miller wrote:
>
> David, if you could review this series I'd really appreciate it.
Will do. I glanced at it last night but need to be in the right frame of
mind for thinking about ATM locking.
I know I have a bottle of vodka *somewhere* around here... I s
On Tue, 2012-10-30 at 20:52 +0100, Krzysztof Mazur wrote:
>
> --- a/net/atm/pppoatm.c
> +++ b/net/atm/pppoatm.c
> @@ -306,12 +306,9 @@ static int pppoatm_send(struct ppp_channel *chan, struct
> sk_buff *skb)
>
> /*
> * It's not clear that we need to bother with using atm_may_se
On Wed, 2012-10-31 at 12:30 +0100, Krzysztof Mazur wrote:
> Yes, original patch had also the same problem with sock_owned_by_user(),
> so I just incorrectly assumed that we can do "goto nospace" after
> pppoatm_may_send(), but ppooatm_may_send() must be the last test.
>
> So I just moved all other
On Wed, 2012-07-11 at 02:25 +0200, Andreas Heider wrote:
> Thanks for adding me, seeing the gmux driver progress is always great.
>
> Regarding the original patch: This is probably only useful when the gmux
> was switched in GRUB and there's already a solution for the resume
> problem in usersp
On Sun, 2012-07-29 at 01:42 +0100, David Woodhouse wrote:
> If I don't hack it to switch the mux to IGD at boot time, I never manage
> to get a sane picture out of the Intel device after switching to it.
> It's late now, but I'll try to get a proper debug log of the wor
On Sun, 2012-07-29 at 09:46 +0200, Andreas Heider wrote:
> Am 29.07.12 03:18, schrieb David Woodhouse:
> > On Sun, 2012-07-29 at 01:42 +0100, David Woodhouse wrote:
> >> If I don't hack it to switch the mux to IGD at boot time, I never manage
> >> to get a sane
On Sun, 2012-07-29 at 20:39 +0100, Matthew Garrett wrote:
>
> And it looks like intel_lvds->edid is only set during
> intel_lvds_init().
> That seems less than ideal. How about something like this entirely
> untested patch?
Not at first attempt. Will poke a little more at it.
http://david.wood
On Sun, 2012-07-29 at 20:39 +0100, Matthew Garrett wrote:
> And it looks like intel_lvds->edid is only set during intel_lvds_init().
> That seems less than ideal. How about something like this entirely
> untested patch?
Actually, it works if I write 'MIGD' first and then 'IGD'. Looks like we
ar
If we've obtained the ROM data through other means (such as from EFI),
we don't want to ignore it just because the IORESOURCE_ROM_SHADOW bit has
got set. This fixes the Radeon ROM handling on my MacBookPro8,3 when booted
via grub1-efi.
Signed-off-by: David Woodhouse
---
This fixes patc
On Sun, 2012-07-29 at 09:46 +0200, Andreas Heider wrote:
> The gmux code you're using is a bit outdated, but if you use
> git://kernel.ubuntu.com/sforshee/linux.git gmux-switcheroo and connect
> an external display (I tested it with a DP one) you should be able to
> boot to DIS and switch to the
On Fri, 2012-10-26 at 13:49 -0700, Linus Torvalds wrote:
> On Fri, Oct 26, 2012 at 5:29 AM, Vinod Koul
> wrote:
> >
> > git://git.infradead.org/users/vkoul/slave-dma.git fixes
>
> git.infradead.org is sick, and is apparently not accepting
> connections...
>
> Can you check whether git-daemon i
ne enough.
Acked-By: David Woodhouse
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
he configured
size by one packet is both harmless and almost never going to happen
since we now limit ourselves to two packets anyway. So:
Acked-By: David Woodhouse
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
ysztof Mazur
> Cc: David Woodhouse
Acked-By: David Woodhouse
But did you spot what's in the end of the context of the first hunk...?
> --- a/net/atm/pppoatm.c
> +++ b/net/atm/pppoatm.c
> @@ -154,6 +154,7 @@ static void pppoatm_unassign_vcc(struct atm_vcc
> *atmvcc)
>
On Tue, 2013-07-09 at 17:18 -0700, Guenter Roeck wrote:
>
> I meant warning as in pr_warn or dev_warn, not WARNING as in traceback.
> Keep in mind that a casual user doesn't expect to see a traceback and will
> tend
> to get alarmed. Several bugs have been filed against this "issue" in various
>
On Tue, 2013-09-10 at 14:43 +0900, Takao Indoh wrote:
> (2013/09/09 18:07), David Woodhouse wrote:
> > If the driver is so broken that it cannot get the device working again
> > after a fault, surely the driver needs to be fixed?
>
> Yes,this problem may be solved by fi
o, aren't there? What about just
writing some fun stuff to a memory BAR and then writing to PCI config to
map that BAR to an address that we can get executed by kernel code?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
27;see' memory pages which belong
to that guest.
> > And there are non-DMA considerations too, aren't there? What about just
> > writing some fun stuff to a memory BAR and then writing to PCI config to
> > map that BAR to an address that we can get executed by kernel code
On Wed, 2013-09-04 at 19:01 +, Matthew Garrett wrote:
> But presumably the guest's view of RAM is what gets written to the BARs?
You're talking about the MMIO BARs of the devices which are given to the
guest, right? The register into which we write the 'ring buffer
address', and for that matte
/linux-mtd.git/commitdiff/d2b1bd1422
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
oing* DMA, seems wrong.
You'll even end up resetting devices just because they have an RMRR,
won't you? (Although I wouldn't lose any sleep over that, I suppose. In
fact it might be a *feature*... :)
--
David WoodhouseOpen Source Technology Centre
david.wood
On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
Setting aside the inevitable whin
On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.
But if I've got device attached to pin 15 of a GPIO controller
, surely that has to be programmed separately from the
On Tue, 2013-10-08 at 19:10 -0700, Brian Norris wrote:
> Hi Linus!
>
> David Woodhouse and I have queued up a few MTD fixes for 3.12. As David seems
> to be MIA again, I am sending the following pull request with his permission.
Not entirely MIA; just still catching up with work and
On Tue, 2013-09-24 at 15:16 +0200, Joerg Roedel wrote:
>
> I am not convinced that this is the right approach. If a device wasn't
> translated by VT-d in the old kernel doesn't mean it will not be
> translated in the new kernel. How about unconditionally resetting all
> PCI busses and/or functions
On Sun, 2012-09-09 at 09:56 -0700, H. Peter Anvin wrote:
>
> > So it should either be start=0xf000 end=0x
> > or it should be start=0xf000 len=0x1000.
>
> I would strongly object to the former; that kind of inclusive ranges
> breed a whole class of bugs by
On Sat, 2012-10-06 at 14:19 +0200, Krzysztof Mazur wrote:
> Now pppoatm_send(), like vcc_sendmsg(), checks for vcc flags that
> indicate that vcc is not ready.
And what locking prevents the flag from being set immediately after we
check it?
--
David Woodhouse
On Tue, 2012-10-09 at 23:26 -0700, Brian Norris wrote:
> I have heuristically determined that all the chips that use
> the new table have ID strings which wrap around after the 6th byte.
I'd be happier if we had confirmation of that from Samsung...
--
dwmw2
smime.p7s
Description: S/MIME crypto
On Tue, 2012-10-09 at 23:39 -0700, Brian Norris wrote:
> I can see if that's possible, but I think it's unlikely. They don't
> even bother following standards (ONFI). Is this an obstacle to
> merging?
No. I already pushed it.
smime.p7s
Description: S/MIME cryptographic signature
On Tue, 2012-10-09 at 10:31 +0200, Lukáš Czerner wrote:
> I am sorry but this reply makes me smile. How can you design a fs
> relying on time attack heuristics to figure out what the proper
> layout should be ? Or even endorse such heuristics to be used in
> mkfs ? What we should be focusing on is
On Fri, 2012-11-30 at 10:53 +0100, Krzysztof Mazur wrote:
> On Fri, Nov 30, 2012 at 08:25:22AM +0000, David Woodhouse wrote:
> > On Fri, 2012-11-30 at 01:57 +0000, David Woodhouse wrote:
> > > I think it's actually fixed for pppoatm by the bh_lock_sock() and the
> >
On Fri, 2012-11-30 at 12:10 +, David Woodhouse wrote:
> In that case I think we're fine. I'll just do the same thing in
> br2684_push(), fix up the comment you just corrected, and we're all
> good.
OK, here's an update to me my patch 8/17 'br2684: don't
On Fri, 2012-11-30 at 18:00 +0100, Krzysztof Mazur wrote:
> On Fri, Nov 30, 2012 at 04:23:46PM +0000, David Woodhouse wrote:
> >
> > +static void br2684_release_cb(struct atm_vcc *atmvcc)
> > +{
> > + struct br2684_vcc *brvcc = BR2684_VCC(atmvcc);
> > +
uld be used by pppoatm.
That one I think *isn't* needed, because we have properly fixed the
races with vcc_destroy_socket(). I just wanted to check you agree...?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
nder EFI doesn't work too well. I have a firmware running
in qemu locally which will let you call SetVirtualAddressMap more than
once, which is a step towards fixing it sanely. It got preempted, but
I'll take another look at it shortly.
--
David Woodhouse
ented
already elsewhere, the PPP channel's ->downl lock protects against the
wakeup happening too soon and effectively being missed.
Signed-off-by: David Woodhouse
Untested.
With this sorted, Acked-By: David Woodhouse vcc;
bh_lock_sock(sk_atm(vcc));
if (sock_owned_by_us
On Fri, 2012-11-09 at 16:30 -0500, David Miller wrote:
> I don't know what to do with this patch because I don't have any
> context whatsoever.
I sent two replies to Krzysztof's series starting with [PATCH v3 0/7]
in Message-Id: <1352240222-363-1-git-send-email-krzys...@podlesie.net>
The first
On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote:
> With this tasklet_schedule() we implement a "spin_lock" here, but in
> this case both conditions (vcc not ready and socket locked) can be
> true for a long time and we can spin here for a long time. I confirmed
> it by reverting patch 1 (a
On Sat, 2012-11-10 at 21:23 +0100, Krzysztof Mazur wrote:
> With this tasklet_schedule() we implement a "spin_lock" here, but in
> this case both conditions (vcc not ready and socket locked) can be
> true for a long time and we can spin here for a long time.
Reading this more carefully this morni
On Sun, 2012-11-11 at 12:04 +0100, Krzysztof Mazur wrote:
> Yes, but socket can be also locked for a long time, vcc_sendmsg() sleeps
> owning socket lock waiting for memory or atm_may_send().
Right. Something like this then, instead of my previous patch 8/7?
Only addresses the sock_owned_by_user(
On Sun, 2012-11-11 at 14:50 +0100, Krzysztof Mazur wrote:
> Looks and works ok after:
> + atmvcc->unlock_cb = pppoatm_unlock_cb;
Heh, yeah. That would probably help :)
Not sure if it's really necessary to optimise out the unneeded wakeups —
I don't think that code path gets exercised very h
On Sun, 2012-11-11 at 17:12 +0100, Krzysztof Mazur wrote:
> It would require using atomic ops because also pppoatm_pop() can
> modify this word. I think it's better to add additional word instead
> of using atomic ops.
Or use the existing flags word, perhaps. Only one bit of which is
actually used
encaps enum - encaps needs only 2 bits,
> but it's ugly.
Yeah, fair enough. It's not the end of the world having it in a separate
word. I was just trying to avoid bloating the structure more than we
needed to.
Acked-by: David Woodhouse for your new
version of patch #6 (returning DROP_P
On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
> This creates quite a few build failures on auto-latest:
>
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `dest
On Wed, 2012-12-26 at 02:44 -0800, David Rientjes wrote:
> I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest
> related to these subsystems and I'm sure it's just because my randconfig
> builds were exposed to this combination solely because of this patch.
Hm, that's an un
On Wed, 2012-12-26 at 14:00 -0800, David Rientjes wrote:
> Umm, you're saying that is legitimate for "make randconfig" done on a
> 32-bit machine to generate 64-bit configurations? The resulting kernel
> cannot be booted.
It has never been expected that a 'randconfig' kernel would actually
boo
On Wed, 2012-12-26 at 14:00 -0800, David Rientjes wrote:
> I do quite a bit of automated config and boot tests to try out
> combinations that others may not have tested when developing their
> code; staging branches such as in tip are interesting to try because
> they haven't yet reached Linus and
On Tue, 2012-12-25 at 22:32 -0800, David Rientjes wrote:
>
> This creates quite a few build failures on auto-latest:
>
> arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> hpet.c:(.text+0x34651): undefined reference to `
On Wed, 2012-12-26 at 17:52 -0800, David Rientjes wrote:
> On Wed, 26 Dec 2012, David Woodhouse wrote:
>
> > Thanks. I'll look into this. I presume it was *always* failing, but
> > nobody happened to come across it because our test coverage of x86
> > config
Signed-off-by: David Woodhouse
---
scripts/checkstack.pl | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index 17e3843..bf7a6af 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -59,6 +59,11 @@ my (@stack, $re, $dre, $x, $xs
ldconfig') before we talk about doing
that though.
Signed-off-by: David Woodhouse
---
Makefile| 3 ++-
arch/x86/Kconfig| 2 +-
arch/x86/Makefile | 4
arch/x86/configs/i386_defconfig | 1 +
4 files changed, 8 insertions(+), 2 deletio
1 - 100 of 2231 matches
Mail list logo
