twitter: linux.kernel - 26 new messages in 12 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: [NET]: da.s_net not copied but assigned to itself in aarp_rcv()
http://groups.google.com/group/linux.kernel/t/164f6bd8b63f7e7c?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 1:50 am
From: David Miller

From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Thu, 14 Jan 2010 19:00:01 -0200

> Em Thu, Jan 14, 2010 at 09:32:11PM +0100, Roel Kluin escreveu:
>> da.s_net was not copied but assigned to itself.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>
> Looks right, must be there for ages...
>
> Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Applied, please always CC: on networking patches.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: intermittent failure to power down with 2.6.33-rc3
http://groups.google.com/group/linux.kernel/t/84fe7fe34d3a1e39?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 1:50 am
From: Oliver Neukum

Hi,

I am seeing an intermittent failure to power down on this laptop. It's
a regression. It does not depend on a shutdown vs. STD. I haven't
observed a failure to reboot.

Regards
Oliver

# dmidecode 2.10
SMBIOS 2.5 present.
41 structures occupying 1870 bytes.
Table at 0x000FCEC0.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: 202
Release Date: 09/15/2008
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 1024 kB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Targeted content distribution is supported
BIOS Revision: 2.2
Firmware Revision: 32.1

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: ASUSTeK Computer Inc.
Product Name: M70Vn
Version: 1.0
Serial Number: 100233070004
UUID: 0069792B-F116-DE81-32F2-00248C745CDB
Wake-up Type: Power Switch
SKU Number:
Family:

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: ASUSTeK Computer Inc.
Product Name: M70Vn
Version: 1.0
Serial Number: BSN12345678901234567
Asset Tag: ATN12345678901234567
Features:
Board is a hosting board
Board requires at least one daughter board
Board is replaceable
Location In Chassis: MIDDLE
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: ASUSTeK Computer Inc.
Type: Notebook
Lock: Not Present
Version: 1.0
Serial Number: CSN12345678901234567
Asset Tag: ATN12345678901234567
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Other
Security Status: Other
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
Socket Designation: Socket 478
Type: Central Processor
Family: Core 2 Duo
Manufacturer: Intel
ID: 76 06 01 00 FF FB EB BF
Signature: Type 0, Family 6, Model 23, Stepping 6
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (Fast floating-point save and restore)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Hyper-threading technology)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz
Voltage: 1.1 V
External Clock: 267 MHz
Max Speed: 2533 MHz
Current Speed: 2533 MHz
Status: Populated, Enabled
Upgrade: Socket 478
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0007
L3 Cache Handle: Not Provided
Serial Number: PSN12345678901234567
Asset Tag: PATN1234567890123456
Part Number: PPN12345678901234567
Core Count: 2
Core Enabled: 2
Thread Count: 2
Characteristics:
64-bit capable

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Other
Installed SRAM Type: Other
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Data
Associativity: 8-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
Socket Designation: L1-Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 64 kB
Maximum Size: 64 kB
Supported SRAM Types:
Other
Installed SRAM Type: Other
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Instruction
Associativity: 8-way Set-associative

Handle 0x0007, DMI type 7, 19 bytes
Cache Information
Socket Designation: L2-Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 6144 kB
Maximum Size: 6144 kB
Supported SRAM Types:
Other
Installed SRAM Type: Other
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: Other

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3401
Internal Connector Type: None
External Reference Designator: LAN
External Connector Type: RJ-45
Port Type: Network Port

Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4501
Internal Connector Type: None
External Reference Designator: VGA
External Connector Type: DB-15 female
Port Type: Video Port

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5201
Internal Connector Type: None
External Reference Designator: USB1
External Connector Type: Access Bus (USB)
Port Type: USB

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5201
Internal Connector Type: None
External Reference Designator: USB2
External Connector Type: Access Bus (USB)
Port Type: USB

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4800
Internal Connector Type: None
External Reference Designator: HDMI
External Connector Type: Other
Port Type: Other

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5101
Internal Connector Type: None
External Reference Designator: SATA 1
External Connector Type: SAS/SATA Plug Receptacle
Port Type: SATA

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4202
Internal Connector Type: None
External Reference Designator: FlashCard
External Connector Type: Other
Port Type: Other

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4301
Internal Connector Type: None
External Reference Designator: ExpressCard
External Connector Type: Other
Port Type: Other

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6601
Internal Connector Type: None
External Reference Designator: eSATA
External Connector Type: SAS/SATA Plug Receptacle
Port Type: SATA

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3703
Internal Connector Type: None
External Reference Designator: Audio Out
External Connector Type: Mini Jack (headphones)
Port Type: Audio Port

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3801
Internal Connector Type: None
External Reference Designator: Mic In
External Connector Type: Mini Jack (headphones)
Port Type: Audio Port

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2502
Internal Connector Type: None
External Reference Designator: USB3
External Connector Type: Access Bus (USB)
Port Type: USB

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4203
Internal Connector Type: None
External Reference Designator: 1394
External Connector Type: IEEE 1394
Port Type: Firewire (IEEE P1394)

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5401
Internal Connector Type: None
External Reference Designator: DockPort
External Connector Type: Other
Port Type: Other

