mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-20 19:23:57 +08:00
372ee16386
Inside the kafs filesystem it is possible to occasionally have a call processed and terminated before we've had a chance to check whether we need to clean up the rx queue for that call because afs_send_simple_reply() ends the call when it is done, but this is done in a workqueue item that might happen to run to completion before afs_deliver_to_call() completes. Further, it is possible for rxrpc_kernel_send_data() to be called to send a reply before the last request-phase data skb is released. The rxrpc skb destructor is where the ACK processing is done and the call state is advanced upon release of the last skb. ACK generation is also deferred to a work item because it's possible that the skb destructor is not called in a context where kernel_sendmsg() can be invoked. To this end, the following changes are made: (1) kernel_rxrpc_data_consumed() is added. This should be called whenever an skb is emptied so as to crank the ACK and call states. This does not release the skb, however. kernel_rxrpc_free_skb() must now be called to achieve that. These together replace rxrpc_kernel_data_delivered(). (2) kernel_rxrpc_data_consumed() is wrapped by afs_data_consumed(). This makes afs_deliver_to_call() easier to work as the skb can simply be discarded unconditionally here without trying to work out what the return value of the ->deliver() function means. The ->deliver() functions can, via afs_data_complete(), afs_transfer_reply() and afs_extract_data() mark that an skb has been consumed (thereby cranking the state) without the need to conditionally free the skb to make sure the state is correct on an incoming call for when the call processor tries to send the reply. (3) rxrpc_recvmsg() now has to call kernel_rxrpc_data_consumed() when it has finished with a packet and MSG_PEEK isn't set. (4) rxrpc_packet_destructor() no longer calls rxrpc_hard_ACK_data(). Because of this, we no longer need to clear the destructor and put the call before we free the skb in cases where we don't want the ACK/call state to be cranked. (5) The ->deliver() call-type callbacks are made to return -EAGAIN rather than 0 if they expect more data (afs_extract_data() returns -EAGAIN to the delivery function already), and the caller is now responsible for producing an abort if that was the last packet. (6) There are many bits of unmarshalling code where: ret = afs_extract_data(call, skb, last, ...); switch (ret) { case 0: break; case -EAGAIN: return 0; default: return ret; } is to be found. As -EAGAIN can now be passed back to the caller, we now just return if ret < 0: ret = afs_extract_data(call, skb, last, ...); if (ret < 0) return ret; (7) Checks for trailing data and empty final data packets has been consolidated as afs_data_complete(). So: if (skb->len > 0) return -EBADMSG; if (!last) return 0; becomes: ret = afs_data_complete(call, skb, last); if (ret < 0) return ret; (8) afs_transfer_reply() now checks the amount of data it has against the amount of data desired and the amount of data in the skb and returns an error to induce an abort if we don't get exactly what we want. Without these changes, the following oops can occasionally be observed, particularly if some printks are inserted into the delivery path: general protection fault: 0000 [#1] SMP Modules linked in: kafs(E) af_rxrpc(E) [last unloaded: af_rxrpc] CPU: 0 PID: 1305 Comm: kworker/u8:3 Tainted: G E 4.7.0-fsdevel+ #1303 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Workqueue: kafsd afs_async_workfn [kafs] task: ffff88040be041c0 ti: ffff88040c070000 task.ti: ffff88040c070000 RIP: 0010:[<ffffffff8108fd3c>] [<ffffffff8108fd3c>] __lock_acquire+0xcf/0x15a1 RSP: 0018:ffff88040c073bc0 EFLAGS: 00010002 RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000000 RCX: ffff88040d29a710 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88040d29a710 RBP: ffff88040c073c70 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88040be041c0 R15: ffffffff814c928f FS: 0000000000000000(0000) GS:ffff88041fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa4595f4750 CR3: 0000000001c14000 CR4: 00000000001406f0 Stack: 0000000000000006 000000000be04930 0000000000000000 ffff880400000000 ffff880400000000 ffffffff8108f847 ffff88040be041c0 ffffffff81050446 ffff8803fc08a920 ffff8803fc08a958 ffff88040be041c0 ffff88040c073c38 Call Trace: [<ffffffff8108f847>] ? mark_held_locks+0x5e/0x74 [<ffffffff81050446>] ? __local_bh_enable_ip+0x9b/0xa1 [<ffffffff8108f9ca>] ? trace_hardirqs_on_caller+0x16d/0x189 [<ffffffff810915f4>] lock_acquire+0x122/0x1b6 [<ffffffff810915f4>] ? lock_acquire+0x122/0x1b6 [<ffffffff814c928f>] ? skb_dequeue+0x18/0x61 [<ffffffff81609dbf>] _raw_spin_lock_irqsave+0x35/0x49 [<ffffffff814c928f>] ? skb_dequeue+0x18/0x61 [<ffffffff814c928f>] skb_dequeue+0x18/0x61 [<ffffffffa009aa92>] afs_deliver_to_call+0x344/0x39d [kafs] [<ffffffffa009ab37>] afs_process_async_call+0x4c/0xd5 [kafs] [<ffffffffa0099e9c>] afs_async_workfn+0xe/0x10 [kafs] [<ffffffff81063a3a>] process_one_work+0x29d/0x57c [<ffffffff81064ac2>] worker_thread+0x24a/0x385 [<ffffffff81064878>] ? rescuer_thread+0x2d0/0x2d0 [<ffffffff810696f5>] kthread+0xf3/0xfb [<ffffffff8160a6ff>] ret_from_fork+0x1f/0x40 [<ffffffff81069602>] ? kthread_create_on_node+0x1cf/0x1cf Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
caif | ||
dsa | ||
mac80211_hwsim | ||
timestamping | ||
3c509.txt | ||
6lowpan.txt | ||
6pack.txt | ||
00-INDEX | ||
alias.txt | ||
altera_tse.txt | ||
arcnet-hardware.txt | ||
arcnet.txt | ||
atm.txt | ||
ax25.txt | ||
batman-adv.txt | ||
baycom.txt | ||
bonding.txt | ||
bridge.txt | ||
can.txt | ||
cdc_mbim.txt | ||
checksum-offloads.txt | ||
cops.txt | ||
cs89x0.txt | ||
cxacru-cf.py | ||
cxacru.txt | ||
cxgb.txt | ||
dccp.txt | ||
dctcp.txt | ||
de4x5.txt | ||
decnet.txt | ||
dl2k.txt | ||
dm9000.txt | ||
dmfe.txt | ||
dns_resolver.txt | ||
driver.txt | ||
e100.txt | ||
e1000.txt | ||
e1000e.txt | ||
eql.txt | ||
fib_trie.txt | ||
filter.txt | ||
fore200e.txt | ||
framerelay.txt | ||
gen_stats.txt | ||
generic_netlink.txt | ||
generic-hdlc.txt | ||
gianfar.txt | ||
i40e.txt | ||
i40evf.txt | ||
ieee802154.txt | ||
igb.txt | ||
igbvf.txt | ||
ip_dynaddr.txt | ||
ip-sysctl.txt | ||
ipddp.txt | ||
iphase.txt | ||
ipsec.txt | ||
ipv6.txt | ||
ipvlan.txt | ||
ipvs-sysctl.txt | ||
irda.txt | ||
ixgb.txt | ||
ixgbe.txt | ||
ixgbevf.txt | ||
kcm.txt | ||
l2tp.txt | ||
lapb-module.txt | ||
LICENSE.qla3xxx | ||
LICENSE.qlcnic | ||
LICENSE.qlge | ||
ltpc.txt | ||
mac80211-auth-assoc-deauth.txt | ||
mac80211-injection.txt | ||
Makefile | ||
mpls-sysctl.txt | ||
multiqueue.txt | ||
netconsole.txt | ||
netdev-FAQ.txt | ||
netdev-features.txt | ||
netdevices.txt | ||
netif-msg.txt | ||
nf_conntrack-sysctl.txt | ||
nfc.txt | ||
openvswitch.txt | ||
operstates.txt | ||
packet_mmap.txt | ||
phonet.txt | ||
phy.txt | ||
pktgen.txt | ||
PLIP.txt | ||
policy-routing.txt | ||
ppp_generic.txt | ||
proc_net_tcp.txt | ||
radiotap-headers.txt | ||
ray_cs.txt | ||
rds.txt | ||
README.ipw2100 | ||
README.ipw2200 | ||
README.sb1000 | ||
regulatory.txt | ||
rxrpc.txt | ||
s2io.txt | ||
scaling.txt | ||
sctp.txt | ||
secid.txt | ||
segmentation-offloads.txt | ||
skfp.txt | ||
smc9.txt | ||
spider_net.txt | ||
stmmac.txt | ||
switchdev.txt | ||
tc-actions-env-rules.txt | ||
tcp-thin.txt | ||
tcp.txt | ||
team.txt | ||
timestamping.txt | ||
tlan.txt | ||
tproxy.txt | ||
tuntap.txt | ||
udplite.txt | ||
vortex.txt | ||
vrf.txt | ||
vxge.txt | ||
vxlan.txt | ||
x25-iface.txt | ||
x25.txt | ||
xfrm_proc.txt | ||
xfrm_sync.txt | ||
xfrm_sysctl.txt | ||
z8530drv.txt |
sb1000 is a module network device driver for the General Instrument (also known as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card which is used by a number of cable TV companies to provide cable modem access. It's a one-way downstream-only cable modem, meaning that your upstream net link is provided by your regular phone modem. This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves a great deal of thanks for this wonderful piece of code! ----------------------------------------------------------------------------- Support for this device is now a part of the standard Linux kernel. The driver source code file is drivers/net/sb1000.c. In addition to this you will need: 1.) The "cmconfig" program. This is a utility which supplements "ifconfig" to configure the cable modem and network interface (usually called "cm0"); and 2.) Several PPP scripts which live in /etc/ppp to make connecting via your cable modem easy. These utilities can be obtained from: http://www.jacksonville.net/~fventuri/ in Franco's original source code distribution .tar.gz file. Support for the sb1000 driver can be found at: http://web.archive.org/web/*/http://home.adelphia.net/~siglercm/sb1000.html http://web.archive.org/web/*/http://linuxpower.cx/~cable/ along with these utilities. 3.) The standard isapnp tools. These are necessary to configure your SB1000 card at boot time (or afterwards by hand) since it's a PnP card. If you don't have these installed as a standard part of your Linux distribution, you can find them at: http://www.roestock.demon.co.uk/isapnptools/ or check your Linux distribution binary CD or their web site. For help with isapnp, pnpdump, or /etc/isapnp.conf, go to: http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html ----------------------------------------------------------------------------- To make the SB1000 card work, follow these steps: 1.) Run `make config', or `make menuconfig', or `make xconfig', whichever you prefer, in the top kernel tree directory to set up your kernel configuration. Make sure to say "Y" to "Prompt for development drivers" and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard networking questions to get TCP/IP and PPP networking support. 2.) *BEFORE* you build the kernel, edit drivers/net/sb1000.c. Make sure to redefine the value of READ_DATA_PORT to match the I/O address used by isapnp to access your PnP cards. This is the value of READPORT in /etc/isapnp.conf or given by the output of pnpdump. 3.) Build and install the kernel and modules as usual. 4.) Boot your new kernel following the usual procedures. 5.) Set up to configure the new SB1000 PnP card by capturing the output of "pnpdump" to a file and editing this file to set the correct I/O ports, IRQ, and DMA settings for all your PnP cards. Make sure none of the settings conflict with one another. Then test this configuration by running the "isapnp" command with your new config file as the input. Check for errors and fix as necessary. (As an aside, I use I/O ports 0x110 and 0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) Then save the finished config file as /etc/isapnp.conf for proper configuration on subsequent reboots. 6.) Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of the others referenced above. As root, unpack it into a temporary directory and do a `make cmconfig' and then `install -c cmconfig /usr/local/sbin'. Don't do `make install' because it expects to find all the utilities built and ready for installation, not just cmconfig. 7.) As root, copy all the files under the ppp/ subdirectory in Franco's tar file into /etc/ppp, being careful not to overwrite any files that are already in there. Then modify ppp@gi-on to set the correct login name, phone number, and frequency for the cable modem. Also edit pap-secrets to specify your login name and password and any site-specific information you need. 8.) Be sure to modify /etc/ppp/firewall to use ipchains instead of the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to convert ipfwadm commands to ipchains commands: http://users.dhp.com/~whisper/ipfwadm2ipchains/ You may also wish to modify the firewall script to implement a different firewalling scheme. 9.) Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be root to do this. It's better to use a utility like sudo to execute frequently used commands like this with root permissions if possible. If you connect successfully the cable modem interface will come up and you'll see a driver message like this at the console: cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11. sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net) The "ifconfig" command should show two new interfaces, ppp0 and cm0. The command "cmconfig cm0" will give you information about the cable modem interface. 10.) Try pinging a site via `ping -c 5 www.yahoo.com', for example. You should see packets received. 11.) If you can't get site names (like www.yahoo.com) to resolve into IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file has no syntax errors and has the right nameserver IP addresses in it. If this doesn't help, try something like `ping -c 5 204.71.200.67' to see if the networking is running but the DNS resolution is where the problem lies. 12.) If you still have problems, go to the support web sites mentioned above and read the information and documentation there. ----------------------------------------------------------------------------- Common problems: 1.) Packets go out on the ppp0 interface but don't come back on the cm0 interface. It looks like I'm connected but I can't even ping any numerical IP addresses. (This happens predominantly on Debian systems due to a default boot-time configuration script.) Solution -- As root `echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter' so it can share the same IP address as the ppp0 interface. Note that this command should probably be added to the /etc/ppp/cablemodem script *right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands. You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well. If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot (in rc.local or some such) then any interfaces can share the same IP addresses. 2.) I get "unresolved symbol" error messages on executing `insmod sb1000.o'. Solution -- You probably have a non-matching kernel source tree and /usr/include/linux and /usr/include/asm header files. Make sure you install the correct versions of the header files in these two directories. Then rebuild and reinstall the kernel. 3.) When isapnp runs it reports an error, and my SB1000 card isn't working. Solution -- There's a problem with later versions of isapnp using the "(CHECK)" option in the lines that allocate the two I/O addresses for the SB1000 card. This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses. Make sure they don't conflict with any other pieces of hardware first! Then rerun isapnp and go from there. 4.) I can't execute the /etc/ppp/ppp@gi-on file. Solution -- As root do `chmod ug+x /etc/ppp/ppp@gi-on'. 5.) The firewall script isn't working (with 2.2.x and higher kernels). Solution -- Use the ipfwadm2ipchains script referenced above to convert the /etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains. 6.) I'm getting *tons* of firewall deny messages in the /var/kern.log, /var/messages, and/or /var/syslog files, and they're filling up my /var partition!!! Solution -- First, tell your ISP that you're receiving DoS (Denial of Service) and/or portscanning (UDP connection attempts) attacks! Look over the deny messages to figure out what the attack is and where it's coming from. Next, edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on to the "cmconfig" command (uncomment that line). If you're not receiving these denied packets on your broadcast interface (IP address xxx.yyy.zzz.255 typically), then someone is attacking your machine in particular. Be careful out there.... 7.) Everything seems to work fine but my computer locks up after a while (and typically during a lengthy download through the cable modem)! Solution -- You may need to add a short delay in the driver to 'slow down' the SURFboard because your PC might not be able to keep up with the transfer rate of the SB1000. To do this, it's probably best to download Franco's sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll want to edit the 'Makefile' and look for the 'SB1000_DELAY' define. Uncomment those 'CFLAGS' lines (and comment out the default ones) and try setting the delay to something like 60 microseconds with: '-DSB1000_DELAY=60'. Then do `make' and as root `make install' and try it out. If it still doesn't work or you like playing with the driver, you may try other numbers. Remember though that the higher the delay, the slower the driver (which slows down the rest of the PC too when it is actively used). Thanks to Ed Daiga for this tip! ----------------------------------------------------------------------------- Credits: This README came from Franco Venturi's original README file which is still supplied with his driver .tar.gz archive. I and all other sb1000 users owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten and Ralph Bonnell who are now managing the Linux SB1000 web site, and to the SB1000 users who reported and helped debug the common problems listed above. Clemmitt Sigler csigler@vt.edu