Re: [PATCH] sunrpc: add endian annotations

2005-09-05 Thread viro
On Mon, Sep 05, 2005 at 10:55:58PM +0400, Alexey Dobriyan wrote: > * usual s/u32/__be32/. > * add svc_getnl(), svc_putnl() in spirit of svc_getu32(), svc_putu32(). > They return and accept __be32 instead of __u32, respectively. > * convert to svc_getnl(), svc_putnl(). Umm... I'm not particulary

Re: [PATCH] sunrpc: add endian annotations

2005-09-05 Thread viro
BTW, _all_ callers of svc_getnl() have the form ntohl(svc_getnl(...)). Which means that at least this one definitely should convert to host-endian before returning... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More major

Re: [PATCH] sunrpc: add endian annotations

2005-09-06 Thread viro
On Tue, Sep 06, 2005 at 12:21:05PM +0400, Alexey Dobriyan wrote: > * usual s/u32/__be32/. > * add svc_getnl(): > Take network-endian value from buffer, convert to host-endian > one and return it. > * add svc_putnl(): > Take host-endian value, convert to network-endian one and put

Re: sunrpc: add endian annotations

2005-09-07 Thread viro
On Wed, Sep 07, 2005 at 03:15:52AM -0700, Alexey Dobriyan wrote: > On 9/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 06, 2005 at 12:21:05PM +0400, Alexey Dobriyan wrote: > > > * add svc_getnl(): > > > Take network-endian value from buffer, convert to host-endian > > > one

Re: net-2.6.20 rebased

2006-11-16 Thread Al Viro
On Thu, Nov 16, 2006 at 05:58:40AM -0500, David Miller wrote: > > I just rebased net-2.6.20 at: > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.20.git > > Al Viro has been going crazy with endianness and checksum type > sparse annotations, which brings the

Re: Kernel header changes break glibc build

2006-12-06 Thread Al Viro
On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > At the time they were added they were meant to be exported but netlink > has evolved and we now have a type safe API. Where? AFAICS, netlink might be considered type-safe only within an address family... - To unsubscribe from this l

Re: Kernel header changes break glibc build

2006-12-06 Thread Al Viro
On Wed, Dec 06, 2006 at 09:26:39PM +0100, Thomas Graf wrote: > * Al Viro <[EMAIL PROTECTED]> 2006-12-06 17:13 > > On Wed, Dec 06, 2006 at 03:31:46PM +0100, Thomas Graf wrote: > > > > > At the time they were added they were meant to be exported but netlink > >

Re: [NETLINK]: Schedule removal of old macros exported to userspace

2006-12-09 Thread Al Viro
On Sat, Dec 09, 2006 at 08:42:45PM -0500, Jeff Bailey wrote: > On 09/12/06, David Miller <[EMAIL PROTECTED]> wrote: > >You can't deprecate stuff visible to userspace, sorry Thomas, > >we just can't do it. > > > >You can migrate people to "better" interfaces, but you can't > >pull the rug out from a

Re: [2.6 patch] drivers/net/loopback.c: convert to module_init()

2006-12-13 Thread Al Viro
On Tue, Dec 12, 2006 at 05:17:56PM -0800, David Miller wrote: > From: Adrian Bunk <[EMAIL PROTECTED]> > Date: Tue, 12 Dec 2006 17:24:35 +0100 > > > This patch converts drivers/net/loopback.c to using module_init(). > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > I'm not %100 sure of t

Re: [PATCH 7/8] NetXen: Fix for PPC machines.

2006-12-27 Thread Al Viro
On Wed, Dec 27, 2006 at 07:58:54AM +, Christoph Hellwig wrote: > On Mon, Dec 18, 2006 at 05:53:59AM -0800, Amit S. Kale wrote: > > Signed-off-by: Amit S. Kale <[EMAIL PROTECTED]> > > > > netxen_nic.h |2 +- > > netxen_nic_init.c | 12 ++-- > > netxen_nic_main.c |4 ++-

[RFC] dependencies for platform drivers (was Re: ax88796: add superh to kconfig dependencies)

2007-11-08 Thread Al Viro
On Thu, Nov 08, 2007 at 04:31:05PM +0900, Magnus Damm wrote: > config AX88796 > tristate "ASIX AX88796 NE2000 clone support" > - depends on ARM || MIPS > + depends on ARM || MIPS || SUPERH You know, that really sucks more and more. How about doing the following: a) making i

NET_DMA: where do we ever call dma_skb_copy_datagram_iovec() with NULL pinned_list?