Handle 0x0016, DMI type 9, 13 bytes
System Slot Information
Designation: PEG
Type: x16 PCI Express
Current Usage: In Use
Length: Short
ID: 0
Characteristics:
3.3 V is provided

Handle 0x0017, DMI type 9, 13 bytes
System Slot Information
Designation: PCIE1
Type: 64-bit PCI Express
Current Usage: In Use
Length: Short
ID: 1
Characteristics:
3.3 V is provided
PME signal is supported

Handle 0x0018, DMI type 9, 13 bytes
System Slot Information
Designation: PCIE2
Type: x1 PCI Express
Current Usage: Available
Length: Short
ID: 2
Characteristics:
3.3 V is provided
PME signal is supported

Handle 0x0019, DMI type 9, 13 bytes
System Slot Information
Designation: PCIE3
Type: x1 PCI Express
Current Usage: Available
Length: Short
ID: 3
Characteristics:
3.3 V is provided
PME signal is supported
Hot-plug devices are supported

Handle 0x001A, DMI type 10, 6 bytes
On Board Device Information
Type: Video
Status: Enabled
Description: Gfx Card

Handle 0x001B, DMI type 10, 6 bytes
On Board Device Information
Type: Ethernet
Status: Enabled
Description: NIC

Handle 0x001C, DMI type 10, 6 bytes
On Board Device Information
Type: Sound
Status: Enabled
Description: Audio Codec

Handle 0x001D, DMI type 10, 6 bytes
On Board Device Information
Type: SATA Controller
Status: Enabled
Description: SATA Controller

Handle 0x001E, DMI type 10, 6 bytes
On Board Device Information
Type: Other
Status: Enabled
Description: 1394/FlashCardReader

Handle 0x001F, DMI type 13, 22 bytes
BIOS Language Information
Installable Languages: 1
en|US|iso8859-1
Currently Installed Language: en|US|iso8859-1

Handle 0x0020, DMI type 16, 15 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2

Handle 0x0021, DMI type 19, 15 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x000FFFFFFFF
Range Size: 4 GB
Physical Array Handle: 0x0020
Partition Width: 0

Handle 0x0022, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0020
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: SODIMM
Set: None
Locator: SODIMM0
Bank Locator: BANK0
Type: DDR2
Type Detail: Synchronous
Speed: 800 MHz
Manufacturer: N/A
Serial Number: N/A
Asset Tag: N/A
Part Number: N/A

Handle 0x0023, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0007FFFFFFF
Range Size: 2 GB
Physical Device Handle: 0x0022
Memory Array Mapped Address Handle: 0x0021
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown

Handle 0x0024, DMI type 17, 27 bytes
Memory Device
Array Handle: 0x0020
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 2048 MB
Form Factor: SODIMM
Set: None
Locator: SODIMM1
Bank Locator: BANK1
Type: DDR2
Type Detail: Synchronous
Speed: 800 MHz
Manufacturer: N/A
Serial Number: N/A
Asset Tag: N/A
Part Number: N/A

Handle 0x0025, DMI type 20, 19 bytes
Memory Device Mapped Address
Starting Address: 0x00080000000
Ending Address: 0x000FFFFFFFF
Range Size: 2 GB
Physical Device Handle: 0x0024
Memory Array Mapped Address Handle: 0x0021
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown

Handle 0x0026, DMI type 22, 26 bytes
Portable Battery
Location: In the back
Manufacturer: AS011OM33F
Manufacture Date: 09/03/12
Serial Number: 4788
Name: M70--26
Chemistry: Other
Design Capacity: 5060 mWh
Design Voltage: 14800 mV
SBDS Version: SMART Ver 0123
Maximum Error: Unknown
OEM-specific Information: 0x00000000

Handle 0x0027, DMI type 200, 27 bytes
OEM-specific Type
Header and Data:
C8 1B 27 00 01 02 03 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00
Strings:
ASUSTeK Computer Inc.
Notebook
1.0

Handle 0x0028, DMI type 127, 4 bytes
End Of Table
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Changelog quality
http://groups.google.com/group/linux.kernel/t/9853dfc4cf6692c8?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Jan 15 2010 1:50 am
From: Pekka Enberg

Hi Julia,

On Fri, Jan 15, 2010 at 11:43 AM, Julia Lawall <julia@diku.dk> wrote:
>> If you want more clear markers around the script so you can skim
>> past it more efficiently when reading the commit message, then ask
>> for that.
>
> If there were markers that would cause tools to hide some information
> under a +, that would be great. Sometimes I have simplified a script
> beyond what would really be reusable just to not create an over-large
> changelog. I hope that the simplified version is at least understandable,
> so that the reader can get an idea of what considerations went into the
> change, but I recall in one case having messed up on that as well, and
> ended up with something that really gave no information whatsoever.

