> assumption that that actually meant they were NOT using GPL symbols.
All symbols in the Linux kernel are to GPL code and all linking dynamic
or otherwise is subject to the GPL licence. That is you need to be able
to show anything non-free linked with it such as a kernel module is not a
derivativ
> +uid=n[:m]Make all files appear to belong to uid n.
> + Useful for e.g. removable media with fstab
> + options 'user,uid=useruid'. The optional second
> + uid m is actually written to the file
On Tue, 31 Jan 2012 09:48:44 +0100
Sjur Brændeland wrote:
> Add a character device implementation for the SHM stream channels.
> The character device provides asynchronous IO and ring-buffer handling.
> The device copies data directly from the Shared Memory area into
> user-land buffers.
What is
> kernel-2.6.32-220.17.1.el6.x86_64
> kernel-2.6.32-220.23.1.el6.x86_64
> kernel-2.6.32-279.1.1.el6.x86_64
You need to contact your vendor for RHEL based kernels - they are
sufficiently different to upstream and from a long time back (with
backports).
This is the wrong place unless you can duplic
On Wed, 01 Aug 2012 17:24:33 -0400
Mark Hounschell wrote:
> What would happen if NVIDIA used this define in their proprietary driver? I
Ask a lawyer but I believe Nvidia has more sense than that both
politically and legally. They walk a very fine line as it is (and IMHO
the wrong side of it but
On Mon, 30 Jul 2012 14:21:33 -0700
John Johansen wrote:
> On 07/30/2012 09:58 AM, Kees Cook wrote:
> > The core ptrace access checking routine already holds the task lock,
> > so there is no need to use get_task_comm() which just tries to take the
> > lock again. Drop its use and access current->
On Sun, 29 Jul 2012 20:40:22 +0800
Fengguang Wu wrote:
> Hi,
>
> This is probably a rather old bug, triggered while doing randconfig
> boot tests in kvm:
I'm not sure testing old devices with no safe probe method is useful in
this context ?
Alan
--
To unsubscribe from this list: send the line
On Fri, 27 Jul 2012 18:42:53 -0400
Len Brown wrote:
> From: Len Brown
>
> The APM idle feature to call into the BIOS
> is known to break some machines, and it has dubious benefit
> on the (decades old) machines it doesn't break.
You mean "doesn't fit my current plan" I think. I see almost no b
o longer assume that each byte
> will only take up one byte in the line discipline. Instead, it will
> make an overly conservative estimate that each byte will take up
> three bytes in the line discipline when PARMRK is set.
>
> Signed-off-by: Jaeden Amero
What a fun corner case
> +enum {
> + VMCI_SUCCESS_QUEUEPAIR_ATTACH = 5,
> + VMCI_SUCCESS_QUEUEPAIR_CREATE = 4,
> + VMCI_SUCCESS_LAST_DETACH= 3,
> + VMCI_SUCCESS_ACCESS_GRANTED = 2,
> + VMCI_SUCCESS_ENTRY_DEAD = 1,
We've got a nice collection of Linux error codes than you, and it
On Thu, 26 Jul 2012 14:28:07 -0700
Greg KH wrote:
> On Thu, Jul 26, 2012 at 10:23:13PM +0100, Alan Cox wrote:
> > On Thu, 26 Jul 2012 12:08:14 -0700
> > Greg KH wrote:
> >
> > > tty: Move the handling of the tty release logic
> >
> > Can we lo
On Thu, 26 Jul 2012 12:08:14 -0700
Greg KH wrote:
> tty: Move the handling of the tty release logic
Can we lose that one specifically. I've chased down Ian Abbotts problem
and replicated it and that is the offending patch not the lock localise
(which still needs to be kept out as it depend
> The following commands were marked as "safe":
>
> Clear Breakpoint
> Enable Breakpoint
> Disable Breakpoint
> Display exception frame
> Stack traceback
This is sufficient to steal cryptographic keys in many environments. In
fact you merely need two or three breakpo
On Thu, 26 Jul 2012 08:51:27 +1000
Stephen Rothwell wrote:
> Hi Greg, Alan,
>
> [Sorry, Alan, I forgot to cc you the first time around.]
>
> On Fri, 20 Jul 2012 13:33:49 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the tty tree, today's linux-next build (x86_64
> > allmodconfig) faile
> > if (serial->type->set_termios) {
> > - tty->termios->c_cflag = cflag;
> > - tty_termios_encode_baud_rate(tty->termios,
> > baud, baud);
> > + tty->termios.c_cflag = cflag;
> > +
> > tty_termios_encode_baud_rate(&tty->termios, bau
Commit-ID: d6250a3f12edb3a86db9598ffeca3de8b4a219e9
Gitweb: http://git.kernel.org/tip/d6250a3f12edb3a86db9598ffeca3de8b4a219e9
Author: Alan Cox
AuthorDate: Wed, 25 Jul 2012 16:28:19 +0100
Committer: H. Peter Anvin
CommitDate: Wed, 25 Jul 2012 08:35:38 -0700
x86, nops: Missing break
On Wed, 25 Jul 2012 14:31:30 +0400
Vladimir Davydov wrote:
> On 07/24/2012 04:44 PM, Alan Cox wrote:
> >> This approach does not need any kernel support (except for the
> >> /proc/cpuinfo filtering). Does this address the issues you have?
> > You can do the /proc/cpui
On Mon, 23 Jul 2012 15:51:03 +0100
Ian Abbott wrote:
> On 2012-07-21 23:41, Alan Cox wrote:
> > On Fri, 20 Jul 2012 23:07:06 +0100
> > Ian Abbott wrote:
> >
> >> I'm getting an Oops in the linux-next tree today after the merge
> >> of the remote-tr
> This approach does not need any kernel support (except for the
> /proc/cpuinfo filtering). Does this address the issues you have?
You can do the /proc/cpuinfo filtering in user space too
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
On Tue, 24 Jul 2012 18:56:30 +0800
tingwei liu wrote:
> On Tue, Jul 24, 2012 at 6:53 PM, Alan Cox wrote:
> > On Tue, 24 Jul 2012 18:39:20 +0800
> > tingwei liu wrote:
> >
> >> Suse 11 SP1 kernel panic。
> >>
> >> I can't debug it without deb
On Tue, 24 Jul 2012 18:39:20 +0800
tingwei liu wrote:
> Suse 11 SP1 kernel panic。
>
> I can't debug it without debuginfo. Who can give me a link of sels
> 2.6.32.12-0.7.default.debug or give some advise.
For distribution kernels (which tend to contain lots of other patches)
it is best to talk t
> So actually, making it straightforward to disable CPUID feature bits
> just for every whim is the bug.
Sometimes its needed to make stuff work. Expecting user space to go
digging in odd places isn't good either but exposing *both* true/apparent
cpuid bits might not be a bad idea.
> I'd like to
> Sorry for the late reply. I'm using Gentoo Linux built from source
> for ~amd64 (unstable).
Thanks
> The crashes all seem to be while the devfs process is running. One
> thing strange I noticed is that I'm using Gentoo's "OpenRC" boot
> system, but the crashes only occur when it is configure
On Sun, 24 Jun 2012 23:49:22 +0200
Jiri Slaby wrote:
> On 06/22/2012 05:38 PM, Alan Cox wrote:
> > Bits noticed doing the termios conversion
> >
> > Signed-off-by: Alan Cox
> > ---
> >
> > drivers/usb/serial/metro-usb.c |8 +---
> >
> What I meant is: although these keycodes are already sent by acpi
> driver code, is it up to userspace to figure out which backlight
> driver to use, or should the kernel modify brightness in psb-bl
> directly ?
I'm not sure how its all glued together. I need to find out some day !
--
To unsubsc
On Mon, 23 Jul 2012 11:54:14 +1000
Anton Blanchard wrote:
>
> udev now requires CONFIG_DEVTMPFS so make it default to y.
>
> I noticed this when booting a ppc64 pseries_defconfig on Fedora 17
> and it paniced because it couldn't mount the root device.
NAK. As Linus keeps saying we shouldn't go
On Fri, 20 Jul 2012 23:07:06 +0100
Ian Abbott wrote:
> I'm getting an Oops in the linux-next tree today after the merge of the
> remote-tracking branch 'tty/tty-next'. I bisected it down to commit
> 36b3c070d2346c890d690d71f6eab02f8c511137 in
> git://git.kernel.org/pub/scm/linux/kernel/git/ne
> Today's build failed because there's a new user in the MIPS tree:
> arch/mips/cavium-octeon/serial.c
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/6739341/
The version in the tree I have registers a platform device rather than
calling into 8250 directly. That appears to be rather better m
On Fri, 20 Jul 2012 20:45:25 +0800
Zhao Chenhui wrote:
> Add IDE support for MPC85xxCDS.
>
> Signed-off-by: Zhao Chenhui
> ---
> arch/powerpc/configs/mpc85xx_defconfig |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig
> b/ar
On Fri, 20 Jul 2012 16:32:45 +0300
Dan Carpenter wrote:
> We're trying to save the termios state and we need to allocate a buffer
> to do it. Smatch complains that the buffer is leaked at the end of the
> function.
>
> Signed-off-by: Dan Carpenter
Acked-by: Alan Cox
On Fri, 20 Jul 2012 10:06:34 +0300
Dan Carpenter wrote:
> We sometimes pass NULL pointers to free_tty_struct(). One example where
> it can happen is in the error handling code in pty_common_install().
>
> Signed-off-by: Dan Carpenter
Acked-by: Alan Cox
We probably shouldn&
> > kconfig already spits out warnings for symbols being selected that
> > don't exist.
>
> We can make these even bigger :-) Add lots of stars (*) around them!
Make oldconfig already handles this just fine
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> Well, yes. I was thinking it would be more like:
>
> distro/Kconfig.fedora
> menuconfig FEDORA
> if FEDORA
> config FEDORA_16
> select WHATEVER
> config FEDORA_17
Nope you need
distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm
boards)/Kconf
> Caused by commit adc8d746caa6 ("tty: move the termios object into the
> tty"). Grep and build testing are your friends ...
>
> I have used the tty tree from next-20120712 again for today.
Doh, patch sent
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wed, 18 Jul 2012 16:30:59 -0400
Terry Phelps wrote:
> On Wed, Jul 18, 2012 at 12:14 PM, Alan Cox wrote:
> >> If I should be posting my question to somewhere other than the
> >> linux-kernel mailing list, please advise me where that might be. It
> >> sure look
> If I should be posting my question to somewhere other than the
> linux-kernel mailing list, please advise me where that might be. It
> sure looks like something in the kernel isn't working properly
> somewhere.
If you can duplicate the problem with an *upstream* kernel then yes it
is. If you onl
> I'm wondering if the gma_power_init call can be moved up before
> chip_setup is called. Seems so, but I thought I would ping you to see
> if you've seen this already.
Fixed in the patches that went to Linus.
I don't have the ACPI backlight working on a lot of systems and don't
know why to be h
On Tue, 17 Jul 2012 08:45:29 -0700
Greg KH wrote:
> On Tue, Jul 17, 2012 at 01:45:06PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the tty tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/tty/tty_ioctl.c: In function 'set_sgfla
On Tue, 17 Jul 2012 13:45:06 +1000
Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the tty tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/tty/tty_ioctl.c: In function 'set_sgflags':
> drivers/tty/tty_ioctl.c:741:9: error: request for member 'c_ifla
> The reporting tool(Abrt) complicated the reporting and kerneloops.org
> DNS still doesn't associated with the required ip address. ( Arjan? )
Anton - just talk to the kernel.org maintainers and get oops.kernel.org
set up somewhere and be done with it.
> - Starting from the Fedora 18 kernel
> Right, I would say that with any CPU core more powerful than this one
> or with more than a few of these, you will also have trouble coming
> up with workloads that really require the CPU performance but don't
> also require a 64 bit virtual address space in either user space
> or kernel.
There
On Mon, 16 Jul 2012 13:44:32 -0700
Linus Torvalds wrote:
> On Mon, Jul 16, 2012 at 12:42 PM, Dave Airlie wrote:
> >
> > Sorry been travelling and a bit neglectful of some of Alan's
> > patches,
>
> I actually took the three Alan sent me already, exactly because they
> seemed harmless and I didn
> Select the profile and then fixup the config the normal way.
>
> If what the admin wants is incompatible with the profile, admin doesn't
> select the profile.
Thats ugly - "distro except..." is a standard thing you ask users to do
for debugging.
However providing you separate the initial profi
> But go forth and test. Make sure it's all good. Because I really wish
> I won't have to do an -rc8.
Crahses and burns on Intel Poulsbo systems with a blank screen.
Fortunately I know why - your tree is short the patch for it that went to
Dave some time before -rc7. I'm just testing that v -rc7 n
On Fri, 13 Jul 2012 14:13:45 +1000
Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/char/mwave/mwavedd.c: In function 'register_serial_portandirq':
> drivers/char/mwave/mwavedd.c:472:2: error: impli
On Thu, 12 Jul 2012 10:48:44 -0700
"Luis R. Rodriguez" wrote:
> From: "Luis R. Rodriguez"
>
> The anti-tivoization clauses must go if we want this license
> to be ever considered for usage with the Linux kernel.
> This patch removes that entire section.
The kernel license won't be changing any
> I suppose at a later date we could turn that into a union with a short
> name like u (so comedidev->pcidev would become something like
> comedidev->u.pcidev), which would allow us to stick a 'struct
> usb_interface *' or some other hardware device wrapper struct pointer in
> the same hole. (Mayb
On Thu, 12 Jul 2012 11:54:28 +0545
Devendra Naga wrote:
> TCB has kcalloc' ed so no need to call memset again on it.
>
> Signed-off-by: Devendra Naga
> ---
> drivers/staging/et131x/et131x.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/staging/et131x/et131x.c b/drivers/
> What if they add 64-bit ARM support to arch/x86? AFAIK some of the
> machines are going to be basically PCs, including legacy I/O, ACPI
> and UEFI, so they are much closer to that than they are to anything
> in arch/arm. The instruction set of course is different, but you
> already said that this
> In the AArch32 kernel port many implementation decisions newer
> architectures were made in a way that preserves backwards compatibility
> to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> use). But keeping the same decisions in AArch64 is wrong.
Same argument as x86-32
On Tue, 10 Jul 2012 12:10:27 +0200
Ortwin Glück wrote:
> The LMS daemon expects a /sys/modules/mei/version file with, a four
> digit version number.
>
> see
> http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/
Just get them to fix the userspace. I thoug
> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific
> workarounds? And Panda is not the only device with this issue.
Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.
So yo
> I think the main strategy should be to spot duplicate code early
> and make sure we deal with it individually. Examples for this are
> probably the implementations for kvm and perf, which largely deal
> with the same hardware on both architectures. Those definitely must
> not get duplicated into
> > These are the same reasons the x86_64 people gave and regretted later.
>
> I would not compare the x86_64 extension to the AArch64 architecture.
It's not an architecture specific observation. I was just observing that
you were following a pattern which in all other cases ended up with a
merg
> The patch will not fix the underlying problem, but just make it behave
> more like it was and allow partial message reads. This is a years old
> problem, the net is full of bugreports of stuff going wrong with
> running dd bs=1 on /proc/kmsg. It is a really stupid idea, and can not
> work for man
> 1. The AArch64 architecture is significantly different from AArch32 (the
> official name of the 32-bit ARM architecture), it is not an extension.
> It has a new exception model, new instruction set (even the register
> names are different), new C ABI, PCS. It has a hardware compat mode but
> tha
> arch/x86/include/asm/atomic64_32.h |1 +
> arch/x86/include/asm/atomic64_64.h |1 +
> arch/xtensa/kernel/syscall.c|2 +-
This looks odd to say the least ?
The only other question I'd ask is given that ppc and x86 have both done
32/64bit
On Fri, 6 Jul 2012 20:45:44 +0300
Jukka Ollila wrote:
> Hello,
>
> A few days ago I filed a kernel regression report concerning a change
> in /proc/kmsg behaviour with short reads:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=44211
>
> The comments suggest that this is probably intentional,
> > From what I've seen its helped make binary
> > module abusers more cautious.
>
> Those not using _GPL exports?
In general. To be honest there is very little binary only stuff left now
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
On Tue, Feb 26, 2008 at 06:04:51PM +0100, Krzysztof Halasa wrote:
> Actually I think the _GPL exports are really harmful - somebody
> distributing a binary module may claim he/she doesn't violate the GPL
> because the module uses only non-GPL exports. OTOH GPL symbols give
They can claim that anyw
> I agree. I [obviously] missed this when I ack'd, mainly ack'ing the
> overall change.
>
> BIOS certainly may modify that PCI config register, but that's before
> the kernel boots. So, using pdev->class is fine.
I don't think the resume quirk is needed either as the core PCI
save/restore cod
> The general idea: A daemon running in user space monitors input data
> from an accelerometer. When the daemon detects a critical condition,
That sounds like a non starter. What if the box is busy, what if the
daemon or something you touch needs memory and causes paging ?
Given the accelerometer
> I don't know who told you that or why, but it's obvious nonsense, as this
> issue shows. Exports should be marked GPL if and only if they cannot be used
> except in a derivative work. If it is possible to use them without taking
> sufficient protectable expression, they should not be marked GPL.
On Mon, Feb 25, 2008 at 10:09:03PM +0200, Adrian Bunk wrote:
> Being able to sue someone who has so many lawsuits that there's anyway
> no money left for me sounds like a bad compensation for serving a few
> years in jail... [1]
If the FSF wrote the code then he should ask the FSF, that seems si
On Mon, Feb 25, 2008 at 09:27:10PM +0200, Adrian Bunk wrote:
> > As I understand it if Vladis wants to submit his own change to the symbol
> > thats up to him, and he'll be liable for any fallout with the FSF, or
> > harm to Linux resulting, so long he's the one who signs it off.
>
> Why isn't any
> The reason I added GPL is not because of some idea that this is all
> "chummy" with the kernel. But because I derived the mcount code from
> glibc's version of mcount. Now you may argue that glibc is under LGPL
> and a non-GPL export is fine. But I've been advised that if I ever take
> code f
> === after conversion
> struct bus_master_interface *interface;
> while (interface->ack != OK) {
> delay(a short while);
> rmb();
> [ after X loops device changes interface->ack by dma ]
> };
>
> All I need is for the read of interface->ack in the loop not to be optimise
> From the patch description it can't be told whether the patch itself is
> correct and only the patch description is bogus...
zero length PRD misparsing. If I remember rightly old IDE never generates
64K PRD slots because other hardware can't handle it either (CS5520/30
etc)
--
To unsubscribe fro
On Sun, 24 Feb 2008 10:12:41 -0500 (EST)
"Robert P. J. Day" <[EMAIL PROTECTED]> wrote:
>
> Given that the removal of this driver has been under discussion for
> over a year:
>
> http://lkml.org/lkml/2006/10/26/231
>
> it would seem time to get rid of it.
NAK - not until a replacement driver
O> I don't see the connection between (no-)smp and ata. Something with
> interrupt routing/IPI, missing irq ack? Booting another !SMP kernel
> works fine. The problem also exists in 2.6.24-rc2.
Almost certainly interrupt routing try smp but with noapic and see if it
fails as well ?
--
To unsubscri
On Sat, 23 Feb 2008 00:05:25 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Feb 2008 20:11:01 +0000 Alan Cox <[EMAIL PROTECTED]> wrote:
>
> >
> > Just wrap this one in a lock_kernel. As I understand it there is no M68K
> > SMP anyway.
> &g
Already patched in my tree
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> At some point checkpatch.pl would need to be updated to know about this
> exception too, that would be the next step.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Alan Cox <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscr
> Either the test of port->tty here is unneeded:
>
> if (port->tty)
>port->tty->low_latency = low_latency;
>
> ...or the lack of test of port->tty here is a mistake:
>
>edge_set_termios (port, port->tty->termios);
Interesting - so coverity doesn't understand the BKL. It
On Fri, 22 Feb 2008 01:05:26 +0100
Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
> Jeff Garzik <[EMAIL PROTECTED]> writes:
>
> > If a driver is full of lines of length >80, that's a problem.
>
> I'm not sure.
> We all have more than 80-chars wide displays for years, don't we? The
Even a vt132 ser
On Fri, 22 Feb 2008 09:48:28 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
> > Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
>
&
> Actually I switched 64bit over to trust e820 completely and not
> reserve 640k-1MB explicitly some time ago
> and AFAIK there hasn't been any reports that it causes problems.
>
> So presumably trusting e802 is ok on modern systems (2003+)
Apparently so - at least 64bit capable ones. We do still
> Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
> Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Vomitted-upon-by: Alan Cox <[EMAIL PROTECTED]>
> - if ((pdev->class >> 8) == PC
On Thu, 21 Feb 2008 20:02:55 -0500
Pavel Roskin <[EMAIL PROTECTED]> wrote:
> Hello!
>
> What are the chances that incorrect tainting of ndiswrapper will be
> fixed in 2.6.25? I'm worried that it still hasn't happened in the
> mainline repository. It's unfortunate to see that a long discussion
>
> > I've added locks in my test tree and now I've finally got -mm to build
> > will do some testing then push more stuff upstream
>
> Thanks. At the tty layer that was probably me.
> Most of the instances already appear to be nested in some other kind of
> locking, but that doesn't make no additi
> I'd been meaning to ask this. So the machines you have which don't
> describe 0xf as reserved also don't describe it as RAM? (I guess
> it's either a hole in the table or one of the other e820 types).
Making 0xf bus addresses RAM is probably a bad idea anyway. Most OS's
treat the E820 ma
> developing is entirely wrong. Oh well. Mind you, providing a
> write_room function is NOT a real solution; it merely reduces the
> condition to a usually-winnable race. (Ironically, when I back-ported
> the 2.6 driver, I excluded its new write_room function. Mistake.)
What race do you see le
On Thu, 21 Feb 2008 14:58:29 +1100
Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Alan Cox writes:
>
> > For some weird reason I can't ascertain (translation "I think its
> > broken") the viocons driver calls directly into the n_tty ldisc code even
> &g
> This is unfortunately very low on the priority stack. I was a bit
> surprised when it went in, honestly, since I hadn't gotten any "it
> works" test reports yet... but that's my fault for not keeping akpm up
> to date.
>
> We'll want to revert this for 2.6.25 release, if it doesn't get fixe
On Wed, 20 Feb 2008 16:22:29 -0500
"John Stoffel" <[EMAIL PROTECTED]> wrote:
>
> Alan> Basically wrap it in lock_kernel where it is hard to prove the
> Alan> locking is ok.
>
> I've got cyclades cards, both ISA and Serial. Do you want/need any
> specific tests? Or should I just send you (or yo
Historically tty->pgrp and friends were pid_t and the code "knew" they
were safe. The change to pid structs opened up a few races and the
removal of the BKL in places made them quite hittable. We put tty->pgrp
under the ctrl_lock for the tty.
Signed-off-by: Alan Cox <[EMAIL P
Take the lock in usb-serial instead. As it relies on the BKL internally
we can't push it any deeper yet.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/usb/serial/usb-serial.c
linux-2.6
Instead of checking for the BKL in these methods, take it ourselves. That
avoids propogating it into the serial drivers and we can then fix them
later on.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-r
Russell King noticed this one: We have to avoid replacing B0 when we pick
a baud rate for a "hung up" port. Ugly but the proper fix is in the tty
layer and means changing the tty<->serial interfaces so we will defer
that for now.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]&g
Just the modem bits this time
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/crisv10.c
linux-2.6.25-rc2-mm1/drivers/serial/crisv10.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/cri
We try and write the correct speed back but the serial midlayer already
mangles the speed on us and that means if we request B0 we report back
B9600 when we should not. For now we'll hack around this in the drivers
and serial code, pending a better long term solution.
Signed-off-by: Ala
Noticed while auditing the code for the BKL elimination project
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/68360serial.c
linux-2.6.25-rc2-mm1/drivers/serial/68360se
Three things here
- Remove softcar handler
- Correct termios change detection logic
- Wrap break/ioctl in lock_kernel ready to drop it in the caller
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/d
big diff
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c
linux-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c2008-02-19
As these are quite complex I've simply pushed the BKL down into the ioctl
handler not tried to do anything neater.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink.c
linux
For some weird reason I can't ascertain (translation "I think its
broken") the viocons driver calls directly into the n_tty ldisc code even
if another ldisc is in use. It'll probably break if you do that but I'm
just fixing the locking and adding a comment that its horked.
Wrap the ioctl handler, and in this case the break handler also in the
BKL. Remove bogus softcar handlers.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/sx.c
linux-2.6.25-rc2-mm1/driver
Remove broken softcar functions, wrap ioctl handler in BKL
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/stallion.c
linux-2.6.25-rc2-mm1/drivers/char/stallion.c
--- linux.vanilla-2.6.
Lock the ioctl handlers and remove bogus softcar handling.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/specialix.c
linux-2.6.25-rc2-mm1/drivers/char/specialix.c
--- linux.vanilla-2.6.
Kill the softcar handlers again, wrap the ioctl handler in the BKL
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.25-rc2-mm1/drivers/char/serial167.c
linux-2.6.25-rc2-mm1/drivers/char/serial167.c
--- linux.v
901 - 1000 of 5738 matches
Mail list logo