2007-07-20 Thread Al Viro
AFAICS, all callers of dma_skb_copy_datagram_iovec() are either * recursive for fragments, pass pinned_list unchanged or * called from tcp, with pinned_list coming from tp->ucopy.pinned_list and only when tp->ucopy.dma_chan is non-NULL. Now, all non-NULL assignments to ->dm

[PATCH] endianness bug in ip6_tunnel

2007-07-21 Thread Al Viro
the latter gives the wrong value on little-endian; As the matter of fact, on l-e it gives 0 - IPV6_TCLASS_MASK will be htonl(0x0ff0), i.e. on little-endian we have (something << 20) & 0xff0... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/net/ipv6/ip6_tunnel.c b/n

Re: [1/2] 2.6.23-rc1: known regressions

2007-07-23 Thread Al Viro
Submitter : Gabriel C <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? > Status : unknown >From 2a7e1148a9d3ee860dc2650c9a45288b120e250f Mon Sep 17 00:00:00 2001 From: Al Viro <[EMAIL PROTECTED]> Date: Mon, 23 Jul 2007 06:20:22 -0400 Subj

Re: [PATCH 1/2][RFC] Update net core to use devres.

2007-07-24 Thread Al Viro
On Tue, Jul 24, 2007 at 03:39:52PM -0700, [EMAIL PROTECTED] wrote: > * netdev_pci_remove_one() can replace simple pci device remove > functions > > * devm_alloc_netdev() is like alloc_netdev but allocates memory using devres. > alloc_netdev() can be removed once all drivers use devres. E

Re: [PATCH 1/2][RFC] Update net core to use devres.

2007-07-24 Thread Al Viro
On Tue, Jul 24, 2007 at 11:51:34PM +0100, Al Viro wrote: > On Tue, Jul 24, 2007 at 03:39:52PM -0700, [EMAIL PROTECTED] wrote: > > * netdev_pci_remove_one() can replace simple pci device remove > > functions > > > > * devm_alloc_netdev() is like alloc_netdev

Re: [PATCH 1/2][RFC] Update net core to use devres.

2007-07-24 Thread Al Viro
On Tue, Jul 24, 2007 at 04:26:21PM -0700, Brandon Philips wrote: > Could you point me to an example you have in mind? > > I quickly searched through a handful of the PCI device drivers and > couldn't find an example where the .remove function didn't do something > to the tune of: > > unregi

Re: [PATCH 1/2][RFC] Update net core to use devres.

2007-07-24 Thread Al Viro
On Wed, Jul 25, 2007 at 12:30:07AM +0100, Al Viro wrote: > On Tue, Jul 24, 2007 at 04:26:21PM -0700, Brandon Philips wrote: > > Could you point me to an example you have in mind? > > > > I quickly searched through a handful of the PCI device drivers and > > couldn&

[PATCH 3/4] pass (host-endian) cmd length as explicit argument to l2cap_conf_req()

2007-07-27 Thread Al Viro
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- net/bluetooth/l2cap.c | 20 +++- 1 files changed, 11 insertions(+), 9 deletions(-) diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c index 09126bf..03309d2 100644 --- a/net/bluetooth/l2cap.c +++ b/net/bluetooth/l

[PATCH 4/4] l2cap: don't mangle cmd.len

2007-07-27 Thread Al Viro
Since nobody uses it after we convert it to host-endian, no need to do that at all. At that point l2cap is endian-clean. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- net/bluetooth/l2cap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/net/bluetooth/l2cap.c

[PATCH 1/4] fix endianness bug in l2cap_sock_listen()

2007-07-27 Thread Al Viro
hat store something in ->psm are storing little-endian. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- net/bluetooth/l2cap.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c index 670ff95..b82cbdd 100644 --- a/

[PATCH 2/4] l2cap: endianness annotations

2007-07-27 Thread Al Viro
no code changes, just documenting existing types Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- include/net/bluetooth/l2cap.h | 50 net/bluetooth/l2cap.c | 27 +++-- 2 files changed, 39 insertions(+), 38 deletions(-)

Re: [PATCH] [374/2many] MAINTAINERS - PCNET32 NETWORK DRIVER

2007-08-13 Thread Al Viro
On Sun, Aug 12, 2007 at 11:46:49PM -0700, Joe Perches wrote: > On Sun, 2007-08-12 at 23:36 -0700, David Miller wrote: > > Ok, 374 patches is just rediculious. > > > > So many patches eats up an enormous amount of mailing list resources, > > and for these patches in particular there are few reasons