It seems to me that the scripts are kernel specific so why don't we
put those useful scripts _within_ the kernel source tree and introduce
a "make coccinelle-check" target?

Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Fri, Jan 15 2010 1:50 am
From: Julia Lawall

> If you want more clear markers around the script so you can skim
> past it more efficiently when reading the commit message, then ask
> for that.

If there were markers that would cause tools to hide some information
under a +, that would be great. Sometimes I have simplified a script
beyond what would really be reusable just to not create an over-large
changelog. I hope that the simplified version is at least understandable,
so that the reader can get an idea of what considerations went into the
change, but I recall in one case having messed up on that as well, and
ended up with something that really gave no information whatsoever.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Fri, Jan 15 2010 2:10 am
From: Julia Lawall

On Fri, 15 Jan 2010, Pekka Enberg wrote:

> Hi Julia,
>
> On Fri, Jan 15, 2010 at 11:43 AM, Julia Lawall <julia@diku.dk> wrote:
> >> If you want more clear markers around the script so you can skim
> >> past it more efficiently when reading the commit message, then ask
> >> for that.
> >
> > If there were markers that would cause tools to hide some information
> > under a +, that would be great. ï¿½Sometimes I have simplified a script
> > beyond what would really be reusable just to not create an over-large
> > changelog. ï¿½I hope that the simplified version is at least understandable,
> > so that the reader can get an idea of what considerations went into the
> > change, but I recall in one case having messed up on that as well, and
> > ended up with something that really gave no information whatsoever.
>
> It seems to me that the scripts are kernel specific so why don't we
> put those useful scripts _within_ the kernel source tree and introduce
> a "make coccinelle-check" target?

Indeed, perhaps a solution that would satisfy everyone would be to make a
place for scripts, perhaps with subdirectories for various tools, and then
when one submits a patch for tool X, one could then submit the script at
the same time (if it wasn't there already) and just refer to the script
that was used. That way, if someone wants to know more about how the
change was made, they could look up the information, and if one does not,
then one would not be bother by having to scroll down to see the actual
patch.

julia

== 4 of 4 ==
Date: Fri, Jan 15 2010 3:10 am
From: Mark Brown

On Fri, Jan 15, 2010 at 11:05:21AM +0100, Julia Lawall wrote:
> On Fri, 15 Jan 2010, Pekka Enberg wrote:

> > It seems to me that the scripts are kernel specific so why don't we
> > put those useful scripts _within_ the kernel source tree and introduce
> > a "make coccinelle-check" target?

> Indeed, perhaps a solution that would satisfy everyone would be to make a
> place for scripts, perhaps with subdirectories for various tools, and then
> when one submits a patch for tool X, one could then submit the script at
> the same time (if it wasn't there already) and just refer to the script
> that was used. That way, if someone wants to know more about how the
> change was made, they could look up the information, and if one does not,
> then one would not be bother by having to scroll down to see the actual
> patch.

This would also mean that other people could run and re-run the scripts
during development much more easily which would help improve the
coverage of new code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
http://groups.google.com/group/linux.kernel/t/22ddf93d90f48d66?hl=en
==============================================================================

== 1 of 11 ==
Date: Fri, Jan 15 2010 2:00 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 15:08 +0530, Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 15, 2010 at 10:03:48AM +0100, Peter Zijlstra wrote:
> > On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
> > >
> > > discussed elsewhere.
> >
> > Thanks for the pointer...
>
> :-)
>
> Peter,
> I think Jim was referring to
> http://sources.redhat.com/ml/systemtap/2007-q1/msg00571.html

That's a 2007 email from some obscure list... that's hardly something
that can be referenced to without link.

As previously stated, I think poking at a process's address space is an
utter no-go.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 11 ==
Date: Fri, Jan 15 2010 2:20 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:

> Ideas?

emulate the one instruction?

== 3 of 11 ==
Date: Fri, Jan 15 2010 2:20 am
From: Ananth N Mavinakayanahalli

On Fri, Jan 15, 2010 at 10:50:14AM +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 15:08 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jan 15, 2010 at 10:03:48AM +0100, Peter Zijlstra wrote:
> > > On Thu, 2010-01-14 at 11:46 -0800, Jim Keniston wrote:
> > > >
> > > > discussed elsewhere.
> > >
> > > Thanks for the pointer...
> >
> > :-)
> >
> > Peter,
> > I think Jim was referring to
> > http://sources.redhat.com/ml/systemtap/2007-q1/msg00571.html
>
> That's a 2007 email from some obscure list... that's hardly something
> that can be referenced to without link.
>
> As previously stated, I think poking at a process's address space is an
> utter no-go.

