hwmon: (coretemp) Use get_online_cpus to avoid races involving CPU hotplug
coretemp_init loops with for_each_online_cpu, adding platform_devices
and sysfs interfaces, then calls register_hotcpu_notifier. There is a
race if a CPU is offlined or onlined after the loop, but before
register_hotcpu_notifier. The race might result in the absence of a
platform_device+sysfs interface for an online CPU, or the presence of
a platform_device+sysfs interface for an offline CPU. A similar race
occurs during coretemp_exit, after the module calls
unregister_hotcpu_notifier, but before it unregisters all devices, a
CPU might offline and a device for an offline CPU will exist for a
short while.
This fix surrounds for_each_online_cpu and register_hotcpu_notifier
with get_online_cpus+put_online_cpus; and surrounds
unregister_hotcpu_notifier and device unregistering with
get_online_cpus+put_online_cpus.
Build tested.
Signed-off-by: Silas Boyd-Wickizer <sbw@mit.edu> Signed-off-by: Jean Delvare <khali@linux-fr.org>
hwmon: (via-cputemp) Use get_online_cpus to avoid races involving CPU hotplug
via_cputemp_init loops with for_each_online_cpu, adding
platform_devices, then calls register_hotcpu_notifier. If a CPU is
offlined between the loop and register_hotcpu_notifier, then later
onlined, via_cputemp_device_add will attempt to add platform devices
with the same ID. A similar race occurs during via_cputemp_exit,
after the module calls unregister_hotcpu_notifier, a CPU might offline
and a device will exist for a CPU that is offline.
This fix surrounds for_each_online_cpu and register_hotcpu_notifier
with get_online_cpus+put_online_cpus; and surrounds
unregister_hotcpu_notifier and device unregistering with
get_online_cpus+put_online_cpus.
Build tested.
Signed-off-by: Silas Boyd-Wickizer <sbw@mit.edu> Acked-by: Harald Welte <laforge@gnumonks.org> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Shubhrajyoti D [Wed, 5 Sep 2012 00:05:26 +0000 (10:05 +1000)]
i2c: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Julia Lawall [Wed, 5 Sep 2012 00:05:26 +0000 (10:05 +1000)]
i2c-smbus: Convert kzalloc to devm_kzalloc
Converting kzalloc to devm_kzalloc simplifies the code and ensures that the
result, alert, is freed after the irq allocated by the subsequent
devm_request_irq. This in turn ensures that when an interrupt can be
triggered, the alert structure is still available.
The problem of a free after a devm_request_irq was found using the
following semantic match (http://coccinelle.lip6.fr/)
devm_request_irq@p1(e1,e2,...,x)
... when any
when != e2 = a
when != x = b
if (...) {
... when != e2 = c
when != x = d
free@p2(...,x,...);
...
return ...;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Wed, 5 Sep 2012 00:05:25 +0000 (10:05 +1000)]
i2c-i801: Support SMBus multiplexing on Asus Z8 series
Add support for SMBus multiplexing on Asus Z8 motherboard series. On
these boards, the memory slots are behind a GPIO-controlled I2C
multiplexer. Models with 6 or 12 memory slots have 2 segments behind
the multiplexer, while models with 18 memory slots have 3 such
segments.
On these boards, only the memory slots are behind the multiplexer,
so it is possible to keep the autodetection mechanism.
The code is generic enough so it could work on other boards as long as
the multiplexer is controlled by GPIO pins. For other forms of
multiplexing (for example using an I2C device) additional code will be
needed.
Thanks to Asus for providing a board to develop and test this feature,
as well as all the technical information required.
At the moment, the GPIO driver must be loaded before the i2c-i801
driver, but I hope to solve this soon, using deferred probing on
the i2c-mux-gpio side.
Jean Delvare [Wed, 5 Sep 2012 00:05:25 +0000 (10:05 +1000)]
i2c-mux: Add support for device auto-detection
Let I2C bus segments behind multiplexers have a class. This allows for
device auto-detection on these segments. As long as parent segments
don't share the same class, it should be fine.
I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I
left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I
don't know if this feature makes sense for the use cases of these
drivers.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Peter Korsgaard <peter.korsgaard@barco.com> Cc: David Daney <david.daney@cavium.com> Cc: Michael Lawnick <ml.lawnick@gmx.de> Cc: Rodolfo Giometti <giometti@linux.it>
Axel Lin [Wed, 5 Sep 2012 00:05:25 +0000 (10:05 +1000)]
i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y
This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let
I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE.
Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as
built-in or module, we also need to export the functions in i2c-designware-core.
This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y &&
CONFIG_I2C_DESIGNWARE_PCI=y:
LD drivers/i2c/busses/built-in.o
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int':
i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init':
i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl':
i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr':
i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer':
i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled':
i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel':
i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg':
i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable':
i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param':
i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable':
i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func':
i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int':
i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here
make[3]: *** [drivers/i2c/busses/built-in.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Tested-by: Jiri Slaby <jslaby@suse.cz> Cc: stable@vger.kernel.org [3.2+]
Emil Goode [Fri, 17 Aug 2012 17:31:04 +0000 (19:31 +0200)]
staging: wlan-ng: Fix problem with wrong arguments
The function pointer scan in struct cfg80211_ops is not
supposed to be assigned a function with a struct net_device
pointer as an argument. Instead access the net_device struct
in the following way:
struct net_device *dev = request->wdev->netdev;
sparse gives these warnings:
drivers/staging/wlan-ng/cfg80211.c:726:17: warning:
incorrect type in initializer (incompatible argument 2
(different base types))
expected int ( *scan )( ... )
got int ( extern [toplevel] *<noident> )( ... )
drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
initialization from incompatible pointer type [enabled by default]
drivers/staging/wlan-ng/cfg80211.c:726:2: warning:
(near initialization for ‘prism2_usb_cfg_ops.scan’)
[enabled by default]
Signed-off-by: Emil Goode <emilgoode@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In znet_probe(), strncmp() may access beyond 0x100000 and
trigger the below oops in kvm. Fix it by limiting the loop
under 0x100000-8. I suspect the limit could be further decreased
to 0x100000-sizeof(struct netidblk), however no datasheet at hand..
Ian Abbott [Fri, 31 Aug 2012 19:41:30 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AO output for das08jr-16-ao
Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
that knobbles the upper three-quarters of the output range for the
'das08jr-16-ao' board.
Ian Abbott [Fri, 31 Aug 2012 19:41:29 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AI encoding for das08jr-16-ao
The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
`ai_encoding` member set to `das08_encode12`. It should be set to
`das08_encode16` same as the 'das08jr/16' board. After all, this board
has 16-bit AI resolution.
The description of the A/D LSB register at offset 0 seems incorrect in
the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
resolution is only 12 bits. The diagrams of the A/D LSB and MSB
registers show 15 data bits and a sign bit, which matches what the
software expects for the `das08_encode16` AI encoding method.
Ian Abbott [Mon, 3 Sep 2012 15:39:43 +0000 (16:39 +0100)]
staging: comedi: das08: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`das08_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `das08_find_pci()`). It is decremented when the `detach` hook
(`das08_detach()`) is called to detach the device. However, when the
PCI device is attached automatically via the `attach_pci` hook
(`das08_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `das08_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:42 +0000 (16:39 +0100)]
staging: comedi: amplc_pci230: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pci230_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pci230_find_pci_dev()`). It is decremented when the `detach`
hook (`pci230_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pci230_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pci230_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:41 +0000 (16:39 +0100)]
staging: comedi: amplc_pc263: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pc263_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc263_find_pci_dev()`). It is decremented when the `detach`
hook (`pc263_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc263_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pc263_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:40 +0000 (16:39 +0100)]
staging: comedi: amplc_pc236: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pc236_attach()`) (called by the comedi core for the `COMEDI_DEVCONFIG`
ioctl), its reference count is incremented in the `for_each_pci_dev`
loop (in `pc236_find_pci_dev()`). It is decremented when the `detach`
hook (`pc236_detach()`) is called to detach the device. However, when
the PCI device is attached automatically via the `attach_pci` hook
(`pc236_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pc236_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:39 +0000 (16:39 +0100)]
staging: comedi: amplc_dio200: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`dio200_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `dio200_find_pci_dev()`). It is decremented
when the `detach` hook (`dio200_detach()`) is called to detach the
device. However, when the PCI device is attached automatically via the
`attach_pci` hook (`dio200_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `dio200_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Mon, 3 Sep 2012 15:39:38 +0000 (16:39 +0100)]
staging: comedi: amplc_pci224: Fix PCI ref count
When attaching a PCI device manually via the comedi driver `attach` hook
(`pci224_attach()`) (called by the comedi core for the
`COMEDI_DEVCONFIG` ioctl), its reference count is incremented in the
`for_each_pci_dev` loop (in `pci224_find_pci_dev()`). It is decremented
when the `detach` hook (`pci224_detach()`) is called to detach the
device. However, when the PCI device is attached automatically via the
`attach_pci` hook (`pci224_attach_pci()`, called at probe time via
`comedi_pci_auto_config()`) it's reference count is not incremented so
there will be an unmatched decrement when detaching the device.
Increment the PCI device reference count in `pci224_attach_pci()` to
correct the mismatch.
Once support for manual configuration has been removed from this driver,
the calls to `pci_dev_get()` and `pci_dev_put()` can be removed.
xfrm: Workaround incompatibility of ESN and async crypto
ESN for esp is defined in RFC 4303. This RFC assumes that the
sequence number counters are always up to date. However,
this is not true if an async crypto algorithm is employed.
If the sequence number counters are not up to date on sequence
number check, we may incorrectly update the upper 32 bit of
the sequence number. This leads to a DOS.
We workaround this by comparing the upper sequence number,
(used for authentication) with the upper sequence number
computed after the async processing. We drop the packet
if these numbers are different.
To do this, we introduce a recheck function that does this
check in the ESN case.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
The vlan encapsulation fields in the maximum flow defintion were
never updated when the representation changed before upstreaming.
In theory this could cause a kernel panic when a maximum length
flow is used. In practice this has never happened (to my knowledge)
because skb allocations are padded out to a cache line so you would
need the right combination of flow and packet being sent to userspace.
Jan Kara [Mon, 3 Sep 2012 14:50:42 +0000 (16:50 +0200)]
ext3: Fix fdatasync() for files with only i_size changes
Code tracking when transaction needs to be committed on fdatasync(2) forgets
to handle a situation when only inode's i_size is changed. Thus in such
situations fdatasync(2) doesn't force transaction with new i_size to disk
and that can result in wrong i_size after a crash.
Fix the issue by updating inode's i_datasync_tid whenever its size is
updated.
CC: <stable@vger.kernel.org> # >= 2.6.32 Reported-by: Kristian Nielsen <knielsen@knielsen-hq.org> Signed-off-by: Jan Kara <jack@suse.cz>
Eric Dumazet [Sat, 1 Sep 2012 03:19:57 +0000 (03:19 +0000)]
fq_codel: dont reinit flow state
When fq_codel builds a new flow, it should not reset codel state.
Codel algo needs to get previous values (lastcount, drop_next) to get
proper behavior.
Signed-off-by: Dave Taht <dave.taht@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Dave Taht <dave.taht@bufferbloat.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Suspending an open usbnet device results in constant
rescheduling of usbnet_bh.
commit 65841fd5 "usbnet: handle remote wakeup asap"
refactored the usbnet_bh code to allow sharing the
urb allocate and submit code with usbnet_resume. In
this process, a test for, and immediate return on,
ENOLINK from rx_submit was unintentionally dropped.
The rx queue will not grow if rx_submit fails,
making usbnet_bh reschedule itself. This results
in a softirq storm if the error is persistent.
rx_submit translates the usb_submit_urb error
EHOSTUNREACH into ENOLINK, so this is an expected
and persistent error for a suspended device. The
old code tested for this condition and avoided
rescheduling. Putting this test back.
Cc: <stable@vger.kernel.org> # v3.5 Cc: Ming Lei <ming.lei@canonical.com> Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
Thomas Graf [Mon, 3 Sep 2012 04:27:42 +0000 (04:27 +0000)]
sctp: Don't charge for data in sndbuf again when transmitting packet
SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and via
skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken up
by __sctp_write_space().
Buffer space charged via sctp_set_owner_w() is released in sctp_wfree()
which calls __sctp_write_space() directly.
Buffer space charged via skb_set_owner_w() is released via sock_wfree()
which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
Therefore if sctp_packet_transmit() manages to queue up more than sndbuf
bytes, sctp_wait_for_sndbuf() will never be woken up again unless it is
interrupted by a signal.
This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
Charging for the data twice does not make sense in the first place, it
leads to overcharging sndbuf by a factor 2. Therefore this patch only
charges a single byte in wmem_alloc when transmitting an SCTP packet to
ensure that the socket stays alive until the packet has been released.
This means that control chunks are no longer accounted for in wmem_alloc
which I believe is not a problem as skb->truesize will typically lead
to overcharging anyway and thus compensates for any control overhead.
Signed-off-by: Thomas Graf <tgraf@suug.ch> CC: Vlad Yasevich <vyasevic@redhat.com> CC: Neil Horman <nhorman@tuxdriver.com> CC: David Miller <davem@davemloft.net> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
HID_LOGITECH_DJ uses "default m", which enables it in default kernel
builds. Since this module just enables extra, non-critical
functionality for one particular piece of hardware (specifically,
differentiating multiple wireless keyboards and mice as separate input
devices rather than treating them as one device), and the hardware works
just fine with the default USB HID support, drop the "default m".
Stefan Weinhuber [Fri, 31 Aug 2012 08:52:13 +0000 (10:52 +0200)]
s390/partitions: make partition detection independent from DASD ioctls
In some usage scenarios it is desireable to work with disk images or
virtualized DASD devices. One problem that prevents such applications
is the partition detection in ibm.c. Currently it works only for
devices that support the BIODASDINFO2 ioctl, in other words, it only
works for devices that belong to the DASD device driver.
The information gained from the BIODASDINFO2 ioctl is only for a small
set of legacy cases abolutely necessary. All current VOL1, LNX1 and
CMS1 type of disk labels can be interpreted correctly without this
information, as long as the generic HDIO_GETGEO ioctl works and
provides a correct disk geometry.
This patch makes the ibm.c partition detection as independent as
possible from the BIODASDINFO2 ioctl. Only the following two cases are
still restricted to real DASDs:
- An FBA DASD, or LDL formatted ECKD DASD without any disk label.
- An old style LNX1 label (without large volume support) on a disk
with inconsistent device geometry.
Signed-off-by: Stefan Weinhuber <wein@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Fri, 31 Aug 2012 11:35:25 +0000 (13:35 +0200)]
s390/mm: change default addressing mode
Change the default addressing mode so that user space runs in primary space
and the kernel runs in home space.
In addition remove the "switch_amode" kernel parameter so all users who
already specified they want the new default behaviour will stay in the
"switched" mode instead of in the opposite they intended.
If there is a need to switch addressing modes, this can be done with the
"user_mode" kernel parameter: user_mode=home
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Thu, 30 Aug 2012 12:24:42 +0000 (14:24 +0200)]
s390/smp: avoid concurrent write to sigp status field
When a sigp instruction is issued it may store a status. This status is
currently stored in a per cpu field of the target cpu.
If multiple cpus issue a sigp instruction with the same target cpu
and a status is stored the result is not necessarily as expected.
Currently this is not an issue:
- on cpu hotplug no sigps, except "restart" and "sense" are sent to the
target cpu.
- on external call we don't look at the status if it is stored
- on sense running the condition code "status stored" is sufficient to
tell if a cpu is running or not
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Wed, 29 Aug 2012 12:12:20 +0000 (14:12 +0200)]
s390/cache: add cpu cache information to /proc/cpuinfo
Add a line for each cpu cache to /proc/cpuinfo.
Since we only have information of private cpu caches in sysfs we
add a line for each cpu cache in /proc/cpuinfo which will also
contain information about shared caches.
Allow user-space processes to use transactional execution (TX).
If the TX facility is available user space programs can use
transactions for fine-grained serialization based on the data
objects that are referenced during a transaction. This is
useful for lockless data structures and speculative compiler
optimizations.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Jan Glauber [Tue, 31 Jul 2012 08:52:05 +0000 (10:52 +0200)]
s390: add support for runtime instrumentation
Allow user-space threads to use runtime instrumentation (RI). To enable RI
for a thread there is a new s390 specific system call, sys_s390_runtime_instr,
that takes as parameter a realtime signal number. If the RI facility is
available the system call sets up a control block for the calling thread with
the appropriate permissions for the thread to modify the control block.
The user-space thread can then use the store and modify RI instructions to
alter the control block and start/stop the instrumentation via RION/RIOFF.
If the user specified program buffer runs full RI triggers an external
interrupt. The external interrupt is translated to a real-time signal that
is delivered to the thread that enabled RI on that CPU. The number of
the real-time signal is the number specified in the RI system call. So,
user-space can select any available real-time signal number in case the
application itself uses real-time signals for other purposes.
The kernel saves the RI control blocks on task switch only if the running
thread was enabled for RI. Therefore, the performance impact on task switch
should be negligible if RI is not used.
RI is only enabled for user-space mode and is disabled for the supervisor
state.
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
projects / karo-tx-linux.git / log