Re: [PATCH 0/3] cxgb3 driver update

2007-08-23 Thread Al Viro
On Wed, Aug 22, 2007 at 11:35:20PM -0700, Divy Le Ray wrote: > Hi Jeff, > > I'm submitting three more patches for inclusion in netdev#upstream. > These patches are built over the series I resent yesterday night. > The patch numbering reflects the stacking. > > Here is a brief description: > - a

Re: [PATCH] via-velocity: use standard VLAN interface (resend)

2007-08-24 Thread Al Viro
On Fri, Aug 24, 2007 at 01:56:49PM -0700, Stephen Hemminger wrote: > static void velocity_init_cam_filter(struct velocity_info *vptr) > { > struct mac_regs __iomem * regs = vptr->mac_regs; > + unsigned short vid; > - mac_set_cam(regs, 0, (u8 *) & (vptr->options.vid), >

Re: [PATCH] via-velocity: more cleanup

2007-08-24 Thread Al Viro
On Fri, Aug 24, 2007 at 02:40:45PM -0700, Stephen Hemminger wrote: > +static void mac_set_vlan_cam(struct mac_regs __iomem * regs, int idx, > + const u8 *addr) ITYM const u16 *, if not an outright u16. These casts (one below and ones in callers) really should die. > +

Re: That whole "Linux stealing our code" thing

2007-09-01 Thread Al Viro
On Sat, Sep 01, 2007 at 09:42:54PM -0400, Luis R. Rodriguez wrote: > We asked SFLC to work with us to make sure that everyone's copyrights > were respected in the right places, and that the licenses various developers > wanted for their copyrights were implemented correctly. The patch I sent > i

Re: That whole "Linux stealing our code" thing

2007-09-01 Thread Al Viro
On Sat, Sep 01, 2007 at 09:58:26PM -0400, Casey Dahlin wrote: > Suppose you saw some other variant of *nix that had some code you wanted > to use, but there was a gaping security hole in it. Wouldn't you patch > it before you incorporated it? and would it be your fault if this fix > made the cod

Re: Fwd: That whole "Linux stealing our code" thing

2007-09-02 Thread Al Viro
On Sun, Sep 02, 2007 at 03:00:46PM +0200, Igor Sobrado wrote: > >Not strictly true. They can either agree to a change and issue one or > >they can convey to other parties the right to change the terms. The GPL > >for example does this for version selection. > > So, under a dual-licensed BSD/GPL co

[PATCH] fix net_device leak in vlan

2007-09-03 Thread Al Viro
ference to net_device now... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c index 1583c5e..2a54691 100644 --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -562,8 +562,6 @@ static int register_vlan_device(struct net_device *real_dev,

[PATCH] mv643xx_eth: duplicate methods in initializer

2007-09-25 Thread Al Viro
Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/mv643xx_eth.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c index 6a117e9..456d1e1 100644 --- a/drivers/net/mv643xx_eth.c +++ b/drivers/net/mv643xx

[PATCH] kill eth_io_copy_and_sum()

2007-02-09 Thread Al Viro
it has almost no remaining users, so it's better to just outright kill it. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/3c503.c |3 +-- drivers/net/ac3200.c |3 +-- drivers/net/e2100.c |3 +-- drivers/net/es3210.c

Re: NetXen driver name

2007-02-12 Thread Al Viro
On Mon, Feb 12, 2007 at 09:12:56AM +0100, Andi Kleen wrote: > On Monday 12 February 2007 09:03, Amit Kale wrote: > > The already released kernel contains a broken driver. It broke due to some > > code rearrangement changes someone submitted to fix sparse warnings. s/sparse warnings/breakage on

Re: [PATCH 1/1] NetXen: Fix to get the driver working after sparse changes

2007-02-12 Thread Al Viro
On Mon, Feb 12, 2007 at 04:33:38AM -0800, Amit S. Kale wrote: > Signed-off-by: Amit S. Kale <[EMAIL PROTECTED]> ACK. My apologies - that pile of brainos had been introduced when I'd been fixing the set_bit() abuses in there (a bunch of places had been casting address of u32 to unsigned long * and

[PATCH] fix atl1 braino

2007-02-12 Thread Al Viro
Spot the bug... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c index 08b2d78..e28707a 100644 --- a/drivers/net/atl1/atl1_hw.c +++ b/drivers/net/atl1/atl1_hw.c @@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw *h

[PATCH] endianness annotations and fixes for olympic

2007-12-16 Thread Al Viro
y had hit fragmented packets during the testing of PPC fixes. PS: Ken Aaker cc'd on assumption that he is the same guy who'd done the original set of PPC fixes in olympic Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/net/tokenring/olympic.c b/drivers/net/tokenr

Re: [git patches] net driver fixes

2007-12-22 Thread Al Viro
On Sun, Dec 23, 2007 at 12:33:14AM -0500, Jeff Garzik wrote: > > A couple [minorly] notable wireless bug fixes, and plenty of viro fixes > for obscure issues :) Heh... FWIW, forcedeth patch (sent your way about two weeks ago) also belongs in the same set. If you need a rese

Re: [git patches] net driver fixes

2007-12-22 Thread Al Viro
On Sun, Dec 23, 2007 at 01:42:14AM -0500, Jeff Garzik wrote: > I applied it to #upstream (2.6.25) since forcedeth is not on any > big-endian platforms AFAIK. All right, then... I hadn't been sure if it's onboard-only, that's all. > I have an epic100 card too if you need it (though it sounds li

[RFC] potential bugs in nexten

2007-12-23 Thread Al Viro
* what are default: doing in netxen_nic_hw_write_wx()/netxen_nic_hw_read_wx()? Unlike all other cases they do iomem->iomem copying and AFAICS they are never actually triggered. * netxen_nic_flash_print() reads the entire user_info from card *in* *host-endian*, then uses user_info.serial_number[]

[RFC] potential bug in cxgb3

2007-12-23 Thread Al Viro
int t3_seeprom_wp(struct adapter *adapter, int enable) { return t3_seeprom_write(adapter, EEPROM_STAT_ADDR, enable ? 0xc : 0); } looks fishy, since t3_seeprom_write() takes the last argument in little-endian, converts to host-endian and feeds it to pci_write_config_dword(). Passing it a

[PATCH] via-velocity big-endian support

2007-12-23 Thread Al Viro
, but that's in the famous last words category... Review and testing is welcome. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c index 35cd65d..0fa1e4b 100644 --- a/drivers/net/via-velocity.c +++ b/drivers/net/via-velo

[PATCH] s2io LRO bugs

2007-12-23 Thread Al Viro
th the value picked from earlier packet. Doing that without ntohl() is an interesting idea and it might even work occasionally; unfortunately, it's quite broken. Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/s2io.c | 20 ++-- drivers/net/s2io.h |

[RFC] skge csum problems

2007-12-24 Thread Al Viro
Both variants of skge (drivers/net and drivers/net/sk98lin/ resp.) have the same problem with rx checksums. They pick checksum from rx descriptor and use it as-is. Normally that would be the right thing to do. However, skge is told to byteswap descriptors on big-endian boxen. Checksum i

Re: [RFC] skge csum problems

2007-12-24 Thread Al Viro
On Mon, Dec 24, 2007 at 02:15:40PM +0100, Andi Kleen wrote: > Al Viro <[EMAIL PROTECTED]> writes: > > > > Checksum is fixed-endian and we want it that way; IOW, what we end up > > storing in skb->csum should be fixed-endian as well. > > AFAIK skb->csum is a

Re: [RFC] skge csum problems

2007-12-24 Thread Al Viro
On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote: > > you will get the same behaviour on big- and little-endian boxen, even though > > the intermediate integer values will be of course different. > > > > skb->csum *must* be stored in the same order on l-e and b-e boxen; that > > w

Re: [PATCH] via-velocity big-endian support

2007-12-25 Thread Al Viro
On Tue, Dec 25, 2007 at 11:43:33PM +0100, Francois Romieu wrote: > > +#define DESC_OWNER cpu_to_le16(0x8000) > > + > > DESC_OWNER does not seem to be used. *nod* That should be removed. > [...] > > +enum { > > + RX_INTEN = __constant_cpu_to_le16(0x8000) > > +}; > > Can we avoid using cpu_to_

Re: [patch 7/7] netxen: fix byte-swapping in tx and rx

2007-12-26 Thread Al Viro
On Wed, Dec 26, 2007 at 10:23:59AM -0800, [EMAIL PROTECTED] wrote: > This cleans up some unnecessary byte-swapping while setting up tx and > interpreting rx desc. The 64 bit rx status data should be converted > to host endian format only once and the macros just need to extract > bitfields. > -

Re: [patch 7/7] netxen: fix byte-swapping in tx and rx

2007-12-26 Thread Al Viro
On Wed, Dec 26, 2007 at 03:29:22PM -0800, Dhananjay Phadke wrote: > I agree for tx desc, the compiler would optimize. > > But for rx (status) desc, I didn't like multiple le64_to_cpu() > for extracting various fields out of same status dword. Fair enough; AFAICS, on rx side you don't mess with c

Re: [PATCH] via-velocity big-endian support

2007-12-28 Thread Al Viro
ck with one >convention in a given driver. Point taken... * kill multibyte bitfields * annotate * add missing conversions * fix a couple of brainos in zerocopy stuff (fortunately, it's ifdef'ed out) Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- drivers/net/via-velocity

Re: [PATCH] Force UNIX domain sockets to be built in

2007-12-31 Thread Al Viro
On Mon, Dec 31, 2007 at 03:03:20PM +0100, Bodo Eggert wrote: > On Mon, 31 Dec 2007, David Miller wrote: > > From: Bodo Eggert <[EMAIL PROTECTED]> > > > > As suggested by Adrian Bunk, UNIX domain sockets should always be built > > > in > > > on normal systems. This is especially true since udev n

Re: sparc oops in ip_fast_csum

2008-01-05 Thread Al Viro
On Fri, Jan 04, 2008 at 06:37:36PM +0100, Mariusz Kozlowski wrote: > Hello, > > This comes from the Linus latest linux-2.6 tree. Randomly happened. > Can't reproduce that. More info below. ip_fast_csum() called from raw_send_hdrinc() from raw_sendmsg() ran through the page boundary into u

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-05 Thread Al Viro
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: > Rank 3: d_splice_alias > NULL pointer deref > Reported 3 times > Happens in the isofs code > Only seen in 2.6.24-rc5-mm1 > More info: http://www.kerneloops.org/search.php?search=d_splice_alias in -rc6

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-05 Thread Al Viro
On Sat, Jan 05, 2008 at 01:06:17PM -0800, Arjan van de Ven wrote: > The http://www.kerneloops.org website collects kernel oops and > warning reports from various mailing lists and bugzillas as well as > with a client users can install to auto-submit oopses. > Below is a top 10 list of the oopses co

Re: sparc oops in ip_fast_csum

2008-01-05 Thread Al Viro
On Sun, Jan 06, 2008 at 11:22:04AM +1100, Herbert Xu wrote: > Actually if you read the code for ip_fast_csum it's obvious what has > happened. %o1 == iph->ihl contains the value 2 which is bogus. > > [IPV4] raw: Strengthen check on validity of iph->ihl > > We currently check that iph->ihl is bo

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-07 Thread Al Viro
On Mon, Jan 07, 2008 at 07:26:12PM -0800, Linus Torvalds wrote: > I usually just compile a small program like > > const char array[]="\xnn\xnn\xnn..."; > > int main(int argc, char **argv) > { > printf("%p\n", array); > *(int *)0=0; > } Heh. I

Re: Top 10 kernel oopses for the week ending January 5th, 2008

2008-01-09 Thread Al Viro
to kick_rdev_from_array() * fold unbind_rdev_from_array() into it (no other callers anymore) * take export_rdev() into failure case in bind_rdev_to_array() * in kick_rdev_from_array() do what export_rdev() does sans kobject_put() and do that before schedule_work(). Take kobje

Re: [PATCH] mv643xx: fix byte order when checksum offload is enabled

2008-01-19 Thread Al Viro
On Sat, Jan 19, 2008 at 07:27:38PM +, Byron Bradley wrote: > case IPPROTO_UDP: > cmd_sts |= ETH_UDP_FRAME; > - desc->l4i_chk = udp_hdr(skb)->check; > + desc->l4i_chk = htons(udp_hdr(skb)->check); >

Re: [PATCH] net: add sparse annotation to ptype_seq_start/stop

2008-01-20 Thread Al Viro
On Sun, Jan 20, 2008 at 09:03:55PM -0800, Paul E. McKenney wrote: > On Sun, Jan 20, 2008 at 03:21:46PM -0800, Stephen Hemminger wrote: > > Get rid of some more sparse warnings. > > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > Adding Josh to CC -- is __acquires() case-insensitive?

Re: [PATCH 1/1][TCP]: break missing at end of switch statement

2007-10-01 Thread Al Viro
On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote: > [TCP]: break missing at end of switch statement > > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]> > --- > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -3129,6 +3129,7 @@ static void tcp_reset(struct sock *sk) >

Re: [PATCH 1/1][TCP]: break missing at end of switch statement

2007-10-01 Thread Al Viro
On Mon, Oct 01, 2007 at 02:02:10PM +0100, Gerrit Renker wrote: > Quoting Al Viro: > | On Mon, Oct 01, 2007 at 01:32:43PM +0100, Gerrit Renker wrote: > | > [TCP]: break missing at end of switch statement > | > > | > Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]&g