In which case we'll need to find a different solution to it. The gdb
style of 'breakpoint hit' -> 'put original instruction back in place' ->
single-step -> 'put back the breakpoint' would be a big limiter,
especially for multithreaded cases.

The design here is to have a small vma sufficiently high enough in
memory a-la vDSO that most apps won't reach, though there is still no
ironclad guarantee.

Ideally, we will need to single-step on a copy of the instruction, in the
user address space of the traced process.

Ideas?

Ananth
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 11 ==
Date: Fri, Jan 15 2010 2:30 am
From: Ananth N Mavinakayanahalli

On Fri, Jan 15, 2010 at 11:13:32AM +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
>
> > Ideas?
>
> emulate the one instruction?

In kernel? Generically? Don't think its that easy for userspace --
you have the full gamut of instructions to emulate (fp, vector, etc);
further, the instruction could itself cause a page fault and the like.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 11 ==
Date: Fri, Jan 15 2010 2:30 am
From: Srikar Dronamraju

Hi Peter,

> > >
> >
> > My reply in
> > http://lkml.indiana.edu/hypermail/linux/kernel/1001.1/02483.html
> > addresses this.
>
> Right, so all that need be done is add the multiple probe stuff to UBP
> and its a sane interface to use on its own, at which point I'd be
> inclined to call that uprobes (UBP really is an crap name).

I am fine with renaming ubp to a suggested name. The reason for splitting
uprobes to two layers was to allow others (currently none) to reuse the
current ubp layer. It was felt that there could be multiple clients for
ubp who could co-exist.

However ubp alone is not enough to provide the userspace tracing.
Currently it wouldn't understand synchronization between different
threads of a process, process life time issues, context in which the
handler has to be run.

As pointed out by Jim earlier, we have segregrated that layer which
takes care of the above issues into the uprobes layer.

For example, while inserting a breakpoint, one of the threads of a
process could be running at the same place where we are trying to place
a breakpoint. Or there could be two threads that could be racing to
insert/delete a breakpoint. These synchronization issues are all handled
by the Uprobes layer.

Uprobes layer would need to be notified of process life-time events
like fork/clone/exec/exit.
It also needs to know
- when a breakpoint is hit
- stop and resume a thread.

Uprobes layer uses utrace to be notified of the process life time events
and the signal handling part.

--
Thanks and Regards
Srikar

>
> Then we can ditch the whole utrace muck as I see no reason to want to
> use that, whereas the ubp (given a sane name) looks interesting.
>

== 6 of 11 ==
Date: Fri, Jan 15 2010 2:40 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
> Hi Peter,
>
> Or there could be two threads that could be racing to
> insert/delete a breakpoint. These synchronization issues are all handled
> by the Uprobes layer.

Shouldn't be hard to put that in the ubp layer, right?

> Uprobes layer would need to be notified of process life-time events
> like fork/clone/exec/exit.

No so much the process lifetimes as the vma life times are interesting,
placing a hook in the vm code to track that isn't too hard,

> It also needs to know
> - when a breakpoint is hit
> - stop and resume a thread.

A simple hook in the trap code is done quickly enough, and no reason to
stop the thread, its not going anywhere when it traps.

== 7 of 11 ==
Date: Fri, Jan 15 2010 3:00 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 15:52 +0530, Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 15, 2010 at 11:13:32AM +0100, Peter Zijlstra wrote:
> > On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
> >
> > > Ideas?
> >
> > emulate the one instruction?
>
> In kernel? Generically? Don't think its that easy for userspace --
> you have the full gamut of instructions to emulate (fp, vector, etc);
> further,

Can't you jit a piece of code that wraps the one instruction, save the
full cpu state, set the userspace segments, have it load pt_regs (except
for the IP) execute the one ins, save the results, restore the full
state?

Then replace pt_regs with the saved result and advance the stored IP by
the length of that one instruction and return to userspace?

All you need to take care of are the priv insns, but doesn't something
like kvm already have code to deal with that?

> the instruction could itself cause a page fault and the like.

Faults aren't a problem, we take faults from kernel space all the time.

== 8 of 11 ==
Date: Fri, Jan 15 2010 3:10 am
From: Maneesh Soni

On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
> > Hi Peter,
> >
> > Or there could be two threads that could be racing to
> > insert/delete a breakpoint. These synchronization issues are all handled
> > by the Uprobes layer.
>
> Shouldn't be hard to put that in the ubp layer, right?
>
> > Uprobes layer would need to be notified of process life-time events
> > like fork/clone/exec/exit.
>
> No so much the process lifetimes as the vma life times are interesting,
> placing a hook in the vm code to track that isn't too hard,
>

I think similar hooks were given thumbs down in the previous incarnation
of uprobes (which was implemented without utrace).

http://lkml.indiana.edu/hypermail/linux/kernel/0603.2/1254.html

