* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 20:51 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <20101007220538.2294a7e4@lxorguk.ukuu.org.uk>
On Thu, 2010-10-07 at 22:05 +0100, Alan Cox wrote:
> On Thu, 07 Oct 2010 13:36:06 -0700
> Daniel Walker <dwalker@codeaurora.org> wrote:
>
> > On Thu, 2010-10-07 at 21:50 +0100, Alan Cox wrote:
> > > > + Say Y here if you want to install DCC driver as a normal serial port
> > > > + /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
> > > > + (major 4, minor 128) and can co-exist with other UARTs, such as
> > > > + 8250/16C550 compatibles.
> > > > +
> > >
> > > NAK to both
> >
> > Both what?
>
> Both device allocations. Please use the 204,186 assigned for JTAG DCC.
>
> > I would agree if this wasn't strictly for debugging embedded devices in
> > difficult situations.. After talking to Mike, it's seems like it would
> > be useful to have this as a ttyS* specifically because embedded devices
> > won't always create a ttyJ* for you and ttyS* will likely already exist.
>
> If you are debugging an embedded device you are capable of changing it
> (otherwise you wouldn't debug it). Therefore the fact you might need to
> tweak the tty creation on the device is not a problem. If you can't
> change the device well there is no point debugging it is there !
Your making too many assumptions .. You might be able to modify the
kernel, and not the userspace. So you couldn't tweak the device
creation .. It's much easier in the server world ..
Hyok should really be addressing this .. If he added for some random
useless reason , then for sure we can rip it out .. Otherwise I think it
deserves some more discussion ..
> We've said no over a period of about ten years to a lot of attempts to
> just borrow the ttyS0 range. If we'd said yes it would have been a
> complete mess by now.
>
> So the answer is no.
Nothing can be unilateral, there's always room for exceptions. You
should say something more like "it's possible, but unlikely".
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Matthew Garrett @ 2010-10-07 20:50 UTC (permalink / raw)
To: Mario Limonciello
Cc: Keng-Yu Lin, len.brown, alan-jenkins, platform-driver-x86,
linux-kernel
In-Reply-To: <AANLkTi=kTQpTkCF6-DE+LdNLH_aki9bD9NPF0L2qRr=Q@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:49:05PM -0500, Mario Limonciello wrote:
> Hi Matthew:
> > Is the kernel able to unblock it under those circumstances?
>
> Manually running rfkill unblock will unblock it in this broken
> firmware scenario in question.
So the issue is in the firmware's response to the keystroke? Ok. I'd
rather have a DMI list of the broken machines than a module parameter.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [PATCH] usb: gadget: langwell_udc: Fix error path
From: Greg KH @ 2010-10-07 20:48 UTC (permalink / raw)
To: Rahul Ruikar
Cc: David Brownell, Greg Kroah-Hartman, Joe Perches, linux-usb,
linux-kernel
In-Reply-To: <AANLkTinxOAFuBjUaZVxHAM_n+xcV1qVEgVZ-up9kDRDP@mail.gmail.com>
On Thu, Oct 07, 2010 at 11:49:41PM +0530, Rahul Ruikar wrote:
> Ok no problem.
> I had sent it because yesterday you asked me to send it again.
Yes, but I assumed it would be in a form that I could apply it in :)
thanks,
greg k-h
^ permalink raw reply
* Re: Restricting USB access
From: Greg KH @ 2010-10-07 20:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <OFACC41AE7.587D1697-ON852577B5.006C93B7-852577B5.006D0ACC@hc-sc.gc.ca>
On Thu, Oct 07, 2010 at 03:50:55PM -0400, Ryan Lawrie wrote:
>
> Good afternoon,
>
> Just wondering if I could get your assistance with something.
>
> I need to secure the USB ports on my LAN workstations so they are not
> writable by users (other than a certain group that I specify). Is this type
> of restriction possible using udev rules?
USB ports are "writeable" or "readable", it depends on the devices you
plug into them that you could then read or write to.
> I was using PolicyKit before but since we've changed OS (from openSUSE11.0
> to 64-bit openSUSE11.2) that no longer seems to function properly.
> Everybody has access to the USB ports now.
You might want to just restrict the users for the specific devices using
a udev rule, or policykit, if that's still around.
What types of devices are you trying to restrict?
thanks,
greg k-h
^ permalink raw reply
* Re: OT: compilation
From: Xavier Chantry @ 2010-10-07 20:50 UTC (permalink / raw)
To: Grzesiek Sójka; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <4CAE2A1B.1000105-t9zbU3WrWHI@public.gmane.org>
2010/10/7 Grzesiek Sójka <pld-t9zbU3WrWHI@public.gmane.org>:
> I have two problems with the kernel compilation.
>
> 1. I have a small rootfs. It is too small to put all the modules there
> without gzipping it first. So installing it requires lots of sweating. That
> is why I was wondering if there is a (more/less easy) way to make the "make
> modules_install" command gzip the modules "on the fly".
>
No idea if you can do that but here are some possible alternatives :
1) increase the size of your rootfs
2) remove modules you don't need and change from modules to builtin
for features or drivers that you don't need to unload/reload
3) a quick googling showed me this patch :
http://www.mail-archive.com/linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg271865.html
However it seems to install first then compress so if that's the case,
you will need to adapt it to your need
4) set INSTALL_MOD_PATH to a prefix , compress modules , then move to
/lib/modules/
LOCALVERSION_AUTO is found in :
make menuconfig
General Setup
Automatically append version information to the version string
^ permalink raw reply
* CLEVO B5120 acpi problems, probably EC-related
From: Oliver Freyd @ 2010-10-07 20:45 UTC (permalink / raw)
To: linux-acpi
Hello,
I'm trying to get this new laptop running with linux (debian testing)
most things are working well, I get acpi events for hotkeys
like volume up/down, or light up/down, but no acpi_events
or even interrupts for the sleep button, the power button,
lid switch and AC power plug.
uname -a
Linux falkenstein 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010
x86_64 GNU/Linux
dmesg|grep ACPI says:
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a701 base: 0xfed00000
[ 0.002994] ACPI: Core revision 20090903
[ 0.497370] ACPI: bus type pci registered
[ 0.512734] ACPI: EC: Look up EC in DSDT
[ 0.518819] ACPI: BIOS _OSI(Linux) query ignored
[ 0.520679] ACPI: EC: GPE storm detected, transactions will use
polling mode
[ 0.540248] ACPI: Interpreter enabled
[ 0.540252] ACPI: (supports S0 S3 S4 S5)
[ 0.540287] ACPI: Using IOAPIC for interrupt routing
[ 0.540597] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC
function
[ 0.575483] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC
function
[ 0.612412] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 0.612664] ACPI: No dock devices found.
[ 0.613466] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.628222] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.628467] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
[ 0.628586] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[ 0.628785] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT]
[ 0.628900] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP02._PRT]
[ 0.629015] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP03._PRT]
[ 0.629129] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP04._PRT]
[ 0.639287] ACPI: PCI Root Bridge [CPBG] (0000:ff)
[ 0.639612] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 12
14 15) *11
[ 0.639713] ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 11 12
14 15) *10
[ 0.639812] ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 12
14 15)
[ 0.639911] ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 *5 6 7 11 12
14 15)
[ 0.640009] ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 10 12
14 15) *0, disabled.
[ 0.640114] ACPI: PCI Interrupt Link [LNKF] (IRQs 1 3 4 5 6 7 11 12
14 15) *0, disabled.
[ 0.640215] ACPI: PCI Interrupt Link [LNKG] (IRQs 1 3 4 5 6 *7 10 12
14 15)
[ 0.640314] ACPI: PCI Interrupt Link [LNKH] (IRQs 1 3 4 5 6 7 *11 12
14 15)
[ 0.640454] PCI: Using ACPI for IRQ routing
[ 0.649093] pnp: PnP ACPI init
[ 0.649105] ACPI: bus type pnp registered
[ 0.665529] pnp: PnP ACPI: found 11 devices
[ 0.665530] ACPI: ACPI bus type pnp unregistered
[ 1.083544] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace
lookup failure, AE_NOT_FOUND
[ 1.083550] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.LPCB.EC__.ADJP] (Node ffff880137a40240), AE_NOT_FOUND
[ 1.083581] ACPI Error (psparse-0537): Method parse/execution failed
[\_TZ_.TZ0_._TMP] (Node ffff880137a44de0), AE_NOT_FOUND
[ 3.203371] ACPI: SSDT 00000000bf71a918 003F0 (v01 PmRef Cpu0Ist
00003000 INTL 20060912)
[ 3.203922] ACPI: SSDT 00000000bf718a18 00471 (v01 PmRef Cpu0Cst
00003001 INTL 20060912)
[ 3.218859] ACPI: Power Button [PWRB]
[ 3.218919] ACPI: Sleep Button [SLPB]
[ 3.223950] ACPI: SSDT 00000000bf719a98 00303 (v01 PmRef ApIst
00003000 INTL 20060912)
[ 3.224539] ACPI: SSDT 00000000bf717d98 00119 (v01 PmRef ApCst
00003000 INTL 20060912)
[ 3.293155] ACPI: Lid Switch [LID0]
[ 3.293230] ACPI: WMI: Mapper loaded
[ 3.293237] ACPI: Power Button [PWRF]
[ 3.328155] ACPI: AC Adapter [AC] (on-line)
[ 3.377779] [Firmware Bug]: ACPI(VGA) defines _DOD but not _DOS
[ 3.377905] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC
function
[ 3.517464] acpi device:01: registered as cooling_device4
[ 3.517750] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no)
[ 4.015196] ACPI: Battery Slot [BAT] (battery present)
[ 4.020328] ACPI: I/O resource 0000:00:1f.3 [0x1840-0x185f] conflicts
with ACPI region SMBI [0x1840-0x184f]
[ 4.020388] ACPI: If an ACPI driver is available for this device, you
should use it instead of the native driver
[ 8.689480] input: ACPI Virtual Keyboard Device as
/devices/virtual/input/input11
especially strange I find the "EC GPE storm detected" and the 3
AE_NOT_FOUND errors.
I tried to decompile the DSDT, and was able to compile it back after
fixing some rather trivial errors, but I'm at a loss with the missing
methods.
I also tried a 2.6.36rc1 kernel, compiled from source,
the missing methods in dmesg were gone, but the buttons did not
work either...
lots of fun hacking linux,
Oliver
^ permalink raw reply
* Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
From: Mario Limonciello @ 2010-10-07 20:49 UTC (permalink / raw)
To: Matthew Garrett
Cc: Keng-Yu Lin, len.brown, alan-jenkins, platform-driver-x86,
linux-kernel
In-Reply-To: <20101007133529.GA21782@srcf.ucam.org>
Hi Matthew:
On Thu, Oct 7, 2010 at 08:35, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> On Thu, Oct 07, 2010 at 08:30:57AM -0500, Mario Limonciello wrote:
>
> > In this specific scenario that Ken Yu submitted this patch for, the
> > firmware will return the same return codes for the SMI's as a functional
> > machine will. Machines affected by this will fail to recover after rfkill
> > is toggled twice. The symptom will be that the soft block always appears
> > set to the same setting with continued keypresses.
> > During the prototype phase this option is quite useful to help debug the
> > problem it addresses.
>
> Is the kernel able to unblock it under those circumstances?
Manually running rfkill unblock will unblock it in this broken
firmware scenario in question.
--
Mario Limonciello
superm1@gmail.com
^ permalink raw reply
* Re: Can you please define "snapshot" and "subvolume"?
From: David Nicol @ 2010-10-07 20:48 UTC (permalink / raw)
To: Francis Galiegue; +Cc: linux-btrfs
In-Reply-To: <AANLkTimBsVGS=eJvpdf2Sq_Dg76zQRgy=E+3089zQ9D4@mail.gmail.com>
On Thu, Oct 7, 2010 at 6:39 AM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> While I fully understand (and use) the purpose of snapshots, I don't
> quite fathom the use case for subvolumes, apart from btrfs-convert...
> Why has btrfs grown such a feature in the first place? Can someone
> give me a use case for them?
I'm new here; I trust that someone will correct me if wrong:
As I understand it, since snapshotting works on volumes, having
subvolumes allows a smaller thing that you can take a snapshot of. A
use case? One could give each user on a multi-user system their own
subvolume rather than their own directory, under /home/... and then
take snapshots of these home directories to implement regular backups
(1)without duplicating unchanged files and (2) with independence
between the users.
As to why they exist, I understand that they began as an
implementation detail of snapshots, rather than their creation having
been driven by the needs of a particular use case, and one could
legitimately criticize currently offered use cases (such as the one
above) as contrived.
I believe it is fair to consider a new subvolume as equivalent of a
snapshot of an empty file system.
^ permalink raw reply
* Re: [PATCH 0/7] a couple of random cleanups
From: Alex Elder @ 2010-10-07 20:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
In-Reply-To: <20101006184111.634126439@localhost.localdomain>
On Wed, 2010-10-06 at 14:41 -0400, Christoph Hellwig wrote:
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
The whole series looks fine. I'm taking them in and will
start testing with them.
-Alex
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Mike Frysinger @ 2010-10-07 20:47 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <1286482013.23836.29.camel@c-dwalke-linux.qualcomm.com>
On Thu, Oct 7, 2010 at 16:06, Daniel Walker wrote:
> On Thu, 2010-10-07 at 16:02 -0400, Mike Frysinger wrote:
>> how is that any different from:
>> ln -s ttyJ0 /dev/ttyS0
>
> It has the same major and minors as ttyS* does. So you don't have to run
> anything on the target.
i dont see how those things are related. the major/minor are
irrelevant, unless you've already hard coded these in some app that
creates device nodes manually (instead of mdev/udev), but even then
that's something that "needs to be run on the target". and both
already have config support to transparently do something like
"symlink ttyS# to XXX" as XXX is created.
-mike
^ permalink raw reply
* Re: [Xenomai-core] Overcoming the "foreign" stack
From: Philippe Gerum @ 2010-10-07 20:48 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Xenomai core
In-Reply-To: <4CAE04B1.9070503@domain.hid>
On Thu, 2010-10-07 at 19:34 +0200, Jan Kiszka wrote:
> Am 07.10.2010 19:08, Philippe Gerum wrote:
> > On Wed, 2010-10-06 at 11:20 +0200, Jan Kiszka wrote:
> >> Am 05.10.2010 16:21, Gilles Chanteperdrix wrote:
> >>> Jan Kiszka wrote:
> >>>> Am 05.10.2010 15:50, Gilles Chanteperdrix wrote:
> >>>>> Jan Kiszka wrote:
> >>>>>> Am 05.10.2010 15:42, Gilles Chanteperdrix wrote:
> >>>>>>> Jan Kiszka wrote:
> >>>>>>>> Am 05.10.2010 15:15, Gilles Chanteperdrix wrote:
> >>>>>>>>> Jan Kiszka wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> quite a few limitations and complications of using Linux services over
> >>>>>>>>>> non-Linux domains relate to potentially invalid "current" and
> >>>>>>>>>> "thread_info". The non-Linux domain could maintain their own kernel
> >>>>>>>>>> stacks while Linux tend to derive current and thread_info from the stack
> >>>>>>>>>> pointer. This is not an issue anymore on x86-64 (both states are stored
> >>>>>>>>>> in per-cpu variables) but other archs (e.g. x86-32 or ARM) still use the
> >>>>>>>>>> stack and may continue to do so.
> >>>>>>>>>>
> >>>>>>>>>> I just looked into this thing again as I'm evaluating ways to exploit
> >>>>>>>>>> the kernel's tracing framework also under Xenomai. Unfortunately, it
> >>>>>>>>>> does a lot of fiddling with preempt_count and need_resched, so patching
> >>>>>>>>>> it for Xenomai use would become a maintenance nightmare.
> >>>>>>>>>>
> >>>>>>>>>> An alternative, also for other use cases like kgdb and probably perf, is
> >>>>>>>>>> to get rid of our dependency on home-grown stacks. I think we are on
> >>>>>>>>>> that way already as in-kernel skins have been deprecated. The only
> >>>>>>>>>> remaining user after them will be RTDM driver tasks. But I think those
> >>>>>>>>>> could simply become in-kernel shadows of kthreads which would bind their
> >>>>>>>>>> stacks to what Linux provides. Moreover, Xenomai could start updating
> >>>>>>>>>> "current" and "thread_info" on context switches (unless this already
> >>>>>>>>>> happens implicitly). That would give us proper contexts for system-level
> >>>>>>>>>> tracing and profiling.
> >>>>>>>>>>
> >>>>>>>>>> My key question is currently if and how much of this could be realized
> >>>>>>>>>> in 2.6. Could we drop in-kernel skins in that version? If not, what
> >>>>>>>>>> about disabling them by default, converting RTDM tasks to a
> >>>>>>>>>> kthread-based approach, and enabling tracing etc. only in that case?
> >>>>>>>>>> However, this might be a bit fragile unless we can establish
> >>>>>>>>>> compile-time or run-time requirements negotiation between Adeos and its
> >>>>>>>>>> users (Xenomai) about the stack model.
> >>>>>>>>> A stupid question: why not make things the other way around: patch the
> >>>>>>>>> current and current_thread_info functions to be made I-pipe aware and
> >>>>>>>>> use an "ipipe_current" pointer to the current thread task_struct. Of
> >>>>>>>>> course, there are places where the current or current_thread_info macros
> >>>>>>>>> are implemented in assembly, so it may be not simple as it sounds, but
> >>>>>>>>> it would allow to keep 128 Kb stacks if we want. This also means that we
> >>>>>>>>> would have to put a task_struct at the bottom of every Xenomai task.
> >>>>>>>> First of all, overhead vs. maintenance. Either every access to
> >>>>>>>> preempt_count() would require a check for the current domain and its
> >>>>>>>> foreign stack flag, or I would have to patch dozens (if that is enough)
> >>>>>>>> of code sites in the tracer framework.
> >>>>>>> No. I mean we would dereference a pointer named ipipe_current. That is
> >>>>>>> all, no other check. This pointer would be maintained elsewhere. And we
> >>>>>>> modify the "current" macro, like:
> >>>>>>>
> >>>>>>> #ifdef CONFIG_IPIPE
> >>>>>>> extern struct task_struct *ipipe_current;
> >>>>>>> #define current ipipe_current
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> Any calll site gets modified automatically. Or current_thread_info, if
> >>>>>>> it is current_thread_info which is obtained using the stack pointer mask
> >>>>>>> trick.
> >>>>>> The stack pointer mask trick only works with fixed-sized stacks, not a
> >>>>>> guaranteed property of in-kernel Xenomai threads.
> >>>>> Precisely the reason why I propose to replace it with a global variable
> >>>>> reference, or a per-cpu variable for SMP systems.
> >>>>
> >>>> Then why is Linux not using this in favor of the stack pointer approach
> >>>> on, say, ARM?
> >>>>
> >>>> For sure, we can patch all Adeos-supported archs away from stack-based
> >>>> to per-cpu current & thread_info, but I don't feel comfortable with this
> >>>> in some way invasive approach as well. Well, maybe it's just my personal
> >>>> misperception.
> >>>
> >>> It is as much invasive as modifying local_irq_save/local_irq_restore.
> >>> The real question about the global pointer approach, is, if it so much
> >>> less efficient, how does Xenomai, which uses this scheme, manage to have
> >>> good performances on ARM?
> >>
> >> Xenomai has no heavily-used preempt_disable/enable that is built on top
> >> of thread_info. But I also have no numbers on this.
> >>
> >> I looked closer at the kernel dependencies on a fixed stack size.
> >> Besides current and thread_info, further features that make use of this
> >> are stack unwinding (boundary checks) and overflow checking. So while we
> >> can work around the dependency for some tracing requirements, I really
> >> see no point in heading for this long-term. It just creates more subtle
> >> patching needs in Adeos, and it also requires work on Xenomai side. I
> >> really think it's better provide a compatible context to reduce
> >> maintenance efforts.
> >>
> >> So I played a bit with converting RTDM tasks to in-kernel shadows. It
> >> works but needs more fine-tuning. My proposal for 2.6 now looks like this:
> >>
> >> - add mm-less shadow support to the nucleus (changes in
> >> xnarch_switch_to and xnshadow_map)
> >> - convert RTDM tasks to in-kernel shadows
> >> - switch current and thread_info on Xenomai task switches
> >> - make in-kernel skins optional, default off
> >> - let in-kernel skins dependent on disabled tracing
> >
> > I agree with your approach of moving to kernel space shadows, this is
> > the best way to get rid of foreign stacks. Those are a relic of the
> > kernel-only era, this introduces painful constraints, e.g. in low-level
> > thread switching code (i.e. so-called "hybrid" scheduling) and other
> > weirdnesses. This definitely has to go.
> >
> > I'm on a wait and see stance about generalizing the use of the ftrace
> > framework for our needs; like Gilles saw with ARM, I must admit that I
> > did notice a massive overhead on low-end ppc as well when we moved the
> > pipeline tracer over it. I'm aware of the mcount optimizations that
> > should be there when cycles really matter, and that ftrace does branch
> > directly to the trace function when only a single one exists, but this
> > may not be easy to keep after the generalization has taken place.
> > Anyway, I'll wait for more data to make my opinion.
>
> As I said, ftrace is more the a simple mcount-tracer. And it's standard,
> distros start to enable it in their production kernels these days
> (except for the function tracer).
>
> If the overhead of the ftrace's mcount is too high on low-end platforms
> (I personally haven't tried it there yet), it would probably be a good
> idea to develop some optimizations or allow some variant that does not
> suffer that much - but upstream then.
>
> >
> > However, those changes can't be targeted at 2.6. The rationale for
> > issuing 2.6 is really about cleaning up some ABI issues and merging
> > invasive but non-critical infrastructure changes, so that we can
> > maintain the 2.x series for a long time without being stuck by the ABI
> > constraints of 2.5.x. Your proposal is clean material for 3.x though,
> > given that we won't even have to bother with in-kernel skin APIs there.
>
> OK, I see. This will be too late for our next version I'm afraid.
>
> But maybe we can establish some intermediate solutions, at least for
> x86-64 where we do not have that many problems with kernel-stack-based
> information. That would allow to explore the potentials of ftrace and
> tools a bit earlier.
>
We could use your tree to host this provided you rebase on -head, and
feed the forge with that material when it is a ready for prime time.
> >
> > This said, I understand we need a branch to experiment radical changes
> > aimed at 3.x, but xenomai-head is no place for that. I have been
> > tracking -head for some time, doing massive cuts in the code to
> > eliminate most of the obvious legacy we don't want to care about anymore
> > (e.g. 2.4 kernel support, in-kernel skin APIs, and a few others). I will
> > shortly open a new tree on git.xenomai.org called "forge" with that code
> > base, so that we have the proper playground to get wild with our
> > chainsaws in the Xenomai core aimed at 3.x.
>
> Looking forward to seeing this.
>
> I actually ran into one compatibility conflict with my shadow rtdm task
> as well: Someone specified rtdm_task_init as RT-safe, and some strange
> network stack called RTnet indeed made use of this.
Yeah, kids these days...
> Would be easier to
> simply require a driver update for a new RTDM version than establishing
> a compatibility workaround.
>
It would make sense to me as well. There are not that many opportunity
to change some bad rules from a good game, and one of them happens now
with 3.x.
> Jan
>
--
Philippe.
^ permalink raw reply
* Re: Questions about CRUSH
From: Sage Weil @ 2010-10-07 20:50 UTC (permalink / raw)
To: Wido den Hollander; +Cc: ceph-devel
In-Reply-To: <1286482123.2633.17.camel@wido-laptop.pcextreme.nl>
Hi Wido!
On Thu, 7 Oct 2010, Wido den Hollander wrote:
> Hi,
>
> I'm working on a crushmap where I have my hosts spread out over 3 racks
> (leafs).
>
> I have 9 physical machines, each with one OSD, spread out over three
> racks.
>
> The replication level I intend to use is 3, my goal with this crushmap
> is to prevent two replicas being stored in the same rack.
>
> Now, this map seems fine to me, but what if one of the racks fails and
> the cluster starts to fix itself, then I would get two replicas in the
> same rack, wouldn't I?
Right.
> Is it better to have: leafs at root = (max replication level + 1) ?
>
> So, if I have my replication level set to 3, I should have 4 racks with
> each 3 OSD's, then the cluster could restore from a complete rack
> failure, without compromising my data safety.
>
> When a complete leaf (rack) fails, the other leafs should be able to
> store all the data, so if my replication level is set to 3, I should
> always have at least 1/3 of free space, otherwise a full recovery won't
> be possible, correct? (OSD's run out of disk space).
>
> Am I missing something here or is this the right approach?
Yeah, I think this is the right approach.
> And I'm not completely sure about:
>
> rule placein3racks {
rule placeinNracks {
> ruleset 0
> type replicated
> min_size 2
> max_size 2
min_size 2
max_size 10
> step take root
> step chooseleaf firstn 0 type rack
> step emit
> }
>
> Is that correct? Here I say that the first step should be to choose a
> rack where the replica should be saved. Should I also specify to choose
> a host afterwards?
The rule generalizes to N replicas, where N can be 2..10 (that's what the
min/max size fields are for). And the chooseleaf line is correct. That
chooses N leaves/devices that are nested beneath N distinct racks. Which
is what you want!
You could also do
step take root
step choose firstn 0 type rack
step choose firstn 1 type device
step emit
That would choose N racks, and then for each rack, choose a nested device.
The problem is when one of the racks it chooses has no (or few) online
devices beneath it, we fail to find a usable device, and the result set
will have <N devices. Chooseleaf doesn't have that problem.
sage
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 20:47 UTC (permalink / raw)
To: Anthony Liguori
Cc: Kevin Wolf, kvm, qemu-devel, ceph-devel, Christian Brunner
In-Reply-To: <4CAE24C5.8030007@codemonkey.ws>
On Thu, Oct 7, 2010 at 12:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/07/2010 01:41 PM, Yehuda Sadeh Weinraub wrote:
>>
>> On Thu, Oct 7, 2010 at 11:38 AM, Anthony Liguori<anthony@codemonkey.ws>
>> wrote:
>>
>>>
>>> On 10/07/2010 01:08 PM, Yehuda Sadeh Weinraub wrote:
>>>
>>>> On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori<anthony@codemonkey.ws>
>>>
...
>>> There's no fd at all? How do you get notifications about an
>>> asynchronous
>>> event completion?
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>
>>
>> (resending to list, sorry)
>>
>> The fd is hidden deep under in librados. We get callback notifications
>> for events completion.
>>
>
> How is that possible? Are the callbacks delivered in the context of a
> different thread? If so, don't you need locking?
Not sure I'm completely following you. The callbacks are delivered in
the context of a different thread, but won't run concurrently. Do you
see any specific concurrency issue? We can add some mutex protection
around at the aio callback, so that if librados turns multithreaded at
this point we're covered.
Thanks,
Yehuda
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Yehuda Sadeh Weinraub @ 2010-10-07 20:47 UTC (permalink / raw)
To: Anthony Liguori
Cc: Christian Brunner, malc, kvm, qemu-devel, Kevin Wolf, ceph-devel
In-Reply-To: <4CAE24C5.8030007@codemonkey.ws>
On Thu, Oct 7, 2010 at 12:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 10/07/2010 01:41 PM, Yehuda Sadeh Weinraub wrote:
>>
>> On Thu, Oct 7, 2010 at 11:38 AM, Anthony Liguori<anthony@codemonkey.ws>
>> wrote:
>>
>>>
>>> On 10/07/2010 01:08 PM, Yehuda Sadeh Weinraub wrote:
>>>
>>>> On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori<anthony@codemonkey.ws>
>>>
...
>>> There's no fd at all? How do you get notifications about an
>>> asynchronous
>>> event completion?
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>
>>
>> (resending to list, sorry)
>>
>> The fd is hidden deep under in librados. We get callback notifications
>> for events completion.
>>
>
> How is that possible? Are the callbacks delivered in the context of a
> different thread? If so, don't you need locking?
Not sure I'm completely following you. The callbacks are delivered in
the context of a different thread, but won't run concurrently. Do you
see any specific concurrency issue? We can add some mutex protection
around at the aio callback, so that if librados turns multithreaded at
this point we're covered.
Thanks,
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Savoy, Pavan @ 2010-10-07 20:46 UTC (permalink / raw)
To: Alan Cox
Cc: Jiri Slaby, gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, linux-bluetooth@vger.kernel.org
In-Reply-To: <20101007215943.45365f45@lxorguk.ukuu.org.uk>
> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Thursday, October 07, 2010 4:00 PM
> To: Savoy, Pavan
> Cc: Jiri Slaby; gregkh@suse.de; linux-kernel@vger.kernel.org;
> devel@driverdev.osuosl.org; linux-bluetooth@vger.kernel.org
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
>
> > But, I want to attach my data not when ldsic is opened, but when ldisc is
> registered.
> > I want to begin accessing the data when ldisc is opened.
>
> How can you attach per tty data when the ldisc is registered - the
> relevant tty driver might not even have been loaded at that point. The
> user may not even have been to the shop and bought it even !
>
> What sort of data is this ?
Data related to requesting the user-space to open/install the ldisc.
Imagine a UEVENT structure or PID of the user-space process to which I need
to send a signal .. I currently use rfkill.
> > to be like a bunch of helpers (1 for FM, 1 for GPS, 1 for NFC, 1 for power-
> management), also the problem of who owns the /dev/tty begins to occur,
> Bluetooth has a utility called hciattach, I don't want my FM radio software to
> run hciattach when /dev/radio0 is opened and communicated via FM.
>
> I would have assumed the hotplug script would have run your own attach
> and daemon and the FM radio etc would talk to the ldisc via other kernel
> interfaces it presented.
>
> So whenever the hardware is detected it would load the hardware driver
> The hardware driver would create a tty instance for each physical port
> The hotplug user space would run 'ti-st-attach' as a helper which would
> load the ldisc and set up the bluetooth as well as providing exported
> methods for FM radio etc.
Yes, pretty similar to what I am doing now. I have this daemon which waits
for events from my ldisc driver, and on receiving the notification it
opens the uart, ioctl's the TIOCSETD and allows the tty to be accessed over
the ldisc.
> > In any case, the ti-st/ seems better now by look of things, I certainly
> welcome suggestions to improve it.
> > Also, is there any plan to re-write whole of TTY like a the i2C or the SPI
> bus structure?
> >
> > Here I can imagine, all TTY line disciplines being sort of protocol/client
> drivers, the TTY sub-system in itself would be like the algos driver and then
> > The uart drivers (like 8250.c) can be the adapter drivers.. What say?
>
> They already are, with the one oddity being that something needs to have
> it opened from user space and to attach the ldisc. Thats fixable but hard
> to fix and I'm not aware of any plan to do so - mostly because nobody
> needs it so far.
Yes, that oddity was the reason this notification had to be done.
I could as well have opened it up on boot and attached the ldisc, but I chose
to use it whenever other drivers wanted to - as in when hci0 is UP, or /dev/radio0 is opened.
> Alan
^ permalink raw reply
* Re: OT: compilation
From: Grzesiek Sójka @ 2010-10-07 20:46 UTC (permalink / raw)
To: Pekka Paalanen; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20101007233420.1f763477-cxYvVS3buNOdIgDiPM52R8c4bpwCjbIv@public.gmane.org>
On 10/07/10 22:34, Pekka Paalanen wrote:
> Yes, it is CONFIG_LOCALVERSION_AUTO as far as I recall, disable that.
Where is it?? Which file??
^ permalink raw reply
* Attention
From: Liu Tai @ 2010-10-07 20:45 UTC (permalink / raw)
My Names are Mr Liu Tai Ling, I have a business bequest for you to handle with me, kindly indicate your interest along with your names, contact address, age, occupation and telephone number for further details. email: liutai.ling@yahoo.com.hk
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: H. Peter Anvin @ 2010-10-07 20:44 UTC (permalink / raw)
To: Vivek Goyal
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
yinghai@kernel.org, caiqian@redhat.com, tglx@linutronix.de,
linux-tip-commits@vger.kernel.org, Kexec Mailing List
In-Reply-To: <20101007192129.GC2581@redhat.com>
On 10/07/2010 12:21 PM, Vivek Goyal wrote:
>>
>> It would be easy enough to either deprecate or make it an alias for
>> crashkernel=...<896M, which is basically what Yinghai's patch does.
>
> Agreed.
>
> So Yinghai's patch is fine. I need to write a patch for introducing
> crashkernel=X<Y syntax to make the behavior explicit. Will do...
>
Sounds like a plan. Thanks!
-hpa
^ permalink raw reply
* Re: [tip:core/memblock] x86, memblock: Fix crashkernel allocation
From: H. Peter Anvin @ 2010-10-07 20:44 UTC (permalink / raw)
To: Vivek Goyal
Cc: caiqian@redhat.com, linux-tip-commits@vger.kernel.org,
Kexec Mailing List, linux-kernel@vger.kernel.org,
mingo@redhat.com, tglx@linutronix.de, yinghai@kernel.org
In-Reply-To: <20101007192129.GC2581@redhat.com>
On 10/07/2010 12:21 PM, Vivek Goyal wrote:
>>
>> It would be easy enough to either deprecate or make it an alias for
>> crashkernel=...<896M, which is basically what Yinghai's patch does.
>
> Agreed.
>
> So Yinghai's patch is fine. I need to write a patch for introducing
> crashkernel=X<Y syntax to make the behavior explicit. Will do...
>
Sounds like a plan. Thanks!
-hpa
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Steven Rostedt @ 2010-10-07 20:44 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Linus Torvalds, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
Andi Kleen, Paul E. McKenney
In-Reply-To: <20101007180737.GA4300@Krystal>
On Thu, 2010-10-07 at 14:07 -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> > I never mention affinity. As with trace-cmd, it assigns a process per
> > CPU, but those processes can be on any CPU that the scheduler chooses. I
> > could probably do it with a single process reading all the CPU fds too.
> > I might add that as an option.
>
> Your scheme works fine because you have only one stream (and thus one fd) per
> cpu. How would you map that with many streams per cpu ?
>
> Also, you might want to consider using threads rather than processes, to save
> the unnecessary VM swaps.
I thought about threads and could go back to them. I'd have to benchmark
to see the performance hit.
>
> >
> > >
> > > > Or do you have an fd per event per CPU, in which case the threads should just
> > > > poll off of their own fds.
> > >
> > > I have one fd per per-cpu buffer, but there can be many per-cpu buffers, each
> > > transporting a group of events. Therefore, I don't want to associate one thread
> > > per event group, because this would be a resource waste. Typically, only a few
> > > per-cpu buffers will be very active, and others will be very quiet.
> >
> > Lets not talk about threads, what about fds? I'm wondering why you have
> > many threads on the same fd?
>
> That's because I have fewer threads than file descriptors. So I can choose to
> either:
>
> 1) somehow assign each thread to many fds statically or
> 2) make each thread wait for data on all fds
>
> Option (2) adapts much better to workloads where a lots of data would come from
> many file descriptors from a single CPU: all threads can collaboratively work to
> extract the data.
OK, this is what I wanted to know. Now as Linus suggested, go and ask
other application developers (web server developers?) if this is
something that could be useful for them? If you get positive feedback,
have them Cc LKML and we can go from there.
Or, if you see that this type of programming is being done in Apache,
and if you can demonstrate that adding this features helps Apache (or
some other popular program), that would also be of benefit.
-- Steve
^ permalink raw reply
* [PATCH net-next] neigh: speedup neigh_resolve_output()
From: Eric Dumazet @ 2010-10-07 20:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1286456008.2912.171.camel@edumazet-laptop>
Le jeudi 07 octobre 2010 à 14:53 +0200, Eric Dumazet a écrit :
> Further improvements would need to use a seqlock instead of an rwlock to
> protect neigh->ha[], to not dirty neigh too often and remove two atomic
> ops.
>
I implemented this idea in following patch, on top on previous one.
[PATCH net-next] neigh: speedup neigh_resolve_output()
Add a seqlock in struct neighbour to protect neigh->ha[], and avoid
dirtying neighbour in stress situation (many different flows / dsts)
Dirtying takes place because of read_lock(&n->lock) and n->used writes.
Switching to a seqlock, and writing n->used only on jiffies changes
permits less dirtying.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/neighbour.h | 16 ++++++++++++
net/core/neighbour.c | 47 ++++++++++++++++++++++++--------------
net/ipv4/arp.c | 6 +---
net/sched/sch_teql.c | 8 +++---
4 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/include/net/neighbour.h b/include/net/neighbour.h
index a4538d5..f04e7a2 100644
--- a/include/net/neighbour.h
+++ b/include/net/neighbour.h
@@ -105,6 +105,7 @@ struct neighbour {
atomic_t refcnt;
atomic_t probes;
rwlock_t lock;
+ seqlock_t ha_lock;
unsigned char ha[ALIGN(MAX_ADDR_LEN, sizeof(unsigned long))];
struct hh_cache *hh;
int (*output)(struct sk_buff *skb);
@@ -302,7 +303,10 @@ static inline void neigh_confirm(struct neighbour *neigh)
static inline int neigh_event_send(struct neighbour *neigh, struct sk_buff *skb)
{
- neigh->used = jiffies;
+ unsigned long now = ACCESS_ONCE(jiffies);
+
+ if (neigh->used != now)
+ neigh->used = now;
if (!(neigh->nud_state&(NUD_CONNECTED|NUD_DELAY|NUD_PROBE)))
return __neigh_event_send(neigh, skb);
return 0;
@@ -373,4 +377,14 @@ struct neighbour_cb {
#define NEIGH_CB(skb) ((struct neighbour_cb *)(skb)->cb)
+static inline void neigh_ha_snapshot(char *dst, const struct neighbour *n,
+ const struct net_device *dev)
+{
+ unsigned int seq;
+
+ do {
+ seq = read_seqbegin(&n->ha_lock);
+ memcpy(dst, n->ha, dev->addr_len);
+ } while (read_seqretry(&n->ha_lock, seq));
+}
#endif
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 53cc548..54aef9c 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -294,6 +294,7 @@ static struct neighbour *neigh_alloc(struct neigh_table *tbl)
skb_queue_head_init(&n->arp_queue);
rwlock_init(&n->lock);
+ seqlock_init(&n->ha_lock);
n->updated = n->used = now;
n->nud_state = NUD_NONE;
n->output = neigh_blackhole;
@@ -1015,7 +1016,7 @@ out_unlock_bh:
}
EXPORT_SYMBOL(__neigh_event_send);
-static void neigh_update_hhs(struct neighbour *neigh)
+static void neigh_update_hhs(const struct neighbour *neigh)
{
struct hh_cache *hh;
void (*update)(struct hh_cache*, const struct net_device*, const unsigned char *)
@@ -1151,7 +1152,9 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
if (lladdr != neigh->ha) {
+ write_seqlock(&neigh->ha_lock);
memcpy(&neigh->ha, lladdr, dev->addr_len);
+ write_sequnlock(&neigh->ha_lock);
neigh_update_hhs(neigh);
if (!(new & NUD_CONNECTED))
neigh->confirmed = jiffies -
@@ -1214,6 +1217,7 @@ static inline bool neigh_hh_lookup(struct neighbour *n, struct dst_entry *dst,
{
struct hh_cache *hh;
+ smp_rmb(); /* paired with smp_wmb() in neigh_hh_init() */
for (hh = n->hh; hh; hh = hh->hh_next) {
if (hh->hh_type == protocol) {
atomic_inc(&hh->hh_refcnt);
@@ -1248,8 +1252,8 @@ static void neigh_hh_init(struct neighbour *n, struct dst_entry *dst,
kfree(hh);
return;
}
- read_unlock(&n->lock);
- write_lock(&n->lock);
+
+ write_lock_bh(&n->lock);
/* must check if another thread already did the insert */
if (neigh_hh_lookup(n, dst, protocol)) {
@@ -1263,13 +1267,13 @@ static void neigh_hh_init(struct neighbour *n, struct dst_entry *dst,
hh->hh_output = n->ops->output;
hh->hh_next = n->hh;
+ smp_wmb(); /* paired with smp_rmb() in neigh_hh_lookup() */
n->hh = hh;
if (unlikely(cmpxchg(&dst->hh, NULL, hh) != NULL))
hh_cache_put(hh);
end:
- write_unlock(&n->lock);
- read_lock(&n->lock);
+ write_unlock_bh(&n->lock);
}
/* This function can be used in contexts, where only old dev_queue_xmit
@@ -1308,16 +1312,18 @@ int neigh_resolve_output(struct sk_buff *skb)
if (!neigh_event_send(neigh, skb)) {
int err;
struct net_device *dev = neigh->dev;
+ unsigned int seq;
- read_lock_bh(&neigh->lock);
if (dev->header_ops->cache &&
!dst->hh &&
!(dst->flags & DST_NOCACHE))
neigh_hh_init(neigh, dst, dst->ops->protocol);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- neigh->ha, NULL, skb->len);
- read_unlock_bh(&neigh->lock);
+ do {
+ seq = read_seqbegin(&neigh->ha_lock);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol),
+ neigh->ha, NULL, skb->len);
+ } while (read_seqretry(&neigh->ha_lock, seq));
if (err >= 0)
rc = neigh->ops->queue_xmit(skb);
@@ -1344,13 +1350,16 @@ int neigh_connected_output(struct sk_buff *skb)
struct dst_entry *dst = skb_dst(skb);
struct neighbour *neigh = dst->neighbour;
struct net_device *dev = neigh->dev;
+ unsigned int seq;
__skb_pull(skb, skb_network_offset(skb));
- read_lock_bh(&neigh->lock);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- neigh->ha, NULL, skb->len);
- read_unlock_bh(&neigh->lock);
+ do {
+ seq = read_seqbegin(&neigh->ha_lock);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol),
+ neigh->ha, NULL, skb->len);
+ } while (read_seqretry(&neigh->ha_lock, seq));
+
if (err >= 0)
err = neigh->ops->queue_xmit(skb);
else {
@@ -2148,10 +2157,14 @@ static int neigh_fill_info(struct sk_buff *skb, struct neighbour *neigh,
read_lock_bh(&neigh->lock);
ndm->ndm_state = neigh->nud_state;
- if ((neigh->nud_state & NUD_VALID) &&
- nla_put(skb, NDA_LLADDR, neigh->dev->addr_len, neigh->ha) < 0) {
- read_unlock_bh(&neigh->lock);
- goto nla_put_failure;
+ if (neigh->nud_state & NUD_VALID) {
+ char haddr[MAX_ADDR_LEN];
+
+ neigh_ha_snapshot(haddr, neigh, neigh->dev);
+ if (nla_put(skb, NDA_LLADDR, neigh->dev->addr_len, haddr) < 0) {
+ read_unlock_bh(&neigh->lock);
+ goto nla_put_failure;
+ }
}
ci.ndm_used = jiffies_to_clock_t(now - neigh->used);
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index f353095..d8e540c 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -502,10 +502,8 @@ int arp_find(unsigned char *haddr, struct sk_buff *skb)
if (n) {
n->used = jiffies;
- if (n->nud_state&NUD_VALID || neigh_event_send(n, skb) == 0) {
- read_lock_bh(&n->lock);
- memcpy(haddr, n->ha, dev->addr_len);
- read_unlock_bh(&n->lock);
+ if (n->nud_state & NUD_VALID || neigh_event_send(n, skb) == 0) {
+ neigh_ha_snapshot(haddr, n, dev);
neigh_release(n);
return 0;
}
diff --git a/net/sched/sch_teql.c b/net/sched/sch_teql.c
index feaabc1..401af95 100644
--- a/net/sched/sch_teql.c
+++ b/net/sched/sch_teql.c
@@ -241,11 +241,11 @@ __teql_resolve(struct sk_buff *skb, struct sk_buff *skb_res, struct net_device *
}
if (neigh_event_send(n, skb_res) == 0) {
int err;
+ char haddr[MAX_ADDR_LEN];
- read_lock(&n->lock);
- err = dev_hard_header(skb, dev, ntohs(skb->protocol),
- n->ha, NULL, skb->len);
- read_unlock(&n->lock);
+ neigh_ha_snapshot(haddr, n, dev);
+ err = dev_hard_header(skb, dev, ntohs(skb->protocol), haddr,
+ NULL, skb->len);
if (err < 0) {
neigh_release(n);
^ permalink raw reply related
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Alan Cox @ 2010-10-07 21:08 UTC (permalink / raw)
To: Daniel Walker
Cc: Mike Frysinger, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Greg Kroah-Hartman, Ben Dooks, Alan Cox,
Kukjin Kim, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
In-Reply-To: <1286483831.23836.40.camel@c-dwalke-linux.qualcomm.com>
> > I would agree 100% with this for the driver in question. The tty_port
> > helpers now make it trivial to do so and it'll be small and clean as a
> > result.
>
> Can you give some example of other drivers which have done this?
The blackfin driver is probably the nicest example for a very simple
device but see also the USB serial drivers (complex example), the SDIO
serial support (shows how to do fancy hotpluggable device stuff with it).
Basically tty_port_open/tty_port_close/tty_port_hangup do all the icky
nasty POSIX open/close/hangup handling and provide you with simple
methods to implement activate/shutdown of a port and carrier detect etc
most of which you don't even need to supply.
You can also skip a lot of other stuff like modem lines - although I can
see why you might want to provide an emulated modem line response for a
console emulation.
Alan
^ permalink raw reply
* Re: [PATCH] OLPC: Add XO-1 poweroff support
From: Daniel Drake @ 2010-10-07 20:42 UTC (permalink / raw)
To: Andres Salomon; +Cc: tglx, mingo, hpa, x86, linux-kernel
In-Reply-To: <20101007130904.29350df2@debxo>
On 7 October 2010 21:09, Andres Salomon <dilinger@queued.net> wrote:
> Any particular reason why this can't be modular?
Because of the pm_power_off thing.
Also, a similar situation would be encountered with set_suspend_ops().
I don't really understand your suggestion. If we set it to NULL on
module unload then the power off would crash on shutdown, right?
Daniel
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network interface
From: Matt Domsch @ 2010-10-07 20:42 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Nijhawan, Vijay, Rose, Charles
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:05:14AM -0700, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
The config tools all take a netdevice name as their argument. What
would it look like then?
$ ifconfig $(netdevname 'Embedded NIC 1')
repeat for each tool that's called? This is similar to what we
proposed with the userspace patch and libnetdevname, so the lookup can
happen inside each app, rather than the system admin having to do the
translation themselves. That was rejected too...
otherwise, it's up to a human to do the translation in their head,
which isn't script-friendly.
-Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Matt Domsch @ 2010-10-07 20:42 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, K, Narendra, netdev@vger.kernel.org,
linux-hotplug@vger.kernel.org, linux-pci@vger.kernel.org,
Hargrave, Jordan, Nijhawan, Vijay, Rose, Charles
In-Reply-To: <AANLkTinP5WPDPvk+kq8vsyP=xC9qcoe+c=1EBp0XJNPk@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:05:14AM -0700, Kay Sievers wrote:
> On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> >> can't speak to their future plans. Narendra's kernel patch does,
> >> as has biosdevname, the udev helper we first wrote for this
> >> purpose, for several years.
> >
> > Then stick with that udev helper please :)
>
> What about just exporting this information in sysfs, and not touch the naming?
The config tools all take a netdevice name as their argument. What
would it look like then?
$ ifconfig $(netdevname 'Embedded NIC 1')
repeat for each tool that's called? This is similar to what we
proposed with the userspace patch and libnetdevname, so the lookup can
happen inside each app, rather than the system admin having to do the
translation themselves. That was rejected too...
otherwise, it's up to a human to do the translation in their head,
which isn't script-friendly.
-Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.