Re: 2.6.23-mm1

2007-10-12 Thread Al Viro
On Fri, Oct 12, 2007 at 12:13:25AM -0700, Andrew Morton wrote: > I always forget to test uml. But a quick test build seems to work until > it hits this: > > arch/um/drivers/slip_kern.c: In function 'slip_init': > arch/um/drivers/slip_kern.c:34: error: 'struct net_device' has no member > named 'h

Re: Files, sockets, and closing

2007-10-26 Thread Al Viro
On Fri, Oct 26, 2007 at 02:03:19PM -0700, Stephen Hemminger wrote: > Looking at this bug: > http://bugzilla.kernel.org/show_bug.cgi?id=9149 > > Exposes some rather deep issues in the filesystem/socket/inet/tcp > layering. It seems that sys_close() zaps the file table entry, but > since each thread

Re: Files, sockets, and closing

2007-10-26 Thread Al Viro
On Fri, Oct 26, 2007 at 03:09:01PM -0700, Stephen Hemminger wrote: > > close() from another thread is not a way to abort blocked accept(). Never > > promised to be that. Just as close() from another thread is not a way to > > abort blocked write() or read() or sendmsg() or... > > The problem is

Re: NFSroot hangs with bad unlock balance in Linux next

2016-05-09 Thread Al Viro
On Mon, May 09, 2016 at 08:21:38AM -0700, Tony Lindgren wrote: > Looks like with both patches applied I still also get this eventually: > > = > [ BUG: bad unlock balance detected! ] > 4.6.0-rc7-next-20160509+ #1264 Not tainted >

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