Thanks
Maneesh

--
Maneesh Soni
Linux Technology Center
IBM India Systems and Technology Lab,
Bangalore, India.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 9 of 11 ==
Date: Fri, Jan 15 2010 3:10 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 11:56 +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 15:52 +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jan 15, 2010 at 11:13:32AM +0100, Peter Zijlstra wrote:
> > > On Fri, 2010-01-15 at 15:40 +0530, Ananth N Mavinakayanahalli wrote:
> > >
> > > > Ideas?
> > >
> > > emulate the one instruction?
> >
> > In kernel? Generically? Don't think its that easy for userspace --
> > you have the full gamut of instructions to emulate (fp, vector, etc);
> > further,
>
> Can't you jit a piece of code that wraps the one instruction, save the
> full cpu state, set the userspace segments, have it load pt_regs (except
> for the IP) execute the one ins, save the results, restore the full
> state?

Hmm, normally the problem with FP/Vector state is that we don't
save/restore it going in/out the kernel, so kernel-space can't use it
because it would change the userspace state, but in this case we can
simply execute that one instruction and have it change user state,
because that's exactly what we want to do.

So we don't need to save restore the full cpu state around that JIT'ed
piece of code, but just the regular regs.

== 10 of 11 ==
Date: Fri, Jan 15 2010 3:20 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 16:35 +0530, Maneesh Soni wrote:
> On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
> > On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
> > > Hi Peter,
> > >
> > > Or there could be two threads that could be racing to
> > > insert/delete a breakpoint. These synchronization issues are all handled
> > > by the Uprobes layer.
> >
> > Shouldn't be hard to put that in the ubp layer, right?
> >
> > > Uprobes layer would need to be notified of process life-time events
> > > like fork/clone/exec/exit.
> >
> > No so much the process lifetimes as the vma life times are interesting,
> > placing a hook in the vm code to track that isn't too hard,
> >
>
> I think similar hooks were given thumbs down in the previous incarnation
> of uprobes (which was implemented without utrace).
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0603.2/1254.html

I wasn't at all proposing to mess with a_ops, nor do you really need to,
I was more thinking of adding a callback like perf_event_mmap() and a
corresponding unmap(), that way you can track mapping life-times and
add/remove probes accordingly.

Adding the probe uses the fact that (most) executable mappings are
MAP_PRIVATE and CoWs a private copy of the page with the modified ins,
right?

What does it do for MAP_SHARED|MAP_EXECUTABLE sections -- simply fail to
add the probe?

== 11 of 11 ==
Date: Fri, Jan 15 2010 3:20 am
From: Peter Zijlstra

On Fri, 2010-01-15 at 12:12 +0100, Peter Zijlstra wrote:
> On Fri, 2010-01-15 at 16:35 +0530, Maneesh Soni wrote:
> > On Fri, Jan 15, 2010 at 11:33:27AM +0100, Peter Zijlstra wrote:
> > > On Fri, 2010-01-15 at 15:56 +0530, Srikar Dronamraju wrote:
> > > > Hi Peter,
> > > >
> > > > Or there could be two threads that could be racing to
> > > > insert/delete a breakpoint. These synchronization issues are all handled
> > > > by the Uprobes layer.
> > >
> > > Shouldn't be hard to put that in the ubp layer, right?
> > >
> > > > Uprobes layer would need to be notified of process life-time events
> > > > like fork/clone/exec/exit.
> > >
> > > No so much the process lifetimes as the vma life times are interesting,
> > > placing a hook in the vm code to track that isn't too hard,
> > >
> >
> > I think similar hooks were given thumbs down in the previous incarnation
> > of uprobes (which was implemented without utrace).
> >
> > http://lkml.indiana.edu/hypermail/linux/kernel/0603.2/1254.html
>
> I wasn't at all proposing to mess with a_ops, nor do you really need to,
> I was more thinking of adding a callback like perf_event_mmap() and a
> corresponding unmap(), that way you can track mapping life-times and
> add/remove probes accordingly.
>
> Adding the probe uses the fact that (most) executable mappings are
> MAP_PRIVATE and CoWs a private copy of the page with the modified ins,
> right?

Does it clean up the CoW'ed page on removing the probe? Does that
account for userspace having made other changes in between installing
and removing the probe (for PROT_WRITE mappings obviously)?

==============================================================================
TOPIC: macvlan: add GRO bit to features mask
http://groups.google.com/group/linux.kernel/t/2e7222a395a374c0?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:10 am
From: Patrick McHardy

Patrick Mullaney wrote:
> Allow macvlan devices to support GRO.

Acked-by: Patrick McHardy <kaber@trash.net>

Please send this patch to Dave, this can already go upstream.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: AMD64 EDAC fix for 2.6.33-rc5
http://groups.google.com/group/linux.kernel/t/d676a81f5a131b41?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:10 am
From: Borislav Petkov

