New flag: LOOKUP_EXCL. Set before doing the final step of pathname
resolution on the paths that have LOOKUP_CREATE and O_EXCL.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
... and don't pass bogus flags when we are just looking for parent.
Fold __path_lookup_intent_open() into path_lookup_open() while we
are at it; that's the only remaining caller.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
My change
commit e2a6b85247
net: Enable TSO if supported by at least one device
didn't do what was intended because the netdev_compute_features
function was designed for conjunctions. So what happened was that
it would simply take the TSO status of the last constituent device.
This patch extends it to support both conjunctions and disjunctions
under the new name of netdev_increment_features.
It also adds a new function netdev_fix_features which does the
sanity checking that usually occurs upon registration. This ensures
that the computation doesn't result in an illegal combination
since this checking is absent when the change is initiated via
ethtool.
The two users of netdev_compute_features have been converted.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Once an endpoint has reached the SHUTDOWN-RECEIVED state,
it MUST NOT send a SHUTDOWN in response to a ULP request.
The Cumulative TSN Ack of the received SHUTDOWN chunk
MUST be processed.
This patch fix to process Cumulative TSN Ack of the received
SHUTDOWN chunk in SHUTDOWN_RECEIVED state.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If SHUTDOWN is received in SHUTDOWN-PENDING state, enpoint should enter
the SHUTDOWN-RECEIVED state and check the Cumulative TSN Ack field of
the SHUTDOWN chunk (RFC 4960 Section 9.2). If the SHUTDOWN chunk can
acknowledge all of the send DATA chunks, SHUTDOWN-ACK should be sent.
But now endpoint just silently discarded the SHUTDOWN chunk.
SHUTDOWN received in SHUTDOWN-PENDING state can happend when the last
SACK is lost by network, or the SHUTDOWN chunk can acknowledge all of
the received DATA chunks. The packet sequence(SACK lost) is like this:
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----------- DATA
<--- shutdown
Enter SHUTDOWN-PENDING state
SACK ----lost---->
SHUTDOWN(*1) ------------>
<----------- SHUTDOWN-ACK
(*1) silently discarded now.
This patch fix to handle SHUTDOWN in SHUTDOWN-PENDING state as the same
as ESTABLISHED state.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
To avoid dock driver is loaded after other drivers like libata, let's
make dock driver not a module.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If SHUTDOWN chunk is received Cumulative TSN Ack beyond the max tsn currently
send, SHUTDOWN chunk be accepted and the association will be broken. New data
is send, but after received SACK it will be drop because TSN in SACK is less
than the Cumulative TSN, data will be retrans again and again even if correct
SACK is received.
The packet sequence is like this:
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<----------- DATA (TSN=x-1)
<----------- DATA (TSN=x)
SHUTDOWN -----------> (Now Cumulative TSN=x+1000)
(TSN=x+1000)
<----------- DATA (TSN=x+1)
SACK -----------> drop the SACK
(TSN=x+1)
<----------- DATA (TSN=x+1)(retrans)
This patch fix this problem by terminating the association and respond to
the sender with an ABORT.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If ICMP packet too big message is received with MTU larger than current
PMTU, SCTP will still accept this ICMP message and sync the PMTU of assoc
with the wrong MTU.
Endpoing A Endpoint B
(ESTABLISHED) (ESTABLISHED)
ICMP --------->
(packet too big, MTU too larger)
sync PMTU
This patch fixed the problem by drop that ICMP message.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Canonicalize a few remaining header guards, with the exception for
those which are still in subarchitecture directories.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Drop double underscores from header guards in arch/x86/include. They
are used inconsistently, and are not necessary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Change header guards named "ASM_X86__*" to "_ASM_X86_*" since:
a. the double underscore is ugly and pointless.
b. no leading underscore violates namespace constraints.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Teach scripts/kconfig/Makefile and top-level Makefile that arch/*/Makefile
is allowed to say Kconfig := <whatever I want instead of arch/blah/Kconfig>.
Rewrite arch/um/Kconfig and arch/um/Kconfig.<subarch> so that the latter
would be top-level one (and include the pieces of the former).
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
we can get DEV_NULL defined for arch/um/drivers/null.c in less
convoluted ways, TYVM...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Long-term we want to split system.h and include barriers part from
underlying target; for now copy that part to sysdep.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Its only difference from underlying atomic.h used to be the include
of kernel.h; it's not needed there anymore.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
* turn asm/ldt.h into ldt.h; update the (very few) users
* take host_ldt.h into sysdep, kill symlink mess
* includes of asm/arch/ldt.h turn into asm/ldt.h now
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
the only theoretical reason for it these days is ppc; aside of uml/ppc
being dead, do_signal() would be happier in arch/powerpc/kernel/signal.h
anyway.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
a) the only difference between sigcontext and sysdep/sigcontext
is that the former contains externs for two long-dead functions.
Removed, switched the only user to sysdep/sigcontext
b) asm/sigcontext.h is removable - that of underlying architecture
would get used.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We can't just plop asm/* into it - userland helpers are built with it
in search path and seeing asm/* show up there suddenly would be a bad
idea.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
arch/ia64/sn/kernel/io_acpi_init.c:361: warning: format ‘%lx’ expects type ‘long unsigned int’, but argument 3 has type ‘long long unsigned int’
Signed-off-by: Len Brown <len.brown@intel.com>
In commit 48d6c64311 ("math-emu: Add
support for reporting exact invalid exception") code was added to
set the new FP_EX_INVALID_{IDI,ZDZ} exception flag bits.
However there is a missing break statement for the
_FP_CLS_COMBINE(FP_CLS_INF,FP_CLS_INF) switch case, the
code just falls into _FP_CLS_COMBINE(FP_CLS_ZERO,FP_CLS_ZERO)
which then proceeds to overwrite all of the settings.
Fix by adding the missing break.
Signed-off-by: David S. Miller <davem@davemloft.net>
cifs: handle the TCP_Server_Info->tsk field more carefully
We currently handle the TCP_Server_Info->tsk field without any locking,
but with some half-measures to try and prevent races. These aren't
really sufficient though. When taking down cifsd, use xchg() to swap
the contents of the tsk field with NULL so we don't end up trying
to send it more than one signal. Also, don't allow cifsd to exit until
the signal is received if we expect one.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
I'm trying to move the powerpc math-emu code to use the include/math-emu bits.
In doing so I've been using TestFloat to see how good or bad we are
doing. For the most part the current math-emu code that PPC uses has
a number of issues that the code in include/math-emu seems to solve
(plus bugs we've had for ever that no one every realized).
Anyways, I've come across a case that we are flagging underflow and
inexact because we think we have a denormalized result from a double
precision divide:
000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE
soft: 001.0000000000000 ..... syst: 001.0000000000000 ...ux
What it looks like is the results out of FP_DIV_D are:
D:
sign: 0
mantissa: 01000000 00000000
exp: -1023 (0)
The problem seems like we aren't normalizing the result and bumping the exp.
Now that I'm digging into this a bit I'm thinking my issue has to do with
the fix DaveM put in place from back in Aug 2007 (commit
405849610f):
[MATH-EMU]: Fix underflow exception reporting.
2) we ended up rounding back up to normal (this is the case where
we set the exponent to 1 and set the fraction to zero), this
should set inexact too
...
Another example, "0x0.0000000000001p-1022 / 16.0", should signal both
inexact and underflow. The cpu implementations and ieee1754
literature is very clear about this. This is case #2 above.
Here is the distilled glibc test case from Jakub Jelinek which prompted that
commit:
--------------------
#include <float.h>
#include <fenv.h>
#include <stdio.h>
volatile double d = DBL_MIN;
volatile double e = 0x0.0000000000001p-1022;
volatile double f = 16.0;
int
main (void)
{
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
d /= f;
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
e /= f;
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
return 0;
}
--------------------
It looks like the case I have we are exact before rounding, but think it
looks like the rounding case since it appears as if "overflow is set".
000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE = 001.0000000000000
I think the following adds the check for my case and still works for the
issue your commit was trying to resolve.
Signed-off-by: David S. Miller <davem@davemloft.net>
Al Viro