2016-05-27 Thread Al Viro
On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote: > @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct > lib_info *libs) > > res = prepare_binprm(&bprm); > > - if (!IS_ERR_VALUE(res)) > + if (res >= 0) if (res == 0), please - prepare_bin

[git pull] sock_recvmsg() redundant argument

2016-04-09 Thread Al Viro
scm/linux/kernel/git/viro/vfs.git for-davem for you to fetch changes up to 2da62906b1e298695e1bb725927041cd59942c98: [net] drop 'size' argument of sock_recvmsg() (2016-03-28 13:57:51 -0400) ---- Al Viro (1): [net] drop &

[cavium] weirdness in cnnic_alloc_aligned_dma()

2015-12-12 Thread Al Viro
IMO ptr = (void *)__get_free_pages(GFP_KERNEL, get_order(size)); if ((unsigned long)ptr & 0x07) { free_pages((unsigned long)ptr, get_order(size)); ptr = N

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-20 Thread Al Viro
On Mon, Oct 19, 2015 at 06:45:32PM -0700, Eric Dumazet wrote: > On Tue, 2015-10-20 at 02:12 +0100, Alan Burlison wrote: > > > Another problem is that if I call close() on a Linux socket that's in > > accept() the accept call just sits there until there's an incoming > > connection, which succeed

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-21 Thread Al Viro
On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote: > >There's going to be a notion of "last close"; that's what this refcount is > >about and _that_ is more than implementation detail. > > Yes, POSIX distinguishes between "file descriptor" and "file > description" (ugh!) and the close

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-21 Thread Al Viro
On Wed, Oct 21, 2015 at 02:18:30PM -0700, Eric Dumazet wrote: > On Wed, 2015-10-21 at 18:04 +0200, casper@oracle.com wrote: > > > It is only expensive within the process itself. > > thread synchro would require additional barriers to maintain this state, > for a very unlikely case. > > The

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-21 Thread Al Viro
On Wed, Oct 21, 2015 at 10:33:04PM +0200, casper@oracle.com wrote: > > >On Wed, Oct 21, 2015 at 03:38:51PM +0100, Alan Burlison wrote: > > > >> >There's going to be a notion of "last close"; that's what this refcount is > >> >about and _that_ is more than implementation detail. > >> > >> Yes,

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-21 Thread Al Viro
On Thu, Oct 22, 2015 at 05:17:50AM +0100, Alan Burlison wrote: > It's been said that the current mechanisms in Linux & some BSD > variants can be subject to races You do realize that it goes for the entire area? And the races found in this thread are in the BSD variant that tries to do something

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-21 Thread Al Viro
On Thu, Oct 22, 2015 at 05:44:58AM +0100, Al Viro wrote: > Except that in this case "correctness" is the matter of rather obscure and > ill-documented areas in POSIX. Don't get me wrong - this semantics isn't > inherently bad, but it's nowhere near bein

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 02:14:42PM +0100, Alan Burlison wrote: > The issues I hit were in the context of application porting, where > the APIs in question are covered by POSIX. The Linux manpages for > open(), close(), socket(), dup2() and shutdown() all claim > POSIX.1-2001 conformance. If perfor

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 08:34:19AM +0200, casper@oracle.com wrote: > > > >And I'm really curious about the things Solaris would do with dup2() there. > >Does it take into account the possibility of new accept() coming just as > >dup2() is trying to terminate the ongoing ones? Is there a wind

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 11:55:42AM +0100, Alan Burlison wrote: > On 22/10/2015 05:21, Al Viro wrote: > > >>Most of the work on using a file descriptor is local to the thread. > > > >Using - sure, but what of cacheline dirtied every time you resolve a > >descrip

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 06:39:34PM +0100, Alan Burlison wrote: > On 22/10/2015 18:05, Al Viro wrote: > > >Oh, for... Right in this thread an example of complete BS has been quoted > >from POSIX close(2). The part about closing a file when the last descriptor > >gets clo

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 08:24:51PM +0200, casper@oracle.com wrote: > The external behaviour atomic; you cannot distinguish the order > between the closing of the original file (and waking up other threads > waiting for a record lock) or changing the file referenced by that newfd. > > But this

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-22 Thread Al Viro
On Thu, Oct 22, 2015 at 09:51:05PM +0200, casper@oracle.com wrote: > > >On Thu, Oct 22, 2015 at 08:24:51PM +0200, casper@oracle.com wrote: > > > >> The external behaviour atomic; you cannot distinguish the order > >> between the closing of the original file (and waking up other threads > >

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-23 Thread Al Viro
On Thu, Oct 22, 2015 at 09:50:10PM +0200, casper@oracle.com wrote: > >Sigh... It completely fails to mention descriptor-passing. Which > > a) is relevant to what "last close" means and > > b) had been there for nearly the third of a century. > > Why is that different? These clearly

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-23 Thread Al Viro
On Fri, Oct 23, 2015 at 06:30:25PM +, David Holland wrote: > So, I'm coming late to this discussion and I don't have the original > context; however, to me this cited behavior seems undesirable and if I > ran across it in the wild I would probably describe it as a bug. Unfortunately, that's p

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-23 Thread Al Viro
On Fri, Oct 23, 2015 at 11:52:34AM +0200, casper@oracle.com wrote: > > > >Ho-hum... It could even be made lockless in fast path; the problems I see > >are > > * descriptor-to-file lookup becomes unsafe in a lot of locking > >conditions. Sure, most of that happens on the entry to some sy

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-27 Thread Al Viro
On Tue, Oct 27, 2015 at 10:52:46AM +, Alan Burlison wrote: > Unfortunately Hadoop isn't the only thing that pulls the shutdown() > trick, so I don't think there's a simple fix for this, as discussed > earlier in the thread. Having said that, if close() on Linux also > did an implicit shutdown()

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-28 Thread Al Viro
[Linus and Dave added, Solaris and NetBSD folks dropped from Cc] On Tue, Oct 27, 2015 at 05:13:56PM -0700, Eric Dumazet wrote: > On Tue, 2015-10-27 at 23:17 +, Al Viro wrote: > > > * [Linux-specific aside] our __alloc_fd() can degrade quite badly > > with some

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-28 Thread Al Viro
On Wed, Oct 28, 2015 at 07:47:57AM -0700, Eric Dumazet wrote: > On Wed, 2015-10-28 at 06:24 -0700, Eric Dumazet wrote: > > > Before I take a deep look at your suggestion, are you sure plain use of > > include/linux/percpu-refcount.h infra is not possible for struct cred ? > > BTW, I am not convin

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-28 Thread Al Viro
On Wed, Oct 28, 2015 at 02:44:28PM -0700, Eric Dumazet wrote: > Well, all this complexity goes away with a O_FD_FASTALLOC / > SOCK_FD_FASTALLOC bit in various fd allocations, which specifically > tells the kernel we do not care getting the lowest possible fd as POSIX > mandates. ... which won't d

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-28 Thread Al Viro
On Wed, Oct 28, 2015 at 04:08:29PM -0700, Eric Dumazet wrote: > > > Except for legacy stuff and stdin/stdout/stderr games, I really doubt > > > lot of applications absolutely rely on the POSIX thing... > > > > We obviously can't turn that into default behaviour, though. BTW, what > > distribution

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-28 Thread Al Viro
On Wed, Oct 28, 2015 at 08:29:41PM -0700, Eric Dumazet wrote: > But this is an optimization : If you do not use the initial dup2(), the > fd array can be automatically expanded if needed (all slots are in use) Whee... > No locking change. files->file_lock is still taken. > > We only want to min

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-29 Thread Al Viro
On Thu, Oct 29, 2015 at 04:15:33PM +, Alan Burlison wrote: > There was an attempt to interpret POSIX that way, with which I still > disagree. If a FD is closed or reassigned then any current pending > operations on it should be terminated. Could the esteemed sir possibly be ars^H^H^Hprevailed

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Al Viro
On Fri, Oct 30, 2015 at 10:18:12AM -0700, Linus Torvalds wrote: > I do wonder if we couldn't just speed up the bitmap allocator by an > order of magnitude. It would be nicer to be able to make existing > loads faster without any new "don't bother with POSIX semantics" flag. > > We could, for exam

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Al Viro
On Fri, Oct 30, 2015 at 05:43:21PM +, David Laight wrote: > ISTM that the correct call should be listen(fd, 0); > Although that doesn't help a thread stuck in recvmsg() for a datagram. > > It is also tempting to think that close(fd) should sleep until all > io activities using that fd have co

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Al Viro
On Fri, Oct 30, 2015 at 02:50:46PM -0700, Linus Torvalds wrote: > Anyway. This is a pretty simple patch, and I actually think that we > could just get rid of the "next_fd" logic entirely with this. That > would make this *patch* be more complicated, but it would make the > resulting *code* be simp

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-30 Thread Al Viro
On Fri, Oct 30, 2015 at 04:52:41PM -0700, Linus Torvalds wrote: > I really suspect this patch is "good enough" in reality, and I would > *much* rather do something like this than add a new non-POSIX flag > that people have to update their binaries for. I agree with Eric that > *some* people will d

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-31 Thread Al Viro
On Fri, Oct 30, 2015 at 04:52:41PM -0700, Linus Torvalds wrote: > I really suspect this patch is "good enough" in reality, and I would > *much* rather do something like this than add a new non-POSIX flag > that people have to update their binaries for. I agree with Eric that > *some* people will do

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-31 Thread Al Viro
On Sat, Oct 31, 2015 at 12:54:50PM -0700, Linus Torvalds wrote: > On Sat, Oct 31, 2015 at 12:34 PM, Al Viro wrote: > > > > ... and here's the current variant of mine. > > Ugh. I really liked how simple mine ended up being. Yours is definitely not. Note that it'

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-10-31 Thread Al Viro
On Sat, Oct 31, 2015 at 02:23:31PM -0700, Linus Torvalds wrote: > The other stuff we probably can't do all that much about. Unless we > decide to go for some complicated lockless optimistic file descriptor > allocation scheme with retry-on-failure instead of locks. Which I'm > sure is possible, bu

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-11-01 Thread Al Viro
On Sat, Oct 31, 2015 at 08:29:29PM +, Al Viro wrote: > On Sat, Oct 31, 2015 at 12:54:50PM -0700, Linus Torvalds wrote: > > On Sat, Oct 31, 2015 at 12:34 PM, Al Viro wrote: > > > > > > ... and here's the current variant of mine. > > > > Ugh. I

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-11-01 Thread Al Viro
On Sun, Nov 01, 2015 at 06:14:43PM -0800, Eric Dumazet wrote: > On Mon, 2015-11-02 at 00:24 +, Al Viro wrote: > > > This ought to be a bit cleaner. Eric, could you test the variant below on > > your > > setup? > > Sure ! > > 5 runs of : > lpaa

Re: Fw: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-11-02 Thread Al Viro
On Mon, Nov 02, 2015 at 10:03:58AM +, David Laight wrote: > Remember, Solaris (and SYSV) has extra levels of multiplexing between > userspace and char special drivers (and probably sockets) than Linux does. > As well as having multiple fd referencing the same struct FILE, multiple > FILE can po

Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

2015-11-04 Thread Al Viro
On Wed, Nov 04, 2015 at 03:54:09PM +, David Laight wrote: > > Sigh... The kernel has no idea when other threads are done with "all > > io activities using that fd" - it can wait for them to leave the > > kernel mode, but there's fuck-all it can do about e.g. a userland > > loop doing write() u

  1   2   3   4   5   6   >