Hi Linus,

please pull the following small fix.

The following changes since commit 7284ce6c9f6153d1777df5f310c959724d1bd446:
Linus Torvalds (1):
Linux 2.6.33-rc4

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git for-linus

Roel Kluin (1):
amd64_edac: Ensure index stays within bounds in amd64_get_scrub_rate

drivers/edac/amd64_edac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

Thanks.

--
Regards/Gruss,
Boris.

Operating | Advanced Micro Devices GmbH
Systems | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. M�nchen, Germany
Research | Gesch�ftsf�hrer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis M�nchen
(OSRC) | Registergericht M�nchen, HRB Nr. 43632

==============================================================================
TOPIC: k10temp: temperature sensor for AMD Family 10h/11h CPUs
http://groups.google.com/group/linux.kernel/t/cadbcb576e338fa3?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:10 am
From: Clemens Ladisch

Jean Delvare wrote:
> On Fri, 27 Nov 2009 14:03:29 +0100, Clemens Ladisch wrote:
> > +temp[1-*]_scale Temperature scale type.
> > + 0: millidegrees Celsius (default if no _scale entry)
> > + 1: relative millidegrees Celsius; see below
> > + 2: millivolts; see below
> > + other values: unknown
>
> Maybe, yes. I am a little worried that older versions of libsensors
> will ignore this attribute. The good thing about this is that users
> will still get some value until they upgrade. The bad thing is that
> they will not know that the value isn't absolute. They are likely to
> get frightened by unexpected values and/or to complain to us about them.
>
> I am wondering if a totally separate channel type wouldn't be
> preferable. The pros and cons would be inverted of course: older
> versions of libsensors would have zero support for that, and all
> applications would have to be updated to support it, but at least the
> meaning of the value would be totally clear. This would come at the
> price of some code duplication both in libsensors and applications
> though.
>
> I guess it basically depends whether we want to consider a thermal
> margin as a "temperature measurement except that it's relative" or as
> something completely separate.

It's different from the millidegree/millivolt issue; millivolts can be
transparently converted by libsensors, while relative values must be
handled/displayed differently by the application. So I think at least
in the libsensors API, relative values should be different.

