This reverts commit 244f46ae6e.
Alan Cox did the research, and just like the other radio protocols
zero-length frames have meaning because at the top level ROSE is
X.25 PLP.
So this zero-length filtering is invalid.
Signed-off-by: David S. Miller <[email protected]>
Hypervisor versions older than version 1.6.1 cannot handle
leaving the profile counter overflow interrupt chirping
when the system does a soft reset.
So use a reboot notifier to shut off the NMI watchdog.
Signed-off-by: David S. Miller <[email protected]>
We can't put 'mdio' until after we've used it in the
fsl_pq_mdio_bus_name() call.
Also fix error return values.
Signed-off-by: David S. Miller <[email protected]>
Sparc was missed in commit 2b1c6bd77d
("generic compat_sys_ustat"). We definitely need it, since our
__kernel_ino_t is "unsigned long".
Signed-off-by: David S. Miller <[email protected]>
This reverts commit f99bcff7a2.
Like netrom, Alan Cox says that zero lengths have real meaning
and are useful in this protocol.
Signed-off-by: David S. Miller <[email protected]>
This reverts commit a3ac80a130.
Alan Cox says that zero length writes do have special meaning
and are useful in this protocol.
Signed-off-by: David S. Miller <[email protected]>
As explained by Benjamin Herrenschmidt:
> CPU 0 is running the context, task->mm == task->active_mm == your
> context. The CPU is in userspace happily churning things.
>
> CPU 1 used to run it, not anymore, it's now running fancyfsd which
> is a kernel thread, but current->active_mm still points to that
> same context.
>
> Because there's only one "real" user, mm_users is 1 (but mm_count is
> elevated, it's just that the presence on CPU 1 as active_mm has no
> effect on mm_count().
>
> At this point, fancyfsd decides to invalidate a mapping currently mapped
> by that context, for example because a networked file has changed
> remotely or something like that, using unmap_mapping_ranges().
>
> So CPU 1 goes into the zapping code, which eventually ends up calling
> flush_tlb_pending(). Your test will succeed, as current->active_mm is
> indeed the target mm for the flush, and mm_users is indeed 1. So you
> will -not- send an IPI to the other CPU, and CPU 0 will continue happily
> accessing the pages that should have been unmapped.
To fix this problem, check ->mm instead of ->active_mm, and this
means:
> So if you test current->mm, you effectively account for mm_users == 1,
> so the only way the mm can be active on another processor is as a lazy
> mm for a kernel thread. So your test should work properly as long
> as you don't have a HW that will do speculative TLB reloads into the
> TLB on that other CPU (and even if you do, you flush-on-switch-in should
> get rid of any crap here).
And therefore we should be OK.
Signed-off-by: David S. Miller <[email protected]>
arch/sparc/kernel/time_64.c: In function ‘timer_interrupt’:
arch/sparc/kernel/time_64.c:732: error: ‘struct kernel_stat’ has no member named ‘irqs’
make[1]: *** [arch/sparc/kernel/time_64.o] Error 1
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
tlb_flush_mmu() needs to flush pending TLB entries before
processing the mmu_gather ->pages list.
Noticed by Benjamin Herrenschmidt.
Signed-off-by: David S. Miller <[email protected]>
Otherwise it might interrupt switch_to() midstream and use
half-cooked register window state.
Reported-by: Chris Torek <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
The change to make xfrm_state objects hash on source address
broke the case where such source addresses are wildcarded.
Fix this by doing a two phase lookup, first with fully specified
source address, next using saddr wildcarded.
Reported-by: Nicolas Dichtel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Only X86 32-bit uses a different alignment for "unsigned long long"
than it's 64-bit counterpart.
Therefore this compat translation is only correct, and only needed,
when either CONFIG_X86 or CONFIG_IA64.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
In compat mode, the cmdbuf->buf 64-bit address cookie can
potentially be only 32-bit aligned. Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.
Use get_unaligned() to fix.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
Platforms such as sparc64 have D-cache aliasing issues. We
cannot allow virtual mappings in different contexts to be such
that two cache lines can be loaded for the same backing data.
Updates to one cache line won't be seen by accesses to the other
cache line.
Code in sparc64 and other architectures solve this problem by
making sure that all userland mappings of MAP_SHARED objects have
the same virtual address base. They implement this by keying
off of the page offset, and using that to choose a suitably
consistent virtual address for mmap() requests.
Making things even worse, getting this wrong on sparc64 can result
in hangs during DRM lock acquisition. This is because, at least on
UltraSPARC-III, normal loads consult the D-cache but atomics such
as 'cas' (which is what cmpxchg() is implement using) only consult
the L2 cache. So if a D-cache alias is inserted, the load can
see different data than the atomic, and we'll loop forever because
the atomic compare-and-exchange will never complete successfully.
So to make this all work properly, we need to make sure that the
hash address computed by drm_map_handle() preserves the SHMLBA
relevant bits, and that's what this patch does for _DRM_SHM mappings.
As a historical note, many years ago this bug didn't exist because we
used to just use the low 32-bits of the address as the hash and just
hope for the best. This preserved the SHMLBA bits properly. But when
the hashtab code was added to DRM, this was no longer the case.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The variable 'max_pages' is ambiguous. There are two concepts
of "pages" being used in this function.
First, we have ATI GART pages which are always 4096 bytes.
Then, we have system pages which are of size PAGE_SIZE.
Eliminate the confusion by creating max_ati_pages and
max_real_pages. Calculate and use them as appropriate.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.
We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV. On the last close, we
release that surface.
Just to be doubly safe, we run the pcigart table setup with the main
surface control register clear.
Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.
However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.
Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd memory.
Adjust all of the ring_rptr access code as needed.
While we're here, kill the 'scratch' pointer in drm_radeon_private.
It's only used in the one place where it is initialized.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some system types (such as
sparc64 where the ioremap() return value is actually a physical I/O
address).
So access the area correctly, using gart_info->gart_table_location as
our guide.
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
As analyzed by Patrick McHardy, vlan needs to reset it's
netdev_ops pointer in it's ->init() function but this
leaves the compat method pointers stale.
Add a netdev_resync_ops() and call it from the vlan code.
Any other driver which changes ->netdev_ops after register_netdevice()
will need to call this new function after doing so too.
With help from Patrick McHardy.
Tested-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Based upon a report by Meelis Roos.
Sparc64 SBUS and PCI controllers use a combination of IMAP and ICLR
registers to manage device interrupts.
The IMAP register contains the "valid" enable bit as well as CPU
targetting information. Whereas the ICLR register is written with
zero at the end of handling an interrupt to reset the state machine
for that interrupt to IDLE so it can be sent again.
For PCI slot and SBUS slot devices we can have multiple interrupts
sharing the same IMAP register. There are individual ICLR registers
but only one IMAP register for managing those.
We represent each shared case with individual virtual IRQs so the
generic IRQ layer thinks there is only one user of the IRQ instance.
In such shared IMAP cases this is wrong, so if there are multiple
active users then a free_irq() call will prematurely turn off the
interrupt by clearing the Valid bit in the IMAP register even though
there are other active users.
Fix this by simply doing nothing in sun4u_disable_irq() and checking
IRQF_DISABLED during IRQ dispatch.
This situation doesn't exist in the hypervisor sun4v cases, so I left
those alone.
Tested-by: Meelis Roos <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
As reported by Stephen Rothwell.
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> net/rds/cong.c: In function 'rds_cong_set_bit':
> net/rds/cong.c:284: error: implicit declaration of function 'generic___set_le_bit'
> net/rds/cong.c: In function 'rds_cong_clear_bit':
> net/rds/cong.c:298: error: implicit declaration of function 'generic___clear_le_bit'
> net/rds/cong.c: In function 'rds_cong_test_bit':
> net/rds/cong.c:309: error: implicit declaration of function 'generic_test_le_bit'
Signed-off-by: David S. Miller <[email protected]>
'pap' is never used in ixgbe_dcb_hw_config_82599()
and 'eec' in ixgbe_acquire_eeptom() is only used when
status == 0 but GCC has some trouble seeing that.
Signed-off-by: David S. Miller <[email protected]>
request_firmware() gives vmalloc'd memory, which is not suitable
for pci_map_single() and friends.
Use a kmalloc()'d copy of the firmware for this DMA operation.
Signed-off-by: David S. Miller <[email protected]>
David S. Miller