(In any case, we should add temp#_scale at least for millivolts.)

> Honestly, I've been thinking about this
> for some time now and I simply don't know what we'd rather do :(

The sysfs interface is a somewhat internal interface; I think the main
question is whether old userspace (old libsensors or old apps using a
new libsensors) should be able to see relative values without knowing
that they are relative.

Coretemp and k10temp already exist and show relative values. If we
introduced a new channel for relative values now, we would still have
problems with those drivers, so it might already be too late to avoid
problems for old userspace.

Best regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: fix some typo's in avc.c
http://groups.google.com/group/linux.kernel/t/45d0aabdd8b3c3da?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:40 am
From: Jiri Kosina

On Thu, 14 Jan 2010, Justin P. Mattock wrote:

> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
> ---
> security/selinux/avc.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
> index f2dde26..3328b1f 100644
> --- a/security/selinux/avc.c
> +++ b/security/selinux/avc.c
> @@ -337,7 +337,7 @@ static inline struct avc_node *avc_search_node(u32 ssid, u32 tsid, u16 tclass)
> * Look up an AVC entry that is valid for the
> * (@ssid, @tsid), interpreting the permissions
> * based on @tclass. If a valid AVC entry exists,
> - * then this function return the avc_node.
> + * then this function returns the avc_node.

Applied, thanks.

--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: ext3: prevent reread after write IO error v2
http://groups.google.com/group/linux.kernel/t/4ac1e62d14e677fe?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:40 am
From: Hidehiro Kawai

Jan Kara wrote:

>>By the way, I think the right fix is to keep uptodate flag on write
>>error, but it gives a big impact. We have to confirm whether
>>over 200 buffer_uptodate's are used for real uptodate check or write
>>error check. For now, I adopt the quick-fix solution.
>
> Yes that needs to be solved. I also looked into it and it's too much work
> to do it in a one big sweep. But I think we could do the conversion
> filesystem by filesystem - see below.
> Admittedly, I don't like your solution very much. It looks strange to
> check write_io_error when *reading* the buffer and I'm afraid we could
> introduce bugs e.g. by clearing write_io_error bit so that ext3_bread would
> then fail to detect the error condition or by some other code deciding to
> read the buffer from disk via other function than just ext3_bread. So I
> think it would be much better to set back uptodate flag shortly after the
> failed write or not clear it at all.
> Now here's how I think we could achieve that without having to change all
> other filesystems: We could create a new superblock flag which would mean
> that "this filesystem handles write_io_error and doesn't want to clear
> uptodate flag". Filesystems with this capability would set this flag when
> calling get_sb_bdev. And if write IO fails we check this flag
> (via bh->b_bdev->bd_super->s_flags) and clear / not clear uptodate flag
> accordingly. What do you think?

Thanks for your comment!

Your suggestion is what I wanted to do ultimately, and it seems
to go well. I'll send a rivised patch later.

Best regards,
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center

==============================================================================
TOPIC: fix a typo in pci-dma.c
http://groups.google.com/group/linux.kernel/t/66cd846910489976?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:40 am
From: Jiri Kosina

On Thu, 14 Jan 2010, Justin P. Mattock wrote:

> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
> ---
> arch/x86/kernel/pci-dma.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index 75e14e2..eec33a7 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -38,7 +38,7 @@ int iommu_detected __read_mostly = 0;
> * This variable becomes 1 if iommu=pt is passed on the kernel command line.
> * If this variable is 1, IOMMU implementations do no DMA translation for
> * devices and allow every device to access to whole physical memory. This is
> - * useful if a user want to use an IOMMU only for KVM device assignment to
> + * useful if a user wants to use an IOMMU only for KVM device assignment to
> * guests and not for driver dma translation.
> */

Applied, thanks.

==============================================================================
TOPIC: hid-debug.c: make local symbols static
http://groups.google.com/group/linux.kernel/t/b870c652591349e4?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Jan 15 2010 2:40 am
From: Jiri Kosina

On Thu, 14 Jan 2010, H Hartley Sweeten wrote:

> hid-debug.c: make local symbols static
>
> The symbols hid_resolv_event and hid_dump_input_mapping
> are only used locally in this file. Make them static to prevent
> the following sparse warnings:
>
> warning: symbol 'hid_resolv_event' was not declared. Should it be static?
> warning: symbol 'hid_dump_input_mapping' was not declared. Should it be static?
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: Jiri Kosina <jkosina@suse.cz>
>
> ---
>
> diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
> index 6abd036..cd4ece6 100644
> --- a/drivers/hid/hid-debug.c
> +++ b/drivers/hid/hid-debug.c
> @@ -864,13 +864,13 @@ static const char **names[EV_MAX + 1] = {
> [EV_SND] = sounds, [EV_REP] = repeats,
> };
>
> -void hid_resolv_event(__u8 type, __u16 code, struct seq_file *f) {
> -
> +static void hid_resolv_event(__u8 type, __u16 code, struct seq_file *f)
> +{
> seq_printf(f, "%s.%s", events[type] ? events[type] : "?",
> names[type] ? (names[type][code] ? names[type][code] : "?") : "?");
> }
>
> -void hid_dump_input_mapping(struct hid_device *hid, struct seq_file *f)
> +static void hid_dump_input_mapping(struct hid_device *hid, struct seq_file *f)
> {
> int i, j, k;
> struct hid_report *report;

Applied, thanks.

==============================================================================
TOPIC: ldisc switching on a HUPped pty hangs the caller
http://groups.google.com/group/linux.kernel/t/318869d0fd7cc646?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Jan 15 2010 2:50 am
From: Alan Cox

> I recently upgraded my gateway machine to 2.6.31. This caused
> ppp-over-ssh to stop working. Indeed, the PPP process got wedged into
> noninterruptible sleep, which this patch fixes.
>
> (The comment, by the way, seems to be wrong. There was no race.)

Really ?

Think about

set_ldisc
hangup
close
open
set to N_TTY etc
Now what ???

> The underlying problem, however, turns out to be the vhangup() syscall
> which the SSH server emits before exec'ing pppd. This causes the tty's
> HUPPED bit to get set, which in turn causes the above error.

vhangup sets the huppet bit to make sure that anything touching the tty
beyond that point goes away and dies.

> diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
> index aafdbae..bb92f5e 100644
> --- a/drivers/char/tty_ldisc.c
> +++ b/drivers/char/tty_ldisc.c
> @@ -621,9 +621,8 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
> /* We were raced by the hangup method. It will have stomped
> the ldisc data and closed the ldisc down */
> clear_bit(TTY_LDISC_CHANGING, &tty->flags);
> - mutex_unlock(&tty->ldisc_mutex);
> - tty_ldisc_put(new_ldisc);
> - return -EIO;
> + retval = -EIO;
> + goto out;
> }
>
> /* Shutdown the current discipline. */
> @@ -652,7 +651,7 @@ int tty_set_ldisc(struct tty_struct *tty, int ldisc)
> /*
> * Allow ldisc referencing to occur again
> */
> -
> +out:
> tty_ldisc_enable(tty);
> if (o_tty)
> tty_ldisc_enable(o_tty);

And falls through to restart work queues and stuff that may not be safe
to do

So: NAK

I agree there is a bug but you've swapped one bug for sevral nastier bugs.

As far as I can see from a quick look the real problem in your case is
that we don't do enough work in the case where tty->driver->flags doesn't
contain TTY_DRIVER_RESET_TERMIOS. We need to reinit the ldisc either way.

== 2 of 2 ==
Date: Fri, Jan 15 2010 3:20 am
From: Alan Cox

Give this a spin
tty: Fix the ldisc hangup race

From: Alan Cox <alan@linux.intel.com>

This was noticed by Matthias Urlichs and he proposed a fix. This patch
does the fixing a different way to avoid introducing several new race
conditions into the code.

The problem case is TTY_DRIVER_RESET_TERMIOS = 0. In that case while we
abort the ldisc change the hangup processing has not cleaned up and restarted
the ldisc either.

We can't restart the ldisc stuff in the set_ldisc as we don't know what
the hangup did and may touch stuff we shouldn't as we are no longer
supposed to influence the tty at that point in case it has been re-opened
before we get rescheduled.

Instead do it the simple way. Always re-init the ldisc on the hangup, but
use TTY_DRIVER_RESET_TERMIOS to indicate that we should force N_TTY.

Signed-off-by: Alan Cox <alan@linux.intel.com>
---

drivers/char/tty_ldisc.c | 50 ++++++++++++++++++++++++++++------------------
1 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/char/tty_ldisc.c b/drivers/char/tty_ldisc.c
index 3f653f7..500e740 100644
--- a/drivers/char/tty_ldisc.c
+++ b/drivers/char/tty_ldisc.c
@@ -706,12 +706,13 @@ static void tty_reset_termios(struct tty_struct *tty)
/**
* tty_ldisc_reinit - reinitialise the tty ldisc
* @tty: tty to reinit
+ * @ldisc: line discipline to reinitialize
*
- * Switch the tty back to N_TTY line discipline and leave the
- * ldisc state closed
+ * Switch the tty to a line discipline and leave the ldisc
+ * state closed
*/

-static void tty_ldisc_reinit(struct tty_struct *tty)
+static void tty_ldisc_reinit(struct tty_struct *tty, int ldisc)
{
struct tty_ldisc *ld;

@@ -721,10 +722,10 @@ static void tty_ldisc_reinit(struct tty_struct *tty)
/*
* Switch the line discipline back
*/
- ld = tty_ldisc_get(N_TTY);
+ ld = tty_ldisc_get(ldisc);
BUG_ON(IS_ERR(ld));
tty_ldisc_assign(tty, ld);
- tty_set_termios_ldisc(tty, N_TTY);
+ tty_set_termios_ldisc(tty, ldisc);
}

/**
@@ -745,6 +746,8 @@ static void tty_ldisc_reinit(struct tty_struct *tty)
void tty_ldisc_hangup(struct tty_struct *tty)
{
struct tty_ldisc *ld;
+ int reset = tty->driver->flags & TTY_DRIVER_RESET_TERMIOS;
+ int err = 0;

/*
* FIXME! What are the locking issues here? This may me overdoing
@@ -772,25 +775,32 @@ void tty_ldisc_hangup(struct tty_struct *tty)
wake_up_interruptible_poll(&tty->read_wait, POLLIN);
/*
* Shutdown the current line discipline, and reset it to
- * N_TTY.
+ * N_TTY if need be.
+ *
+ * Avoid racing set_ldisc or tty_ldisc_release
*/
- if (tty->driver->flags & TTY_DRIVER_RESET_TERMIOS) {
- /* Avoid racing set_ldisc or tty_ldisc_release */
- mutex_lock(&tty->ldisc_mutex);
- tty_ldisc_halt(tty);
- if (tty->ldisc) { /* Not yet closed */
- /* Switch back to N_TTY */
- tty_ldisc_reinit(tty);
- /* At this point we have a closed ldisc and we want to
- reopen it. We could defer this to the next open but
- it means auditing a lot of other paths so this is
- a FIXME */
+ mutex_lock(&tty->ldisc_mutex);
+ tty_ldisc_halt(tty);
+ /* At this point we have a closed ldisc and we want to
+ reopen it. We could defer this to the next open but
+ it means auditing a lot of other paths so this is
+ a FIXME */
+ if (tty->ldisc) { /* Not yet closed */
+ if (reset == 0) {
+ tty_ldisc_reinit(tty, tty->termios->c_line);
+ err = tty_ldisc_open(tty, tty->ldisc);
+ }
+ /* If the re-open fails or we reset then go to N_TTY. The
+ N_TTY open cannot fail */
+ if (reset || err) {
+ tty_ldisc_reinit(tty, N_TTY);
WARN_ON(tty_ldisc_open(tty, tty->ldisc));
- tty_ldisc_enable(tty);
}
- mutex_unlock(&tty->ldisc_mutex);
- tty_reset_termios(tty);
+ tty_ldisc_enable(tty);
}
+ mutex_unlock(&tty->ldisc_mutex);
+ if (reset)
+ tty_reset_termios(tty);
}

/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Friday, January 15, 2010

linux.kernel - 26 new messages in 12 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts